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.
Thanks for your thoughts Karl. Vielen Dank.
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.
I think at some point you’ll probably need to post your files to get an accurate answer.
Hard to tell exactly without looking at the project, but maybe this helps:
How to test if this happens:
Good luck!
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:
luminance-hdr-cli --hdrWeight gaussian --hdrResponseCurve linear -v -s output.hdr inputfile1.tif inputfile2.tif inputfile3.tif
Ahh thanks Mr Teatime and Karl!
I am slowly understanding the process better.
Checked if the three exposure levels are stitched in the same way: 2 look good, the +2 EV one has a few errors.
Together with Karl’s info it is time to start all over again for another test.
PS: Love bash… :- )
Just FYI … a status update.
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.
“Exposure corrected, low dynamic range”:
And “High dynamic range” giving:
Same set, same settings. same run but a different output.
I am giving up.
Sorry to hear that it didn’t work!
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 had the same problem when trying HDR panorama in Hugin, and haven’t found a good solution.
If you’re not bound to Hugin alone, I described my current HDR pano workflow (involving HDRMerge and RawTherapee) here.
HTH,
Flössie
Thanks Sebastien and Flössie!
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.
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.
Danke!
Yeah, indeed. If I remember correctly, it actually was @Morgan_Hardwood who found this out.
If you run into trouble, drop me a message.
Thanks! Will do!
As an old open source user and hacker, I do prefer OSS tools (and I do not even have, nor want, access to PS and/or LR).
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.
Yes @stoffball
9 rows of 3 bracketed pictures… Stack 4 has been selected for AC
Funny thing is the first 3 stacks are OK, then 1 or 2 shifted, 1 or 2 OK, rest shifted again…
Sorry, but this is not visible in the screenshot. You are showing the general information and photometric parameters. I was speaking about geometric parameters (image positions). Can you attach the pto file (images are not needed, alternatively can you provide a download link)?
Please find the file below.
https://drive.google.com/file/d/1kFWy12M7fETT65HwZxMSsLBQ8f8FAlA_/view?usp=sharing
@Henk
ok, the image position are linked. But there are 2 other serious problems with the project file.
First, I doubt that you shoot the images with a lens with cylindrical projection. Switching back to a rectilinear lens projection decreases the control point error significantly.
Second, the overlap between your images is about 60-70 % and not 30 % as you written.
This interacts with the automatically stack detection and Hugin will try to merge 2 stacks into 1 HDR image. see Hugin Stitcher tab - PanoTools.org Wiki from the Hugin wiki, also included as help in Hugin. Even if is written under caption Exposure fusion the same algorithm applies also to HDR output.
Quote
If Exposure fused from stacks (added comment for HDR) is enabled then hugin will group the input images into exposure stacks by comparing positions, any images with more than 70 % overlap are grouped like this. Each of these bracketed exposure stacks will be exposure fused with enfuse (merged with hugin_hdrmerge into a HDR image) and the results seam blended together into a panorama with enblend.
To fine tune this read the last note in the list in the above mentioned file:
Quote
For special cases the percentage for decision for the overlap can be fine-tuned (only in expert). Go to Photos tab and select group by output stacks and change the minimum overlap value. If you want to use the already assigned stacks instead of the deduced stacks, set the minimum overlap value to -1.
PS: This behavior the area dates back before explicit stack handling in Hugin was implemented. Changing this would break backward compatibility.
Thank you for your efforts @stoffball !
I assume that resetting this now would mean all current control points will be invalid. Might try that next weekend or week… The lens was/is a 50 mm and I already was surprised to see the deviations near the edges but attributed it to roll and not 100.00% level camera rotation.
What Hugin said at some time ago to me was:
“Since the vertical field of view is not too wide, you could try setting the panorama projection to cylindrical Cylindrical projection preserves vertical lines, unlike equirectangular.”
Now I assume that that only applies to the stitch tab 
As there are many high rise flats in the distance, vertical lines need to be preserved. As there is water along the lower edge, and a dark sky along the top edge, there is only narrow band in the middle (only larger directly in front of me). So overlapping around 50% was my target. I (mis)understood that 30% was the minimum…
(beep (beep)! Never knew this!!! I already wondered where the 5 (instead of 9) stacks in the log file came from. Output stacks =/= input stacks… Hm so how to change that.
Set to -1 and hit Re-Optimise… Works
Bit of patience…
The result is absolutely gorgeous!!!
Thank you again!!
