Dear Todd,
Thank you for this information. I’m going to take note of this for next additions.
Just to be certain :
1/ = “jenshannoschwalm”
2/ = "darktable.git
3/ = i would find by clicking on the “Pull Request” tab, and then click on the PR I’m interested in, and then I can find him on the top of the next page, after the name. (as Jorismak explained yesterday). Or is there a more direct way to recover the identification?
1 Like
Note: if you plan on testing development branches, GitHub has a command-line tool ‘gh’.
It makes checking out the right branch very easy: all you need is the number of the pull request (PR):
gh pr checkout 12345
(Of course, this requires that you git clone the main darktable repository first.)
For next additions , i would just wait until they are in darktable, so in the master branch. Properly accepted as it were.
This is just such a game changer that you go through the hoops to get it early 
.
(For the record, there are still changes / fixes coming in for this branch… and as its still in proposal, it might turn out to be different when and if it finally is accepted … so you are taking a sneak peak at work in progress … So expect things to change and expect bugs).
It’s a style choice , but has nothing to do with ‘hdr’ or not.
Merging multiple shots is to capture a big range of data.
How you squeeze that data back into the limited range of your display , that’s ‘just another edit’.
That overcooked look you can get with a single shot just as easily… And that means you can get a natural look with a multi shot just as easy.
And as kofa said , camera’s of the last decade can often capture more than enough data in a single shot , if you keep exposure low so that you don’t clip. I don’t see the need for multi shot in a lot of cases, and so never do them.
And if i do, combining two shots (one at like -3 and one at 0) gives you all the data you need.
3 Likes
It should land there during august (this is planned for 4.2) and until now I concentrate on fixes for 4.0.1.
4 Likes
I currently use the highlight-weighted matrix metering mode on my Z 6 for all my shooting. It keeps most highlights in sensor resolution, but it will let a few things go, like in-scene speculars and strong sunlit glint. For those I’ll invoke highlight-reconstruction right after demosaic, mainly to get rid of the magenta caused by the white balance skewing of those pileups.
The consequence of relying on this metering mode is the need to pull up low values, and not in a consistent way. Thing is, the Z 6 is pretty forgiving, in that I rarely need to use a denoise on my pulled-up shadows. With my D7000 I messed a bit with two-image HDR amalgams, but it’s that hassle that ultimately convinced me to bite the bullet and get a better camera.
Here’s one rather extreme example. Twilght, looking to the southwest, shot from a moving train so no opportunity to HDR:
License: CC-BY-4.0, https://creativecommons.org/licenses/by/4.0/legalcode
The ground lighting appears a bit wonky because it was, quite dark compared to the sky. Indeed, the linear data has the sky nicely exposed and the ground is almost indiscernible black. it took a decidedly non-linear tone curve to push all the data around to get this rendition. But, no highlight reconstruction…
5 Likes
OK, I’ be patient. 
Possible to share the raw?
Sure:
DSZ_1908.NEF (26.9 MB)
License: CC-BY-4.0, https://creativecommons.org/licenses/by/4.0/legalcode
Nice one and definitely not exposed to the right
Heh, I thought it was a scene at late dusk.
Generically, twilight is about the illumination, that being sky-scattered sunlight from the below-the-horizon sun. “Dusk” and “dawn” are instants in time, so to speak, having to do with the sun’s instantaneous relationship to the horizon.
And yes, I care deeply about the leap second Meta so enthusiastically wants to do away with… 
1 Like
A lot nicer than mine. Duly shamed, I went back and pulled the shadows back down, and replaced the matrix profile with my SSF LUT profile, which took that yellow out of the green…
2 Likes
Excuse me. This is my interpretation. I am not satisfied. I like the "tone of the road (very close to the ris, which is supposed), I like the “tones” of the forest greens. I don’t like the tone of the mountains in the background on the left with a very ugly magenta/reddish tone…
DSZ_1908.NEF.xmp (13,5 KB)
cheers
1 Like
Interesting… I went back to pix-peep my rendition, and that mountain is a lot more “neutral” there:
In the screenshot I included the view of my colorspace tool, shows I’m using my SSF profile. However, it looks the same with the plain old matrix profile.
I don’t have an operable darktable with which to regard your .xmp; what input camera profile are you using?
I do not use a specific camera profile. The space is sRGB relative colour space.
You have to use a camera profile, or at least a matrix of primaries, to describe the input. sRGB is the destination, and the transform is usually camera → XYZ → sRGB, so the camera and destination profiles don’t have to know about each other.
I’d surmise right now that the darktable default matrix for the Z 6 is from an Adobe DCP, which tend to be “warmer” than a ColorChecker-targeted profile. Just a gross surmise, based on heresay and supposition…