ICC profile with CICP tag about little-cms HOT 14 OPEN

I am adding you suggestion to the wish list. Could I close this as it is not a bug?

from little-cms.

This tag is purely informative. Is a flag for capable software to discard the profile and use its own HDR color management. The profile is a simplification for ICC workflows like lcms2.

from little-cms.

The question is what to do when the tag doesn't match the profile. In this case the tag describes the actual color space while the profile implements some kind of destructive hard-clipping tone mapping that you don't want to apply when you're processing an image...

from little-cms.

If the profile is wrong, there is nothing lcms can do.
Right now, providing a different color manager that switches and replaces the ICC one when a certain tag is found is out of the scope of this library.

from little-cms.

Technically, if the profile is wrong, lcms can do anything and still be a conforming implementation of the ICC spec :)

The ICC spec doesn't say what should take precedence in case of conflict between the CICP transfer function and the curves in the profile (it should says there shall not be such a conflict). Applications like Chrome let CICP take precedence, lcms2 lets the profile curves take precedence. Both are technically OK since they're dealing with a technically wrong profile, but if these profiles occur in the wild (Adobe software does produce them), it's a bit less than ideal that we're getting diverging behavior. The whole point of color management is to ensure consistency, after all.

from little-cms.

It is not a matter of precedence, the CICP tag is saying "discard all this profile and use other standards instead". Current implementation of lcms does not do this. It would require to write a new CMM for HDR.

from little-cms.

The CICP tag basically just describes primaries and a transfer function, which is something lcms can already handle just fine, no?

from little-cms.

Unfortunately it is not so easy. There is a database of primaries and functions, the chromatic adaptation, gamut mapping, intents, highlight handling for floating point and testbeds. Could easily take 4-5 months of development. Without a clear business case, this is a no way.

from little-cms.

A better question might be, "How do I use little CMS to do this thing I need to do?" There may be a sequence of API calls for you to use to do the replacement.

from little-cms.

The only things that are used in practice right now, as far as I can tell, are three sets of primaries (sRGB, P3 and Rec2020) and three transfer curves (sRGB, PQ and HLG).

I am not talking about dealing with tone mapping or any other tricky stuff. All I'm trying to do is convert to linear RGB and back, using the proper transfer curve (the one signaled in CICP) and not the clipping one that is given in the ICC profile curves. I guess I could manually parse the CICP tag (like what libjxl does, for example) and then construct a corresponding lcms profile from it using the primaries and transfer function, but I was hoping there's already an lcms function or option to do just that.

from little-cms.

The cICP tag is pretty simple, a set of four uint8 values that provide for enumerations of various primary and trc definitions specified in ITU-T Rec H.273 (ref: ICC.1-2022-05). So, why would you only want to replace the LittleCMS TRCs, why not also the primaries?

BTW, found a decent discussion on this at the ColorWeb-CG repo: w3c/ColorWeb-CG#18

from little-cms.

In the example I have, the primaries in the main part of the profile are identical to the ones signaled in the CICP tag of the profile, but yes, it would make sense to take both the primaries and the transfer curves from the CICP tag.

To be clear: I am not talking about the cICP chunk in PNG files (which is quite similar but not the same thing), I am talking about the cicp tag in ICC v4.4 profiles.

In the PNG spec, it's clear what takes precedence: if there is a cICP chunk, it takes precedence over the ICC profile (https://www.w3.org/TR/png-3/#cICP-chunk).

In the ICC spec though, no precedence rules are specified (and conforming profiles should not contain conflicting tags). Currently, lcms just ignores the information given in the CICP tag, I think, or at least in case of conflict, does not give it precedence.

from little-cms.

Currently, lcms just ignores the information given in the CICP tag, I think, or at least in case of conflict, does not give it precedence.

In 2.16 you can use cmsReadTag to get a cmsVideoSignalType structure. Then is up to you to use cmsCreateRGBProfile or use the original profile. Using a simple matrix-shaper is in general a bad idea if you want intents, gamut mapping and precision. And cmsCreateRGBProfile only gives you a matrix-shaper. A good profile may have BToDxx tags that operates on highlights much better than a simple matrix shaper. But at that level, the CMM has no way to know if the profile is good or not, so reverting to a matrix shaper would at least risky.

from little-cms.

It would be convenient to have something like cmsCreateRGBProfileFromVideoSignalType.

I guess there are two ways in which the profiles embedded in HDR images are used: one is describing how to render the image nicely on an SDR display, the other is describing the actual colorspace of the image data (e.g. Rec.2100 PQ). It depends on the application which of these two things is relevant.

from little-cms.