Using RawTherapee in combination with HDRMerge is a great pleasure by itself, but now I have extended my workflow with Hugin for stitching. The results are quite nice, but I was wondering if my workflow is really optimal. Here is what I do at the moment:
Merge my RAWs for each slice of the pano with HDRMerge. I’ve found out that a blur radius of 2 or 3 yields the best results for me. Reading the code, it seems that saving the DNG with 16 or 32 bits depends on the machine’s endianess while 24 bits should be portable. Is that true?
Open the brightest slice with RT. Select ‘Neutral’ profile. Adjust “Auto Levels” so that they aren’t auto anymore. Set “Lightness”, “Contrast”, and “Saturation” all to zero. I’m unshure about highlight and shadow compression, so I leave them at 100 and 50. Sharpen. Save as 16b TIFF with output color profile “RT_Large_gsRGB”. Clone pp3 to all slices and develop them accordingly.
Stitch the TIFFs in Hugin and save the pano as LDR TIFF, which is 16b again.
Open the pano with RT and let the wonderful CIECAM02 tonemapping happen.
What do you think? Am I on the right track? I’m a bit unshure, if I preserve all details in the shadows with my RT preprocessing step. The preprocessed images look relatively dull and the postprocessing is mostly about lifting the shadows via tonemapping.
I sometimes find with my own panoramas that using my camera’s own raw development software has some advantages when it comes to colour and lens correction. The camera manufacturer know how to pull the most benefit from its own raw image format, so I’ve started there to produce 16-bit TIFFs corrected only for these two variables. These I pass along to hugin for alignment, exposure blending (Enfuse), and stitching. Hugin’s own 16-bit TIFF output can then be passed to Rawtherapee for tone mapping, noise reduction, and other enhancements.
Totally! But I was busy eating and this had to wait
Don’t worry about 16-, 24- and 32-bit. I tried 5 shots bracketed 2EV apart of a very high dynamic range scene and saw no difference between 16-bit and 32-bit, so I use 16-bit - it’s smaller.
2.a. If you still see ‘Auto Levels’, you need to update.
2.b. If you use “(Neutral)” then you shouldn’t need to set any of those other things you mention to zero - the profile does that for you.
2.c. The rest sounds good.
2.d. The question is whether you get the best results by (a) first tweaking your photos and then stitching, or (b) setting your photos to neutral, stitching and then tweaking. I think it generally doesn’t matter (I think = I tested many things and arrived at this conclusion). What does matter is that you don’t lose any data before stitching. As such, when I process photos intended for being stitched into panoramas, I made a processing profile which uses things like chromatic aberration correction, a little sharpening, defringing, and other things particular to my lens, but when it comes to the exposure tools I leave everything as neutral as possible while preventing clipping in the shadows and highlights. Generally this means enabling “Highlight Reconstruction” (even if I leave it at 0) and sometimes setting the Black slider to -5000 or so. Once stitched, I then make it look aesthetically pleasing, knowing I lost no data till that point.
I need to stress that you should absolutely not use tools like Color Toning or Wavelets before stitching, only after, because they will create differences between the tiles (I call them tiles, I mean the individual ‘shots’ or ‘panels’ or ‘fields-of-view’ or ‘bracketed sets’ which you stitch).
The rest sounds good.
Finally, once you’ve preserved all data up to the point of stitching, don’t forget to stop prioritizing that when you tweak the stitched panorama, because I-can-see-everything does not equate to what-a-nice-photo
@tbransco I don’t agree that the camera knows best. For one, computer software has more processing power at its disposal. Secondly, a generic profile for your lens (regardless whether it comes from the camera or lens manufacturer or elsewhere) is likely to not be as good as a profile you made yourself, using your lens on your body. Third, distortion is complicated, your lens and body combination could suffer from several kinds of it, so the software correcting it should support that.
Just to clarify, I was suggesting the use of desktop software, not the use of the camera itself, to convert the raw files to TIFF. Fair points on the remainder, though; I’ve just not been keen enough to build such profiles for each lens/camera combo I might use. Those with higher standards, or worse lens/camera combos, are certainly welcome to go that route.
Well, I’m using the most recent distribution-supplied RT version, and although the distribution is Debian testing this still happens to be an elderly 4.2. But shure, I can compile the latest GIT version if I’m no longer content with the stock version’s features.
[quote=“floessie, post:1, topic:717”]
What do you think? Am I on the right track? I’m a bit unshure, if I preserve all details in the shadows with my RT preprocessing step. The preprocessed images look relatively dull and the postprocessing is mostly about lifting the shadows via tonemapping.
[/quote]It looks great so yes. Your workflow sounds sane too.
Enfuse (the exposure blending in hugin) can sometimes also deliver great results out of the box so give that a try too.
Regarding the specific image it looks a bit underexposed at least in the shadows. I’d probably push it a bit more:
Yes, I tried it once and was not overly impressed, but maybe I was too green or the shot didn’t fit.
That looks indeed better on this white background. And actually, I had it printed on aludibond to be placed on a light yellow wall and it is a tad too dark. Next time I better ask for advice here beforehand.
Do you mind sharing your settings for the CIECAM02 section? I’m new to HDRMerge and RT.
A little tutorial on what to do with the CIECAM02 tone mapping will be ideal!
I like the edited image from @Jonas_Wagner which is slightly brighter and vivid.
I’ve used my own shell script to simulate the ZeroNoise technique and process fake exposures (from the ZeroNoise output) with enfuse; but I never get any accepted/pleased result…
HDRMerge looks promising and better than my script because it works at the raw level.
The version of RT from the Open Build Service for Debian has been working very reliably for me for a long time and gets timely updates. The version in the Debian repo is ancient!
Hi there,
no problem. Here is the PP3. sthlm.tif.pp3 (5.8 KB)
It has been some time since I worked on it. Read the tooltip for tonemapping in RT carefully. It basically explains what is needed to get it working with CIECAM02.
Mica, that’s a good hint. For others it could be helpful, if you post the relevant sources.conf lines here. For me … Well, I’ve decided to spend a bit of my time on RT every now and then, so I’m building directly from git.
@paperdigits thanks a lot for the link! I was actually looking for something like this. I will install the updated version asap. Am also using regular Debian and I look forward to all the bug fixes
You are welcome, but you should really thank the repo maintainer for doing the packaging work, the updates usually come within 2 days of me seeing a post here.
But shure, I can compile the latest GIT version if I’m no longer content with the stock version’s features.
Your workflow sounds sane too.
