Nuke/Vray exr float info

[m_hinks]

Hi,

We've recently starting using Nuke for post production on animations, and using exr's straight from vray. We save the exr's with all required elements through the VFB and the raw image file section, simply adding .exr not Vrimg.

I want to know what setting the exr is saved as. 16 or 32 float? Can/will save options be added for this section? I only ask as I've been advised 16 float will be more than enough info to use in nuke, and 32 bit will be over kill.

Nuke is working out very well, and would reommend it to all. I know some people on here use it daily. Does anyone have any tips or tricks for the vray/nuke combination?

Thanks

Mark

[Shimakaze]

When saving as a raw exr image that way it'll be saved as 16 bit half float.

[instinct]

To be able to provide the same memory saving advantage as vrimg (saving by bucket and not holding the whole image in memory) vray saves to tiled exr images. These are a lot slower to load. So rewriting them out of nuke to make them scanline based images will give you better performance.

Regards,
Thorsten

[vlado]

You can control whether they are saved as 16- or 32-bits with the output_rawExrUseHalf propery of the renderer from MaxScript. By default this is off and the file is saved as 32-bit.

Best regards,
Vlado

[Shimakaze]

You can control whether they are saved as 16- or 32-bits with the output_rawExrUseHalf propery of the renderer from MaxScript. By default this is off and the file is saved as 32-bit.

Best regards,
Vlado

For me it's always saved 16 bit by default

[vlado]

Ah, my mistake -the default is "on", so 16-bit it is. If you turn this off though, you should get a 32-bit file.

Best regards,
Vlado

[m_hinks]

To be able to provide the same memory saving advantage as vrimg (saving by bucket and not holding the whole image in memory) vray saves to tiled exr images. These are a lot slower to load. So rewriting them out of nuke to make them scanline based images will give you better performance.

Regards,
Thorsten

Ok, thats a good tip, thanks Thorsten. And thanks Vlado for clearing up that the exr's are getting saved as 16 bit-half float.

Ill look at rewriting them out next time im in Nuke! Is there a good setting to use, or will it be obvious?!

Vlado, can there be control of the exr as to which compression it uses, or are we stuck with the current so they can be saved tiled? Could we use the save dialog below, the element section to save a single exr, I notice you get all the settings, and will it store all the element?

Thanks

[m_hinks]

Thorsten, I'm just coming back to this subject, and Im not sure which Zip scanline compression to re-compress the vray .exr's as, 1 or 16?

Also, is it best to keep them as 16 bit float, as this is what the native .exr is from vray, as vlado said earlier?

Many thanks,

[Sushidelic]

Hi!
Right now we're recompressing the tiled multilayer halffloat exr's from Vray to 1 scanline halffloat multilayer in nuke, then they decode about 5 times faster (in nuke).

Best regards,
Michael

EDIT: Natively, vray renders are always 32 bit internally. But till now we didn't encounter a situation where a difference between 16bit and 32bit was visible - so imho stay at 16bit and save disk space and network speed, it's far enough usually.

[sv]

over on vfxtalk there has been some interesting discussions about this, where people are saying it's more to do with the compression Vray RAW image uses to save the files that affects Nuke's performance, rather than the tile / scanline saving. Can anyone confirm this?

VRay being bucket-based and nuke being scanline-based will have zero effect on your system performance. Once the images are rendered, they're images, regardless of how they were created.

Things that WILL affect performance are file format, bit depth, and compression scheme. I have had a lot of success using VRay with Nuke in the past, and I can't see any reason you would have problems. Just load up on RAM, fast multitcore CPUs, and fast storage of some kind, and you'll be golden.

...

it really depends on the compression used in the exrs.
Blocks are usually slower to decompress in to memory but takes less space on the drive, and the same can be said for wavelets and stuff..
I'd research over the method of compression avalaible in exrs if i were you.
Render is something that is rendering. Once the image has been saved to disk the method of rendering is ininfluent, only the compression used to store matters.

If that weren't true you'd probably comp faster with images rendered by renderman compared to those done by mental ray, you can see it's quite silly

...

However, I'm still not totally convinced the difference between the two is due to an actual image difference created by buckets vs. scanlines. I think it's more a compression issue.

Some of the EXR compression schemes use scanlines (namely, the .vrimg2exr converter default), so the compressed images that come from the converter are already optimized for nuke's loader.

In contrast, writing EXR's directly from the VRay framebuffer results in fully uncompressed images. This, I imagine, is due to 1) the images not necessarily being written sequentially, 2) the images not being written in scanlines, and 3) the images not being compiled all at once. This could definitely result in the slowdown people are seeing in nuke, since they are having to stream much more data to view their images, instead of streaming a compressed image and letting the CPU decompress it on the fly.


In my experience it does work better to write to .exr and convert in Nuke, rather than writing to .vrimg and converting using the script - but this is just personal preference and the Vray2Exr is a great, great tool - thanks Vlado & Chaos.

[vlado]

Actually someone explained to me that Nuke processes images in scanlines, which is why scanline OpenEXR files are so much faster than tile-based. I have not specifically made tests to see what is the difference in performance though.

Best regards,
Vlado

[instinct]

The difference is real, and there IS a technical difference between tilebased and scanlinebased images that DOES affect performance. You can blindly request scanlines in a scanlinebased image. Where in a tilebased EXR tiles do not have to be in any specific order. Hence the EXR Libs have to find all tiles belonging to a requested scanline and grab them.

Regards,
Thorsten

[sv]

ah, makes perfect sense...

[m_hinks]

So would you agree that re-compressing the vray exr's to 1 scanline exr's is the best method for performance?

Thanks, very interesting

[instinct]

yup, no matter how you are doing it, it helps tons. Also helps with stability esp. with big images in nuke. at least on 32bit systems.

Regards,
Thorsten