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

[Pekka P. <pek...@ha...>]

On Fri, 15 Mar 2024 15:16:13 +0100
<mar...@li...> wrote:

> Hi Paalanen,
> 
> Nice to contact you. Regarding your question, matrix shaper is only a very
> limited subset, true ICC profiles uses CLUT. Also, matrix shaper does not
> allow gamut mapping so it is better to avoid matrix-shaper whatever
> possible.
> 
> I think there is a much better solution than replicating all lcms internals.
> You have to implement thetrahedral interpolation on GPU. It is not a big
> deal, in CUDA and OpenCL is trivial. You can use the lcms code as basis.
> 
> Then, when you want to do color management, just create a color transform
> and sample all RGB to RGB gamut in a CLUT of 33 points. You could use more
> points if wish so, but 33 is enough in most cases. Ignore the profiles
> internals, it is nothing of your business:
> 
>  cmsOpenProfileFromFile input
> cmsOpenProfileFromFile  output
> 
> cmsCreateTransform input to output in floating point float
> 
> for (r=0; r<255; r += 256/33)
> 	for (g=0; g<255; g += 256/33)
> 		for (b=0; b<255; b += 256/33)
> 		{
> 			cmsDoTransform rgb ->  rgb_out
> 			store in GPU CLUT
> 		}
> 
> Close everything
> 
> Then, when you want to transform an image, just use this CLUT and
> tethahedral interpolation to do the color matching. It is fast because it
> happens in the GPU. It is simple because you have not to worry about the
> internal representation of the profiles. It is scalable because you can add
> more points to increase precision and it is portable. And all color
> management features are working.

Hi Marti,

I wish I could share your optimism.

Do you know if that is also enough when one side is BT.2020/PQ encoded
HDR and the other side can be anything, including an optical encoding?

If you have any paper to point to that suggests a 3D LUT is all you
need, I would be exhilarated, and I would tell the Linux display driver
engineers to forward that to their hardware engineers, so we wouldn't
have do things the hard way in the future.

I know, ICC profiles cannot represent HDR spaces in a good way, unless
maybe with the most recent addition of CICP tags. However, I don't need
to represent such things as valid ICC conformant profiles, they will
never escape Weston's processes. I'm planning to abuse the
cmsHPROFILE/cmsPipeline machinery that LittleCMS already has in an
extendable form instead of inventing my own, and craft such
cmsHPROFILEs that a chain of them results in the pipeline I need. The
reason I originally went this way is because I need to be able to
handle source/destination profile combinations where one of them is a
valid ICC profile file, and the other is a DTV video format description
like HDR10 with HDR static metadata. Of course, I need to support a
pure ICC workflow too.

We want to make an explicit trip through an optically encoded
intermediate space for blending, so transformations between two
electrical encodings will be rare. We are also likely to get
application content in optical encoding, optical scRGB sounds to be
popular in (Windows) HDR games.

My experience with LUTs is that even something as simple as the inverse
of power 2.2 curve will need a ridiculous number of uniformly
distributed LUT elements to reach any kind of usable precision. For 8
bit-per-channel electrical encoding precision, with 4096 elements in
optical domain the maximum error is still bigger than +/- 1 code point.
I believe the perceptual quantizer curve is even more extreme. We will
be adding the missing curve types as LittleCMS plugins, like the PQ and
HLG curves, since they would be far too expensive as LUTs.

Luckily though, I can choose the compositor blending space such that
that kind of curves will appear alone and not need channel mixing at
that stage. But a 1D LUT is probably not good enough even then, which
is why display controller hardware designers are inventing things like
fixed-function curves and non-uniformly distributed 1D LUTs.

I suspect that if a 3D LUT could do everything with reasonable
precision / storage trade-off, the display controller hardware
designers would simply put a 3D LUT on the card instead of all the
various matrix, fixed curve, and LUT elements they are having now, in
addition to some 3D LUT elements. By this I mean composition
off-loading to display controllers, a.k.a Linux DRM with multiple KMS
planes that the hardware blends together live during a scanout cycle.

My ultimate goal as a Weston compositor developer is to aim at
off-loading all color processing to the display controller, and using a
GPU only as a fallback. That means I need to match the fixed-function
hardware capabilities as closely as possible, and they seem to be
having a series of elements. See for example the "DCN 3.0 family color
caps and mapping" diagram just above
https://dri.freedesktop.org/docs/drm/gpu/amdgpu/display/display-manager.html#blend-mode-properties .

Hence, the idea of just collapsing everything into a single giant 3D
LUT does not seem to fit, as easy as it would make my life.

> Don't mess with DToBxx neither with matrix shaper, otherwise you would end
> replicating all lcms functionality. Don't try to oversimplify by using
> matrix-shaper, those are not good for gamut mapping and have no intents.
> Color management does not work by using matrix shaper.

So, to get back to the point.

I'm starting from a matrix-shaper profile in the tests, because a
matrix-shaper profile carries all the stage types Weston currently
recognises and optimises. This is the way I can easily test the 3x1D
LUT - matrix - 3x1D LUT path, and the optimiser. I have understood that
matrix-shaper profiles are common as SDR display profiles when you
don't bother profiling the display. Also television broadcast standards
use essentially matrix-shaper types.

All I'm doing here is to check that the mathematics is coded correctly.

When Weston fails to recognise a cmsStage or fails to map the optimised
pipeline to its internal fixed-function pipeline (which mimics what DRM
KMS exposes, so that we can more easily off-load the pipeline to KMS in
the future), it falls back to a 3D LUT. I need an ICC profile file that
contains such stages that force Weston to fall back. A literal 3D LUT
stage is the best option, because I want to test Weston's 3D LUT path.

When I use a 3D LUT in an ICC file, I suddenly also need to adhere to
the perceptual PCS definition of the black point as well. The fact that
matrix-shaper profiles do not behave the same is the headache here.

I did get it to work, by copying 10-20 lines of code from
ComputeBlackPointCompensation() depending on if you count the comments.
I was hoping to not need to do that and just tell LittleCMS to add BPC
compensation in the transformation.

I haven't tried to replace my matrix-shaper test profiles with a DToB
profile using a matrix and a curveset, but then I would need to adhere
to the perceptual PCS black point already there. I think it would just
move my problem from one place to another instead of solving it.


Thanks,
pq

> 
> Hope that helps
> 
> Marti Maria
> The LittleCMS Project
> https://www.littlecms.com
> 
> 
> 
> uetiwonder why are you takin such huge amount 
> 
> > -----Original Message-----
> > From: Pekka Paalanen <pek...@ha...>
> > Sent: Friday, March 15, 2024 11:23 AM
> > To: lcm...@li...
> > Subject: [Lcms-user] Creating equivalent matrix-shaper and 3D LUT  
> profiles,
> > problem with BPC
> > 
> > Hi,
> > 
> > I'm working on a Wayland compositor (Weston) to integrate LittleCMS in it.  
> I
> > use LittleCMS to come up with the color transformation from ICC profiles,
> > then extract and optimize the cmsPipeline, and implement it in OpenGL ES  
> 3.0
> > shaders.
> > 
> > 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).
> > 
> > Crafting matrix-shaper profiles is easy. Crafting an equivalent profile  
> that
> > internally has a 3D LUT (DToB/BToD) is the problem. I can craft such an  
> ICC
> > profile, but because I need to test with the perceptual rendering intent,  
> I
> > should also include BPC between the zeros black point of a matrix-shaper  
> and
> > the non-zero black point of the v4 perceptual PCS. Otherwise the  
> assumption
> > that a perceptual v4 CLUT profile has the ICCv4 defined perceptual black  
> point
> > does not hold, and the tests fail.
> > 
> > Is my goal reasonable to begin with, or should I just accept that  
> exercising the
> > different Weston GL ES code paths by means of different ICC profiles  
> cannot
> > lead to identical results and I need to define my expected test results
> > separately for each case?
> > 
> > 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've tried creating the DToB/BToD test profile 3D LUT by creating a chain  
> of the
> > usual matrix-shaper profile and the abstract XYZ profile and sampling  
> that, but
> > now I'm convinced that I cannot get BPC applied that way, not with the XYZ
> > profile at least.
> > 
> > 
> > Thanks,
> > pq  
>