[Openicc] MS on HDR CMS :)

[Kai-Uwe Behrmann]

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.

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.

> >> 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.

> 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.

> 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.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org