-
Notifications
You must be signed in to change notification settings - Fork 630
Handle various bits per sample values in JPEG XL files #4738
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
base: main
Are you sure you want to change the base?
The head ref may contain hidden characters: "JPEG\u00A0XL\u00A0bits\u00A0per\u00A0sample"
Handle various bits per sample values in JPEG XL files #4738
Conversation
Signed-off-by: Peter Kovář <[email protected]>
Signed-off-by: Peter Kovář <[email protected]>
If you get something like 12 bps, are you just leaving those values as they are but storing them in a uint16? So, like, fully bright is 4095? The design philosophy we adopted is that the app shouldn't need to consider every possible bit depth. On the app side of the interface, we pretend all values are UINT8, UINT16, HALF, etc. So the OIIO reader is expected to "round up" and promote a "non-whole" bit depth to the next bigger whole one -- e.g., 12 bit in the file becomes UINT16. But we want it to look like a proper UINT16, so what we do is scale the values up so that the max brightness is always 65535 for UINT16 data. Also when we do this scaling, we set in the ImageSpec an attribute "oiio:BitsPerSample" that gives the origin number of bits in the file. You can see how this works in tiffinput.cpp, for example. Look circa line 1053 (in current main), and 1859 for where the bit depth scaling takes place. |
@1div0 ping on this, I had made some comments/questions |
Hi, @1div0, do you have any comments on the question I had about whether different bit depths in the file were being properly scaled to the full data type range before being handed to the app? |
Last two weeks were extremely busy. The various bit depth in JPEG XL image files in the range from 1 to 31 bits per channel are handled by the decoder in the reference libjxl transparently according to selected data type. That means 8, 16 and 32 bits per channel in output from decoder are scaled properly, so there is not needed to do more. In other words, 12 bpc images are scaled to next bigger type UINT16. |
bits = 32; | ||
} |
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.
We're getting at least one CI failure for gcc11 that is pointing out an error where 'bits' may be uninitialized. I would recommend one more final else
clause here that calls errfmt and returns false, catching any situation where info.bits_per_sample could possibly have a value > 32.
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.
Will take care of it in the evening.
I was wondering why the 12 bits per channel images were rejected by the image viewer?
Description
Extend the ranges of bits per sample.