> JPEG XL as a technical project was a real nightmare
Why?
> (surprisingly, Firefox is not attributed this - they also do not support it yet, and they are not doing anything _other_ than awaiting Chrome's work for it!)
Those writing the new Rust decoder are largely people who worked on the standard and on the original C++ implementation, + contributions from the author of jxl-oxide (who is not at Google).
JPEG XL is not “apply zstd to the pixel data”. What the parent comment meant is that JPEG XL, like zstd, happens to use ANS among its set of techniques. It handles gradients just fine.
> How so? As far as I can tell, the ICCv2 spec is very agnostic as to the gamut and dynamic range of the output medium. It doesn't say anything to the extent of "thou shalt not produce any colors outside the sRGB gamut, nor make the white point too bright".
That’s precisely what makes it unsuitable for HDR. With PQ, (1, 1, 1) means 10 000 cd/m² – if you simply create an ICC profile with the PQ transfer function, an image that looks right on a hypothetical 10 000 cd/m² monitor will look way too dim when naïvely scaled down (as ICC-type colour management would have you do) to the 300 cd/m² of a typical monitor. HLG, meanwhile, has a transfer function that depends on the peak luminance, which is not possible to do with ICC (the profile would have to assume a specific peak luminance), and the reason that it does that is to preserve the subjective perception of the image.
So, sure, you can prepare an HDR image so that it looks right on a monitor with a 1000 cd/m² peak luminance, describe the colorspace in relative terms using an ICC profile, and you will have “done HDR using ICC”, but that’s arguably a very low bar for “supporting HDR”.
JPEG can be rotated losslessly. `jpegtran` can do it, for example (and comes with a script called `exifautotran` to automatically normalise the orientation of a bunch of JPEG files at once).
reply