J might that depend on network load since a zips exr is smaller then a dpx of the same resolution? Plus if you are trying to save disk space. I use DPX's internally here but I have worked at places where everything is converted to EXR in ingest to save space and bandwidth according to the IT guy.
Randy S. Little http://www.rslittle.com/ http://www.imdb.com/name/nm2325729/ On Thu, Aug 8, 2013 at 6:00 PM, J Bills <[email protected]> wrote: > dpx's are a fair amount faster in Nuke than EXR, in my tests. I suppose > we'll hit a point where the camera sensors can capture more than 16 bit and > then EXR might get the call, but until then, viva la dpx for live action > plates. EXR for cg renders, though, obviously. > > I need to update my little test with EXR 2.0 one of these days, give it a > go > > quicktimes have no place in a Nuke script. I mean, they can work and I > haven't seem them wreck stability every time, but best to get them ran out > and swapped in with image seqs before you take anything to a renderfarm, > that's for sure! > > Nice for editing and possibly for lightweight review, but that's about the > extent of Quicktime's usefulness. > > Brenden Bolles (proEXR plugin guy) has said publically he's working on a > container format that would use OpenEXR as a base - essentially an openEXR > quicktime. Finally, lossless and float! Although it will likely be .ogg > or something thereabouts if I recall. This would be nice! I'm not a fan > of ProRes. You can say "perceptibly lossless" all you want, but it's still > lossy and where I come from that ain't good. I hate that editors seem to > toss it around like it's lossless. > > > > > On Thu, Aug 8, 2013 at 4:06 PM, John Coldrick <[email protected]>wrote: > >> No, it's early days yet. I would agree that it's likely network usage >> would go up but we have yet to test it. Just interactively comparing, the >> speed was about the same, but I get that doesn't translate directly to >> heavy usage in the middle of the day. Quite frankly I think it's not a >> good idea, I was looking for someone doing violent wave-offs to save me the >> trouble. :) >> >> But yeah, I'll check that, thanks! >> >> Cheers, >> >> J.C. >> >> >> On Thu, Aug 8, 2013 at 7:00 PM, Randy Little <[email protected]>wrote: >> >>> Did you check network and render farm memory usage with QT vs DPX? I >>> would think DPX put a lot less load on the nework. Also why dpx. exr with >>> zips is smaller and at least as fast which in turn would lessen your >>> network load during render or working even more. No? yes? am I still >>> asleep trying to remember how plus works after 20 year of doing this? >>> >>> Randy S. Little >>> http://www.rslittle.com/ >>> http://www.imdb.com/name/nm2325729/ >>> >>> >>> >>> >>> On Thu, Aug 8, 2013 at 3:56 PM, John Coldrick >>> <[email protected]>wrote: >>> >>>> Hey all - we typically pull our plates from the above files and output >>>> to dpx files for compositing. Someone here has been pushing for just using >>>> the original quicktimes directly in comp(we've gotten a fix from the latest >>>> release notes that addresses a subtle colour shift between nuke and >>>> compressor). Apart from the arguments about speed(we found in the end it's >>>> actually pretty similar) and workflow(head in and out and the rest we can >>>> probably handle), it struck me that stability is a potential problem. >>>> We're running windows here(win7 64 bit), and I was able to make some >>>> quicktime crashes pretty trivially with Nuke 6.3v4 through 7.0v8(same >>>> triggers, same crash, which suggests the issue is with quicktime). >>>> >>>> I'm arguing no for stability reasons, but I can see the benefits if it >>>> works - just wondering if anyone here has done this with any success or >>>> wildly wave their hands saying 'nooooooo!'. >>>> >>>> Thanks in advance >>>> >>>> J.C. >>>> >>>> _______________________________________________ >>>> 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 >> > > > _______________________________________________ > 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
