[Webkit-unassigned] [Bug 208235] Support JPEG XL images

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=208235

Jon Sneyers <jon at cloudinary.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jon at cloudinary.com

--- Comment #9 from Jon Sneyers <jon at cloudinary.com> ---
No, libjxl cannot handle color management for you, for the simple reason that libjxl has no way of knowing the display color space. So it is the same as with any other image format in that respect: you get uncompressed pixel values and an ICC profile, which together define a decoded image. To show those pixels on a screen, you have to convert them from the image color space (given by the ICC profile) to the display color space (which is how the screen will interpret pixel values). You cannot simply assume that the display color space will be sRGB; wider gamut screens are common (e.g. Display P3), and also HDR screens are becoming more common (e.g. Rec.2100 PQ or HLG).

That said; if you happen to know the display color space, using JxlDecoderSetPreferredColorProfile() you _can_ ask the libjxl decoder to try to do the color management for you, i.e. to return pixels that are already in that color space. This is only possible for certain display color spaces (the ones that can be described by a JxlColorEncoding, which includes most color spaces used in practice like sRGB, AdobeRGB, Display P3, DCI-P3, Rec.2100, etc; it doesn't include more complicated color spaces though that e.g. use lookup tables), and even then it is not guaranteed that libjxl will be able to return pixels in the requested space: it can only do that in the case of lossy images (which use an internal absolute color space called XYB) and in the case of lossless images that are in a JxlColorEncoding color space; it cannot do that in more complicated cases like CMYK or weird arbitrary-ICC-profile cases.

Anyway, in practice you should just take the pixel data and the ICC profile returned by the libjxl decoder and do the same thing with it as with any other image. It can be optimized a bit in case you happen to know the display space - using JxlDecoderSetPreferredColorProfile() you can make it very likely that the returned ICC profile happens to be identical to the display space, so your CMS gets a no-op case (pixel values don't need to be converted at all) - but that's an optimization I wouldn't bother to implement in an initial implementation of jxl support (since likely it requires quite a bit of nontrivial code plumbing for you to actually know the display space).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20211119/6a72bb05/attachment-0001.htm>