On Friday, August 12, 2022 at 12:37:53 PM UTC-4 Florian Königstein wrote:
> Probably it's best here to first optimize only raw, pitch and roll and > then only translations. I gave that a lot of thought, and I have not yet coded/tested what I decided to do instead. But I think there is a better way to structure the idea of "first optimize only ...". My testing so far has caused me to conclude I need to first stabilize the behavior of what is there now, before making the big changes I really want. There is too much tendency for giant changes in performance and result quality from what is essentially luck (chaotic magnification of initial rounding error). To stabilize what is there now (reduce the luck element in its results): I think the ambiguity between rotation and translation is not a big problem. The two big problems that I think I understand are: 1) images that are not directly connected to the anchor image 2) the instability of the lens correction and fov optimization. I don't understand the benefits of the first stage optimizing one distance rather than two directional distances. But for now I'll trust that concept and expand on it. I want several initial stages, and lens parameters changeable only in the last initial stage. After all the initial stages, the "stage 2" would run exactly as it does now. As they do now, the initial stages would all run with cutoffs that should make then stop quickly (get only a rough fit). 1) First it would take the anchor image plus all those images that share 3 or more CPs with the anchor. 2-?) For subsequent initial stages, each time add all images that share 3 or more CPs with the union of all images of the prior stage. ?+1) If necessary (implying a very badly connected panorama) add all the rest of the images ?+2) Enable lens and fov if those were specified to be optimized. In cases where lens correction is major enough, it becomes a user problem to get the lens right (or at least close) first. In normal expert use, I expect the lens was solved earlier and not subject to further optimization. In normal beginner use, I expect the whole lens correction is subtle enough that delaying its optimization (earlier initial stages use whatever values were already there) is fine for the rough estimate intent of those stages. Each initial stage will only happen if it adds something to the previous initial stage. So simple panoramas with lens and fov already fixed would have the same single initial stage they have now. BTW, do you have any .pto files (in the format read by PToptimize.exe) that you think I should include in my testing? Is there some simple way (especially when you don't have the image files) to create a .pto in the PToptimize.exe format from a .pto in the hugin format? -- 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/777343f9-5ea9-4379-be85-8c03e59a42a5n%40googlegroups.com.
