JPEG XL overview available

[Jyrki Alakuijala]

Here: https://jpeg.org/jpegxl/index.html

[SolidComp]

This is interesting. I'm glad it supports HDR images. It might solve the problems that Netflix outlined here concerning HDR images and graphics for their UI.

[SolidComp]

Jyrki, what do you think of the 32-bit per channel color support? What would that look like? Is it overkill? Would human eyes appreciate the difference in, say, 12-bit per channel color vs. 8-bit?

10 and 12 bit seem to be the targets for HDR video (Dolby Vision, HDR10, etc.) 32-bit would be 128 bits per pixel if they also have a 32-bit alpha channel.

[Jyrki Alakuijala]

Jyrki, what do you think of the 32-bit per channel color support? What would that look like? Is it overkill?

8 bits is not quite enough for sdr, and 10 bits is better there. For hdr 15 bits seems to be enough. So, yes, 32 bit internals are an overkill. The choice of internally 32 bits based on availability of simd primitives. 16 bit integers would have made possibly more sense but decoding would have been slower.

[SolidComp]

Jyrki, are you working on the JPEG XL project? Is there any cross-pollination between JPEG XL and PIK? What will become of PIK?

[Jyrki Alakuijala]

Jyrki, are you working on the JPEG XL project? Is there any cross-pollination between JPEG XL and PIK? What will become of PIK?

Yes, fully working on a pik derivative as one of the codecs in jpeg xl. We are in the phase where we are removing 'unnecessary moving parts' and writing the spec.

[SolidComp]

Yes, fully working on a pik derivative as one of the codecs in jpeg xl. We are in the phase where we are removing 'unnecessary moving parts' and writing the spec.

Cool, let me know if you need help. I'm good at spec writing, though I've never written a spec for an image format.

[mo0n_sniper]

For what will the PIK based codec will be used in Jpeg XL?

[Jyrki Alakuijala]

For what will the PIK based codec will be used in Jpeg XL?

For general purpose lossy image compression. It is rather close to being a traditional jpeg, just more dense.

[thorfdbg]

8 bits is not quite enough for sdr, and 10 bits is better there. For hdr 15 bits seems to be enough. So, yes, 32 bit internals are an overkill. The choice of internally 32 bits based on availability of simd primitives. 16 bit integers would have made possibly more sense but decoding would have been slower.

What is certainly necessary to understand is how you define HDR. There are two approaches: The approach taken by MPEG assuming an n-bit integer representation which then undergoes an EOTF to map it to radiance values, and the EOTF is signaled by additional metadata. There is also the approach that was taken by JPEG XT Part 7 (unlike Part 6, which follows the EOTF approach) where you assume that your images are represented in relative or absolute radiance, and the radiance is then the pixel value. This then follows the workflow in computational photography, and the approach OpenEXR uses. In the latter case, you want to have at least 16 bit, which are then however floating point. While 32 bit are probably overshoot, you may want to look into JPEG 2000 part 2 where the number of bits in exponent and mantissa are signaled, and a floating point format is being used. By that I mean that a simple "int only" approach may not be fully sufficient, and 16 bits may not be fully sufficient if you have radiance images.

[SolidComp]

What is certainly necessary to understand is how you define HDR. There are two approaches: The approach taken by MPEG assuming an n-bit integer representation which then undergoes an EOTF to map it to radiance values, and the EOTF is signaled by additional metadata. There is also the approach that was taken by JPEG XT Part 7 (unlike Part 6, which follows the EOTF approach) where you assume that your images are represented in relative or absolute radiance, and the radiance is then the pixel value. This then follows the workflow in computational photography, and the approach OpenEXR uses. In the latter case, you want to have at least 16 bit, which are then however floating point. While 32 bit are probably overshoot, you may want to look into JPEG 2000 part 2 where the number of bits in exponent and mantissa are signaled, and a floating point format is being used. By that I mean that a simple "int only" approach may not be fully sufficient, and 16 bits may not be fully sufficient if you have radiance images.

Which MPEG standard are you referring to?

Also, what approach do they take for HDR video like in HDR10+ and Dolby Vision? Are they mapping to radiance values? HDR10+ uses 10-bit integers, not surprisingly. Dolby Vision is 12-bit, and I think it must be integers not FP (there might also be a 10-bit form of Dolby Vision but I'm not sure).

[Jyrki Alakuijala]

15 bits gives 32768 values. JPEG XL XYB colorspace uses always cubic mapping to get photons from the compressed values. This means dynamic range is 1 : 32768³, i.e., 1 : 35184372088832. While some image formats may give more dynamic range, JPEG XL should be enough for all comfort viewing with about 7 orders of magnitude of headroom.