Re: [Lcms-user] Creating equivalent matrix-shaper and 3D LUT profiles, problem with BPC

[Graeme G. <gr...@ar...>]

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.

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.

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>.

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.

> 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. Adobe's BPC white paper
notes that BPC should be optional for these intents, and there are
good reasons for this. 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. 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.

Cheers,
	Graeme Gill.