On Tue, Aug 9, 2022 at 12:12 PM Florian Königstein <[email protected]> wrote:
> The image DSC00293.JPG was missing. I took the image DSC00289.JPG as a > (false) replacement for it. > First, there are about 20 CPs with distances of about >9000. They are > totally wrong correspondences. I deleted them. > I really messed up in posting this. I don't quite understand how, but I can clearly look back and see I did. 293 is not part of the panorama. When I first tried to assemble this (long before selecting it as a test case) I thought 293 was part and got some terrible results due to that. Then I removed it. My testing was with the version I had removed 293 from. But somehow I posted with 293. Looking now, I see all the garbage CPs connect to that image. So removing that image was correct, rather than removing the garbage CPs (but I don't expect anyone should have guessed that). Sorry. > > Then I resetted all positions to zero and restarted optimizing rotations > and transations. It takes longer time and gives terrible results, and the > errors are varying if you do it again. Normally this should not happen > because it's a deterministic algorithm. But maybe SuiteSparse uses some > algorithms that are "slightly" not deterministic. > Thankyou for reminding me that is the way I should have been testing. I did that for previous performance testing but forgot this time. Your results really bother me. I thought the code was in better shape than that. Maybe the garbage extra image matters despite the CPs you removed. But I doubt it. Seems like something is in much worse shape than I thought. I hope you didn't enable any FOV optimization. I certainly think that is fundamentally broken in hugin and isn't safe to mix into any kind of controlled test. > > And in ill-conditioned mathematical problems like here small differences > in roundoff errors can lead to totally different results. > I'm very familiar with that in other optimization problems. I'm still not ready to believe that is what is happening here. > > I see no problem that different versions of Hugin / Hugin++ give different > results: It's just because the optimization problem is ill-conditioned. > I am certainly not surprised at Hugin vs. Hugin++ differences. I'm surprised at the giant Hugin 2020 vs. Hugin 2021 reduction in accuracy. I'm more surprised at the difference (despite it being smaller) between your build of hugin++ and my build of hugin++ across modest changes in source code none of which seem relevant to optimization speed or results. > > > Yes, the function lmdif_sparse() returns a code that indicates the > stopping criterion that was met. The meaning of the codes is described in > the file levmar.c. > Before I pay too much attention to really understanding what they mean, I want to figure out how to get the code displayed on the (details pull down of the) pop up that gives summary stats for the second strategy. I'd also like a way to keep the summary stats from the first strategy around long enough to read it. > > Without having checked it, I don't believe that B is met. I believe that > ftol is reached (return code 1). > How do you know the return code? I guess I had only concluded (by result and timing differences) that B was the non sparse termination reason (except in that 2021 official build). Until you made me rethink that, I was assuming with no valid reason that sparse had the same termination reason. > > > > I don't know exactly your idea about computing the partial derivatives, > but I think fastPTOptimizer does it quite well. > Before I used the function splm_intern_fdif_jac() (see it's description in > levmar.c), but then I used another method inside adjust.c that is at least > as fast as splm_intern_fdif_jac(). > Both of those are finite difference methods. I read through your code trying to understand why it might be better than having the levmar code do it (why it was worth writing that complicated code). I can see a few ways that accidental extra work is avoided in your code (by knowing the relationship between images and CPs) that would be harder to avoid in more general code. I didn't understand the version you're not using well enough to understand if it does some of that extra work. -- 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 on the web visit https://groups.google.com/d/msgid/hugin-ptx/CALe0Q_k%2BypFNRORNfumiXLSWc0sconPH%2BW6%3DFn7LcU-4H9CMEw%40mail.gmail.com.
