On Wednesday, August 10, 2022 at 3:24:57 PM UTC-4 Florian Königstein wrote:
> I searched all source code files of Hugin++ for the string "tilt" (e.g. > there could be variables tilt_x, tilt_y, tilt_z like in libpano13). But > there wasn't found anything. > So Hugin probably does not use tilt. > > I don't know the meaning of it. > > But I wouldn't delete the tilt from libpano13. Hugin and libpano are > widely used software, and surely some people have made other tools that can > be used with libpano13 and Hugin. > If there are no ** very good ** reasons against it, you should keep > backward compatibility when developing Hugin++ and libpano13 / > fastPTOptimizer further. > > One possibility is adding alternate code under a different internal name, such that it can be selected by the caller, but isn't used by default. So, there would be two optimizers there, one with the original performance and features, the other with better performance, removing some features I don't understand and don't think hugin++ uses, and adding the features that I want to add. The features I want to add would also change stitching. I'm not yet even looking at what backward compatibility for that would look like (but don't expect it to be difficult). For optimization, I will need to have new and old versions coexist in one build anyway during development. Once I think the new optimization is across the board better than the old one for hugin++, that doesn't necessarily give a good reason to remove the old one from the build. I'm not sure yet, but I think a parameter based internal (to the dll) run-time selection of which is being invoked (through the same call) would be better than simply giving the new one a new name. But either is practical. I'm a big believer in extern "C" interface across exe to dll boundaries wherever practical, even if both sides are coded in C++. That solves some problems in Linux, and a far larger number of uglier problems in Windows. If I make any big change to fastPTOptimize, the new code will be all C++. I doubt that will present any problems for those building it from source (as it might have presented problems back when libpano13 was first invented). But I certainly don't want to do anything that stops a caller of all the features of the DLL from being coded entirely in C. Having a C interface to the DLL (because it is currently coded in C) is a good starting point for having a C interface because I prefer a C interface on that boundary. I still hope this question gets a reply from someone who does know what those parameters are intended for and what other tools might be using them. -- 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/f76526c9-16b7-4703-b596-15a9eeb3856dn%40googlegroups.com.
