Using SDKs directly also means numerous APIs, one for each SDK, instead of one API.
Since you have so much direct experience dealing with undocumented RAW formats from so many vendors what’s your best guess at this early stage? Is this all a bit of a tempest in a teapot and not really that different from any other new RAW format that may require reverse engineering? Seems very similar approach technically to Canon’s CRAW - how did that pan out?
CR3 took a lot of effort, close to a year. Current Canon decoder incorporates some code similar to what we have in LibRaw, which speeds things up a bit. We can't be sure of course, but maybe they looked into what we have.
I can't predict how much time it will take with HE, because it also depends on how lucky we are with our guesses.
I'm still very much amazed the raw formats are kept secret. Don't see the point.
Iliah, just want to say that as a user of libraw, I really appreciate your efforts to keep up with this crap. Without it, I wouldn't have had much success in developing a full-featured raw processor all by myself.
In fact, here's a shout-out to the libraries I've found instrumental in my endeavor:
LibRaw - reads a humongous number raw formats
LittleCMS - color management for a "color mechanic" like me
exiv2 - all things metadata
librtprocess - most-excellent demosaics and highlight reconstruction from RawTherapee
Libraw and exiv2 developers do the heavy lifting figuring all these image formats with little to no help from the manufacturers, and in a pretty responsive manner considering they do this for free. Thanks!
And yeah, me too, I really don't get why the manufacturers don't make the effort to make the products of their precious products more usable. Although, recent efforts to field things like Apple ProRaw represent a goofy sort of compromise, high-bitdepth RGB that's more amenable to editing (really, nothing a 16-bit TIFF with an embedded color profile couldn't do...)
