Re: [Lcms-user] Creating equivalent matrix-shaper and 3D LUT profiles, problem with BPC
An ICC-based CMM for color management
Brought to you by:
mm2
From: Pekka P. <pek...@ha...> - 2024-03-18 12:51:21
|
On Sat, 16 Mar 2024 15:35:50 +1100 Graeme Gill <gr...@ar...> wrote: > Pekka Paalanen wrote: > > Hi, > > > I have some difficulty in generating ICC profiles in Weston's test > > suite. I want the test suite to exercise all code paths to ensure the > > color operations are implemented correctly. I have separate code paths > > for matrices+curves and 3D LUTs. Which code path gets chosen depends on > > what processing blocks (cmsStage) an ICC file results in. Therefore, I > > would like to craft identically behaving ICC files that hit the > > different code paths (the goal). > > I think Marti's advice is to be taken seriously - a lot of the point of using > an ICC library like lcms is to let it do all the work with regard profile > details (and there are a lot of details that have accumulated over the years). > So using a generic extraction such as cLUT representation while > allowing you to do the pixel transformation in HW is the way to go. Hi Graeme, yes. That's why I want to take advantage of LittleCMS for everything ICC file related as much as I possibly can. The two complications I have are: - interfacing ICC profiles with television broadcast standard profiles that do not follow ICC rules, and - the desire to match the chain of mathematical operations implemented by display controller hardware (fixed-function, as opposed to programmable GPU shaders). There are people hard at work to define Linux KMS UAPI to get deterministic and well-defined color processing operations exposed from display controller hardware, btw. This explains the plan: https://lists.freedesktop.org/archives/dri-devel/2024-February/443518.html I think that is a direct consequence of Wayland color management design. I would like to believe that eventually we could even influence hardware design in the long run. > In my experience there is some advantage in terms of the quality/speed > tradeoff in being able to add optimized per channel in & out > curves to the cLUT, but it is somewhat non-trivial to implement > this in a generic way, if the ICC library itself doesn't provide > such facilities. I'll certainly read the paper Marti pointed to. > Not withstanding the above, in my ArgyllPRO color transformation > regression test (icc/lutest) code I create a bunch of ICC profiles > that all implement the same overall transform using different > ICC V2 & V4 tags, and you can grab the RGB sub-set of them from here: > <https://www.argyllpro.com.au/argyllPRO_RGB_lu_test_profiles.zip>. Interesting, thanks. So far I've preferred to create profiles programmatically during the tests, so that it's clear how they were formed. > Note the limitations of this set though: these are just RGB device profiles, > and does not include any other type of profile (i.e. device link), nor > does it include other device colorspaces such as monochrome, CMYK, CMY, N-color > etc., all spaces that can occur when transforming from source to (say) an RGB > display. They also do not all have non-linear per channel curves (in order > to make them reproduce the same device->XYZ transform), so this > isn't much of a test of these stages of the machinery. We are limiting the scope in Wayland. Currently the protocol draft requires a 3-channel Display Class profile for application content. DeviceLink is not supported directly, but an application can apply a DeviceLink itself and then tell the compositor that it already used the chosen display's profile to get the equivalent result. > > If my goal is reasonable, then what would be a good way to add the > > required BPC? Can I make LittleCMS compute it for me, or should I just > > copy the BPC algorithm from LittleCMS? > > I'd be somewhat wary of adding BPC to everything, particularly to > the perceptual or saturation intents. I have understood that LittleCMS has already made that decision for me, for the v4 perceptual rendering intent: https://github.com/mm2/Little-CMS/blob/46355888b823b563db928faec59b0312a05e1143/src/cmscnvrt.c#L1129-L1133 > Adobe's BPC white paper > notes that BPC should be optional for these intents, and there are > good reasons for this. In the Wayland protocol, we indeed have "media-relative rendering intent with BPC" as an explicitly separate option. > The underlying desire for BPC is due to a > fundamental architectural problem with the ICC idea of mixing and > matching source and destination device profiles while also supporting > gamut mapping. In general it can't work properly due to the need to > simultaneously know both source and destination gamuts to create such > a mapping. When I started learning about ICC color management, that was one of the fundamental questions I had: How do you know the two gamuts in order to the able to map between them. It is relieving to hear that not finding a clear answer to that is not my personal failure in understanding. Curiously, HDR static metadata carries something called Mastering Display Color Volume, which essentially is that color gamut, separately from the colorimetry encoding. In Wayland we would have the opportunity to extend it to SDR material too. > There are three attempts at working around this problem > that I'm aware of: > > 1) ICC PRMG. This can partially work, but is also limited by > attempting to implement gamut mapping in isolation in each > device profile. > > 2) Adobe BPC. This is true gamut mapping, but applied just to > the black point. Their algorithm is a heuristic, and doesn't > always identify the correct black points to map from & to, > sometimes causing worse black levels, rather than better. > > 3) ArgyllCMS gamut mapping. > This has the advantage of allowing true gamut mapping, even with > popular matrix source spaces, but has the disadvantage of the > resulting perceptual or saturation table only being correct for a > specific source profile. > See <http://www.argyllcms.com/doc/iccgamutmapping.html> for more details. I always remember that page by the diagram at the end. :-) Thanks, pq |