I am afraid that I am doing something wrong with Hugin 2019.3.0 and cannot find what it is… After more than a week of redoing and retrying without success I can do with some help.
The project is a HDR panorama consisting of 9 horizontal about 30% overlapping pictures, each bracketed at 0 EV, -2 EV and +2 EV. All 27 pictures are 16-bit TIFFs (each about 182 MB). Every row has the same settings (aperture, ISO) and vary in shutter speed only. The pictures were taken with a tripod and a remote so each bracketed set is pixel accurate on top of each other.
Loading the 27 pictures in Hugin and creating 9 stacks is easy (the exposure settings calculated using aperture, shutter speed and ISO of each row is the same - as it should be). Running the control points sets about 1200 control points and they look OK. For the top row, the 0 EV row, I set the vertical lines of the major buildings (far away). Setting field of view and one can stitch the panorama.
Now comes the curious bit. The top 0 EV row stitches correctly and cannot find any errors; no ghosting, buildings/towers are straight etc in the TIFF. The result is 23713 x 4294 pixels.
The fused version however is totally unusable: the first/left 30% is OK, then parts are shifted, a small centre area is OK, then more horizontal shifts (eg. a church tower, some distance and the tower appears again, chimneys have ghosts to the left and right) and the last 5% is correct again. The intermediate files (exposure layer) of each stack has the same deformation so the final results should be on top of each other.
So the 0 EV result is correct but the fused version has these heavily shifted bits. Why? And what should I have to do to prevent that from happening?
And can one modify the fusion process (bit more of the +2 EV, and a bit less of the -2 EV layers)?
No. A 50 mm lens on the tripod hole but the closest objects are at least 340 m away. The 0 EV row stitches perfectly.
Yes tried to aligning each stack first, fusing them to a tiff, using Luminance. However, due to the autolevels at least 1 stack was completely off (could not find how to switch that off for van Hateren)… Somehow, I like Hugin’s merging is a bit more. It is a night shot… Just ran a stitch based on Luminance produced tiff’s but several lights and adverts are not white (and pure black areas are white… that can be gimped…)
1200 control points for 27 images seems rather high (I’ve got panos that are 145 to 200 images, and I’ve never used more than 600 control points) - are there any in the +2EV and -2EV image sets?
Try saving the images without tone mapping - Hugin can work with 32-bit HDR (not tone-mapped) images natively.
I can imagine that when you have a well evenly lit scene you only need one control point in a few quadrants to define the distortion to be applied to a picture. The distance between points helps then.
My image is dark. The light value based on aperture, shutterspeed, and ISO, using log_2(N**2/t) is only 3.1. The under exposure -2 EV is useful for some lit advertisements and lights in the distance. The +2 EV should enable me to light up some dark houses and the sky a bit. The sky should be green/blueish in the west, kind of darker purple-ish in the north (see the example). and red-ish orange in the east.
The sky is featureless (no clouds) and the foreground is a quiet river acting as a mirror. However, small ripples are still present, but except from two buoys no stationary lights. The leaves a small strip only with deterioration information… A few vertical lines can be defined assuming high lights reflecting in the water.
The control points are distributed between each EV row of 9 pictures, along the 9 stacks of 3 and a mix criscross. The control points in the water are not to be trusted… This leaves me a vertical band of about 25%.
Is there a way to delete double and/or close control points?
Will try to save Luminance results without tone mapping. Which operator would you recommend (a natural look is preferred) and how to switch the tone mapping to linear? I must admit I am not that familiar with Luminance yet.
Hard to tell exactly without looking at the project, but maybe this helps:
Hugin stitches pictures of similar exposure first, then merges the exposure levels to HDR.
Enblend determines the seams between overlapping pictures partially based on local brightness, so those seams may look different depending on the exposure level of those to pictures
This means that although pictures from one stack are perfectly aligned, part of the picture at 0EV might get paired with the -2EV picture from another stack in some place because enblend preferred to use the data from the neighbouring stack at that particular location.
How to test if this happens:
In the stitching tab, select “HDR stacks” and “stitched layers of similar exposure”, then export
check if the HDR stacks are nicely aligned and look good (that means that they were kept in the correct position)
check if the three exposure levels are stitched in the same way
ceck if there are any funny stitching errors in per exposure level – maybe the alignment didn’t work well?
Perhaps, but the the panoramas I mentioned are nothing of the sort, and has nothing at all to do with my advice to you. (FWIW moonless, cloudless night, with large patches that have no direct illumination.)
OK, it sounds (from “mix crisscross”) like you created the control points with all of your images, eg. you have control points created on the +2EV and -2EV images. If this is the case, try deleting all the control points on your +2EV and -2EV images (be sure to set your stacks before stitching.)
I don’t think so - I usually optimize, then delete points with high error amounts.
No operator, no tonemapping. You don’t “switch” tonemapping to linear, you simply don’t tonemap - just save the HDR images instead of tonemapping them. If you’re comfortable with the command line, you can use something like this:
After more tries I decided to go for just 1 one row only (the +2 EV row). From scratch. I was even able to use some stars near the top (this is a major European city and a very light polluted area - surprised to see that many starts for the very first time!).
After a while after setting everything up I restricted the “Panorama Outputs” to just two settings.
Did one more test… replaced the 16-bit tiffs with jpegs; same result.
As each EV row consists of 9 30% overlapping images with the same light value (using the same 50 mm lens) and each EV stack is pixel perfect overlapping, another test is possible: using the control points of one row for the other two rows. This shows that the mathematical operations are not the same as buildings and details shift. That is a surprise to me. Light intensities/transparencies etc have to be adjusted of course, but the transformation/deformation of each image in a stack should be the same (then the HDR bit using the 16 bit stitched row tiffs could be done external to Hugin). At least that was my assumption. It is clearly not the case.
I will study your workflow… I compiled Hugin 2019 and replaced it for an earlier distro release. Therefore, reinstalling it is simply a “make install”. Your
“Export to LDR TIFF. Although it says “LDR”, this will preserve the float and unclipped nature.”
Sounds just great.
Merge the bracketed shots with HDRMerge => already have the latest version, so the cumbersome HDR merging takes place outside of Hugin
In RT apply “Neutral” and “Unclipped”.
In RT enable lens correction and capture sharpening (new feature by @heckflosse bound for 5.8).
Adjust exposure to help stitching => if HDRmerge does exactly the same to each stack that should not be a problem
Export to 32b float TIFFs.
Stitch in Hugin 2019.0.0+ (important, since earlier versions will clip the result). => can do :- )
Export to LDR TIFF. Although it says “LDR”, this will preserve the float and unclipped nature => neat :- )
For this very sample I chose to apply “Unclipped” again on the resulting TIFF in RT and exported it at 50% resolution to a compressed 16b float TIFF. This reduced the file size from 520MB to 30MB.
I will try it next weekend I hope… Looking forward to it, as HDRmerge should not move pixels and I already have the control points it should be a quick test.
As each EV row consists of 9 30% overlapping images with the same light value (using the same 50 mm lens) and each EV stack is pixel perfect overlapping, another test is possible: using the control points of one row for the other two rows.
Just one question: you have told Hugin that the images of each stack are perfectly overlapping by linking the image positions in each stack? This should make the work for Hugin easier because it does not need the align the images in each stack.
If you run into trouble, drop me a message.