On 6/11/2012 12:03 PM, Jeremy Selan wrote:

Good idea. I'll make a runtime button to switch between the two. That
will also let us confirm the two code paths give similar results. ;)

I just got out of a bad relationship with some code that was handed to me that was full of #ifdefs, so I thought I'd try to do a solid for everyone else and recommend against them. :-)

On Mon, Jun 11, 2012 at 9:43 AM, Paul Miller<pa...@...> wrote:

On 6/11/2012 11:36 AM, Jeremy Selan wrote:

Hello!

Sorry you're having trouble with the documentation. Which specific
file or url are you at? I'd like to update it to make sure it's
current.

I'd recommend looking into src/apps/ociodisplay/main.cpp

Even though that's a GPU example, 95% of the code would be unchanged
even if we were to use the CPU pathway. (Actually, maybe I should
have ifdef's for CPU vs GPU? It's a nice example.

If you can, make it switchable between the two during run-time, or as a
command-line switch. #ifdefs make the code harder to read.

On Monday 11 June 2012 Jun, Jeremy Selan wrote:

Hello!

Sorry you're having trouble with the documentation. Which specific
file or url are you at? I'd like to update it to make sure it's
current.

https://github.com/imageworks/OpenColorIO/blob/master/docs/developers/usage_examples.rst -- the "Displaying an image, using the CPU (Full Display Pipeline)" section.

I'd have attached a patch for the docs if I knew for sure what the right way would be :-).

I'd recommend looking into src/apps/ociodisplay/main.cpp

Okay!

Even though that's a GPU example, 95% of the code would be unchanged
even if we were to use the CPU pathway. (Actually, maybe I should
have ifdef's for CPU vs GPU? It's a nice example.

Yeah -- it could be nice, or two next to each other, just to show the difference. Also to show the difference in performance.

See UpdateOCIOGLState(), up to the processor = config->getProcessor(transform);
At that point, you can directly apply the processor to perform and
in-place color conversion on your image.

// Wrap the image in a light-weight ImageDescription
OCIO::PackedImageDesc img(imageData, w, h, 4);

// Apply the color transformation (in place)
processor->apply(img);

Unfortunately we dont offer native support for half-float buffers on
the CPU side, so in the meantime you will need to copy to float32.

Okay, that's fine, as long as I know.

The reason some applications expose file selectors is for people who
dont want to use OCIO configurations, but still want to be able to use
raw existing luts. (This is essentially for backwards compatibility).
I would say to not worry about this for now, for an initial
implementation.

Right -- thanks for the hint. Krita comes from the icc world, despite having had openexr support for half a decade now, so there's a bit of mental adaptation to be made.

By the way, I would *highly* recommend looking into using the GPU
pathway for creating a display.

Yes, that's next on my todo. We try to support both cpu and gpu with Krita as much as possible, but we're rewriting our gpu-based canvas implementation at the moment, so I thought I'd get started with the cpu path.

(You should be able to steal much of
the code from src/apps/ociodisplay/main.cpp). For places where
you're baking color transforms into images (loading/saving images,
etc) the CPU pathway is preferred. But for situations where you will
be playing back image sequences to the display, or handling pan/zoom
with frequent updates (real-time preview), the GPU pathway is much
higher performance. Also, when using the GPU codepath you can store
the underlying image in any data type you like. (such as half float,
or even integer should your color-space be amenable to it).

Thanks for all the hints! I'll let you know when I've got more questions or can report that Krita is one of the apps that support OpenColorIO :-)
--
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl

Good idea. I'll make a runtime button to switch between the two. That
will also let us confirm the two code paths give similar results. ;)

On 6/11/2012 11:36 AM, Jeremy Selan wrote:

Hello!

Sorry you're having trouble with the documentation. Which specific
file or url are you at? I'd like to update it to make sure it's
current.

I'd recommend looking into src/apps/ociodisplay/main.cpp

Even though that's a GPU example, 95% of the code would be unchanged
even if we were to use the CPU pathway. (Actually, maybe I should
have ifdef's for CPU vs GPU? It's a nice example.

If you can, make it switchable between the two during run-time, or as a command-line switch. #ifdefs make the code harder to read.

Hello!

Sorry you're having trouble with the documentation. Which specific
file or url are you at? I'd like to update it to make sure it's
current.

I'd recommend looking into src/apps/ociodisplay/main.cpp

Even though that's a GPU example, 95% of the code would be unchanged
even if we were to use the CPU pathway. (Actually, maybe I should
have ifdef's for CPU vs GPU? It's a nice example.

See UpdateOCIOGLState(), up to the processor = config->getProcessor(transform);
At that point, you can directly apply the processor to perform and
in-place color conversion on your image.

// Wrap the image in a light-weight ImageDescription
OCIO::PackedImageDesc img(imageData, w, h, 4);

// Apply the color transformation (in place)
processor->apply(img);

Unfortunately we dont offer native support for half-float buffers on
the CPU side, so in the meantime you will need to copy to float32.


The reason some applications expose file selectors is for people who
dont want to use OCIO configurations, but still want to be able to use
raw existing luts. (This is essentially for backwards compatibility).
I would say to not worry about this for now, for an initial
implementation.


By the way, I would *highly* recommend looking into using the GPU
pathway for creating a display. (You should be able to steal much of
the code from src/apps/ociodisplay/main.cpp). For places where
you're baking color transforms into images (loading/saving images,
etc) the CPU pathway is preferred. But for situations where you will
be playing back image sequences to the display, or handling pan/zoom
with frequent updates (real-time preview), the GPU pathway is much
higher performance. Also, when using the GPU codepath you can store
the underlying image in any data type you like. (such as half float,
or even integer should your color-space be amenable to it).

-- Jeremy