I would think it’s trivial to add a rec.2020 2.4 icc profile? Rec.2020 with 2.4 function is in the standard, that’s why I used 2.4 in the comment. But it doesn’t have to be 2.4 exactly.
Display P3 is SDR. HDR Is a very weird thing that I won’t go into too much. Just export in sRGB, use other tools to convert to Rec.2020 2.4 with an icc profile or whatever, and tag it as HLG, it would look fine.
It does look fine. With my settings as in an earlier post. If I can avoid using other tools (which ones?) is better.
Well, it’s an unrelated thing, isn’t it?
For example on the Macbook I can switch the display to High Dynamic Range and set a color profile from a list of many (although I’m not sure which ones are actually supported. My external monitor (which is not really top notch) can also switch between HDR and SDR and this is independent from the color profile.
indeed, primaries being p3 or not is not related with the whole HDR thin, which is exactly what I mean by the quote reply. Though technically, Display P3 standard specified sRGB transfer function.
@giusarg thanks for your posts. I’m also interested since months in achieving some darktable output, that can make use of the HDR, XDR, gain map or whatever is needed to get that bright look on my iPhone and iPads high quality screens, where most of my photos are shown at the end of the day! Darktables typical sRGB JPG output always looks kinda dull compared to the shots taken with the iPhone camera and that frustrates me.
I tried to mimic your way of working (exporting with profile HLG P3 RGB) and now my questions to you: What file format do you use for export? JPEG XL 16 bit?
Going that way I get to see impressive photos with slightly overcooked highlights on my Apple devices (very bright which is good, but also very strong color in the highlights)
The gamma (actually transfer function, gamma is technically the wrong term) is implicitly chosen based on the profile set in the export or output color space module. What @kofa meant is that the user can’t override this behaviour.
No, they do apply a gamma. See above.
The pixelpipe uses the gamut and transfer function set in the input color space module. By default this is linear rec2020, that is, no transfer function/gamma. This is used throughout until display/export.
I export to jpeg-xl because, apart from supporting HDR and wide gamuts, produces smaller files than, for example jpeg, using similar quality settings.
I now choose 16 bit because I have just learnt that 32 floating point is overkill for my need.
Bear in mind that, in order to be seen exactly as you see it, the end user must use the same display and the picture must not be automatically converted to a SDR jpg, for example, when shared via Whatsapp or similar.
So when I occasionally share an HDR picture which looks great on a P3, I have no idea on how it looks like on an SDR phone.
Regarding the brightness of the highlights.
Since darktable’s preview is not close enough to how the image look like once exported (not even on the same screen), I rely on the histogram, as I said. I put the wide gamut tool / right-click: histogram profile to HLG P3 which in my case is the same as the export profile (HLG P3 RGB). Then I take care that my histogram never crosses the right border. In fact I try to keep it at a short distance from it.
Regarding the colors.
Again, the issue is that, even with my darktable built against the patched gtk+3, the preview in Darkroom is not faithful to the exported image as it appears in the viewer. So It’s really a matter of trial and error. I guess that you could try to desaturate a little bit the highlights, or reduce the chromaticity, for example with Color Balance RGB and learn from experience.
An interesting thing about JXL - if you export lossy, it doesn’t really matter what you choose (and you can convince yourself by trying different outputs, you’ll end up w/ files of the same size; it is not so for lossless obviously), the internal representation is always float for lossy. The bit depth is almost like just a “hint” to the decoder what to convert to when opening (and they don’t even have to follow it and can stay with float or choose any other bit depth)…
Thank you for the quick reply!
I’ll try the hints and adapt my edit a bit. 
