# Nits Desk

> HDR is not brighter. It is a different curve. A pixel value is not a quantity of light —
> it is an index into a curve, and the same 0.5807 is a light grey under gamma and 203 nits
> under PQ. Nothing in the number says which.

https://nits-desk.skillsafe.ai/

## What it is

Five lanes over one graded master and the screens it has to survive, plus a **free
browser-side engine** that computes the curve. The engine costs nothing, needs no account,
and makes no network calls. Writing the report costs credits.

## The arithmetic

    PQ (SMPTE ST 2084), with the published constants:
      m1 = 2610/16384          m2 = (2523/4096) x 128
      c1 = 3424/4096           c2 = (2413/4096) x 32     c3 = (2392/4096) x 32
      code = ((c1 + c2 x Y^m1) / (1 + c3 x Y^m1))^m2      where Y = nits / 10000

    reference white   203 nits (ITU-R BT.2408), NOT the peak
    code share        |code(b) - code(a)|
    stops             log2(a / b)
    scaled map        nits x (screenPeak / sourcePeak)
    anchored map      reference white -> the screen's white, headroom spread above

## Figures that are exact, and surprising

- **Reference white is 203 nits and the peak is not white.** BT.2408 puts graphics white,
  subtitle white and the level an SDR picture sits at inside an HDR container all at 203. A
  1,000-nit master has **2.30 stops of headroom** above white, for speculars and skies.
- **The obvious tone map is why HDR looks dark, and the amount is exact.** Scaling by the
  ratio of the peaks puts reference white at **20.3 nits** on a 100-nit screen where a viewer
  expects 100 — **79.7 percent low**. The highlights keep their relationship to each other and
  the whole picture goes down with them.
- **More than half the code range is spent below 100 nits.** 50.8 percent of PQ covers the
  range SDR already had; 100 to 1,000 takes 24.4 percent and 1,000 to 10,000 takes 24.8. The
  curve is perceptual, so **HDR is mostly about the shadows** — the range at the top is what
  gets demonstrated in a shop.
- **Anchoring on white costs the highlights, exactly.** On a true SDR screen there is nothing
  above white, so all 2.30 stops land on one value. That is the trade, not a bug in the method.
- **Neither map is what a good tone mapper does.** A real one rolls off between them. They are
  the two ends, and they are worth computing because the ends bracket the decision and the dark
  one is what you get by default.
- **Absolute against relative is not a setting.** Under PQ a code value IS a number of nits, on
  every display that honours it. Under HLG it is a fraction of whatever the display can do, so
  the same file is a different picture on every screen — by design. A PQ signal sent to a
  display expecting gamma is interpreted with the wrong function end to end: it does not look
  slightly wrong, it looks washed out.
- **A screen that is merely dimmer shares a file.** A screen that wants a different curve never
  does. A 400-nit laptop clips 9.9 percent of the code range off a 1,000-nit master and keeps
  0.98 stops above white; a 100-nit projector clips 24.4 percent and keeps none.
- **MaxCLL is what stops a display dimming a picture that never needed it.** Without it a
  display tone-maps to the container's declared peak rather than to the content, so a 1,000-nit
  container whose brightest pixel is 320 nits gets treated as though it were full.

## The sheet

    GRADE
    name     | the launch film master
    curve    | pq
    peak     | 1000
    refwhite | 203
    maxcll   | 950
    maxfall  | 180

    SCREENS
    s1 | the reference monitor  | 1000 nits | pq
    s2 | a good laptop          | 400 nits  | pq
    s3 | the meeting-room projector | 100 nits | sdr

A screen row is `id | what it is | N nits | curve`; either attribute may be omitted. `curve` is
`pq`, `hlg`, `sdr` or `srgb` and **has no default** — without it the numbers are not quantities
of light and the page says so rather than guessing. `refwhite` defaults **by curve**: 203 nits
for an HDR one, the curve's own white for an SDR one, because an SDR master's white IS its peak.
Every assumption is reported, since the tone-mapping figures are all anchored to it.

## The lanes

- `plan` - decide the grade before the screens are known
- `check` - what this grade does on these screens (the primary lane)
- `curve` - what the numbers actually mean, and where the curve spends its code values
- `map` - what tone mapping costs, screen by screen, as the two ends of the decision
- `deliver` - what one master covers and what needs its own

## What it cannot do

It is arithmetic on declared metadata and **has not seen a frame**. The two tone maps are
endpoints rather than recommendations. It does not know what is in the picture — a grade whose
brightest pixel is one practical and one whose whole frame is a sky have identical metadata and
different answers. A stated peak is a claim about a display rather than about the content.
Figures for a relative curve are conditional on a stated screen brightness. And colour
primaries, matrix and black level are not looked at.

## Source

Lanes derived from the `image-manipulation-image-magick` skill in
[github/awesome-copilot](https://github.com/github/awesome-copilot), which converts, resizes and
inspects images — and whose metadata output includes the colour space, the one field that
decides whether the result looks right and the one nobody reads. Not affiliated with or endorsed
by the authors of that repository.

## API

https://nits-desk.skillsafe.ai/api.html