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

[<mar...@li...>]

Hello,

Well, no solution fits everything, of course, but I found the CLUT plus
linearization curves to work fine in many scenarios. I think the issue here
is HDR is not well supported by ICC workflows, highlights and values above
L* 100 of D50 are seldom discussed in the 4.4 ICC spec. For BT.2020/PQ,
which profile I'm attaching this is quite evident. Lcms can deal with it on
unbounded mode, but if you feed a RGB -> Lab transform, for
RGB=(255,255,255) you will find L*=523!! This is not encodable in any CLUT
unless you provide enough headroom. 

I did this paper many, many time ago regarding how to increase accuracy of
CLUT. Hope that would be of any help.
https://www.littlecms.com/ASICprelinerization_CGIV08.pdf

Regards
Marti Maria
The LittleCMS Project
https://www.littlecms.com
  
> > -----Original Message-----
> > From: Pekka Paalanen <pek...@ha...>
> > Sent: Friday, March 15, 2024 5:06 PM
> > To: mar...@li...
> > Cc: lcm...@li...
> > Subject: Re: [Lcms-user] Creating equivalent matrix-shaper and 3D LUT
> > profiles, problem with BPC
>>
> > 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
> > >