Hi,
I am trying to find out if darktable can output images in an HDR format for use in HDR TV productions that are graded in Da Vinci Resolve. I would think that using the HDR output color profiles would accomplish this, but so far I haven’t had too much luck.
I have tried to export images in linear Rec.2020, HLG Rec.2020 and PQ Rec.2020, as exr and 16 bit tif. As far as I can think, I would then be able to take these images into Resolve, assign their respective input colorspace/gammas and they would look correct in Resolve, when the project is set up in either HLG or PQ (ST2084).
So far only HLG comes close to doing this. The PQ images are way too bright and the linear ones too dark. So I suspect that the HLG images look ok only because the HLG curve is somewhere between the others.
In darktable, I don’t use filmic rgb or sigmoid, as far as I know they are intended for normal SDR output. I just make sure nothing is clipped and set the output color profile.
I am sure there is something vital I am missing, but what?
This is all because dt is ICC profile based, which means it operates on the 0.0-1.0 range assumption. 1.0 here means “max value”, and for PQ this is an absolute 10000 nits. So you have to figure out where you want to place your “1.0” in terms of nits and exposure compensate accordingly.
HLG is more forgiving as it is relative and not absolute. I like to pull about 1 1/3 EV before exporting to HLG: Experimenting with HLG and HDR10 for still images - #15 by kmilos
Right, thanks. That makes sense, I think. I knew it had to be something 
This was one topic of unknowness when I was working on the sigmoid module so I’m quite interested in hearing what a workflow could look like.
The simplest is probably todo linear raw as exr and apply the aces display transform in resolve. But you can actually use the sigmoid module instead of the aces transform! Just increase the display white point to something like 1200%. 100% is just a soft limit. I would still recommend to export as linear exr in this case as well, it’s up to you where the display transform is done.
ICC profiles shouldn’t really affect this in any way. The important part is that the darktable scene referred workflow uses the same middle grey standard as aces, 0.1845 so it is fairly compatible with the aces workflow.
Please post some more info and examples of how it goes! I don’t have access to HDR screens so haven’t been able to try this out in practice myself.
If memory serves me well, I have been able to export linear Rec2020 values > 1 as floating-point TIFF.
Sure, there is no clipping when exporting linear and float (that’s why it’s recommended for HDR/scene-referred work), but any (ICC and dt) transfer curve works on the 0-1 range only, and 1.0 is where the right edge of the histogram is in dt. And this is really messed up for the absolute PQ transfer curve.
Even when you export unclipped linear float, there is still the question of what dt’s 1.0 actually means to e.g. Resolve - i.e. does it assume that 0.18 is mid-gray?
This is interesting, I’ll look into that.
About the display white point, is it safe to say that the x% will be similar to the target nits level? So if 100% is for normal 100 nits display, 1000% will be for 1000 nits HDR, which is what we are mastering for?
As for HDR displays, I have a proper HDR grading monitor at work for Resolve. At home I am limited to the MacBook Pro XDR display (which is very good) and an iPad Pro as external monitor.
For a little bit of context, I am a long time colorist, working in the broadcast industry, with about 12 years of Resolve experience and other Da Vinci systems long before that. We are slowly introducing HDR, and I have been thinking about stills and graphics in HDR for some time. I just got involved in a production where the question of stills came up specifically, and being a long time darktable addict I thought maybe this was a way to do it.
So if 100% is for normal 100 nits display, 1000% will be for 1000 nits HDR, which is what we are mastering for?
The white level percentage is linear so yes I would think that should work out correctly for you.
But I get 1200% when I try to match the HLG 1000 nits ACES curve in my curve explorer app: https://jandren-tone-curve-explorer-streamlit-app-xca32q.streamlit.app/
Here are the settings for a 1000 nits HLG ACES like curve in the sigmoid module:
Display white: 1200%
Contrast 1.34
Skew: -0.24
Preserve hue: 0% ← being able to control this might be the advantage to process the files with the display transform in darktable.
One of those to at least, maybe you could figure out which one of the two that is correct?
Again, one alternative way for you to edit is to use the sigmoid module when editing darktable but then deactivating it on export and apply the ACES display transform in Resolve. I would at least be intersting in seeing if those two methods are roughly equivalent!
0.1845 is used as middle grey in all the new scene referred modules and they are designed to handle values larger than one. This makes darktable compatible with the ACES workflow which have the same assumption. 1 is just a value brighter than middle grey, its actual display value depends on your display transform. The sigmoid module supports (and filmic should too) display transform to a HDR display i.e. with a higher luminance than “100%”. Stuff like the histogram might not work so well though but that won’t affect the output, just make it a bit harder to achieve it.
Exactly. That’s why it’s extremely messed up for the PQ case - the (legacy way as dt implements) ICC PQ export profile puts 1.0 at 10000 nits indiscriminately, thus outputting 0.18 at a whooping 1800 nits! At least for the PQ case, you (and dt, and future ICC implementations [1][2]) need to have the extra piece of info such as maxCLL etc.
Oh wow, yeah that isn’t ideal! I don’t have any insight in the PQ format but I would probably file this as a bug with the intention that a PQ export should align with how ACES does it. And thanks for the links Please, write a issue on Github if you haven’t already!
.exr should work fine and export with 0.1845 as middle grey. So I guess that would be the recommendation here.
Sorry, but it’ll have to be someone w/ “skin in the game” who actually uses the workflow and can formulate a proper and detailed proposal/requirements. There have been several discussions already on dt github, but nothing concrete.
And then there’s of course Adobe’s HDR Optimization
Well, since you mention Adobe, let me also add as reference how this is done in ART, in case anyone is interested. I can confirm that it works at least on 1 sample (that is my TV
Not sure how well it works, since I don’t have an HDR monitor, but one of the drivers behind the scene-referred workflow and filmic was specifically being able to handle HDR output, so it seems you have misunderstood something.
In filmic I assume you need to use display > target white luminance to set the desired DR. The manual isn’t entirely clear on that.
I tried that later, but it didn’t do much difference. I guess it’s about the 0 to 1 mapping mentioned above, setting middle grey way too high.
But why would you need a tonemapper like filmic or sigmoid for HDR output?
I thought the whole idea behind filmic and sigmoid was to map the high DR of modern cameras to the much lower DR of current standard screens and paper.
Also, the idea of mapping a very large DR to a range of 0…1 with a fixed point at 0.18 sounds … complicated.
Even a HDR display is finite I guess. I don’t have a HDR screen myself but rather draw from knowledge reading up how ACES works.
I guess the 0.18 point would have to be mapped to 18% of diffuse white, an not the theoretical max (e.g. 10 000 nits for PQ). We have to remember that diffuse white in an HDR signal should not be much brighter than in an SDR signal, usually around 100-200 nits. The rest of the dynamic range should be reserved for specular highlights and light sources. So this would place our 18% around the 18-36 nits area.
I get the impression that a lot of TV/movie productions still maintain a film-like curve, just slightly less aggressive, in order to preserve the “look” of film.
It is true that you can just feed un-tonemapped HLG to a TV and it’ll actually look pretty good (note that the TV itself may do some tonemapping internally), whereas if you feed un-tonemapped SDR to a monitor or TV, it’ll look dull and flat.
Back ages ago, what I did was export linear Rec. 2020 from darktable, and then use ffmpeg’s zscale filter to do the HLG transform.
Found where AP talks about filmic and HDR:
@hpbirkeland Seems that display white should be 400%
Because the input DR is not the same as the output/display DR. One way or another, that will have to be managed.