[Bf-vfx] OCIO branch

[Matt Ebb]

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