
The SRGB Learning Curve - forrestthewoods
https://gamedevdaily.io/the-srgb-learning-curve-773b7f68cf7a#.vekxs27q5
======
leni536
IMO the worst offenders are image shrinking features in many applications.
Open this in your favorite browser/image viewer then shrink it to 50%:

[http://www.4p8.com/eric.brasseur/gamma-1.0-or-2.2.png](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](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.

~~~
jacobolus
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](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/](https://hsivonen.fi/png-gamma/) or
for a more general browser color rant cf. [http://regex.info/blog/photo-
tech/color-spaces-page1](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”.

~~~
vanderZwan
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](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.

~~~
jacobolus
Have you seen this work?
[http://w3.impa.br/~diego/projects/GanEtAl14/](http://w3.impa.br/~diego/projects/GanEtAl14/)

~~~
vanderZwan
Nope, thanks for the link!

------
jacobolus
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...](https://commons.wikimedia.org/wiki/File:Log_by_aliasing_to_int.svg)

> _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/colour_and_gamma/GammaFAQ.html)

[http://poynton.com/notes/color/GammaFQA.html](http://poynton.com/notes/color/GammaFQA.html)

~~~
krullie
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=318)

[https://www.fxphd.com/fxphd/courseDetails.php?idCourse=375](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=421)

------
DiabloD3
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).

~~~
anon4
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.

~~~
DiabloD3
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.

------
nkron
Another great article highlighting how often software gets it wrong is here:
[http://www.4p8.com/eric.brasseur/gamma.html](http://www.4p8.com/eric.brasseur/gamma.html)

------
madaxe_again
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.

~~~
jacobolus
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.

~~~
madaxe_again
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.

~~~
jacobolus
When there’s no profile or metadata included, you could show the uploader an
image preview and give them a choice of color spaces.

------
kelsolaar
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://colour-science.org/posts/the-importance-of-terminology-
and-srgb-uncertainty/)

