19 ms·

What every coder should know about gamma

560 points by johnnovak 10y ago

willvarfar 10y ago
I'm divided; I really want the article to be true, and for everyone to realise what a whole mistake we've been making all along... but, as the legions of us who don't adjust for gamma demonstrate, ignoring it doesn't make the world end?!
- ploxiln 10y ago
  Nope, world doesn't end, but scaled images look wrong, some more than others. For more examples see http://www.4p8.com/eric.brasseur/gamma.html http://www.4p8.com/eric.brasseur/gamma.html
- zubat 10y ago
  Ignoring the color space is hardly a world ender for most applications, but it has an effect on quality that can be subtle to drastic depending on what you're doing. For example, arcade games emulated in MAME often have a washed-out look by default because the monitor gamma isn't included(but it can be achieved through user customization). One thing the article misses is a process or checklist to discover your requirements for color spaces. Characterizing it as a gamma-only problem isn't entirely correct since we also have completely different models of color(e.g. LAB, HSV, YUV) that make tradeoffs for different applications. So, something like: 1. Input data: if it contains gamma data or specifies a color space use that, else assume linear sRGB. 2. Output device: is gamma correction done for you/can you access information about the device capabilities and lighting situation? This can inform viewing conditions. For example, if your smartphone has a light sensor this can be used to adjust gamma as well as backlighting to achieve a near-linear perceptual response. Most apps wouldn't consider doing this of course. If the output is a file or stream determine the most likely use cases and convert as necessary. 3. Internal processing. For each image or signal you process, determine its input color space, and the ideal color space to run it in. Then decide which approximation is an appropriate trade-off for your application(since many color space conversions are compute-intense), and implement conversions as necessary. For many situations, gamma-corrected sRGB is "good enough" hence its emphasis in the article.
  - astrange 10y ago
    > Ignoring the color space is hardly a world ender for most applications, but it has an effect on quality that can be subtle to drastic depending on what you're doing. For example, arcade games emulated in MAME often have a washed-out look by default because the monitor gamma isn't included(but it can be achieved through user customization). Actually, no emulator does gamma-correct scaling, and when I've tried adding some in the past a lot of games looked quite different and much darker. So different that I don't think most players, who grew up on emus instead of the real thing, would actually accept it. It was hard enough getting them to accept correct aspect ratios, since NES pixels weren't square either.
    - DiabloD3 10y ago
      The problem with gamma-correctness in emulators is you ALSO have to emulate limited nominal ranges (digitally, 16-235 for Y, 16-240 for UV) on top of doing NTSC or PAL coloring correctly. Since doing limited ranges on sRGB looks so weird (mainly, 16 is surprisingly bright for being black), some people gamma correct for 1.8 instead of 2.2... which is a hilarious value when you realize that is the gamma value for classic Macs.
      - astrange 10y ago
        I feel pretty good about the "unfiltered" display on an emulator being the original RGB. Seems like adding that 16-235 NTSC YUV conversion on top of 5-bit-per-channel SNES RGB would just make banding even worse, and not really look different? I mean, I don't like running with the accurately rainbowy and scanliney composite cable mode filters myself, and I thought I cared.
        DiabloD3 10y ago
        It won't make the banding worse. To do this naively: Mathematically, 5 bit is 32 values. Multiply each value step by 8, and you get 0, 8 .. 256. Multiply each step by 7, and you get 0, 7 ... 224. Offset each step by 16, you get 16, 17 ... 240. Also, some emulators do offer chroma subsampling effects just to make certain things look more accurate. That said, yes, all my emulation days involved "incorrect" SNES rendering: 5 bit per channel SNES RGB, with each step being +32, with no NTSC adjustment.
- johnnovak 10y ago
  The world wouldn't end without computers either, or in fact, without humans, so this is a moot point... :) As I mentioned in the article, you can get away with working directly in sRGB in some cases (general image processing, non-photorealistic rendering), but in some other cases it's a must (physically accurate photorealistic rendering). But ignoring it will always produce wrong results. You actually might like those results, but the important point I was trying to get through was to be aware of these potential issues, and then you may ignore them at your own peril.
- pfranz 10y ago
  Probably most people working in an industry related to graphics have no idea about this and things mostly work. If you get a dark band around something you can tweak it until it looks right or is good enough. I'm troubleshooting a problem right now where two separate applications blend images together and the result is different. Both results have been shipped to clients for years and fixing it is more of "tidying things up." But doing it right the first time or being aware helps things look right more often and can enable you to do more complex things without constantly having to tweak the results.
panic 10y ago
Nowadays GPUs are able to convert between sRGB and linear automatically when reading and writing textures. There's no more excuse for incorrect rendering on modern hardware!
- jblow 10y ago
  Actually no, there are plenty of excuses, because this stuff gets super confusing and it's easy to make a mistake.
  - kvark 10y ago
    How is The Witness doing w.r.t. gamma correctness? Any issues you can remember as an example of "super confusing" stuff?
    - jblow 10y ago
      If we made any mistakes, they are pretty small. What gets super confusing is that you have a bunch of different stuff flying around. You have textures in different formats and render targets in different formats (some are in sRGB, some are in HDR 16-bit floating-point, some are other random formats somewhere in-between). You need to set up your shader state to do the right thing for both the input texture and the render target, and the nuances of how to do this are going to change from system to system. Sometimes if you make a mistake it is easily spotted; other times it isn't. And then there are issues of vertex color, etc. Do you put your vertex colors in sRGB or linear space? Well, there are good reasons for either choice in different contexts. So maybe your engine provides both options. Well, now that's another thing for a programmer to accidentally get wrong sometimes. Maybe you want to introduce typechecked units to your floating-point colors to try and error-proof this, but we have not tried that and it might be annoying. All that said, everyone is about to rejigger their engines somewhat in order to be able to output to HDR TVs (we are in the process of doing this, and whereas it is not too terrible, it does involve throwing away some old stuff that doesn't make sense any more, and replace it by stuff that works a new way).
      - 10y ago
Glyptodon 10y ago
The thing that seems a bit weird to me is that the constant light intensity graduation (fig 1) appears much more even/linearly monotonic to me than the perceptual one (fig 2) which seems really off at the ends, kind of sticking to really really dark black for too long at the left end, shifting to white too fast at the right end.
- jusssi 10y ago
  You may want to check your display settings. Possibly too much contrast. Many TVs have horribly excessive color saturation and contrast settings by default, in order to look sharp and colorful (specifically, more sharp and colorful than the next brand) at the store. Maybe that applies to computer monitors too.
- johnnovak 10y ago
  Your display is severely miscalibrated. Do a gamma calibration first then try again, things should look very different then!
cscheid 10y ago
Hey, so gamma is not a logarithmic response. You claim that the delta you use in Figure 2 is a ratio, but your code, https://github.com/johnnovak/johnnovak.site/blob/master/blog/files/2016-09-21/src/gammaramp.nim#L64 https://github.com/johnnovak/johnnovak.site/blob/master/blog... uses a fixed power. These are not the same thing. f(x+eps)/f(x) ~= eps f'(x)/f(x) + 1 f(x) = x^2.2 f'(x) = 2.2x^1.2 f(x+eps)/f(x) ~= 1.2 eps/x + 1 Human response to light is not particularly well-modeled by a logarithmic response. It's --- no big surprise --- better modeled by a power law. This stuff is confusing because there's two perceptual "laws" that people like to cite: Fechner-Weber, and Stephens's. Fechner-Weber is logarithmic; Stephens's is a generalized power-law response.
- mark-r 10y ago
  A power law plotted on a logarithmic scale will be a straight line. log(x^2.2) == 2.2*log(x).
  - cscheid 10y ago
    You need log transformations on both axes for this to work.
    - Coding_Cat 10y ago
      For those whose algebra is rusty: Let y = ax^n Then log(y) = log(ax^n) = log(a)+log(x^n) = log(a) + log(x)*n i.e. and equation for a line when plotting log(y) vs. log(x).
    - mark-r 10y ago
      Yeah OK, after a little reflection I see where my mistake was. I wish there was a way to delete my comment.
- johnnovak 10y ago
  Your exactly right, my bad... I'll correct the article later today (and I'll also remove the word 'logarithmic' from a few places). Thanks!
- 10y ago
jadbox 10y ago
Interesting that Nim (lang) is used in the examples- good readable code too
- qwertyuiop924 10y ago
  Yeah, Nim is interesting, and pretty nice for gamedev (efficient, GCed when you want it, hand management when you don't, no stop-the-world, etc.). Personally, I haven't worked with it much yet, as there are just too many languages, and some of the semantics were immidiate turn-offs (static typing with very minimal inference, odd multi-assignment semantics, enforced use of discard (which discourages minimal APIs, and encourages functions with side-effects to have no return value, which is a Bad Thing), requiring forward declarations (if you need it for metaprogramming, than why can Scheme and Lisp avoid it?), not defaulting to bignums, dynamic dispatch chosen by the creator of the original class, really clumsy macros, no hygene AFAICT (although two namespaces and a module system make this less of an issue: However, I doubt the module system was built to protect hygene. Somebody should look into this, so we can know for sure), really, really clumsy macros (I mean really, come on guys: macros aren't new: how did you even mess that up? You can totally do better than that, even without parens. But if you add parens, it's so much easier. Clojure even made it socially acceptable!)).
  - perturbation 10y ago
    Could you expand on the lack of hygiene? I know Nim has hygienic templates by default, with an opt for 'injecting' variables into the enclosing scope (which comes in handy when (for example) you have a DSL for parsing command line options like the docopt.nim or commandeer packages). If you mean that whatever AST is generated by calling macro gets put in the enclosing scope - then yes, AFAIK you're right, but this can be fixed by wrapping a macro in a proc (function). I'll agree that forward declaration is really clumsy, I hope that that is fixed before 1.0.
    - qwertyuiop924 10y ago
      I meant that ASTs were non-hygenic, with all the problems therein, and nary a gensym to be seem, AFAICT. That's pretty bad. I also fail to see how wrapping a macro in a proc would help, unless you mean the call to the macro at the expansion site, which is a pretty clumsy thing to do, and actually doesn't fix most of the problems.
kevinwang 10y ago
On my iPhone, for the checkerboard resizing, the srgb-space resizing (b) is almost an exact match, while C appears much whiter.
- mark-r 10y ago
  Which is why he recommends not viewing the examples on a phone. Too bright is less noticeable than too dark, so I guess you're lucky it's off in that direction. It's also possible that the image file is a PNG with a gAMA chunk, which sometimes gets rendered incorrectly by browsers.
- johnnovak 10y ago
  I get a similar behaviour on my Android phone. As I mentioned in the article, that example doesn't work on most phone LCD screens. Try it on a real desktop monitor!
  - dingaling 10y ago
    > Try viewing it on a real desktop monitor! You keep saying this, but many people don't have a real desktop monitor. Laptop sales exceed desktop sales and both are dwarfed even by tablets alone. So whether it's technically the correct approach is irrelevant for a large proportion of potential end-users, for whom it will look broken.
    - johnnovak 10y ago
      Sorry, I can't magically fix all the mobile device screens of the world so they will start displaying images in a gamma-correct way... The fact is, the owners of such devices will never see gamma correct images on their screens, at least until the manufacturers fix this. It sucks but I can't help there. Anyway, I think you have bigger problems than gamma with those devices anyway (glare, reflections etc.), so that's probably the least of your concerns.
- zx2c4 10y ago
  Yep, for me too on a 4k HiDPI screen. The reason is that the browser scales the original image, using the naive incorrect algorithm. Amazing full-circle confirmation of the author's point, eh?
wfunction 10y ago
Can anyone get IrfanView to output the correct image? I'm trying the latest version I can find and it still gives me full gray.
twothamendment 10y ago
I know and love my gamma. She makes the best cookies!
Negitivefrags 10y ago
Something that is important to note is that in photoshop the default is gamma incorrect blending. If you work on game textures, and especially for effects like particles, it's important that you change the photoshop option to use gamma correct alpha blending. If you don't, you will get inconsistent results between your game engine and what you author in photoshop. This isn't as important for normal image editing because the resulting image is just being viewed directly and you just edit until it looks right.
- johnnovak 10y ago
  Yep, that bit about Photoshop is being mentioned in the description of Figure 8.
deleted 10y ago
[deleted]
jnordwick 10y ago
Gamma? http://www.investopedia.com/terms/g/gamma.asp http://www.investopedia.com/terms/g/gamma.asp
ansgri 10y ago
Enough has been said about incorrect gamma (this and [0]), now I think it's high time to bash the software of the world for incorrect downscaling (e.g. [1]). It has much more visible effects, and has real consequences for computer vision algorithms. In the course on computer vision in my university (which I help teaching) we teach this stuff to make students understand physics, but at the end of the lecture I'd always note that for vision it's largely irrelevant and isn't worth the cycles to convert image to the linear scale. [0] http://www.4p8.com/eric.brasseur/gamma.html http://www.4p8.com/eric.brasseur/gamma.html [1] http://photo.stackexchange.com/questions/53820/why-do-photos-of-digital-screens-turn-out-the-way-they-do http://photo.stackexchange.com/questions/53820/why-do-photos...
- anotheryou 10y ago
  ugh, yes. smart objects in photoshop downscale way uglier than pure pixel images (even when rasterizing the smart objects after the transform), no Idea why.
  - joelkesler 10y ago
    The resizing algorithm set in the photoshop preferences (bicubic, etc) is applied when resizing smart objects. I have found that if I am unhappy with how one algorithm looks, I switch to another, free transform the smart object (but make no sizing adjustment) and hit enter. The object will be rerendered with the newly selected algorithm.
    - anotheryou 10y ago
      I found the settings, but somehow it's just still not the same. I now do the smart object stuff until it's all settled, than resize to 100%, rasterize and resize back to what I had set.
- goatface 10y ago
  The development version of GIMP (the 2.9 series) - which will be come 2.10 uses GEGL which always does scaling with linear light encoding; as well as premultiplied alpha, regardless of what color "mode" the project is in. Getting scaling and resampling right in all cases is easier than retroactively fix the prevalent bad habit of non-linear compositing..
qwertyuiop924 10y ago
I'd already seen most of this in a video (courtesy of Henry, aka MinutePhysics, https://m.youtube.com/watch?v=LKnqECcg6Gw https://m.youtube.com/watch?v=LKnqECcg6Gw), but it was nice to see a programmer-oriented explanation, nonetheless.
j2kun 10y ago
Is this why my computer screen's brightness controls always seem to have a huge jump between the lowest two settings (off and dimmest-before-off)?
- Symbiote 10y ago
  That's probably a sign of a cheap monitor. You can try the calibration instructions here, which does a decent job of calibrating the monitor, and showing you whether yours is good or not: http://www.lagom.nl/lcd-test/ http://www.lagom.nl/lcd-test/
mxfh 10y ago
Good reminder about these persisting blending issues in the linear interpretation of RGB values, which was well explained to non-coders as well here in a quite popular MinutePhysics video: https://www.youtube.com/watch?v=LKnqECcg6Gw https://www.youtube.com/watch?v=LKnqECcg6Gw As others commented the gamma scaling issues seem even more relevant. Just please, don't use RGB color space for generating gradients. In fact, it's ill fitted for most operations concerning the perception of colors as is. chroma.js: https://vis4.net/blog/posts/mastering-multi-hued-color-scales/ https://vis4.net/blog/posts/mastering-multi-hued-color-scale... D3: https://bl.ocks.org/mbostock/3014589 https://bl.ocks.org/mbostock/3014589 Interesting excursion: historically the default viewing gammas seem to have lowered, because broadcasting defaulted to dimly lit rooms, while today's ubiquitous displays are usually in brighter environments. https://www.w3.org/Graphics/Color/sRGB.html https://www.w3.org/Graphics/Color/sRGB.html
skierscott 10y ago
I work on algorithms that can be applied to images, and was equally surprised when I saw a video called "Computer color is broken." I investigated and wrote a post called "Computer color is only kinda broken"[1]. This post includes visuals and investigates mixing two colors together in different colorspaces. [1]:http://scottsievert.com/blog/2015/04/23/image-sqrt/ http://scottsievert.com/blog/2015/04/23/image-sqrt/
jacobolus 10y ago
One thing I hate is that essentially all vector graphics and text rendering (Cairo, Quartz, MS Windows, Adobe apps, ...) is done with gamma-oblivious antialiasing, which means that apparent stroke width / text color changes as you scale text up or down. This is why if you render vector graphics to a raster image at high resolution and then scale the image down (using high quality resampling), you get something that looks substantially thinner/lighter than a vector render. This causes all kinds of problems with accurately rendering very detailed vector images full of fine lines and detailed patterns (e.g. zoomed out maps). It also breaks WYSIWYG between high-resolution printing and screen renders. (It doesn’t help that the antialiasing in common vector graphics / text renderers are also fairly inaccurate in general for detailed shapes, leading to weird seams etc.) But nobody can afford to fix their gamma handling code for on-screen rendering, because all the screen fonts we use were designed with the assumption of wrong gamma treatment, which means most text will look too thin after the change. * * * To see a prototype of a better vector graphics implementation than anything in current production, and some nice demo images of how broken current implementations are when they hit complicated graphics, check this 2014 paper: http://w3.impa.br/~diego/projects/GanEtAl14/ http://w3.impa.br/~diego/projects/GanEtAl14/
- panic 10y ago
  But nobody can afford to fix their gamma handling code for on-screen rendering, because all the screen fonts we use were designed with the assumption of wrong gamma treatment, which means most text will look too thin after the change. OS X dilates glyphs when using (linear) LCD antialiasing to counteract this effect. Chrome was having problems getting consistent text rendering in different contexts because of this dilation: https://lists.w3.org/Archives/Public/www-style/2012Oct/0109.html https://lists.w3.org/Archives/Public/www-style/2012Oct/0109....
- johnnovak 10y ago
  Ah, this line width problem with vector graphics has been bothering me for ages... Now it makes perfect sense! I suspected most fonts are designed for incorrect gamma handling, after all, designers just look at the gamme-incorrect output and then tweak it until it looks right. By the way, as I mentioned in my article, Photoshop has an option to use a custom gamma for text antialiasing, which is set to 1.42 by default (check out the antialiasing section). Vector graphics programs could adopt a similar workaround and things would be mostly fine.
elihu 10y ago
This is very good and useful; I'll have to update my ray-tracer accordingly. One thing not discussed though is what to do about values that don't fit in the zero-to-one range? In 3-D rendering, there is no maximum intensity of light, so what's the ideal strategy to truncate to the needed range?
- jacobolus 10y ago
  > what's the ideal strategy to truncate to the needed range? This depends on your aesthetic goals. There’s no single right answer here. There’s been a large amount of academic research into “high dynamic range imaging”. If you do a google scholar search, you can find hundreds of papers on the subject, I recommend you start with the most cited ones, and then follow the citation graph where your interests lead you. Or start with Wikipedia, https://en.wikipedia.org/wiki/High-dynamic-range_imaging https://en.wikipedia.org/wiki/High-dynamic-range_imaging
  - elihu 10y ago
    Mostly my goal is just "do the simplest thing that doesn't look bad". My naive approach is to just clamp the values to not exceed 1.0, but it occurs to me that it might be worth asking if there's something else I should be doing instead. I'm more interested in the computational and algorithmic side of ray-tracing, so I care more about things like constructing optimal bounding volume hierarchies than getting all the physically-correct-rending details right to produce the absolute best possible output. I just don't want the output to be ugly for easily fixable reasons.
    - pixel_fcker 10y ago
      Just clamping at 1.0 is fine. HDR tonemapping trying to emulate human vision is mostly bullshit and generally looks awful anyway. As long as you're rendering in a linear space (which means simply that you've gamma-corrected all your inputs) and displaying with a display gamma applied, then you're fine. Beyond that you might choose to emulate a "film look" by applying an S-curve to your image. EDIT: also, you really don't want to be clamping at all when saving images - just write out a floating-point OpenEXR file.
platz 10y ago
please dont use condescending titles barking what all coders should or shouldnt know (invariably the topic is a niche that the author wants to cajole others into caring about too)
- BetterThanYou 10y ago
  You've been downvoted or whatever that is called here. But you're right. I know all about that shit. I know more than most people have forgotten. But it's not something everyone needs to know. I can't even use my skills in a world where everyone needs a "full stack developer" but people keep pretending they're the person who does the interviews and (not pretending) treats them as an autistic "better than you" contest.
  - johnnovak 10y ago
    Sorry if you found the title condescending. In the intro section I also admit that I was ignorant about the whole gamma topic a few weeks ago. But I think it's an important topic, hence the title. Of course, 10 different people have 10 different opinions about what other people "should know". But this is a personal blog, and this is my personal opinion :) I guess you can't please everyone.
- Neeek 10y ago
  If you don't code around gamma then don't bother reading? I mean it says in the title, right there "about gamma", I don't see how that's drawing anyone else but the intended audience. I don't even deal in the article's subject matter but still found it interesting, informative, and well written; I think the condescending intent is coming entirely from you.
slacka 10y ago
> The graphics libraries of my operating system handle gamma correctly. (Only if your operating system is Mac OS X 10.6 or higher) Not just OS X. The majority of Linux games from the past 2 decades including all SDL and id tech 1-3 games relied on X server's gamma function. An X.Org Server update broken it about 6 years ago. It was fixed a few weeks ago. https://bugs.freedesktop.org/show_bug.cgi?id=27222 https://bugs.freedesktop.org/show_bug.cgi?id=27222
- johnnovak 10y ago
  My bad, I'm not really using Linux. I'll update the article, thanks! :)
kazinator 10y ago
I was going to comment snarkily: "Really? Every coder? What if you program toasters?" Then it immediately occurred to me that a toaster has some binary enumeration of the blackness level of the toast, like from 0 to 15, and this corresponds to a non-linear way to the actual darkness: i.e. yep, you have to know something about gamma.
- johnnovak 10y ago
  As arguably vision is the most important sensory channel in human-computer interaction, I'd say it doesn't hurt for all coders to have at least a vague understanding of gamma. I think it should be part of the "basic education". Of course, it's just my opinion :)
- mrob 10y ago
  Bread darkening accelerates with time under heating as the water levels reduce, so human vision isn't the only non-linearity here. For an ordinary consumer product I'd just test various breads to find the average time needed for light/medium/heavy toast, and linearly interpolate between those if I needed finer granularity, no gamma correction required. Hardly anybody knows about objective standards for toastedness, and they can always turn it up or down next time. Only if it's a fancy commercial toaster with optical feedback then gamma correction could matter.
  - kazinator 10y ago
    The whole combined nonlinearity could be one "toaster gamma" function, mapping from cooking time values to darkness level.
- kefka 10y ago
  Speaking of non-traditional applications of Gamma... In the 3d printing world, we have a filament of PLA (corn based plastic) with wood dust mixed in the plastic, of around 20%. This gives a filament that feels, machines, and colors like wood. And if you extrude at varying temps, you can give the part lighter or darker colors (darkness dependant on higher temp). I can almost guarantee that there's no gamma correction, let alone darkness calculation, being done for filaments like that. And it would follow an inverse power distribution - the more heat, the higher the power and the lower the final energy result (burnt = lower potential energy in wood). So yeah, even if you don't do graphics, it still applies. Damn...
reduxive 10y ago
This article could really benefit from an image DIFF widget. Even animated flashing GIF images would be an improvement. It needs something that not only permits comparable overlays, but (perhaps with a third diff layer) also highlights the ugly/wrong pixels with a high-contrast paint. A handful of images are only somewhat obviously problematic, but for most of the images, I really had to struggle to find undesirable artifacts. If it's that difficult to discern inconsistent image artifacts, one can understand why so little attention is often paid to this situation.
Retric 10y ago
Did anyone else think the first set of bars was linear not the second? I could not notice any difference between the leftmost three bars on the bottom section. Or does this relate to how iPad renders images or something? ed: Same issue on PC.
- johnnovak 10y ago
  It's most likely an iPad thing. Try viewing it on a real desktop monitor!
  - Retric 10y ago
    Nope, tried PC got same issue.
    - johnnovak 10y ago
      You need to calibrate your monitor then.
nichochar 10y ago
The design of your website, and it's readability, is great! Good job
- johnnovak 10y ago
  Thanks man, I'm a bit obsessed with these things and have spent way too much time on it. I'm glad someone notices and appreciates these details! :)
  - ShinyCyril 10y ago
    I absolutely loved the design too. Simple, readable, but still striking.
crazygringo 10y ago
This is one of the most fascinating articles I've come across on HN, and so well explained, so thank you. But I wonder about what the "right" way to blend gradients really is -- the article shows how linear blending of bright hues results in an arguably more natural transition. Yet a linear blending from black to white would actually, perceptually, feel too light -- exactly what Fig. 1 looks like -- the whole point is that a black-to-white gradient looks more even if calculated in sRGB, and not linearly. So for gradients intended to look good to human eyes, or more specifically that change at a perceptually constant rate, what is the right algorithm when color is taken into account? I wonder if relying just on gamma (which maps only brightness) is not enough, but whether there are equivalent curves for hue and saturation? For example, looking at any circular HSV color picker, we've very sensitive to changes around blue, and much less so around green -- is there an equivalent perceptual "gamma" for hue? Should we take that into an account for even better gradients, and calculate gradients as linear transitions in HSV rather than RGB?
- nitrogen 10y ago
  Maybe gradients should be computed in a more perceptually oriented colorspace like LAB, YCbCr, YIQ, XYZ, etc.
  - jjgreen 10y ago
    Like this? http://tristen.ca/hcl-picker/#/hlc/6/1/20313E/EFEE68 http://tristen.ca/hcl-picker/#/hlc/6/1/20313E/EFEE68
- tangent128 10y ago
  As I read it, for "physical correctness" gamma is the most important consideration. When selecting your initial color palette, though, it is true hue and saturation do have nonlinear perception. There are (somewhat complicated) color spaces designed to deal with that: https://en.wikipedia.org/wiki/Lab_color_space https://en.wikipedia.org/wiki/Lab_color_space http://www.husl-colors.org/ http://www.husl-colors.org/ lets you play with a compromise color space.
- johnnovak 10y ago
kevin_thibedeau 10y ago
What is usually little mentioned is that the transfer function for LCDs is a sigmoid rather than an exponential. The latter is simulated for desktop displays to maintain compatibility with CRTs. Embedded LCDs don't usually have this luxury.
- johnnovak 10y ago
  That's some very good info and it explains why the checkerboard pattern example looks completely off on all phones!
spunker540 10y ago
I don't think this is something every coder should know about-- maybe every graphics coder
- johnnovak 10y ago
  Ah, the title again... I'll promise I'll choose my title more carefully next time, so many people are hung up on this...
optimuspaul 10y ago
Lost me when he said the fig 2 appeared to have a more even gradation than fig 1, and not just because of the spelling error. The fig 1 looked more even to me, but I am colorblind.
- optimuspaul 10y ago
  Ok, I went further and became even more annoyed. I think in all of the examples the linear images looked way better. Could be due to the gamma correction my Mac does, or maybe the authors opinions are vastly different than mine.
  - johnnovak 10y ago
    It's not an opinion, check the references section for further info.
- johnnovak 10y ago
  It's always refreshing to meet people who never make spelling errors! :) Other than that, try calibrating your monitor!
tomjakubowski 10y ago
Hi John! If you're reading comments, I just thought you should know that the link to w3.org in the (color) "Gradients" section is broken. It should point to https://lists.w3.org/Archives/Public/www-style/2012Jan/0607.html https://lists.w3.org/Archives/Public/www-style/2012Jan/0607.... but there's an extra "o" at the end of the URL in your page's link.
- johnnovak 10y ago
  Thanks for that, I'll fix it later today!
  - tomjakubowski 10y ago
    Another one: "ray racer" is probably meant to be "ray tracer" (that, or my imagination is far too small) - and links to another broken page here http://blog.johnnovak.net/tags/ray%20tracing http://blog.johnnovak.net/tags/ray%20tracing
    - johnnovak 10y ago
      Thanks, good catch! No matter how many times I proofread my writings, some of these errors always slip through...
      - mctx 10y ago
        Also a couple of typos: "acceleation" and "sofware’s"
        johnnovak 10y ago
        Cheers, corrected!
mixmastamyk 10y ago
The conclusion reminded me of the "unicode sandwich," i.e. decode on data load, process in a pure form, then encode before writing to disk.
notlisted 10y ago
Beautiful description and great examples. One thing confuses me. I'm actually using PS CS5 (supposedly the last 'correct' one?) and resizing figure 11 to 50% actually results in B, not C. Is there an option/setting I can use to fix this?
- ondross 10y ago
  I think it's oddly worded - it's wrong as of CS6, meaning at the time of CS6 it is wrong, and it got fixed after that?
  - johnnovak 10y ago
    It's wrong in CS6, and that the only version of Photoshop I could test it with.
- johnnovak 10y ago
  Thanks, I'm glad you enjoyed the article. The only way I could get Photoshop to resize correctly was to convert the image to 32-bit first, do the resizing, then convert back to 8/16-bit (there might other simpler ways, though, but this is guaranteed to work). The image description actually describes this process.
inopinatus 10y ago
Um. Curiously, that first example didn't work for me. Figures 1 & 2, under "Light emission vs perceptual brightness" are compared thus: "On which image does the gradiation appear more even? It’s the second one!" Except that for me it isn't. The first one, graded by emission rather than perception, appears more evenly graded to me. There is no setting I can find using the Apple calibration tool (even in expert mode) that does anything but strengthen this perception. This raises only questions. Is this discrepancy caused by my Apple Thunderbolt Display? By my mild myopia? The natural lighting? My high-protein diet? The jazz on the stereo? The NSA? Or do I really have a different perception of light intensity? And is anyone else getting the same? Note: I have always had trouble with gamma correction during game setup; there has never been a setting I liked. Typically there'll be a request to adjust gamma until a character disappears, but however I fiddle things it never does.
- johnnovak 10y ago
  I highly doubt you perceive light intensity radically differently to your fellow humans... :) Most likely your monitor is miscalibrated. Try a few different gamma calibration images from other sources (Google Images -> "gamma calibration") and if they consistently indicate that your monitor is miscalibrated, then you have your answer.
  - pawadu 10y ago
    Well he never said he was a human. For all we know he could be The Terminator trying to find John Connor in Google Maps.
    - johnnovak 10y ago
      Instant upvote :)
    - witty_username 10y ago
      How do you know GP is male?
  - saucetenuto 10y ago
daredevildave 10y ago
And if you want to use a WebGL engine with gamma correct rendering... https://playcanvas.com https://playcanvas.com ;-) http://developer.playcanvas.com/en/user-manual/designer/settings/#gamma-correction http://developer.playcanvas.com/en/user-manual/designer/sett...
chmike 10y ago
Does it mean that when doing a conversion from sRGB encoding to physical intensity encoding we have to extend the number of bits to encode the physical intensity values to avoid rounding errors in the sRGB encoding ? I guess that that the required number of bits to encode physical intensity values depends on the operations. performed. The author suggest using floats, but this means 3x4 bytes and 4x4 bytes with the alpha channel. Would 16 bit unsigned integer be enough ? Floats are ok when using graphic cards, but not ok when using the processor.
- johnnovak 10y ago
  Yes, we need greater precision, ideally floats, but maybe 16 bits would be enough (haven't tested this or thought much about it.) But for multiple passes of processing floats are definitely the way to go due to rounding errors. I don't think you'd get worse performance when using floats on current hardware.
- elbows 10y ago
  16-bit integers are good enough for most image-processing algorithms. But you have to code pretty careful to avoid overflow or loss of precision in your intermediate values. Floating point is much easier to work with, and sometimes makes a difference with quality. On modern CPUs it's also about as fast as integer processing, if not a bit faster sometimes. On GPUs, it might actually be the other way around -- image processing tasks tend to be limited by memory bandwidth, so you might get better performance with 16-bit integers. But I haven't tried it.
emcq 10y ago
Meh gamma is a simplistic nonlinearity to model the world; if you care about perception use a CIE colorspace, if you care about gaming they have developed more sophisticated nonlinearities for HDR.
Alexey_Nigin 10y ago
I tried viewing the article on 4 different monitors. All monitors had default settings except for brightness. Monitors A & B were on new laptops, monitor C was on a very old laptop, and monitor D was on a smartphone. Here are the results: FIGURES 1 & 2. On monitor A, all bands of color in figure 1 were easily discernible. The first four bands of color in figure 2 looked identically. Figure 1 looked more evenly spaced than figure 2. On monitor B, all bands of color in figure 1 were easily discernible. The first five bands of color in figure 2 looked identically. Figure 1 looked more evenly spaced than figure 2. On monitor C, all bands of color except the last two in figure 1 were easily discernible. The first three bands of color in figure 2 looked identically. Figure 1 looked about as evenly spaced as figure 2. The result from monitor D was the same as the result from monitor A. FIGURE 12. On monitors A and B, the color of (A) was closer to (B) than to (C). On monitor C, (A) appeared equally close in color to (B) and (C). On monitor D, the color of (A) was exactly identical to (B). CONCLUSION: On monitor C, gamma correction had neutral effect. On all other monitors, the effects were negative. Unfortunately, I was unable to find a standalone PC monitor for my comparison. It is entirely possible that a PC monitor would give a different result. However, since most people use laptops and tablets nowadays, I doubt the article's premise that "every coder should know about gamma".
- johnnovak 10y ago
  Looks like you missed all the other artifacts I gave examples for, which are all calibration independent (colour blending, compositing, rendering etc.)
- odbol_ 10y ago
  It's kind of silly how he says "everyone needs to know about this; it's so important" and then the first example he preceded by saying that mobile phone screens basically can't tell the difference and don't matter.
kristofferR 10y ago
I get that this is an article about gamma, but it should have mentioned that sRGB is on the way out. People who need to think about gamma also need to think about wider color spaces like DCI-P3, which the Apple ecosystem is moving to pretty quickly (and others would be dumb to not follow).
- mark-r 10y ago
  Apparently DCI-P3 specifies 2.6 for the gamma, except that Apple sticks with a gamma of 2.2. Hopefully color management will be able to compensate in all situations. Either way, you still need to worry about gamma!
  - foolrush 10y ago
    Having peeled apart the iMac ICC, Apple is actually using the sRGB in their EOTFs.
pilooch 10y ago
I do AI, I let my CNN eat the gammas :)
sriku 10y ago
When viewing this on a macbook air, the discussion around the two images in the section "Light emission vs perceptual brightness" appears weird. To me, the first image appears linearly spaced and in the second image I can hardly make out the difference between the first few bars of black.
- hjnilsson 10y ago
  Imagine there is a light source farthest to the right. Which bar would accurately reflect how you expect the light to decrease from the source? It should be the second (linear) bar, that the difference between the last few levels of black is imperceptible could be attributed to the fact that the MBA has a quite poor screen.
anotheryou 10y ago
Can anyone recommend a tool/library to output at least full HD image fades to a video with correct gamma? Preferably even with dithering for finer steps when fading slowly. My main problem is that I'm not good at on-the-fly encoding and outputting frame by frame feels a bit excessive.
amelius 10y ago
> sRGB is a colour space that is the de-facto standard for consumer electronic devices nowadays, including monitors, digital cameras, scanners, printers and handheld devices. It is also the standard colour space for images on the Internet. Ok, does that mean that the device performs the gamma-transformation for me, and I don't need to worry about gamma? (and if not, why not?)
datenwolf 10y ago
I think the deep underlying problem is not just handling gamma but that to this day the graphics systems we use make programs output their graphics output in the color space of the connected display device. If graphics system coders in the late 1980-ies and early 1990-ies would have bothered to just think for a moment and look at the existing research then the APIs we're using today would expect colors in linear contact color space. Practically all the problems described in the article (which BTW has a few factual inaccuracies regarding the technical details on the how and why of gamma) vanish if graphics operations are performed in a linear contact color space. The most robust choice would have been CIE1931 (aka XYZ1931). Doing linear operations in CIE Lab also avoids the gamma problems (the L component is linear as well), however the chroma transformation between XYZ and the ab component of Lab is nonlinear. However from a image processing and manipulation point of view doing linear operations also on the ab components of Lab will actually yield the "expected" results. The biggest drawback with contact color spaces is, that 8 bits of dynamic range are insufficient for the L channel; 10 bits is sufficient, but in general one wants at least 12 bits. In terms of 32 bits per pixel practical distribution is 12L 10a 10b. Unfortunately current GPUs experience a performance penality with this kind of alignment. So in practice one is going to use a 16 bits per channel format. One must be aware that aside the linear XYZ and Lab color spaces, even if a contact color space is used images are often stored with a nonlinear mapping. For example DCI compliant digital cinema package video essence encoding is specified to be stored as CIE1931 XYZ with D65 whitepoint and a gamma=2.6 mapping applied, using 12 bits per channel.
- contingencies 10y ago
  Wow. May I ask how/where you learned all that?
  - jacobolus 10y ago
    If you want to learn about color, the best source on the web is http://www.handprint.com/LS/CVS/color.html http://www.handprint.com/LS/CVS/color.html There are some (in my opinion) better explanations in books, but it’s hard to link people to books. :-)
  - deleted 10y ago
catpolice 10y ago
As a pedantic writer, it annoys me that the article starts by mentioning a quiz and making a big deal about answering yes or no to the questions... but there aren't actually any questions. The "quiz" is a list of statements. Each one can be understood by context to imply a question about whether you agree with the statement, but it's distracting because you can't answer yes to something that isn't a question.

560 points by johnnovak 10y ago

I'm divided; I really want the article to be true, and for everyone to realise what a whole mistake we've been making all along... but, as the legions of us who don't adjust for gamma demonstrate, ignoring it doesn't make the world end?!

ploxiln 10y ago
Nope, world doesn't end, but scaled images look wrong, some more than others. For more examples see http://www.4p8.com/eric.brasseur/gamma.html http://www.4p8.com/eric.brasseur/gamma.html
zubat 10y ago
Ignoring the color space is hardly a world ender for most applications, but it has an effect on quality that can be subtle to drastic depending on what you're doing. For example, arcade games emulated in MAME often have a washed-out look by default because the monitor gamma isn't included(but it can be achieved through user customization). One thing the article misses is a process or checklist to discover your requirements for color spaces. Characterizing it as a gamma-only problem isn't entirely correct since we also have completely different models of color(e.g. LAB, HSV, YUV) that make tradeoffs for different applications. So, something like: 1. Input data: if it contains gamma data or specifies a color space use that, else assume linear sRGB. 2. Output device: is gamma correction done for you/can you access information about the device capabilities and lighting situation? This can inform viewing conditions. For example, if your smartphone has a light sensor this can be used to adjust gamma as well as backlighting to achieve a near-linear perceptual response. Most apps wouldn't consider doing this of course. If the output is a file or stream determine the most likely use cases and convert as necessary. 3. Internal processing. For each image or signal you process, determine its input color space, and the ideal color space to run it in. Then decide which approximation is an appropriate trade-off for your application(since many color space conversions are compute-intense), and implement conversions as necessary. For many situations, gamma-corrected sRGB is "good enough" hence its emphasis in the article.
- astrange 10y ago
  > Ignoring the color space is hardly a world ender for most applications, but it has an effect on quality that can be subtle to drastic depending on what you're doing. For example, arcade games emulated in MAME often have a washed-out look by default because the monitor gamma isn't included(but it can be achieved through user customization). Actually, no emulator does gamma-correct scaling, and when I've tried adding some in the past a lot of games looked quite different and much darker. So different that I don't think most players, who grew up on emus instead of the real thing, would actually accept it. It was hard enough getting them to accept correct aspect ratios, since NES pixels weren't square either.
  - DiabloD3 10y ago
    The problem with gamma-correctness in emulators is you ALSO have to emulate limited nominal ranges (digitally, 16-235 for Y, 16-240 for UV) on top of doing NTSC or PAL coloring correctly. Since doing limited ranges on sRGB looks so weird (mainly, 16 is surprisingly bright for being black), some people gamma correct for 1.8 instead of 2.2... which is a hilarious value when you realize that is the gamma value for classic Macs.
    - astrange 10y ago
      I feel pretty good about the "unfiltered" display on an emulator being the original RGB. Seems like adding that 16-235 NTSC YUV conversion on top of 5-bit-per-channel SNES RGB would just make banding even worse, and not really look different? I mean, I don't like running with the accurately rainbowy and scanliney composite cable mode filters myself, and I thought I cared.
      - DiabloD3 10y ago
        It won't make the banding worse. To do this naively: Mathematically, 5 bit is 32 values. Multiply each value step by 8, and you get 0, 8 .. 256. Multiply each step by 7, and you get 0, 7 ... 224. Offset each step by 16, you get 16, 17 ... 240. Also, some emulators do offer chroma subsampling effects just to make certain things look more accurate. That said, yes, all my emulation days involved "incorrect" SNES rendering: 5 bit per channel SNES RGB, with each step being +32, with no NTSC adjustment.
johnnovak 10y ago
The world wouldn't end without computers either, or in fact, without humans, so this is a moot point... :) As I mentioned in the article, you can get away with working directly in sRGB in some cases (general image processing, non-photorealistic rendering), but in some other cases it's a must (physically accurate photorealistic rendering). But ignoring it will always produce wrong results. You actually might like those results, but the important point I was trying to get through was to be aware of these potential issues, and then you may ignore them at your own peril.
pfranz 10y ago
Probably most people working in an industry related to graphics have no idea about this and things mostly work. If you get a dark band around something you can tweak it until it looks right or is good enough. I'm troubleshooting a problem right now where two separate applications blend images together and the result is different. Both results have been shipped to clients for years and fixing it is more of "tidying things up." But doing it right the first time or being aware helps things look right more often and can enable you to do more complex things without constantly having to tweak the results.

panic 10y ago

Nowadays GPUs are able to convert between sRGB and linear automatically when reading and writing textures. There's no more excuse for incorrect rendering on modern hardware!

jblow 10y ago
Actually no, there are plenty of excuses, because this stuff gets super confusing and it's easy to make a mistake.
- kvark 10y ago
  How is The Witness doing w.r.t. gamma correctness? Any issues you can remember as an example of "super confusing" stuff?
  - jblow 10y ago
    If we made any mistakes, they are pretty small. What gets super confusing is that you have a bunch of different stuff flying around. You have textures in different formats and render targets in different formats (some are in sRGB, some are in HDR 16-bit floating-point, some are other random formats somewhere in-between). You need to set up your shader state to do the right thing for both the input texture and the render target, and the nuances of how to do this are going to change from system to system. Sometimes if you make a mistake it is easily spotted; other times it isn't. And then there are issues of vertex color, etc. Do you put your vertex colors in sRGB or linear space? Well, there are good reasons for either choice in different contexts. So maybe your engine provides both options. Well, now that's another thing for a programmer to accidentally get wrong sometimes. Maybe you want to introduce typechecked units to your floating-point colors to try and error-proof this, but we have not tried that and it might be annoying. All that said, everyone is about to rejigger their engines somewhat in order to be able to output to HDR TVs (we are in the process of doing this, and whereas it is not too terrible, it does involve throwing away some old stuff that doesn't make sense any more, and replace it by stuff that works a new way).
    - 10y ago

Glyptodon 10y ago

The thing that seems a bit weird to me is that the constant light intensity graduation (fig 1) appears much more even/linearly monotonic to me than the perceptual one (fig 2) which seems really off at the ends, kind of sticking to really really dark black for too long at the left end, shifting to white too fast at the right end.

jusssi 10y ago
You may want to check your display settings. Possibly too much contrast. Many TVs have horribly excessive color saturation and contrast settings by default, in order to look sharp and colorful (specifically, more sharp and colorful than the next brand) at the store. Maybe that applies to computer monitors too.
johnnovak 10y ago
Your display is severely miscalibrated. Do a gamma calibration first then try again, things should look very different then!

cscheid 10y ago

Hey, so gamma is not a logarithmic response. You claim that the delta you use in Figure 2 is a ratio, but your code, https://github.com/johnnovak/johnnovak.site/blob/master/blog/files/2016-09-21/src/gammaramp.nim#L64 https://github.com/johnnovak/johnnovak.site/blob/master/blog... uses a fixed power. These are not the same thing. f(x+eps)/f(x) ~= eps f'(x)/f(x) + 1 f(x) = x^2.2 f'(x) = 2.2x^1.2 f(x+eps)/f(x) ~= 1.2 eps/x + 1 Human response to light is not particularly well-modeled by a logarithmic response. It's --- no big surprise --- better modeled by a power law. This stuff is confusing because there's two perceptual "laws" that people like to cite: Fechner-Weber, and Stephens's. Fechner-Weber is logarithmic; Stephens's is a generalized power-law response.

mark-r 10y ago
A power law plotted on a logarithmic scale will be a straight line. log(x^2.2) == 2.2*log(x).
- cscheid 10y ago
  You need log transformations on both axes for this to work.
  - Coding_Cat 10y ago
    For those whose algebra is rusty: Let y = ax^n Then log(y) = log(ax^n) = log(a)+log(x^n) = log(a) + log(x)*n i.e. and equation for a line when plotting log(y) vs. log(x).
  - mark-r 10y ago
    Yeah OK, after a little reflection I see where my mistake was. I wish there was a way to delete my comment.
johnnovak 10y ago
Your exactly right, my bad... I'll correct the article later today (and I'll also remove the word 'logarithmic' from a few places). Thanks!
10y ago

jadbox 10y ago

Interesting that Nim (lang) is used in the examples- good readable code too

qwertyuiop924 10y ago
Yeah, Nim is interesting, and pretty nice for gamedev (efficient, GCed when you want it, hand management when you don't, no stop-the-world, etc.). Personally, I haven't worked with it much yet, as there are just too many languages, and some of the semantics were immidiate turn-offs (static typing with very minimal inference, odd multi-assignment semantics, enforced use of discard (which discourages minimal APIs, and encourages functions with side-effects to have no return value, which is a Bad Thing), requiring forward declarations (if you need it for metaprogramming, than why can Scheme and Lisp avoid it?), not defaulting to bignums, dynamic dispatch chosen by the creator of the original class, really clumsy macros, no hygene AFAICT (although two namespaces and a module system make this less of an issue: However, I doubt the module system was built to protect hygene. Somebody should look into this, so we can know for sure), really, really clumsy macros (I mean really, come on guys: macros aren't new: how did you even mess that up? You can totally do better than that, even without parens. But if you add parens, it's so much easier. Clojure even made it socially acceptable!)).
- perturbation 10y ago
  Could you expand on the lack of hygiene? I know Nim has hygienic templates by default, with an opt for 'injecting' variables into the enclosing scope (which comes in handy when (for example) you have a DSL for parsing command line options like the docopt.nim or commandeer packages). If you mean that whatever AST is generated by calling macro gets put in the enclosing scope - then yes, AFAIK you're right, but this can be fixed by wrapping a macro in a proc (function). I'll agree that forward declaration is really clumsy, I hope that that is fixed before 1.0.
  - qwertyuiop924 10y ago
    I meant that ASTs were non-hygenic, with all the problems therein, and nary a gensym to be seem, AFAICT. That's pretty bad. I also fail to see how wrapping a macro in a proc would help, unless you mean the call to the macro at the expansion site, which is a pretty clumsy thing to do, and actually doesn't fix most of the problems.

kevinwang 10y ago

On my iPhone, for the checkerboard resizing, the srgb-space resizing (b) is almost an exact match, while C appears much whiter.

mark-r 10y ago
Which is why he recommends not viewing the examples on a phone. Too bright is less noticeable than too dark, so I guess you're lucky it's off in that direction. It's also possible that the image file is a PNG with a gAMA chunk, which sometimes gets rendered incorrectly by browsers.
johnnovak 10y ago
I get a similar behaviour on my Android phone. As I mentioned in the article, that example doesn't work on most phone LCD screens. Try it on a real desktop monitor!
- dingaling 10y ago
  > Try viewing it on a real desktop monitor! You keep saying this, but many people don't have a real desktop monitor. Laptop sales exceed desktop sales and both are dwarfed even by tablets alone. So whether it's technically the correct approach is irrelevant for a large proportion of potential end-users, for whom it will look broken.
  - johnnovak 10y ago
    Sorry, I can't magically fix all the mobile device screens of the world so they will start displaying images in a gamma-correct way... The fact is, the owners of such devices will never see gamma correct images on their screens, at least until the manufacturers fix this. It sucks but I can't help there. Anyway, I think you have bigger problems than gamma with those devices anyway (glare, reflections etc.), so that's probably the least of your concerns.
zx2c4 10y ago
Yep, for me too on a 4k HiDPI screen. The reason is that the browser scales the original image, using the naive incorrect algorithm. Amazing full-circle confirmation of the author's point, eh?

wfunction 10y ago

Can anyone get IrfanView to output the correct image? I'm trying the latest version I can find and it still gives me full gray.

twothamendment 10y ago

I know and love my gamma. She makes the best cookies!

Negitivefrags 10y ago

Something that is important to note is that in photoshop the default is gamma incorrect blending. If you work on game textures, and especially for effects like particles, it's important that you change the photoshop option to use gamma correct alpha blending. If you don't, you will get inconsistent results between your game engine and what you author in photoshop. This isn't as important for normal image editing because the resulting image is just being viewed directly and you just edit until it looks right.

johnnovak 10y ago
Yep, that bit about Photoshop is being mentioned in the description of Figure 8.

deleted 10y ago

[deleted]

jnordwick 10y ago

Gamma? http://www.investopedia.com/terms/g/gamma.asp http://www.investopedia.com/terms/g/gamma.asp

ansgri 10y ago

Enough has been said about incorrect gamma (this and [0]), now I think it's high time to bash the software of the world for incorrect downscaling (e.g. [1]). It has much more visible effects, and has real consequences for computer vision algorithms. In the course on computer vision in my university (which I help teaching) we teach this stuff to make students understand physics, but at the end of the lecture I'd always note that for vision it's largely irrelevant and isn't worth the cycles to convert image to the linear scale. [0] http://www.4p8.com/eric.brasseur/gamma.html http://www.4p8.com/eric.brasseur/gamma.html [1] http://photo.stackexchange.com/questions/53820/why-do-photos-of-digital-screens-turn-out-the-way-they-do http://photo.stackexchange.com/questions/53820/why-do-photos...

anotheryou 10y ago
ugh, yes. smart objects in photoshop downscale way uglier than pure pixel images (even when rasterizing the smart objects after the transform), no Idea why.
- joelkesler 10y ago
  The resizing algorithm set in the photoshop preferences (bicubic, etc) is applied when resizing smart objects. I have found that if I am unhappy with how one algorithm looks, I switch to another, free transform the smart object (but make no sizing adjustment) and hit enter. The object will be rerendered with the newly selected algorithm.
  - anotheryou 10y ago
    I found the settings, but somehow it's just still not the same. I now do the smart object stuff until it's all settled, than resize to 100%, rasterize and resize back to what I had set.
goatface 10y ago
The development version of GIMP (the 2.9 series) - which will be come 2.10 uses GEGL which always does scaling with linear light encoding; as well as premultiplied alpha, regardless of what color "mode" the project is in. Getting scaling and resampling right in all cases is easier than retroactively fix the prevalent bad habit of non-linear compositing..

qwertyuiop924 10y ago

I'd already seen most of this in a video (courtesy of Henry, aka MinutePhysics, https://m.youtube.com/watch?v=LKnqECcg6Gw https://m.youtube.com/watch?v=LKnqECcg6Gw), but it was nice to see a programmer-oriented explanation, nonetheless.

j2kun 10y ago

Is this why my computer screen's brightness controls always seem to have a huge jump between the lowest two settings (off and dimmest-before-off)?

Symbiote 10y ago
That's probably a sign of a cheap monitor. You can try the calibration instructions here, which does a decent job of calibrating the monitor, and showing you whether yours is good or not: http://www.lagom.nl/lcd-test/ http://www.lagom.nl/lcd-test/

mxfh 10y ago

Good reminder about these persisting blending issues in the linear interpretation of RGB values, which was well explained to non-coders as well here in a quite popular MinutePhysics video: https://www.youtube.com/watch?v=LKnqECcg6Gw https://www.youtube.com/watch?v=LKnqECcg6Gw As others commented the gamma scaling issues seem even more relevant. Just please, don't use RGB color space for generating gradients. In fact, it's ill fitted for most operations concerning the perception of colors as is. chroma.js: https://vis4.net/blog/posts/mastering-multi-hued-color-scales/ https://vis4.net/blog/posts/mastering-multi-hued-color-scale... D3: https://bl.ocks.org/mbostock/3014589 https://bl.ocks.org/mbostock/3014589 Interesting excursion: historically the default viewing gammas seem to have lowered, because broadcasting defaulted to dimly lit rooms, while today's ubiquitous displays are usually in brighter environments. https://www.w3.org/Graphics/Color/sRGB.html https://www.w3.org/Graphics/Color/sRGB.html

skierscott 10y ago

I work on algorithms that can be applied to images, and was equally surprised when I saw a video called "Computer color is broken." I investigated and wrote a post called "Computer color is only kinda broken"[1]. This post includes visuals and investigates mixing two colors together in different colorspaces. [1]:http://scottsievert.com/blog/2015/04/23/image-sqrt/ http://scottsievert.com/blog/2015/04/23/image-sqrt/

jacobolus 10y ago

One thing I hate is that essentially all vector graphics and text rendering (Cairo, Quartz, MS Windows, Adobe apps, ...) is done with gamma-oblivious antialiasing, which means that apparent stroke width / text color changes as you scale text up or down. This is why if you render vector graphics to a raster image at high resolution and then scale the image down (using high quality resampling), you get something that looks substantially thinner/lighter than a vector render. This causes all kinds of problems with accurately rendering very detailed vector images full of fine lines and detailed patterns (e.g. zoomed out maps). It also breaks WYSIWYG between high-resolution printing and screen renders. (It doesn’t help that the antialiasing in common vector graphics / text renderers are also fairly inaccurate in general for detailed shapes, leading to weird seams etc.) But nobody can afford to fix their gamma handling code for on-screen rendering, because all the screen fonts we use were designed with the assumption of wrong gamma treatment, which means most text will look too thin after the change. * * * To see a prototype of a better vector graphics implementation than anything in current production, and some nice demo images of how broken current implementations are when they hit complicated graphics, check this 2014 paper: http://w3.impa.br/~diego/projects/GanEtAl14/ http://w3.impa.br/~diego/projects/GanEtAl14/

panic 10y ago
But nobody can afford to fix their gamma handling code for on-screen rendering, because all the screen fonts we use were designed with the assumption of wrong gamma treatment, which means most text will look too thin after the change. OS X dilates glyphs when using (linear) LCD antialiasing to counteract this effect. Chrome was having problems getting consistent text rendering in different contexts because of this dilation: https://lists.w3.org/Archives/Public/www-style/2012Oct/0109.html https://lists.w3.org/Archives/Public/www-style/2012Oct/0109....
johnnovak 10y ago
Ah, this line width problem with vector graphics has been bothering me for ages... Now it makes perfect sense! I suspected most fonts are designed for incorrect gamma handling, after all, designers just look at the gamme-incorrect output and then tweak it until it looks right. By the way, as I mentioned in my article, Photoshop has an option to use a custom gamma for text antialiasing, which is set to 1.42 by default (check out the antialiasing section). Vector graphics programs could adopt a similar workaround and things would be mostly fine.

elihu 10y ago

This is very good and useful; I'll have to update my ray-tracer accordingly. One thing not discussed though is what to do about values that don't fit in the zero-to-one range? In 3-D rendering, there is no maximum intensity of light, so what's the ideal strategy to truncate to the needed range?

jacobolus 10y ago
> what's the ideal strategy to truncate to the needed range? This depends on your aesthetic goals. There’s no single right answer here. There’s been a large amount of academic research into “high dynamic range imaging”. If you do a google scholar search, you can find hundreds of papers on the subject, I recommend you start with the most cited ones, and then follow the citation graph where your interests lead you. Or start with Wikipedia, https://en.wikipedia.org/wiki/High-dynamic-range_imaging https://en.wikipedia.org/wiki/High-dynamic-range_imaging
- elihu 10y ago
  Mostly my goal is just "do the simplest thing that doesn't look bad". My naive approach is to just clamp the values to not exceed 1.0, but it occurs to me that it might be worth asking if there's something else I should be doing instead. I'm more interested in the computational and algorithmic side of ray-tracing, so I care more about things like constructing optimal bounding volume hierarchies than getting all the physically-correct-rending details right to produce the absolute best possible output. I just don't want the output to be ugly for easily fixable reasons.
  - pixel_fcker 10y ago
    Just clamping at 1.0 is fine. HDR tonemapping trying to emulate human vision is mostly bullshit and generally looks awful anyway. As long as you're rendering in a linear space (which means simply that you've gamma-corrected all your inputs) and displaying with a display gamma applied, then you're fine. Beyond that you might choose to emulate a "film look" by applying an S-curve to your image. EDIT: also, you really don't want to be clamping at all when saving images - just write out a floating-point OpenEXR file.

platz 10y ago

please dont use condescending titles barking what all coders should or shouldnt know (invariably the topic is a niche that the author wants to cajole others into caring about too)

BetterThanYou 10y ago
You've been downvoted or whatever that is called here. But you're right. I know all about that shit. I know more than most people have forgotten. But it's not something everyone needs to know. I can't even use my skills in a world where everyone needs a "full stack developer" but people keep pretending they're the person who does the interviews and (not pretending) treats them as an autistic "better than you" contest.
- johnnovak 10y ago
  Sorry if you found the title condescending. In the intro section I also admit that I was ignorant about the whole gamma topic a few weeks ago. But I think it's an important topic, hence the title. Of course, 10 different people have 10 different opinions about what other people "should know". But this is a personal blog, and this is my personal opinion :) I guess you can't please everyone.
Neeek 10y ago
If you don't code around gamma then don't bother reading? I mean it says in the title, right there "about gamma", I don't see how that's drawing anyone else but the intended audience. I don't even deal in the article's subject matter but still found it interesting, informative, and well written; I think the condescending intent is coming entirely from you.

slacka 10y ago

> The graphics libraries of my operating system handle gamma correctly. (Only if your operating system is Mac OS X 10.6 or higher) Not just OS X. The majority of Linux games from the past 2 decades including all SDL and id tech 1-3 games relied on X server's gamma function. An X.Org Server update broken it about 6 years ago. It was fixed a few weeks ago. https://bugs.freedesktop.org/show_bug.cgi?id=27222 https://bugs.freedesktop.org/show_bug.cgi?id=27222

johnnovak 10y ago
My bad, I'm not really using Linux. I'll update the article, thanks! :)

kazinator 10y ago

I was going to comment snarkily: "Really? Every coder? What if you program toasters?" Then it immediately occurred to me that a toaster has some binary enumeration of the blackness level of the toast, like from 0 to 15, and this corresponds to a non-linear way to the actual darkness: i.e. yep, you have to know something about gamma.

johnnovak 10y ago
As arguably vision is the most important sensory channel in human-computer interaction, I'd say it doesn't hurt for all coders to have at least a vague understanding of gamma. I think it should be part of the "basic education". Of course, it's just my opinion :)
mrob 10y ago
Bread darkening accelerates with time under heating as the water levels reduce, so human vision isn't the only non-linearity here. For an ordinary consumer product I'd just test various breads to find the average time needed for light/medium/heavy toast, and linearly interpolate between those if I needed finer granularity, no gamma correction required. Hardly anybody knows about objective standards for toastedness, and they can always turn it up or down next time. Only if it's a fancy commercial toaster with optical feedback then gamma correction could matter.
- kazinator 10y ago
  The whole combined nonlinearity could be one "toaster gamma" function, mapping from cooking time values to darkness level.
kefka 10y ago
Speaking of non-traditional applications of Gamma... In the 3d printing world, we have a filament of PLA (corn based plastic) with wood dust mixed in the plastic, of around 20%. This gives a filament that feels, machines, and colors like wood. And if you extrude at varying temps, you can give the part lighter or darker colors (darkness dependant on higher temp). I can almost guarantee that there's no gamma correction, let alone darkness calculation, being done for filaments like that. And it would follow an inverse power distribution - the more heat, the higher the power and the lower the final energy result (burnt = lower potential energy in wood). So yeah, even if you don't do graphics, it still applies. Damn...

reduxive 10y ago

This article could really benefit from an image DIFF widget. Even animated flashing GIF images would be an improvement. It needs something that not only permits comparable overlays, but (perhaps with a third diff layer) also highlights the ugly/wrong pixels with a high-contrast paint. A handful of images are only somewhat obviously problematic, but for most of the images, I really had to struggle to find undesirable artifacts. If it's that difficult to discern inconsistent image artifacts, one can understand why so little attention is often paid to this situation.

Retric 10y ago

Did anyone else think the first set of bars was linear not the second? I could not notice any difference between the leftmost three bars on the bottom section. Or does this relate to how iPad renders images or something? ed: Same issue on PC.

johnnovak 10y ago
It's most likely an iPad thing. Try viewing it on a real desktop monitor!
- Retric 10y ago
  Nope, tried PC got same issue.
  - johnnovak 10y ago
    You need to calibrate your monitor then.

nichochar 10y ago

The design of your website, and it's readability, is great! Good job

johnnovak 10y ago
Thanks man, I'm a bit obsessed with these things and have spent way too much time on it. I'm glad someone notices and appreciates these details! :)
- ShinyCyril 10y ago
  I absolutely loved the design too. Simple, readable, but still striking.

crazygringo 10y ago

This is one of the most fascinating articles I've come across on HN, and so well explained, so thank you. But I wonder about what the "right" way to blend gradients really is -- the article shows how linear blending of bright hues results in an arguably more natural transition. Yet a linear blending from black to white would actually, perceptually, feel too light -- exactly what Fig. 1 looks like -- the whole point is that a black-to-white gradient looks more even if calculated in sRGB, and not linearly. So for gradients intended to look good to human eyes, or more specifically that change at a perceptually constant rate, what is the right algorithm when color is taken into account? I wonder if relying just on gamma (which maps only brightness) is not enough, but whether there are equivalent curves for hue and saturation? For example, looking at any circular HSV color picker, we've very sensitive to changes around blue, and much less so around green -- is there an equivalent perceptual "gamma" for hue? Should we take that into an account for even better gradients, and calculate gradients as linear transitions in HSV rather than RGB?

nitrogen 10y ago
Maybe gradients should be computed in a more perceptually oriented colorspace like LAB, YCbCr, YIQ, XYZ, etc.
- jjgreen 10y ago
  Like this? http://tristen.ca/hcl-picker/#/hlc/6/1/20313E/EFEE68 http://tristen.ca/hcl-picker/#/hlc/6/1/20313E/EFEE68
tangent128 10y ago
As I read it, for "physical correctness" gamma is the most important consideration. When selecting your initial color palette, though, it is true hue and saturation do have nonlinear perception. There are (somewhat complicated) color spaces designed to deal with that: https://en.wikipedia.org/wiki/Lab_color_space https://en.wikipedia.org/wiki/Lab_color_space http://www.husl-colors.org/ http://www.husl-colors.org/ lets you play with a compromise color space.
johnnovak 10y ago

kevin_thibedeau 10y ago

What is usually little mentioned is that the transfer function for LCDs is a sigmoid rather than an exponential. The latter is simulated for desktop displays to maintain compatibility with CRTs. Embedded LCDs don't usually have this luxury.

johnnovak 10y ago
That's some very good info and it explains why the checkerboard pattern example looks completely off on all phones!

spunker540 10y ago

I don't think this is something every coder should know about-- maybe every graphics coder

johnnovak 10y ago
Ah, the title again... I'll promise I'll choose my title more carefully next time, so many people are hung up on this...

optimuspaul 10y ago

Lost me when he said the fig 2 appeared to have a more even gradation than fig 1, and not just because of the spelling error. The fig 1 looked more even to me, but I am colorblind.

optimuspaul 10y ago
Ok, I went further and became even more annoyed. I think in all of the examples the linear images looked way better. Could be due to the gamma correction my Mac does, or maybe the authors opinions are vastly different than mine.
- johnnovak 10y ago
  It's not an opinion, check the references section for further info.
johnnovak 10y ago
It's always refreshing to meet people who never make spelling errors! :) Other than that, try calibrating your monitor!

tomjakubowski 10y ago

Hi John! If you're reading comments, I just thought you should know that the link to w3.org in the (color) "Gradients" section is broken. It should point to https://lists.w3.org/Archives/Public/www-style/2012Jan/0607.html https://lists.w3.org/Archives/Public/www-style/2012Jan/0607.... but there's an extra "o" at the end of the URL in your page's link.

johnnovak 10y ago
Thanks for that, I'll fix it later today!
- tomjakubowski 10y ago
  Another one: "ray racer" is probably meant to be "ray tracer" (that, or my imagination is far too small) - and links to another broken page here http://blog.johnnovak.net/tags/ray%20tracing http://blog.johnnovak.net/tags/ray%20tracing
  - johnnovak 10y ago
    Thanks, good catch! No matter how many times I proofread my writings, some of these errors always slip through...
    - mctx 10y ago
      Also a couple of typos: "acceleation" and "sofware’s"
      - johnnovak 10y ago
        Cheers, corrected!

mixmastamyk 10y ago

The conclusion reminded me of the "unicode sandwich," i.e. decode on data load, process in a pure form, then encode before writing to disk.

notlisted 10y ago

Beautiful description and great examples. One thing confuses me. I'm actually using PS CS5 (supposedly the last 'correct' one?) and resizing figure 11 to 50% actually results in B, not C. Is there an option/setting I can use to fix this?

ondross 10y ago
I think it's oddly worded - it's wrong as of CS6, meaning at the time of CS6 it is wrong, and it got fixed after that?
- johnnovak 10y ago
  It's wrong in CS6, and that the only version of Photoshop I could test it with.
johnnovak 10y ago
Thanks, I'm glad you enjoyed the article. The only way I could get Photoshop to resize correctly was to convert the image to 32-bit first, do the resizing, then convert back to 8/16-bit (there might other simpler ways, though, but this is guaranteed to work). The image description actually describes this process.

inopinatus 10y ago

Um. Curiously, that first example didn't work for me. Figures 1 & 2, under "Light emission vs perceptual brightness" are compared thus: "On which image does the gradiation appear more even? It’s the second one!" Except that for me it isn't. The first one, graded by emission rather than perception, appears more evenly graded to me. There is no setting I can find using the Apple calibration tool (even in expert mode) that does anything but strengthen this perception. This raises only questions. Is this discrepancy caused by my Apple Thunderbolt Display? By my mild myopia? The natural lighting? My high-protein diet? The jazz on the stereo? The NSA? Or do I really have a different perception of light intensity? And is anyone else getting the same? Note: I have always had trouble with gamma correction during game setup; there has never been a setting I liked. Typically there'll be a request to adjust gamma until a character disappears, but however I fiddle things it never does.

johnnovak 10y ago
I highly doubt you perceive light intensity radically differently to your fellow humans... :) Most likely your monitor is miscalibrated. Try a few different gamma calibration images from other sources (Google Images -> "gamma calibration") and if they consistently indicate that your monitor is miscalibrated, then you have your answer.
- pawadu 10y ago
  Well he never said he was a human. For all we know he could be The Terminator trying to find John Connor in Google Maps.
  - johnnovak 10y ago
    Instant upvote :)
  - witty_username 10y ago
    How do you know GP is male?
- saucetenuto 10y ago

daredevildave 10y ago

And if you want to use a WebGL engine with gamma correct rendering... https://playcanvas.com https://playcanvas.com ;-) http://developer.playcanvas.com/en/user-manual/designer/settings/#gamma-correction http://developer.playcanvas.com/en/user-manual/designer/sett...

chmike 10y ago

Does it mean that when doing a conversion from sRGB encoding to physical intensity encoding we have to extend the number of bits to encode the physical intensity values to avoid rounding errors in the sRGB encoding ? I guess that that the required number of bits to encode physical intensity values depends on the operations. performed. The author suggest using floats, but this means 3x4 bytes and 4x4 bytes with the alpha channel. Would 16 bit unsigned integer be enough ? Floats are ok when using graphic cards, but not ok when using the processor.

johnnovak 10y ago
Yes, we need greater precision, ideally floats, but maybe 16 bits would be enough (haven't tested this or thought much about it.) But for multiple passes of processing floats are definitely the way to go due to rounding errors. I don't think you'd get worse performance when using floats on current hardware.
elbows 10y ago
16-bit integers are good enough for most image-processing algorithms. But you have to code pretty careful to avoid overflow or loss of precision in your intermediate values. Floating point is much easier to work with, and sometimes makes a difference with quality. On modern CPUs it's also about as fast as integer processing, if not a bit faster sometimes. On GPUs, it might actually be the other way around -- image processing tasks tend to be limited by memory bandwidth, so you might get better performance with 16-bit integers. But I haven't tried it.

emcq 10y ago

Meh gamma is a simplistic nonlinearity to model the world; if you care about perception use a CIE colorspace, if you care about gaming they have developed more sophisticated nonlinearities for HDR.

Alexey_Nigin 10y ago

I tried viewing the article on 4 different monitors. All monitors had default settings except for brightness. Monitors A & B were on new laptops, monitor C was on a very old laptop, and monitor D was on a smartphone. Here are the results: FIGURES 1 & 2. On monitor A, all bands of color in figure 1 were easily discernible. The first four bands of color in figure 2 looked identically. Figure 1 looked more evenly spaced than figure 2. On monitor B, all bands of color in figure 1 were easily discernible. The first five bands of color in figure 2 looked identically. Figure 1 looked more evenly spaced than figure 2. On monitor C, all bands of color except the last two in figure 1 were easily discernible. The first three bands of color in figure 2 looked identically. Figure 1 looked about as evenly spaced as figure 2. The result from monitor D was the same as the result from monitor A. FIGURE 12. On monitors A and B, the color of (A) was closer to (B) than to (C). On monitor C, (A) appeared equally close in color to (B) and (C). On monitor D, the color of (A) was exactly identical to (B). CONCLUSION: On monitor C, gamma correction had neutral effect. On all other monitors, the effects were negative. Unfortunately, I was unable to find a standalone PC monitor for my comparison. It is entirely possible that a PC monitor would give a different result. However, since most people use laptops and tablets nowadays, I doubt the article's premise that "every coder should know about gamma".

johnnovak 10y ago
Looks like you missed all the other artifacts I gave examples for, which are all calibration independent (colour blending, compositing, rendering etc.)
odbol_ 10y ago
It's kind of silly how he says "everyone needs to know about this; it's so important" and then the first example he preceded by saying that mobile phone screens basically can't tell the difference and don't matter.

kristofferR 10y ago

I get that this is an article about gamma, but it should have mentioned that sRGB is on the way out. People who need to think about gamma also need to think about wider color spaces like DCI-P3, which the Apple ecosystem is moving to pretty quickly (and others would be dumb to not follow).

mark-r 10y ago
Apparently DCI-P3 specifies 2.6 for the gamma, except that Apple sticks with a gamma of 2.2. Hopefully color management will be able to compensate in all situations. Either way, you still need to worry about gamma!
- foolrush 10y ago
  Having peeled apart the iMac ICC, Apple is actually using the sRGB in their EOTFs.

pilooch 10y ago

I do AI, I let my CNN eat the gammas :)

sriku 10y ago

When viewing this on a macbook air, the discussion around the two images in the section "Light emission vs perceptual brightness" appears weird. To me, the first image appears linearly spaced and in the second image I can hardly make out the difference between the first few bars of black.

hjnilsson 10y ago
Imagine there is a light source farthest to the right. Which bar would accurately reflect how you expect the light to decrease from the source? It should be the second (linear) bar, that the difference between the last few levels of black is imperceptible could be attributed to the fact that the MBA has a quite poor screen.

anotheryou 10y ago

Can anyone recommend a tool/library to output at least full HD image fades to a video with correct gamma? Preferably even with dithering for finer steps when fading slowly. My main problem is that I'm not good at on-the-fly encoding and outputting frame by frame feels a bit excessive.

amelius 10y ago

> sRGB is a colour space that is the de-facto standard for consumer electronic devices nowadays, including monitors, digital cameras, scanners, printers and handheld devices. It is also the standard colour space for images on the Internet. Ok, does that mean that the device performs the gamma-transformation for me, and I don't need to worry about gamma? (and if not, why not?)

datenwolf 10y ago

I think the deep underlying problem is not just handling gamma but that to this day the graphics systems we use make programs output their graphics output in the color space of the connected display device. If graphics system coders in the late 1980-ies and early 1990-ies would have bothered to just think for a moment and look at the existing research then the APIs we're using today would expect colors in linear contact color space. Practically all the problems described in the article (which BTW has a few factual inaccuracies regarding the technical details on the how and why of gamma) vanish if graphics operations are performed in a linear contact color space. The most robust choice would have been CIE1931 (aka XYZ1931). Doing linear operations in CIE Lab also avoids the gamma problems (the L component is linear as well), however the chroma transformation between XYZ and the ab component of Lab is nonlinear. However from a image processing and manipulation point of view doing linear operations also on the ab components of Lab will actually yield the "expected" results. The biggest drawback with contact color spaces is, that 8 bits of dynamic range are insufficient for the L channel; 10 bits is sufficient, but in general one wants at least 12 bits. In terms of 32 bits per pixel practical distribution is 12L 10a 10b. Unfortunately current GPUs experience a performance penality with this kind of alignment. So in practice one is going to use a 16 bits per channel format. One must be aware that aside the linear XYZ and Lab color spaces, even if a contact color space is used images are often stored with a nonlinear mapping. For example DCI compliant digital cinema package video essence encoding is specified to be stored as CIE1931 XYZ with D65 whitepoint and a gamma=2.6 mapping applied, using 12 bits per channel.

contingencies 10y ago
Wow. May I ask how/where you learned all that?
- jacobolus 10y ago
  If you want to learn about color, the best source on the web is http://www.handprint.com/LS/CVS/color.html http://www.handprint.com/LS/CVS/color.html There are some (in my opinion) better explanations in books, but it’s hard to link people to books. :-)
- deleted 10y ago

catpolice 10y ago

As a pedantic writer, it annoys me that the article starts by mentioning a quiz and making a big deal about answering yes or no to the questions... but there aren't actually any questions. The "quiz" is a list of statements. Each one can be understood by context to imply a question about whether you agree with the statement, but it's distracting because you can't answer yes to something that isn't a question.