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 <[email protected]> > 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 <[email protected] > >wrote: > > > On Mar 12, 2013 3:27 PM, "Julien Enche" <[email protected]> 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 > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > > > > > -- > With best regards, Sergey Sharybin > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
