Planar HDRI backgrounds

[Roy Hirshkowitz]

Coming soon-- the ability to use planar HDRIs as visibile/refractive backgrounds.  Three parts to this:

 

1. A tool to turn a standard RGB image into HDR by applying an inverse tone mapping operator.  This is not as good as acquiring an HDRI by bracketing and using HDR software to put the thing together-- but it seems to work OK for many applications.
2. The ability to use .hdr files when selecting a WalkAbout background
3. An additional lighting channel to manipulate the background brightness in real time.

It's a little complex-- but I think it may allow for better control than straight alpha compositing.

 

Here's a nighttime example with the background channel multiplier at 1.0 and 5.0:

 

 

And a similar daylight example:

 

 

[qweqwi]

Fantastic Roy ...good job...we are anxious...

[Peter Milner]

Thanks Roy, that will be hugely useful for me.
A few questions:
How bright will the image be able to go?
Does the brightness of the image affect the amount of light coming into the room?
Would it be possible to do something similar with standard jpg images?
Is the image visible in the walkabout view?
Will it be available with cylindrical and spherical mapping as well (for animation)?

Peter

[Roy Hirshkowitz]

Here's the same image using a channel multiplier of 10000.0-- it would get brighter much quicker if I desaturated the image somewhat before converting to HDR.

No lighting when used this way-- no you can't do this w/ standard jpgs-- yes it creates a preview image for WalkAbout viewing-- no animation in this mode.

You can take a spherical bitmap and convert it to hdr as well. This can be used for lighting, or as a background suitable for animation, or both.

[Marc Chaumier]

What does it mean "turn a standard RGB image into HDR by applying an inverse tone mapping operator"?
To make an HDR with a JPG? In this case, this HDR could give the light to the scene??? Or just give an average bleeding of color and brightness?
Even with exterior scenes, will it give an significant advantage?
In any case, it seems to be usefull. Thanks Roy for your "keep the pressure" method of work. ;o)

[Roy Hirshkowitz]

Tone mapping takes luminance and creates RGB colors for display or saving in an image. Inverse tone mapping reverses that equation. nXt's tone operator requires two other pieces of information in order to invert it properly-- the average luminance and the maximum luminance of a scene. The way it works at the moment is that you check Daylight, Night, or Custom. For the custom setting you provide the max and avg lum. This process is nowhere near as good as the standard way of building an HDRI using bracketed photos, but it does seem to recover luminance in an acceptable way.

If you do this with a spherically projected bitmap, yes it can be used for lighting as an HDRI. In this mode you can, of course, reflect the background as well.

Not sure how useful planar HDRIs will be for exteriors-- you'll have to experiment. The colors of the bitmap may move around more than you like.

[Marc Chaumier]

Thanks, Roy, for these explanations, it will be exiting to try it.

[Eric B]

First, Roy this is great given the way AR5 does not like RGB's that have any sort of luminance assigned.

Second, seeing as this will be on yet another channel is good in that the effect can be adjusted to help with the daylight burn in.

Third, just like Marc said above, I am a bit mystified by the whole "turn a standard RGB" into pseudo-HDR. It sounds like I may have to mess around with the controls for a bit to see what they do.

Fourth, Yes the colors of the bitmap may move around a bit, but not too bad even for relatively few passes (like around my typical 25 or so).

Last, would there be a way to have some manner of assumed max and min suggested luminance for a scene so that a User messing around with the Custom settings can start somewhere close to reasonable? Perhaps it could be taken from a test run of Daylight or Night settings.

This goes back to my controls vs. output effect. When I see someone say "you get this on setting 1, and this on setting 5, and this on setting 10000..." I just roll my eyes. Really, setting 10000? Does that mean there is a discernable difference between 9000 and 9005? If so great, if not then why have a setting that can span over such a huge range?

If anything just convert the input into some manner of logarithmic or exponential derivative so that the User does not have to remember that a setting of 7653 is ideal. But that is just a suggestion.