Update: this has worked very well. I have converted the multi-pass optimization you described into my scripted pipeline and it is working quite well. I have managed to successfully mosaic up to 65 images at a time (albeit skipping some of them to avoid excessive overlap). I am going to continue expanding to even larger batches.
Thanks again for your help! Best, Derek On Tuesday, May 5, 2026 at 10:40:23 PM UTC-4 Derek Dohler wrote: > Thank you Lukas! This is extremely helpful. > > I agree that it is not a simple example. I'm getting this: > http://78.46.190.157:8080/birds.jpg, ie, good alignment but the mapping > is a little wonky. While I don't think my result is great I have some > thoughts about that: > > > This is better than anything I've managed so far, this looks really good! > Thanks for trying! > > > -- the images overlap far too much. I have removed 2 out of every 3. > That could be done systematically, if they always overlap that much. > One could also truncate each image. > > > Okay, that's good to have confirmed. I suspected something like this might > be happening, and at one point I tried stitching "adjacent" images (based > on EXIF timestamp) into mini-panoramas before stitching the bigger one, > which seemed to help somewhat. I can repurpose that logic to simply skip > images taken close together instead. > > > -- I assume the images have been shot out the side of the plane, ie, not > vertically down. Then it is not correct to set yaw and pitch of the > anchor to zero. (I'm getting a yaw of ~20degrees). > > > Yes, this is correct. And thank you! I don't think I would have ever > realized this about the anchor on my own. > > > > -- freely optimising y/p/r/Tx/Ty/Tz of many images hardly ever converges > into the intended minimum. The obvious strategies are to optimise a few > images, add a few more, optimise them together, etc. Here, I have > optimised first Tx/Ty for all, then y/p/r for all except the anchor, > then y/p for the anchor. Tz has only been included for some images -- > optimising it for all yields better agreement but a worse mapping (and I > assume the plane has been at a consistent height). I don't have a good > idea how to deal with that -- the problem is obviously that the degrees > of freedom are not orthogonal. > > > Okay, perfect, this sounds workable. I hadn't considered a multi-pass > optimization like this, but it makes sense to do positions and y/p/r > separately to prevent them from confounding each other during optimization. > I think that the plane GPS track may be available somewhere in the data > dump, so it might be possible to impute an elevation to the images based on > timestamps. It probably wouldn't be precise enough to use directly, but > perhaps it could be used as a starting point that is close to reality. But > that sounds like an idea for v2. :) > > > -- having any right angles on the ground and using them for line control > points would help very much. > > > This is good to know. There aren't always going to be straight lines > available but in some cases there may be due to debris. I will keep an eye > out for opportunities to use this. > > Thank you very much for your help! > > Best, > Derek > > > > best regards, lukas wirz > > > > -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/hugin-ptx/1a8b07d5-58c5-4e0d-804c-67822cd01c46n%40googlegroups.com.
