Some HDR Questions and Problems

wollompa · August 20, 2026, 10:32am

Turns out while JXL stores values >1.0, it considers them out of gamut (§ 4.1.4), and has a “nominal range of [0, 1]”. So I still don’t know what HDR is! And thus their ‘Intensity Target’ seems more of a maxCLL or peak mastering luminance.

On macOS and fltgui/hdr_avg_nits, I don’t know but I think the system always takes control of the brightness of (1, 1, 1). Here’s a WWDC talk on their system from 5 years ago, which I suspect many would find excruciating. However there’s SMPTE ST 2094-50 from a few months ago, authored mostly by Apple and Google, which at a glance looks like a similar idea. I’ll try to read it.

Also on JXL, I have bodged together a seemingly working export module. See GitHub - WFinster/vkdt: raw photography workflow that sucks less · GitHub. Some notes:

Only lossy for now.
Only effort = 7.
Only some primaries and transfer functions supported (though it should warn you if you try to use the unsupported ones).
AdobeRGB being weird.
Maybe EXIF works?
Should build fine on Linux and macOS, but not extensively tested. The macOS bundling would need some adjustments to work properly (but I’ve got it working locally) due to homebrew things. Windows not at the moment as I don’t know how to do the equivalent of these lines in the Windows config.mk but for libjxl:

VKDT_JPEG_CFLAGS=-I/c/msys64/ucrt64/include
VKDT_JPEG_LDFLAGS=-L/ucrt64/lib -ljpeg
export VKDT_JPEG_CFLAGS VKDT_JPEG_LDFLAGS

Generally likely to be bad because the most sophisticated C I’ve previously written was a terrible quicksort algorithm earlier this year that took me days and ended up slower then my mergesort. And I still haven’t reached the chapter on pointers.

hanatos · September 9, 2026, 7:45am

oh very cool! just came back, only reading this now. will look at the pr…

wollompa · September 10, 2026, 9:50am

Ooh you’re back! I haven’t made a PR yet — it isn’t really finished and there were some other issues and questions I meant to ask. But I can make one if that’s an easier place to discuss things.

hanatos · September 10, 2026, 10:44am

ah, no worries. ask here or on github. i have to say i like the code, comments, and commit history so far very chaotic and human…

wollompa · September 11, 2026, 1:08pm

Hahah that’s very nice of you. Good to know I come off human despite my love of the em and en dash . I’ll figure out how to make a PR…

Doug-Phoenix · September 11, 2026, 1:36pm

I’m not sure if this helps, but take a look at the doc here:

Nis forwarded this a while ago in another thread.

hanatos · September 14, 2026, 3:32pm

really nice hud! 20ms present delay for 4ms gpu processing sounds worrying. maybe try the other swapchain modes intgui/vk_present_mode:1 in vkdt/config.rc.

anyways, jxl write support is now merged, thanks for the contribution!

btw i use

intgui/allowhdr:1
fltgui/hdr_avg_nits:50

with an sdr monitor with the sway compositor for colour managed output that looks near identical to sdr display of exported images in say swayimg or eog. maybe that’s a secret scaling factor applied to PQ in this compositor chain.

age · September 14, 2026, 7:30pm

github.com/darktable-org/darktable

Fix converting from PQ curves to linear

opened 02:06PM - 27 Dec 19 UTC

closed 12:16AM - 25 Mar 23 UTC

cryptomilk

no-issue-activity

The following is copy&paste from #3749 @cryptomilk > The AVIF with PQ Rec20…20 loads fine. It is completely black, but if I increase the exposure, then I start seeing the gradient. @joedrago > This means you are missing the luminance scaling part. PQ is implicitly a > 10,000 nits container, whereas most other transfer functions are relative > luminance (zero is black and one is "as bright as the monitor can go"). > After darktable converts to linear, it should multiply each channel by > (10000/destLum), where the destination luminance is how bright you consider > SRGB to be (or how bright you plan to display on the screen). Chrome always > uses 80 when displaying PQ on SDR displays, Vantage lets you adjust it with > the T keybind. assuming dark table handles overranging correctly > (channels>1), everything should look really good. @TurboGit > I see, this means that our color spaces are OK but when we are using them for whatever image on SDR display we need to adjust the final image by multiplying the 3 RGB channels by around 80. Is that correct? @joedrago > No, you don't multiply by 80, you scale by the ratio of "source luminance" to "destination luminance" when going between overranged linear and PQ. Here's Chrome's implementations of FromLinear and ToLinear, for example: > > https://cs.chromium.org/chromium/src/ui/gfx/color_transform.cc?l=97 > https://cs.chromium.org/chromium/src/ui/gfx/color_transform.cc?l=177 > > The big question to ask yourself is "how bright, in nits, is (1.0, 1.0, 1.0, 1.0) when darktable is operating in rec2020 linear?" Chrome has locked in on 80 in their implementation (likely due to SRGB's semi-unused standard), macOS might think it is 100 nits, nominal HLG might prefer it was 203 nits, etc. > > Does darktable offer a means to show how bright a pixel is already? If so, what math is it doing to calculate the value in nits? That should be the value you use in a ratio alongside 10000 when going to/from PQ. > @joedrago > Scaling the channels like this only makes sense after converting to linear; scaling in PQ (or any other nonlinear TF) will do weird things. > > In my opinion it should just be a part of the PQ->Linear and Linear->PQ conversions, assuming darktable's LinearRec2020 has a known luminance for (1.0,1.0,1.0) and does good things with overranging (channels > 1.0). @TurboGit > Well sadly this is looking beyond my expertise :( Hopefully someone will shine in and help with the matter as to how best integrate this in dt.

Shouldn’t the scale factor be 10000nits/100nits=100

For HLG 1000 nits I think the scale fator has to be 1000nits/100nits=10

hanatos · September 15, 2026, 7:15am

right. that’s exactly the “nobody knows the factor” discussion right there. in my particular example the quest is to find out what sway or wayland (dunno who’s responsible here, don’t feel like searching through the source now) think what (a) is the number of nits pq in the swapchain encodes and (b) the peak luminance of my monitor is. this will then be used to compute some scale factor. in the sdr application, i wish to compensate that, so that 1.0 in vkdt will correspond to peak luminance of my sdr monitor.

note that this is only about 10bpc pq encoding of the swap chain image for display, not about storing in jxl.

wollompa · October 7, 2026, 12:14pm

Sorry, been a busy time!

really nice hud! 20ms present delay for 4ms gpu processing sounds worrying. maybe try the other swapchain modes intgui/vk_present_mode:1 in vkdt/config.rc.

There are a lot of fun metrics, not that I know what nearly any of them mean. I gave a quick try of intgui/vk_present_mode:1 but it didn’t seem to affect the present delay, which seems to fluctuate in the range of 20–25ms on my machine. I assume there are a number of performance oddities on Mac, what with MoltenVK, macOS and Metal, and the unusual (relative to other desktop GPUs) design of the Apple Silicon GPUs. But one wouldn’t complain

I’m writing a further thing on the PQ encoding, but it keeps growing longer so I’ll leave it for a later comment. But just would note that the fltgui/hdr_avg_nits: setting still doesn’t seem to affect anything on macOS (but I can see the effect on Linux with Mutter).