HN Debrief

What every coder should know about Gamma Correction

  • Graphics
  • Programming
  • Developer Tools
  • Web

The post is a long primer on gamma correction in digital imaging. It explains why most images are stored in a nonlinear form like sRGB, why arithmetic on those values can produce wrong-looking blends and gradients, and why converting to linear light before doing image math is often the right fix. People broadly agreed with the practical lesson that raw pixel values are not trustworthy as brightness values, especially in 8-bit pipelines. But they also said the article is dated and sloppy about what problem gamma encoding is actually solving. The biggest correction was that sRGB is not a perceptually uniform color space, and its transfer curve was not designed as a clean match for human vision. It is largely a legacy display and storage convention, so treating it as the right space for every visual operation leads to bad conclusions. That reframed the whole piece. Linear light is the right working space for operations tied to actual emitted light, like many compositing and filtering steps. It is not the universal answer for all appearance-driven tasks. For gradients, antialiasing, and some kinds of color interpolation, commenters said you often want a more perceptual space such as CIELAB or Oklab instead. Several comments also widened the scope beyond gamma alone. ICC profile handling, monitor behavior, limited-range video formats, and newer HDR or float16 pipelines all change the tradeoff. The practical consensus was simple: gamma bugs usually come from mismatched assumptions between stages of the pipeline, not from mysterious math.

If your product renders images, UI, video, or charts, treat "linear vs sRGB" as only the first decision. You need to be explicit about the color space for storage, blending, gradients, text, and export paths, or you will ship subtle but visible bugs.

Discussion mood

Mostly positive on the topic, but critical of the article's precision. People liked the basic warning against doing image math in encoded sRGB values, yet several commenters said the writeup confuses gamma correction with perceptual uniformity and oversells linear light as a one-size-fits-all answer.

Key insights

  1. 01

    sRGB is not perceptually uniform

    sRGB’s transfer function is a legacy encoding convention, not a true model of equal visual steps. That changes how you read the article’s examples. If your goal is human-looking interpolation or text edge coverage, neither raw sRGB nor linear light is automatically correct. You may need a perceptual color space instead.

    Stop using "perceptual" as shorthand for sRGB in design docs or rendering code. When an operation is judged by human appearance rather than physical light transport, test Oklab or another perceptual space before assuming linear fixes it.

      Attribution:
    • 20k #1
  2. 02

    The right space depends on the task

    Linear light is best for some operations because light adds linearly, but gradients are a different problem. Color ramps between vivid hues often look wrong in linear RGB, and Oklab can produce smoother results with fewer hue shifts. The useful rule is not "always linear". It is "choose the space that matches the operation."

    Break your pipeline into stages instead of picking one canonical space for everything. Use linear for compositing and energy-like math, then switch to a perceptual space for gradients, palette work, and other appearance-tuned output.

      Attribution:
    • zokier #1
    • raphlinus #1
    • leni536 #1
  3. 03

    HDR weakens the old 8-bit tradeoff

    The article’s core justification for gamma encoding is bit efficiency in limited integer formats. That logic gets weaker once you store color in float16, which already gives you far more usable precision across a wide range. New browser support for srgb-linear and display-p3-linear shows that more pipelines can now stay explicit about linear-light data instead of forcing everything through classic sRGB encoding.

    If you are building HDR, graphics, or pro imaging features, revisit assumptions inherited from 8-bit web image handling. Wider-gamut and linear color formats can simplify some processing paths and reduce pointless encode-decode churn.

      Attribution:
    • dmitshur #1
  4. 04

    Most gamma bugs are pipeline mismatches

    The recurring failure mode is not hard math. It is one stage assuming values mean light, another assuming they mean display-encoded samples, and a third silently converting or not converting. That is why the problem feels like coordinate-space bugs. The values are fine inside one convention and wrong the moment they cross a boundary without metadata or conversion.

    Audit every image boundary in your stack. File decode, texture upload, shader sampling, blending, resize, export, and CSS or UI presentation should each declare whether data is linear, sRGB-encoded, or something else.

      Attribution:
    • nicebyte #1 #2
  5. 05

    Zero does not always mean display black

    Even when people talk as if pixel code values map cleanly from black to white, common video formats do not. Limited-range YUV formats reserve headroom and footroom, so black can sit at a nonzero code value like 16 instead of 0. That makes naive assumptions about doubling values or interpreting histograms even less reliable once you leave simple full-range RGB images.

    Do not reuse image-processing assumptions across RGB and video paths without checking range conventions. If your product ingests camera, broadcast, or compressed video formats, validate full-range versus limited-range handling early.

      Attribution:
    • LoganDark #1
    • pavlov #1

Against the grain

  1. 01

    The article's visual proof is presentation-sensitive

    The grayscale example that is supposed to make one result obviously better did not land for everyone. Background color changes the judgment, and some viewers found the supposedly inferior version more evenly stepped. That is a useful warning against treating a single screenshot as decisive evidence for a color theory claim.

    When you justify rendering choices with visual comparisons, test them on different surrounds and displays. A demo that only works on one background is not strong enough to anchor a product decision.

      Attribution:
    • dheera #1
    • tobr #1
  2. 02

    Color management is the bigger modern problem

    Framing the issue as gamma correction misses how much of today’s pain comes from broader color-space handling and calibration. In a world with Oklab, wide-gamut displays, and mixed browser behavior, an older gamma-only explanation can point engineers at the wrong abstraction layer.

    If your team is debugging visual inconsistencies, start with end-to-end color management before chasing gamma constants. The wrong profile or display assumption can swamp smaller transfer-curve details.

      Attribution:
    • hatthew #1

In plain english

Antialiasing ↩
A rendering technique that smooths jagged edges by partially covering pixels at boundaries.
CIELAB ↩
A color space created to model perceived color differences more uniformly than device RGB spaces.
display-p3-linear ↩
A linear-light version of the Display P3 color space.
float16 ↩
A 16-bit floating-point numeric format often used in graphics to store values with more dynamic range than 8-bit integers.
Gamma correction ↩
A nonlinear encoding or decoding step used in imaging so stored numeric values do not map directly to emitted light intensity.
HDR ↩
High Dynamic Range, imaging that preserves a much wider range between dark and bright values than standard images.
ICC profile ↩
A data file that describes how a device or image represents color so software can convert colors correctly between devices and spaces.
Oklab ↩
A newer perceptual color space designed to give visually smoother interpolation and editing behavior than RGB spaces.
Perceptually uniform color space ↩
A color space designed so equal numeric steps correspond more closely to equal perceived visual differences.
sRGB ↩
Standard Red Green Blue, the common default color space for images and displays on the web, with a specific nonlinear transfer curve.
sRGB-linear ↩
A linear-light version of sRGB where the same primaries are used but numeric values are proportional to actual light intensity.
YUV ↩
A family of video color encodings that separate brightness information from color information.

Reference links

Color space references and tools