Skip to content

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

1div0
Copy link
Contributor

@1div0 1div0 commented May 4, 2025

I was wondering why the 12 bits per channel images were rejected by the image viewer?

Description

Extend the ranges of bits per sample.

@lgritz
Copy link
Collaborator

lgritz commented May 4, 2025

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.

@lgritz
Copy link
Collaborator

lgritz commented May 21, 2025

@1div0 ping on this, I had made some comments/questions

@lgritz
Copy link
Collaborator

lgritz commented May 31, 2025

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?

@1div0
Copy link
Contributor Author

1div0 commented Jun 1, 2025

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.

Comment on lines +264 to 265
bits = 32;
}
Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants