Hi!

So... Basically Krita now supports OpenColoriO :-). I've used the display example as suggested and implemented both the CPU and the GPU path. Everything seems to be working fine, and fast. See http://www.valdyas.org/~boud/krita_opencolor_io.jpg. I'm not sure whether this feature will be in the 2.5 release since we're branching for the release today, and I'm hesistant to merge a huge branch without much review.

Thanks for the help.

Oh my goodness!
That was fast!
We'll pick up this branch and put it through its paces. Then once we've bashed it around enough it may be safer to decide to merge into the trunk. What do you think?

--
Simon Legrand
http://slegrand.blogspot.com/

On Friday 15 June 2012 Jun, Boudewijn Rempt wrote:

Hi!

So... Basically Krita now supports OpenColoriO :-). I've used the display
example as suggested and implemented both the CPU and the GPU path.
Everything seems to be working fine, and fast. See
http://www.valdyas.org/~boud/krita_opencolor_io.jpg. I'm not sure whether
this feature will be in the 2.5 release since we're branching for the
release today, and I'm hesistant to merge a huge branch without much review.

Thanks for the help.

Oh, and being very cheeky... I wouldn't mind Krita being in the list with compatible software. Here's a patch with a draft :-)

--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl

Congrats!

I can't wait to download it and give it a test. We'll certainly
update opencolorio.org and list Krita! :)

-- Jeremy

Boudewijn,

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

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

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

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.

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.

-- Jeremy

Oh, and also note that OCIO ships with some example images,
http://code.google.com/p/opencolorio/downloads/detail?name=ocio-images.1.0v4.tgz

if you'd like to confirm the color processing is working appropriately.

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

On Friday 15 June 2012 Jun, Jeremy Selan wrote:

Oh, and also note that OCIO ships with some example images,
http://code.google.com/p/opencolorio/downloads/detail?name=ocio-images.1.0v4.tgz

if you'd like to confirm the color processing is working appropriately.

Thanks, got it!

--
Boudewijn Rempt