Nuke : More efficient on png or tif sequences?

[Junx]

Hello,

Does anyone know which sequence format Nuke reads more efficiently? PNG or TIF Sequences? Working in 8-bit only....This noob thanks you.

J

[aaronber]

You could do your own tests on your system to see what works best for you.

I have found that PNG takes too long to compress and decompress, while tiff takes a long time to read and write to the hard drive (unless you have fast storage).

I always go with EXR.

[memetemin]

multi layer exr very fast for me

[ringas]

multi layer exr very fast for me

I was doing the same thing up until recently, but then I tried splitting up the layers, using autocrop in the writes, and reading them back in separately....

The difference in speed is immense!!!!

The downside is that now there are a lot more files in the disk, but the cumulative size is rather smaller compared to the initial multilayer EXR.

[pingking]

@Junx:
uncompressed Tiff should be faster then PNG, because png decrompession takes some time and must be done on the whole image. also nuke has to load the whole image before it can work on the scanlines it needs.
with uncompressed tiff nuke should be able to read only the scanlines it needs

@ringas, memetemin:
for most systems seperated layers should be faster to read in and work with, because nuke has only to read the layers it needs. while with multichannel exr nuke has to read all the channels inside the exr even if you only need one. thats not a fault of nuke, its a exr specification.

[peterpearson]

Exactly what pingking said:

EXRs (at least in OpenEXR 1.x - 2.0 will change this) store the channels in an interleaved format so the values for one pixel are stored adjacent to one another for all the channels. This means Nuke has to jump through the data to get the channels if there are a large number of them which has an overhead (both CPU time and disk IO).

Using separate files for the different AOVs is more efficient as Nuke only has to read in the data it's been asked for.

Also make sure the EXRs are stored in scanline mode instead of tile and that you use zip1 compression (or none) - any other settings will cause slowdowns, as Nuke wants scanlines, so if you've got tiled EXRs coming out of a renderer, Nuke has to decompress the entire row of tiles (each one of which is 32x32 pixels) just to get a single scanline of 1x32 per tile, which is really inefficient. With scanline EXRs, Nuke can just decompress the scanline it wants and read that which is *much* faster.

[Gentle Fury]

Both formats are garbage.

You should always work in EXR when you can...since Nuke is actually built around that format. When you build a Nuke script you are actually building a live exr file...that is what you view. Since that is the native format it is the best for input and output. PNG is highly compressed and a terrible format for anything other than web graphics and TIF, while not compressed is clamped and won't allow for values exceeding 1 or 0....which is not a good way to work!

[pingking]

Both formats are garbage.

You should always work in EXR when you can...since Nuke is actually built around that format. When you build a Nuke script you are actually building a live exr file...that is what you view. Since that is the native format it is the best for input and output. PNG is highly compressed and a terrible format for anything other than web graphics and TIF, while not compressed is clamped and won't allow for values exceeding 1 or 0....which is not a good way to work!

thats not true: a tiff file can hold 32bit float values, you can have tiff in 8bit int, 16bit int and 32bit float.

[Gentle Fury]

thats not true: a tiff file can hold 32bit float values, you can have tiff in 8bit int, 16bit int and 32bit float.

32bit is the only non-clamped tif format. And it is NOT a good format.

[Boris28]

Its interesting that with 3ds max you can save a 48 bit uncompressed png file while with Maya you can only save a 16/32 bit I think and no option to uncompress. Exr is the king