I would consider EXR ZIPS vs DPX the EXR will be smaller and still be same fijle quality as DPX.
Randy S. Little http://www.rslittle.com/ http://www.imdb.com/name/nm2325729/ On Thu, Sep 18, 2014 at 8:26 PM, Deke Kincaid <[email protected]> wrote: > We updated the the newest Red SDK in Nuke 8.0v6, so there shouldn't be any > problems with reading newer camera files even if it is just for > conversion. Also the newest Red SDK adds the ability for us to GPU > debayer. We may or may not have time to get this into Nuke 9.0v1 but we > will see. This should help with r3d speed in Nuke. > > -- > Deke Kincaid > Creative Specialist > The Foundry > Skype: dekekincaid > Tel: (310) 399 4555 - Mobile: (310) 883 4313 > Web: www.thefoundry.co.uk > Email: [email protected] > > On Thu, Sep 18, 2014 at 4:17 PM, John Coldrick <[email protected]> > wrote: > >> Cool, thanks for the feedback guys. The speed hit seems like a no-fly... >> >> Cheers, >> >> J.C. >> >> On Thu, Sep 18, 2014 at 6:41 PM, Nathan Rusch <[email protected]> >> wrote: >> >>> R3D's are going to be slow because they need to be debayered. You're >>> also looking at more room for error by exposing all of the debayer settings >>> to the artist, and more room for instability by getting third-party >>> libraries involved. >>> >>> I would stick with DPXs. >>> >>> -Nathan >>> >>> >>> *From:* John Coldrick <[email protected]> >>> *Sent:* Thursday, September 18, 2014 3:01 PM >>> *To:* Nuke user discussion <[email protected]> >>> *Subject:* [Nuke-users] R3D "Live" source plates in Nuke >>> >>> In the past we had experimented using quicktime files directly in Nuke >>> as source plates and it was pretty much a disaster, unstable, inexplicitly >>> slow at times, and checking around that was a concession from a number of >>> shops. Fine in theory, seemed OK, but inevitably when you got to a real >>> shot, trouble. >>> >>> I'm just curious if anyone has had any experience with using R3D files >>> like this. We'd be working at 4K from a Red Dragon, I'm thinking on the >>> plus side the compression would make for faster interaction, but >>> potentially on the negative side some of the snappy scanline efficiencies >>> might be lost, and of course, stability is key. I've also noticed that the >>> firmware in the camera can be a real issue in getting successful reads in >>> Nuke, so there's a thing... >>> >>> We're going to do some testing, but just curious if anyone had any war >>> stories. >>> >>> 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
