HDR, color management, krita, luts and other apps

[Simon Legrand]

Hi guys. Ouch, 3 days on set and I come back to a BIG thread. :) It's
exciting to see the developments taking shape!
I hope I didn't kick open a can of worms by bringing up the colour space
sliders. Right now, Krita seems to be doing its job just fine, I was just
thinking of exposing the slider from the preference menu to a dockable
tool.
However if you all view this as a needed opportunity to do more work on
Krita's colour management then great! :)

I have forwarded Boudewijn's initial email to all the relevant people in DD
London (Comp, Texture, Matte painters, ect...) I've asked them to read
through it and let me know if they spotted anything or wanted to expand on
any point.

I'll report back if any of them come up with useful information.

On Thu, Jun 7, 2012 at 9:13 AM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:

> 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.
>>>
>>
Haha. No, actually it's true that Nuke keeps its own colour pipe very
simple, because Nuke itself is usually used to basically 'create'
colourspaces and LUTs that work for different mediums. If we had an
automatic monitor colour correction on top of that it may make things very
complex for us. It's kept simple on purpose. :) And we all use calibrated
Dreamcolor screens anyway.


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


Yes and we do use those.
http://h10010.www1.hp.com/wwpc/us/en/sm/WF05a/382087-382087-64283-72270-3884471-3648397.html?dnr=1
We never use non calibrated screens to review anything, which is why there
was never a real need for Nuke to automatically adapt itself. However Krita
has a broader user base and it most definitely would have to keep doing
what it's doing now and not go the Nuke way. But I think everyone seems to
agree on this.


>
>
>  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
>
> ______________________________**_________________
> kimageshop mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/**listinfo/kimageshop<https://mail.kde.org/mailman/listinfo/kimageshop>
>



-- 
Simon Legrand
http://slegrand.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20120607/b0b5b624/attachment.html>