of course we would like the option of more sophisticated tone mapping algorithims
Is there any developer aware of this? I’m just asking because I didn’t find any of them mentioning it although it seems to be a more basic feature than Volumetrics, Fur, SSS, etc…
oh crap and I was under the impression the curve control in Blender for 3D rendering is tone mapping, this is only an exposure control?
Hi, on this link ( https://corona-renderer.com/forum/index.php/topic,3584.0.html) from Corona Renderer forum you may find some information like this image to illustrate what Tone mapping actually does to the image:
Also, this link which talk about one of the Tone mapping algorithms, the Filmic one starting at slide n°53:
I looked at the code snippet in the Corona forum and I couldn’t fully understand how it can’t be replicated with curves and the white point controls.
The main part of the code is a long math operation on the color channels based on certain variables, isn’t that the same thing you do with Blender’s curve settings?
The main part of the code is a long math operation on the color channels based on certain variables, isn’t that the same thing you do with Blender’s curve settings?
Yeah, you can approximate global tonemapping with curves.
And the math formula is often short,
for example: 1-e^-(image*muliplier) applied for each RGB color channel for simplest exponential tonemapping.
To revive this topic: @marcoG_ita asked me on IRC whether adding tonemapping in Viewport is possible, so I had a look.
It turns out that it works pretty well, but for a serious patch there are some considerations:
Which operators would you like? It should be also available in the compositor, since having perfectly balanced lighting in the viewport is no use if you can’t have the same result in an F12 render. My current code contains a LuxRender/Indigo-style Reinhard mapper, which however is not in the compositor. So, should I add this operator to the compositor as well, port the “Rh simple” from the compositor to Cycles, or use a completely different one?
So, I could use some feedback here. If there is interest, I could post a test build as well.
Hi Lukas.
If you’re going to introduce reinhard tonemapping to the Cycles color management panel, then I would advise you use some of the cutting edge algorithms that have been talked about in the Luxrender forum.
In my opinion, I really like the concept of being able to see the final tonemapped result while an F12 render is going like currently seen when using the current color management options, but I also agree that people will want freedom to tweak it in compositing as well.
Global reinhard (02) + some contrast correction slider.
Exponential is also interesting.
I’m confused, is the proposal to remove the Tonemap node from the compositer or is it to duplicate that functionality elsewhere? If the former, what do you do when you have an existing HDR background plate or render that needs to be tonemapped? How are you supposed to build your own local tonemapping operator by differencing the original base image with a simplified version generated by a global tonemapping operator, tweaking that difference map to pull out details, then recompositing it with the base image?
It seems like the fundamental issue raised by this thread is that the effects of the compositor are not shown in the viewport, making certain tasks difficult because of the lack of real-time feedback. Rather than move useful functionality out of the compositor and scatter it around other parts of Blender’s UI, or worse start duplicating functionality, wouldn’t it be better to try and solve the underlying issue? This thread is about tonemapping but getting a realtime preview of compositor effects like depth of field and lens distortion would be awfully useful for other tasks. I’m sure that is a much larger task, but with all of the view port and deps graph work being done, now might be the time to look at it.
I’m sure everyone has their favorites, but I think the first thing Blender could use is better documentation of the operators it already has, the wiki is fairly useless on this point.
I’m not entirely sure what ‘Rh Simple’ is but I’m guessing it is some variation of the most basic 1/(1+x) operator.
Based on the parameters it exposes and its behavior I’m pretty sure ‘R/D Photoreceptor’ is based on the Reinhard and Devlin 2005 paper, which is a nice general purpose tonemapper. It’s not quite the same as the Reinhard et al., 2002 version that many people are familiar with from other applications but it is a pretty good default to have, arguably better than 2002 in some ways. That being said, I’m not sure the default settings that Blender uses for this operator are ideal. In particular, while setting Adaption equal to 1 maximizes the amount of detail recovered as the authors intended, it also tends to produce a pretty flat low contrast image that may not be very visually pleasing. Using a smaller value of Adaption (or setting it to 0 for the pure global version) almost always seems to give a nicer looking result out of the box. The flatness also tends to be emphasized in Blender because, unless I’m misremembering, Blender’s default OCIO config doesn’t apply an S-shaped display transform as advocated for by the VES’s Cinematic Color whitepaper and found in, for example, the spi-vfx config.
So that would be Reinhard et al., 2002?
bumping this thread a lil’ bit…
@lukasstockner97 - May I suggest implementing something like the Highlight Compression parameter Corona Renderer use:
It’s the most intuitive tone mapping I’ve ever seen! It should appear next to the exposure parameter in the Color Management panel.
Ondra Karlic, the developer shared the code:
https://corona-renderer.com/forum/index.php/topic,1807.0.html
In my opinion, this should work for the preview and F12 render. If someone just want to do the tonemapping in the compositor, or in another software he can leave the highlight compression parameter at 1,00 , the default value.
@jedfrechette
No, I don’t want to remove anything from the Compositor 
Basically, the idea is that because compositing does not take place when using viewport rendering, a replacement tonemapper for use in viewport rendering would be useful. However, my concern was that this tonemapper should also be available in the compositor, since you probably want to have the same look for which you tweaked your materials in the F12 render. The easy soultion would be to apply the TMO also when doing a F12 render, but tonemapping should be done after compositing…
Adding full compositing support to the Cycles viewport is both a huge amount of work and will most likely slow it down a lot…
@all
Thanks for the suggestions!
So, my current approach would be:
Now, the question remains: What TMO should be used? Options that I am considering are Reinhard02 (as it is used in the new Lux operator), the Corona operator and the “Rh simple” (as it is used in the Blender Compositor).
Would this approach be useful?
PS: Sorry for the long silence, I was busy IRL, but now I have enough time again 
Doesn’t the color management function get applied at the end of the image pipe for both viewport rendering, normal F12 renders, and the compositor (whether it had render layer nodes or just images)? Why not just add the TMO there?
@lukasstockner - Sounds good! This is really needed!
As soon as you have a working build don’t hesitate to post it here Thank’s for working on this!
yes, that’s the way to go in my opinion too
Well, the color management would be the best place to implement it, but as far as I can see it’s mostly done by OpenColorIO, not by Blender itself. I’ll have a look whether it’s possible, but I’m not quite optimistic.
oh, that’s the deal…
There is definitely interest for that! I don’t use Blender for compositing and it would be nice to output tonemapped images straight from blender.
Couldn’t the performance issue be solved by having a new “Viewport” output node in the compositor? That way the user could control which portions of the comp are applied to the viewport and make their own decisions regarding the tradeoff between viewport fidelity and performance.
Okay, good news first: It turned out that adding operations to the color management is quite easy actually, so this means that tonemapping is applied to Viewport Rendering, the F12 rendering view, the compositing result (after the compositor), saving LDR images (the “typical” images) and to the image editor with “view as render” enabled, but not to saving HDR images (like .exr), which is exactly like it should behave.
The bad news is that this does not work with Reinhard, as it would need the average brightness (or more precisely, the geometric mean of the luminances), which is not known when you’re in the middle of an F12 render, for example.
The second good news is: The Corona highlight compression does work with the color management, and I just compiled a testbuild where you can try it out:
Just go into the color management settings and you’ll find a “Highlight compression” slider. The default value of 1 does nothing, but increasing it will make highlights darker and avoid clipping/burnout that way.
A few examples:
Highlight Compression 1 (default):
