Handle various bits per sample values in JPEG XL files

[1div0]

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]

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]

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

[lgritz]

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]

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.

[jessey-git]

Gentle nudge. How's this PR going?

[1div0]

C001! Finally all checked. Lesson learned. Will do better next time_t.

Good Night. And Good Luck.