Scoping WPT reftest coverage for JPEG XL HDR and wide-gamut color

[Minju-kim-igalia]

web-platform-tests/wpt#58481 added substantial JPEG XL coverage. HDR and wide-gamut color still look like an area where some focused follow-up would be useful.

The Interop 2026 JPEG XL roadmap calls out HDR / wide-gamut testing as an area where a solution or RFC would be useful, so I wanted to open a thread focused specifically on that part of the work.

I’m taking an initial look alongside Chromium issue 483413433 and web-platform-tests/wpt#44320 to better understand what automated coverage here might depend on.

To help structure that discussion, it seems useful to separate the work into:

1. shared screenshot / reference-output questions,
2. wide-gamut SDR cases,
3. HDR-specific cases such as PQ, HLG, and gain maps.

Input would be very helpful on:

• For wide-gamut SDR, should the first strict automated tests focus on the existing Adobe RGB / Display P3 / Rec.2020 coverage?
• If so, how should expected PNG references be generated for those tests: by a browser-independent rule, or by using one decoder implementation as the basis for the expected PNGs?
• For HDR, should the first automated target be PQ / HLG rendering behavior, while keeping gain maps in scope for the same RFC / design work?
• For strict reftest comparison in these cases, should the expectation be exact match, or a tightly-bounded fuzzy policy?
• Do we need small canonical assets for P3 / Rec.2020 / PQ / HLG / gain maps, rather than relying mainly on the current large conformance image and sRGB-only 3x3 fixtures?

[foolip]

Thanks for filing this, @Minju-kim-igalia! I might be the only person subscribed to this repo, and I missed this.

cc @hjanuschka

Input would be very helpful on:

• For wide-gamut SDR, should the first strict automated tests focus on the existing Adobe RGB / Display P3 / Rec.2020 coverage?

I think automating these tests is the most important, yes. It will require capturing screenshots in something other than 8-bit sRGB over WebDriver or WebDriver BiDi.

• If so, how should expected PNG references be generated for those tests: by a browser-independent rule, or by using one decoder implementation as the basis for the expected PNGs?

If HDR and wide gamut screenshots are defined in WebDriver (BiDi) and the format is one that can be decoded in Python, then I think following the same approach as the current reftest setup using 8-bit sRGB would make sense. IIRC it's up to the executor in wptrunner how to compare the test to the ref, but there could be a shared implementation for all browsers controlled by WebDriver.

• For HDR, should the first automated target be PQ / HLG rendering behavior, while keeping gain maps in scope for the same RFC / design work?

@veluca93 has told me that gain maps are still a very new thing in JPEG XL, there's no support in any encoder. So PQ and HLG certainly seem more important in practice.

• For strict reftest comparison in these cases, should the expectation be exact match, or a tightly-bounded fuzzy policy?

I think a bit of fuzziness will be required. IIUC JPEG XL doesn't define the bit-exact decoding and uses floating point math, so depending on implementation architecture there could be some tiny differences.

• Do we need small canonical assets for P3 / Rec.2020 / PQ / HLG / gain maps, rather than relying mainly on the current large conformance image and sRGB-only 3x3 fixtures?

I'm not sure about this one, but I think we need the refs to also go beyond sRGB to really test wide gamut and HDR.

[hjanuschka]

@foolip i am subscribed here too 🤣

beside the fact that some stuff is missing in jxl-rs itself, is there any automated HDR/Gamut tests already in WPT where i could take a look?

[foolip]

@hjanuschka there's no infrastructure for capturing screenshots with anything other than sRGB so I think there can't be any tests for it.

Or maybe there could be tests using f16 canvas...?