Standardisation approach · draft, 27 September 2026
Data first. Perception last.
A standard for scientific figures has to rest on what can be measured and checked: the data, its units and its uncertainty, and a declared mapping from value to light. How things look to the eye matters only at the final step, when the result is fitted to a particular screen. Draft v0.3 of the profile is organised in that order. It treats range and depth as separate questions, and not in tension with one another: how far above white a figure may reach is a matter of the mapping (layer 2), whilst how many levels a file must hold is set by the data's own uncertainty (layer 3).
The model
Five layers, from the data up
Named, reusable mappings, for example Highlight (sparse extremes above a high threshold) and Extend (a second range above the main one). They are conveniences built on layer 2, not rules.
The only place perception enters: fitting to the display's headroom (ISO 21496-1 weights, a BT.2390-form roll-off), dithering, and viewing conditions. Different screens may render differently; the file does not change.
Encoding must not add error larger than the data's own uncertainty. The eye's threshold (a DICOM GSDF JND) is a second, lower limit that says when more bits stop being visible. It is not the target.
One declared, global, monotonic and invertible function from data value to light, in multiples of SDR white (BT.2408). Invertible means a reader can always get from brightness back to the value. When the data is light (luminance maps, calibrated images, surface brightness), the mapping is proportional, so the display shows the true brightness ratios within its range. Otherwise, the knee is justified by the data: a physical threshold, a stated false-alarm level, or a domain preset.
The values, their units, their uncertainty, and a validity mask (saturated, clipped, bloomed or otherwise bad pixels, which never go above white), all kept at full precision. Every other layer is derived from this one.
Why this order: a standard rests on what can be tested. Layers 1–3 can be checked by a program
(udeep.validate). Layer 4 depends on the screen and the viewer, so it is guidance, measured with
the device checks and perceptual models, and never used as the basis for a rule.
Design principles
How the profile is written
- A profile, not a new format. It combines existing standards (BT.2100, ISO 21496-1, PNG
cICP, AVIF, JPEG XL, XMP, SVG). Anything that opens those files can open a conforming figure. - Safe fallback by construction. The SDR version is the figure of record, so adopting the profile never makes a figure worse on an ordinary screen or in print.
- Testable requirements. Every MUST can be checked by a program or a stated test. Evidence of benefit is reported separately and is not written into the rules.
- Small core, versioned. The normative core stays short. Changes are versioned, with a change log and a citable DOI for each version.
- Open. Text under CC BY 4.0, reference code under BSD-3, and no patent claims from the editors.
The route
From draft to standard
Community specification
A public, versioned draft, an issue tracker for comments, a reference implementation in Python with ports in JavaScript and Rust that are held to the same golden test vectors, and a conformance validator. A DOI for each version is planned; none has been issued yet.
Independent implementations
At least one implementation written by someone else, for example in another plotting ecosystem, that passes the same conformance tests. Standards bodies look for this: W3C's Recommendation track normally expects two independent implementations of each feature.
A home for the work
A W3C Community Group. Anyone may propose one, and it launches with five supporters. Its reports are community specifications, not W3C standards, but they are the recognised place to incubate a web-facing specification.
Liaison, not reinvention
Feed specific needs into the standards that already own each piece: CSS Color HDR (HDR colours for figure elements), the PDF Association (HDR in documents), ISO/TC 42 through a national body (gain maps), and domain bodies for their own conventions.
Precedents: FITS began as an astronomers' convention and was endorsed by the International Astronomical Union. Gain maps began as company specifications (Adobe, Google) before ISO standardised the common model as ISO 21496-1 in 2025. In both cases, community practice with working files came before the formal standard.
Why a profile
No existing format does all of it
A scientific figure that can be checked has to do five things at once: open anywhere as an ordinary figure, say exactly how its data became light, say how precisely it holds the data, name the data it was made from, and be signed so that a change shows. Each format below does some of that. As far as I have found, none does all of it. UDeep is therefore a profile on top of formats that already exist, adding only what none of them carries.
| Format | Opens anywhere | Declares data to light | States its precision | Names its data | Signed |
|---|---|---|---|---|---|
| Ordinary PNG or JPEG figure | yes | no | no (8 bits, unstated) | no | no |
| HDR photo formats (Ultra HDR JPEG, PQ AVIF) | yes | brightness only, with no data meaning | no | no | no |
| C2PA-signed image | yes | no | no | no | yes: who signed it, and that it is unchanged |
| PDF or SVG figure | yes | no | no | no | possible |
| Scientific data formats (FITS, HDF5, OME-TIFF) | specialist viewers | display settings, where kept, are not part of a standard figure | the data itself | it is the data | no |
| DICOM (medical) | medical viewers | yes, a window or lookup table | the data itself | it is the data | possible |
| UDeep | yes (gain-map JPEG, PNG) | yes, and invertible | yes, and checked | yes, by digest | C2PA, being tested |
DICOM comes closest: it declares how stored values are shown. It stays inside medical viewers, though, has no place in a paper or on a web page, and does not use the range of an HDR screen. The scientific data formats hold the data faithfully but not the figure, and a reader of a paper never sees them. UDeep takes the parts that exist (the gain-map JPEG, the 16-bit PNG, XMP metadata and C2PA) and adds the declared mapping, its precision and the link to the data.
ISO
Where it fits in ISO
ISO already standardises every building block the profile uses, and one ISO family, ISO 22028, is the natural home for what is missing. The profile builds on these standards rather than competing with them.
| ISO standard | Committee | What it provides | Role in the profile |
|---|---|---|---|
| ISO 22028-1 | TC 42 | Architecture for extended colour encodings, including image states (for example scene-referred and output-referred) | The frame for a new data-referred state |
| ISO/TS 22028-5:2023 (a full International Standard revision is in progress) | TC 42 | HDR/WCG encodings for still images from BT.2100 (PQ, HLG); nominal diffuse white; metadata for scene- and display-referred images; reference viewing conditions | The encoding layer. Our "SDR white" is its nominal diffuse white |
| ISO 21496-1:2025 | TC 42 | Gain maps: an SDR image plus a map applied up to each display's headroom | The compatibility delivery; the SDR base is the figure of record |
| ISO 15076-1 (ICC.1) | TC 130 | ICC colour profiles | Colour management of deliveries |
| ISO/IEC 18181 | JTC 1/SC 29 | JPEG XL: high bit depth, gain maps, extra channels | Archive delivery that can carry the data itself |
| ISO/IEC 23091-2 (ITU-T H.273) | JTC 1/SC 29 | Colour code points (as in PNG cICP) | Signalling in PNG and AVIF |
| ISO 16684-1 | TC 171 | XMP metadata | Carrier for the declared mapping |
| ISO 32000-2 | TC 171 | PDF 2.0 (HDR is not yet portable) | The publication form; SDR is the figure of record |
| ISO 3664 | TC 42 | Viewing conditions for graphic technology and photography | Reference for recording viewing conditions in device tests |
The contribution ISO does not have
ISO 22028 describes images that record a scene or are prepared for a display. A scientific figure is neither: its brightness is a declared function of measured data. The candidate contribution is a data-referred image state and its metadata, covering:
- the data unit and uncertainty;
- the invertible mapping from value to light;
- the knee and the rule that justifies it;
- the validity mask.
It would sit alongside the existing scene- and display-referred metadata of ISO 22028-5. That is a small, well-bounded addition to an existing family, not a new format.
How work gets into ISO
Through BSI
In the UK, BSI committee CPW/42 mirrors ISO/TC 42 and prepares the UK's input to it. Experts join through BSI. A national body such as BSI can propose a new work item, which the committee's members then vote on.
Through an organisation in liaison
Organisations in liaison with a committee can also propose new work. They can comment on drafts, but they do not vote.
Publicly Available Specification
ISO/IEC JTC 1 lets recognised submitters (W3C, OASIS, Khronos, the Joint Development Foundation) send a finished specification straight to ballot, in under a year instead of up to four. glTF 2.0 reached ISO/IEC this way. This route suits JTC 1 subjects, and requires a mature specification from such a body.
Suggested sequence.
- Align the profile with ISO 22028-5 and ISO 21496-1 now (terms, metadata, references).
- Build community practice and evidence (stages 1–2 above).
- Engage BSI CPW/42 and propose a Technical Report (informative: the evidence and the data-referred model).
- Then propose a Technical Specification (normative, published for trial use).
- Then an International Standard or an amendment to ISO 22028-5.
A trade-off to weigh: ISO documents are sold, and ISO holds the text's copyright. The community specification can stay free alongside, as other transposed specifications have done. ISO timelines are measured in years, so the open profile should keep moving meanwhile.
What changes in the profile
From v0.2 to v0.3
| v0.2 | v0.3 (6 October 2026) |
|---|---|
| Highlight and Extend described alongside the rules | Moved to informative presets (layer 5) |
| Precision set by the eye (JND) | Precision set by the data's uncertainty; the JND kept as the visibility limit |
| The mapping must be global and monotonic | …and invertible, with the inverse stated, plus a proportional "physical" mapping for data that is light |
| Metadata: mapping only | Metadata also records the data's uncertainty and validity mask |
| Roll-off shape in the requirements | Moved to display rendering (layer 4) |
| Terms of its own ("SDR white") | ISO 22028-5 terms (nominal diffuse white), with ISO 22028-5 and 22028-1 as normative references and a data-referred image state |
Since 6 October: the draft has gained rules on 7 and 8 October, among them colour maps defined as tables, digests that tie a file to its data and to its SDR figure, and an exact rule for how numbers are written. Each is listed with its date in the profile's Annex E.
Where the code stands: the reference implementation's curve now follows v0.3. It rises all the way
to the top of the range, where the old one flattened: at 2× headroom the old curve squeezed 39 % of a CT range above the
knee into the last 3 % of brightness. The figures on this site use the new curve. The code now writes the v0.3
metadata into its files, and the gallery's files carry it. A validator (udeep.validate) checks a file against its own declaration, and every HDR figure in the gallery and on the home page passes the checks it can make from the file alone. A file does not carry its data, so the pixel checks need the figure that made the file.