[Openicc] MS on HDR CMS :)

[Chris Murphy]

On Feb 11, 2008, at 1:43 PM, Kai-Uwe Behrmann wrote:

> Am 11.02.08, 10:02 -0500 schrieb Chris Murphy:
>> On Feb 11, 2008, at 2:23 AM, Kai-Uwe Behrmann wrote:
>>> Am 10.02.08, 22:52 -0500 schrieb Chris Murphy:
>>>> Nevertheless the ICC needs to deal with HDR. And Europe needs to  
>>>> get
>>>
>>> What else would you like to see supported?
>>
>> CAM. This one size fits all thing doesn't work when it comes to HDR,
>> and although ICC v4 and PRMG helps, it's still one size fits all.
>> It's not scene specific.
>
> So DToBxTags and BToDxTags would not deal with that eigther, as  
> they seem
> to propose precission benefits only.

No because tags are precomputed. I'm suggesting something smarter  
than that.

> While it is simply possible to define viewing range limits for HDR
> imagery, it is not so clear at the moment how to handle  
> tonemapping. The
> later is almost known as dynamic, read as non parametric. We did  
> not yet
> see many algorythms settled to fit into a static system like te ICC
> descriptions.

I recognize this is an ICC criticism, a long standing one of mine. I  
don't like prebaked profiles. They fit a certain need, but we're  
rapidly growing beyond that. I want to see CAM brought in to solve  
some of these problems on a dynamic basis. In an ICC context, this  
means in a CMM.

>
>>>> over this recent obsession with L* image encoding, which I think is
>>>> weird. With respect to encoding the article makes a good point. For
>>>
>>> What is wired in respect to the L* encoding for LDR images?
>>
>> Print doesn't have an L* based tone reproduction curve. For near two
>> decades it's been known that it's closer to gamma 1.8 defined.
>
> My guess L* stands for media neutrality without rejecting the idea  
> of a
> having some device gamut. A full CIE*Lab encoding as is would  
> provide no
> hint about a device gamut.
> You emphasise printing only. But I'd think we see consuming of much  
> more
> media in form of movie, TV and so on or at least thise media are  
> growing
> compared to print. Print is no longer the only graphic output media.

I am simply talking about tone reproduction curve. L* is a silly  
thing to be pushing. It is not helpful.


>
>> The ECI explicitly recommends users with 8bpc ECI-RGBv1.0 (TRC=gamma
>> 2.2) images *NOT* convert them to ECI-RGBv2.0 (TRC=L*) because of
>> loss of quality, i.e. the lost of bits. ECI is really recommend it in
>> a 16bpc workflow, *and* primary for the print and publishing
>> industry*,in which case we shouldn't even be having an encoding
>> debate! They aren't 16bpc workflows in print and publishing, and L*
>> is not an appropriate TRC for them either.
>
> ECI-RGBv2.0 is recommended for conversions from 16-bit to 8-bit.

ECI-RGBv2 should be recommended for anything is my point. It's just  
ridiculous. v1.0 is perfectly fine for 8bpc workflow. For 16bpc  
workflow the TRC is not relevant for practical purposes.

>
>> So quite frankly I wish ECI-RGBv2.0 would die a fast painless death.
>> I am still a big fan of ECI-RGBv1.0 and actually prefer it over Adobe
>> RGB (1998) for 8bpc print workflows, and I continue to recommend it
>> for that. But L*? 12% loss of bits in the conversion through 8bpc.
>> Why would I do this?
>
> It is not recommended to convert from a editing colour space with 8- 
> bit
> encoding to ECI nor Adobe or ProPhoto just for archiving. For 16-bit
> sources it is not a problem.
> 8-bit is a pure end consumer format. It shows artifacts on  
> virtually every
> manipulation, and should therefore be almost avoided for production  
> stages.

ProPhoto RGB/ROMM RGB has 8bpc, 12bpc, and 16bpc versions and that's  
why Kodak decided on gamma 1.8 encoding. If it were just 16bpc and  
32bpc no doubt it would be linear encoded.

Anyway, point is the L* thing is silly and I wish it would just go  
away. I do not like ECI-RGB v2.0, I think it's confusing and  
unhelpful to the market.

Chris