31 ms·

Show HN: Fixing 100 years of analog lens compatibility with data driven solution

Hi HN, Bruno here. I’m not a developer, but I’ve spent 15+ years in the photography industry as a camera/lens reviewer, photojournalist, and consultant for major brands. One of the most frequent (and frustrating) questions photographers ask is: “Will this lens work on this camera?” You’d think this would be a solved problem in the AI era... but it’s not. There has never been a structured, global dataset for cross-system lens compatibility. --- ### Why? The data exists, but it’s fragmented—buried in *paper archives, PDF manuals, and old forums from the Dot-Com era*. Compatibility isn’t just about mount fit: there are flange distance constraints, electronic protocols, AF & aperture limitations, and third-party adapters. *Manufacturers (Canon, Nikon, Sony, etc.) have attempted to document their own systems—but often with errors, omissions, and without ever considering intercompatibility between brands. No one has ever attempted to unify this knowledge in an open, structured way. --- ### So after Christmas, I decided to teach myself coding and build what nobody else had: CLIC – Camera & Lens Interoperability Checker Covers 71 manufacturers, 106 mounts, 1347 cameras, and 4039 lenses (for now). Detects native compatibility + third-party adapter solutions. Calculates theoretical matchups (~2.1M possible combinations). Database grows daily—based on historical archives and community contributions. --- ### Challenges: Structuring compatibility logic in a scalable way (mechanical fit, adapters, electronic limitations). Extracting reliable data from disparate sources (manufacturers' PDFs, old forum posts, literal books). Managing edge cases (e.g., Nikon F mount has ~10 sub-versions* with different behaviors). --- ### Try it here → https://www.fotocaz.com/ https://www.fotocaz.com/ Still a work in progress, but I’d love feedback from HN on: Eliminating false positives to ensure the tool provides photographically accurate results, not just technically correct ones. (There’s what the code says, and what mechanical + optical constraints allow.) Better ways to structure the dataset (currently using JSON and Vanilla JS… but it won’t scale easily). Efficient search/filtering for 2M+ potential matchups (and this problem can only grow as I add more lenses, cameras, mounts and adapters, because in 100 years, manufacturers had plenty of time to go wild). How to handle cases where official compatibility info is missing or uncertain? I’m here to learn from you and improve this tool. Thoughts?

aboardRat4 2y ago
Nice tool, but fails when the network is intermittent. I suggest loading all data together with the page, and avoid using AJAX altogether. It's not huge, after all, just a few megs.
- bruno_labarbere 2y ago
  Thanks for the feedback! You're making a point. You're absolutely right: today, CLIC relies entirely on AJAX, which is not ideal if the connection drops. Loading everything upfront would make it more resilient, but I'm also trying to avoid making users wait several seconds before they can do anything. That said, the database is "only" 4.3 MB, so yeah, it's not huge, but my priority so far has been to get the compatibility logic right before optimizing performance. Basically, I focus on making sure the results are photographically accurate before worrying about network issues. Of course, if users can't even load the database, they don't have much to verify! I see a few ways to improve this: - Preloading a compressed version (.gz or .br) to reduce size. - Lazy-loading only what's necessary, then fetching extra data when needed (first need to learn how to do it). - Implementing a fallback cache (LocalStorage/IndexedDB) to avoid reloading every time. - Also, one potential optimization would be loading only the most popular brands/mounts first, then fetching the rest on demand. The problem? I don’t have enough user data yet to know what’s actually "popular" and I won’t get that data unless people use the tool first. So, yeah... chicken & egg problem. For now, brute force it is, but once I get more feedback on what users search for the most, I can optimize accordingly. It's a trade-off between "just making sure it works at all" and "making it load efficiently." But I’ll definitely look into this!

aboardRat4 2y ago

Nice tool, but fails when the network is intermittent. I suggest loading all data together with the page, and avoid using AJAX altogether. It's not huge, after all, just a few megs.

bruno_labarbere 2y ago
Thanks for the feedback! You're making a point. You're absolutely right: today, CLIC relies entirely on AJAX, which is not ideal if the connection drops. Loading everything upfront would make it more resilient, but I'm also trying to avoid making users wait several seconds before they can do anything. That said, the database is "only" 4.3 MB, so yeah, it's not huge, but my priority so far has been to get the compatibility logic right before optimizing performance. Basically, I focus on making sure the results are photographically accurate before worrying about network issues. Of course, if users can't even load the database, they don't have much to verify! I see a few ways to improve this: - Preloading a compressed version (.gz or .br) to reduce size. - Lazy-loading only what's necessary, then fetching extra data when needed (first need to learn how to do it). - Implementing a fallback cache (LocalStorage/IndexedDB) to avoid reloading every time. - Also, one potential optimization would be loading only the most popular brands/mounts first, then fetching the rest on demand. The problem? I don’t have enough user data yet to know what’s actually "popular" and I won’t get that data unless people use the tool first. So, yeah... chicken & egg problem. For now, brute force it is, but once I get more feedback on what users search for the most, I can optimize accordingly. It's a trade-off between "just making sure it works at all" and "making it load efficiently." But I’ll definitely look into this!