Hello Randy and thanks for feedbacks.
> Other wise changing just the width of the ROI wouldn't change redraw
speed.
In the case of Zip1 this make sense as as the line is needed by your
ROI, the whole line need to be loaded. And I guess Nuke only cache the
visible part of the pixels. So change your ROI of few pixels on the left
make Nuke need to reload every line just to uncompress the missing
pixels from the cache.
Am I right on this?
Regards,
Dorian
Le 03/31/2014 05:08 PM, Randy Little a écrit :
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]
<mailto:[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 <tel:%28310%29%20399%204555> - Mobile:
(310) 883 4313
Web: www.thefoundry.co.uk <http://www.thefoundry.co.uk/>
Email: [email protected] <mailto:[email protected]>
On Mon, Mar 31, 2014 at 10:23 AM, Dorian Fevrier
<[email protected]
<mailto:[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]
<mailto:[email protected]>,
http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[email protected]>,http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
[email protected]
<mailto:[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
