EOTF — Electro-Optical Transfer Function — is the display-side half of the transfer-function story. It defines how a TV converts the numbers in a video file into actual photons coming out of the screen. The opposite is the OETF (Opto-Electronic), which describes how a camera converts incoming light into stored numbers. Together they form a round trip: camera light → stored values → display light. EOTF is what makes that final step deterministic.
Why this is worth caring about: it's how the industry agrees that "code value 800 on this 10-bit signal" maps to "exactly 200 nits of brightness on the screen". Without a standard EOTF, every TV would interpret the same file differently — one a bit brighter, another a bit darker — and HDR especially would fall apart, because HDR's whole promise is precise brightness levels. The PQ EOTF (SMPTE ST 2084), used by HDR10 and Dolby Vision, defines absolute brightness from 0 to 10,000 nits and is what makes HDR signals look "the same" across compliant displays.
For a product team, EOTF is mostly an invisible plumbing concept, but it shows up at two places. Authoring: when you produce HDR content, you tag the EOTF (PQ, HLG, gamma) in the file's metadata so players know how to interpret the numbers. Get the tag wrong and the picture looks crushed or washed out. Conversion: when content needs to move between HDR and SDR, or between PQ and HLG, the player or transcoder has to do a careful EOTF translation that preserves the look. Tools like FFmpeg's zscale filter and professional grading systems handle this — but it's an active step, not something that happens automatically.
