[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: HDR, color management, krita, luts and other apps
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2012-06-07 7:50:17
Message-ID: 201206070950.17729.boud () valdyas ! org
[Download RAW message or body]

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.	

<...>

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

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


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


-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop


[prev in list] [next in list] [prev in thread] [next in thread]