Re: [Bf-committers] Blender 2.59 release AHOY!
Hi, I've got fix for grease pencil in mu branch [1], but it's really that kind of changes which shouldn't be applied in last minute (at least there are several possible issues i wanted to check), so let's limit GP a bit for 2.59. About reloading scripts and so. I've been working on UI in my branch after merging ghash changes there and haven't found any bad sides of this change. About more clear release next time. I'm not sure why this release is so "crazy". Is it our lag, lag of coordination or so.. [1] http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=39313 P.S. linux 32/64 bit would be available soon. Campbell Barton wrote: > Hi, woke up to find a re-release from a revision that contains changes > I made that were *not* intended to be in a stable release - switching > operators and menus to hash lookups. > We should have branched at r39259 stable and applied patches there > before re-releasing. > > > There is also the issue with grease pencil session - where the > operator points to data that can be freed on 'Global Undo' (as opposed > to the crasher with the modal operators own *fake* undo, fixed 39237 > and double undos fixed 39235). > > Sergey's fix means you can't move the viewport while grease pencil > session is enable so the option is now not at all working as it was > meant. > > *Sigh* > Since there were 3 fairly bad bugs in this tool (2 crashers), my > impression is that option isn't used all that much. > A correct fix isn't some small edit, the operator must store data > differently, this should have been picked up during normal > development, IMHO we should not attempt to sort this out as a > last-minute, show-stopper fix. > > > There is the remaining issue: > Do we use current bsd/linux/mac builds from r39304 (and wait on win > build before announcing), > Or re-branch from 39259 and apply a few fixes there and rebuild on all > platforms. > > By not re-branching we break our own guidelines - to unfreeze quick > but use a branch for fixes and it feels very sloppy to me. > On the other hand my change of moving operators/menu's into a hash > isn't that big a deal and works with scripts reloading, freeing, > re-registering operators etc - I would expect any bugs here would be > obvious and break blender immediately, so I *think* they are safe. > > Suggest to go ahead with r39304, but next release be more clear with > release tag/branch, and the following unfreeze. > > - Campbell > > On Fri, Aug 12, 2011 at 3:58 AM, Kent Mein wrote: >> In reply to Sergey I. Sharybin (g.ula...@gmail.com): >> >>> Didn't know OSX still have got issues with non-trunk verison. I've just >>> commited patch from Jens to solve this problems. >>> >>> We prefer to keep revisions synced for all platforms, so please use >>> >>> Trunk: r39307 >>> Extensions: r2241 >>> >> Updated tarball of the source and md5sum are in incoming on ftp.blender.org >> >> Kent >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
While writing my last reply I made an error checking on the re-release revision I saw Sergey's mail refer to 39304. In my last mail substitute 39304 with 39307. Lets use tag's next time! On Fri, Aug 12, 2011 at 10:30 AM, pete larabell wrote: > well, 12.5 hrs from now... is tomorrow for me. i can have it uploaded > in 13hrs from now. > > On Thu, Aug 11, 2011 at 7:29 PM, pete larabell wrote: >> if you need 39304 for FreeBSD it'll have to wait till tomorrow... :( >> >> On Thu, Aug 11, 2011 at 7:29 PM, pete larabell wrote: >>> I only have a 39307 uploaded.. don't think I put 39304 up... is 39307 ok??? >>> >>> On Thu, Aug 11, 2011 at 7:10 PM, Campbell Barton >>> wrote: Hi, woke up to find a re-release from a revision that contains changes I made that were *not* intended to be in a stable release - switching operators and menus to hash lookups. We should have branched at r39259 stable and applied patches there before re-releasing. There is also the issue with grease pencil session - where the operator points to data that can be freed on 'Global Undo' (as opposed to the crasher with the modal operators own *fake* undo, fixed 39237 and double undos fixed 39235). Sergey's fix means you can't move the viewport while grease pencil session is enable so the option is now not at all working as it was meant. *Sigh* Since there were 3 fairly bad bugs in this tool (2 crashers), my impression is that option isn't used all that much. A correct fix isn't some small edit, the operator must store data differently, this should have been picked up during normal development, IMHO we should not attempt to sort this out as a last-minute, show-stopper fix. There is the remaining issue: Do we use current bsd/linux/mac builds from r39304 (and wait on win build before announcing), Or re-branch from 39259 and apply a few fixes there and rebuild on all platforms. By not re-branching we break our own guidelines - to unfreeze quick but use a branch for fixes and it feels very sloppy to me. On the other hand my change of moving operators/menu's into a hash isn't that big a deal and works with scripts reloading, freeing, re-registering operators etc - I would expect any bugs here would be obvious and break blender immediately, so I *think* they are safe. Suggest to go ahead with r39304, but next release be more clear with release tag/branch, and the following unfreeze. - Campbell On Fri, Aug 12, 2011 at 3:58 AM, Kent Mein wrote: > In reply to Sergey I. Sharybin (g.ula...@gmail.com): > >> Didn't know OSX still have got issues with non-trunk verison. I've just >> commited patch from Jens to solve this problems. >> >> We prefer to keep revisions synced for all platforms, so please use >> >> Trunk: r39307 >> Extensions: r2241 >> > > Updated tarball of the source and md5sum are in incoming on > ftp.blender.org > > Kent > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers >>> >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
well, 12.5 hrs from now... is tomorrow for me. i can have it uploaded in 13hrs from now. On Thu, Aug 11, 2011 at 7:29 PM, pete larabell wrote: > if you need 39304 for FreeBSD it'll have to wait till tomorrow... :( > > On Thu, Aug 11, 2011 at 7:29 PM, pete larabell wrote: >> I only have a 39307 uploaded.. don't think I put 39304 up... is 39307 ok??? >> >> On Thu, Aug 11, 2011 at 7:10 PM, Campbell Barton >> wrote: >>> Hi, woke up to find a re-release from a revision that contains changes >>> I made that were *not* intended to be in a stable release - switching >>> operators and menus to hash lookups. >>> We should have branched at r39259 stable and applied patches there >>> before re-releasing. >>> >>> >>> There is also the issue with grease pencil session - where the >>> operator points to data that can be freed on 'Global Undo' (as opposed >>> to the crasher with the modal operators own *fake* undo, fixed 39237 >>> and double undos fixed 39235). >>> >>> Sergey's fix means you can't move the viewport while grease pencil >>> session is enable so the option is now not at all working as it was >>> meant. >>> >>> *Sigh* >>> Since there were 3 fairly bad bugs in this tool (2 crashers), my >>> impression is that option isn't used all that much. >>> A correct fix isn't some small edit, the operator must store data >>> differently, this should have been picked up during normal >>> development, IMHO we should not attempt to sort this out as a >>> last-minute, show-stopper fix. >>> >>> >>> There is the remaining issue: >>> Do we use current bsd/linux/mac builds from r39304 (and wait on win >>> build before announcing), >>> Or re-branch from 39259 and apply a few fixes there and rebuild on all >>> platforms. >>> >>> By not re-branching we break our own guidelines - to unfreeze quick >>> but use a branch for fixes and it feels very sloppy to me. >>> On the other hand my change of moving operators/menu's into a hash >>> isn't that big a deal and works with scripts reloading, freeing, >>> re-registering operators etc - I would expect any bugs here would be >>> obvious and break blender immediately, so I *think* they are safe. >>> >>> Suggest to go ahead with r39304, but next release be more clear with >>> release tag/branch, and the following unfreeze. >>> >>> - Campbell >>> >>> On Fri, Aug 12, 2011 at 3:58 AM, Kent Mein wrote: In reply to Sergey I. Sharybin (g.ula...@gmail.com): > Didn't know OSX still have got issues with non-trunk verison. I've just > commited patch from Jens to solve this problems. > > We prefer to keep revisions synced for all platforms, so please use > > Trunk: r39307 > Extensions: r2241 > Updated tarball of the source and md5sum are in incoming on ftp.blender.org Kent ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers >>> >>> >>> >>> -- >>> - Campbell >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
if you need 39304 for FreeBSD it'll have to wait till tomorrow... :( On Thu, Aug 11, 2011 at 7:29 PM, pete larabell wrote: > I only have a 39307 uploaded.. don't think I put 39304 up... is 39307 ok??? > > On Thu, Aug 11, 2011 at 7:10 PM, Campbell Barton wrote: >> Hi, woke up to find a re-release from a revision that contains changes >> I made that were *not* intended to be in a stable release - switching >> operators and menus to hash lookups. >> We should have branched at r39259 stable and applied patches there >> before re-releasing. >> >> >> There is also the issue with grease pencil session - where the >> operator points to data that can be freed on 'Global Undo' (as opposed >> to the crasher with the modal operators own *fake* undo, fixed 39237 >> and double undos fixed 39235). >> >> Sergey's fix means you can't move the viewport while grease pencil >> session is enable so the option is now not at all working as it was >> meant. >> >> *Sigh* >> Since there were 3 fairly bad bugs in this tool (2 crashers), my >> impression is that option isn't used all that much. >> A correct fix isn't some small edit, the operator must store data >> differently, this should have been picked up during normal >> development, IMHO we should not attempt to sort this out as a >> last-minute, show-stopper fix. >> >> >> There is the remaining issue: >> Do we use current bsd/linux/mac builds from r39304 (and wait on win >> build before announcing), >> Or re-branch from 39259 and apply a few fixes there and rebuild on all >> platforms. >> >> By not re-branching we break our own guidelines - to unfreeze quick >> but use a branch for fixes and it feels very sloppy to me. >> On the other hand my change of moving operators/menu's into a hash >> isn't that big a deal and works with scripts reloading, freeing, >> re-registering operators etc - I would expect any bugs here would be >> obvious and break blender immediately, so I *think* they are safe. >> >> Suggest to go ahead with r39304, but next release be more clear with >> release tag/branch, and the following unfreeze. >> >> - Campbell >> >> On Fri, Aug 12, 2011 at 3:58 AM, Kent Mein wrote: >>> In reply to Sergey I. Sharybin (g.ula...@gmail.com): >>> Didn't know OSX still have got issues with non-trunk verison. I've just commited patch from Jens to solve this problems. We prefer to keep revisions synced for all platforms, so please use Trunk: r39307 Extensions: r2241 >>> >>> Updated tarball of the source and md5sum are in incoming on ftp.blender.org >>> >>> Kent >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> >> >> >> -- >> - Campbell >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
I only have a 39307 uploaded.. don't think I put 39304 up... is 39307 ok??? On Thu, Aug 11, 2011 at 7:10 PM, Campbell Barton wrote: > Hi, woke up to find a re-release from a revision that contains changes > I made that were *not* intended to be in a stable release - switching > operators and menus to hash lookups. > We should have branched at r39259 stable and applied patches there > before re-releasing. > > > There is also the issue with grease pencil session - where the > operator points to data that can be freed on 'Global Undo' (as opposed > to the crasher with the modal operators own *fake* undo, fixed 39237 > and double undos fixed 39235). > > Sergey's fix means you can't move the viewport while grease pencil > session is enable so the option is now not at all working as it was > meant. > > *Sigh* > Since there were 3 fairly bad bugs in this tool (2 crashers), my > impression is that option isn't used all that much. > A correct fix isn't some small edit, the operator must store data > differently, this should have been picked up during normal > development, IMHO we should not attempt to sort this out as a > last-minute, show-stopper fix. > > > There is the remaining issue: > Do we use current bsd/linux/mac builds from r39304 (and wait on win > build before announcing), > Or re-branch from 39259 and apply a few fixes there and rebuild on all > platforms. > > By not re-branching we break our own guidelines - to unfreeze quick > but use a branch for fixes and it feels very sloppy to me. > On the other hand my change of moving operators/menu's into a hash > isn't that big a deal and works with scripts reloading, freeing, > re-registering operators etc - I would expect any bugs here would be > obvious and break blender immediately, so I *think* they are safe. > > Suggest to go ahead with r39304, but next release be more clear with > release tag/branch, and the following unfreeze. > > - Campbell > > On Fri, Aug 12, 2011 at 3:58 AM, Kent Mein wrote: >> In reply to Sergey I. Sharybin (g.ula...@gmail.com): >> >>> Didn't know OSX still have got issues with non-trunk verison. I've just >>> commited patch from Jens to solve this problems. >>> >>> We prefer to keep revisions synced for all platforms, so please use >>> >>> Trunk: r39307 >>> Extensions: r2241 >>> >> >> Updated tarball of the source and md5sum are in incoming on ftp.blender.org >> >> Kent >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > > -- > - Campbell > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
Hi, woke up to find a re-release from a revision that contains changes I made that were *not* intended to be in a stable release - switching operators and menus to hash lookups. We should have branched at r39259 stable and applied patches there before re-releasing. There is also the issue with grease pencil session - where the operator points to data that can be freed on 'Global Undo' (as opposed to the crasher with the modal operators own *fake* undo, fixed 39237 and double undos fixed 39235). Sergey's fix means you can't move the viewport while grease pencil session is enable so the option is now not at all working as it was meant. *Sigh* Since there were 3 fairly bad bugs in this tool (2 crashers), my impression is that option isn't used all that much. A correct fix isn't some small edit, the operator must store data differently, this should have been picked up during normal development, IMHO we should not attempt to sort this out as a last-minute, show-stopper fix. There is the remaining issue: Do we use current bsd/linux/mac builds from r39304 (and wait on win build before announcing), Or re-branch from 39259 and apply a few fixes there and rebuild on all platforms. By not re-branching we break our own guidelines - to unfreeze quick but use a branch for fixes and it feels very sloppy to me. On the other hand my change of moving operators/menu's into a hash isn't that big a deal and works with scripts reloading, freeing, re-registering operators etc - I would expect any bugs here would be obvious and break blender immediately, so I *think* they are safe. Suggest to go ahead with r39304, but next release be more clear with release tag/branch, and the following unfreeze. - Campbell On Fri, Aug 12, 2011 at 3:58 AM, Kent Mein wrote: > In reply to Sergey I. Sharybin (g.ula...@gmail.com): > >> Didn't know OSX still have got issues with non-trunk verison. I've just >> commited patch from Jens to solve this problems. >> >> We prefer to keep revisions synced for all platforms, so please use >> >> Trunk: r39307 >> Extensions: r2241 >> > > Updated tarball of the source and md5sum are in incoming on ftp.blender.org > > Kent > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
In reply to Sergey I. Sharybin (g.ula...@gmail.com): > Didn't know OSX still have got issues with non-trunk verison. I've just > commited patch from Jens to solve this problems. > > We prefer to keep revisions synced for all platforms, so please use > > Trunk: r39307 > Extensions: r2241 > Updated tarball of the source and md5sum are in incoming on ftp.blender.org Kent ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
FreeBSD builds are up... again again :) On Thu, Aug 11, 2011 at 11:01 AM, Sergey I. Sharybin wrote: > Pardon, guys, > > Didn't know OSX still have got issues with non-trunk verison. I've just > commited patch from Jens to solve this problems. > > We prefer to keep revisions synced for all platforms, so please use > > Trunk: r39307 > Extensions: r2241 > > as reference for new release archives. > > I hope it's last update before real release! Anyway, thanks all! > > -- > With best regards, Sergey I. Sharybin > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender OCIO
> - Blender use color-management only for float images. I do not plan and > > changing this. For quick operation of some of the Blender features (3d > view > > texturing, sequencer, ...) I think it is best to keep things that way. > > > > what does that mean ? 8bit (or whatever) image are not converted to float > anyway ? > When loading a PNG or JPEG image for example. it is loaded in 8bit per channel in ImBuf->rect without doing any color-management transformation (the data in ImBuf->rect is in the same color-space as in the file). If you use this image as a texture in text-face mode for the game engine or 3D view, than this 8bit per channel image is used directly in it's "native" color-space. But if you use this image in a "image input" node in the compositor, than this image is converted to float in ImBuf->rect_float and at the same time color-management is applied for this float data to be in linear color-space. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
Pardon, guys, Didn't know OSX still have got issues with non-trunk verison. I've just commited patch from Jens to solve this problems. We prefer to keep revisions synced for all platforms, so please use Trunk: r39307 Extensions: r2241 as reference for new release archives. I hope it's last update before real release! Anyway, thanks all! -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
The very recent linux release archives are there: http://download.blender.org/ftp/incoming/linux-release-39304/ Sergey I. Sharybin wrote: > I've made grease pencil block all other operations when using it in > sketching mode. > > It's the only way for now because it's not only undo which can confuse > grease pencil, also > toggling edit mode, transformation and so confuses this operator. > > So we should update release builds to > > Trunk: r39304 > Extensions: r2241 > > Thomas Dinges wrote: >> As a side note, please keep trunk frozen until release is out! No >> unnecessary commits! >> >> Am 11.08.2011 14:37, schrieb Thomas Dinges: >>> Enable "Use Sketching session" (Grease Pencil) in the Toolbar, and draw >>> something into the viewport. Undo. Crash. >>> Confirmed by Sergey and myself on Linux and Windows. >>> >>> Showstopper!? >>> >>> Am 10.08.2011 22:18, schrieb Campbell Barton: yikes! thats bad!, yes _please_ report bugs like this right away, especially near release and in the tracker. but good you found this too, fixed in svn. Platform maintainers, these rev's are now needed for building. Trunk: r39272 Extensions: r2241 > > > -- > With best regards, Sergey I. Sharybin -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Cycles - more than 2 textures Bug
Hi, Thanks, I've added a link in the wiki bug list. http://wiki.blender.org/index.php/Dev:2.5/Source/Render/Cycles/KnownIssues Brecht. On Thu, Aug 11, 2011 at 3:09 PM, Thomas Volkmann wrote: > Hi, > > I have uploaded a testscene that shows that issue. Open the blend, look > at the render, in the materialnode-tree connect the last 'Mix Closure' > to 'Material surface', look at the render again. > Scene is here: > http://thomasvolkmann.com/download/cycles_tex_BUG.zip > > cheers, > Thomas > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
I've made grease pencil block all other operations when using it in sketching mode. It's the only way for now because it's not only undo which can confuse grease pencil, also toggling edit mode, transformation and so confuses this operator. So we should update release builds to Trunk: r39304 Extensions: r2241 Thomas Dinges wrote: > As a side note, please keep trunk frozen until release is out! No > unnecessary commits! > > Am 11.08.2011 14:37, schrieb Thomas Dinges: >> Enable "Use Sketching session" (Grease Pencil) in the Toolbar, and draw >> something into the viewport. Undo. Crash. >> Confirmed by Sergey and myself on Linux and Windows. >> >> Showstopper!? >> >> Am 10.08.2011 22:18, schrieb Campbell Barton: >>> yikes! thats bad!, yes _please_ report bugs like this right away, >>> especially near release and in the tracker. >>> but good you found this too, fixed in svn. >>> >>> Platform maintainers, these rev's are now needed for building. >>> >>> Trunk: r39272 >>> Extensions: r2241 -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Cycles - more than 2 textures Bug
Hi, I have uploaded a testscene that shows that issue. Open the blend, look at the render, in the materialnode-tree connect the last 'Mix Closure' to 'Material surface', look at the render again. Scene is here: http://thomasvolkmann.com/download/cycles_tex_BUG.zip cheers, Thomas ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
As a side note, please keep trunk frozen until release is out! No unnecessary commits! Am 11.08.2011 14:37, schrieb Thomas Dinges: > Enable "Use Sketching session" (Grease Pencil) in the Toolbar, and draw > something into the viewport. Undo. Crash. > Confirmed by Sergey and myself on Linux and Windows. > > Showstopper!? > > Am 10.08.2011 22:18, schrieb Campbell Barton: >> yikes! thats bad!, yes _please_ report bugs like this right away, >> especially near release and in the tracker. >> but good you found this too, fixed in svn. >> >> Platform maintainers, these rev's are now needed for building. >> >> Trunk: r39272 >> Extensions: r2241 >> -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender 2.59 release AHOY!
Enable "Use Sketching session" (Grease Pencil) in the Toolbar, and draw something into the viewport. Undo. Crash. Confirmed by Sergey and myself on Linux and Windows. Showstopper!? Am 10.08.2011 22:18, schrieb Campbell Barton: > yikes! thats bad!, yes _please_ report bugs like this right away, > especially near release and in the tracker. > but good you found this too, fixed in svn. > > Platform maintainers, these rev's are now needed for building. > > Trunk: r39272 > Extensions: r2241 > -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Blender OCIO
Hi, > - Blender use color-management only for float images. I do not plan and > changing this. For quick operation of some of the Blender features (3d view > texturing, sequencer, ...) I think it is best to keep things that way. > what does that mean ? 8bit (or whatever) image are not converted to float anyway ? F 2011/8/10 Xavier Thomas > Hi, > > Here is my ideas/interrogations regarding the my blender-ocio integration > experiment. > > My plan is to replace the current color-management code with code relying > on > the OCIO library, and make the current colormanagement pipeline > configurable > by the user. Because I do not have much time to dedicate to this project, I > want to follow those rules: > - small incremental steps > - any contributor/tester is welcome. > - be patient > > Some Things to knows: > - Blender use color-management only for float images. I do not plan and > changing this. For quick operation of some of the Blender features (3d view > texturing, sequencer, ...) I think it is best to keep things that way. > However a flag to force converting some image to float when loading them > would be usefull. > - OCIO needs a config file containing the list of color-spaces, > display/view > transformations, roles, ... So Blender would need to provide a default > configuration. Users can overwrite the default configuration but in this > case there could be problem when exchanging blender files that was created > with different config (missing colorspaces, different name for the > same color-space, ...) > > > Some of the interrogations I have since I began working on this: > > - Color management would become mandatory and the property > "rendersetting.use_color_management" would be removed. This would make > OpenColorIO a mandatory dependency for compiling, so I included the OCIO > source in "extern". OCIO comes with its own mandatory dependencies (tinyxml > and yaml-cpp, both patched). For now I didn't change the way those > dependencies are compiled: using the CMake ExternalProject macro that > unpack > the tgz containing the source, patch it and compile it. I am not sure if > those dependencies can stay in "extern/ocio/ext" or if I should add a > directory in "extern for" each of those libraries (extern/tinyxml and > extern/yaml-cpp). It is not a big deal really but it would be better to > decide on this before working more on the building systems (for now only > CMake is working). Once a decision is taken if somebody want to contribute > for Scons and tests on Windows/Mac I am cool with it ;) > > - In "extern/ocio" I added 2 files "ocio-capi.h" and "ocio-capi.c". Those > contains just a basic C API to access the OCIO lib from blender C code. The > API is very close to the original OCIO API and complete enough for loading > a > config and its content (main color-spaces and display/views) as well as > for applying transform to a whole buffer or use the per pixel > transformations. The main issue at this level is that OCIO uses shared > pointer in C++ so it made it a bit difficult to write an simple C API. To > work around this you should call a function to release each pointer to OCIO > objects after using them. Like this for example: > > ConstConfigRcPtr* config = OCIO_getCurrentConfig(); > ConstColorSpaceRcPtr* colorspace = OCIO_configGetColorSpace(config, > "colorspace_name"); > // do something here > OCIO_colorSpaceRelease(colorspace); > OCIO_configRelease(config); > > This is a bit annoying but not a big deal because this API will only be > used > in BKE_colormanagement which will provide a easier API to use in other > place > of the Blender source. Anyway, if one of you have a better way to do this I > am all ears. > > - BKE_colormanagement > This seems to be the appropriate place to write the > blender color-management system (relying on the OCIO C API). > *There seems to be no consistent naming for the functions in there. Should > I > prefix the public functions with BKE or a new prefix BCM or not at all? > Also, I used camelCase for the functions name is that OK or should it be > all > lower case with _ between words? > *Is the use of the global G (G.main) OK to store the info needed by the > color management system (list of colorspaces in the config for example)? > *I added in there some helper functions to get RNA EnumProperty arrays of > available choice for color-spaces/display. This would be needed in > different > places in the RNA system (Images properties, save image operators, some > nodes, viewers, ...). Maybe this belongs in the makesrna code, I am not > sure. > > > - DNA data > For the data that will be saved in the blend file, I plan to add char[32] > properties to the DNA structures for saving color-space name (in the Image > structure for example). Like this is is possible to match different blend > file with different OCIO config file. When loading a blend file, we can > mach > color-spaces by name and detect color-spaces used in the blender file that > are missi
