This prompted me to dig back and see my original bug report submitted around the time of 8.0v1 -although I haven't checked to see if this was fixed, and I didn't get sent a bug ID. The rest is a copy paste:
I seem to have found a repeatable bug that affects the LensDistortion node under certain circumstances. If I have a film scan plate (linearised exr) that has a few hot pixels in the ~500 range then the LensDistortion will slow to a crawl unless I add a Clamp node in-between. Of course, it's best practice to deal with those hot pixels but the LensDistortion does work fine in Nuke 7.0v9. Actually, I just checked and this is affecting STMap as well, I figured they may be using the same underlying method. Windows 7 Enterprise SP1. I've noticed this also seems to be an issue if I have, say, a cg render with a bounding box. If I kill the bounding box either by cropping or extending to the full image bounds then I'm back to normal speed. On 26 August 2014 11:00, Jed Smith <[email protected]> wrote: > I'm not sure if it's the same bug, but I have run into a similar problem > with LensDistortion nodes when put inline with certain other nodes. > > Basically the image calculates extremely slowly, but if you break > concatenation by putting a blur or grade above the LensDistortion node, it > works as expected. This particular issue might be related to piz compressed > exrs as well. > > Anyway, it's a long shot but your issue sounded similar to this one. > > Quoted below is my email to The Foundry with the bug id and an example > script. > > Hope that helps! > > On Monday, 2014-08-04 at 3:10p, Jed Smith wrote: > > I have run into another instance of bug id 42159, and thought I would > forward it along in case it is helpful in resolving the issue. This occurs > on Mac OSX 10.9.3 with Nuke 8.0v5. > > Open the script and view the end of the node stack. You can hopefully > observe that the image calculates very slowly for the complexity of the > input. Notice that if you insert the provided blur node before the > lensdistortion node to break concatenation, the image calculates as > expected. > > Interestingly, I discovered that if the input image is a piz compressed > sequence, this behavior occurs, but if it is a zip (1 scanline) compressed > image, it does not. A switch node is provided to demonstrate this. > > Would love to get this issue resolved. Thanks! > > -- > Jed Smith > Compositor, Atomic Fiction > > On Tuesday, 2014-08-26 at 7:07a, Frank Rueter|OHUfx wrote: > > yeah, I have tried runnign dealine jobs with only 2 and 4 threads each > with absolutely no results. > Then, when I set off a single manual command line render with all 10 cores > (20 cpus) it produced a frame after several minutes. > > > On 27/08/14 01:55, matt estela wrote: > > You're probably tried this, but maybe run multiple instances of nuke, each > running a limited number of threads? It's how we run nuke jobs on the farm > on our 8 and 16 core machines, limiting them to 4 cores from memory. > On 26/08/2014 11:51 PM, "Frank Rueter|OHUfx" <[email protected]> wrote: > > damn, that leaves me dead in the water. > oh well, I guess I will just go to bed and be grateful for any frame I see > in the morning > > On 27/08/14 01:31, Michael Garrett wrote: > > I may be wrong here, but I've actually seen something like this bug with > some operations that require heavy filtering, I seem to remember it getting > introduced with Nuke 8. I submitted a bug report to The Foundry with speed > comparisons with Nuke 7. > > I first noticed it with STMap then LensDistortion but it's quite > possible SphericalTransform is part of the same issue. > > The machine at the time was a 12 core Windows workstation. > > > On 26 August 2014 08:45, Frank Rueter|OHUfx <[email protected]> wrote: > > Hi guys, > > I am having a problem with a brand new deca core machine (64GB RAM) that > just won't render scripts with a SphericalTransform node. Nuke loads up, > then sits there with 0 cpu load or memory consumption and nothing happens. > Even my 4 year old laptop renders some frames - slowly, but it renders. > > I tried both windows and linux with similar results. This The inputs to > the SphericalTransform are 2k square. > > When I leave it rendering a single frame with all it's ten cores it will > eventually do it, but about 20 times slower than it should. > > Scripts without the SphericalTransform are fine. > > Does anybody have any idea what is going on? I am a bit screwed as I am > facing a huge deadline in a couple of days and can't render with the > fastest machine in the house. > > Cheers, > Frank > > > -- > [image: ohufxLogo 50x50] <http://www.ohufx.com> *vfx compositing > <http://ohufx.com/index.php/vfx-compositing> | workflow customisation and > consulting <http://ohufx.com/index.php/vfx-customising> * > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > > > _______________________________________________ > Nuke-users mailing [email protected], > http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > -- > [image: ohufxLogo 50x50] <http://www.ohufx.com> *vfx compositing > <http://ohufx.com/index.php/vfx-compositing> | workflow customisation and > consulting <http://ohufx.com/index.php/vfx-customising> * > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > > _______________________________________________ > Nuke-users mailing [email protected], > http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > -- > [image: ohufxLogo 50x50] <http://www.ohufx.com> *vfx compositing > <http://ohufx.com/index.php/vfx-compositing> | workflow customisation and > consulting <http://ohufx.com/index.php/vfx-customising> * > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
