AA contrast in underexposed images.

#1

When rendering to 32bit float how does mental ray compute the antialiasing…? Does mental compute the contrast threshold based on a floating point image or the exposured image? I have an underexposed 32bit floating point image that i want to correct in post, do I get poor AA because of the lower contrast in comparison to an image with good exposure? Both images have the exact same rendersettings.

#2

Not a direct answer, but I think there maybe some clues in this article.

I always have these problems with overexposed renders and often wish there was an easy way of applying aa in post, after adjusting exposure.

– David

#3

http://forums.cgsociety.org/showpost.php?p=4672947&postcount=4

#4

Emil3d, I’ve read that thread too and it’s relevant, but I think the problem with aa in an adjusted underexposed image is that you cant hide it using the same kind of tricks. I get the feeling that it is one of those cases where doing the adjustment in a non-linear colorspace may actually give better results in the perceived aa. However I think that the best thing to do is to try and render as close as you can to the exposure you actually need using one of the exposure lens shaders.

– David

#5

djx, I completely agree with you and for me those tricks don’t work for most cases, not just underexposed images. I was in a rush and posted the link without any comment hoping to help with understanding how MR calculates AA, not that I believe in the recommended workarounds.
Here is a good example of the problem with some of my previous classroom rendering tests.
The two images were rendered from an identical scene to 32 bit float file with only one difference; the first image was rendered without an exposure lens shader and tone mapped and color corrected in Photoshop. The second image was rendered with mia_exposure_photographic and then slightly corrected in Photoshop.

     Without exposure lens shader. 
The aliasing is very obvious on some of the legs of the chairs and tables and the top of the window sill. I don't see how this can be fixed with glows or glare. And if rendering for print, which requires high resolution and a heavy dose of sharpening, the problem will become even worse.
    [img]http://i111.photobucket.com/albums/n129/Emil3d/PostTonemapped.jpg[/img]
    
     
     this was rendered with mia_exposure_photographic. The aliasing is not that bad and more acceptable.
    [img]http://i111.photobucket.com/albums/n129/Emil3d/Tonemapped.jpg[/img]
     
     
On another note, based on my experience, I'm never able to match in post the result from rendering with exposure lens shader, it seems that MR is producing images with fundamentally different base. Compare the images above and lets take for example the differences in the grill of the center lights, this is not a tone mapping difference, aside from different color which may be matched with more tweaking, the exposure lens shader also seems to affect the entire balance of reflections and light intensity which is impossible for me to match in post. 
   So, to me, aside from being  more flexible,  rendering to full dynamic range without exposure lens shaderrather is actually a different rendering result which may or may not be better.
#6

aside from different color which may be matched with more tweaking, the exposure lens shader also seems to affect the entire balance of reflections and light intensity which is impossible for me to match in post

I see what you mean. I had not considered this before. Maybe if we render passes and tone map them separately we can get something matching (in theory). However, in practice it always ends up being too much effort to make it worth my while. My work is for tv so I dont need all that control. Tone mapping in the render with a little bit of a tweak in post is generally enough.

Thanks for showing these examples too.

– David

#7

I’ve recently been doing a bunch of learning with gamma, and while my head is killing me i seem to be getting some decent results.

My only concern is that my images, while more saturated, have quite increased contrast. Was wondering if there was a way to step back the contrast, a lot.

scene:
physcial sky/sun with exposure_photographic, gamma 1
framebuffer gamma, .455
mia_portal light

any help would be greatly appreciated

#8

I think the main differences you are seeing is the result of the differences between tonemapping per PIXEL and tonemapping per SAMPLE, which fundamentally gives slighlty different PIXELS.

Imagine 4 samples of intensity 5, 5, 2 and 0.5, and try to cram them into a pixel.

The per-pixel tonemapping would have as input the pixel averaged i.e. something like this

(5+5+2+0.5) / 4  = 3.0625

…i.e. still a “much brighter than 1.0” pixel, that gets tonemapped to something less bright.

Imagine instead if you tonemap the individual samples with some overbright compression, e.g. something like:

5 => 1.1
5 => 1.1
2 => 0.8
0.5 => 0.4

…and then you blend these to a final pixel, you get (1.1+1.1+0.8.0.4) / 4 = 0.85

If perceived contrast increases you are doing something backwards, it’s the non-gamma-corrected images that have too much contrast, the gamma corrected have less contrast.

I.e. a quadratic falloff light, in a non-gamma corrected render, has a big blown out blob, a tiny region of useful light, and then blackness, whereas in proper linear (gamma corrected) color space, it has a soft natural falloff.

/Z

#9

thanks masterzap. i think the issue is that i had conflicting gamma specifics. All the threads and posts on gamma dont really start at the beginning for people who dont understand it, its clearly a bit higher on the knowledge ladder.

most of the info is for rendering to a 32 float image. Which is confusing for people who dont understand it b/c the setup for rendering to 32 Float is for a FINAL RENDER. and gamma settings will change when just trying to see how things appear for a PREVIEW RENDER. I can only assume (hopefully) I am not the first person to have had issues piecing this together.

And of course there is tons of debate on the best workflow, which leads the user to believe there is no golden rule.

working off a 2.2 gamma from the exposure_photographic node, the framebuffer gamma should be at .455. While having its benefits, it cant account for specific textures that need more control, which is where Gamma Control nodes come in. When using these in addition to the already .455 framebuffer, things have become way to dark. Now i believe the answer is an over Gammafication(delicious word!). Bringing the framebuffer gamma back up to 1.0 has begun yielding the results i’d expect.

so it’s safe to say that its either, .455 in the framebuffer, or .455 in the gamma control node.

or i’m an idiot!

#10

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.