This isn't usual scenario behavior (you *should* have OCIO configuration). Correct fix would be to fallback to "stub"-based OCIO API which would be much more predictable and which isn't so much difficult to implement. I know about this issue and i'll work on this after codebase unfreeze.
The issue with your fix is missing configuration could backfire in lots of other places. On Thu, Oct 4, 2012 at 12:50 PM, Dan Eicher <[email protected]> wrote: > On Wed, Oct 3, 2012 at 11:21 PM, Sergey Sharybin <[email protected]> > wrote: > > Function you mentioned should not return null and if if does -- some > > datablock's color space is configured wrong and that's what should be > fixed. > > > > This probably prevents crash but currently i don't consider it's a > correct > > fix and would want to have feedback about circumstances when crash > happens > > here. > > This prevents a crash if the colorspace data file can't be found -- > blender just complains about the OCIO environmental variable instead > of segfaulting which IMHO is a little more user friendly. To reproduce > the crash just move the datafiles/colormanagment folder somewhere > blender can't find it. > > This doesn't fix any color management issues or anything like that, it > just checks for a null pointer being returned from a function that > *can* return NULL...easy peasy. > > Dan > _______________________________________________ > 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
