filmic XY graphs incorrect for [target white luminance] over 100%/HDR

[TiredOfGuessing]

Describe the bug

To apply filmic to HDR the author notes that the [Filmic module > display tab > target white luminance] can be set greater than 100% corresponding to the desired EV increase to the maximum luminance level above SDR/100% (link below with italicized excerpt).

The graph view [dynamic range mapping] work for both [display tab > target white luminance] lower and greater than 100%.

But the other three graph view modes [look only, look + mapping (lin), look + mapping (log)] do not for [target white luminance] greater than 100%. The curve is changed but the graph view is neither enlarged at the current scale nor rescaled to fit the increased values in the same area. See attached screen grabs. Bottom row works for both 100% and 400% but top row only works for 100% not for 400%. So the graph curve clipping bug is displayed top right.

Filmic Author explanation. https://discuss.pixls.us/t/mastering-workflow-for-linear-images-for-hdr-displays/19371/16

Filmic is compatible with HDR output, you just need to set the “display white luminance” (in display tab) to more than 100% (for 10 bits output, that would be 400% since you get 2EV more).

Since the implementation of 10-bit export formats, I’m hoping the caution in the same post below no longer applies.

However, the output color profile and gamma/display encoding modules, later in the pipe, clip signal to 8 bits unsigned integer, e.g [0; 255], so darktable as an app is not HDR-ready yet.

Steps to reproduce

1. Select filmic module > display tab
2. Increase [target white luminance] to over 100% e.g. 400%
3. choose any of the three XY type filmic graph modes

Expected behavior

graph should display full curve range regardless target white luminance setting

Logfile | Screenshot | Screencast

No response

Commit

No response

Where did you obtain darktable from?

downloaded from www.darktable.org

darktable version

4.6.1

What OS are you using?

Mac

What is the version of your OS?

MacOS 14 Sonoma

Describe your system?

MacBook M1

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

Apple M1 macOS

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

[ralfbrown]

The "display encoding" module (aka "gamma") converts the 32-bit floating point color channels into 8-bit integer color channels for the actual display by the GUI toolkit darktable uses. That part would need to be rewritten to actually show HDR on-screen inside darktable, which also requires that Gtk have an HDR-capable API with more than eight bits per channel (I'm not familiar enough with that aspect to know whether it does).

[TiredOfGuessing]

Thanks for your clarification. I have read elsewhere about the difficulties with Cairo and higher bit depths for displays, it sounds like the solution is next generation/vkdt. I assume the pipeline Ts somewhere (1) to the display with Cairo and display profile then (2) also to export using either output color profile or export module profile.

[TiredOfGuessing]

It looks like this issue is more fundamental and bigger than a graph data vs graph area scaling issue. I think this should be retitled, but to what I am not exactly sure.

I don't know enough about the path to "display" vs "output"/file. Also how selecting the bit depth of export would migrate to filmic.

Contrary to the developer quote in the initial report the dt_iop_tonecurve_draw() comments imply code changes for anything above the display tab settings = 100%/SDR.

dt_iop_tonecurvedraw() comment for graphs // draw the dynamic range of display // if white = 100%, assume -11.69 EV because of uint8 output + sRGB OETF. // for uint10 output, white should be set to 400%, so anything above 100% increases DR // FIXME : if darktable becomes HDR-10bits compatible (for output), this needs to be updated_

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[Micky774]

@ralfbrown This seems to be a gateway into a fairly comprehensive change to darktable supporting 10bit-hdr processing and output, right? Is this something on the roadmap, or unlikely to be considered soon? I personally have no experience w/ the darktable code base, and am new to much of the photo editing world, but I'd be happy to try to help with this if you think it would be feasible for a newcomer to make progress on.

[ralfbrown]

10-bit output should be possible with some image formats, but as I said, 10-bit screen display requires support from Gtk. I'm not familiar enough with the toolkit to know whether an appropriate API exists in Gtk3 (currently used); it's likely that Gtk4 has such an API, but darktable is only just taking the first tentative steps toward what would be a significant code overhaul to switch to Gtk4.

I have no idea whether anyone actually has 10-bit display on their personal to-do list.

[pkonecki]

GTK Blog post about HDR display support.

TLDR: Not there yet.