HDR, color management, krita, luts and other apps

[Kai-Uwe Behrmann]

Am 07.06.12, 09:50 +0200 schrieb Boudewijn Rempt:
> On Wednesday 06 June 2012 Jun, Sven Langkamp wrote:
>> I guess someone would get shot for the first sentence in Simon's place ;)
>> Would be a bit strange if an application that costs a few thousand euro
>> couldn't do that.
>
> Er, no -- I think that Nuke users are supposed to assume that their monitors are all sRGB without serious deviations. That's a workflow that Krita will support, of course, by setting the monitor profile to sRGB.

This means disabling display colour correction, which is IMO not so 
straight forward.

>> I think you need to do more than just the lut docker. The image would have
>> an ocio colorspace and we can't convert between icc based and ocic easily.
>>
>> To make that easier we might limit the layer colospace to the image
>> colospace to avoid conversion on lower levels too.
>
> I'm assuming that any layer-internal colorspace conversions aren't 
> relevant here. Down to the projection composition it's all lcms2. From 
> there, I want the lut docker to enable some optional extra steps that 
> replace the usual projection-to-monitor tranform:
>
> * associate the projection with an ocio lut. I don't want to convert the
>   projection using ocio, I want to disregard the existing colorspace.
>   This will only work for float32 rgba color models, of course -- ocio
>   supports nothing else in any case.
>
> * implement the functionality of the mari toolbar in the lut docker
>
> * implement the transforms from the image projection to 8 bit sRGB using ocio
>
> * (optionally) use lcms2 to convert sRGB to the monitor profile (if different from from sRGB).

Huch. This rolls a stone from my heart :-)
If people want compatibility with movie software they can simply a
probably expensive monitor with sRGB emulation or use CompICC or future 
KWin with ICC support.

>> Just if Krita is running in ocio mode, lcms would still need a shader or so.
>
> There's existing code (in oyranos) that allows us to create a lookup texture from an icc profile, so the last transform (sRGB->monitor) can also be done in a shader.

A colour conversion chain like the following would be rather easy:

source colour space ->
   gamma + exposure ->
     ocio proofing colour space ->
       monitor colour space

Then put the above colour transform inside a 3Dtexture and
attach to the OpenGL image texture through a shader. So the complete 
conversion will run on the GPU. The shader can take additional arguments 
to support gamma and exposore.

>> I think if you go with lcms->ocio->lcms, that defeats the whole purpose of
>> using ocio in the first place. I think we could just assume that somebody
>> who uses ocio will use opengl canvas.
>
> Well, not, not quite, the purpose of ocio is to allow the familiar 
> transforms (lut changes, gamma, exposure, channel selections). That can 
> work in the qpainter canvas just as well.
>
> In fact, I intend to implement it in the qpainter canvas first, since 
> the opengl canvas is in a bit of a flux at the moment.

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