so i extracted the OnFineTuneAll function from MainFrame into it's own binary...

[jak]

i wanted to script it in an assistant so here it is

just put cptune.cpp in ./src/hugin1/icpfind/ (couldn't get the includes to be built in time properly from the tools folder, feel free to put it wherever if you know better how to configure CMake, lol), and cptune.pod in ./docs/, patch the CMakeLists (or fix 'em yourself) and optionally patch Correlation.h to silence the "maxima to close to the border" non-errors from the CLI output (at least, PointFineTune just prints a debug line there while PointFineTuneRotSearch annoyingly prints an error)

seems to work as intended from my testing, have only tested in linux however, and not particularly thoroughly

[T. Modes]

jak schrieb am Mittwoch, 15. Mai 2024 um 07:45:23 UTC+2:

i wanted to script it in an assistant so here it is

the fine-tune function was written at a time without automatic control point detector in Hugin and was intended for fine-tuning manually set control points. Therefore scripting was not intending for this function.

For automatic found control points you should not call fine tune. Fine-tune works only at the 100 % scale. But the control points by cpfind are already optimized and contain information from several size scales. If you fine-tune these control points you destroy this information and so this should be avoided.

[jak]

my experience has been that cpfind creates a fair number of outright bad points and a few that are just a bit off and fine-tune tends to fix all of that fairly cleanly (where cpclean tends to miss many of these)

for reference i've been working on stitching 600dpi rectilinear scans of newsprint sized comics, this "information from several size scales" cpfind uses might very well be what's giving me these bad points as the size scaling between overlapping images should always be 1:1 here

in any case i went through the effort of getting this working and figured i'd share it for anyone else interested, even if it's considered "only for manually set points" it could still be useful for someone to batch-tune old projects or if they simply chose to manually set the points instead of using cpfind

[T. Modes]

jak schrieb am Mittwoch, 15. Mai 2024 um 19:49:57 UTC+2:

my experience has been that cpfind creates a fair number of outright bad points and a few that are just a bit off and fine-tune tends to fix all of that fairly cleanly (where cpclean tends to miss many of these)

then this should be fixed in cpfind, don't it? This should be tried first before introducing a new tool. Maybe you could try this first?

So only if this does not help, the patch could be taken into consideration. But then the patch needs a lot of reworking:

* Don't duplicate code of base algorithms. That makes the maintenance more difficult than necessary. So both places should use the same code.

* When using wx functions in a program you need to initialize the wx library before. Command line tools should use wxWidgets only if absolute necessary (some single program need it, but most cli are not depended on wxWidgets).

* Also the image cache needs some more initialization before using it.

* You are using nearly the whole alphabet for switches. Not all switches are really necessary to tweak by the user (e.g. reproject, alternate, maybe other also). Some are totally unnecessary: the correlation is always between 0 and 1. No need to clean cp with correlation >1.0 - this does not happen. Also is really the tweaking of the curvature necessary? This adds a lot of complexity to the command line, documentation but also to the code, which is not necessary.

There are many options technical possible, but it makes no sense to expose all finer details to the user. For some it is better to use sensible fixed default values.

* There may be other issues I have miss at a first scan of the code.

And then there are more formal issues

* Please provide an unified diff file with all changes in a single file. And not several files with the comment "feel free to put it wherever" (your words)

* Unnecessary code should be removed and not commented out only with the comment "not sure what these do but everything seems to work fine without it?". This helps nobody and adds only garbage.

* Please use our indentation/brace style (most new code is Allman style based) and don't mix in the same file.