Noisy render: max/vray frame buffer looks fine but saved images are noisy

[hmercado]

Hello,

I am having a strange render issue with vray RT. When I render the render shows up perfectly clean (noise free) in the vray frame buffer and on the max frame buffer but when I open the rendered image in the ram player or photoshop the image is extremely noisy

As you can see in the attached image the frame buffer (top image) is noise free. The saved images loaded in the ram player(bottom image) is noisy.

Never seen anything like it before; Any idea what would be the problem?
Thank you.

[vlado]

What file format are you saving to?

The RAM player has issues to show gamma-corrected images properly so I wouldn't trust it. What happens if you just "view" the image (in 3ds Max main menu, Render > View image file...)?

Best regards,
Vlado

[^Lele^]

EDIT: i lack reading skills, obviously.

It looks palettized.
What's the format you're saving out of the VFB?

[hmercado]

Thank you,

Yes, I was saving out to tga; never had any issues before with tga.
I saved to png with higher bit depth now and its all good.

Cheers!

[^Lele^]

Go Exr, and become free!

[hmercado]

Thanks,

I tried exr once but compositing in after effects became too slow and buggy so I went back to tgas
Maybe I wasn't doing it right? Would you share some tips?

[^Lele^]

Uhm, not quite specific to AE (haven't used it since version 5. you do NOT want tips on that from me.), nor would I probably be able to state anything which is not in PLENTY of better qualified literature.

But here are some simple things which make ME love working with EXRs, in semi-randomic order:

Their Range : you are not limited to the palette of colors which your monitor can display, as the images can store pretty much ANY value for a pixel, either absurdly small, or absurdly big. I DO mean "Absurdly".

Their Data Type : EXRs are not 8bit, they are 16 or 32 BPC (similar to Tiff, one would think, or PNGs...) but with one important difference, as data isn't stored as integers, but as float of variable precision.
What it really means is that you aren't tied to expressing a brightness which is in the range of 0-255, or 0-65535, and which can vary only by discrete quantities (you can't save a color value of 128.5), but rather you can be as accurate as you need/please.

Their Data Shape and Behaviour : The way EXRs store data has a number of fairly useful repercussions;
* The visible range is normalised (ie. in the 0.0-1.0 range), so one's understanding of a color value is a lot more immediate, in 3d or in post.
* The Maths is simple, and invertible: Within a normalised color (or mathematical, more generally) space, 1.0*0.5 produces the same result as 1.0/2.0.
Try that with the palettized range, and right away the maths gets messy, as 0.5 can't be expressed as integer, so it's either 0 or 1, making the division result wrong, and even if it could be expressed, then the resulting color would have no meaning at all (127.5).
Consider the product above a lighting operation (say, light intensity times surface diffuse value, at a right angle), and then the maths would be 255*128. Which will never return a mid gray pixel.
Raytracers, of course, internally all use floating point numbers, so that's of no concern.
But you clearly could not do relighting in AE if you rendered, and proceeded to comp, in integer space (be it 8 or 16 bits).
However, saving the image in integer mode, and just asking AE to promote the comp to float will surely allow you to do the maths and relighting, but the precision with which colours were calculated by the renderer has been lost at save time, and you will pay the price once AE starts working the maths out.
Remember, in Exr you may not be immediately able to tell what a pixel value is with your eyes alone, either because it's "super-bright" and may need re-exposure to not look white, or because one would not perceive two pixels as being different, while they are but by something very small, like 0.0001 or less.

Their Format Flexibility : as there simply isn't (with the exception of the VRimg format, perhaps) another way to store all your render elements neatly within the one image file, for later reprocessing.
You can save one file per frame, which would include all of the REs you'd need for post, and later choose if you want to split the REs out as single images, or use the image as a single file, and extract the REs from within your Post application (no idea if AE can do this.).
Further, the format is able to store metadata of all sorts, and very efficient image and data windows, useful for instance in render passes, where the screen is mostly empty, and only one small part of it contains data.
The data window allows your Post app to only process the relevant parts, skipping the empty parts of the image entirely (which equates to memory and cpu cycles saves).
EXRs have been extended further for version 2.0, so that now they can contain particularly accurate depth information about the scene (think z-buffer on steroids. I'll be stoned in a public place for this one...), so that you can do all sorts of post wizardry even on volumes like smoke and such, but most importantly you'll be able to comp in depth with high a degree of accuracy and little to no effort at all.
Last but not least, they can be written as tiles.
In V-Ray you can render pretty much any image resolution, without paying the price for the creation and display of the frame buffer, as the renderer will calculate and write out each bucket as it gets done into your EXR image, each bucket an image tile with all the REs one may have added.
As the render is done, you can convert the tiled EXR to a different EXR "flavour" (typically, data organisation changes from tiled to scanline, and data compaction is set to zip-1s) for decode performance reasons, or with EXR2, you can use it directly at a decently low performance cost.

So, what are the issues?
Well, size, especially starting from 8bit images, may look bigger.
In fact, the format sports many a different type of compaction (ie. lossless) which tend to reduce the image sizes to around about what you'd expect from a TGA file, and if the screen is mostly empty, much smaller.
Deep EXRs are a different beast, and can easily reach hundreds and hundreds and hundreds of megabytes if there's plenty of deep data to save (think a fumeFX saved out so that in comp it can be edited volumetrically...)
And perhaps, for the same image, some performance hit in the decode phase (ie. before it gets displayed), again, compared to "flat" formats like TGA (at most, RLE encoded a simple pixel list.). You won't notice much of a difference in the day-to-day with zip1s encoded EXRs, though. Those are blazing fast.
Of course a drawback when you're green to the whole approach has to be the learning curve.
However, you don't need to go dive in at the deep end (pun intended) of EXRs, for most of the benefits are apparent as one chooses the format for saving and comping, and you can get familiar with the nuances of EXRs at a more leisurely pace, while perusing the wide amount of authoritative literature on the internet.

[lightpixel]

for aftereffects and exr´s I am using this helpfull tool... works very well in AE with multichannel exr´s

http://www.fnordware.com/ProEXR/

[Brian Bradley]

Thanks,

I tried exr once but compositing in after effects became too slow and buggy so I went back to tgas

Might want to try using Half Float (16 bit) as opposed to the full float 32 bit variety. Lower file size should help somewhat with the speed.

Bri

[Neilg]

if you switch off the srgb button in the vfb it'll show you what image is being saved - a much, much darker version with different gamma. you run tga or jpg compression on this and then lift it back up, it's been clamped/fucked about with in the dark areas.
Just use exr, or make sure you're saving images in the appropriate gamma (exr is easier, deal with it later)