I don't believe that it has to read the whole line. Other wise changing just the width of the ROI wouldn't change redraw speed. I can't remember but I thought it was discussed before about that very thing.
Randy S. Little http://www.rslittle.com/ http://www.imdb.com/name/nm2325729/ On Mon, Mar 31, 2014 at 4:52 PM, Dorian Fevrier < [email protected]> wrote: > Hi Deke, thanks for feedbacks! > > For now, nothing is write in the stone, that's why I ask for the faster > way to read EXRs. > > Files are located on server. > Nuke version is 8.0v3 > About the number of layer/channels, it depend on your answer. :) I guess > we will have one file per layer and per AOV, so the end files will only > have rgba without any sub layers/channels. > What is the problem with backward compatibility? I didn't get it. Files > write with OpenEXR 1.7 will be slower to open in Nuke 8x? > > I copy paste the problem I see with Zip1 (From my answer to Jeremy): > > > - when you zoom on a part of the image you are working, you need to load > and uncompress the whole line of every file you use to generate it. > - when you unzoom and should only display 1 pixel for 2 or 2 pixel every 3 > (horizontally I mean), it need to load the whole line while only 2 pixels > of 3 are needed. > > And I add: Tell me if I'm wrong but Nuke seems to work with cache more > granularly with NO_COMPRESSION EXRs than any compression method because > cache seems to be generated on the fly only for visible areas while Zip1 > make it need to reload the whole line when another area is needed. > > Regards, > > Dorian > > Le 03/31/2014 03:12 PM, Deke Kincaid a écrit : > > So this depends on a few factors. A few questions first. Where are the > files located(local raid, local disk, or server)? Which version of nuke? > How many layers/channels are you writing? If you are using Nuke 8 can the > file lack backward compatibility (multipart channels written for exr 2.0). > > The reason I ask is on a network Zip1 compressed tend to be best and a > good mix of compression and speed. Locally on a fast fusion io then > uncompressed is actually faster though they take up a lot more space. If > you use lots of channels in a single file then writing the layers as > separate parts are suggested or if the file is all mattes then write each > channel as a separate part. > > -- > 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 Mon, Mar 31, 2014 at 10:23 AM, Dorian Fevrier < > [email protected]> wrote: > >> Hi (again for some of you!) Nuke community! >> >> I try to find the faster EXR formats for the exr Nuke reader in a case of >> a full CG compositing and it's quite hard to get valid informations. >> >> Could someone confirm me this: >> >> One channel per file (RGBA) >> Compression: Imf::NO_COMPRESSION >> Order: Imf::INCREASING_Y (I've never been sure about this) >> A dataWindow well defined. >> >> Have I miss something? >> >> Big thanks in advance and Hello again! >> >> Regards, >> >> Dorian >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > 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
