Re: Documentation issues
Jeremy Selan <jeremy...@...>
Hello!toggle quoted messageShow quoted text
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
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)
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
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).
On Mon, Jun 11, 2012 at 1:50 AM, Boudewijn Rempt <bo...@...> wrote: