[Bf-committers] Cineon/DPX speed up

Julien Enche julien.enche at gmail.com
Wed Mar 13 10:44:25 CET 2013


Sergey,

Thank you for these clarifications, I will change the code accordingly and
submit a patch to correct that.

Troy,
At the moment DPX code does all the colorspace conversion itself to give
Blender a 32 bits float linear buffer.
 I haven't looked into the colormagement code and ocio usage in Blender
yet, so I can't answer you now about letting ocio do the conversion itself.
I'll have a look.

Julien



2013/3/13 Sergey Sharybin <sergey.vfx at gmail.com>

> Julien,
>
> When IB_test flag is set, no rect, rect_float buffers shall be allocated
> and no pixels reading from file shall happen. If it happens in Cineon/DPX
> that'd be bad and code shall be modified to be aware of this flag.
>
> IMB_rect_from_float shall not be called unless it's needed to the format
> itself. If codec outputs linear rect_float, it's indeed better to skip byte
> buffer generation.
>
> Troy,
> No, we could not "unbind" in my understanding of this word. Float buffers
> are always scene linear space with premultiplied alpha. Linearization
> happens after codec returned float buffer using ocio, for sure. You could
> not skip this step.
>
> If the question is more about 'if we could use ocio instead of hardcoded
> conversions" -- yes we could. If we shall -- no idea, depends on what's
> exactly going on there.
>
> If the question is more about "whether ocio is able to convert files'
> curves and primaries to internal blender's" yes it's able. You would only
> need to add some more spaces to your config. But that's not something i
> would want to happen in trunk -- exposing all the spaces which only one
> single person from this mailing list could follow is a crap ;)
>
> Long story short:
> - If DPX code is not aware of IB_test flag, that shall be easy to change
> - If DPX code itself does not rely on byte buffer, no rect_from_float shall
> happen
> - If there're some hardcoded curves in the code, we could check on
> switching them to generic ocio transform code. But please, do not introduce
> new spaces.
>
>
>
> On Wed, Mar 13, 2013 at 5:49 AM, Troy Sobotka <troy.sobotka at gmail.com
> >wrote:
>
> > On Mar 12, 2013 3:27 PM, "Julien Enche" <julien.enche at gmail.com> wrote:
> >
> > > 1) At the moment, the IB_test flag is not taken in account in the
> > > imb_load_dpx_cineon function, so color conversion happens twice. I
> > > haven't really find out what should be done and what can be skipped
> when
> > > this flag is set. Can you give me more information on the purpose of
> > > this flag so that I could adapt the code to use it efficiently (and
> > safely).
> >
> > Is there any way we can unbind the DPX code in such a way that it uses
> OCIO
> > and merely flags it as log etc? As I understood it, the DPX code makes
> > assumptions on the format and decodes accordingly?
> >
> > I ask because it would permit loading of different styled logs (Josh
> Pines
> > versus Cineon etc.), color primaries, etc.
> >
> > Curious if it is feasible to hand the log transfer curve conversion and
> > color primaries off to OCIO?
> >
> > With respect,
> > TJS
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> --
> With best regards, Sergey Sharybin
>  _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list