What a doubtful scientist asks first

Why would a scientific figure need HDR?

Because an ordinary figure stops at white, and most data doesn't.

A detector or a CT scanner records 12 to 16 bits, and an 8-bit figure has 256 levels. So the figure has to choose: set white for the faint part and clip the bright part flat, or fit the whole range in and lose the faint contrast. Radiologists switch between a soft-tissue window and a bone window for exactly this reason. An HDR screen can show light above the figure's white, so one file can keep the ordinary figure as it is and show what lies above it.

It isn't always worth it. In the real-data gallery it helped most where the range above white was large (a gravitational-wave signal peaking at 327 times the mean noise power) and added little where it was under 4 times (the M87 black hole), where an ordinary figure scaled to the peak shows the same structure.

More: the six real datasets, and what they taught.

Why not a log stretch or a better colour map?

Use one when it is enough. It is the comparison HDR has to beat.

A stretch fits the whole range into the same levels, so each part of the range gets fewer of them than it would on its own, and the faint part no longer looks the way it did. HDR keeps the ordinary figure below the knee and adds the rest above white, so neither range is traded for the other. Whether that is better in practice is the open question below. The planned study compares HDR with the whole range compressed into SDR, because that is the best SDR alternative, as well as with the ordinary clipped figure.

The colour maps are a separate matter. UDeep's two maps are built in Jzazbz, a perceptually uniform colour space that extends to HDR, and their lightness rises at every point for normal vision and for simulated protanopia, deuteranopia and tritanopia. Grey works too.

More: the planned study, and the colour-vision check.

Isn't brighter than white just a way to make a figure pop?

It can be, and the profile is written to stop that.

The mapping from data to brightness is one curve for the whole image, written into the file: no local tone mapping and no automatic boost. Below the knee the HDR figure is identical to the ordinary figure clipped at the same white, so nothing you could read before has changed. Above the knee the curve keeps rising to the top of the declared range, so every brightness maps back to one data value. Saturated or clipped pixels are never lifted above white.

The knee has to mean something: a physical threshold, a false-alarm level, or a domain preset such as a CT window. A knee set from a percentile is marked exploratory. And a side-by-side is only fair if the SDR part is the same in both: in the model tests, choosing a different white point or stretch was 2 to 7 times more visible than anything HDR added.

More: the idea in four rules, and section 6 of the profile.

Has anyone shown that it helps?

No. Nobody has shown that HDR helps people read scientific figures.

What exists so far are model predictions (ColorVideoVDP, with the display modelled), which show a small visible gain for sparse bright features, and a stronger result for a second range above white that rests on one CT slice. No observers were tested. In medical imaging, more grey levels helped in one pilot study and made no difference to accuracy in a larger one, more luminance alone did not help, and a prototype HDR display gave small gains on difficult cases.

Asking people which figure they prefer would not settle it. In Park and Montag's study of tone mapping for scientific images, what observers preferred and what they judged useful correlated weakly (R² = 0.31). A task-based study has been designed, with its predictions to be registered in advance and a null result to be published too. It has not been run.

More: the observer studies, the model results, and the planned study.

What if my screen, or my reader's, can't show HDR?

Then they see the ordinary figure, which is the point.

A gain-map JPEG is an ordinary JPEG with a second image inside it. A viewer that knows nothing of HDR shows the SDR figure, and an HDR viewer applies the gain up to its own headroom (ISO 21496-1). The SDR version is the figure of record, and every conclusion has to be readable from it.

If you aren't sure what your screen is doing, the device check has a white band with squares at 2, 4 and 8 times its white. If you can see the squares, you are seeing HDR. If the band is plain white, you are seeing the SDR version, as intended.

More: does my screen show HDR?, and what has been tested.

Can I put it in a paper?

Not as HDR yet. The paper carries the SDR figure, and that is complete by design.

PDF has no portable HDR: it can hold HDR only as private data that conforming viewers must ignore, and the PDF Association has chosen JPEG XL for HDR in future. The HDR version can go in the supplementary material, where the same file shows the ordinary figure to anyone without an HDR screen. Journals' image-integrity rules ask for processing that is global and declared, which is what the profile requires.

More: section 9.4 of the profile, and the standards.

How do I know a file used the mapping it says it did?

Check it. The validator reads what the file declares and tests it.

python -m udeep.validate figure.jpg reads the declaration, checks that it is complete and invertible and that nothing goes past the headroom, and, given the data and the SDR figure, checks that the file belongs with them and that its pixels are what that data and that figure make. Its report says how far it got: declared, consistent, or reproduced.

It can't tell you who made the file. The digests in a file link it to an array and to an SDR figure, but anyone who changes the data can work out new digests and write them in, so they are links, not signatures. Where that matters, publish the digest somewhere your readers already trust, such as the data repository's record of the dataset.

More: conformance, section 10, and security, section 16.

Will a bright figure be uncomfortable to look at?

Possibly. Nobody has a number for it.

Guidelines limit flashing to three flashes a second, but we found none that limits steady brightness or the size of a bright area. HDR production keeps levels above white for small highlights. The profile forbids flashing above white, requires that switching between HDR and SDR is started by the viewer, and asks pages to offer a limit. Every page on this site has a "Limit HDR" control.

More: comfort and accessibility, and section 14 of the profile.

A question that isn't here?

Ask it in the project's discussions on GitHub. Questions there are public, so anyone can read the answers, and the answer that settles a question is marked as the answer. Questions that come up often are added to this page. Reading needs no account; asking needs a GitHub account.

A fault in the tools, a report of what your screen shows, or a comment on the profile goes to the issue tracker instead.