Reinhard + Premultiply Alpha

[thomas]

Hi all,

Just a quick question: In my opinion Reinhard and premultiply alpha do not play that nice together. I can see where it is coming from, Reinhard picks up the blacks that are the result of the premultiplying and tries to compensate for it by making the opaque parts of the rendering white. Is it possible to account for the alpha channel in the Reinhard algorithm or is the way things work now, in fact, intended behaviour?

Best,
Thomas

[jeanphi]

Hi,

Reinhardt works with the mean of the render intensity. So if you have large black areas, it will compensate by letting other areas burn. You can compensate for that with the tonemapping parameters.
We could also discard fully black pixels in the computation, I'll have a look at it since I think that some other tonemappers already do it.

Jeanphi

[jeanphi]

Hi,

I just checked and Reinhardt already checks for the color to be strictly greater than 0 to account for it. You need to adjust the settings to get your desired result.

Jeanphi

[Abel]

Reinhardt already checks for the color to be strictly greater than 0 to account for it. You need to adjust the settings to get your desired result.

But how about using Thomas's suggestion of using alpha? Couldn't the algorithm just ignore any pixels that have for example more than 90% transparency? It would be rather nice to get a more nicely tonemapped image right away when using the premultiply alpha setting.

[jeanphi]

Hi,

Then it will be yet another parameter (the 90%) that you'll need to adjust because in some cases it won't work. Is it that difficult to just rise the burn factor or use another algorithm like maxwhite for example which will work just fine in such a situation?
I'm really not sure that the idea will work.

Jeanphi

[thomas]

Hi all,

Thanks guys for giving this some thought. In my head I must have thought it should be possible to have the same output for the opaque parts regardless of the type of alpha while using Reinhard. I now realise this is impossible unless lux would keep track of an additional buffer for unpremultiplied output, which I presume is not feasible. In retrospect I think Discarding pixels with alpha lower than some threshold for the mean calculation in Reinhard is also undesirable because it would no longer take e.g. sunskies in account in regular renders. Back to linear it is for me.

Best,
Thomas

[Abel]

Is it that difficult to just rise the burn factor or use another algorithm like maxwhite

It's not difficult at all and adjusting the burn slider just takes a split second. The reason I still care about it is twofold:

1. Novice users who are not yet familiar with the workings of tonemapping may think they have done something wrong, or may think that LuxRender is just prone to give burned out output, or may start trying adjusting sliders like crazy and do something stupid.

2. One of the metrics of judging the quality of a program is how easy it is to get it to do what you want, and another one is the quality of the output without user interaction. In the workflow, even though adjusting one slider is a minor operation, I think there is a big difference between "prepare scene, press render, LuxRender will open and create nice output" and "prepare scene, press render, LuxRender will open and create blown out output, adjust slider, see if it is good, adjust slider, get nice output".

Of course I realise that if changing the behaviour would result in a speed penalty or significantly increased memory usage, then it may not be worth it.

[jeanphi]

Hi,

The main issue is defining the correct behaviour: with the metrics used you could have the same values for a scene where you're interested in a small highly lit area where you want all the output dynamic, and a scene with a few very bright areas that you're not interested in. That's a limitation of the tonemapping algorithm, there are other algorithms that provide local adaptation and are able to much better deal with such situations. There's even a very old task in Mantis for that (#344).

EDIT: and your points are perfectly valid, I just don't like to rely on tricks to hide fundamental flaws, sorry if I sounded a bit harsh

Jeanphi

[J the Ninja]

To add to that, I don't think using a local tone mapping algorithm by default is necessarily a good idea either. They tend to calculate slower than global ones, and often give very washed-out or surreal-looking output (the so-called "HDR Hell") if not configured properly. Some of them (like the oft-mentioned contrast-based one from the mantiuk paper) have a habit of locking onto to render noise as a detail to be preserved and wind up sharpening it as well, showing noise where a global operator wouldn't.

[Abel]

The main issue is defining the correct behaviour: with the metrics used you could have the same values for a scene where you're interested in a small highly lit area where you want all the output dynamic

Isn't that exactly where the alpha channel comes in? I agree that with very dark sections of an image one should not ignore that area, but if large parts of the output are transparent I cannot imagine anyone wanting that transparent area to be considered black for tonemapping purposes.

there are other algorithms that provide local adaptation and are able to much better deal with such situations. There's even a very old task in Mantis for that (#344).

Let me know when you are getting tired of me asking for additional tone mapping options in LuxRender.

sorry if I sounded a bit harsh

You didn't and even if you did, it would not nearly cancel out my eternal gratitude for your great work on this program!