A native Windows tool for batch-converting HDR JPEG XR screenshots to ordinary SDR PNG / JPEG images.
Two programs are provided:
JXRBatchConverter.exe— Win32 GUI (中文 / English interface), drag & drop from File Explorer and Windows Photos, batch conversionjxr2sdr.exe— command-line tool for scripted and batch use
Everything runs completely locally: no network, no API, no account, no cloud service. Both binaries are x64 and statically linked — no Python, no .NET, no MSVC runtime.
Latest release: GitHub Releases → v1.0.0 — download
JXRBatchConverter_1.0.0.zip from the Releases page. SHA256SUMS.txt inside
the archive lists the SHA256 of every other shipped file (LF line endings, so
sha256sum -c SHA256SUMS.txt works on Linux/macOS).
See QUICKSTART.md for the 60-second version and RELEASE_NOTES.md for what
is new in this release.
| mode | what it is |
|---|---|
HDRWCG (hdrwcg, default) |
The faithful HDR→SDR baseline pipeline, verified against real HDR + WCG Image Viewer exports. |
Viewer Match (viewermatch9) |
The recommended mode when the goal is to closely match HDR + WCG Image Viewer SDR exports: the HDRWCG baseline plus a frozen low-light correction. Parameters are fixed. |
| Adjustable | The same baseline pipeline with paper white / exposure / input max / rolloff exposed. |
| Legacy 2022 / Legacy SDR | Reproduce the 2022 open-source export behaviour (including its wiring bug, which makes midtones 2.535x too bright), for comparison only. |
HDRWCG remains the default for backwards compatibility. Viewer Match is the recommended mode when the goal is to closely match HDR + WCG Image Viewer SDR exports.
The HDRWCG baseline differs most from tested Viewer exports in low-light regions. Viewer Match adds a frozen low-light correction developed from those measurements.
Double-click JXRBatchConverter.exe:
- Add images... or drag
.jxrfiles / folders into the window — drag & drop works from File Explorer and from the Windows 11 Photos app. A dropped folder is scanned at the top level only (no subfolders); for recursive trees use the CLI with--recursive. While a conversion is running, further drops are politely refused (non-blocking hint) — the queue stays exactly as it was. - Pick the tone-mapping mode (see the table above)
- Pick the output format — PNG, PNG 16-bit, or JPEG (quality 95)
- Optionally set an output directory; leave empty to write next to each source file
- Click Start
GUI language — 中文 / English: the selector at the top right switches
the whole interface instantly, no restart needed. On first start the GUI
follows the Windows UI language (Simplified Chinese systems get Chinese,
everything else English); the manual choice is remembered per user under
HKCU\Software\JXRBatchConverter (no admin rights needed). While a
conversion is running the selector is disabled. The product ships exactly
two languages — Simplified Chinese and English; other Chinese variants
(such as Traditional Chinese locales) default to English by design.
Numeric input (Adjustable / JPEG quality): values must be valid finite
numbers (203, 1.0, 0.5); text like abc, nan, 2abc or inf is
rejected with a clear message and Start is cancelled — nothing is silently
defaulted or clamped, and your edit boxes keep their contents. Out-of-range
but valid values still follow the documented range policy.
Outputs are never overwritten: the first output gets _SDR, then _SDR (1),
_SDR (2), ... Output names are reserved up front, so two inputs with the
same basename can never race to the same file.
When Viewer Match is selected, the tuning fields (paper white, exposure, input max, rolloff) are greyed out and show the fixed values the mode always uses — this is intentional: Viewer Match parameters are frozen so the mode always behaves exactly as validated. If you switch from Adjustable to Viewer Match and back, your previous Adjustable values are restored. If an image contains transparency, the status list marks the conversion as fallen back to the baseline — the conversion itself still succeeds.
jxr2sdr screenshot.jxr --mode viewermatch9 --format png
A whole capture folder, recursively, 4 threads:
jxr2sdr "%USERPROFILE%\Videos\Captures" --mode viewermatch9 --format png --recursive --workers 4
Main options (jxr2sdr --help for everything):
jxr2sdr [options] <file/dir...>
-o, --output <dir> output directory (default: next to each source)
--format png|png16|jpg
--quality <1-100> JPEG quality (default 95)
--suffix <text> output suffix (default "_SDR")
--conflict suffix|skip|overwrite
--workers <n> concurrency (default min(4, CPU cores))
--recursive recurse into subdirectories
--mode hdrwcg|viewermatch9|adjustable|legacy2022|legacysdr
--paper-white <nits> SDR peak brightness (default 203)
--exposure <x> linear exposure (default 1.0)
--input-max <nits> override image MaxCLL (default: auto)
--rolloff <0..1> highlight roll-off (adjustable mode only)
Exit codes: 0 all succeeded 1 usage/argument error 2 at least one
conversion failed
viewermatch9 is Viewer Match. Its parameters are frozen: the tuning flags
above are rejected when combined with this mode, in any order. Pass a
directory with --recursive for large batches — a few hundred individual
paths can overflow the Windows command line.
Viewer Match runs the faithful HDRWCG baseline and then applies a frozen low-light correction on top — a fixed mathematical transform, integrity- checked at runtime. There is no model service, no runtime inference, no network access and no parameter to tune.
How the correction is applied: Viewer Match applies a source-gated low-light correction — full-strength in the darkest range and smoothly fading to zero by 30 nits source luminance. Pixels outside the validated source domain and brighter pixels remain on the HDRWCG baseline, bit-exactly.
Transparency: Viewer Match was validated on opaque HDR screenshots. If any transparency is detected, Viewer Match automatically uses the HDRWCG baseline for the whole image.
Validation, measured in a blind comparison against real HDR + WCG Image Viewer exports:
On one preregistered 8-image blind holdout, all 8 images improved whole-image RMSE; pooled RMSE improved from 10.18 to 3.89 (8-bit levels). MAE, luminance RMSE, shadow RMSE and midtone RMSE also improved on all 8 images.
Scope of that claim: it is one 8-image holdout — evidence of a real, repeatable improvement, not a universal statistical guarantee — and Viewer Match is not a bit-perfect reproduction of anyone's software.
Guarantees:
- the tone-mapping parameters are frozen (paper white 203, SDR white 80, input max auto, exposure 1.0, rolloff 0); the CLI rejects the tuning flags in this mode and the GUI greys them out;
- images that contain any transparency are converted with the untouched HDRWCG baseline, bit-exactly;
- the default
hdrwcgmode is unchanged and remains the faithful baseline.
The baseline pipeline, modelled on HDR + WCG Image Viewer
(13thsymphony/HDRImageViewer, MIT):
WIC decode JPEG XR, float preserved (scRGB, 1.0 == 80 nits) <- never 8-bit
-> D2D tone mapping (HDR display mode, image MaxCLL, 203 nits output)
-> white level adjustment (80 nits scene side -> 203 nits display side)
-> WIC encode to 8-bit sRGB (or 16-bit) PNG / JPEG
The pipeline was calibrated against real viewer exports: midtones and highlights agree to within about 1 sRGB level on the tested references. It targets a 203 cd/m² white (HDR Reference White in BT.2100; the scene side is 80 cd/m², the Windows/Direct2D scRGB SDR white).
An ordinary SDR JPEG XR input is detected from the real pixel format and passed through with colour management only — it is never wrongly tone mapped. This is derived from the image, not assumed.
Input JPEG XR / HD Photo: .jxr, .wdp, .hdp
Output PNG 8-bit, PNG 16-bit, JPEG quality 1–100
Output alpha policy (fixed for this release):
| format | contents |
|---|---|
| PNG 8-bit | 8-bit sRGB RGB, no alpha channel (WIC 32bppBGR) |
| PNG 16-bit | 16-bit sRGB RGBA, preserves alpha |
| JPEG | no alpha (format limitation) |
If you need the alpha channel preserved, use PNG 16-bit. Viewer Match's transparent-image fallback is a tone-mapping safety rule, not an alpha preservation promise for every encoder.
- Windows 10 1809 or later (x64)
- the WIC JPEG XR codec (absent on Server Core and N editions)
- a WDDM 2.x graphics driver; if Direct3D11 is unavailable the pipeline falls back to WARP (software rendering)
No MSVC runtime, no .NET, no Python, no internet connection.
- One direction only: HDR → SDR. No SDR → HDR, no gain-map output.
- The pipeline targets a 203 cd/m² white. Other targets: use the Adjustable mode.
- The HDRWCG baseline differs most from tested Viewer exports in low-light regions; Viewer Match exists to close exactly that gap, within the scope of its validation described above.
- Viewer Match parameters are fixed by design, and Viewer Match falls back to the HDRWCG baseline for images with transparency.
- The legacy modes reproduce a 2022 open-source defect on purpose and are labelled as such; they are not the current Microsoft Store app's behaviour.
Rough single-file timings on a desktop x64 machine, one worker (PNG output; actual numbers depend on content and storage):
| resolution | HDRWCG | Viewer Match |
|---|---|---|
| 1920x1080 | ~0.6 s | ~0.75 s |
| 2560x1440 | ~0.8 s | ~1.0 s |
| 3840x2160 (4K) | ~1.1 s | ~1.7 s |
Decode and encode dominate the cost; the Viewer Match correction adds a small
fraction. Batch throughput scales with --workers (default 4).
The release archive contains:
| file | what it is |
|---|---|
JXRBatchConverter.exe |
GUI application |
jxr2sdr.exe |
command-line converter |
README.md |
this file |
QUICKSTART.md |
short getting-started guide |
RELEASE_NOTES.md |
what is new in this release |
LICENSE |
MIT licence |
SHA256SUMS.txt |
SHA256 of every other shipped file |
This repository contains the full buildable source (see below).
Toolchain: LLVM-MinGW (clang targeting x86_64-w64-mingw32), C++20. A bash shell (MSYS2 or Git Bash) is required on Windows.
bash build.sh all # builds both binaries into build/ and dist/
bash build.sh test # builds and runs the self-test binaries
The shipped release binaries are produced with this exact script — no
additional toolchain steps. Python is not needed to build or run the
product; it is used only by part of the developer/test tooling under
devtools/.
The repository includes the test sources used during development:
- strict numeric-parser regression (
devtools/strictparse_test.cpp) - CLI regression suite (
devtools/rc4_regress.py) - GUI behavioural tests (
devtools/rc4_gui_behaviour.py,devtools/rc3_localization_tests.py) - Viewer Match contract tests (
devtools/h9_contract_test.cpp,devtools/h9_gate_parity.cpp,devtools/h9_d2h_selftest.cpp) - deterministic fixture generators (
devtools/makefixtures.cpp,devtools/make_alpha_fixtures.cpp,devtools/make_size_fixture.cpp) - self-test runner (
tools/run-tests.sh; the full corpus variant expects reference material that is not part of this repository) - source/binary reproducibility checks used for the release
The 1.0 release was tested and regression-checked, and received an independent adversarial software review followed by separate reproduction of the reported findings. This is not a claim of formal verification, absence of bugs, or security certification.
MIT (see LICENSE).
The HDR → SDR pipeline reimplements 13thsymphony/HDRImageViewer (MIT); the parameter values, the MaxCLL algorithm and the choice of the HDR rather than SDR display mode all come from that source. The GUI, the CLI, the Viewer Match correction and the batch infrastructure are original to this project. This project is not affiliated with, or endorsed by, Microsoft, NVIDIA, or the HDR + WCG Image Viewer authors.