Highlight reconstruction darktable vs. rawtherapee

It’s been stated a few times in the thread that the white-level for this file is wrong in DT, making the highlight-clipping-indicator and the highlight-recovery modules not really work. Set the correct white-level, and you’ll notice what’s clipped and not.

I’ve also posted screenshots to RT seeing the same magenta cast and clipped raw, and FastRawViewer (libraw / rawdigger) to show what is clipped and not.
This file clearly needs some reconstruction to get the sky to show OK.

edit: @hannoschwalm beat me to it again (Discuss not showing new replies for me only after a reload, so I don’t see replies from others before I post myself :pensive: )

Dear Joris, Thanks for yr reply. I must admit that I read the thread not thoroughly enough And I didn’t really understood the consequence of issue with the whitepoint.

It should be an 4th (EDIT mistake should be 5th) option in the existing highlight reconstruction module.

OK, I see. You refer to the ‘guided laplacians’ option. But wasn’t that already in DT 3.9?

Sorry, I’m not on my pc so couldn’t check, I should have said, 5th option :face_with_hand_over_mouth: It’s simply called highlight reconstruction (or similar)

It wasn’t meant to be pointing fingers or anything! Just checking that the information we started with is still true , or that something new is discovered :wink:

I

Dear Steven, I managed to install this version of DT (407f53c). I did : “git clone --recurse-submodules --depth 1 GitHub - jenshannoschwalm/darktable: darktable is an open source photography workflow application and raw developer” and followed the instructions further down that page on how to install a test version, alongside my ‘normal’ version.


There’s only the 4 options in HLR.
Do I have to do something extra, to have the new module activated in this version?

Oh… it’s certainly not there! I’m sorry not to be of more help, but I have very little technical knowledge when it comes to compiling and so on. I’m a windows user, so I installed the build from @priort and it just worked…
The only thing I can think of to check - is to look on the top left corner of the darktable window, it should say what version it is below the logo. The screenshot below is ‘normal’ DT 4.0, the release version, whereas when I’m running the new build it reads 4.1.0 followed by a string of characters. It might be different on windows, but you could at least maybe check that your system is actually running the new version. I’m sure someone else will have a more useful suggestion!

After cloning, you have to check out the relevant feature branch, not the master one.

I’m not sure what you mean by ‘check out’. But I’ll start a new Topic, because this has nothing to do anymore with HLR. It’s more related to an new Linux-, former Mac user taking his first steps in the world of github, cloning, compiling, building, … and I don’t really understand it all. Yet. grrrr.

@emmel , here’s some info I put together on building dt -

Hi Andrew,
I wanted to start a new topic, and when I typed in a subject, your topic came up as a suggestion. I’m reading it at the moment and it’s just what I need. So, no new topic from me needed. :handshake:

Well, you are right, of course. The sky is heavily clipped, in all three RGB channels somewhere, so clipping tools are necessary. There are different tools, so there are different results, of course - according to individual tastes. I wanted to point out only the presence of the Dynamic Range Compression tool in the RT, which can be used here in a fast and effective way, although not the only one. The DRC in the RT compresses the data so that it fits the destination range using R.Fattal and Co. algorithm. It cures here almost completely the magenta problem, due to chromatic aberration. This “almost” and so on, would need some extra work, but this is beyond the scope of our discussion devoted mainly to the DT, which is out of my experience.

The new highlight recovery code is not yet in the official Darktable sourcecode. It’s ‘proposed, but not yet accepted’ at this stage, so to speak.

On the Darktable github, there is a section with ‘pull request’, proposals for code to be ‘pulled into Darktable’. This is the one for the highlight recovery:

On the top of that page:

So the code is currently in @hannoschwalm’s github repository.

So the easiest way to explain (there are other ways), is to check out his github:

Just as you did with git clone. I would leave out the --depth 1 for now. That means you get only the ‘latest’ code, without it, you get ‘everything’.

Then check out the correct branch (‘switch branch’ to the new code), and then update the submodules.

git clone https://github.com/jenshannoschwalm/darktable.git
cd darktable
git checkout gl_recovery_v4
git submodule init
git submodule update

Maybe this can be combined in a one-liner as

git clone -b gl_recovery_v4 --recurse-submodules https://github.com/jenshannoschwalm/darktable.git

Then continue your build as usual. Since you managed to build v4 before, this should work out just fine.

2 Likes

This is all you need to do and then build…

git switch -c new_branch
git pull https://github.com/<user>/<forked-repo>.git <branch>

No cloning needed just add the branch…it will track changes …you can remove it easily later if you want…

1 Like

I hammer home the point about not clipping highlights with the ETTR suggestion. Also if you push the ETTR too much and don’t clip you can still get very desaturated highlights. That could be a problem for some images. I agree, that I would much rather deal with noise than reconstruct a clipped highlight. However, sometimes the dynamic range of the lighting means even the best of us will get unavoidable clipping.

1 Like

@kofa I like that you describe LR exposure merge as an in camera solution. Because I have a perpetual LR 6 licence I defer to it for my exposure blending. I like that it handles RAW files and even handheld shots. What really amazes me is that if there are tourists (bloody photographer’s curse) walking around the scene it can handle that problem as well. LR works most of the time, but even it can have a hissy fit sometimes.

I have played with Hugin a little but not invested enough time into it yet because of LR. I have tried the HDR function in DT with tripod aligned shots and have been underwhelmed by its performance. I am not sure if DT version has improved in that module.

I don’t, but I think you do. :slight_smile:

I rarely do HDR merges; I stitch (hand-held) panoramas. For scenes with a high dynamic range, I underexpose to protect the highlights, and deal with the noise. I don’t think the noise is a serious problem, not even from my 10-year-old LX7 (1/1.7") compact, which is much like the G16 you used in your example.

I feel most of the HDRs I see on the internet are horrible, unnatural and overcooked. If the scene permits and I have a tripod I like to do auto exposure bracketing, process the separate images in DT and output as 16 bit tiffs which I then open as layers in Gimp and blend with layer masks. A gradient mask will often work nicely for landscapes and replaces the need for a gradient lens filter which can be a pain to use anyway.

1 Like

Perefect! And the “one liner” worked. Thanks for you support!