gammaCorrectionDefault values are not intuitive

[fhoech]

As someone with a certain amount of knowledge in colorimetry and light, I find it very confusing that the gammaCorrectionDefault values are seemingly not in all cases to be taken as, unlike what I would expect, the correction that should be applied, but the state of the RGB data in the X3D file, with implications for the actual correction applied. E.g. if you have an X3D file where the colors are not linear light, e.g. if they have already been encoded with an sRGB or other gamma 2.2-ish transfer function, you have to set gammaCorrectionDefault="none" (this actually makes some sense, but shouldn't it be the default? Many VRML and X3D files I have looked at seem to have RGB values encoded with an sRGB-like transfer function, and all VRML and X3D viewers except X3DOM seem to go by that assumption). I certainly wouldn't expect a value of "linear" to apply any gamma correction, in fact, I would expect it to be synonymous to "none", and application of the sRGB transfer function (which what a value of "linear" actually seems to do) would be much better represented by a value of, well, "sRGB". Also, the documentation doesn't make sense in some parts:

(Quoting from http://doc.x3dom.org/tutorials/lighting/gamma/index.html)

"RGB Colors and textures are assumed to be gamma coded."

Not when the default for gammaCorrectionDefault is "linear", which seems to assume the RGB values are linear light and then applies the sRGB transfer function.

"These days people generally prefer the linear workflow, i.e. compensating for gamma-coded colors in some way, or eliminating them from the scene and assets."

A linear light workflow is precisely not "compensating for gamma-coded colors", it's the other way around: In a linear light workflow, you have to apply gamma correction to get visually correct output.

"When working gamma-corrected (i.e. in the linear setting) [...]"

As mentioned above, I wouldn't expect a value of "linear" to apply any gamma correction. That it actually applies the sRGB transfer function, is unfortunate at best.

[simonthum]

Hi,

you are right with most of what you say.

This was essentially made in one evening. I started out with the correction to apply (2.0, 2.2, 1.0), and the name remained but the setting names later changed to internal-denomination-based, because I deemed that simpler. My bad.

The rationale (#222 if you speak german) is that you specify the net effect as seen from the outside rather than how it's achieved. I would prefer to keep that bit even if other names are proposed.

I also looked at SVG

http://www.w3.org/TR/2003/REC-SVG11-20030114/filters.html#feComponentTransfer

but I think spelling "gamma" to get linear behaviour is downright ugly, given that 99% of material is gamma encoded and 99% of software gets this wrong by default. Other standards are equally shrewd or slient (like X3D).

Please, propose a set of values and meanings that makes sense to you!

But some of what you say seems wrong: In "linear", RGB is taken as encoded (it always is "assumed to be gamma coded") and accordingly is decoded first (made linear). The point is, however you work, you specify color encoded, like about everywhere else. It's linear because internal computation will happen in a linear domain. "Native" might be better than "none" due to that, although I'd prefer "Native_broken_donotuse" ;)

I also know that a linear workflow is not defined by compensating for gamma, but it's often part of the story. I just wanted to make clear what the gamma setting is about.

Technically you cannot currently realize a linear workflow in X3DOM, we should be explicit about that. The setting needs to be more fine-grained for that - this is the "Default" in "gammaCorrectionDefault", i.e. the thinking is that one can easily add "gammaCorrectionTexture", "..Color", "...Output" to actually adapt to a given workflow.

IMO it's the "Correction" bit which is currently a bit off. The basic idea - allowing to keep scenes mostly as they are - should be preserved unless one is really set out to do a linear workflow.

Since X3D remains silent on that (although I doubt it will be hard to convince them to change it) any odd combination would still be in the bounds of X3D, including a truly linear workflow.

So, if you can provide a useful nomenclature that would certainly help.

[mlimper]

After checking what this actually means, I agree that "linear" is confusing.
"linearize" would be more meaningful, but why don't directly call it "correctGamma"? :-)

So possible values could be:

• "none"
• "correctGamma" / "linearize"
• "correctGamma_fast" / "linearize_fast"

or something like that...

I wouldn't have thought about authoring my content in another space than linear color space, to be honest... so, for me as an X3DOM user that wants the colors within his scene to be faithfully reproduced on the screen, I would like to have "correctGamma" as default.

[simonthum]

Sounds sensible, but your last paragraph is confusing me slightly.

All the colors you'll ever get out of photoshop, GIMP or color pickers will be gamma encoded - so you more or less need to be authoring in non-linear colors. They should be decoded, processed linearly and the re-encoded for faithful reproduction, though. I suppose that is what you want to say?

[mlimper]

For textures, yes.

For X3D materials, I would not have assumed I have to specify them in a non-linear space.

[simonthum]

Well it is sort of counter intuitive but that is how colors are specified virtually everywhere. All you do is divide by 255 to get from hex to float - it's a practical matter. Departing from that would have your users needing to do conversion from e.g. a color picker to X3DOM using arcane sRGB formulas they did not know would exist.

But the real killer is compatibility with existing scenes.

[fhoech]

Thanks @simonthum and @mlimper for your feedback.

But some of what you say seems wrong: In "linear", RGB is taken as encoded (it always is "assumed to be gamma coded") and accordingly is decoded first (made linear).

That's not what it seems to do do though. When I used a setting of "linear" with a file that had its color values already sRGB encoded, the visual effect was that it got displayed much lighter than it should be, which implies that (only) the forward sRGB transfer function was applied. To turn sRGB into linear light, you would need to apply the reverse sRGB transfer function (simplified n ^ 2.22) first. Then do any processing in linear light, and then the forward function (simplified n ^ (1.0 / 2.22)) to get sRGB again for display.

Technically you cannot currently realize a linear workflow in X3DOM, we should be explicit about that.

I would propose to prevent confusion in future to amend the current gammaCorrectionDefault with gammaEncodingDefault, and have the latter only deal with the transform to linear light (from whichever way the values in the X3D scene are specified to be encoded using this setting), with the following possible values:

• "linear": Values in the file are already encoded in linear light.
• "sRGB": Values in the file are sRGB-encoded.
• "x.x" (float): Values in the file are encoded with gamma x.x (1.0 would have the identical effect to "linear").

But we still need to compensate for display, and when in future a linear workflow becomes possible we cannot simply use the encoding value because a display very likely behaves in a different way. So the setting gammaEncodingDefault should be coupled with gammaCorrectionDefault, and the latter should only handle the compensation for display (linear light to display RGB transformation):

• "linear"/"None": No display compensation. (I don't like a "Native" value because it implies to me that the native behavior of the display is somehow known from within x3dom, which it is not)
• "sRGB": Apply sRGB transfer function (simplified n ^ (1.0 / 2.22)).
• "x.x" (float): Apply power function n ^ (1.0 / x.x).

When in a file only gammaCorrectionDefault is present, it should be assumed gammaEncodingDefault is the same. In the case of gammaCorrectionDefault "linear" that should mean no decoding to linear (it is already), and no compensation for display.

[simonthum]

Without having done any checks, the behaviour you describe is either a bug or you did not switch off the headlight.

Regarding your proposal, future confusion is the matter. I had in mind a scheme of options roughly like:

gamma(Encoding|Decoding|Correction)(Color|Texture|Framebuffer)

(with correction meaning both en/decoding)

so you could address each stage separately to adjust to the workflow, potentially with local overrides per image or material definition, enabling linear and encoded authoring mixed in one scene.

But you have a point that maybe only the decoding belongs into the scene at all. Let's revisit this in a few days, when I have some spare time. Max, maybe you have some more input too.

[fhoech]

gamma(Encoding|Decoding|Correction)(Color|Texture|Framebuffer)
(with correction meaning both en/decoding)

Looks good.

But you have a point that maybe only the decoding belongs into the scene at all.

That would simplify things a lot and reduce the error potential as well I think.

[simonthum]

@fhoech I didn't get to look at the gamma stuff in detail but I did try to see how you are getting brighter materials, which I fail to reproduce. Could you open another bug with a small test scene? That would certainly help.

[fhoech]

I did try to see how you are getting brighter materials, which I fail to reproduce

Turns out I actually can't reproduce it either (current version of x3dom, didn't check earlier ones). I used a very simple test (http://hoech.net/files/x3dom/Sphere.xhtml) and when I switch between linear/none and look at or sample the center point with a color picker, it stays the same (RGB 127 127 127).

[simonthum]

OK, great, then at least there is no obvious regression ;)

Your test, however, is pretty much the same test that I came up with (compares nicely to images of half moons to fend off claims that gamma correction is somehow wrong), but I'm in no mood to dig deeper for the sake of it.

That said, the test IMO shows the strength of the current approach: being compatible to the scenes out there, focusing only on the internal denomination. I still haven't looked closely at how to combine this with e.g. a linear work flow but I have something I'd like to discuss with @mlimper f2f so if you have further comments or suggestions just post them.