On Friday 15 June 2012 Jun, Jeremy Selan wrote:

Boudewijn,

Kudos on the quick integration again! Can I see the code? Is there a
repo you can point us to?

Sure: https://projects.kde.org/projects/calligra/repository/show?rev=krita-lut_docker-rempt . Big fat warning: first cut implemenation, it's cool and seems to work, but lots of cleaning up to do. The main code is in krita/plugins/extensions/dockers/lut, with some forays into krita/ui/opengl and krita/ui/canvas.

There are no binaries yet -- build instructions are at http://community.kde.org/Calligra/Building/Building_Calligra,
the website at http://www.krita.org

Looking further at your example screenshot, I notice that you have
gamma set to 2.2, and exposure to 2.4. Were these particular values
just playing around with the UI, or are they the defaults? I would
expect the sliders for gamma to default to 1.0, and exposure to 0.0.
(Presuming you're linking up exposure with pow(2,exp), as ociodisplay
does).

The exposure, yes, that was playing around, the default is 0.0, the gamma is 2.2 by default. I suspect I misunderstood the gamma slider, and compared to the ociodisplay app, it's definitely wrong. One of the bugs I need to fix... Another bug is that if I go negative with exposure, pixels get transparent. I suspect a problem in our openexr loading code.

The DisplayTransform gamma and exposure sliders are there to allow the
artist to preview / inspect the fidelity of there work, particularly
in the dark and bright regions. They are NOT there to account for the
display gamma. (This is traditionally done inside the OCIO profile,
and is not visible externally to the user). Does this make sense?

Yes, indeed. I missed that. The problem here is that I have actually never seen another app that uses ocio in action, except in some videos :-). I'm hoping for good input from some test users soon.

Also note that painting is rarely done directly in scene-linear
colorspace (HDR), so it's probably not the best default for input
color space. (Maybe some day it will, but not quite yet).

Yeah... We've had support for openexr and f16/f32 colorspaces (rgb, cmyk, ycbcr, xyz, gray) for ages, since like 2005 (http://www.valdyas.org/fading/index.cgi/hacking/krita/opengl.html is the first screenshot I can find), but we haven't had any real users for it yet. That will come now, and that will help me refine the painting workflow. There is also this blog about color selecting when the image is in f16/f32: http://blog.cberger.net/2007/12/01/painting-in-hdr-with-krita/. But I broke that and will need to fix it :-)

Krita really cares primarily about creative painting, in this respect it's matte and texture painting. I know we've got a way to go yet :-).

I would recommend querying
ColorSpace cs = config->getColorSpace(OCIO::ROLE_TEXTURE_PAINT)
if(cs) cs->getName()

This is how mari find the default color space. You could also query
MATTE_PAINT if you think that's more likely for artists in krita to
use.

Thanks for the hints! I might make that an option -- it's, after all, what we usually do in krita.

If you test with a profile that uses a film emulation lut (such as
spi-vfx), by switching between "Film" and "Raw" you'll be able to see
the 3D color warp that would be anticipated in a theatrical context.

I'll test that as well.

--
Boudewijn Rempt