I forgot to say: The optimizer, only divides the sum of squares by the square of the ratio of the actual AVERAGE FOV of the images to the initial AVERAGE FOV of the images if this ratio is smaller than one, i.e. if the actual AVERAGE FOV is smaller than the initial AVERAGE FOV. Otherwise, the error would get smaller if the FOV increases and the optimizer would tend to estimnate big FOVs. Florian Königstein schrieb am Sonntag, 20. Februar 2022 um 11:15:42 UTC+1:
> I have sometimes also the problem getting totally wrong results for yaw, > pitch and roll. Yes, limits can help from converging to a local minimum > with wrong parameters. E.g. you may know that the rotation of all images is > nearly zero or nearly 90 degrees. Then you can force the optimizer to keep > rotation e.g. in -10 ... 10 degrees or 80 .. 100 degrees. > > Since most cameras yield a good estimation of the FOV, I generally don't > optimize the FOV. > > Optimizing FOV is generally a difficult task. If you must for some reason > optimize the FOV, try setting the initial FOV to a value that is higher > than the expected value. > > Assume the FOVs that the optimizer actually assumes are relatively small. > If the optimizer makes the FOVs smaller so that it goes to zero, the > projection of the images onto the unit sphere get smaller - nearly > linear/proportional with the FOV. And the error also gets smaller with the > FOV. So the optimizer would estimate FOVs of zero and would set the yaw, > pitch and roll of all images equal. All control points would be projected > onto the same point on the unit sphere. > Of course this in not what we want. To prevent the optimizer from > estimating a FOV of zero, the sum of squares of the errors is artificially > divided by the square of a factor being proportional to the FOVs. To be > accurate, this factor is equal to the ratio of the actual AVERAGE FOV of > the images to the initial AVERAGE FOV of the image, so the error doesn't > tend to zero if the FOV goes to zero (and all yaw, pitch, roll tend to be > equal). > > In my version of libpano is probably not a bug in the code. But when I > compile it now, there seems to be some incompatibilites with SuiteSparse or > with libraries that SuiteSparse uses. > > > [email protected] schrieb am Samstag, 19. Februar 2022 um 13:27:14 > UTC+1: > >> Other than field of view, what parameters are able to produce wrong >> results that have lower total error than any correct result? >> >> If I understand correctly, that is the major reason for wanting limits. >> But in case I've misunderstood: >> In many other optimization problems hard limits are used to speed up >> optimization and/or keep it out of non convergence areas (where derivative >> based optimization sees a wrong direction and/or the error function might >> be NaN) even though those bad areas hold no false solutions. Is that also >> a significant issue in hugin? >> >> I still think a more stable objective function is a better idea than >> limits for solving the basic problem. But for discussing the value limits >> might have, I'd like to understand what aspect (if any) is general across >> many parameters, vs. what is specific to field of view. >> >> -- 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/d57d5003-7528-49eb-826f-80be443d2770n%40googlegroups.com.
