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

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

>It seems to me that BPC makes black worse almost as often as it makes it
better though!
Haha, blame Adobe for that, I just followed their recipe.

> Case in point with lcms BPC:
Nice matching, don't they?

I guess both profiles you used are V2. The BPC is used automatically by lcms
when you mix V2 and V4

Tried with built-in sRGB, which is V4:

marti@PORTATIL:~$ transicc -i\*srgb -o bpctest.icm -t0
LittleCMS ColorSpace conversion calculator - 4.3 [LittleCMS 2.09]

Enter values, 'q' to quit
R? 0
G? 0
B? 0

R=19.3152 G=11.3658 B=24.4436

Regards
Marti

-----Original Message-----
From: Graeme Gill <gr...@ar...> 
Sent: Wednesday, March 20, 2024 3:20 AM
Cc: lcm...@li...
Subject: Re: [Lcms-user] Creating equivalent matrix-shaper and 3D LUT
profiles, problem with BPC

mar...@li... wrote:

Hello Marti,

> Sure, 16 bits is a plenty of room, but if you use 16 bits to encode L* 
> and a big part of the domain are highlights over 100, then you could 
> end 0..100 to be encoded using 9 bits and this is still not enough for a
decent accuracy.

An available HDR display is lucky to hit 2000 cd/m^2. If you pick a diffuse
white of (say) 200 cd/^m, and the max is encoded as L* = 100, then the
diffuse white ends up at L* = 37.8. With 16 bits that leaves 24773
perceptually encoded levels SDR range or 14.6 bits. That's a resolution of
0.004 dE, more than enough.

Worst case XYZ PCS is not so favourable of course - a 10000 cd/m^2 display
running at a diffuse white point of 100 cd/m^s would only have a little over
9 bits of linear encoding available. This would have visible banding in
black. So yes, either a ICC V2 16 bit L*a*b* PCS or ICC V4 MPE XYZ PCS
floating point to encode source standards.

> Another issue is what to do with those highlights. A tag with HDR 
> diffuse white would help to do a coarse clipping, but if you want some 
> gamut mapping to bring highlights into SDR gamut, you have to redo
everything.

I really don't imagine doing this in the profile itself. Too inflexible.
Better off doing this in the linking or execution of the source to
destination transform using non-ICC machinery.

> Then, since I could not discard such big number of profiles, I tried 
> to imagine a way to automatically do the rescaling from different PCS. 
> And found BPC to work fine for that. So, the idea behind this change 
> is to increase inter-operability and fix broken profiles.

It seems to me that BPC makes black worse almost as often as it makes it
better though!

Case in point with lcms BPC:

Using this RGB printer profile: <https://www.argyllcms.com/bpctest.icm>

transicc.exe -t1 -isRGB.icm -obpctest.icm Enter values, 'q' to quit R? 0 0 0
R=25.8949 G=5.3969 B=0.0000

icclu -ff -ir -s255 bpctest.icm
25.894900 5.396900 0.000000 [RGB] -> Lut_A2B1 -> 5.693560 0.252739 -3.343661
[Lab]

transicc.exe -b -t1 -isRGB.icm -obpctest.icm Enter values, 'q' to quit R? 0
0 0
R=41.5914 G=9.5681 B=0.0000

icclu -ff -ir -s255 bpctest.icm
41.591400 9.568100 0.000000 [RGB] -> Lut_A2B1 -> 8.089132 -0.308324
-2.011786 [Lab]


At least the lcms BPC doesn't seem to wreck the perceptual black on this
one:
(unlike Adobe's always on BPC in Lightroom)

transicc.exe -b -t0 -isRGB.icm -obpctest.icm Enter values, 'q' to quit R? 0
0 0
R=19.3152 G=11.3658 B=24.4436

icclu -ff -ir -s255 bpctest.icm
19.315200 11.365800 24.443600 [RGB] -> Lut_A2B1 -> 4.296325 -0.431107
-5.422716 [Lab]

Cheers,
	Graeme.	


_______________________________________________
Lcms-user mailing list
Lcm...@li...
https://lists.sourceforge.net/lists/listinfo/lcms-user