[Bf-vfx] OCIO branch

[Brecht Van Lommel]

It would be convenient if we could do it all on the fly, but my
understanding is that not all OCIO transforms can run on the GPU. For
example 3D LUTs are not supported, which is used for e.g. the ACES RRT
+ sRGB or spi-vfx sRGB conversion. Another concern might be
performance for more complicated transforms.

Personally I think the main change to make is to have a proper
distinction between an 8bit ImBuf and a cached display buffer (which
might be created from a float or 8bit image). If it happens to be so
that we can display the rect directly, or the rect_float with an
on-the-fly GLSL transforms, this cache can stay empty. The ImBuf might
then have a list of such cached display buffers (usually there would
be one, but there's case where you need multiple). The weak point then
is deciding when to free buffers in the cache, but I think it's
doable.

Brecht.

On Sun, May 20, 2012 at 1:43 AM, Matt Ebb <matt at mke3.net> wrote:
> I always disliked the image editor keeping an 8bit buffer around for
> display. I can't remember all the cases, but having to keep the two in
> sync makes a lot of things a lot more complicated and bug-prone (eg.
> the curves widget in the image editor).
>
> I would hope that in this modern era, float images could be kept
> internally as float, and be transformed at render time for display on
> the GPU, wich AFAIK is what OCIO lets you do. Ideally this would also
> support some degree of gamma/exposure adjustment before this in that
> GPU pipeline (for preview/display only) a la nuke.
>
> Matt
>
>
> On Sun, May 20, 2012 at 2:41 AM, Lukas Tönne
> <lukas.toenne at googlemail.com> wrote:
>> Hi,
>>
>> I have recently updated the existing OCIO branch [1] by Xavier Thomas
>> to latest trunk (last update was 8 months ago) and put a copy in my
>> personal git repository [2]. After discussion with Brecht i've made a
>> few changes to the code layout and done some minor work to make myself
>> familiar with the C API and OCIO in general. Check the log [3] for
>> details (i'll keep the branch rebased on trunk, so the commits will
>> stay on top). I have no background in color management, so please bear
>> with me and correct me if i'm wrong :)
>>
>> Coder stuff:
>>
>> One general design question is how to handle display buffers. I think
>> the consensus is that all float image buffers should generally be
>> using scene-linear profiles. In order to display such buffers using
>> the current glDrawPixels methods (GLSL transformation may work using a
>> shader) i assume it is preferable to use a cached display buffer with
>> the color-transformed ("sRGB") values. UI elements with single or
>> limited number of colors OTOH can probably use direct color
>> transformation calls for drawing.
>>
>> The only place where such a display buffer is implemented atm is the
>> Image space, which uses a second ImBuf struct "colormanaged_ibuf" to
>> store the display device values. In other places the scene-linear
>> buffer may not even be stored (point in case: node previews), so the
>> image would have to be reconstructed (compositor/shader execution)
>> each time the display/view profile is changed ...
>>
>> My suggestion would be to add the display buffer directly in the ImBuf
>> struct, in addition to the original scene-linear rect_float (for int
>> buffers this would just be the unsigned char *rect buffer). ImBuf
>> should generally be used in all places where image data is displayed
>> in the UI (so node preview would use it as well). Does that make
>> sense?
>>
>> Regards,
>> Lukas
>>
>> [1]
>> https://github.com/thmxv/blender-ocio
>>
>> [2]
>> https://www.gitorious.org/~lukastoenne/blenderprojects/blender-lukastoenne
>>
>> checkout the branch directly with:
>>
>> git clone git://gitorious.org/~lukastoenne/blenderprojects/blender-lukastoenne.git
>> -b ocio
>>
>> [3]
>> https://www.gitorious.org/blenderprojects/blender-lukastoenne/commits/ocio
>> _______________________________________________
>> Bf-vfx mailing list
>> Bf-vfx at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-vfx
> _______________________________________________
> Bf-vfx mailing list
> Bf-vfx at blender.org
> http://lists.blender.org/mailman/listinfo/bf-vfx