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

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

Hi Graeme,

> In my view the elephant in the room with regard to HDR standards is the
lack of explicitly dealing with the diffuse white.

Agreed, but this is not the only issue. There is also the encoding and the
containers for numbers. In V4 you have DtoBxx/BtoDxx tags that could hold
floating point range and therefore store extended ranges, but if you want to
stay in 16 bits representation, then you have a limited precision. 
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. 
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.
 
> This also means that SDR mappings are not hard coded into the profiles,
and can be set by the user to suite their viewing situation and/or the
source material.
Exactly.

> A slightly more sophisticated measure than simple L* that I've used for
printer linearization is equalizing distance in delta E space, but probably
not something to pursue in initial development
Nice idea. Maybe then using a minimization algorithm like damped
least-squares to find best curve points in regard of dE would work, I wonder
how weird the obtained curves would be in this case.

I think ICC would say that the solution for HDR is to use ICCMax, but I'm
afraid only Onyx is currently supporting those profile.

Cheers
Marti