About · 18 October 2026
An independent project, at an early stage
UDeep is the work of Mathew Newman (ORCID 0000-0003-1784-3250). It is an independent project, not affiliated with an institution or a standards body. The profile is a working draft, and the tools are a research preview.
Status
What exists, and what does not
| Piece | State |
|---|---|
| Profile, draft v0.3 (data-first) | written; open issues listed in its section 10. Tagged as version 0.3.0 on 17 October 2026; not yet released with a DOI |
| Python reference implementation | working, with tests; it reproduces all 90 shared test vectors. Writes and reads gain-map JPEGs and 16-bit PQ PNGs, and reads a PNG data record back as data, whatever its colour map. Matplotlib front end, with figures shown inline in a notebook |
| Shared native core library (Rust, with a C interface) | all 14 kinds implemented; it reproduces all 90 cases. Writes and reads gain-map JPEGs and 16-bit PQ PNGs. Its C interface is checked by a C program built against the header, with sanitizers, static analysis, Valgrind and Miri, and its file readers have been fuzzed. The Python package uses it wherever it is installed |
| Installable packages | wheels that carry the core are built for Linux, Windows and macOS (Intel and Apple silicon), and checked in a clean install; nothing is on PyPI yet |
| WebAssembly and JavaScript | the core built as WebAssembly reproduces every output of every golden case through its binding. The plain JavaScript port reproduces the 55 cases it implements: it does not compute stored levels or write the metadata and caption |
| Julia | a binding to the native core, tested on the shared test vectors, with a Makie extension that draws an HDR image and colour bar and saves the figure as a gain-map JPEG; it writes 16-bit PQ PNGs too, and it has counterparts of the four Python worked examples. Not registered as a package yet |
Conformance validator (python -m udeep.validate) | working, for gain-map JPEGs and 16-bit PQ PNGs. Every HDR figure in the gallery and on the home page passes the checks that can be made from the file alone, and with the data supplied it reads a data record back out of the file |
| Read by programs we did not write | Google's libultrahdr decodes the gain-map JPEGs as the reference does; FFmpeg reads the 16-bit PNG as BT.2020 PQ from its cICP chunk |
| Metadata in the files (profile section 8), and a caption generated from it | in gain-map JPEGs and 16-bit PNGs; the gallery's HDR files carry it. The namespace address has a page listing every property |
| Strictly increasing, reversible curve above the knee | done (profile 6.3) |
| Real-data gallery and device checks | six datasets; four check pages |
| GPU shader (WebGPU) | the mapping as a shader, tested on one graphics card against the shared test vectors, and a live view in the browser that draws data through it. The view agrees with the reference to 0.2 %; nobody has yet judged it on an HDR screen |
| Hybrid SVG writer; HDR video of real data | not yet |
| Evidence that HDR helps people read figures | none yet; a study is designed (below) |
| Device evidence | one phone and one monitor so far |
The missing evidence
A study that has been designed and not yet run
No one has shown that HDR helps people read a scientific figure. The planned study compares three versions of the same data, with tasks that have known answers:
- SDR clipped: the ordinary figure, with everything above the knee white.
- SDR compressed: the whole range squeezed into SDR. This is the best SDR alternative.
- HDR: the ordinary figure plus the range above white.
The predictions, to be registered in advance: above the knee, HDR does at least as well as the compressed figure, and both beat the clipped one. Below the knee, HDR equals the clipped figure, and both beat the compressed one. Reading values from the colour bar is no worse with HDR. If these hold, HDR is the only version that does not trade one range against the other. A null result would be published too.
It needs research-ethics approval before anyone is recruited, and it would benefit from a collaborator in vision science or in a field that reads such images every day. If that is you, please get in touch.
Help wanted
Tell us what your screen shows
The device evidence comes from two screens. Run the device checks and send the result. The details matter, because the same file can look different on different screens and settings.
Device and model: Operating system and version: Browser or app, and version: Brightness setting (and was automatic brightness on?): Room light (dark / dim / bright): Viewed directly, not over remote desktop: yes / no Format check (F0 to F6): which show the squares inside the white band? SVG check (S0 to S6, V1 to V3): Video check (V1 to V5): which play, and which show the squares? Precision check (each letter): bands / faint / smooth
Citing and reuse
How to cite it
Until a versioned release with a DOI exists, cite the repository and the profile version:
Newman, M. (2026). UDeep: Ultra Deep Range scientific figures and the UDeep Figure Profile, draft v0.3. https://github.com/ultradeeprange/udeep
The repository's CITATION.cff carries the same information in machine-readable form. Code is under
BSD-3-Clause; text, the profile and this site are under CC BY 4.0. Figures made from third-party data keep the terms
of their sources, listed on the gallery page.
Contact
Comments, corrections and collaboration
Use the issue tracker for comments on the profile, corrections to the evidence, and device reports. If you maintain a scientific application and want to try this in it, the apps page describes what is involved.