There was not a bug in my code, but there were some problems with linking
to incompatible libraries.
Further more, the PTOptimizer.exe that was as binary in my Hugin++ bundle
was compiled with a false option: Instead of printing messages to the
console
it tried unsuccesfully to open a window.
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,
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
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
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
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
I just tested my min / max feature on PToptimizer.exe and it seems that
there is some bug. It doesn't work as expected.
But it did work in earlier versions of "fastptoptimizer". I think that I'll
be able to fix it soon.
Florian Königstein schrieb am Samstag, 19. Februar 2022 um 10:35:52
In my version "fastptoptimizer" of libpano I have the options to define a
min and a max limit for each parameter, i.e. the optimizer won't change the
parameter beyond the limits. The min / max options define "hard" limits for
the parameter.
You can alternatively define "soft" limits by setting
This may or may not be helpful -- but in the SkyFill program I found a
version of levenberg marquardt that will fit with constraints on the
parameters. I *think* it is derived from the source code hugin has
(lmdir.c), so functionally might be quite close to what it in hugin. You
can find it
Hi !
Thank you for your taking some time on this.
I'll try to find some examples during the next week, and put a link to
download the individual images.
Le 13/02/2022 à 13:11, johnfi...@gmail.com a écrit :
I think that problem is important and ought to get some attention and
can be solved.
I think that problem is important and ought to get some attention and can
be solved.
But I think your suggested solution would not be effective. Either the
user would need to know enough in setting the limits that they might as
well just set the value and not optimize the variable, or
11 matches
Mail list logo
