Page 2 of 3

### Re: [REQ] hdr environment - gamma control

Posted: Mon May 13, 2013 8:30 pm
These a,b,c names sound like a generic placeholder for something that should be named properly.

### Re: [REQ] hdr environment - gamma control

Posted: Tue May 14, 2013 12:58 am
thanks Zom-B, that does sound useful!! missed that one completely somehow...

### Re: [REQ] hdr environment - gamma control

Posted: Tue May 14, 2013 2:07 am
b = offset
c = scale

They are the coefficients from a quadratic polynomial: ax^2 + bx + c.

### Re: [REQ] hdr environment - gamma control

Posted: Tue May 14, 2013 2:29 am
Also thanks Ono, I just still think that this is not the kind of explanation you can throw at any artist without getting some strange looks... there are lots of people who a scared of maths, and most would not even consider understanding even such a simple formula.

I recall that his topic came up already a few times, are there any serious suggestions for a more intuitive naming? How is this handled in other exporters (I only know Blendigo)?

Cheers!

### Re: [REQ] hdr environment - gamma control

Posted: Tue May 14, 2013 2:33 am
That *is* the more intuitive naming. I don't see what's hard to understand about scale and offset.
And regarding quadratic, there really is no simpler way to describe it AFAIK. If you don't understand it, then you don't need to use it

### Re: [REQ] hdr environment - gamma control

Posted: Tue May 14, 2013 3:21 am
OnoSendai wrote:That *is* the more intuitive naming. I don't see what's hard to understand about scale and offset.
And regarding quadratic, there really is no simpler way to describe it AFAIK. If you don't understand it, then you don't need to use it
I'm personally not uncomfortable of ax²+bx+c (by the way I'm not an artist), but for instance, photoshoppers will understand brightness/contrast (it's exactly what the eponymous PS adjustment does).

Etienne

### Re: [REQ] hdr environment - gamma control

Posted: Tue May 14, 2013 3:23 am
galinette wrote:
OnoSendai wrote:That *is* the more intuitive naming. I don't see what's hard to understand about scale and offset.
And regarding quadratic, there really is no simpler way to describe it AFAIK. If you don't understand it, then you don't need to use it
I'm personally not uncomfortable of ax²+bx+c (by the way I'm not an artist), but for instance, photoshoppers will understand brightness/contrast (it's exactly what the eponymous PS adjustment does).

Etienne
a = brightness?

### Re: [REQ] hdr environment - gamma control

Posted: Tue May 14, 2013 3:50 am
OnoSendai wrote:a = brightness?
no, c=brightness and b=contrast, more understood than scale/offset (which are more used for geometry than pixels)

for a, it's true there is no equivalent (except qualitatively gamma, but this is not gamma)

Anyway, the +ax² term exists nowhere else than in Indigo, it's quite unusual to have non-linearity as an additive term. So I do not see how to make it artist friendly.

Why not allowing gamma correction for EXRs? This would be a more simple solution to the original question... You can default it to 1.0 for all HDR formats, and precalc it if set to something else than 1.0

Etienne

### Re: [REQ] hdr environment - gamma control

Posted: Tue May 14, 2013 4:05 am
galinette wrote:
OnoSendai wrote:a = brightness?

Why not allowing gamma correction for EXRs? This would be a more simple solution to the original question... You can default it to 1.0 for all HDR formats, and precalc it if set to something else than 1.0

Etienne
Performance reasons, but also HDRs should have encoding gamma = 1 anyway.

### Re: [REQ] hdr environment - gamma control

Posted: Tue May 14, 2013 4:25 am
OnoSendai wrote:Performance reasons
EXR is a float format, so as I wrote, you can precalc the pow()'ed values when reading the file without increasing the memory consumption, no??
EDIT : OK, EXR has many possible formats. But with the most common half and float formats, you can precalc the gamma correction without increasing memory consuption.
OnoSendai wrote:but also HDRs should have encoding gamma = 1 anyway.
In theory yes, but this removes a powerful "artist-friendly" shadow adjustment possibility which is easy to implement, and I believe, would help many users. Don't see gamma as a reading format parameter in this case, but as an image adjustment.

For instance, even with gamma=2.2 LDRIs, user often tweak the gamma to change the response curve. For instance, with exponent maps, it's quite useful.

Etienne

### Re: [REQ] hdr environment - gamma control

Posted: Tue May 14, 2013 4:35 am
Hi Etienne,
In Indigo, different materials can refer to the same exr, but with different a, b, c, and gamma values. In order for the texture data to be shared, the gamma etc.. can't be baked in.

### Re: [REQ] hdr environment - gamma control

Posted: Sun May 19, 2013 11:29 pm
(eheheh nothing to add to the discussion: I'm enjoying this battle of brains with a popcorn cone :D:D )

### Re: [REQ] hdr environment - gamma control

Posted: Mon May 20, 2013 4:50 am
Pibuz wrote:(eheheh nothing to add to the discussion: I'm enjoying this battle of brains with a popcorn cone :D:D )
Thanks for reminding me to continue the thread

Ono : This is a clear advantage for materials (lower memory consumption), but I seriously doubt that using the same EXR in the environment and in another material at the same time will be a common case! But I recognize that handling this kind of special cases would make code uglier. I'm sure you can find an elegant solution though! That gamma correction of envmaps is really a feature I would have enjoyed in my previous works with Indigo, especially with clear sun envmaps, to balance the amount of shadow.

Etienne

### Re: [REQ] hdr environment - gamma control

Posted: Mon May 20, 2013 5:15 am
Hi Etienne,
But you could just use the 'a' parameter instead of gamma, as it's close.

### Re: [REQ] hdr environment - gamma control

Posted: Mon May 20, 2013 9:32 am
galinette wrote:... but I seriously doubt that using the same EXR in the environment and in another material at the same time will be a common case!
I don't understand what ya guys exactly argue about, but I for sure can second that EnvMaps get used once in a scene...