[Openicc] review of new wide gamut editing space

[Chris Murphy]

On Mar 21, 2012, at 4:58 PM, Graeme Gill wrote:

> Chris Murphy wrote:
>> If we go to 32bpc float as a minimum across the board, neither primaries nor TRC matter at all.
>> Finally, peace.
> 
> It's still important to distinguish between editing and final delivery both in terms
> of number representation and gamut. A 4 x increase in storage space and bandwidth
> is still not trivial, even though some people would like to imagine that it can
> be ignored.

Definitely not ignored. But looked forward to. A fairly large percentage of the purpose of 32bpc float isn't for storing the data, but for compositing.


> When rendered to a typical output gamut, 8 bits is still very satisfactory
> for everyday use, particularly if the imagery has natural noise in it, while 16 bit is
> total overkill.

I'm completely with you on the practical matter of delivering images. I'm not suggesting 32bpc float for the entire intertoobz anytime soon. But as a separate, also practical matter, compositing space it makes a lot of sense and is something that Microsoft and Adobe arrived at for their imaging pipelines some time ago.

> Even in editing, 16 bits exceeds the Signal to Noise ratio of any real sensor.

Yes, yes. But it's not just about sensors, is it? It's about taking 3-4 shots, compositing them together into an HDR photo, doing that times 9 to make a seamlessly stitched panorama. For one print. And that's yesterday's requirement. So what's next?



> And then there is the gamut problem. With constrained values and real device profiles
> you have a defined gamut. With unconstrained values and/or imaginary colorspaces you don't,
> and you have to adopt a workflow that recognises that you can't assume source gamuts based
> on the colorspace. Few people or systems do so.

Absolutely. The realm of HDR rendering is even more about "what looks good" and is an active area of research that's possibly of greater interest than the seemingly simpler task of output referred ProPhoto to an inkjet printer - which we still don't have exactly right.


Chris Murphy