Hi guys. Ouch, 3 days on set and I come back to a BIG thread. :) It's exciting to see the developments taking shape!<br>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. <br>
However if you all view this as a needed opportunity to do more work on Krita's colour management then great! :)<br><br>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.<br>
<br>I'll report back if any of them come up with useful information.<br><br><div class="gmail_quote">On Thu, Jun 7, 2012 at 9:13 AM, Kai-Uwe Behrmann <span dir="ltr"><<a href="mailto:ku.b@gmx.de" target="_blank">ku.b@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 07.06.12, 09:50 +0200 schrieb Boudewijn Rempt:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wednesday 06 June 2012 Jun, Sven Langkamp wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess someone would get shot for the first sentence in Simon's place ;)<br>
Would be a bit strange if an application that costs a few thousand euro<br>
couldn't do that.<br></blockquote></blockquote></div></blockquote><div><br>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.<br>
 </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote>
<br>
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.<br>
</blockquote>
<br></div>
This means disabling display colour correction, which is IMO not so straight forward.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think you need to do more than just the lut docker. The image would have<br>
an ocio colorspace and we can't convert between icc based and ocic easily.<br>
<br>
To make that easier we might limit the layer colospace to the image<br>
colospace to avoid conversion on lower levels too.<br>
</blockquote>
<br>
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:<br>

<br>
* associate the projection with an ocio lut. I don't want to convert the<br>
  projection using ocio, I want to disregard the existing colorspace.<br>
  This will only work for float32 rgba color models, of course -- ocio<br>
  supports nothing else in any case.<br>
<br>
* implement the functionality of the mari toolbar in the lut docker<br>
<br>
* implement the transforms from the image projection to 8 bit sRGB using ocio<br>
<br>
* (optionally) use lcms2 to convert sRGB to the monitor profile (if different from from sRGB).<br>
</blockquote>
<br></div>
Huch. This rolls a stone from my heart :-)<br>
If people want compatibility with movie software they can simply a<br>
probably expensive monitor with sRGB emulation or use CompICC or future KWin with ICC support.</blockquote><div><br>Yes and we do use those. <br><a href="http://h10010.www1.hp.com/wwpc/us/en/sm/WF05a/382087-382087-64283-72270-3884471-3648397.html?dnr=1">http://h10010.www1.hp.com/wwpc/us/en/sm/WF05a/382087-382087-64283-72270-3884471-3648397.html?dnr=1</a><br>
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.<br>
 </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just if Krita is running in ocio mode, lcms would still need a shader or so.<br>
</blockquote>
<br>
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.<br>
</blockquote>
<br></div>
A colour conversion chain like the following would be rather easy:<br>
<br>
source colour space -><br>
  gamma + exposure -><br>
    ocio proofing colour space -><br>
      monitor colour space<br>
<br>
Then put the above colour transform inside a 3Dtexture and<br>
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.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think if you go with lcms->ocio->lcms, that defeats the whole purpose of<br>
using ocio in the first place. I think we could just assume that somebody<br>
who uses ocio will use opengl canvas.<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
</blockquote>
<br></div>
kind regards<span class="HOEnZb"><font color="#888888"><br>
Kai-Uwe Behrmann<br>
-- <br>
developing for colour management <a href="http://www.behrmann.name" target="_blank">www.behrmann.name</a> + <a href="http://www.oyranos.org" target="_blank">www.oyranos.org</a></font></span><div class="HOEnZb"><div class="h5">
<br>
______________________________<u></u>_________________<br>
kimageshop mailing list<br>
<a href="mailto:kimageshop@kde.org" target="_blank">kimageshop@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kimageshop" target="_blank">https://mail.kde.org/mailman/<u></u>listinfo/kimageshop</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Simon Legrand<br><a href="http://slegrand.blogspot.com/">http://slegrand.blogspot.com/</a><br>