编程与软件工程blog.johnnovak.net
每个程序员都应了解的 Gamma
What every coder should know about gamma
2016 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇长文系统讲解了 gamma 的来龙去脉：人眼对亮度的感知是非线性的，而 CRT 显示器的响应也是非线性的，两者如何相互影响，以及为什么在图像缩放、混合、抗锯齿等操作中忽略 gamma 会导致错误的结果。文章用大量图例演示了 gamma 不正确的合成与渐变会产生的色带和明暗失真。
为什么经久不衰：它把一个几乎所有程序员都会踩坑却少有人讲清楚的视觉感知与色彩编码问题讲得透彻，多年后仍是理解图像渲染正确性的最佳入门读物。
HN 评论精选
主流矢量与文字渲染都忽略 gamma，导致缩放失真，且因字体依赖错误渲染而难以修复
我讨厌的一点是，几乎所有矢量图形和文字渲染（Cairo、Quartz、Windows、Adobe 应用……）都使用不考虑 gamma 的抗锯齿，导致描边粗细和文字颜色随缩放而变化。这就是为什么把矢量图形高分辨率渲染成位图再缩小后，看起来比直接矢量渲染更细更淡。这给精细矢量图的渲染带来各种问题，也破坏了打印与屏幕显示间的所见即所得。但没人能负担得起修复屏幕渲染的 gamma 处理，因为我们使用的屏幕字体都是在错误 gamma 假设下设计的，改对了文字反而会显得太细。
jacobolus查看英文原文
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/
指出文中把人眼感知误述为对数响应，实际更符合 Stevens 幂律
gamma 不是对数响应。你声称图 2 中的增量是比值，但你的代码用的是固定幂次，两者不是一回事。人眼对光的响应并不特别符合对数模型，而是更符合幂律。这容易混淆，因为人们常引用两种感知定律：Fechner-Weber（对数）和 Stevens（广义幂律）。
cscheid查看英文原文
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 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.
Photoshop 默认混合不考虑 gamma，做游戏纹理时必须手动开启正确混合
需要注意 Photoshop 默认使用 gamma 不正确的混合。如果你制作游戏纹理，尤其是粒子等特效，一定要把 Photoshop 改成 gamma 正确的 alpha 混合，否则游戏引擎里的结果会和你在 Photoshop 里做的对不上。普通修图倒无所谓，因为最终只是直接看图、调到好看为止。
Negitivefrags查看英文原文
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.
作者的个人感知与文中示例相反，说明人眼感知存在个体差异
奇怪，第一个例子在我这里不成立。文章说第二张渐变更均匀，但对我来说按发光强度渐变的第一张反而更均匀。我用 Apple 校准工具怎么调都改变不了这个感受。这到底是我的显示器、近视、环境光的问题，还是我真的对光强有不同的感知？还有别人和我一样吗？
inopinatus查看英文原文
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.
反驳文中关于字体设计的说法：字体细不是 gamma 造成的，用 gamma 调文字只是错误 hack
文章很棒，但有一处不对：说字体是为 gamma 不正确的光栅化器设计的，这完全不成立——字体主要是为高分辨率印刷设计的，gamma 基本无关。小字号在屏幕上正确渲染时显得过细，是因为白底黑字的视觉渗色、界面字体习惯偏粗、以及笔画不足一像素时的对比度问题，这些都与 gamma 无关。用 gamma 让文字变深只是个 hack，本质上是错误的。
crazygringo查看英文原文
This is a fantastic article, but one nitpick: > The reason for this is that most fonts have been designed for gamma-incorrect font rasterizers, hence if you use linear space (correctly), then the fonts will look thinner than they should. That's not true at all -- fonts are mostly designed for high-resolution printing where gamma is essentially irrelevant. Fonts in small sizes can look overly thin on computer screens when rendered "correctly" as black-on-white because 1) bright white surrounding a black letter can "bleed" into it in our vision, 2) we've become accustomed to comparatively bold fonts in computer interfaces and so fonts designed for print look thin by comparison, and 3) when stems are less than a pixel wide and therefore render as gray, this also introduces contrast problems (less of a problem on retina screens). None of these have anything to do with gamma. However, changing the gamma used in rendering actually does work as a "hack" to make letterforms darker with more contrast -- but it's actually entirely incorrect. Also with regarding small fonts, font designers have long known that the smaller a font is, the thicker its strokes should be proportionally, so some fonts come in optical sizes. "Text" or "book" weights are "normal", while "display" designed for larger sizes is thinner, and the occasional "small text" size is even thicker (often intended for classified listings, historically). If you look at typefaces actually designed primarily for computer screens rather than print, like Georgia and Verdana, you'll see they are indeed thicker, much like "small text" fonts.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选