What I want to say: the (rough) value is important - even is the absolute value is not so precise.
The calculation of the value is done by optimization. So there can always be several minimums. So the optimizer can finish in different minimum. Especially when you optimize "Everything" with the high degrees of freedom there a several solutions possible. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1856336 Title: Running geometric optimizer changes displayed focal length Status in Hugin: Opinion Bug description: I am a new 'hugin' user and I've been playing with it for about a week encountering various problems. I hope I've managed to make some systematization of the problems, so this report is the first in a series of reports I'm going to file. System info as hugin reports it: " Operating System: Linux 4.15.0-72-generic x86_64 Architecture: 64 bit Free memory: 2055068 kiB Hugin Version: 2019.0.0.a369cbe55179 Path to resources: /usr/share/hugin/xrc/ Path to data: /usr/share/hugin/data/ Hugins camera and lens database: /home/sergei/.hugindata/camlens.db Multi-threading using C++11 std::thread and OpenMP Libraries wxWidgets: wxWidgets 3.0.4 wxWidgets Library (wxGTK port) Version 3.0.4 (Unicode: wchar_t, debug level: 1), Runtime version of toolkit used is 2.24. Compile-time GTK+ version is 2.24.32. libpano13: 2.9.19 Boost: 1.65.1 Exiv2: 0.25.0 SQLite3: 3.22.0 Vigra: 1.11.0 LittleCMS2: 2.9 ". Location of input images: https://cloud.mail.ru/public/HmmR/35U75uuiB/ . Input images are DSC_0849.NEF .. DSC_0856.NEF files, i.e. 8 images altogether. If you want to download any file from the the URL, right- click on the file, and a drop-down menu with the following items in Russian will appear: Открыть в новой вкладке Скачать Сохранить в Облако . Select the second item, i.e. Скачать (which means Download), and the regular browser download window will appear. To reproduce the problem first import into 'hugin' input .NEF files the usual way using the "Photos" tab. Have a look at 'correct_focal_length.png' file in the above web folder for assistance. I chose RawTherapee version 5.7 to import files into 'hugin', and the profile file for RawTherapee is '/usr/share/rawtherapee/profiles/Unclipped.pp3' (it comes with RawTherapee). Just in case contents of the file: " [Exposure] ClampOOG=false Curve=0; Curve2=0; [Black & White] BeforeCurve=0; AfterCurve=0; [Vibrance] Enabled=false [Color appearance] Enabled=false [Film Simulation] Enabled=false [RGB Curves] LumaMode=false [Color Management] ApplyLookTable=false [RAW] CA=true CAAutoIterations=2 ". As the files are imported into hugin and the list of .tif files produced from the input .NEF files appears, click on any of the .tif files - as one can see in 'correct_focal_length.png' file 'DSC_0849.tif' file is selected, and it is also the default anchor file for both position and exposure. As a result of clicking on input .tif file lens focal distance and crop factor are displayed - which in this case are 18mm and 1.5 (again, see the 'correct_focal_length.png' file) . The numbers are correct - I indeed set the zoom to 18mm and the camera crop factor is 1.5 . I assume 'hugin' grabs this info from the .NEF files as it should. In this case all input files have the same focal length. After importing input files I went to the "Feature making" part of the GUI and detected control points fully automatically - see the 'correct_focal_length.png' file for details. After detecting control points I went to the "Optimize" part of the GUI and ran geometric optimizer - see the 'correct_focal_length.png' file for details. When geometric optimizer finished its work a window with its report appeared, and I clicked OK. As a result of it displayed focal length in the GUI changed to 22.982mm and the crop factor field became empty - see 'wrong_focal_length.png' file for details in the above web folder. It should be noted that the 22.982 is about 23, and the keyword here is "about". With the same set of input images the number changes slightly from invoking to invoking - for example, I remember 23.001, 22.999, etc. IMO such behavior is wrong - input focal length either comes from the raw file, or from user input - it shouldn't be changed by 'hugin'. Such behavior might indicate usage of uninitialized data or freed memory or index overrun, etc. If I understand correctly how overall 'hugin' works, focal length is used to calculate view angle, so wrong focal length can cause calculation of wrong view angles and thus lead to wrong stitching. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1856336/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp