-
Notifications
You must be signed in to change notification settings - Fork 606
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build(deps): Raise minimum libraw to 0.18 #3921
Conversation
Soliciting opinions on this. Please do speak up if you think there is a good reason to continue supporting libraw 0.15-0.17 for OIIO 2.5 that will be the supported release for late 2023 and most of 2024. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't use libraw, so I have no opinions on whether newer versions have bugs or if there's a good reason not to upgrade. Assuming there are no issues with newer versions, this requirement seems fine with me. The code, looks correct (lots of cleanups, removing no longer needed code).
#ifdef LIBRAW_DECODER_FLATFIELD | ||
// See if we can access the Bayer patterned data for this raw file | ||
libraw_decoder_info_t decoder_info; | ||
m_processor->get_decoder_info(&decoder_info); | ||
if (!(decoder_info.decoder_flags & LIBRAW_DECODER_FLATFIELD)) { | ||
errorf("Unable to extract unbayered data from file \"%s\"", | ||
name); | ||
return false; | ||
} | ||
|
||
#endif |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm guessing this is code that no longer exists in newer libraw?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, LIBRAW_DECODER_FLATFIELD disappeared several versions back.
This is just about compatibility with old versions, raising the minimum. We were never preventing people from using newer ones, so it's not really a worry that new ones might have bugs (I'd put money on old ones being buggier, by virtue of the fact that they'll never get any more fixes). And in any case, once we raise our C++ minimum to 17, we will have to raise the minimum libRaw again to 0.20, since earlier versions don't compile cleanly with C++17. This is just a half-way step along that path that we'll be forced to follow soon anyway. |
Rationale: * LibRaw 0.18 was released in last 2016, so we are stil supporting all libraw from up to 6 years back. * LibRaw 0.18 is necessary for ACES, plus it improves a lot of metadata handling. * LibRaw 0.20 is the minimum that can be used when compiling with C++17, and we will almost certainly move to C++17 as a minimum in OIIO 2.6, so it seems like LibRaw 0.18 is reasonable minimum for the upcmoming 2.5. Remove some cruft that's no longer necessary if we drop support for 0.15-0.17. Signed-off-by: Larry Gritz <[email protected]>
Rationale:
Remove some cruft that's no longer necessary if we drop support for 0.15-0.17.