Trying again in GIMP
Itās a pity that such a large percentage of the edits posted show the very highlight reconstruction failure that the OP was complaining about, and contrasting with the simple, reliable, no-fuss reconstruction of highlights that he got from Lightroom.
This thread really serves to emphasise that DT really should be delivered with a default highlight recovery that is as reliable and fuss-free as almost all the software we get from camera manufacturers and the big independents.
Yes, the power and flexibility of DT highlights recovery is fantastic, and appreciated, but we shouldnāt be seeing so many problems that need addressing.
Now, I will close by contradicting my above rant: I ran the OPās file in my DT 4.2.0 and the default āinpaint opposedā highlight recovery worked fine! 
I then proceeded with a quick personal edit of the OP image and got this look, just sharing for fun.
PK1_3540.DNG.xmp (14.8 KB)
cheers
so then?
2 Likes
Yep, thatās the funny thing about this thread - it was started when dt was indeed lacking a decent HLR algo, but now, in 4.2 the OPās issue no longer exists - as you found. The new default HLR settings work perfectly on 95% now, instead of, um, 30%? before.
1 Like
This image was one of the many images we (@Iain @garagecoder and me) investigated in depth while developing āopposedā and āsegmentation basedā. In images like this a smooth transition from non-highlights to reconstructed-because-blown-out was sort of a challenge. So if you evaluate the different algos and applications handling such issues ā watch out for those parts of the image 
About the 30% in question. I would also use a question mark here While deciding to make āopposedā the new default we checked for āhow many images failā on the algorithm and in fact there are very few (maybe the 5% you mentioned). With the old clip algo we also had only few images failing completely (well we had a constant color shift due to white balance - letās forget this now) but we had a failure rate of close to 100% if we wanted any detail recovered
9 Likes
Seeing the good results of that effort of yours, we can just say Thanks a lot for the work done!
3 Likes
Thanks for all the work you put in! My 30% figure was a bit (very) unscientific. I was thinking more of images where the image stands all falls by large blown areasā¦ like this oneā¦ as opposed to 30% of images all together. But sorry - didnāt mean dt was all that bad before!
Havenāt played with darktable for quite some time and I want to get rid of the rust that has been building upā¦
This one seemed a nice one to start with again. I remember doing this one using RawTherapee when it was originally posted and having a rather hard time to get a meh result.
The one below isnāt perfect, thereās for example a small cloud cluster that isnāt prominent enough for my taste, but it isnāt all that hard to get to the result shown here:
darktable 4.3.0+978 (14.4 KB)
In dt 4.4.2 the problem simply does not exist. Highlight reconstruction with default settings (inpaint opposed) fixes it. Decompression with filmic and tone eq, local contrast with diff & sharpen, small color adjustments using cc channel mixer.
PK1_3540.DNG.xmp (10.0 KB)
3 Likes
Hello,
Hereās my colorful interpretation of this beautiful photo.
Reading this thread, itās easy to see how Darktable has evolved.
PK1_3540.DNG.xmp (24.2 KB)
Darktable 4.5 & Sigmoid + one of the profiles I use for my Pentax K-1
Pentax K-1 Camera Vibrant.icc (528 Bytes)
Greetings from Brussels,
Christian
2 Likes
Yes, itās certainly a good example this oneā¦ it caused no end of issues back in 3.8 or whatever was current when this thread started. Go DT!
1 Like
I really like the proposal of @hanatos with vkdt. I leave mine with Ansel (DT fork).
PK1_3540.DNG.xmp (9,9 KB)
Cheers
2 Likes
1 Like