None of the blurs, but most of the color correction nodes will clamp values above 1.0 or below 0.0, you have to watch yourself carefully. For example, everything that works in HSV or uses a lookup table. The "half float" pixel format survives more cases than the "float" case, and should be also faster
On Wed, Apr 17, 2013 at 9:22 PM, Jason S <[email protected]> wrote: > ** > Well, > > It supports float images (exr's or otherwise) > in the sense that color values can go beyond 1 > that includes added/multiplied values using color corrects or composite > nodes, > and blurring (or anything) will consider those values. > > Yet in my example scene, > I put all sources in float (previously in 16 bit) in 12k > and displayed an 'out of memory' message. > > So I guess what prevents the FXTree's memory to be increased > is something else that could need some fixing. :\ > > OT/FYI In nuke, you can put *nukescripts.cache_clear("") * (when > rendering) > in the *after each frame* field in the Python tab of write nodes which > really helps alot. > > > > On 17/04/2013 3:24 AM, [email protected] wrote: > > I almost agree. > In my experience FXtree is great as long as you stick to 8 or 16 bit > images and perhaps very localized switching to 32bit on a small part of the > tree. > EXR images, handled in float - has been a total no-go for me – even a > simple 4 layer slap comp at HD res was painstakingly slow, and yes I did > try to give it more ram. I’d love to be proven wrong though. > Either way it doesn’t offer much in terms of a linear workflow, and clamps > pretty much anything – so not a lot you can do with those EXRs - and that’s > where Nuke delivers in spades. It can be a drag taking up ram and slowing > down - emptying buffers should be the operation you do the most on Nuke. > > > >
