View topic - Tone mapping awareness-raising thread

Tone mapping awareness-raising thread

General discussion on lighting, backgrounds, Global Illumination, rendering parameters and tonnemapping.

Tone mapping awareness-raising thread

Post Tue Mar 17, 2009 9:34 pm

An option is included in the QT render output windows to save your images using a high dynamic range format (EXR). The aim of this feature is to perform post processing operations such as tone mapping using the High Dynamic Range (HDR) of the image. Some ideas about tone mapping:

  • YafaRay always works internally using high dynamic range and color depth, which means that it works more according with the human eye. The colors you see on display are only a limited part of the colors and luminance YafaRay has calculated for a given render. This is true for most raytracers.
  • This extra range & color depth can not be stored using 8-bits file formats (bmp, png, jpg, etc).
  • Many post processing operations like gamma correction, saturation or brightness & contrast are gamma-destructive, because factors in such operations can be only aproximated or the destination value does not exist (out of range). This is particularly true when using 8-bits color.
  • Tone mapping is a technique to approximate the appearance of high dynamic range images with a more limited dynamic range. With tone mapping, you can choose a mood for your renders from the full range of colors YafaRay is able to produce.
  • The 'Exposure' control in the old YafRay 009 was in fact a tone mapping control.
  • You can perform the output Gamma correction as a post processing step as well. Gamma correction is a technique to transform linear RGB values into video signal values.
  • By using EXR, you can perform these operations without destroying image data. Apart from exposure, tone mapping filters allow for other interesting operations, such as saturation control, brightness & contrast controls, noise reduction, chromatic and light adaptation (white balance), etc.

At the moment we don't have implemented any tonemapping filter in YafaRay, although it is a planned feature. I would like to recommend QTpfsgui for post processing operations on your HDR render:

http://qtpfsgui.sourceforge.net/

Use this thread to post your tone mapping experiments, questions and experiences, please.
Last edited by Samo on Sat Mar 21, 2009 1:48 pm, edited 1 time in total.
User avatar
Samo
 
Posts: 3092
Joined: Tue Dec 20, 2005 10:39 am
Location: Spain

Post Thu Mar 19, 2009 2:41 pm

I would like to learn more about qtpfsgui workflow. :)

I tried playing around with the program a while ago to do some exposure control on an image, but got scared off after not getting decent results. But having seen this thread I dusted off the old exr file and had another go at it. The image I played with is from an old wip project (unfinished):

Image

I wanted to generally brighten the image and improve light attenuation (like under the round table by the fireplace), and maybe try to tone down the blown out reflections on the table tops. I had the most success with Reinhard '05 (pre tone mapping gamma 0.7, brightness 1.5, chromatic adaptation 0.5, light adaptation 0.75):

Image

This brightened the image okay I guess, but I think something got messed up with the contrast between light and shadow. The scene really needs to be rerendered with a tweaked lighting setup, but for now I was just playing with the old image as it was.

I also liked other algorithms (like Durand), but not as much as Reinhard 'O5.

One question: when rendering the exr I assumed I had to disable "clamp RGB" to get the full dynamic range, is that correct? I generally leave this on since the Mitchell AA filter seems to have trouble in high contrast areas (like in the images above).

Anyway, I'd like to see yafaray get its own tone mapping someday. I actually miss old yafray's exposure control.
User avatar
wizofboz
 
Posts: 235
Joined: Tue Sep 16, 2008 7:00 pm

Post Fri Mar 20, 2009 10:24 am

This is what I get playing with one of the Gabich's scenes.


Image

On the left is the scene original render, on the right I have used reinhard05: pregamma 2.2, brightness -5, max. cromatic adaptation, light adaptation 0.30.

reinhard 05, which simulates photoreceptor adaptation to lighting conditions, like that of the human eye, is probably the most useful filter for simple tonemapping operations. I believe the best practice is to save always EXR+PNG of each scene, like modern DSLR cameras can save RAW+JPG.
User avatar
Samo
 
Posts: 3092
Joined: Tue Dec 20, 2005 10:39 am
Location: Spain

Post Sat Mar 21, 2009 1:39 pm

One question: when rendering the exr I assumed I had to disable "clamp RGB" to get the full dynamic range, is that correct? I generally leave this on since the Mitchell AA filter seems to have trouble in high contrast areas (like in the images above).


well, that's an interesting question.

In theory, when you save your renders using EXR, you might or might not use more dynamic range than by using 8-bits PNG, but you always use more color depth. Let me explain this with an image:
Image

This is an over lit version of the kronos scene, and below is the 8-bit PNG histogram, notice how the histogram is cut on the left and there is some missing range:

Image

The first advantange of using EXR is that you get that missing range, and you can work with it. This is the histogram in QTpfsgui:
Image

Anyway, the low dynamic range of a 8-bit format could be enough for a well lit scene without any glowing surface, the dynamic range of that scene falls into the available range of either LHR or HDR formats. The difference is that with HDR you have always more color depth for a given range, which means that you can process images with more precission and without destroying gamma.

When you save your images with clampRGB enabled, you use less dynamic range, no matter what format is used to save the render in. But if you use EXR to save a clampRGB render, you have always more color depth.

and now a theory for you to chew on: using clampRGB+EXR would be better than clampRGB disabled+EXR, since with the former method you can reach the range of the later by tone mapping, while keeping the AA benefits of clampRGB.

what do you think? :P
Last edited by Samo on Sat Mar 21, 2009 6:08 pm, edited 2 times in total.
User avatar
Samo
 
Posts: 3092
Joined: Tue Dec 20, 2005 10:39 am
Location: Spain

Post Sat Mar 21, 2009 4:14 pm

Thanks for your thoughts about this.

and now a theory for you to chew on: using clampRGB+EXR would be better than clampRGB disabled+EXR, since with the former method you can reach the range of the later by tone mapping, while keeping the AA benefits of clampRGB.


Maybe there's something I don't understand, but I disagree with this.

I have attempted to reproduce your overlit version of the Kronos lightbulb scene:

Image

I rendered and saved two exr versions of this scene, one with clampRGB enabled and one with it disabled. The yafaray rendered output of both versions were of course very similar to the image above. However when I loaded both exr files into qtpfsgui there were immediate differences:

Image

The nonclamped exr has a nice well-controlled exposure while the clamped one is ugly and blown out. Looking at the histograms above both images it looks like the clamped exr is clipped at the right where the nonclamped version has additional information. And finally it is impossible to tone-map the clamped exr to get rid of the blown out areas even at minimum brightness settings:

Image

But the unclamped exr behaves nicely:

Image

So I conclude that using the clampRGB option loses information in the resulting exr file. But hopefully you can show me to be totally wrong so I can use clampRGB again. :D


BTW I am now reading the research paper that the qtpfsgui Reinhard '05 algorithm originated, and I'm learning more about the function of the parameters and especially what the paper considers to be sane values for those parameters. If you want I could post a summary of this information for others to go by. In case you don't already know, the paper is available here:

http://www.cs.ucf.edu/~reinhard/pubs.html
(under 2005 third one down)

Thanks for looking at all this. :)
User avatar
wizofboz
 
Posts: 235
Joined: Tue Sep 16, 2008 7:00 pm

Post Sat Mar 21, 2009 6:30 pm

Image

Ok if you look at your screenshot:
- The render on the left is the 'normal' render, range is from -1 aprox. to +0.4 (horizontal bar on the top, green range)
- The render on the right is the clampRGB render, range goes from -1 to +0.1 aprox, therefore less range.

The fact that you see it different has more to do with the viewer application than with the files, the app. tries to tone map the EXR files so you can see them on your LHR monitor. If there is more range then the EXR file is mapped differently, in fact you can move that bar and map a different portion of the available range and get similar results.

So I conclude that using the clampRGB option loses information in the resulting exr file. But hopefully you can show me to be totally wrong so I can use clampRGB again. :D


Yes, when clampRGB is enabled because your render has poor AA in fast high-contrast changes, some range is lost but you have better antialiasing, and that's independent from the output format you want to use.

However, if you use EXR for your 'clamped' render, you have more color depth. Then, you can tone map this 'clamped' render and give it more range, as in a normal render, while keeping the better antialiasing.

The aim of this is to overcome the fact that clampRBG produces better antialiasing in fast high-contrast changes, but duller renders, There is an excellent example here:
http://www.yafray.org/forum/viewtopic.php?p=6598#6598

Anyway it is just a theory I have to prove true. I'm glad you are interested in this topic.
User avatar
Samo
 
Posts: 3092
Joined: Tue Dec 20, 2005 10:39 am
Location: Spain

Re: Tone mapping awareness-raising thread

Post Thu Apr 02, 2009 10:23 am

Hi, thanks for the infos.
I thought yafaray had some kind of internal/automatic tonemapping feature ..because i find easier to get well exposed images compared to other renderers...Can we say that actually yafaray uses a linear tonemapping ?

Anyway, I'm a big fan of qtpfsgui, i'm learning it, and i found useful to distinguish two parts of tonemap:
-exposure and balance control , managing the hdr range using Reinhard or simply exponential tonemap or even simpler curves. (i'd love to see realtime curves in the gui like vray)
Theese are the kinds of tonemap usually integrated in renderers.

-local adaptation : like Mantiuk and Fattal filters. Theese are much slower (even 10mins for an 1080p still) and can give funky-pictorial results , because they take into account not only the pixel color values themselves , but also the intensity of surrounding pixels .
i find this filters very useful, but more suited for postprocessing (i'd love to see them in blender node editor !)
I'm not sure if Reinhart filter does some local adaptation , surely not as much as fattal.

I use qtpfsgui mainly for the local contrast adaptation part, results are often extreme ,but once blended subtly with the original render they do a great job in controlling under/over exposed areas..

One big note about qtpfsgui ! if you import a normal srgb image (like yafaray with output gamma 2.2) be sure to "explain it " to the program by setting "pregamma" slider to 0.4545 , in the tonemap window.
It is important to do all tonemapping filters in linear space , by doing "pregamma 0.45" you make your srgb image back to linear , then all filters work much better, (and the output ldr are still normal srgb images)

edit: In the viewer window ,instead, when you load an hdr render with normal srgb gamma it will look washed out .
The gamma dropdown menu will say "gamma 2.2" why ? because usually hdr are saved as linear and require a "gamma 2.2" correction to look right on monitors.
Saving your render as srgb is fine (gamma operations aren't destructive on hdr files), but , to display it correctly in qtpfsgui viewer , you must select "linear" : this means "do no correction" and doesn't mean that your render has linear (1.0) gamma !
Also, this viewer thing has no effect on tonemap window , it's just preview display.

I hope this is useful, and please correct me if i said anything wrong !
Last edited by nizu on Tue Apr 07, 2009 7:58 pm, edited 2 times in total.
User avatar
nizu
 
Posts: 24
Joined: Fri Mar 13, 2009 10:17 am
Location: Torino , Italy

Re: Tone mapping awareness-raising thread

Post Thu Apr 02, 2009 2:23 pm

About the ClampRGB discussion. My understanding is that samo is right, it has a partial effect to tonemap an hdri that has been rendered with the tonemap setting. However, I am not sure why you would want to do this. For me at least, the length of time a render takes is set by how smooth I can get the noise in the scene. If this is the case you lose no time by rendering a 4x or even 16x image to a lower image quality, then tonemapping, then using some 2d image software to shrink the image to the desired size. This will get right of bad jaggies and will allow full use of tonemapping, (Which is absolutely necessary).
loh
 
Posts: 250
Joined: Sat Sep 20, 2008 3:22 am

Re: Tone mapping awareness-raising thread

Post Fri Aug 21, 2009 3:03 pm

One question I have is whether the EXR image must be saved with gamma 2.2 or gamma 1.0.
I get correct a pre tone mapping gamma using 1.0 ouput in YafaRay, and later giving it a 2.2 gamma in qtpfsgui.

What's your experience in that regrad guys?
User avatar
Samo
 
Posts: 3092
Joined: Tue Dec 20, 2005 10:39 am
Location: Spain

Re: Tone mapping awareness-raising thread

Post Fri Aug 21, 2009 7:47 pm

Hi,
afaik the yafaray output can be either .
Gamma 1.0 : i saw suggested in tutorials , as teoric standard for hdr images , it leaves the pic as a 'natural' linear image , then you must look at the image through a 'lut' (any app with software gamma correction , 'color proofing' is the same thing , i guess)
gamma 2.2 : doesn't change image quality (afaik) . Pic looks right on monitors , no need for software color correction , like in blender node editor this way you don't need a gamma correction node to display it correctly.

I use output gamma 2.2 , this way i make less confusion in further editing .
However i read that gamma output 1.0 is a standard in big studios as compositing people are used to linear images as input to compositing apps.

Then in qtpfsgui i use display gamma 1.0 , pregamma of 0.4545 (in tonemapping panel)
The correct value combinations are : (afaik, again :) )

yafaray output -> qtpfsgui display window "gamma" - qtpfsgui tonemap panel "pregamma" -
1.0 -> 2.2 - 1.0 -
2.2 -> 1.0 - 0.4545 -

Note that another variable in displaying hdrs are black point and white point : qtpfsgui viewer offers a small histogram display (green) and the blue bar sets black/white points .
I can't see a standard or rule : can be a fixed range (-1 , 0) , or range can be given by the darkest and brightest pixel values ..depends on the app.

(btw .. i just noticed that durand tonemapper is broken in qtpfsgui 1.9.3 , i advertised this algorythm as very useful .. but try it in 1.9.2 or earlier )
User avatar
nizu
 
Posts: 24
Joined: Fri Mar 13, 2009 10:17 am
Location: Torino , Italy

Re: Tone mapping awareness-raising thread

Post Sat Aug 22, 2009 5:51 am

Hi Nizu, thanks for your answer:

yafaray output -> qtpfsgui display window "gamma" - qtpfsgui tonemap panel "pregamma"
1.0 -> 2.2 - 1.0
2.2 -> 1.0 - 0.4545


I agree with the first and second values, after some test I have reached the same opinion.

However the third value means that you are tonne mapping your image without any kind of device 'pre gamma', which results in a darker image to tone up. I'm not saying it's wrong and in fact it leads to interesting images with more contrast. However it produces different results than if you start with a device 'pre gamma' applied, like this:

1.0 -> 2.2 - 2.2
2.2 -> 1.0 - 1.0

I wonder if it is a standar technique to tonemap an image which is still in the linear space, without any kind of 'device gamma' applied before. Have you any link or reference about this technique?

I wonder if, in this case, you have to tone map the image to reach a correct level of exposure so you don't need to use adjust levels tool, or users should use a combination of tone mapping and adjusting levels = 2.2 to get a correct result.
User avatar
Samo
 
Posts: 3092
Joined: Tue Dec 20, 2005 10:39 am
Location: Spain

Re: Tone mapping awareness-raising thread

Post Sat Aug 22, 2009 10:32 am

Hi,
unfortunately i haven't a clear reference for the use of 'pregamma' ..those values i suggested come from experiments : with output 2.2 and pregamma 1.0 some operators like durand give very strange results , some (reinhart) just give different brightness.
However i think it's correct to say that :
-tonemapper operators are supposed to work on linear images : hdrs assembled from cameras are linear ,and .RAW photos too.
(cameras shoot a 'raw' linear pic , then they apply a gamma curve specific to the camera model but always meant for srgb monitors , then save the result as ldr jpegs)

If you have an hdr saved with gamma 2.2 (possible with cg render) using pregamma 0.4545 converts it back to linear. before sending it to tonemapper.

-LDR output is always supposed to be srgb (gamma 2.2) : i don't think there's any need to specify output gamma in tonemapper.
Adjusting levels is always useful , but just as 'fine tuning' and the gamma value there is to be used as levels control (to tweak the 50% value level )

This is just my guess, but based on the fact that ldr have limited range , so gamma 2.2 is always used because it makes the best use of that limited range (gamma 2.2 means having more precise brightness 'steps' in midtones , just like human eye does) the only exception are bumpmaps where brightness means 'height' and can be linear.
User avatar
nizu
 
Posts: 24
Joined: Fri Mar 13, 2009 10:17 am
Location: Torino , Italy

Re: Tone mapping awareness-raising thread

Post Tue Aug 25, 2009 10:24 pm

Hi Nizu, thanks for the answer, I'm gathering some information about it, so the user's guide is more complete in that regard.

I can see the logic in your answer.
User avatar
Samo
 
Posts: 3092
Joined: Tue Dec 20, 2005 10:39 am
Location: Spain

Re: Tone mapping awareness-raising thread

Post Wed Aug 26, 2009 4:48 pm

I'm glad to be of help , looking forward to see the documentation,

Indeed , there aren't a lot of certain sources so it's hard to be sure or have proofs.. i had not considered the possibility of gamma correction on ldr output before ... various things suggest it's not necessary but i haven't found confirmation on any source (most available info on qtpfsgui is on photography forums ..i think real photo miss some variables of cg renders gamma workflow )

Also , i said i found easier to output 2.2 gamma hdrs .. maybe it's not a good idea , as it can create confusion .
Gamma 2.2 hdrs don't require a LUT to be viewed , ok, but will likely require to change default settings in apps that (fully) support hdr.. example : blender node editor requires to add a gamma node to display linear hdrs (acting as LUT) while Qtpfsgui defaults (display gamma and pregamma) are meant for linear hdrs.
User avatar
nizu
 
Posts: 24
Joined: Fri Mar 13, 2009 10:17 am
Location: Torino , Italy

Re: Tone mapping awareness-raising thread

Post Thu Aug 27, 2009 8:05 am

Nizu,

I agree with your Pre Gamma workflow, it produces a more consistent contrast and better colors. However, I have discovered that using the Adjust Levels tool on an already tonemapped image is a gamma-destructive operation, check the histogram in an image editor.

So I believe that any basic gamma correction operation should be done not with the Adjust levels tool, but with the Pre Gamma tool, taking as a starting point always the linear HDR render, as you suggest.

Also it is a bit redundant suggesting that uses should output yafaray renders with Gamma 1.0, because then they lost a bit of control over the final result, unless they output two versions of the final render. So I believe that the best workflow is:

YafaRay Gamma ouput= 2.2 -> QTpfsgui HDRI visualisation window= 1.0 (linear) -> QTpfsgui Tonemapping Pre Gamma= 0.4545* -> Tonemapping

*making small up and down adjustements in the 0.4545 Pre Gamma value is possible, to adjust render gamma as desired, in conjunction with tonemapping adjustements.
User avatar
Samo
 
Posts: 3092
Joined: Tue Dec 20, 2005 10:39 am
Location: Spain

Next

Return to Lighting and Rendering



Who is online

Users browsing this forum: No registered users and 2 guests

cron