PDA

View Full Version : Render to .exr equals bad aliasing?


visua
09-25-2007, 10:43 AM
Okey here's an issue that I just can't get my head around,
playin with Dagon's scene rendering out an .exr (32x4) with
batchrender. FB gamma 1 to keep things linear (prev conv tiles and prev tonemap
tiles set to off), opening the file in photoshop and setting the gamma to 2,2 and adjusting the exposure so everything looks nice.

And I get these weird aliasing-artefacts around the window/opening? I've tried just about
everything I could think of, and the render looks just fine in renderview but when I
batch to float that ugly aliasing is there once again. Maybe it has somethin to do with the alpha since I've yet haven't manage to get the pysical sky to show up in batch. But if that's the case it should just affect the spheres against the black bg and not that upper window frame? I'm clueless...

http://www.nicz.net/daExr.png

mr Bob
09-25-2007, 11:04 PM
Hey there , do you fancy posting up your scene file , so we can have a look. I just rendered out some 32bit z depth passes as .exr files and they were fine.

B

noxy
09-26-2007, 12:19 AM
It looks like an unpremultiplied edge. If you bring it into a compositor, does it still look bad? Or rather, does the alpha look aliased as well?

Noxy

MasterZap
09-26-2007, 07:30 AM
This is actually completely "normal", although for most people, unexpected.

As a matter of fact, this effect happens in real life with real (digital) cameras too.

Here's the thing; Anti-aliasing is done by blending some subpixel samples.

Imagine a window, whose edge covers one quarter (1/4) of some pixel.

If we are rendering in low-dynamic range (i.e. not to floating point), mental ray clips each rays color to 1.0 (i.e. "white") *before* filtering.

This means that no matter HOW bright the window was (1.0, 10.0, 100.0 or 1000000.0) the ray gets clipped to 1.0 (white) and THEN blended with it's neigbours.

So for our example with a window that covers 1/4 of a pixel, the result is a 25% gray pixel, which is what you would expect for an anti-aliased white pixel covered to 25%.

However, in floating point rendering there is no clipping happening.

So if the intensity of the window was 10.0, and it covers 25% of the pixel, this is still a total intensity of 2.5 ... whiter than white (but still rendered on your screen as a "white pixel"! This is no less white than the "white" pixel that results from a pixel that is fully covered by the window. Even a pixel only covered 10% by the window still ends up "white". Yet the wall pixel beside it (covered 0% by the window) is dark. I.e. any pixel that even "touches" the window is full white. You get aliasing!

And this is completely normal. As a matter of fact, if you change the exposure in your HDR viewer you will see that when you get to the point where the window stops blowing out, your anti-aliasing comes back!

And yes, this would happen to a superbright pixel also in a real digital camera. However, intra-pixel bleed and glare tends to cover this up, it can sometimes be evident in a photographed image.

So... how do you get around it?

Well, there are two basic fixes:

a) Do what reality would do, and cover up the effect with glare.

In a real optical system, such superbrights would spill onto neighbouring pixels due to lateral scattering in the imaging surface (film, ccd, or retina of eye) or scattering inside the optical path (lenses, the optical goo inside the eye) and - to a much lesser extent and much less than people think - scattering in the atmosphere.

There are numerous shaders and tools to do this, from "glow" filters in photoshop, the Lume "Glare" shader that ships with max, Maya Glow, etc. etc. that all "does the job"... pick one. Use it. Enjoy.

b) Intentionally "pre-clamp" the rays before filtering with a lens shader.

This is the "best" way in the sense that it gives you your anti-aliasing back. However, be aware that this pretty much precludes you from doing any major exposure changes in post production, so you must already know that the exposure you have in your image is "ok" for how you plan to use it. I.e. the operation you do will pretty much keep blown-out things pegged as "white", and you will kill any detail in the overexposed region by doing so.

The problem with this is that doing the exposure in post is one of the main reasons of rendering to float in the first place! So it's a double-edged sword.

Anyway, there are multiple shaders to do this: One is the simple mib_lens_clamp shader which... well... just clamps. Duh.

A "nicer" and "more gentle" method is to use the mia_exposure_simple shader, which has a bit of control allowing you to do a "gentle clamp" (with the help of the "compression" feature), or the new mia_exposure_photographic (which does it's "gentle clamping" with the help of the "highlights_burn" paremeter). In either case use them in a "gamma=1" mode to keep the result in scene-reffered linear space (but "gently clamped"), since - I'm hoping - you are applying your display gamma in some later display step.


/Z

avinashlobo
09-26-2007, 08:25 AM
Thanks a lot for the detailed explanation. I think a 32-bit-aware Glow filter is the way to go here. Simple, effective and realistic.

visua
09-26-2007, 10:46 AM
You're the man Zap, thank you for the very thorough explanation!
I've been using the mia_exposure_simple so far, but now I'd like to tonemap
my renders in post for enhanced control.

Btw, do you know some nifty trick to include the physical sky in the float-render?
Since it's an environment it has no alpha and I can't get it to "stick"...

//NIC


This is actually completely "normal", although for most people, unexpected.

As a matter of fact, this effect happens in real life with real (digital) cameras too.

Here's the thing; Anti-aliasing is done by blending some subpixel samples.

Imagine a window, whose edge covers one quarter (1/4) of some pixel.

If we are rendering in low-dynamic range (i.e. not to floating point), mental ray clips each rays color to 1.0 (i.e. "white") *before* filtering.

This means that no matter HOW bright the window was (1.0, 10.0, 100.0 or 1000000.0) the ray gets clipped to 1.0 (white) and THEN blended with it's neigbours.

So for our example with a window that covers 1/4 of a pixel, the result is a 25% gray pixel, which is what you would expect for an anti-aliased white pixel covered to 25%.

However, in floating point rendering there is no clipping happening.

So if the intensity of the window was 10.0, and it covers 25% of the pixel, this is still a total intensity of 2.5 ... whiter than white (but still rendered on your screen as a "white pixel"! This is no less white than the "white" pixel that results from a pixel that is fully covered by the window. Even a pixel only covered 10% by the window still ends up "white". Yet the wall pixel beside it (covered 0% by the window) is dark. I.e. any pixel that even "touches" the window is full white. You get aliasing!

And this is completely normal. As a matter of fact, if you change the exposure in your HDR viewer you will see that when you get to the point where the window stops blowing out, your anti-aliasing comes back!

And yes, this would happen to a superbright pixel also in a real digital camera. However, intra-pixel bleed and glare tends to cover this up, it can sometimes be evident in a photographed image.

So... how do you get around it?

Well, there are two basic fixes:

a) Do what reality would do, and cover up the effect with glare.

In a real optical system, such superbrights would spill onto neighbouring pixels due to lateral scattering in the imaging surface (film, ccd, or retina of eye) or scattering inside the optical path (lenses, the optical goo inside the eye) and - to a much lesser extent and much less than people think - scattering in the atmosphere.

There are numerous shaders and tools to do this, from "glow" filters in photoshop, the Lume "Glare" shader that ships with max, Maya Glow, etc. etc. that all "does the job"... pick one. Use it. Enjoy.

b) Intentionally "pre-clamp" the rays before filtering with a lens shader.

This is the "best" way in the sense that it gives you your anti-aliasing back. However, be aware that this pretty much precludes you from doing any major exposure changes in post production, so you must already know that the exposure you have in your image is "ok" for how you plan to use it. I.e. the operation you do will pretty much keep blown-out things pegged as "white", and you will kill any detail in the overexposed region by doing so.

The problem with this is that doing the exposure in post is one of the main reasons of rendering to float in the first place! So it's a double-edged sword.

Anyway, there are multiple shaders to do this: One is the simple mib_lens_clamp shader which... well... just clamps. Duh.

A "nicer" and "more gentle" method is to use the mia_exposure_simple shader, which has a bit of control allowing you to do a "gentle clamp" (with the help of the "compression" feature), or the new mia_exposure_photographic (which does it's "gentle clamping" with the help of the "highlights_burn" paremeter). In either case use them in a "gamma=1" mode to keep the result in scene-reffered linear space (but "gently clamped"), since - I'm hoping - you are applying your display gamma in some later display step.


/Z

Kako
09-26-2007, 04:34 PM
So, MasterZap, see if I got it right. Unless I compress my hdri to the 0-1 range or clip the overbright values to 1 BEFORE filtering, the boundary between an overexposed area and a dark area will always have aliasing? (not considering horizontal and vertical boundary lines, of course :D)

There's another thread regarding fp and AA and you all probably read it, already: 32bit and AA problems in Mental Ray. (http://forums.cgsociety.org/showthread.php?t=228917)

Unfornately, the images Dagon posted aren't there anymore. So I'm not completely sure that's the same issue. Anyway... Reading that thread made me think that I could render an hdri without aliasing between overexposed and dark areas. But, was that problem really solved? Cause I can't stop having aliasing in my fp exr's, and maybe MasterZap just explained why.

In that thread was suggested that we could render through the renderview and then get the exr in the images/temp folder. This file is really an anti-aliased exr and for a moment I thought my problems were gone. However, it looks like the values are clamped to 1 before the file is written! So that would be a fp file with clamped values. :rolleyes: Rendering through batch render will still give me aliasing artifacts, as rygoody also mentioned there.

I'll see if I post some images later regarding this.

Kako.

MasterZap
09-27-2007, 10:38 AM
So, MasterZap, see if I got it right. Unless I compress my hdri to the 0-1 range or clip the overbright values to 1 BEFORE filtering, the boundary between an overexposed area and a dark area will always have aliasing? (not considering horizontal and vertical boundary lines, of course :D)


You needen't compress it strictly to a 0-1 range, but the more you really allow each ray to be above-the-color-that-will-be-white-in-your-final-pixel, the larger risk you run of getting visible aliasing due to that color "taking over" the pixel color in the filtering.

You can still retain some overbrightness, and still get "ok" aliasing. You can, for example, set your "knee" in mia_exposure_simple to 2.0! This will only start "compressing" at level 2... leaving you some leeway in post for adjustment, but still getting "ok anti-aliasing"

This is exactly the reason why it is actually beneficial to do your tone-mapping on a per-ray basis (i.e. in a lens shader) rather than in a post effect (like an output shader, or an external tool); only the in-render per-ray tone mapping (done in a lens shader) solves all those issues with aliasing.

And if you want the interactive tweaking, you can always

- save a roughg EXR with no exposure plugin at all
- use that EXR in the "preview slot" and enable "Use Preview"
- tweak till "She's got the look"
- turn of "Use Preview" do the "real" render with the tonemapper as lens shader

This process is kind of demonstrated at the end of this Maya demo video (http://download.autodesk.com/us/maya/videos/7_mk8_web_Render_2.mov)

/Z

Kako
09-27-2007, 09:31 PM
Thanks again for your attention, MasterZap!
All understood.
Loved the mia_exposure_photographic, by the way. Perfect and easy as it should be.

Kako.

CGTalk Moderation
09-27-2007, 09:31 PM
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.