Effort 1 is the fastest, but offers the least compression. Try effort 3 for lossless. It should give you a good balance of speed and compression.
1 Like
I added some more functionality to the plugin, and moved it to my repository as the PR looks a bit stale.
I found two convenient workflows that consistently give relatively good results and donāt require fiddling with image duplicates:
-
Process the SDR intent in DT. For UltraHDR export use the āSDR only modeā. It just makes the gainmap a copy of the SDR intent, boosting the highlights. The gainmap metadata can be changed in the UI for a more precise tonemapping, but it gives surprisingly good results OOTB.
-
Process the HDR intent. I do HDR merging in Affinity Photo (w/o tonemapping), exporting to radiance HDR (linear 32 bit) and processing the rest in DT, but I guess in theory HDR merge in DT would work just as well. Add a final exposure compensation of -5.5 EV as the last module. On UltraHDR export use the āHDR onlyā mode and just correct the peak display brightness (for me 1600 gives roughly the correct level of highlights).
Example outputs in the zip.
ultrahdr.zip (10.0 MB)
I tried to apply the exposure correction in ffmpeg, with the eq filter, since Iām using ffmpeg to generate the libultrahdr input raws anyway, but so far no luck. exposure correction also compresses the image to SDR luminance ranges, and I wasnāt able to figure out the colorspace conversions that would work. Since itās impossible to specify styles in the write_image function, manual exposure correction, or applying a style manually is currently necessary. Any ideas on how to improve on this are welcome 
1 Like
Nice! 
P.S. Iād stay away from RGBE format as it has poorer precision than half 16b float. What else does Affinity support for export? EXR or TIFF w/ half float? You always have 32b float PFM and TIFF I guess?
Thereās many formats that might work. EXR, TIFF 16 bit, JPEG-XL. No PFM though. Iāll see what works good with the workflow as outlined. I think I resolved the main blockers to make UltraHDR creation actually convenient, so now the challenge is to go take some photos
1 Like
I havenāt tried the updated plugin yet, but I have an update regarding the artefacts and colour inaccuracies that I mentioned last time.
TL;DR: they disappeared after upgrading the software. Also macOS Sequoia now renders JXL and UltraHDR pictures as HDR in both Preview and Quick Look!
Longer story:
I recently upgraded to macOS Sequoia, and when previewing the exact same test images as in my previous post, I noticed that they were now rendered as HDR (in both Preview and Quick Look, i.e. when you press the space bar in the file browser) but also that there was no noticeable oversaturation, nor artefacts, for RGB gain maps.
Those were still present in Adobeās Gain Map Demo App, so I updated it to the latest version (17.0.1 build 2048 as of writing). To my surprise, the issues were now gone as well.
This was for the exact same files that I uploaded here (not re-generated), suggesting that the procedure outlined above to produce UltraHDR images was indeed correct, but that there was a bug in the reference implementation (!). Which is a good thing, because it means that nothing needs to be changed on our side.
This does not mean, however, that the three images now look exactly the same. The JXL file still has a visibly larger colour volume compared to UltraHDR with an RGB gain map, which itself has a larger colour volume compared to the monochromatic gain map. So for maximum fidelity, you will still want JXL, but when backward compatibility matters, UltraHDR with an RGB gain map is a nice middle ground.
1 Like
Thanks for the update!
Interestingly enough, I opted not to use JPEG XL for HDR intents myself, as its export from Affinity Photo has some strange color banding (when compared to RGBE or TIF) that I cannot fix so far.
If you have some time (and images to test on), I wonder if the HDR-only workflow as outlined above gives good results on your end too. The advantage is that I can develop HDR with an application that can actually display HDR content, and still get the benefits of using DT modules afterwards.
1 Like
Thanks to you for the great work on the plugin! I will give your workflow a try, but editing the initial HDR intent in Darktable since I donāt have Affinity Photo.
Since support for displaying HDR in Darktable still seems to be a few years away (although I could imagine some workaround to āemulateā it), I have actually been researching photo editors with good HDR support, but I am not aware of many open-source ones (apart from vkdt, if I manage to build it on mac). And proprietary editors donāt usually discuss their colour science, so itās hard to judge them without carefully trying them all. But I digress, and thatās a bit off-topic for this forum anyway since they are not FOSS.
1 Like
Thanks @Krzysztof_Kotowicz for the awesome plugin. Finally the pictures from my real camera donāt look so dull (in contrast to the photos token with my pixel phone) if viewed in in the google photos app. Great work!
1 Like
@Krzysztof_Kotowicz
When using the the SDR only exporter wouldnāt it make more sense to autogenerate an image with an exposure of -2 steps and use that as a gain map instead of the image itself?
Why -2 EV specifically? So far the images Im using look subjectively OK with no exposure correction.
On the other hand, if there is an easy way to programatically create exposure-corrected temporary images in dt, that would help with the -5.6 EV correction step for the HDR intents. I suppose this is just a matter of duplicating the image, applying a style and then removing it, but I didnāt explore that yet.