JPEG XL color space in lossy mode about libjxl HOT 15 OPEN

There is a special field in image header to signal XYB-encoded image, and it is independent of tagged color space info. For XYB-encoded images, tagged color space (and ICC profiles) typically represents what color space the original image was in.

from libjxl.

How can I determine whether the images are encoded in XYB format? Are you suggesting that XYB-encoded images might still contain ICC profiles representing their original color spaces, such as DisplayP3, similar to the example I've provided? If so, why isn't the ICC profile that corresponds to the original AdobeRGB color space embedded when the input is a png file in AdobeRGB? Thank you.

from libjxl.

BTW, ImageMagic shows both have different ICC profile

First one from AdobeRGB

    icc:copyright: CC0
    icc:description: RGB_D65_0.639997;0.329997;0.210005;0.710005;0.149998;0.060004_Per_g0.454707

Second one from DisplayP3

    icc:copyright: CC0
    icc:description: RGB_D65_DCI_Per_SRG

from libjxl.

How can I determine whether the images are encoded in XYB format?

It seems that jxlinfo doesn't explicitly show whether image is XYB or not, but it's actually encoded in the bitstream. You can use jxl-oxide to determine if it's XYB-encoded, or manually parse the beginning of the image using libjxl directly.

Are you suggesting that XYB-encoded images might still contain ICC profiles representing their original color spaces, such as DisplayP3, similar to the example I've provided?

Yes, but if it's the case, those information is just a suggestion. Decoders are free to decode those images in sRGB, color space of the monitor, or anything. However most decoders will decode to the tagged color space by default.

If so, why isn't the ICC profile that corresponds to the original AdobeRGB color space embedded when the input is a png file in AdobeRGB?

JPEG XL can represent some special color spaces without ICC profiles. These color spaces are called "enum color space". When encoding, libjxl detects such ICC profiles, converts them to enum color space and skips embedding ICC profiles. Display P3 and Adobe RGB are representable with enum color space.

libjxl can also "synthesize" an ICC profile of enum color space. ImageMagick seems to show the synthesized ICC profiles.

from libjxl.

JPEG XL can represent some special color spaces without ICC profiles. These color spaces are called "enum color space". When encoding, libjxl detects such ICC profiles, converts them to enum color space and skips embedding ICC profiles. Display P3 and Adobe RGB are representable with enum color space.

Only Display P3 (and some others) can be represented by CICP enums, AdobeRGB cannot, so ICC is the only option there.

from libjxl.

JPEG XL "enum color space" supports custom primaries and gamma, so Adobe RGB can be represented with those too.

from libjxl.

JPEG XL "enum color space" supports custom primaries and gamma

Sure, but if it's not a CICP enum, there's not much point/advantage in recording the custom values over the more widely supported ICC profile. I doubt many 3rd parties handle the custom values...

from libjxl.

Thanks @tirr-c for pointing out jxl-oxide.

Both of them are XYB-encoded.

First one from AdobeRGB

dbtsai@DBs-Mac ~ % jxl-oxide  -I adobergb.jxl
JPEG XL image (Container)
  Image dimension: 7952x5304
  Bit depth: 16 bits
  XYB encoded, suggested display color encoding:
    Colorspace: RGB
    White point: D65
    Primaries: 0.639997, 0.329997; 0.210005, 0.710005; 0.149998, 0.060004
    Transfer function: Gamma 2.199218881437691
Frame #0 (keyframe)
  VarDCT (lossy)
  Frame type: Regular
  7952x5304; (0, 0)

Second one from DisplayP3

dbtsai@DBs-Mac ~  % jxl-oxide  -I displayp3.jxl 
JPEG XL image (Container)
  Image dimension: 7952x5304
  Bit depth: 16 bits
  XYB encoded, suggested display color encoding:
    Colorspace: RGB
    White point: D65
    Primaries: P3
    Transfer function: sRGB
Frame #0 (keyframe)
  VarDCT (lossy)
  Frame type: Regular
  7952x5304; (0, 0)

Based on the jxl-oxide, it seems that the version from AdobeRGB utilizes an enum color space featuring custom primaries and gamma, doesn't it?

Additionally, it appears that neither version embeds the original ICC profiles, opting instead to incorporate only the synthesized ICC profiles, correct?

from libjxl.

If jxlinfo says the image is "lossy", it means it is internally using XYB.
If it says the image is "possibly lossless", it means it is internally not using XYB.

Using XYB internally implies lossy; not using XYB doesn't mean it's lossless but typically it will be either lossless from pixels or a lossless JPEG recompression.

from libjxl.

Is the XYB color model universal and unaffected by the RGB color space it originates from? If that's the case, does this mean we can modify the recommended display color encoding without altering the XYB values?

from libjxl.

JPEG XL "enum color space" supports custom primaries and gamma

Sure, but if it's not a CICP enum, there's not much point/advantage in recording the custom values over the more widely supported ICC profile. I doubt many 3rd parties handle the custom values...

The value is that in order to convert into the space of an arbitrary ICC profile, you need a CMS engine, whereas primaries and transfer can be handled by linear algebra provided you know the coordinates in CIE-xy and the transfer function.

from libjxl.

The value is that in order to convert into the space of an arbitrary ICC profile, you need a CMS engine, whereas primaries and transfer can be handled by linear algebra provided you know the coordinates in CIE-xy and the transfer function.

I understand that, just saying that I suspect a lot of existing implementations will just expect an ICC profile to pass on to CMS, and are not quite ready to actually construct one (IMHO an unnecessary burden for most).

And yes, PNG also has this in cHRM and gAMA tags. I rarely see it being used. Almost everyone who cares about color reproduction just goes for ICC, because it is widely supported.

from libjxl.

It does not matter if an ICC profile for the custom primaries is not embedded in the JXL itself because libjxl can synthesize one if necessary.

from libjxl.

It does not matter if an ICC profile for the custom primaries is not embedded in the JXL itself because libjxl can synthesize one if necessary.

Yes, libjxl makes this convenient, because it embeds a CMS. But I guess there could be other implementations that are not using libjxl? For example: Joe sends pixel data + ICC through the lossy codec (libjxl based, so it decides to strip the ICC profile to save a few bits by the custom enums) and transmits it to Jane. She happens not be using libjxl but another implementation w/o all the CMS bells & whistles, so now she cant readily get the image in the original color space & its profile (or can't get an approximation of them w/o some extra, imposed work). The codec is not behaving as a black box.

from libjxl.

Just to clarify, it doesn’t take a whole CMS to recreate an ICC profile. The part of libjxl that takes care of this is this file:

https://github.com/libjxl/libjxl/blob/5e689eb20b9967d589035f7bffd516490670fb5f/lib/jxl/cms/jxl_cms_internal.h

Or if one is using lcms2, they can use the following functions from it instead of passing it an ICC profile:

cmsHPROFILE cmsCreateRGBProfile(const cmsCIExyY* WhitePoint,
                                const cmsCIExyYTRIPLE* Primaries,
                                cmsToneCurve* const TransferFunction[3]);

cmsToneCurve* cmsBuildGamma(cmsContext ContextID, cmsFloat64Number Gamma);

Likewise, with Apple’s libraries: https://developer.apple.com/documentation/coregraphics/cgcolorspace/1408861-init

from libjxl.