The SRGB Learning Curve(gamedevdaily.io)
gamedevdaily.io
The SRGB Learning Curve
https://gamedevdaily.io/the-srgb-learning-curve-773b7f68cf7a#.vekxs27q5
22 comments
A tricky thing w/r/t browsers is that they are often really crappy at figuring out what color space a PNG image is supposed to be in. I think they often intentionally strip out the color space info from PNG images for the sake of helping PNG images blend smoothly into CSS / Flash / etc., for which they also don’t do correct color management. [The CSS spec says that colors should be interpreted as sRGB, but browsers don’t actually follow the spec.]
As a result of this problem, it’s difficult to judge whether image resizing specifically is being done incorrectly, or whether the image is just being interpreted incorrectly at any size.
You’ll notice if you open your first test image (http://www.4p8.com/eric.brasseur/gamma-1.0-or-2.2.png) in Apple’s Preview app, you get the correct behavior, but this is different from the behavior in Safari, for example, which shows something incorrect at every size. Stranger still, the behavior in Safari is roughly “correct” while resizing a browser window, but as soon as you let go of the mouse, it reverts to being incorrect.
There are multiple possible ways to embed color space info into PNG images, and the PNG spec is actually really terrible and confusing on this subject which results in lots of inconsistencies from one implementation to another. If I remember correctly some of them are treated better by browsers than others, but I’m not sure if there’s a way to encode images such that it will be handled properly everywhere (I mean, handled correctly even at 100% size, without any resizing). I’m not an expert on browser image rendering though. cf. e.g. https://hsivonen.fi/png-gamma/ or for a more general browser color rant cf. http://regex.info/blog/photo-tech/color-spaces-page1
* * *
One particularly annoying thing about gamma and image rendering is that all font and vector graphics rendering in pretty much all software (Illustrator, Inkscape, Cairo, Quartz, browsers, etc.) is implicitly done (incorrectly) in gamma-encoded space rather than linear space. This causes vector graphics with thin lines to change dramatically in appearance as you scale them up or down, but no implementation is able to fix their behavior and do the right thing because all content (e.g. small text rendering) in that renderer will suddenly look “wrong”.
As a result of this problem, it’s difficult to judge whether image resizing specifically is being done incorrectly, or whether the image is just being interpreted incorrectly at any size.
You’ll notice if you open your first test image (http://www.4p8.com/eric.brasseur/gamma-1.0-or-2.2.png) in Apple’s Preview app, you get the correct behavior, but this is different from the behavior in Safari, for example, which shows something incorrect at every size. Stranger still, the behavior in Safari is roughly “correct” while resizing a browser window, but as soon as you let go of the mouse, it reverts to being incorrect.
There are multiple possible ways to embed color space info into PNG images, and the PNG spec is actually really terrible and confusing on this subject which results in lots of inconsistencies from one implementation to another. If I remember correctly some of them are treated better by browsers than others, but I’m not sure if there’s a way to encode images such that it will be handled properly everywhere (I mean, handled correctly even at 100% size, without any resizing). I’m not an expert on browser image rendering though. cf. e.g. https://hsivonen.fi/png-gamma/ or for a more general browser color rant cf. http://regex.info/blog/photo-tech/color-spaces-page1
* * *
One particularly annoying thing about gamma and image rendering is that all font and vector graphics rendering in pretty much all software (Illustrator, Inkscape, Cairo, Quartz, browsers, etc.) is implicitly done (incorrectly) in gamma-encoded space rather than linear space. This causes vector graphics with thin lines to change dramatically in appearance as you scale them up or down, but no implementation is able to fix their behavior and do the right thing because all content (e.g. small text rendering) in that renderer will suddenly look “wrong”.
Regarding your last point, that's another reason to hope hardware accelerated path rendering gets adopted ASAP:
https://www.youtube.com/watch?v=yN6eyFYDMkg&t=11m4s
(I know this is not exactly the same visual bug, but generally speaking Mark Kilgard & Co. seem to have done their homework and really implemented the specs properly)
The other reasons being that it's faster and more energy-efficient.
https://www.youtube.com/watch?v=yN6eyFYDMkg&t=11m4s
(I know this is not exactly the same visual bug, but generally speaking Mark Kilgard & Co. seem to have done their homework and really implemented the specs properly)
The other reasons being that it's faster and more energy-efficient.
Have you seen this work? http://w3.impa.br/~diego/projects/GanEtAl14/
Nope, thanks for the link!
Can anyone explain the gradient merging example? If we sum an image in which luminosity is linearly rising from left to right with the image in which the luminosity is linearly rising from top to bottom, then the result should have constant luminosity across bottom left - top right diagonal. So we shouldn't see a circle effect in the top left corner, but rather a rotation of first gradient by +45 degrees. Or are the gradients not linear in luminosity? Or are you guys not seeing the circle effect? It does looks quite different on my other monitor, but I can still clearly see a circle instead of topleft-bottomright linear drop in luminosity on the left example.
I see a circle effect in the "correct" merge and don't see one in the "incorrect" merge. My guess is that the gradient is linear in sRGB values, so if you merge in sRGB space (incorrectly) then you get a rotated, sRGB space linear gradient.
Yea, I guess that also explains why gradients don't look that smooth.
This was previously discussed here:
https://news.ycombinator.com/item?id=8207271
https://news.ycombinator.com/item?id=8207271
OSX, Chrome 46 - apparently their scaling "Rules", though I'm not sure if a 100%, the "Sucks" is still faintly visible.
To pick a couple minor nits:
> For those of you familiar with the binary format of floating-point numbers, we do not think of them as being “gamma 2.0” — they are still just linear values, we just bear in mind that their precision characteristics are similar to those of a gamma 2.0 curve.
Actually floating point numbers are distributed roughly like log₂x, not like √x. https://commons.wikimedia.org/wiki/File:Log_by_aliasing_to_i...
> Monitors were (and still are) gamma-space display devices
This is misleading. LCD displays are “gamma-space display devices” not because of anything inherent to the medium, but because they have built-in lookup tables which interpret incoming data that way and set output to look correct based on the particular characteristics of the display. Cathode Ray Tube displays do have a nonlinear relation between voltage and light output which is fairly similar to an inverse gamma curve (of gamma ~2.5), but that’s more a convenient coincidence than a reason for gamma encoding digital images, which is primarily about using a limited number of bits in an efficient way.
* * * * *
Anyone who needs to deal with gamma encoding issues should really read Charles Poynton’s FAQ and FQA:
http://poynton.com/notes/colour_and_gamma/GammaFAQ.html
http://poynton.com/notes/color/GammaFQA.html
> For those of you familiar with the binary format of floating-point numbers, we do not think of them as being “gamma 2.0” — they are still just linear values, we just bear in mind that their precision characteristics are similar to those of a gamma 2.0 curve.
Actually floating point numbers are distributed roughly like log₂x, not like √x. https://commons.wikimedia.org/wiki/File:Log_by_aliasing_to_i...
> Monitors were (and still are) gamma-space display devices
This is misleading. LCD displays are “gamma-space display devices” not because of anything inherent to the medium, but because they have built-in lookup tables which interpret incoming data that way and set output to look correct based on the particular characteristics of the display. Cathode Ray Tube displays do have a nonlinear relation between voltage and light output which is fairly similar to an inverse gamma curve (of gamma ~2.5), but that’s more a convenient coincidence than a reason for gamma encoding digital images, which is primarily about using a limited number of bits in an efficient way.
* * * * *
Anyone who needs to deal with gamma encoding issues should really read Charles Poynton’s FAQ and FQA:
http://poynton.com/notes/colour_and_gamma/GammaFAQ.html
http://poynton.com/notes/color/GammaFQA.html
Good catch. Charles is really up there with the best in colour theory. For anyone interested he has a couple of really good courses on fxphd. One of the best teachers I've had.
https://www.fxphd.com/fxphd/courseDetails.php?idCourse=318
https://www.fxphd.com/fxphd/courseDetails.php?idCourse=375
https://www.fxphd.com/fxphd/courseDetails.php?idCourse=421
https://www.fxphd.com/fxphd/courseDetails.php?idCourse=318
https://www.fxphd.com/fxphd/courseDetails.php?idCourse=375
https://www.fxphd.com/fxphd/courseDetails.php?idCourse=421
I wish more software developers understood these things.
A lot of games IMO have been marred by this, usually you can see it via really bad banding in dark areas.
My recommendation? A working temporal dither implementation while baking it to sRGB yourself in the final stage of your pipeline.
My other recommendation? 10 and 12 bit output becoming the norm, which Rec 2020 is mandating and future HDMI and Displayport specs will be forced to support for proper 4k support (currently, no 4k TV or monitor being sold meets 4k compatibility requirements due to not supporting Rec 2020's colorspace nor colordepth) (HDMI 2.0 already supports Rec 2020, but does not mandate support for).
A lot of games IMO have been marred by this, usually you can see it via really bad banding in dark areas.
My recommendation? A working temporal dither implementation while baking it to sRGB yourself in the final stage of your pipeline.
My other recommendation? 10 and 12 bit output becoming the norm, which Rec 2020 is mandating and future HDMI and Displayport specs will be forced to support for proper 4k support (currently, no 4k TV or monitor being sold meets 4k compatibility requirements due to not supporting Rec 2020's colorspace nor colordepth) (HDMI 2.0 already supports Rec 2020, but does not mandate support for).
12bit will be pretty awful to work with though. That will mean 36 bits per pixel, which doesn't fit into a whole number of 8-bit-bytes. Best to just bite the bullet and go 16bit for internal representation.
That's how a lot of software that can handle 12 bit already does it. It is only baked to whatever format the display wants (yes, 12 bit displays exist, they are tens of thousands of dollars, and only used very sparingly during post-production).
Presumably, it is either padded to 5 bytes, or two pixels are shoved into 9 bytes when shipped to the monitor.
Presumably, it is either padded to 5 bytes, or two pixels are shoved into 9 bytes when shipped to the monitor.
Another great article highlighting how often software gets it wrong is here: http://www.4p8.com/eric.brasseur/gamma.html
This is a source of pain in web dev, too - we convert uploaded images to srgb so they display as consistently as possible across devices - and generally clients save in srgb. It's when they upload Adobe rgb images that get auto-converted that the fun starts, as the effect is usually one of the image appearing "washed out".
Curious if anyone has come up with a clever solution to this one.
Curious if anyone has come up with a clever solution to this one.
What does “auto converted” mean in this context?
If you know the image is Adobe RGB (e.g. it has an embedded color profile, or has an "Adobe RGB" metadata tag) then you should either keep that metadata around, or if you want to turn it into an sRGB image you’ll need to convert the colors of every pixel. Since the Adobe RGB gamut is larger than the sRGB gamut, for some images you’ll need to map out-of-gamut colors into the sRGB gamut, either by hard clipping them (I recommend clipping along constant hue/lightness lines in CIELAB or CIECAM02 space) or by doing a more sophisticated transformation. There are lots of possible choices to make when gamut mapping. If you’re interested in the details there was a ~1000 page book published on the subject a few years ago. :-) (Or the easy thing is to just let some existing color management software like Apple ColorSync, LittleCMS, or whatever Adobe’s thing is called handle the gamut mapping for you, though in my opinion they all do a relatively mediocre job, unfortunately.)
If you don’t know the image was Adobe RGB – i.e. the metadata was stripped out before it got to you – then there’s not a lot you can do, unless you want to examine the color content of the image and come up with some kind of heuristic for guessing the color space.
If you know the image is Adobe RGB (e.g. it has an embedded color profile, or has an "Adobe RGB" metadata tag) then you should either keep that metadata around, or if you want to turn it into an sRGB image you’ll need to convert the colors of every pixel. Since the Adobe RGB gamut is larger than the sRGB gamut, for some images you’ll need to map out-of-gamut colors into the sRGB gamut, either by hard clipping them (I recommend clipping along constant hue/lightness lines in CIELAB or CIECAM02 space) or by doing a more sophisticated transformation. There are lots of possible choices to make when gamut mapping. If you’re interested in the details there was a ~1000 page book published on the subject a few years ago. :-) (Or the easy thing is to just let some existing color management software like Apple ColorSync, LittleCMS, or whatever Adobe’s thing is called handle the gamut mapping for you, though in my opinion they all do a relatively mediocre job, unfortunately.)
If you don’t know the image was Adobe RGB – i.e. the metadata was stripped out before it got to you – then there’s not a lot you can do, unless you want to examine the color content of the image and come up with some kind of heuristic for guessing the color space.
Yeah, it's usually the latter - and when we do know it's Adobe RGB we do exactly what you recommend, going via CIELAB - but it's not precise, and clipping does occur.
We're leaning towards "please upload a valid image" as a solution, which is a shame, but the whole perceptual end of things makes doing this automatically nigh on impossible - can't come up with a solution that works for all cases.
We're leaning towards "please upload a valid image" as a solution, which is a shame, but the whole perceptual end of things makes doing this automatically nigh on impossible - can't come up with a solution that works for all cases.
When there’s no profile or metadata included, you could show the uploader an image preview and give them a choice of color spaces.
We published a follow-up post yesterday, essentially calling for a better vocabulary usage when discussing about colour science and theory: http://colour-science.org/posts/the-importance-of-terminolog...
http://www.4p8.com/eric.brasseur/gamma-1.0-or-2.2.png
I tested it right now in chromium 46 and it still doesn't scale it correctly. Last time I checked Firefox doesn't do it better.
An other good article about this problem: http://www.4p8.com/eric.brasseur/gamma.html
There are other areas where this becomes apparent, such as physical lighting models where it only makes sense to use a linear colorspace. Is there a type safe library to handle colors well (like having separate types for "compressed" and "linear" color values)? I think that could mitigate most of these problems caused by naive implementations.