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/55d857f0-817a-41c1-9c27-e9630471ea0en%40googlegroups.com.
