Filmic and Gamma

[chafouin]

@monitorhero

Does this mean the addon only properly works in 2.8 with the update to it? @chafouin

No it’s in the 2.79 nightly builds as well.

I’ll try to find the time to test the issues you are having with exposure and intensities this week-end.

[monitorhero]

@troy_s

Perhaps a better way to think about scene referred values, such as those in an EXR, is to think of the values as data and less as an “image” in a traditional sense. That is, in the scene referred domain, there is no real notion of “white” nor “black”. Once we accept this, we can see that the data in the file doesn’t represent any actual values , but rather describes the relationship between the values. That is, an EXR only represents ratios of the three lights and their relationship to each other, and no defined “ground truth”.

If we understand that, we can also begin to understand that the default encoding for an “image” EXR has no explicit relationship to the chosen view transform. Looking at a thumbnail? The EXR might not align with the needs of the thumbnailer’s assumptions. Trying to view the EXR in an image viewer? The image viewer might make assumptions that are incorrect for the data.

If we were to take the maximum value in an EXR, then add another brighter source, the value would be higher. Likewise, if we descend down into the darker parts of a capture, we can easily see that there is no lower bound either. Again, there is no notion of black or white [1] in a scene referred set of data. Those notions are defined entirely by the view transform / exposure / etc.

Thank you Troy for explaining it again. This part I can comprehend.

@troy_s

Once this is understood, it is easier to understand scaling the scene values. If we have a particular value that we need to land at a particular code value of a particular view transform, we can apply (2^NUMBER_OF_STOPS_OF_ADJUSTMENT)*IMAGE_VALUES to scale the data properly. That is, aligning image data and keeping the linear ratios between the values must be achieved by multiplication. This is precisely the method that proper exposure compensation uses to shape the data prior to a view transform, or shape the data itself before saving to an encoding. This is scaling the data.

Here is where I struggle. Could you give me a practical example of that calculation? And is the .hdr format inferior to the .exr format inside Blender?

[troy_s]

@monitorhero

Could you give me a practical example of that calculation?

Assuming you have two plate shots, scene referred. If one was exposed at your current “at exposure” for the chosen view transform, and the other shot was two stops too hot, you could decrease it via the math above.

@monitorhero

And is the .hdr format inferior to the .exr format inside Blender?

It isn’t just Blender. If we had two encoding values to use, and the format covered 1000000000 nits to 0.0001 nits, we can see the problem. While the minimum and maximum code value represents a vast range, our two values are distributed such that it is terribly inefficient; it doesn’t offer enough granularity in the between values. Same issue with HDR and underused values; it restricts the useful range, and does so in a non-uniform fashion.

In the case of EXR at 32 bit float, it covers a vast range of values, albeit not as wide as the HDR format. However, EXR does so with a good degree of granularity across the values it does cover. To repeat, HDR covers a wider range of values, but a majority of those values are likely rarely, if ever, utilized, hence wasting the range of values that are useful for a majority of CGI work. This can lead to posterized imagery and other sub-optimal results.

For more information, this is an excellent link on how the various encoding formats hold up against each other. I’ll let you figure out which one is the clear winner by a huge margin.

[CarlG]

@monitorhero

Could you give me a practical example of that calculation?

Say you want to make an image with a TV and the TV is the main subject. The scene is setup for two renders; nighttime using internal lights only, and daytime using outside lighting. The camera exposure for these exposures will vary.

You can scale the TV emission with the exposure formula above so that it appears just as bright at both exposures, all you need to do is plug in the correct exposure number; obviously this is faking it, but selling the TV you don’t want to put it in an underexposed setting (unless you want to show the difference).

[monitorhero]

Thank you guys. That makes it clearer now.

I also opened a thread with a project I started which is more hands-on. And I would be happy if you guys could give me some feedback or help me out on it

[Roken]

Hell, don’t stop. I am learning so much off this thread.

[Roken]

OK, utilising what I’ve been able to learn, this is where I got to.

[smilebags]

This is beautiful!

I found your addon when you released the first few videos and we communicated a bit regarding the camera-controls side of things. Awesome to see you active here and still working on the addon. A graphics driver update just killed 2.79 for me so I’ve been getting by with a barely usable 2.8. If you need someone to test the 2.8 version of your addon when it comes out, I’m more than happy to!