Nathan what is the block size? The entire width? I don' t know for some reason I was under the impression that the array is little blocks of scan lines. Or is it that each block is the entire X ?
Scan Lines For scan line blocks, the line offset table is a sequence of scan line offsets, with one offset per scan line block. In the table, scan line offsets are ordered according to increasing scan line y coordinates. Randy S. Little http://www.rslittle.com/ http://www.imdb.com/name/nm2325729/ On Mon, Mar 31, 2014 at 5:15 PM, Nathan Rusch <[email protected]>wrote: > When using ZIPS with scanline-based EXRs, each scanline is compressed > into its own block within the file, so the library has to read and > decompress the whole line, even if only part of the resulting data is > actually used by Nuke. > > -Nathan > > > *From:* Randy Little <[email protected]> > *Sent:* Monday, March 31, 2014 2:08 PM > *To:* Nuke user discussion <[email protected]> > *Subject:* Re: [Nuke-users] Faster EXR format for Nuke read. > > 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 <%28310%29%20399%204555> - 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 > > > _______________________________________________ > 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
