On Monday, August 8, 2022 at 3:29:44 PM UTC-4 Florian Königstein wrote:
> Before I answer to your post more detailed, could you please send me the > images per Mail so that I can load the pano without the need for dummy > images. Maybe the optimization was faster for me since some CPs were > deleted due to my dummy image. Having your images I can see the speed in > exactly your configuration. > I put them on a google drive and sent you a link. If I messed that up and you can't access, ask me again. > > I just tried out a pano with only two images. The camera was rotated by an > angle of about 22 degrees between the images. I also held the camera by > hand, but translation is anyway small compared to rotation. When I optimize > only yaw, pitch and roll, the optimizer finds the yaw of about 22 degrees. > When I optimize yaw, pitch, roll, TrX, TrY, TrZ, the optimizer finds a yaw > of 6 degrees and some rather big translation. That is nonsense. This > example confirms that estimating both rotation and translation when the > translation is zero or small is very difficult. > > Do you have enough overlap and control points distributed over the overlap area to make the distinction between translation and roll possible? Are your lens parameters likely correct so that lens parameter errors are not interfering with with the optimization? If yes to both, I'd like to see those images and project to try to understand what when wrong. With a true Yaw of 22 degrees and just two images, and limiting the optimization to yaw, pitch and roll, I would certainly expect hugin to get near the correct yaw, even if it is getting a fairly poor fit. If the overlap and CPs aren't very good, then it is also understandable that a better fit for the CPs could give a wildly wrong actual result, including a wildly wrong yaw. But that doesn't make the general case against optimizing all 6 basic camera point of view parameters. With multi-way overlap (as in the group of photos I sent) misinterpreting yaw for TrX in one limited overlap tends to be forced out of the solution by the circular interconnection of those two through other images. I don't EVER get as good results from hugin or hugin++ as I think I ought to. That was the original reason I started working on the code, though I delayed a long time before recently digging into the optimization. So I don't want to pre judge whether the two photo problem you just described is a fundamental limitation due to low CP overlap vs. hugin not really doing what it should. But I am confident that in the cases with more overlap (including virtual overlap through other connection routes) there is no basic flaw in optimizing all six of those camera point of view parameters. -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/e6a08dbf-5613-48fb-b900-86e26813732cn%40googlegroups.com.
