[Hugin-bug-hunters] [Bug 2060139] Re: Filechooser leaves out directories
By default a flatpak has no access to the host filesystem and can't therefore open files in /mnt. You need to give the flatpak the right filesystem permissions. ** Changed in: hugin Status: New => Invalid -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2060139 Title: Filechooser leaves out directories Status in Hugin: Invalid Bug description: When choosing files and go to "Computer" I get a selection of directories; the directory "/mnt", amongst others, is not shown. Trying to drop files from there on the panorama creator does nothing: the files are not loaded. Hugin 2023.0.0.d88dc56ded0e (flatpak release) OS: Linux Mint 21.2 Cinnamon To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2060139/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1949326] Re: Hugin crashes when clicking twice on "optimize" while Hugin is busy
Fixed in repository ** Changed in: hugin Status: New => Fix Committed ** Changed in: hugin Milestone: None => 2024.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1949326 Title: Hugin crashes when clicking twice on "optimize" while Hugin is busy Status in Hugin: Fix Committed Bug description: To reproduce it, start Hugin, and open a PTO file that is large enough so that the loading takes some seconds. Probably you could instead start some other action so that Hugin is busy for some seconds. Before the loading has finished (or Hugin has finished the other action), press (left-click on) the grayed out button for geometrical optimization in the "images" tab TWO times. After loading has finished, two windows with title "Panorama Tools" will appear. In one the text 012345678901234567890123456789... appears and nothing changes over time. The other "Panorama Tools" window behaves normally. When finished optimization, accept the results. Then Hugin will crash. Betriebssystem: Windows 10 (build 19042), 64-bit edition Architektur: 64 bit Freier Speicher: 59397196 kiB Aktive Codepage: 1252 (Western European Windows) Hugin Version: Pre-Release 2021.0.0.f77f3586f101 built by Thomas Ressourcen-Pfad: C:\Program Files\Hugin\share\hugin\xrc\ Datenpfad: C:\Program Files\Hugin\share\hugin\data\ Hugins Kamera- und Objektivdatenbank: C:\Users\user\AppData\Roaming\hugin\camlens.db Multi-Threading mittels C++11 std::thread und OpenMP Monitorprofile: C:\Windows\system32\spool\drivers\color\sRGB Color Space Profile.icm Bibliotheken wxWidgets: wxWidgets 3.1.6 wxWidgets Library (wxMSW port) Version 3.1.6 (Unicode: wchar_t, debug level: 1), compiled at Oct 16 2021 14:59:21 Runtime version of toolkit used is 10.0. libpano13: 2.9.21 Exiv2: 0.27.4 SQLite3: 3.35.5 Vigra: 1.11.1 LittleCMS2: 2.10 To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1949326/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2056709] Re: Generating Hugin Default as of 20240229 - errors/warnings
I pushed some changeset which address these issues. ** Changed in: hugin Status: New => Fix Committed ** Changed in: hugin Milestone: None => 2024.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2056709 Title: Generating Hugin Default as of 20240229 - errors/warnings Status in Hugin: Fix Committed Bug description: Although as of 20240310 I now have a working Hugin, with no WxWidgets exceptions, the path to that was not completely smooth... I will attach a large text file with the problems I encountered, and what I did to solve them [or not solve them...]. Thank you for fixing #2052366! To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2056709/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2056709] Re: Generating Hugin Default as of 20240229 - errors/warnings
Putting all unrelated item in one ticket and then a text file makes it very difficult to answer on individual items. Next time please open one ticket for each item (or maybe 2-3 related in one ticket) and don't use description on external files. Some first comments: 1. ENABLE_LAPACK cmake flag not documented in INSTALL_cmake 7. In ... "#warning use LUT after parameter tuning [-Wcpp]" Both are related. I added a comment in INSTALL_cmake 2. rev.txt missing This file is not missing. Downloading all files from mercurial is not supported. The offical tarball contains this file. For development version use a mercurial checkout - this takes care of this file. 3. Three places that report: "Policy CMP0153 is not set: The exec_program command should not be called. This warning is new in newest CMake version. I will change it, but needs some more testing. Points 4./5./8./9./10. are all related and some errors are caused by your patching. -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2056709 Title: Generating Hugin Default as of 20240229 - errors/warnings Status in Hugin: New Bug description: Although as of 20240310 I now have a working Hugin, with no WxWidgets exceptions, the path to that was not completely smooth... I will attach a large text file with the problems I encountered, and what I did to solve them [or not solve them...]. Thank you for fixing #2052366! To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2056709/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2056095] Re: Enblend will not compile on Linux Musl
Should be fixed in repository (changeset 5ddeb593ba8c) ** Changed in: enblend Status: New => Fix Committed -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/2056095 Title: Enblend will not compile on Linux Musl Status in Enblend: Fix Committed Bug description: When compiling on linux with Musl libc, filespec.cc fails to compile because GLOB_BRACE does not exist. I see nothing indicating that it will be ever added to Musl, so the alternative would be to include a function to replace it on filespec.cc. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/2056095/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 785803] Re: Enblend --no-optimize produces black holes into panoramas
Fixes with changes in #2053287 ** Changed in: enblend Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/785803 Title: Enblend --no-optimize produces black holes into panoramas Status in Enblend: Fix Committed Bug description: --no-optimize: http://i.imgur.com/Bc9hD.jpg How it should look: http://i.imgur.com/MAyhz.jpg Win7 x64 w/ 32bit and x64 Hugin 2011.1 RC1 (2011.0.0.8f1447ab8649 built by Matthew Petroff), multithreaded Enblend. Project contains less than ten fisheye images encompassing the whole panosphere, so it's your average spherical panorama. You can see how much the images overlap here: http://i.imgur.com/KuAqU.jpg I think the issue could be related to too small overlap between images. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/785803/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 721136] Re: enblend creates an unexplainable black area.
Fixes with changes in #2053287 ** Changed in: enblend Status: Confirmed => Fix Committed -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/721136 Title: enblend creates an unexplainable black area. Status in Enblend: Fix Committed Bug description: enblending http://prive.bitwizard.nl/t80001.tif and http://prive.bitwizard.nl/t80003.tif results in http://prive.bitwizard.nl/t8a.tif I cannot say I expected that black triangle in the output. My enblend was pulled from hg this morning (no changes) and built without imagecache or openMP. (imagecache causes corruption of the output similar but different to this. ) To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/721136/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2053287] Re: sometimes there are black patches/corners in blended images
Thanks for testing. I also closed the mentioned tickets. -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/2053287 Title: sometimes there are black patches/corners in blended images Status in Enblend: Fix Committed Bug description: As has been known for a long time, enblend sometimes produces black patches in the corners of subimages. As we have discussed by email, I'd like to suggest a patch for that: -- patch1 contains the pyramid type to make the following simpler -- patch2 contains the actual change where the mask is corrected using both alpha layers prior to the actual blending step -- patch3 are two small functional changes that are unrelated to the main issue -- patch4 are modernisation and style improvements, that I just had to do while working on the code. If you think some of them don't add enough (or any) value, feel free to drop some. cheers, lukas wirz To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/2053287/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2053287] Re: sometimes there are black patches/corners in blended images
@Bruno: Are you building with automake or with CMake? (On Ubuntu with CMake it works. But it seems they are providing a patched vigra library, where this offending line is missing.) @Lukas: I applied now most of your patches and pushed the changes to the repository. Thank you again for the patches. Some parts I skipped because of cosmetic issues or some part results in compile error with MSVC. ** Changed in: enblend Status: New => Fix Committed -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/2053287 Title: sometimes there are black patches/corners in blended images Status in Enblend: Fix Committed Bug description: As has been known for a long time, enblend sometimes produces black patches in the corners of subimages. As we have discussed by email, I'd like to suggest a patch for that: -- patch1 contains the pyramid type to make the following simpler -- patch2 contains the actual change where the mask is corrected using both alpha layers prior to the actual blending step -- patch3 are two small functional changes that are unrelated to the main issue -- patch4 are modernisation and style improvements, that I just had to do while working on the code. If you think some of them don't add enough (or any) value, feel free to drop some. cheers, lukas wirz To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/2053287/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2053136] Re: App crashes on MacOS Sonoma 14
*** This bug is a duplicate of bug 2045446 *** https://bugs.launchpad.net/bugs/2045446 ** This bug has been marked a duplicate of bug 2045446 Hugin Crashes When Starting Program -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2053136 Title: App crashes on MacOS Sonoma 14 Status in Hugin: New Bug description: Just downloaded the latest version of the software. After opening it, I can see the interface and tooltips. When i close tooltips, the app crashes. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2053136/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2052366] Re: As of version 2023.x.x.x : An Assertion Failed! * 6
Fixed in repository (changeset 2b2251f51580). (The bug was in an old code. Maybe wxWidgets has become more pedantic in its check to earlier version.) ** Changed in: hugin Status: New => Fix Committed ** Changed in: hugin Milestone: None => 2024.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2052366 Title: As of version 2023.x.x.x : An Assertion Failed! * 6 Status in Hugin: Fix Committed Bug description: Until version 2023.x.x.x, I have not had the following occur. Now, each time the stitching process runs, there are 6 times that a PTBatcherGUI window appears that is headlined "An assertion failed!" Dismissing the first two causes the stitching to start and eventually to conclude successfully, but there are 4 additional windows. I believe that for each panorama stitched, the backtraces are the same - that is, the first backtrace for panorama #1 is the same as the backtrace for panorama #2, the second backtrace for #1 is the same as for #2, etc. It appears that the assertion is the same for all six windows, and that in fact, there are only three different backtraces, each repeated twice (#1==#2, #3==#4, #5==#6) ASSERT INFO: /usr/include/wx-3.2/wx/strvararg.h(484): assert "(argtype & (wxFormatStringSpecifier::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type The first two backtraces contain only: [1] wxEntry(int&, wchar_t**) [2] __libc_start_main #3/#4 add: [1] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [2] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [3] wxEvtHandler::TryHereOnly(wxEvent&) [4] wxEvtHandler::ProcessEventLocally(wxEvent&) [5] wxEvtHandler::ProcessEvent(wxEvent&) [6] wxEvtHandler::SafelyProcessEvent(wxEvent&) [7] wxTimerImpl::SendEvent() [8] g_main_loop_run [9] gtk_main [10] wxGUIEventLoop::DoRun() [11] wxEventLoopBase::Run() [12] wxAppConsoleBase::MainLoop() after the above (numbers, of course, different) #5/#6 add two more sets (total of 3) of: [1] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [2] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [3] wxEvtHandler::TryHereOnly(wxEvent&) [4] wxEvtHandler::ProcessEventLocally(wxEvent&) [5] wxEvtHandler::ProcessEvent(wxEvent&) but with a slightly different preface: [16] wxEvtHandler::ProcessPendingEvents() [17] wxAppConsoleBase::ProcessPendingEvents() [18] wxApp::DoIdle() after the [19] g_main_loop_run instead of the earlier: [6] wxEvtHandler::SafelyProcessEvent(wxEvent&) [7] wxTimerImpl::SendEvent() In case this explanation is confusing (likely!), I will [try to] attach a text file joining all six backtraces. I will also try to attach a video showing the stitch. I may have to upload it to YouTube and just include the link... == Debian Testing / sway/testing,now 1.8.1-2 amd64 [installed] Operating System: Linux 6.5.0-5-amd64 x86_64 Architecture: 64 bit Free memory: 8485176 kiB Hugin Version: 2023.0.0.d88dc56ded0e Path to resources: /usr/share/hugin/xrc/ Path to data: /usr/share/hugin/data/ Hugins camera and lens database: /home/scott/.local/share/hugin/camlens.db Multi-threading using C++11 std::thread and OpenMP Libraries wxWidgets: wxWidgets 3.2.4 wxWidgets Library (wxGTK port) Version 3.2.4 (Unicode: wchar_t, debug level: 1), Runtime version of toolkit used is 3.24. Compile-time GTK+ version is 3.24.38. libpano13: 2.9.22 Boost: 1.83.0 Exiv2: 0.27.6 SQLite3: 3.44.2 Vigra: 1.11.1 LittleCMS2: 2.14 To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2052366/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2049641] Re: Multiple RAW files with dcraw don't work
That helps to fix it. The log shows that the line were wrapped at the width of the control. When I decreased the width of the log window I was able to reproduce the bug. I fixed this in the repository. It will be in the next version. A workaround for the time being is the increase the width of the log window when dcraw runs. (This setting is stored so it needs to be done only once.) ** Changed in: hugin Status: New => Fix Committed ** Changed in: hugin Milestone: None => 2024.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2049641 Title: Multiple RAW files with dcraw don't work Status in Hugin: Fix Committed Bug description: Hello, I've had good results with JPEG files using Hugin and wanted to try RAW files. Since it is sufficient and you don't need any major software, I wanted to use dcraw. But I have a problem when I select several files at once as recommended. The first file is processed and then the import stops. If I interpret it correctly, there is probably a problem with the white-balance reference where, I think, not all the data is passed to the next pass. Prozessiere: C:\Program Files\Hugin\bin\dcraw.exe -w -v -4 -T "D:\test\test\IMG_0005.CR2" Loading Canon EOS 1300D image from D:\test\test\IMG_0005.CR2 ... Scaling with darkness 2048, saturation 13584, and multipliers 2.089844 1.00 1.419922 1.00 AHD interpolation... Converting to sRGB colorspace... Writing data to D:\test\test\IMG_0005.tiff ... Aktualisiere EXIF-Daten der Datei D:\test\test\IMG_0005.tiff 1 image files updated Vorgang dauerte 3 s Prozessiere: C:\Program Files\Hugin\bin\dcraw.exe -r 2.089844 1.00 -v -4 -T "D:\test\test\IMG_0006.CR2" Non-numeric argument to "-r" Vorgang dauerte 0 s From here nothing happens anymore. You can only cancel the import. If you import one file at a time, as is not recommended, there are no problems. Best regards Detlef Paschke To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2049641/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2049641] Re: Multiple RAW files with dcraw don't work
I upload a test version of Hugin with more debug output: https://sourceforge.net/projects/hugin/files/hugin/hugin-2024.0/Hugin_test_win.zip/download Please extract into a separate folder. Do not overwrite an existing installation. It contains only a subset of all files and it may hang after conversion. Please try to import your raw files. It will print some more debug information. Select details and then copy all the information it has printed. Maybe it delivers a hint what exactly goes wrong. -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2049641 Title: Multiple RAW files with dcraw don't work Status in Hugin: New Bug description: Hello, I've had good results with JPEG files using Hugin and wanted to try RAW files. Since it is sufficient and you don't need any major software, I wanted to use dcraw. But I have a problem when I select several files at once as recommended. The first file is processed and then the import stops. If I interpret it correctly, there is probably a problem with the white-balance reference where, I think, not all the data is passed to the next pass. Prozessiere: C:\Program Files\Hugin\bin\dcraw.exe -w -v -4 -T "D:\test\test\IMG_0005.CR2" Loading Canon EOS 1300D image from D:\test\test\IMG_0005.CR2 ... Scaling with darkness 2048, saturation 13584, and multipliers 2.089844 1.00 1.419922 1.00 AHD interpolation... Converting to sRGB colorspace... Writing data to D:\test\test\IMG_0005.tiff ... Aktualisiere EXIF-Daten der Datei D:\test\test\IMG_0005.tiff 1 image files updated Vorgang dauerte 3 s Prozessiere: C:\Program Files\Hugin\bin\dcraw.exe -r 2.089844 1.00 -v -4 -T "D:\test\test\IMG_0006.CR2" Non-numeric argument to "-r" Vorgang dauerte 0 s From here nothing happens anymore. You can only cancel the import. If you import one file at a time, as is not recommended, there are no problems. Best regards Detlef Paschke To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2049641/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2049641] Re: Multiple RAW files with dcraw don't work
The log file looks the same on my machine. When processing the first file dcraw prints the used wb multiplier: multipliers 1.832031 1.00 1.646484 1.00 These are parsed by hugin and passed to the second call of dcraw. This works on my side: Prozessiere: C:\Users\Thomas\Downloads\dcraw.exe -r 1.832031 1.00 1.646484 1.00 -v -4 -T "C:\date But on your side the last 2 numbers are missing: Prozessiere: C:\Program Files\Hugin\bin\dcraw.exe -r 1.832031 1.00 -v -4 -T "D:\test\IMG_0002.CR2" So my assumptions was that there were some hidden characters (ASCII <32), which confuses the parsing. But the log looks normal without hidden characters. (The parsing is very simple: all characters behind the word multipliers up to the line end are used to construct the second dcraw call.) Sorry, but currently I have no further idea what to check. ** Changed in: hugin Status: Incomplete => New -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2049641 Title: Multiple RAW files with dcraw don't work Status in Hugin: New Bug description: Hello, I've had good results with JPEG files using Hugin and wanted to try RAW files. Since it is sufficient and you don't need any major software, I wanted to use dcraw. But I have a problem when I select several files at once as recommended. The first file is processed and then the import stops. If I interpret it correctly, there is probably a problem with the white-balance reference where, I think, not all the data is passed to the next pass. Prozessiere: C:\Program Files\Hugin\bin\dcraw.exe -w -v -4 -T "D:\test\test\IMG_0005.CR2" Loading Canon EOS 1300D image from D:\test\test\IMG_0005.CR2 ... Scaling with darkness 2048, saturation 13584, and multipliers 2.089844 1.00 1.419922 1.00 AHD interpolation... Converting to sRGB colorspace... Writing data to D:\test\test\IMG_0005.tiff ... Aktualisiere EXIF-Daten der Datei D:\test\test\IMG_0005.tiff 1 image files updated Vorgang dauerte 3 s Prozessiere: C:\Program Files\Hugin\bin\dcraw.exe -r 2.089844 1.00 -v -4 -T "D:\test\test\IMG_0006.CR2" Non-numeric argument to "-r" Vorgang dauerte 0 s From here nothing happens anymore. You can only cancel the import. If you import one file at a time, as is not recommended, there are no problems. Best regards Detlef Paschke To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2049641/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2049641] Re: Multiple RAW files with dcraw don't work
One idea to test. Redirect the output of the first dcraw command to a log file and attach the log file here. >From your log the command should be: C:\Program Files\Hugin\bin\dcraw.exe -w -v -4 -T "D:\test\IMG_0001.CR2" 2>IMG_0001.log (and yes, it should be 2>IMG_0001.log) -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2049641 Title: Multiple RAW files with dcraw don't work Status in Hugin: Incomplete Bug description: Hello, I've had good results with JPEG files using Hugin and wanted to try RAW files. Since it is sufficient and you don't need any major software, I wanted to use dcraw. But I have a problem when I select several files at once as recommended. The first file is processed and then the import stops. If I interpret it correctly, there is probably a problem with the white-balance reference where, I think, not all the data is passed to the next pass. Prozessiere: C:\Program Files\Hugin\bin\dcraw.exe -w -v -4 -T "D:\test\test\IMG_0005.CR2" Loading Canon EOS 1300D image from D:\test\test\IMG_0005.CR2 ... Scaling with darkness 2048, saturation 13584, and multipliers 2.089844 1.00 1.419922 1.00 AHD interpolation... Converting to sRGB colorspace... Writing data to D:\test\test\IMG_0005.tiff ... Aktualisiere EXIF-Daten der Datei D:\test\test\IMG_0005.tiff 1 image files updated Vorgang dauerte 3 s Prozessiere: C:\Program Files\Hugin\bin\dcraw.exe -r 2.089844 1.00 -v -4 -T "D:\test\test\IMG_0006.CR2" Non-numeric argument to "-r" Vorgang dauerte 0 s From here nothing happens anymore. You can only cancel the import. If you import one file at a time, as is not recommended, there are no problems. Best regards Detlef Paschke To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2049641/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2049641] Re: Multiple RAW files with dcraw don't work
I tested with 3 different dcraw executables. All are version 9.28: Raw photo decoder "dcraw" v9.28 by Dave Coffin, dcoffin a cybercom o net Usage: dcraw.exe [OPTION]... [FILE]... -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2049641 Title: Multiple RAW files with dcraw don't work Status in Hugin: Incomplete Bug description: Hello, I've had good results with JPEG files using Hugin and wanted to try RAW files. Since it is sufficient and you don't need any major software, I wanted to use dcraw. But I have a problem when I select several files at once as recommended. The first file is processed and then the import stops. If I interpret it correctly, there is probably a problem with the white-balance reference where, I think, not all the data is passed to the next pass. Prozessiere: C:\Program Files\Hugin\bin\dcraw.exe -w -v -4 -T "D:\test\test\IMG_0005.CR2" Loading Canon EOS 1300D image from D:\test\test\IMG_0005.CR2 ... Scaling with darkness 2048, saturation 13584, and multipliers 2.089844 1.00 1.419922 1.00 AHD interpolation... Converting to sRGB colorspace... Writing data to D:\test\test\IMG_0005.tiff ... Aktualisiere EXIF-Daten der Datei D:\test\test\IMG_0005.tiff 1 image files updated Vorgang dauerte 3 s Prozessiere: C:\Program Files\Hugin\bin\dcraw.exe -r 2.089844 1.00 -v -4 -T "D:\test\test\IMG_0006.CR2" Non-numeric argument to "-r" Vorgang dauerte 0 s From here nothing happens anymore. You can only cancel the import. If you import one file at a time, as is not recommended, there are no problems. Best regards Detlef Paschke To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2049641/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2049641] Re: Multiple RAW files with dcraw don't work
Thanks for the test files. But I can't reproduce the issue. When using your file, dcraw processes both files without problems: Prozessiere: C:\Users\Thomas\Downloads\dcraw.exe -w -v -4 -T "C:\daten\Hugin\test\raw\Canon\IMG_0001.CR2" Loading Canon EOS 1300D image from C:\daten\Hugin\test\raw\Canon\IMG_0001.CR2 ... Scaling with darkness 2048, saturation 13584, and multipliers 1.832031 1.00 1.646484 1.00 AHD interpolation... Converting to sRGB colorspace... Writing data to C:\daten\Hugin\test\raw\Canon\IMG_0001.tiff ... Aktualisiere EXIF-Daten der Datei C:\daten\Hugin\test\raw\Canon\IMG_0001.tiff 1 image files updated Vorgang dauerte 5 s Prozessiere: C:\Users\Thomas\Downloads\dcraw.exe -r 1.832031 1.00 1.646484 1.00 -v -4 -T "C:\daten\Hugin\test\raw\Canon\IMG_0002.CR2" Loading Canon EOS 1300D image from C:\daten\Hugin\test\raw\Canon\IMG_0002.CR2 ... Scaling with darkness 2048, saturation 13584, and multipliers 1.832031 1.00 1.646484 1.00 AHD interpolation... Converting to sRGB colorspace... Writing data to C:\daten\Hugin\test\raw\Canon\IMG_0002.tiff ... Aktualisiere EXIF-Daten der Datei C:\daten\Hugin\test\raw\Canon\IMG_0002.tiff 1 image files updated Vorgang dauerte 4 s The log of dcraw looks identical to your run. So I don't understand why in your case the wb multiplier are not correctly read from the log. In the log they appear correct, but they are not correctly parsed for the second run of dcraw. Maybe your dcraw version adds some non-printable to the log? Could you try another dcraw version? Just to be sure: you are using the latest Hugin version 2023.0? -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2049641 Title: Multiple RAW files with dcraw don't work Status in Hugin: Incomplete Bug description: Hello, I've had good results with JPEG files using Hugin and wanted to try RAW files. Since it is sufficient and you don't need any major software, I wanted to use dcraw. But I have a problem when I select several files at once as recommended. The first file is processed and then the import stops. If I interpret it correctly, there is probably a problem with the white-balance reference where, I think, not all the data is passed to the next pass. Prozessiere: C:\Program Files\Hugin\bin\dcraw.exe -w -v -4 -T "D:\test\test\IMG_0005.CR2" Loading Canon EOS 1300D image from D:\test\test\IMG_0005.CR2 ... Scaling with darkness 2048, saturation 13584, and multipliers 2.089844 1.00 1.419922 1.00 AHD interpolation... Converting to sRGB colorspace... Writing data to D:\test\test\IMG_0005.tiff ... Aktualisiere EXIF-Daten der Datei D:\test\test\IMG_0005.tiff 1 image files updated Vorgang dauerte 3 s Prozessiere: C:\Program Files\Hugin\bin\dcraw.exe -r 2.089844 1.00 -v -4 -T "D:\test\test\IMG_0006.CR2" Non-numeric argument to "-r" Vorgang dauerte 0 s From here nothing happens anymore. You can only cancel the import. If you import one file at a time, as is not recommended, there are no problems. Best regards Detlef Paschke To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2049641/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2049641] Re: Multiple RAW files with dcraw don't work
I tested with my RAW files and it works here. There must be something with your RAW files Hugins is not reading correctly. Can you provide a link to 2-3 RAW files for further debugging? ** Changed in: hugin Status: New => Incomplete -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2049641 Title: Multiple RAW files with dcraw don't work Status in Hugin: Incomplete Bug description: Hello, I've had good results with JPEG files using Hugin and wanted to try RAW files. Since it is sufficient and you don't need any major software, I wanted to use dcraw. But I have a problem when I select several files at once as recommended. The first file is processed and then the import stops. If I interpret it correctly, there is probably a problem with the white-balance reference where, I think, not all the data is passed to the next pass. Prozessiere: C:\Program Files\Hugin\bin\dcraw.exe -w -v -4 -T "D:\test\test\IMG_0005.CR2" Loading Canon EOS 1300D image from D:\test\test\IMG_0005.CR2 ... Scaling with darkness 2048, saturation 13584, and multipliers 2.089844 1.00 1.419922 1.00 AHD interpolation... Converting to sRGB colorspace... Writing data to D:\test\test\IMG_0005.tiff ... Aktualisiere EXIF-Daten der Datei D:\test\test\IMG_0005.tiff 1 image files updated Vorgang dauerte 3 s Prozessiere: C:\Program Files\Hugin\bin\dcraw.exe -r 2.089844 1.00 -v -4 -T "D:\test\test\IMG_0006.CR2" Non-numeric argument to "-r" Vorgang dauerte 0 s From here nothing happens anymore. You can only cancel the import. If you import one file at a time, as is not recommended, there are no problems. Best regards Detlef Paschke To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2049641/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2046661] Re: Smart Screen blocks installation on Windows 10
You can remove the blocking tag in the file preferences. And it should install then. For getting a digital signature you have to pay to Microsoft. This I won't pay. ** Changed in: hugin Status: New => Opinion -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2046661 Title: Smart Screen blocks installation on Windows 10 Status in Hugin: Opinion Bug description: It seems the MSI file needs some digital signature to circumvent Windows Smart Screen's default blocking the installation. As the last version of Hugin could be installed without this issue (AFAIR), I guess it's a new "feature" of Windows 10 Smart Screen. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2046661/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2045960] Re: hugin 2023.0.0: three asserts with wxgtk 3.2.4
The assert should now be fixed in default branch. My comments in #4 are still valid. So there is still some room for improvement in your build script. ** Changed in: hugin Status: Incomplete => Fix Committed ** Changed in: hugin Milestone: None => 2024.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2045960 Title: hugin 2023.0.0: three asserts with wxgtk 3.2.4 Status in Hugin: Fix Committed Bug description: On startup when compiled against wxgtk 3.2.4 I get 3 asserts (that I don't get when compiled against wxgtk 3.1.7) I can click continue and hugin appears to work despite the errors on startup: ASSERT INFO: /var/tmp/paludis/build/x11-libs-wxGTK-3.2.4/work/wxWidgets-3.2.4/src/gtk/dc.cpp(497): assert ""cr"" failed in wxPaintDCImpl(): using wxPaintDC without being in a native paint event BACKTRACE: [1] wxPaintDC::wxPaintDC(wxWindow*) [2] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [3] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [4] wxEvtHandler::TryHereOnly(wxEvent&) [5] wxEvtHandler::ProcessEventLocally(wxEvent&) [6] wxEvtHandler::ProcessEvent(wxEvent&) [7] wxEvtHandler::SafelyProcessEvent(wxEvent&) [8] wxWindow::GTKSendPaintEvents(_cairo*) [9] g_closure_invoke [10] g_signal_emit_valist [11] g_signal_emit [12] gtk_container_propagate_draw [13] g_closure_invoke [14] g_signal_emit_valist [15] g_signal_emit [16] gtk_container_propagate_draw [17] g_closure_invoke [18] g_signal_emit_valist [19] g_signal_emit [20] gtk_container_propagate_draw [21] g_closure_invoke [22] g_signal_emit_valist [23] g_signal_emit [24] gtk_container_propagate_draw [25] gtk_container_propagate_draw [26] gtk_main_do_event [27] wxWindow::Update() [28] wxAuiManager::OnSize(wxSizeEvent&) [29] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [30] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [31] wxEvtHandler::TryHereOnly(wxEvent&) [32] wxEvtHandler::ProcessEventLocally(wxEvent&) [33] wxEvtHandler::ProcessEvent(wxEvent&) [34] wxEvtHandler::SafelyProcessEvent(wxEvent&) [35] wxWindow::DoSetSize(int, int, int, int, int) [36] wxBoxSizer::RepositionChildren(wxSize const&) [37] wxSizer::Layout() [38] wxWindowBase::Layout() [39] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [40] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [41] wxEvtHandler::TryHereOnly(wxEvent&) [42] wxEvtHandler::ProcessEventLocally(wxEvent&) [43] wxEvtHandler::ProcessEvent(wxEvent&) [44] wxEvtHandler::SafelyProcessEvent(wxEvent&) [45] g_closure_invoke [46] g_signal_emit_valist [47] g_signal_emit [48] gtk_widget_size_allocate_with_baseline [49] gtk_widget_size_allocate_with_baseline [50] g_closure_invoke [51] g_signal_emit_valist [52] g_signal_emit [53] gtk_widget_size_allocate_with_baseline [54] g_signal_emit_valist [55] g_signal_emit [56] g_closure_invoke [57] g_signal_emit_valist [58] g_signal_emit [59] g_main_context_iteration [60] gtk_main_iteration [61] wxGUIEventLoop::DoYieldFor(long) [62] wxEventLoopBase::YieldFor(long) [63] wxAppConsoleBase::Yield(bool) [64] wxEntry(int&, wchar_t**) [65] __libc_start_main ASSERT INFO: /var/tmp/paludis/build/x11-libs-wxGTK-3.2.4/work/wxWidgets-3.2.4/src/common/dcgraph.cpp(466): assert ""IsOk()"" failed in SetTextForeground(): wxGCDC(cg)::SetTextForeground - invalid DC BACKTRACE: [1] wxGCDCImpl::SetTextForeground(wxColour const&) [2] wxDCImpl::InheritAttributes(wxWindow*) [3] wxPaintDC::wxPaintDC(wxWindow*) [4] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [5] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [6] wxEvtHandler::TryHereOnly(wxEvent&) [7] wxEvtHandler::ProcessEventLocally(wxEvent&) [8] wxEvtHandler::ProcessEvent(wxEvent&) [9] wxEvtHandler::SafelyProcessEvent(wxEvent&) [10] wxWindow::GTKSendPaintEvents(_cairo*) [11] g_closure_invoke [12] g_signal_emit_valist [13] g_signal_emit [14] gtk_container_propagate_draw [15] g_closure_invoke [16] g_signal_emit_valist [17] g_signal_emit [18] gtk_container_propagate_draw [19] g_closure_invoke [20] g_signal_emit_valist [21] g_signal_emit [22] gtk_container_propagate_draw [23] g_closure_invoke [24] g_signal_emit_valist [25] g_signal_emit [26] gtk_container_propagate_draw [27] gtk_container_propagate_draw [28] gtk_main_do_event [29] wxWindow::Update() [30] wxAuiManager::OnSize(wxSizeEvent&) [31] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [32] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [33] wxEvtHandler::TryHereOnly(wxEvent&) [34]
[Hugin-bug-hunters] [Bug 2045960] Re: hugin 2023.0.0: three asserts with wxgtk 3.2.4
I had no time to look into the asserts. But some comments after a first look: * You are adding many parameters with default settings. This makes reading the command line more complicated than needed. * The command lines are very long. No sure if all settings are really needed. Do you really need all your user defined changes? * The settings will result in crashes when running under Wayland because you disabled all settings which are added to support this window manager. * Using -DCMAKE_BUILD_TYPE:STRING=None is completely unsupported. I think only the default build types Debug, Release, RelWithDebInfo and MinSizeRel are supported by the underlying CMake modules (shipped with CMake). And Hugin does not add any additional build types. So passing this build type can result in unwanted side effects. I strongly discourage from using the build type and instead stick with the standard build types. -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2045960 Title: hugin 2023.0.0: three asserts with wxgtk 3.2.4 Status in Hugin: Incomplete Bug description: On startup when compiled against wxgtk 3.2.4 I get 3 asserts (that I don't get when compiled against wxgtk 3.1.7) I can click continue and hugin appears to work despite the errors on startup: ASSERT INFO: /var/tmp/paludis/build/x11-libs-wxGTK-3.2.4/work/wxWidgets-3.2.4/src/gtk/dc.cpp(497): assert ""cr"" failed in wxPaintDCImpl(): using wxPaintDC without being in a native paint event BACKTRACE: [1] wxPaintDC::wxPaintDC(wxWindow*) [2] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [3] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [4] wxEvtHandler::TryHereOnly(wxEvent&) [5] wxEvtHandler::ProcessEventLocally(wxEvent&) [6] wxEvtHandler::ProcessEvent(wxEvent&) [7] wxEvtHandler::SafelyProcessEvent(wxEvent&) [8] wxWindow::GTKSendPaintEvents(_cairo*) [9] g_closure_invoke [10] g_signal_emit_valist [11] g_signal_emit [12] gtk_container_propagate_draw [13] g_closure_invoke [14] g_signal_emit_valist [15] g_signal_emit [16] gtk_container_propagate_draw [17] g_closure_invoke [18] g_signal_emit_valist [19] g_signal_emit [20] gtk_container_propagate_draw [21] g_closure_invoke [22] g_signal_emit_valist [23] g_signal_emit [24] gtk_container_propagate_draw [25] gtk_container_propagate_draw [26] gtk_main_do_event [27] wxWindow::Update() [28] wxAuiManager::OnSize(wxSizeEvent&) [29] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [30] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [31] wxEvtHandler::TryHereOnly(wxEvent&) [32] wxEvtHandler::ProcessEventLocally(wxEvent&) [33] wxEvtHandler::ProcessEvent(wxEvent&) [34] wxEvtHandler::SafelyProcessEvent(wxEvent&) [35] wxWindow::DoSetSize(int, int, int, int, int) [36] wxBoxSizer::RepositionChildren(wxSize const&) [37] wxSizer::Layout() [38] wxWindowBase::Layout() [39] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [40] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [41] wxEvtHandler::TryHereOnly(wxEvent&) [42] wxEvtHandler::ProcessEventLocally(wxEvent&) [43] wxEvtHandler::ProcessEvent(wxEvent&) [44] wxEvtHandler::SafelyProcessEvent(wxEvent&) [45] g_closure_invoke [46] g_signal_emit_valist [47] g_signal_emit [48] gtk_widget_size_allocate_with_baseline [49] gtk_widget_size_allocate_with_baseline [50] g_closure_invoke [51] g_signal_emit_valist [52] g_signal_emit [53] gtk_widget_size_allocate_with_baseline [54] g_signal_emit_valist [55] g_signal_emit [56] g_closure_invoke [57] g_signal_emit_valist [58] g_signal_emit [59] g_main_context_iteration [60] gtk_main_iteration [61] wxGUIEventLoop::DoYieldFor(long) [62] wxEventLoopBase::YieldFor(long) [63] wxAppConsoleBase::Yield(bool) [64] wxEntry(int&, wchar_t**) [65] __libc_start_main ASSERT INFO: /var/tmp/paludis/build/x11-libs-wxGTK-3.2.4/work/wxWidgets-3.2.4/src/common/dcgraph.cpp(466): assert ""IsOk()"" failed in SetTextForeground(): wxGCDC(cg)::SetTextForeground - invalid DC BACKTRACE: [1] wxGCDCImpl::SetTextForeground(wxColour const&) [2] wxDCImpl::InheritAttributes(wxWindow*) [3] wxPaintDC::wxPaintDC(wxWindow*) [4] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [5] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [6] wxEvtHandler::TryHereOnly(wxEvent&) [7] wxEvtHandler::ProcessEventLocally(wxEvent&) [8] wxEvtHandler::ProcessEvent(wxEvent&) [9] wxEvtHandler::SafelyProcessEvent(wxEvent&) [10] wxWindow::GTKSendPaintEvents(_cairo*) [11] g_closure_invoke [12] g_signal_emit_valist [13] g_signal_emit [14] gtk_container_propagate_draw [15] g_closure_invoke [16] g_signal_emit_valist
[Hugin-bug-hunters] [Bug 2045960] Re: hugin 2023.0.0: three asserts with wxgtk 3.2.4
Tested with wxWidgets 3.2.4 and don't get any asserts. So it may only appear with some special parameters. How have you configured wxWidgets and Hugin during build process? ** Changed in: hugin Status: New => Incomplete -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2045960 Title: hugin 2023.0.0: three asserts with wxgtk 3.2.4 Status in Hugin: Incomplete Bug description: On startup when compiled against wxgtk 3.2.4 I get 3 asserts (that I don't get when compiled against wxgtk 3.1.7) I can click continue and hugin appears to work despite the errors on startup: ASSERT INFO: /var/tmp/paludis/build/x11-libs-wxGTK-3.2.4/work/wxWidgets-3.2.4/src/gtk/dc.cpp(497): assert ""cr"" failed in wxPaintDCImpl(): using wxPaintDC without being in a native paint event BACKTRACE: [1] wxPaintDC::wxPaintDC(wxWindow*) [2] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [3] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [4] wxEvtHandler::TryHereOnly(wxEvent&) [5] wxEvtHandler::ProcessEventLocally(wxEvent&) [6] wxEvtHandler::ProcessEvent(wxEvent&) [7] wxEvtHandler::SafelyProcessEvent(wxEvent&) [8] wxWindow::GTKSendPaintEvents(_cairo*) [9] g_closure_invoke [10] g_signal_emit_valist [11] g_signal_emit [12] gtk_container_propagate_draw [13] g_closure_invoke [14] g_signal_emit_valist [15] g_signal_emit [16] gtk_container_propagate_draw [17] g_closure_invoke [18] g_signal_emit_valist [19] g_signal_emit [20] gtk_container_propagate_draw [21] g_closure_invoke [22] g_signal_emit_valist [23] g_signal_emit [24] gtk_container_propagate_draw [25] gtk_container_propagate_draw [26] gtk_main_do_event [27] wxWindow::Update() [28] wxAuiManager::OnSize(wxSizeEvent&) [29] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [30] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [31] wxEvtHandler::TryHereOnly(wxEvent&) [32] wxEvtHandler::ProcessEventLocally(wxEvent&) [33] wxEvtHandler::ProcessEvent(wxEvent&) [34] wxEvtHandler::SafelyProcessEvent(wxEvent&) [35] wxWindow::DoSetSize(int, int, int, int, int) [36] wxBoxSizer::RepositionChildren(wxSize const&) [37] wxSizer::Layout() [38] wxWindowBase::Layout() [39] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [40] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [41] wxEvtHandler::TryHereOnly(wxEvent&) [42] wxEvtHandler::ProcessEventLocally(wxEvent&) [43] wxEvtHandler::ProcessEvent(wxEvent&) [44] wxEvtHandler::SafelyProcessEvent(wxEvent&) [45] g_closure_invoke [46] g_signal_emit_valist [47] g_signal_emit [48] gtk_widget_size_allocate_with_baseline [49] gtk_widget_size_allocate_with_baseline [50] g_closure_invoke [51] g_signal_emit_valist [52] g_signal_emit [53] gtk_widget_size_allocate_with_baseline [54] g_signal_emit_valist [55] g_signal_emit [56] g_closure_invoke [57] g_signal_emit_valist [58] g_signal_emit [59] g_main_context_iteration [60] gtk_main_iteration [61] wxGUIEventLoop::DoYieldFor(long) [62] wxEventLoopBase::YieldFor(long) [63] wxAppConsoleBase::Yield(bool) [64] wxEntry(int&, wchar_t**) [65] __libc_start_main ASSERT INFO: /var/tmp/paludis/build/x11-libs-wxGTK-3.2.4/work/wxWidgets-3.2.4/src/common/dcgraph.cpp(466): assert ""IsOk()"" failed in SetTextForeground(): wxGCDC(cg)::SetTextForeground - invalid DC BACKTRACE: [1] wxGCDCImpl::SetTextForeground(wxColour const&) [2] wxDCImpl::InheritAttributes(wxWindow*) [3] wxPaintDC::wxPaintDC(wxWindow*) [4] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [5] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [6] wxEvtHandler::TryHereOnly(wxEvent&) [7] wxEvtHandler::ProcessEventLocally(wxEvent&) [8] wxEvtHandler::ProcessEvent(wxEvent&) [9] wxEvtHandler::SafelyProcessEvent(wxEvent&) [10] wxWindow::GTKSendPaintEvents(_cairo*) [11] g_closure_invoke [12] g_signal_emit_valist [13] g_signal_emit [14] gtk_container_propagate_draw [15] g_closure_invoke [16] g_signal_emit_valist [17] g_signal_emit [18] gtk_container_propagate_draw [19] g_closure_invoke [20] g_signal_emit_valist [21] g_signal_emit [22] gtk_container_propagate_draw [23] g_closure_invoke [24] g_signal_emit_valist [25] g_signal_emit [26] gtk_container_propagate_draw [27] gtk_container_propagate_draw [28] gtk_main_do_event [29] wxWindow::Update() [30] wxAuiManager::OnSize(wxSizeEvent&) [31] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [32] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [33] wxEvtHandler::TryHereOnly(wxEvent&) [34] wxEvtHandler::ProcessEventLocally(wxEvent&) [35]
[Hugin-bug-hunters] [Bug 2038860] Re: Updated Hungarian translations
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2038860 Title: Updated Hungarian translations Status in Hugin: Fix Released Bug description: Updated Hungarian translations for Hugin 2023.0 beta1 To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2038860/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2037164] Re: 2023.0 beta1 assert after klick on [Stitch]
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2037164 Title: 2023.0 beta1 assert after klick on [Stitch] Status in Hugin: Fix Released Bug description: Hello, klicking Stitch! on the Stitcher tab yields assert errors like this one: - ASSERT INFO: /usr/include/wx-3.2/wx/strvararg.h(484): assert "(argtype & (wxFormatStringSpecifier::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type BACKTRACE: [1] HuginQueue::detail::GenerateFinalArgfile(HuginBase::Panorama const&, wxString const&, wxConfigBase const*, std::set, std::allocator > const&, double) [2] HuginQueue::GetStitchingCommandQueue(HuginBase::Panorama const&, wxString const&, wxString const&, wxString const&, wxString&, wxArrayString&, wxArrayString&, std::ostream&) [3] RunStitchPanel::StitchProject(wxString const&, wxString const&, wxString const&) [4] wxEntry(int&, wchar_t**) [5] __libc_start_main - (2023.0 beta1, built against libepoxy) cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2037164/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2041687] Re: does not show/log enblend error messages
Thanks to all for testing. Will today release 2023.0 rc1 ** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2041687 Title: does not show/log enblend error messages Status in Hugin: Fix Released Bug description: Hello, hugin does not show/log enblend errors. I think it did previously. This is on 2023.0~beta1+dfsg-1. This was originally reported by Michael Deegan in https://bugs.debian.org/1054129 It is easy to reproduce by replacing enblend with a dummy-script like this one -#!/bin/sh echo status on stdout echo error in stderr 1>&2 exit 1 -- The corresponding logfile ends with Remapping LDR images... Blending images... Process took 9 s cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2041687/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2041687] Re: does not show/log enblend error messages
Fixed in repository. It took some time to tackle this down. It does not happen on Ubuntu 2022.4 LTS with wxWidgets 3.0.5 in my test virtual machine. After upgrading to 2023.4 with wxWidgets 3.2.2 I could reproduce the issue. It is related to 0x0 characters in the output, which wxWidgets 3.2.x pass through while 3.0.5 seems to have them filtered out. This causes issues like the one you observed. It should now be fixed in repository in 2023.0 branch. Initially I had the plan to release rc1 this weekend. But it has to wait until the fix is confirmed (that it is working and does not break anything else). ** Changed in: hugin Status: New => Fix Committed ** Changed in: hugin Milestone: None => 2023.0rc1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2041687 Title: does not show/log enblend error messages Status in Hugin: Fix Committed Bug description: Hello, hugin does not show/log enblend errors. I think it did previously. This is on 2023.0~beta1+dfsg-1. This was originally reported by Michael Deegan in https://bugs.debian.org/1054129 It is easy to reproduce by replacing enblend with a dummy-script like this one -#!/bin/sh echo status on stdout echo error in stderr 1>&2 exit 1 -- The corresponding logfile ends with Remapping LDR images... Blending images... Process took 9 s cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2041687/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2038860] Re: Updated Hungarian translations
Thanks, committed to repository. ** Changed in: hugin Status: New => Fix Committed ** Changed in: hugin Milestone: None => 2023.0rc1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2038860 Title: Updated Hungarian translations Status in Hugin: Fix Committed Bug description: Updated Hungarian translations for Hugin 2023.0 beta1 To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2038860/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2037164] Re: 2023.0 beta1 assert after klick on [Stitch]
Should be fixed in repository (changeset adfe0b28c62a) ** Changed in: hugin Status: New => Fix Committed ** Changed in: hugin Milestone: None => 2023.0rc1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2037164 Title: 2023.0 beta1 assert after klick on [Stitch] Status in Hugin: Fix Committed Bug description: Hello, klicking Stitch! on the Stitcher tab yields assert errors like this one: - ASSERT INFO: /usr/include/wx-3.2/wx/strvararg.h(484): assert "(argtype & (wxFormatStringSpecifier::value)) == argtype" failed in wxArgNormalizer(): format specifier doesn't match argument type BACKTRACE: [1] HuginQueue::detail::GenerateFinalArgfile(HuginBase::Panorama const&, wxString const&, wxConfigBase const*, std::set, std::allocator > const&, double) [2] HuginQueue::GetStitchingCommandQueue(HuginBase::Panorama const&, wxString const&, wxString const&, wxString const&, wxString&, wxArrayString&, wxArrayString&, std::ostream&) [3] RunStitchPanel::StitchProject(wxString const&, wxString const&, wxString const&) [4] wxEntry(int&, wchar_t**) [5] __libc_start_main - (2023.0 beta1, built against libepoxy) cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2037164/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1989723] Re: aborts on startup when built against wxwidgets3.2
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1989723 Title: aborts on startup when built against wxwidgets3.2 Status in Hugin: Fix Released Bug description: Hello, I have tried building hugin 2021.0 against wxwidgets3.2. It builds fine (some new deprecation warnings), but the binary is non- functional. It aborts immediately on startup, offering to save some debugging info (attached). cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1989723/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 847433] Re: 'Create panorama' is disabled in single photo projects
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/847433 Title: 'Create panorama' is disabled in single photo projects Status in Hugin: Fix Released Bug description: When starting a project, both 2. Align... and 3. Create panorama are greyed out which makes sense. However if I load a single photo into Hugin, they are still greyed. This is a problem as a common use of Hugin for me is to load a single image and remap it to a different projection. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/847433/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 679939] Re: add quick crop
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/679939 Title: add quick crop Status in Hugin: Fix Released Bug description: in the crop tool of the fast preview add this functionality: doubleclick (left) sets the left (/upper/right/lower) crop side to the leftmost "black" pixel, ie everything left from this line has at least one colored pixel. a right doubleclick sets it such that there is at least one colored pixel to the right and none to the left. as double right click does not really exist, a shift left click could be implemented as this as well... To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/679939/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2025037] Re: Heap-buffer-overflow when adding an image in HuginBase::PTools::setDestImage
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2025037 Title: Heap-buffer-overflow when adding an image in HuginBase::PTools::setDestImage Status in Hugin: Fix Released Bug description: Hi there We want to share that the latest version (2022.0.0) of pto_merge causes another heap-buffer-overflow bug in the function HuginBase::PTools::setDestImage as well as in the function HuginBase::PanoramaMemento::loadPTScript. The invalid memory allocation may attribute to the malformed values as parameters to the HuginBase::PTools::setDestImage . Here is the output of program with address sanitizer attached. Bug Report ERROR: 13:28:41.047604 (/home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panotools/PanoToolsInterface.cpp:357) setDestImage(): unsupported projection = ==4011==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60309808 at pc 0x7f973bddfdeb bp 0x7fff0426e670 sp 0x7fff0426e660 READ of size 8 at 0x60309808 thread T0 #0 0x7f973bddfdea in HuginBase::PTools::setDestImage(Image&, vigra::Diff2D, unsigned char*, HuginBase::PanoramaOptions::ProjectionFormat const&, std::vector > const&, double) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panotools/PanoToolsInterface.cpp:362 #1 0x7f973bde173e in HuginBase::PTools::Transform::updatePTData(vigra::Diff2D const&, std::map, std::allocator >, HuginBase::Variable, std::less, std::allocator > >, std::allocator, std::allocator > const, HuginBase::Variable> > > const&, HuginBase::BaseSrcPanoImage::Projection&, vigra::Diff2D const&, HuginBase::PanoramaOptions::ProjectionFormat&, std::vector > const&, double) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panotools/PanoToolsInterface.cpp:66 #2 0x7f973bde1b53 in HuginBase::PTools::Transform::createTransform(vigra::Diff2D const&, std::map, std::allocator >, HuginBase::Variable, std::less, std::allocator > >, std::allocator, std::allocator > const, HuginBase::Variable> > >, HuginBase::BaseSrcPanoImage::Projection, vigra::Diff2D const&, HuginBase::PanoramaOptions::ProjectionFormat, std::vector > const&, double, vigra::Diff2D const&) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panotools/PanoToolsInterface.cpp:181 #3 0x7f973bded5d8 in HuginBase::PTools::Transform::createTransform(HuginBase::SrcPanoImage const&, HuginBase::PanoramaOptions const&) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panotools/PanoToolsInterface.cpp:147 #4 0x7f973bcef22b in HuginBase::PanoramaOptions::getVFOV() const /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/PanoramaOptions.cpp:358 #5 0x7f973bcf131d in HuginBase::PanoramaOptions::setProjectionParameters(std::vector > const&) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/PanoramaOptions.cpp:190 #6 0x7f973bcf1858 in HuginBase::PanoramaOptions::resetProjectionParameters() /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/PanoramaOptions.cpp:200 #7 0x7f973bc722b9 in HuginBase::PanoramaMemento::loadPTScript(std::istream&, int&, std::__cxx11::basic_string, std::allocator > const&) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/Panorama.cpp:2492 #8 0x7f973bc9c618 in HuginBase::Panorama::readData(std::istream&, std::__cxx11::basic_string, std::allocator >) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/Panorama.cpp:2178 #9 0x555e5c6e1975 in main /home/ubuntu/targets/hugin-2022.0.0_original/src/tools/pto_merge.cpp:99 #10 0x7f9739390082 in __libc_start_main ../csu/libc-start.c:308 #11 0x555e5c6e2c5d in _start (/home/ubuntu/targets/hugin-2022.0.0_original/build/src/tools/pto_merge+0xbc5d) 0x60309808 is located 0 bytes to the right of 24-byte region [0x603097f0,0x60309808) allocated by thread T0 here: #0 0x7f973c13a587 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cc:104 #1 0x7f973ac7c9a5 in __gnu_cxx::new_allocator::allocate(unsigned long, void const*) /usr/include/c++/9/ext/new_allocator.h:114 #2 0x7f973ac7c9a5 in std::allocator_traits >::allocate(std::allocator&, unsigned long) /usr/include/c++/9/bits/alloc_traits.h:443 #3 0x7f973ac7c9a5 in std::_Vector_base >::_M_allocate(unsigned long) /usr/include/c++/9/bits/stl_vector.h:343 #4 0x7f973ac7c9a5 in std::vector >::_M_default_append(unsigned long) /usr/include/c++/9/bits/vector.tcc:635 #5 0x7f973bcf1ab7 in std::vector >::resize(unsigned long) /usr/include/c++/9/bits/stl_vector.h:937 #6 0x7f973bcf1ab7 in HuginBase::PanoramaOptions::setProjection(HuginBase::PanoramaOptions::ProjectionFormat)
[Hugin-bug-hunters] [Bug 2025032] Re: Heap-buffer-overflow when adding an image in HuginBase::PanoramaMemento::loadPTScript
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2025032 Title: Heap-buffer-overflow when adding an image in HuginBase::PanoramaMemento::loadPTScript Status in Hugin: Fix Released Bug description: Hi there We want to share that the latest version (2022.0.0) of pto_merge causes heap-buffer-overflow. The invalid memory allocation may attribute to the excessive values in function parameters to the HuginBase::PanoramaMemento::loadPTScript. Here is the output of program with address sanitizer attached. ### Bug Report = ==3616==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60203800 at pc 0x7f3098044709 bp 0x7ffe486d8200 sp 0x7ffe486d81f0 READ of size 8 at 0x60203800 thread T0 #0 0x7f3098044708 in HuginBase::PanoramaMemento::loadPTScript(std::istream&, int&, std::__cxx11::basic_string, std::allocator > const&) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/image_variables.h:100 #1 0x7f3098052618 in HuginBase::Panorama::readData(std::istream&, std::__cxx11::basic_string, std::allocator >) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/Panorama.cpp:2178 #2 0x55cfccdd8975 in main /home/ubuntu/targets/hugin-2022.0.0_original/src/tools/pto_merge.cpp:99 #3 0x7f3095746082 in __libc_start_main ../csu/libc-start.c:308 #4 0x55cfccdd9c5d in _start (/home/ubuntu/targets/hugin-2022.0.0_original/build/src/tools/pto_merge+0xbc5d) 0x60203800 is located 0 bytes to the right of 16-byte region [0x602037f0,0x60203800) allocated by thread T0 here: #0 0x7f30984f0587 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cc:104 #1 0x7f309802e9a9 in __gnu_cxx::new_allocator::allocate(unsigned long, void const*) /usr/include/c++/9/ext/new_allocator.h:114 #2 0x7f309802e9a9 in std::allocator_traits >::allocate(std::allocator&, unsigned long) /usr/include/c++/9/bits/alloc_traits.h:443 #3 0x7f309802e9a9 in std::_Vector_base >::_M_allocate(unsigned long) /usr/include/c++/9/bits/stl_vector.h:343 #4 0x7f309802e9a9 in void std::vector >::_M_realloc_insert(__gnu_cxx::__normal_iterator > >, HuginBase::SrcPanoImage* const&) /usr/include/c++/9/bits/vector.tcc:440 #5 0x7f309802e9a9 in std::vector >::push_back(HuginBase::SrcPanoImage* const&) /usr/include/c++/9/bits/stl_vector.h:1195 #6 0x7f309802e9a9 in HuginBase::PanoramaMemento::loadPTScript(std::istream&, int&, std::__cxx11::basic_string, std::allocator > const&) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/Panorama.cpp:3130 #7 0x7f3098052618 in HuginBase::Panorama::readData(std::istream&, std::__cxx11::basic_string, std::allocator >) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/Panorama.cpp:2178 #8 0x55cfccdd8975 in main /home/ubuntu/targets/hugin-2022.0.0_original/src/tools/pto_merge.cpp:99 #9 0x7f3095746082 in __libc_start_main ../csu/libc-start.c:308 SUMMARY: AddressSanitizer: heap-buffer-overflow /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/image_variables.h:100 in HuginBase::PanoramaMemento::loadPTScript(std::istream&, int&, std::__cxx11::basic_string, std::allocator > const&) Shadow bytes around the buggy address: 0x0c047fff86b0: fa fa 00 00 fa fa 00 00 fa fa 04 fa fa fa 00 00 0x0c047fff86c0: fa fa 01 fa fa fa 04 fa fa fa 00 00 fa fa 00 fa 0x0c047fff86d0: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa 0x0c047fff86e0: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 04 fa 0x0c047fff86f0: fa fa 00 fa fa fa 00 fa fa fa 01 fa fa fa 00 00 =>0x0c047fff8700:[fa]fa fd fa fa fa 00 fa fa fa 04 fa fa fa 00 fa 0x0c047fff8710: fa fa 00 fa fa fa 04 fa fa fa 00 fa fa fa 00 fa 0x0c047fff8720: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa 0x0c047fff8730: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa 0x0c047fff8740: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 00 0x0c047fff8750: fa fa 00 00 fa fa 04 fa fa fa 00 00 fa fa 01 fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==3616==ABORTING ### Envionment OS: Ubuntu 20.04.5 LTS x86_64 Release: hugin 2022.0.0 Program: pto_merge
[Hugin-bug-hunters] [Bug 2002813] Re: align_image_stack hangs
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2002813 Title: align_image_stack hangs Status in Hugin: Fix Released Bug description: I have an application that uses align_image_stack, which works very well. Unfortunately it sometimes hangs up when aligning two images, I assume that's because they are too difficult to align. It states "Number of good matches: 0, bad matches: 40" many times, then that it has done "n iterations" up to 259. At that point it states "Run called" and then gets stuck. This would be alright if I was using it from a terminal, but it's embarrassing when it does it in my app - there's no easy way to detect the condition and stop it. It would be better to prevent it - is that possible? If not I think it's a bug. I can supply the two images. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2002813/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2000019] Re: Take into account digital zoom ratio EXIF tag in the computation of the HFOV
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/219 Title: Take into account digital zoom ratio EXIF tag in the computation of the HFOV Status in Hugin: Fix Released Bug description: The horizontal field of view (HFOV) property of a picture is critical to allow proper stitching. Inadequate values forbid automatic detection of control points, which is a central piece (and major added value) in Hugin's, and hence breaks the automated stitching workflow. Thankfully, Hugin automatically computes the HFOV value for pictures with valid EXIF data. Again, this is a great benefit which avoids manual computation for each lense and lengthy entry of manual data. In traditional cameras, the HFOV is mainly a function of the lense's focal length: adjusting the zoom between two shots with the same camera results in different focal lengths for each shot. This information is correctly read and interpreted into distinct HFOV by Hugin. In contrast, modern digital cameras, such as samsung cell phones to cite just one widely-spread example, typically feature fixed lenses with a unique focal length. Yet, it is still possible to take shots with different zoom factors (or, say, to be given pictures to stitch that were taken with such a device and with different zoom factors...). In this case, the focal length information is identical for all shots and the zoom information is encoded in a distinct EXIF tag, called the 'Digital Zoom Ratio'. Currently, it seems that Hugin doesn't take advantage of this tag, hence wrongly assuming that all pictures taken with the same 'digital camera' have an identical HFOV. This causes Hugin to be unable to stitch the pictures, because it typically fails to find control points. This might be relatively straightforward to fix given that: - The digital zoom ratio affects the HFOV in a simple manner, so it should be possible to compute the HFOV by taking into account both the lense's focal length and the digital zoom ratio (when available) - Hugin seems to rely on Exiv2 to acquire EXIF data from files, which supports the 'Digital Zoom Ratio' tag, so it should be possible to access this tag with the existing infrastructure. I checked that the command `exiv2 -pt image.jpg` on my images return the tag `Exif.Photo.DigitalZoomRatio` with the correct value. The same values are also read by Exiftool (checked with command `exiftool image.jpg`). I'm using Hugin 2021.0.0.52df0f76c700 (built with Exiv2 0.27.5) on Ubuntu 22.04.1. The version of Exiv2 that I used in the command line is also 0.27.5. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/219/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2025035] Re: Use-After-Free bug in HuginBase::ImageVariable::linkWith
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2025035 Title: Use-After-Free bug in HuginBase::ImageVariable::linkWith Status in Hugin: Fix Released Bug description: Hi there We want to share that the latest version (2022.0.0) of pto_merge causes heap-use-after-free. We assume that the function HuginBase::BaseSrcPanoImage::setFilename in the function HuginBase::PanoramaMemento::loadPTScript tries to access previously freed memory. Here is the output of program with address sanitizer attached. ### Bug Report = ==3836==ERROR: AddressSanitizer: heap-use-after-free on address 0x60601960 at pc 0x7fee211f5506 bp 0x7ffd73f55460 sp 0x7ffd73f55450 READ of size 8 at 0x60601960 thread T0 #0 0x7fee211f5505 in HuginBase::PanoramaMemento::loadPTScript(std::istream&, int&, std::__cxx11::basic_string, std::allocator > const&) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/image_variables.h:79 #1 0x7fee211fc618 in HuginBase::Panorama::readData(std::istream&, std::__cxx11::basic_string, std::allocator >) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/Panorama.cpp:2178 #2 0x560fdf074975 in main /home/ubuntu/targets/hugin-2022.0.0_original/src/tools/pto_merge.cpp:99 #3 0x7fee1e8f0082 in __libc_start_main ../csu/libc-start.c:308 #4 0x560fdf075c5d in _start (/home/ubuntu/targets/hugin-2022.0.0_original/build/src/tools/pto_merge+0xbc5d) 0x60601960 is located 32 bytes inside of 57-byte region [0x60601940,0x60601979) freed by thread T0 here: #0 0x7fee2169b51f in operator delete(void*) ../../../../src/libsanitizer/asan/asan_new_delete.cc:165 #1 0x7fee211c97aa in __gnu_cxx::new_allocator::deallocate(char*, unsigned long) /usr/include/c++/9/ext/new_allocator.h:128 #2 0x7fee211c97aa in std::allocator_traits >::deallocate(std::allocator&, char*, unsigned long) /usr/include/c++/9/bits/alloc_traits.h:469 #3 0x7fee211c97aa in std::__cxx11::basic_string, std::allocator >::_M_destroy(unsigned long) /usr/include/c++/9/bits/basic_string.h:241 #4 0x7fee211c97aa in std::__cxx11::basic_string, std::allocator >::_M_dispose() /usr/include/c++/9/bits/basic_string.h:236 #5 0x7fee211c97aa in std::__cxx11::basic_string, std::allocator >::~basic_string() /usr/include/c++/9/bits/basic_string.h:662 #6 0x7fee211c97aa in HuginBase::BaseSrcPanoImage::setFilename(std::__cxx11::basic_string, std::allocator >) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/image_variables.h:62 #7 0x7fee211c97aa in HuginBase::PanoramaMemento::loadPTScript(std::istream&, int&, std::__cxx11::basic_string, std::allocator > const&) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/Panorama.cpp:3133 #8 0x7fee211fc618 in HuginBase::Panorama::readData(std::istream&, std::__cxx11::basic_string, std::allocator >) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/Panorama.cpp:2178 #9 0x560fdf074975 in main /home/ubuntu/targets/hugin-2022.0.0_original/src/tools/pto_merge.cpp:99 #10 0x7fee1e8f0082 in __libc_start_main ../csu/libc-start.c:308 previously allocated by thread T0 here: #0 0x7fee2169a587 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cc:104 #1 0x560fdf07f9b8 in void std::__cxx11::basic_string, std::allocator >::_M_construct(char*, char*, std::forward_iterator_tag) /usr/include/c++/9/bits/basic_string.tcc:219 #2 0x7fee211c9736 in void std::__cxx11::basic_string, std::allocator >::_M_construct_aux(char*, char*, std::__false_type) /usr/include/c++/9/bits/basic_string.h:251 #3 0x7fee211c9736 in void std::__cxx11::basic_string, std::allocator >::_M_construct(char*, char*) /usr/include/c++/9/bits/basic_string.h:270 #4 0x7fee211c9736 in std::__cxx11::basic_string, std::allocator >::basic_string(std::__cxx11::basic_string, std::allocator > const&) /usr/include/c++/9/bits/basic_string.h:455 #5 0x7fee211c9736 in HuginBase::BaseSrcPanoImage::setFilename(std::__cxx11::basic_string, std::allocator >) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/image_variables.h:62 #6 0x7fee211c9736 in HuginBase::PanoramaMemento::loadPTScript(std::istream&, int&, std::__cxx11::basic_string, std::allocator > const&) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/Panorama.cpp:3133 #7 0x7fee211fc618 in HuginBase::Panorama::readData(std::istream&, std::__cxx11::basic_string, std::allocator >) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/Panorama.cpp:2178 #8 0x560fdf074975 in main
[Hugin-bug-hunters] [Bug 2002559] Re: build error with flann 1.9.2
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2002559 Title: build error with flann 1.9.2 Status in Hugin: Fix Released Bug description: Hello, this was originally reported in https://bugs.debian.org/1027934 hugin 2022.0.0 fails to build against flann 1.9.2 since it does not use FLANN_LIBRARY_DIRS as set by CMakeModules/FindFLANN.cmake ~~~ [ 50%] Linking CXX executable cpfind cd /dev/shm/HUGIN/hugin-2022.0.0/obj-x86_64-linux-gnu/src/hugin_cpfind/cpfind && /usr/bin/cmake -E cmake_link_script CMakeFiles/cpfind.dir/link.txt --verbose=1 /usr/lib/ccache/c++ -g -O2 -ffile-prefix-map=/dev/shm/HUGIN/hugin-2022.0.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -Wl,-z,defs -fopenmp CMakeFiles/cpfind.dir/PanoDetector.cpp.o CMakeFiles/cpfind.dir/PanoDetectorLogic.cpp.o CMakeFiles/cpfind.dir/TestCode.cpp.o CMakeFiles/cpfind.dir/Utils.cpp.o CMakeFiles/cpfind.dir/main.cpp.o -o cpfind -Wl,-rpath,/dev/shm/HUGIN/hugin-2022.0.0/obj-x86_64-linux-gnu/src/hugin_cpfind/localfeatures:/dev/shm/HUGIN/hugin-2022.0.0/obj-x86_64-linux-gnu/src/celeste:/dev/shm/HUGIN/hugin-2022.0.0/obj-x86_64-linux-gnu/src/hugin_base: ../localfeatures/liblocalfeatures.so.0.0 /usr/lib/x86_64-linux-gnu/libvigraimpex.so /usr/lib/x86_64-linux-gnu/libOpenEXR.so /usr/lib/x86_64-linux-gnu/libImath-3_1.so /usr/lib/x86_64-linux-gnu/libIex-3_1.so /usr/lib/x86_64-linux-gnu/libIlmThread-3_1.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libjpeg.so /usr/lib/x86_6 4-linux-gnu/libtiff.so /usr/lib/x86_64-linux-gnu/libpng.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libexiv2.so /usr/lib/x86_64-linux-gnu/libpano13.so ../../foreign/levmar/libhuginlevmar.a /usr/lib/x86_64-linux-gnu/libGLEW.so /usr/lib/x86_64-linux-gnu/libfftw3.so /usr/lib/x86_64-linux-gnu/libvigraimpex.so /usr/lib/x86_64-linux-gnu/libOpenEXR.so /usr/lib/x86_64-linux-gnu/libImath-3_1.so /usr/lib/x86_64-linux-gnu/libIex-3_1.so /usr/lib/x86_64-linux-gnu/libIlmThread-3_1.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libjpeg.so /usr/lib/x86_64-linux-gnu/libtiff.so /usr/lib/x86_64-linux-gnu/libpng.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libexiv2.so /usr/lib/x86_64-linux-gnu/liblcms2.so ../../celeste/libceleste.so.0.0 -lflann -lflann_cpp -lhdf5 -lmpi -llz4 ../../hugin_base/libhuginbase.so.0.0 /usr/lib/x86_64-linux-gnu/libX11.so /usr/lib/x86_64-linux-gnu/libOpenGL.s o /usr/lib/x86_64-linux-gnu/libGLX.so /usr/lib/x86_64-linux-gnu/libGLU.so /usr/lib/x86_64-linux-gnu/libsqlite3.so /usr/lib/x86_64-linux-gnu/libpano13.so ../../foreign/levmar/libhuginlevmar.a /usr/lib/x86_64-linux-gnu/libGLEW.so /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.74.0 /usr/lib/x86_64-linux-gnu/libboost_system.so.1.74.0 /usr/lib/x86_64-linux-gnu/libfftw3.so /usr/lib/x86_64-linux-gnu/libvigraimpex.so /usr/lib/x86_64-linux-gnu/libOpenEXR.so /usr/lib/x86_64-linux-gnu/libImath-3_1.so /usr/lib/x86_64-linux-gnu/libIex-3_1.so /usr/lib/x86_64-linux-gnu/libIlmThread-3_1.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libjpeg.so /usr/lib/x86_64-linux-gnu/libpng.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libjpeg.so /usr/lib/x86_64-linux-gnu/libpng.so /usr/lib/x86_64-linux-gnu/libtiff.so /usr/lib/x86_64-linux-gnu/libexiv2.so /usr/lib/x86_64-linux-gnu/liblcms2.so /usr/bin/ld: cannot find -lhdf5: No such file or directory collect2: error: ld returned 1 exit status ~~~ Find attached the patch used in the Debian package patch to fix this. cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2002559/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2028087] Re: Creating Mask crash fix
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2028087 Title: Creating Mask crash fix Status in Hugin: Fix Released Bug description: (using a my build of hugin-2022.0.0 on MacOS v10.12.6) When creating a mask for exclude region, hugin would sometimes crash. This attach patch fixes this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2028087/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2007178] Re: Replace GLEW with epoxy
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2007178 Title: Replace GLEW with epoxy Status in Hugin: Fix Released Bug description: GLEW is installed for either GLX or EGL, making it impossible to switch to EGL if some applications need GLX. epoxy also does not need to be initialised, making startup faster. GTK, Firefox and Libreoffice are among those using epoxy. Patch (not sure the best way to work with Launchpad and/or Sourceforge...): https://sourceforge.net/p/hugin/hugin/merge-requests/2/ A draft that has only been tested on Linux and at the moment uses PKG_SEARCH_MODULE to find epoxy. So, may work on macOS (libepoxy is available in Homebrew) but more work for Windows and other supporting scripts. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2007178/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2012946] Re: Masks-Crop Window Displays Itself Fully In Child Window
** Changed in: hugin
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Hugin Bug
Hunters, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/2012946
Title:
Masks-Crop Window Displays Itself Fully In Child Window
Status in Hugin:
Fix Released
Bug description:
In a new session, I import 6 files and click the "Masks" tab and then
select the first file in my list. I then select the "Crop" button
below the file listing and the entire parent window starting with the
"#|Filename |Number of masks|..." where I am clicking the "Crop"
button displays in the the pane where the photo with the crop lines
should show. This makes it impossible to properly place the crop
marks. Notice in the screenshot accompanying this report that the
child window of the image appears, but with its parent and the crop
marks are placed over the unwanted parent portion.
This occurs in Gentoo Linux. Here is my installation information:
eos /etc/portage/package.use # date; eix -I hugin
Mon Mar 27 08:05:54 PDT 2023
[I] media-gfx/hugin
Available versions: 2022.0.0 ***l {debug lapack python raw sift
L10N="ca ca-valencia cs da de en-GB es eu fi fr hu it ja nl pl pt-BR ro ru sk
sv zh-CN zh-TW" PYTHON_SINGLE_TARGET="python3_9 python3_10 python3_11"}
Installed versions: 2022.0.0(10:15:02 03/18/23)(raw sift -debug -lapack
-python L10N="-ca -ca-valencia -cs -da -de -en-GB -es -eu -fi -fr -hu -it -ja
-nl -pl -pt-BR -ro -ru -sk -sv -zh-CN -zh-TW" PYTHON_SINGLE_TARGET="python3_10
-python3_9 -python3_11")
Homepage:http://hugin.sf.net
Description: GUI for the creation & processing of panoramic
images
eos /etc/portage/package.use #
From the About-System window:
Operating System: Linux 5.15.85-gentoo-dist x86_64
Architecture: 64 bit
Free memory: 8556908 kiB
Hugin
Version: 2022.0.0.a0962865f932
Path to resources: /usr/share/hugin/xrc/
Path to data: /usr/share/hugin/data/
Hugins camera and lens database: /home/jlpoole/.hugindata/camlens.db
Multi-threading using C++11 std::thread and OpenMP
Libraries
wxWidgets: wxWidgets 3.0.5
wxWidgets Library (wxGTK port)
Version 3.0.5 (Unicode: wchar_t, debug level: 1),
compiled at Mar 16 2023 07:58:05
Runtime version of toolkit used is 3.24.
Compile-time GTK+ version is 3.24.35.
libpano13: 2.9.21
Boost: 1.81.0
Exiv2: 0.27.6
SQLite3: 3.40.1
Vigra: 1.11.1
LittleCMS2: 2.14
What should happen is that the image displays in the child pane and
the crop outline appears and can be manipulated.
I have Hugin installed on WIndows 7 and have not experienced this
problem. What can I provide or do to give further insight into what
is happening here. I could rebuild the project with debug flags. Also
I noticed this build uses Python 3_10. The Gentoo ebuild file has the
following specifications:
eos /etc/portage/package.use # date; cat
/var/db/repos/gentoo/media-gfx/hugin/hugin-2022.0.0.ebuild
Mon Mar 27 08:17:21 PDT 2023
# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
EAPI=7
WX_GTK_VER="3.0-gtk3"
PYTHON_COMPAT=( python3_{9..11} )
inherit python-single-r1 wxwidgets cmake xdg
DESCRIPTION="GUI for the creation & processing of panoramic images"
HOMEPAGE="http://hugin.sf.net;
SRC_URI="mirror://sourceforge/${PN}/${P/_/}.tar.bz2"
LICENSE="GPL-2+ BSD BSD-2 MIT wxWinLL-3 ZLIB FDL-1.2"
SLOT="0"
KEYWORDS="amd64 arm64 x86"
LANGS=" ca ca-valencia cs da de en-GB es eu fi fr hu it ja nl pl pt-BR
ro ru sk sv zh-CN zh-TW"
IUSE="debug lapack python raw sift $(echo ${LANGS//\ /\ l10n_})"
CDEPEND="
dev-db/sqlite:3
dev-libs/boost:=
dev-libs/zthread
>=media-gfx/enblend-4.0
media-gfx/exiv2:=
media-libs/freeglut
media-libs/glew:=
media-libs/libjpeg-turbo:=
>=media-libs/libpano13-2.9.19_beta1:=
media-libs/libpng:=
media-libs/openexr:=
media-libs/tiff:=
>=media-libs/vigra-1.11.1-r5[openexr]
sci-libs/fftw:3.0=
sci-libs/flann
sys-libs/zlib
virtual/glu
virtual/opengl
x11-libs/wxGTK:${WX_GTK_VER}=[X,opengl]
lapack? ( virtual/blas virtual/lapack )
python? ( ${PYTHON_DEPS} )
sift? ( media-gfx/autopano-sift-C )"
RDEPEND="${CDEPEND}
media-libs/exiftool
raw? ( media-gfx/dcraw )"
DEPEND="${CDEPEND}
[Hugin-bug-hunters] [Bug 2025036] Re: NULL pointer defererence error in HuginBase::ImageVariable::linkWith
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2025036 Title: NULL pointer defererence error in HuginBase::ImageVariable::linkWith Status in Hugin: Fix Released Bug description: Hi there We just want to share that the latest version (2022.0.0) of pto_merge causes null pointer error. Here is the output of program with address sanitizer attached. ### Bug Report AddressSanitizer:DEADLYSIGNAL = ==3844==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x7f1d38983b07 bp 0x7fff493bd1f0 sp 0x7fff493b6920 T0) ==3844==The signal is caused by a READ memory access. ==3844==Hint: address points to the zero page. #0 0x7f1d38983b06 in bool std::operator== >, std::vector > >(std::shared_ptr > > const&, std::shared_ptr > > const&) /usr/include/c++/9/bits/shared_ptr.h:384 #1 0x7f1d38983b06 in HuginBase::ImageVariable > >::linkWith(HuginBase::ImageVariable > >*) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/ImageVariable.h:184 #2 0x7f1d38983b06 in HuginBase::BaseSrcPanoImage::linkRadialDistortion(HuginBase::BaseSrcPanoImage*) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/image_variables.h:93 #3 0x7f1d38983b06 in HuginBase::PanoramaMemento::loadPTScript(std::istream&, int&, std::__cxx11::basic_string, std::allocator > const&) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/image_variables.h:93 #4 0x7f1d389a6618 in HuginBase::Panorama::readData(std::istream&, std::__cxx11::basic_string, std::allocator >) /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/Panorama.cpp:2178 #5 0x56488e0f5975 in main /home/ubuntu/targets/hugin-2022.0.0_original/src/tools/pto_merge.cpp:99 #6 0x7f1d3609a082 in __libc_start_main ../csu/libc-start.c:308 #7 0x56488e0f6c5d in _start (/home/ubuntu/targets/hugin-2022.0.0_original/build/src/tools/pto_merge+0xbc5d) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /usr/include/c++/9/bits/shared_ptr.h:384 in bool std::operator== >, std::vector > >(std::shared_ptr > > const&, std::shared_ptr > > const&) ==3844==ABORTING ### Envionment OS: Ubuntu 20.04.5 LTS x86_64 Release: hugin 2022.0.0 Program: pto_merge libhuginbase: 2020.0.0 (retrieved and compiled from source code) libpano13: 2.9.19 To reproduce the problem, we need to build hugin: sudo cmake -DCMAKE_C_FLAGS="-g" -DCMAKE_CXX_FLAGS="-g" .. ### How to reproduce $ pto_merge poc-file *.jpg (*.jpg any name of jpg file including asterisk(*)) poc-file is attached. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2025036/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2025038] Re: Improper handling of values in HuginBase::PTools::Transform::transform causes assertion error in libpano13
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2025038 Title: Improper handling of values in HuginBase::PTools::Transform::transform causes assertion error in libpano13 Status in Hugin: Fix Released Bug description: Hi there We just want to share that the latest version (2022.0.0) of pto_merge causes reaching assertion error, which is improper to the normal execution. The stack execution from the function HuginBase::PTools::Transform::transform() checks NaN through the function erect_lambertazimuthal(), but it causes assertion has failed saying ‘pto_merge: math.c:846: erect_lambertazimuthal: Assertion `! isnan(x)' failed.' Here is the output of gdb results. ### Bug Report (gdb) r Starting program: /home/ubuntu/targets/hugin-2022.0.0_original/build/src/tools/pto_merge ../AFLplusplus/hugin_ptomerge_jpg/default/crashes/id:000242,sig:06,src:001403,time:28753634,execs:1225769,op:havoc,rep:2 1.jpg [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". pto_merge: math.c:846: erect_lambertazimuthal: Assertion `! isnan(x)' failed. Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x748e9859 in __GI_abort () at abort.c:79 #2 0x748e9729 in __assert_fail_base ( fmt=0x74a7f588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x75d93d92 "! isnan(x)", file=0x75d93d8b "math.c", line=846, function=) at assert.c:92 #3 0x748fafd6 in __GI___assert_fail (assertion=0x75d93d92 "! isnan(x)", file=0x75d93d8b "math.c", line=846, function=0x75d93e60 "erect_lambertazimuthal") at assert.c:101 #4 0x75d5ce68 in erect_lambertazimuthal () from /lib/x86_64-linux-gnu/libpano13.so.3 #5 0x75d5b8d3 in execute_stack_new () from /lib/x86_64-linux-gnu/libpano13.so.3 #6 0x7733a368 in **HuginBase::PTools::Transform::transform** (this=this@entry=0x7fff3fc0, dest=..., src=...) at /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panotools/PanoToolsInterface.cpp:250 #7 0x7724a33f in HuginBase::PanoramaOptions::getVFOV (this=) at /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/hugin_math/hugin_math.h:87 #8 0x7724c31e in HuginBase::PanoramaOptions::setProjectionParameters (this=0x7fffc530, params=std::vector of length 0, capacity 0) at /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/PanoramaOptions.cpp:190 #9 0x7724c859 in HuginBase::PanoramaOptions::resetProjectionParameters (this=) at /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/PanoramaOptions.cpp:200 #10 0x771cd2ba in HuginBase::PanoramaMemento::loadPTScript (this=, i=..., ptoVersion=, prefix=...) at /home/ubuntu/targets/hugin-2022.0.0_original/src/hugin_base/panodata/Panorama.cpp:2492 #11 0x771f7619 in HuginBase::Panorama::readData (this=, dataInput=..., documentType=...) at /usr/include/c++/9/bits/basic_string.h:267 #12 0xe976 in main (argc=, argv=0x7fffe4c8) at /usr/include/c++/9/ext/new_allocator.h:80 ### Envionment OS: Ubuntu 20.04.5 LTS x86_64 Release: hugin 2022.0.0 Program: pto_merge libhuginbase: 2020.0.0 (retrieved and compiled from source code) libpano13: 2.9.19 To reproduce the problem, we need to build hugin: sudo cmake -DCMAKE_C_FLAGS="-g" -DCMAKE_CXX_FLAGS="-g" .. ### How to reproduce $ pto_merge poc-file *.jpg (*.jpg any name of jpg file including asterisk(*)) poc-file is attached. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2025038/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2025577] Re: Hugin fails to compile with exiv2 v0.28.0 and newer
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2025577 Title: Hugin fails to compile with exiv2 v0.28.0 and newer Status in Hugin: Fix Released Bug description: Building Hugin with exiv2 v0.28.0 and newer fails due to this change in exiv2: https://github.com/Exiv2/exiv2/commit/256365830a5ce7a917d48acca8ba0b58569f4510 This is the error when compiling: hugin/src/hugin_base/panodata/SrcPanoImage.cpp: In member function ‘bool HuginBase::SrcPanoImage::readEXIF()’: hugin/src/hugin_base/panodata/SrcPanoImage.cpp:387:45: error: ‘class Exiv2::Xmpdatum’ has no member named ‘toLong’ 387 | croppedWidth = pos->toLong(); | ^~ hugin/src/hugin_base/panodata/SrcPanoImage.cpp:397:46: error: ‘class Exiv2::Xmpdatum’ has no member named ‘toLong’ 397 | croppedHeight = pos->toLong(); | ^~ hugin/src/hugin_base/panodata/SrcPanoImage.cpp:411:70: error: ‘class Exiv2::Xmpdatum’ has no member named ‘toLong’ 411 | hfov = 360 * croppedWidth / (double)pos->toLong(); | ^~ hugin/src/hugin_base/panodata/SrcPanoImage.cpp:422:47: error: ‘class Exiv2::Xmpdatum’ has no member named ‘toLong’ 422 | fullHeight = pos->toLong(); | ^~ hugin/src/hugin_base/panodata/SrcPanoImage.cpp:433:44: error: ‘class Exiv2::Xmpdatum’ has no member named ‘toLong’ 433 | cropTop = pos->toLong(); |^~ make[2]: *** [src/hugin_base/CMakeFiles/huginbase.dir/build.make:720: src/hugin_base/CMakeFiles/huginbase.dir/panodata/SrcPanoImage.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:754: src/hugin_base/CMakeFiles/huginbase.dir/all] Error 2 make: *** [Makefile:156: all] Error 2 This was the changeset I was trying to compile: changeset: 8617:729748be1738 tag: tip user:tmodes date:Sat Jul 01 10:34:45 2023 +0200 summary: Refactored writing pto file To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2025577/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2033187] Re: failed assertion while removing control points in rectangle
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2033187 Title: failed assertion while removing control points in rectangle Status in Hugin: Fix Released Bug description: Operating System: Linux 6.1.0-11-amd64 x86_64 Architecture: 64 bit Free memory: 430260 kiB Hugin Version: 2022.0.0.a0962865f932 Path to resources: /usr/share/hugin/xrc/ Path to data: /usr/share/hugin/data/ Hugins camera and lens database: /home/anttil/.local/share/hugin/camlens.db Multi-threading using C++11 std::thread and OpenMP Libraries wxWidgets: wxWidgets 3.2.2 wxWidgets Library (wxGTK port) Version 3.2.2 (Unicode: wchar_t, debug level: 1), Runtime version of toolkit used is 3.24. Compile-time GTK+ version is 3.24.36. libpano13: 2.9.21 Boost: 1.74.0 Exiv2: 0.27.6 SQLite3: 3.40.1 Vigra: 1.11.1 LittleCMS2: 2.14 When removing control points in selected rectangle in the Control Points tab there is a pop-up about "an assertion failed." Unchecking "Show this dialog next time" it is possible to continue without problems, otherwise the pop-up appears when removing control points the next time. It appears to happen every time regardless of project file. The problem did not happen in the previous versions of Hugin. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2033187/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 847433] Re: 'Create panorama' is disabled in single photo projects
This use case is already covered by the existing checks. Should now be fixed in repository. ** Changed in: hugin Status: New => Fix Committed ** Changed in: hugin Milestone: 2017.0beta1 => 2023.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/847433 Title: 'Create panorama' is disabled in single photo projects Status in Hugin: Fix Committed Bug description: When starting a project, both 2. Align... and 3. Create panorama are greyed out which makes sense. However if I load a single photo into Hugin, they are still greyed. This is a problem as a common use of Hugin for me is to load a single image and remap it to a different projection. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/847433/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2032806] Re: Color glitches in dark areas
I have seen now: the pto file is using normal panorama output, but the image shows the output of blended_fused. So the artefacts are created from enfuse. This is a known issue, there are already several threads and bug reports about it. -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2032806 Title: Color glitches in dark areas Status in Hugin: Opinion Bug description: Hello, I use regurarly Hugin to stitch panoramas. I have a problem with one of them : there are color glitches in some dark areas, that are not there in the original files. See attached files. Using v. 2022.0.0.a0962865f932 on Debian 12 To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2032806/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 847433] Re: 'Create panorama' is disabled in single photo projects
There are some special checks for the activation of the create pano button if the project contains only one image. But these are ignored directly after loading the image. This can be easily changed. But what checks would be sensible for single image projects? Currently it enables create button when * output projection != equirectangular * crop set But this may not be so useful when using an user defined output. I thought of adding * image projection === euquirectangular Do you have other ideas what checks to do? -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/847433 Title: 'Create panorama' is disabled in single photo projects Status in Hugin: New Bug description: When starting a project, both 2. Align... and 3. Create panorama are greyed out which makes sense. However if I load a single photo into Hugin, they are still greyed. This is a problem as a common use of Hugin for me is to load a single image and remap it to a different projection. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/847433/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2032806] Re: Color glitches in dark areas
I said reset response curve (Ra/Rb/Rc/Rd/Re=0 or use reset in context menu) and not set response curve to linear. If it still is visible reset all photometric parameters (vignetting, color balance, exposure, response curve). -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2032806 Title: Color glitches in dark areas Status in Hugin: Opinion Bug description: Hello, I use regurarly Hugin to stitch panoramas. I have a problem with one of them : there are color glitches in some dark areas, that are not there in the original files. See attached files. Using v. 2022.0.0.a0962865f932 on Debian 12 To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2032806/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2032806] Re: Color glitches in dark areas
Reset the response curve. It looks a little bit strange. Such wrong values for the response curve can happen when the brightness values of the images are not spread over the whole brightness range. ** Changed in: hugin Status: New => Opinion -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2032806 Title: Color glitches in dark areas Status in Hugin: Opinion Bug description: Hello, I use regurarly Hugin to stitch panoramas. I have a problem with one of them : there are color glitches in some dark areas, that are not there in the original files. See attached files. Using v. 2022.0.0.a0962865f932 on Debian 12 To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2032806/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2033187] Re: failed assertion while removing control points in rectangle
This is probably already fixed in default branch (changeset 69ef10dab84d). Please test default branch and reopen tickets if it still happens with default branch with mentioned changeset. ** Changed in: hugin Status: New => Fix Committed ** Changed in: hugin Milestone: None => 2023.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2033187 Title: failed assertion while removing control points in rectangle Status in Hugin: Fix Committed Bug description: Operating System: Linux 6.1.0-11-amd64 x86_64 Architecture: 64 bit Free memory: 430260 kiB Hugin Version: 2022.0.0.a0962865f932 Path to resources: /usr/share/hugin/xrc/ Path to data: /usr/share/hugin/data/ Hugins camera and lens database: /home/anttil/.local/share/hugin/camlens.db Multi-threading using C++11 std::thread and OpenMP Libraries wxWidgets: wxWidgets 3.2.2 wxWidgets Library (wxGTK port) Version 3.2.2 (Unicode: wchar_t, debug level: 1), Runtime version of toolkit used is 3.24. Compile-time GTK+ version is 3.24.36. libpano13: 2.9.21 Boost: 1.74.0 Exiv2: 0.27.6 SQLite3: 3.40.1 Vigra: 1.11.1 LittleCMS2: 2.14 When removing control points in selected rectangle in the Control Points tab there is a pop-up about "an assertion failed." Unchecking "Show this dialog next time" it is possible to continue without problems, otherwise the pop-up appears when removing control points the next time. It appears to happen every time regardless of project file. The problem did not happen in the previous versions of Hugin. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2033187/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2028087] Re: Creating Mask crash fix
Ok, committed to repository with a comment about it. ** Changed in: hugin Status: Incomplete => Fix Committed ** Changed in: hugin Milestone: None => 2023.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2028087 Title: Creating Mask crash fix Status in Hugin: Fix Committed Bug description: (using a my build of hugin-2022.0.0 on MacOS v10.12.6) When creating a mask for exclude region, hugin would sometimes crash. This attach patch fixes this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2028087/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2028087] Re: Creating Mask crash fix
Adding twice a comment with your initials and a date is not helpful. This can be tracked with mercurial. More helpful would be a comment with a description why the separate code block is necessary. And why does it only happens with exclude region? Should be the same happen also with include region? ** Changed in: hugin Status: New => Incomplete -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2028087 Title: Creating Mask crash fix Status in Hugin: Incomplete Bug description: (using a my build of hugin-2022.0.0 on MacOS v10.12.6) When creating a mask for exclude region, hugin would sometimes crash. This attach patch fixes this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2028087/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2028086] Re: MacOS build patches
Please regenerate the patch against current head of default branch. It contains already some the your changes. Second, please check the patch again. (e.g. CC="/opt/local//bin/clang" has a double slash instead of a single one) And third and the main issue: please consolidate your efforts for the Mac builds with other builders. I opened a thread in the mailing list https://groups.google.com/g/hugin-ptx/c/ssEQpNf7-Co ** Changed in: hugin Status: New => Incomplete -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2028086 Title: MacOS build patches Status in Hugin: Incomplete Bug description: Attached below are the build file patches that I used to compile version hugin-2022.0.0 to create a MacOS dmg that runs on MacOS v.10.12.6 thru Monterey (I think?). One thing to note is that if you have libjpeg-turbo installed, it will be pickup first and your build will fault with an exception in anything that uses jpeg routines. It boils down to a versioning issue in the libjpeg-turbo header (it reports version 8) and the jpeg routines in this build process (needs something other than reporting version 8). So rename the libjpeg-turbo headers and it will be fine. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2028086/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2025577] Re: Hugin fails to compile with exiv2 v0.28.0 and newer
Should be fixed in repository. It would be nice if such incompatible / code breaking changes would be announced in the changelog or readme. (Hiding in a long list of all changesets is not user friendly.) Even better would be if they could work around such issues and maintain a stable interface especially when it is an external library which is used by several other programs. ** Changed in: hugin Status: New => Fix Committed ** Changed in: hugin Milestone: None => 2023.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2025577 Title: Hugin fails to compile with exiv2 v0.28.0 and newer Status in Hugin: Fix Committed Bug description: Building Hugin with exiv2 v0.28.0 and newer fails due to this change in exiv2: https://github.com/Exiv2/exiv2/commit/256365830a5ce7a917d48acca8ba0b58569f4510 This is the error when compiling: hugin/src/hugin_base/panodata/SrcPanoImage.cpp: In member function ‘bool HuginBase::SrcPanoImage::readEXIF()’: hugin/src/hugin_base/panodata/SrcPanoImage.cpp:387:45: error: ‘class Exiv2::Xmpdatum’ has no member named ‘toLong’ 387 | croppedWidth = pos->toLong(); | ^~ hugin/src/hugin_base/panodata/SrcPanoImage.cpp:397:46: error: ‘class Exiv2::Xmpdatum’ has no member named ‘toLong’ 397 | croppedHeight = pos->toLong(); | ^~ hugin/src/hugin_base/panodata/SrcPanoImage.cpp:411:70: error: ‘class Exiv2::Xmpdatum’ has no member named ‘toLong’ 411 | hfov = 360 * croppedWidth / (double)pos->toLong(); | ^~ hugin/src/hugin_base/panodata/SrcPanoImage.cpp:422:47: error: ‘class Exiv2::Xmpdatum’ has no member named ‘toLong’ 422 | fullHeight = pos->toLong(); | ^~ hugin/src/hugin_base/panodata/SrcPanoImage.cpp:433:44: error: ‘class Exiv2::Xmpdatum’ has no member named ‘toLong’ 433 | cropTop = pos->toLong(); |^~ make[2]: *** [src/hugin_base/CMakeFiles/huginbase.dir/build.make:720: src/hugin_base/CMakeFiles/huginbase.dir/panodata/SrcPanoImage.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:754: src/hugin_base/CMakeFiles/huginbase.dir/all] Error 2 make: *** [Makefile:156: all] Error 2 This was the changeset I was trying to compile: changeset: 8617:729748be1738 tag: tip user:tmodes date:Sat Jul 01 10:34:45 2023 +0200 summary: Refactored writing pto file To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2025577/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2024280] Re: left magnifier in cp editor window shows mirrored image
If you can't reproduce it, it is not necessary to upload anything. If it happens again, you can upload the pto file first. I will see if this is sufficient to reproduce the issue. The pto file can be attached to the ticket. For bigger files an external file hoster/cloud service would be preferred. ** Changed in: hugin Status: Incomplete => Opinion -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2024280 Title: left magnifier in cp editor window shows mirrored image Status in Hugin: Opinion Bug description: I tried different magnifier sizes but it seems that the magnifier of (only) the left image in the cp editor tab shows a mirrored view of the actual image which is a bit distracting. I can supply a screenshot if that helps. Thank you all (especially Thomas Modes who is putting so much effort also in correcting those little glitches) for making hugin available and still improving features! BTW I am now running hugin on my trusty "cheesegrater" Intel tower Mac that happily runs Xubuntu. Betriebssystem: Linux 5.15.0-75-generic x86_64 Architektur: 64 bit Freier Speicher: 22099748 kiB Hugin Version: 2022.0.0.a0962865f932 Ressourcen-Pfad: /usr/share/hugin/xrc/ Datenpfad: /usr/share/hugin/data/ Hugins Kamera- und Objektivdatenbank: /home/<...>/.hugindata/camlens.db Multi-Threading mittels C++11 std::thread und OpenMP Bibliotheken wxWidgets: wxWidgets 3.0.5 wxWidgets Library (wxGTK port) Version 3.0.5 (Unicode: wchar_t, debug level: 1), Runtime version of toolkit used is 3.24. Compile-time GTK+ version is 3.24.33. libpano13: 2.9.20 Boost: 1.74.0 Exiv2: 0.27.5 SQLite3: 3.37.2 Vigra: 1.11.1 LittleCMS2: 2.12 To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2024280/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2024280] Re: left magnifier in cp editor window shows mirrored image
I can't reproduce the issue here. The image is correctly drawn. Can you provide a small pto file with 2 images which shows the issue? One more question: Is autorotate images activated or deactivated in preferences? ** Changed in: hugin Status: New => Incomplete -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2024280 Title: left magnifier in cp editor window shows mirrored image Status in Hugin: Incomplete Bug description: I tried different magnifier sizes but it seems that the magnifier of (only) the left image in the cp editor tab shows a mirrored view of the actual image which is a bit distracting. I can supply a screenshot if that helps. Thank you all (especially Thomas Modes who is putting so much effort also in correcting those little glitches) for making hugin available and still improving features! BTW I am now running hugin on my trusty "cheesegrater" Intel tower Mac that happily runs Xubuntu. Betriebssystem: Linux 5.15.0-75-generic x86_64 Architektur: 64 bit Freier Speicher: 22099748 kiB Hugin Version: 2022.0.0.a0962865f932 Ressourcen-Pfad: /usr/share/hugin/xrc/ Datenpfad: /usr/share/hugin/data/ Hugins Kamera- und Objektivdatenbank: /home/<...>/.hugindata/camlens.db Multi-Threading mittels C++11 std::thread und OpenMP Bibliotheken wxWidgets: wxWidgets 3.0.5 wxWidgets Library (wxGTK port) Version 3.0.5 (Unicode: wchar_t, debug level: 1), Runtime version of toolkit used is 3.24. Compile-time GTK+ version is 3.24.33. libpano13: 2.9.20 Boost: 1.74.0 Exiv2: 0.27.5 SQLite3: 3.37.2 Vigra: 1.11.1 LittleCMS2: 2.12 To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2024280/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2018003] Re: UI hangs while About window is open.
I don't see the point of have a non-modal about dialog. The about dialog is showing only information about the program. Nothing that needs to be changed or even read when processing a panorama. ** Changed in: hugin Status: New => Opinion -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2018003 Title: UI hangs while About window is open. Status in Hugin: Opinion Bug description: The panorama preview window stops responding to input when the About window is opened from the main program window. I feel that the About window is unnecessarily modal. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2018003/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2018002] Re: "Could not process of output of reference image" when importing raw images with dcraw
This is not reproducible here. I downloaded sample raw images from the mentioned camera and these are imported correctly with dcraw. Have you added additional parameters to dcraw? Can you provide a sample image? ** Changed in: hugin Status: New => Incomplete -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2018002 Title: "Could not process of output of reference image" when importing raw images with dcraw Status in Hugin: Incomplete Bug description: Aside from the ungrammaticalness of the error message, it results in the selected reference image having different colour balance to the other images in the series. I assume this is because hugin is attempting (and failing) to parse dcraw output. Here is such an example of output: Loading Olympus E-M5MarkII image from /mnt/photos/2023/20230420/p4205264.orf ... Scaling with darkness 253, saturation 4095, and multipliers 1.00 0.492308 0.903846 0.492308 AHD interpolation... Rebuilding highlights... Converting to sRGB colorspace... Writing data to /mnt/photos/2023/20230420/p4205264.tiff ... System info: Operating System: Linux 6.1.0-7-amd64 x86_64 Architecture: 64 bit Free memory: 892712 kiB Hugin Version: 2022.0.0.a0962865f932 Path to resources: /usr/share/hugin/xrc/ Path to data: /usr/share/hugin/data/ Hugins camera and lens database: /home/michael/.local/share/hugin/camlens.db Multi-threading using C++11 std::thread and OpenMP Libraries wxWidgets: wxWidgets 3.2.2 wxWidgets Library (wxGTK port) Version 3.2.2 (Unicode: wchar_t, debug level: 1), Runtime version of toolkit used is 3.24. Compile-time GTK+ version is 3.24.36. libpano13: 2.9.20 Boost: 1.74.0 Exiv2: 0.27.6 SQLite3: 3.40.1 Vigra: 1.11.1 LittleCMS2: 2.14 To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2018002/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 679939] Re: add quick crop
- A reset crop button (removing all cropping is currently quite fiddly). - Some preset grid overlays for composition (rule of thirds, corner diagonals, golden ratio etc...). These were already implemented in 2011 - Shift-drag at the centre would move only horizontally or vertically similar to the Drag mode. - Shift-drag on corners or edges would resize symmetrically about the centre. - Ctrl-drag would preserve aspect ratio. - An 'outside' autocrop in addition to the existing 'inside' autocrop. - A series of preset aspect ratios (1:1, 2:1, 3:2, 4:3, 16:9, 1.618:1, etc...). These are implemented in default branch. (If further aspect ratios are needed, they can be easily added.) ** Changed in: hugin Status: Triaged => Fix Committed ** Changed in: hugin Milestone: None => 2023.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/679939 Title: add quick crop Status in Hugin: Fix Committed Bug description: in the crop tool of the fast preview add this functionality: doubleclick (left) sets the left (/upper/right/lower) crop side to the leftmost "black" pixel, ie everything left from this line has at least one colored pixel. a right doubleclick sets it such that there is at least one colored pixel to the right and none to the left. as double right click does not really exist, a shift left click could be implemented as this as well... To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/679939/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2016362] Re: Feature request: Add "Fit crop around images" button
*** This bug is a duplicate of bug 679939 *** https://bugs.launchpad.net/bugs/679939 > This was done for speed (see below). As I understand it, for > non-masked/non-cropped images _some_ point on the source image's edge will be > at its largest/smallest projected X/Y position in the final panorama; is this > not the case? Only for this special case. But not in the general case with fisheye lenses or cropping or masking. >Aren't their edges always outside their interiors once projected? No. The projection formula is only well-defined in the crop area. Outside of the crop it can remap points *far* away from the cropped edge. It can even be the case that the remapping operation is not (mathematically) defined (transformImgCoord returning false). So the calculation of the crop is wrong. This is not addressed in the new patch. I committed some changes to the repository which should implement an outside crop. -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2016362 Title: Feature request: Add "Fit crop around images" button Status in Hugin: New Bug description: It would be useful to have a button that sets the crop so that all of the pixels in the source images are in the final image (i.e. set the bounding box to surround all of the source images). This is similar (kind of opposite) in behavior to the "Stitcher→Fit Crop to Images" button that sets the crop so that there are no non- image pixels in final image. This is useful for when you want to be able to see all of the source images in the final image and don't care if it looks pretty. The specific use-case that I have is documenting locations for cartography. I want to be able to see all of a location and currently I have to manually set the crop for each panorama. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2016362/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2016362] Re: Feature request: Add "Fit crop around images" button
*** This bug is a duplicate of bug 679939 *** https://bugs.launchpad.net/bugs/679939 Testing only the first/last row/column of each image is not enough. It will fail e.g. for fisheye images and images with crop or masks. Also please use only whitespace for indentation. The patch contains mixed tab and white space indentation. It needs also more clean up from copying from existing code. -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2016362 Title: Feature request: Add "Fit crop around images" button Status in Hugin: New Bug description: It would be useful to have a button that sets the crop so that all of the pixels in the source images are in the final image (i.e. set the bounding box to surround all of the source images). This is similar (kind of opposite) in behavior to the "Stitcher→Fit Crop to Images" button that sets the crop so that there are no non- image pixels in final image. This is useful for when you want to be able to see all of the source images in the final image and don't care if it looks pretty. The specific use-case that I have is documenting locations for cartography. I want to be able to see all of a location and currently I have to manually set the crop for each panorama. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2016362/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2016362] Re: Feature request: Add "Fit crop around images" button
*** This bug is a duplicate of bug 679939 *** https://bugs.launchpad.net/bugs/679939 ** This bug has been marked a duplicate of bug 679939 add quick crop -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2016362 Title: Feature request: Add "Fit crop around images" button Status in Hugin: New Bug description: It would be useful to have a button that sets the crop so that all of the pixels in the source images are in the final image (i.e. set the bounding box to surround all of the source images). This is similar (kind of opposite) in behavior to the "Stitcher→Fit Crop to Images" button that sets the crop so that there are no non- image pixels in final image. This is useful for when you want to be able to see all of the source images in the final image and don't care if it looks pretty. The specific use-case that I have is documenting locations for cartography. I want to be able to see all of a location and currently I have to manually set the crop for each panorama. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2016362/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2012946] Re: Masks-Crop Window Displays Itself Fully In Child Window
I committed a further modification. Hopefully it is now fixed.
--
You received this bug notification because you are a member of Hugin Bug
Hunters, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/2012946
Title:
Masks-Crop Window Displays Itself Fully In Child Window
Status in Hugin:
Fix Committed
Bug description:
In a new session, I import 6 files and click the "Masks" tab and then
select the first file in my list. I then select the "Crop" button
below the file listing and the entire parent window starting with the
"#|Filename |Number of masks|..." where I am clicking the "Crop"
button displays in the the pane where the photo with the crop lines
should show. This makes it impossible to properly place the crop
marks. Notice in the screenshot accompanying this report that the
child window of the image appears, but with its parent and the crop
marks are placed over the unwanted parent portion.
This occurs in Gentoo Linux. Here is my installation information:
eos /etc/portage/package.use # date; eix -I hugin
Mon Mar 27 08:05:54 PDT 2023
[I] media-gfx/hugin
Available versions: 2022.0.0 ***l {debug lapack python raw sift
L10N="ca ca-valencia cs da de en-GB es eu fi fr hu it ja nl pl pt-BR ro ru sk
sv zh-CN zh-TW" PYTHON_SINGLE_TARGET="python3_9 python3_10 python3_11"}
Installed versions: 2022.0.0(10:15:02 03/18/23)(raw sift -debug -lapack
-python L10N="-ca -ca-valencia -cs -da -de -en-GB -es -eu -fi -fr -hu -it -ja
-nl -pl -pt-BR -ro -ru -sk -sv -zh-CN -zh-TW" PYTHON_SINGLE_TARGET="python3_10
-python3_9 -python3_11")
Homepage:http://hugin.sf.net
Description: GUI for the creation & processing of panoramic
images
eos /etc/portage/package.use #
From the About-System window:
Operating System: Linux 5.15.85-gentoo-dist x86_64
Architecture: 64 bit
Free memory: 8556908 kiB
Hugin
Version: 2022.0.0.a0962865f932
Path to resources: /usr/share/hugin/xrc/
Path to data: /usr/share/hugin/data/
Hugins camera and lens database: /home/jlpoole/.hugindata/camlens.db
Multi-threading using C++11 std::thread and OpenMP
Libraries
wxWidgets: wxWidgets 3.0.5
wxWidgets Library (wxGTK port)
Version 3.0.5 (Unicode: wchar_t, debug level: 1),
compiled at Mar 16 2023 07:58:05
Runtime version of toolkit used is 3.24.
Compile-time GTK+ version is 3.24.35.
libpano13: 2.9.21
Boost: 1.81.0
Exiv2: 0.27.6
SQLite3: 3.40.1
Vigra: 1.11.1
LittleCMS2: 2.14
What should happen is that the image displays in the child pane and
the crop outline appears and can be manipulated.
I have Hugin installed on WIndows 7 and have not experienced this
problem. What can I provide or do to give further insight into what
is happening here. I could rebuild the project with debug flags. Also
I noticed this build uses Python 3_10. The Gentoo ebuild file has the
following specifications:
eos /etc/portage/package.use # date; cat
/var/db/repos/gentoo/media-gfx/hugin/hugin-2022.0.0.ebuild
Mon Mar 27 08:17:21 PDT 2023
# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
EAPI=7
WX_GTK_VER="3.0-gtk3"
PYTHON_COMPAT=( python3_{9..11} )
inherit python-single-r1 wxwidgets cmake xdg
DESCRIPTION="GUI for the creation & processing of panoramic images"
HOMEPAGE="http://hugin.sf.net;
SRC_URI="mirror://sourceforge/${PN}/${P/_/}.tar.bz2"
LICENSE="GPL-2+ BSD BSD-2 MIT wxWinLL-3 ZLIB FDL-1.2"
SLOT="0"
KEYWORDS="amd64 arm64 x86"
LANGS=" ca ca-valencia cs da de en-GB es eu fi fr hu it ja nl pl pt-BR
ro ru sk sv zh-CN zh-TW"
IUSE="debug lapack python raw sift $(echo ${LANGS//\ /\ l10n_})"
CDEPEND="
dev-db/sqlite:3
dev-libs/boost:=
dev-libs/zthread
>=media-gfx/enblend-4.0
media-gfx/exiv2:=
media-libs/freeglut
media-libs/glew:=
media-libs/libjpeg-turbo:=
>=media-libs/libpano13-2.9.19_beta1:=
media-libs/libpng:=
media-libs/openexr:=
media-libs/tiff:=
>=media-libs/vigra-1.11.1-r5[openexr]
sci-libs/fftw:3.0=
sci-libs/flann
sys-libs/zlib
virtual/glu
virtual/opengl
x11-libs/wxGTK:${WX_GTK_VER}=[X,opengl]
lapack? ( virtual/blas virtual/lapack )
python? ( ${PYTHON_DEPS} )
sift? ( media-gfx/autopano-sift-C )"
RDEPEND="${CDEPEND}
media-libs/exiftool
raw? ( media-gfx/dcraw )"
DEPEND="${CDEPEND}
[Hugin-bug-hunters] [Bug 2012946] Re: Masks-Crop Window Displays Itself Fully In Child Window
There was already one fix at the weekend in this area.
But it was not enough for the wxGTK implementation. It should now be fixed in
repository in default branch.
** Changed in: hugin
Status: New => Fix Committed
** Changed in: hugin
Milestone: None => 2023.0beta1
--
You received this bug notification because you are a member of Hugin Bug
Hunters, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/2012946
Title:
Masks-Crop Window Displays Itself Fully In Child Window
Status in Hugin:
Fix Committed
Bug description:
In a new session, I import 6 files and click the "Masks" tab and then
select the first file in my list. I then select the "Crop" button
below the file listing and the entire parent window starting with the
"#|Filename |Number of masks|..." where I am clicking the "Crop"
button displays in the the pane where the photo with the crop lines
should show. This makes it impossible to properly place the crop
marks. Notice in the screenshot accompanying this report that the
child window of the image appears, but with its parent and the crop
marks are placed over the unwanted parent portion.
This occurs in Gentoo Linux. Here is my installation information:
eos /etc/portage/package.use # date; eix -I hugin
Mon Mar 27 08:05:54 PDT 2023
[I] media-gfx/hugin
Available versions: 2022.0.0 ***l {debug lapack python raw sift
L10N="ca ca-valencia cs da de en-GB es eu fi fr hu it ja nl pl pt-BR ro ru sk
sv zh-CN zh-TW" PYTHON_SINGLE_TARGET="python3_9 python3_10 python3_11"}
Installed versions: 2022.0.0(10:15:02 03/18/23)(raw sift -debug -lapack
-python L10N="-ca -ca-valencia -cs -da -de -en-GB -es -eu -fi -fr -hu -it -ja
-nl -pl -pt-BR -ro -ru -sk -sv -zh-CN -zh-TW" PYTHON_SINGLE_TARGET="python3_10
-python3_9 -python3_11")
Homepage:http://hugin.sf.net
Description: GUI for the creation & processing of panoramic
images
eos /etc/portage/package.use #
From the About-System window:
Operating System: Linux 5.15.85-gentoo-dist x86_64
Architecture: 64 bit
Free memory: 8556908 kiB
Hugin
Version: 2022.0.0.a0962865f932
Path to resources: /usr/share/hugin/xrc/
Path to data: /usr/share/hugin/data/
Hugins camera and lens database: /home/jlpoole/.hugindata/camlens.db
Multi-threading using C++11 std::thread and OpenMP
Libraries
wxWidgets: wxWidgets 3.0.5
wxWidgets Library (wxGTK port)
Version 3.0.5 (Unicode: wchar_t, debug level: 1),
compiled at Mar 16 2023 07:58:05
Runtime version of toolkit used is 3.24.
Compile-time GTK+ version is 3.24.35.
libpano13: 2.9.21
Boost: 1.81.0
Exiv2: 0.27.6
SQLite3: 3.40.1
Vigra: 1.11.1
LittleCMS2: 2.14
What should happen is that the image displays in the child pane and
the crop outline appears and can be manipulated.
I have Hugin installed on WIndows 7 and have not experienced this
problem. What can I provide or do to give further insight into what
is happening here. I could rebuild the project with debug flags. Also
I noticed this build uses Python 3_10. The Gentoo ebuild file has the
following specifications:
eos /etc/portage/package.use # date; cat
/var/db/repos/gentoo/media-gfx/hugin/hugin-2022.0.0.ebuild
Mon Mar 27 08:17:21 PDT 2023
# Copyright 1999-2023 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
EAPI=7
WX_GTK_VER="3.0-gtk3"
PYTHON_COMPAT=( python3_{9..11} )
inherit python-single-r1 wxwidgets cmake xdg
DESCRIPTION="GUI for the creation & processing of panoramic images"
HOMEPAGE="http://hugin.sf.net;
SRC_URI="mirror://sourceforge/${PN}/${P/_/}.tar.bz2"
LICENSE="GPL-2+ BSD BSD-2 MIT wxWinLL-3 ZLIB FDL-1.2"
SLOT="0"
KEYWORDS="amd64 arm64 x86"
LANGS=" ca ca-valencia cs da de en-GB es eu fi fr hu it ja nl pl pt-BR
ro ru sk sv zh-CN zh-TW"
IUSE="debug lapack python raw sift $(echo ${LANGS//\ /\ l10n_})"
CDEPEND="
dev-db/sqlite:3
dev-libs/boost:=
dev-libs/zthread
>=media-gfx/enblend-4.0
media-gfx/exiv2:=
media-libs/freeglut
media-libs/glew:=
media-libs/libjpeg-turbo:=
>=media-libs/libpano13-2.9.19_beta1:=
media-libs/libpng:=
media-libs/openexr:=
media-libs/tiff:=
>=media-libs/vigra-1.11.1-r5[openexr]
sci-libs/fftw:3.0=
sci-libs/flann
sys-libs/zlib
virtual/glu
virtual/opengl
x11-libs/wxGTK:${WX_GTK_VER}=[X,opengl]
lapack? ( virtual/blas virtual/lapack )
[Hugin-bug-hunters] [Bug 1989723] Re: aborts on startup when built against wxwidgets3.2
The default branch does now allow to use the epoxy library instead of GLEW (see https://bugs.launchpad.net/hugin/+bug/2007178 ) The use the epoxy library add -DBUILD_WITH_EPOXY=on to the CMake command line. Epoxy should detect at run-time if you are using GLX or EGL and so improve the situation (hopefully). ** Changed in: hugin Status: Incomplete => Fix Committed ** Changed in: hugin Milestone: None => 2023.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1989723 Title: aborts on startup when built against wxwidgets3.2 Status in Hugin: Fix Committed Bug description: Hello, I have tried building hugin 2021.0 against wxwidgets3.2. It builds fine (some new deprecation warnings), but the binary is non- functional. It aborts immediately on startup, offering to save some debugging info (attached). cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1989723/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2007178] Re: Replace GLEW with epoxy
I committed the changes to the repository. But I made the choice of GLEW or epoxy user configurable in the CMake build. ** Changed in: hugin Status: New => Fix Committed ** Changed in: hugin Milestone: None => 2023.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2007178 Title: Replace GLEW with epoxy Status in Hugin: Fix Committed Bug description: GLEW is installed for either GLX or EGL, making it impossible to switch to EGL if some applications need GLX. epoxy also does not need to be initialised, making startup faster. GTK, Firefox and Libreoffice are among those using epoxy. Patch (not sure the best way to work with Launchpad and/or Sourceforge...): https://sourceforge.net/p/hugin/hugin/merge-requests/2/ A draft that has only been tested on Linux and at the moment uses PKG_SEARCH_MODULE to find epoxy. So, may work on macOS (libepoxy is available in Homebrew) but more work for Windows and other supporting scripts. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2007178/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2007178] Re: Replace GLEW with epoxy
For ImageTransformsGPU.cpp you need to include before gl.h. Then the glut call work (removing an error reporting is a no-go). But when I use the released epoxy lib (compiled with MSVC) I'm getting the crashes. After more testing it appears there is a bug in libepoxy build system or in meson. Depending on the selected meson backend different code is generated. The backend vs and ninja are both using the some compiler and linker, but produce a different sized library. The library generated by the vs backend is crashing. But when building with the ninja backend epoxy is working. So now I need to clean up the modified code. -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2007178 Title: Replace GLEW with epoxy Status in Hugin: New Bug description: GLEW is installed for either GLX or EGL, making it impossible to switch to EGL if some applications need GLX. epoxy also does not need to be initialised, making startup faster. GTK, Firefox and Libreoffice are among those using epoxy. Patch (not sure the best way to work with Launchpad and/or Sourceforge...): https://sourceforge.net/p/hugin/hugin/merge-requests/2/ A draft that has only been tested on Linux and at the moment uses PKG_SEARCH_MODULE to find epoxy. So, may work on macOS (libepoxy is available in Homebrew) but more work for Windows and other supporting scripts. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2007178/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2007736] Re: FreeBSD hugin assistant stuck cleaning points
I'm not aware of some log files written. wxWidgets is using execvp under the hood of wxExecute. Not sure if this is helpful. -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2007736 Title: FreeBSD hugin assistant stuck cleaning points Status in Hugin: New Bug description: Hello, I can make hugin work, but it takes some doing. If I run the assistant, it will find the control points but gets stuck statistically cleaning them. If I x out I can go into advanced mode and select the images and manually clean the points. It will also only find the points using assistant. If I try in advanced mode it starts cpfind but immediately locks up. So I find the points with assistant and switch over to advanced for the rest and it works. I was using the 2021 version from the pkg and have since upgraded to 2022 with no change. I am runing FreeBSD 13.1. I also tried building from ports to no luck. It works on my Debian partition though. Running cpfind once the assistant runs fine along with cpclean with a previously generated pto file. Thanks in advance! To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2007736/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2007736] Re: FreeBSD hugin assistant stuck cleaning points
Tested on Windows and Ubuntu. On both system it works without problems with the provided test images. Hugin is using wxExecute from wxWidgets to call the command line tools. So I have no experience what on FreeBSD interferences with these calls. -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2007736 Title: FreeBSD hugin assistant stuck cleaning points Status in Hugin: New Bug description: Hello, I can make hugin work, but it takes some doing. If I run the assistant, it will find the control points but gets stuck statistically cleaning them. If I x out I can go into advanced mode and select the images and manually clean the points. It will also only find the points using assistant. If I try in advanced mode it starts cpfind but immediately locks up. So I find the points with assistant and switch over to advanced for the rest and it works. I was using the 2021 version from the pkg and have since upgraded to 2022 with no change. I am runing FreeBSD 13.1. I also tried building from ports to no luck. It works on my Debian partition though. Running cpfind once the assistant runs fine along with cpclean with a previously generated pto file. Thanks in advance! To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2007736/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2007178] Re: Replace GLEW with epoxy
I tried to test it on Windows. First I needed several more changes to get it to compile. But it does not work: nona --gpu is only printing "Attempting to dlopen() while in the dynamic linker." and then crashes. Opening the fast preview crashes Hugin without feedback/further information. -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2007178 Title: Replace GLEW with epoxy Status in Hugin: New Bug description: GLEW is installed for either GLX or EGL, making it impossible to switch to EGL if some applications need GLX. epoxy also does not need to be initialised, making startup faster. GTK, Firefox and Libreoffice are among those using epoxy. Patch (not sure the best way to work with Launchpad and/or Sourceforge...): https://sourceforge.net/p/hugin/hugin/merge-requests/2/ A draft that has only been tested on Linux and at the moment uses PKG_SEARCH_MODULE to find epoxy. So, may work on macOS (libepoxy is available in Homebrew) but more work for Windows and other supporting scripts. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2007178/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2007178] Re: Replace GLEW with epoxy
First I need to check how to build on Windows. The readme does not provide instructions specific for Windows. It seems epoxy needs 2! different build systems (currently not used by Hugin or its dependencies) which would be a high obstacle for building such a small library. Second this lib is new for me and I don't know how enduring it is or how good the maintenance is. Last year there were only 5 commits to the repo. A further point is that the patch is very invasive. It changes many files where GLEW is not used at all. Is this really necessary? ** Changed in: hugin Importance: Undecided => Wishlist -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2007178 Title: Replace GLEW with epoxy Status in Hugin: New Bug description: GLEW is installed for either GLX or EGL, making it impossible to switch to EGL if some applications need GLX. epoxy also does not need to be initialised, making startup faster. GTK, Firefox and Libreoffice are among those using epoxy. Patch (not sure the best way to work with Launchpad and/or Sourceforge...): https://sourceforge.net/p/hugin/hugin/merge-requests/2/ A draft that has only been tested on Linux and at the moment uses PKG_SEARCH_MODULE to find epoxy. So, may work on macOS (libepoxy is available in Homebrew) but more work for Windows and other supporting scripts. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2007178/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2002813] Re: align_image_stack hangs
The main issue here is, that ais has found only 2 cp, but there are 6 parameters to optimize. Then the optimizer goes haywire and the autocrop hangs. I added an additional check to prevent this loop. ** Changed in: hugin Status: Incomplete => Fix Committed ** Changed in: hugin Milestone: None => 2023.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2002813 Title: align_image_stack hangs Status in Hugin: Fix Committed Bug description: I have an application that uses align_image_stack, which works very well. Unfortunately it sometimes hangs up when aligning two images, I assume that's because they are too difficult to align. It states "Number of good matches: 0, bad matches: 40" many times, then that it has done "n iterations" up to 259. At that point it states "Run called" and then gets stuck. This would be alright if I was using it from a terminal, but it's embarrassing when it does it in my app - there's no easy way to detect the condition and stop it. It would be better to prevent it - is that possible? If not I think it's a bug. I can supply the two images. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2002813/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2002813] Re: align_image_stack hangs
In the first case the problem is complex and a combination of several switches. With the optimization of HFOV (-m) the optimization leads to a movement of the second image outside of the ROI. When now running autocrop (-C switch) it resulted in the hang because the second image is outside of the panorama canvas. This is now fixed in the repository. You are using a lot of different parameters. So it is difficult to reproduce the second example. When using the parameters as in your first sample it works here (with and also without -m switch). So please don't simply add the images here. Please provide also the full command line for reproduction. Otherwise it becomes too difficult to find something plausible. -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2002813 Title: align_image_stack hangs Status in Hugin: Incomplete Bug description: I have an application that uses align_image_stack, which works very well. Unfortunately it sometimes hangs up when aligning two images, I assume that's because they are too difficult to align. It states "Number of good matches: 0, bad matches: 40" many times, then that it has done "n iterations" up to 259. At that point it states "Run called" and then gets stuck. This would be alright if I was using it from a terminal, but it's embarrassing when it does it in my app - there's no easy way to detect the condition and stop it. It would be better to prevent it - is that possible? If not I think it's a bug. I can supply the two images. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2002813/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2002813] Re: align_image_stack hangs
align_image_stack -o test problem-image1.jpg problem-image2.jpg WARNING: Spread of exposure values is very small. Disabling sorting images by exposure value. No Feature Points Bad params An error occurred during optimization. Try adding "-p debug.pto" and checking output. Exiting... When calling with standard parameters it does not hang. What is your full command line for align_image_stack? -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2002813 Title: align_image_stack hangs Status in Hugin: Incomplete Bug description: I have an application that uses align_image_stack, which works very well. Unfortunately it sometimes hangs up when aligning two images, I assume that's because they are too difficult to align. It states "Number of good matches: 0, bad matches: 40" many times, then that it has done "n iterations" up to 259. At that point it states "Run called" and then gets stuck. This would be alright if I was using it from a terminal, but it's embarrassing when it does it in my app - there's no easy way to detect the condition and stop it. It would be better to prevent it - is that possible? If not I think it's a bug. I can supply the two images. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2002813/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2002762] Re: OpenGL preview's list of active images lags by 1 click
You did not mentioned which operating system and which Hugin version. Also it is not reproducible on Windows and LUbuntu. On both systems it works perfectly. Maybe you are confused by a hover effect on the button which can have another colour (maybe it is only slightly different) ** Changed in: hugin Status: New => Invalid ** Changed in: hugin Status: Invalid => Incomplete -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2002762 Title: OpenGL preview's list of active images lags by 1 click Status in Hugin: Incomplete Bug description: When images are loaded into the GL preview window, buttons for active images are blue and inactive ones are white. Clicking a button to toggle an image should update that button immediately, but the button colors are apparently redrawn using an outdated state. The problem is immediately apparent if an image is clicked off, but the button remains blue, until another image is toggled, then the first image's button turns white. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2002762/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2002813] Re: align_image_stack hangs
Yes, having the 2 images would be helpful. Otherwise it is very difficult to find the point. ** Changed in: hugin Status: New => Incomplete -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2002813 Title: align_image_stack hangs Status in Hugin: Incomplete Bug description: I have an application that uses align_image_stack, which works very well. Unfortunately it sometimes hangs up when aligning two images, I assume that's because they are too difficult to align. It states "Number of good matches: 0, bad matches: 40" many times, then that it has done "n iterations" up to 259. At that point it states "Run called" and then gets stuck. This would be alright if I was using it from a terminal, but it's embarrassing when it does it in my app - there's no easy way to detect the condition and stop it. It would be better to prevent it - is that possible? If not I think it's a bug. I can supply the two images. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2002813/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2002559] Re: build error with flann 1.9.2
Thanks for the patch. Committed to repository (default branch) ** Changed in: hugin Status: New => Fix Committed ** Changed in: hugin Milestone: None => 2023.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/2002559 Title: build error with flann 1.9.2 Status in Hugin: Fix Committed Bug description: Hello, this was originally reported in https://bugs.debian.org/1027934 hugin 2022.0.0 fails to build against flann 1.9.2 since it does not use FLANN_LIBRARY_DIRS as set by CMakeModules/FindFLANN.cmake ~~~ [ 50%] Linking CXX executable cpfind cd /dev/shm/HUGIN/hugin-2022.0.0/obj-x86_64-linux-gnu/src/hugin_cpfind/cpfind && /usr/bin/cmake -E cmake_link_script CMakeFiles/cpfind.dir/link.txt --verbose=1 /usr/lib/ccache/c++ -g -O2 -ffile-prefix-map=/dev/shm/HUGIN/hugin-2022.0.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -Wl,-z,defs -fopenmp CMakeFiles/cpfind.dir/PanoDetector.cpp.o CMakeFiles/cpfind.dir/PanoDetectorLogic.cpp.o CMakeFiles/cpfind.dir/TestCode.cpp.o CMakeFiles/cpfind.dir/Utils.cpp.o CMakeFiles/cpfind.dir/main.cpp.o -o cpfind -Wl,-rpath,/dev/shm/HUGIN/hugin-2022.0.0/obj-x86_64-linux-gnu/src/hugin_cpfind/localfeatures:/dev/shm/HUGIN/hugin-2022.0.0/obj-x86_64-linux-gnu/src/celeste:/dev/shm/HUGIN/hugin-2022.0.0/obj-x86_64-linux-gnu/src/hugin_base: ../localfeatures/liblocalfeatures.so.0.0 /usr/lib/x86_64-linux-gnu/libvigraimpex.so /usr/lib/x86_64-linux-gnu/libOpenEXR.so /usr/lib/x86_64-linux-gnu/libImath-3_1.so /usr/lib/x86_64-linux-gnu/libIex-3_1.so /usr/lib/x86_64-linux-gnu/libIlmThread-3_1.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libjpeg.so /usr/lib/x86_6 4-linux-gnu/libtiff.so /usr/lib/x86_64-linux-gnu/libpng.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libexiv2.so /usr/lib/x86_64-linux-gnu/libpano13.so ../../foreign/levmar/libhuginlevmar.a /usr/lib/x86_64-linux-gnu/libGLEW.so /usr/lib/x86_64-linux-gnu/libfftw3.so /usr/lib/x86_64-linux-gnu/libvigraimpex.so /usr/lib/x86_64-linux-gnu/libOpenEXR.so /usr/lib/x86_64-linux-gnu/libImath-3_1.so /usr/lib/x86_64-linux-gnu/libIex-3_1.so /usr/lib/x86_64-linux-gnu/libIlmThread-3_1.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libjpeg.so /usr/lib/x86_64-linux-gnu/libtiff.so /usr/lib/x86_64-linux-gnu/libpng.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libexiv2.so /usr/lib/x86_64-linux-gnu/liblcms2.so ../../celeste/libceleste.so.0.0 -lflann -lflann_cpp -lhdf5 -lmpi -llz4 ../../hugin_base/libhuginbase.so.0.0 /usr/lib/x86_64-linux-gnu/libX11.so /usr/lib/x86_64-linux-gnu/libOpenGL.s o /usr/lib/x86_64-linux-gnu/libGLX.so /usr/lib/x86_64-linux-gnu/libGLU.so /usr/lib/x86_64-linux-gnu/libsqlite3.so /usr/lib/x86_64-linux-gnu/libpano13.so ../../foreign/levmar/libhuginlevmar.a /usr/lib/x86_64-linux-gnu/libGLEW.so /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.74.0 /usr/lib/x86_64-linux-gnu/libboost_system.so.1.74.0 /usr/lib/x86_64-linux-gnu/libfftw3.so /usr/lib/x86_64-linux-gnu/libvigraimpex.so /usr/lib/x86_64-linux-gnu/libOpenEXR.so /usr/lib/x86_64-linux-gnu/libImath-3_1.so /usr/lib/x86_64-linux-gnu/libIex-3_1.so /usr/lib/x86_64-linux-gnu/libIlmThread-3_1.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libjpeg.so /usr/lib/x86_64-linux-gnu/libpng.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libjpeg.so /usr/lib/x86_64-linux-gnu/libpng.so /usr/lib/x86_64-linux-gnu/libtiff.so /usr/lib/x86_64-linux-gnu/libexiv2.so /usr/lib/x86_64-linux-gnu/liblcms2.so /usr/bin/ld: cannot find -lhdf5: No such file or directory collect2: error: ld returned 1 exit status ~~~ Find attached the patch used in the Debian package patch to fix this. cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/2002559/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2000019] Re: Take into account digital zoom ratio EXIF tag in the computation of the HFOV
Should now be fixed in repository. ** Changed in: hugin Status: Incomplete => Fix Committed ** Changed in: hugin Milestone: None => 2023.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/219 Title: Take into account digital zoom ratio EXIF tag in the computation of the HFOV Status in Hugin: Fix Committed Bug description: The horizontal field of view (HFOV) property of a picture is critical to allow proper stitching. Inadequate values forbid automatic detection of control points, which is a central piece (and major added value) in Hugin's, and hence breaks the automated stitching workflow. Thankfully, Hugin automatically computes the HFOV value for pictures with valid EXIF data. Again, this is a great benefit which avoids manual computation for each lense and lengthy entry of manual data. In traditional cameras, the HFOV is mainly a function of the lense's focal length: adjusting the zoom between two shots with the same camera results in different focal lengths for each shot. This information is correctly read and interpreted into distinct HFOV by Hugin. In contrast, modern digital cameras, such as samsung cell phones to cite just one widely-spread example, typically feature fixed lenses with a unique focal length. Yet, it is still possible to take shots with different zoom factors (or, say, to be given pictures to stitch that were taken with such a device and with different zoom factors...). In this case, the focal length information is identical for all shots and the zoom information is encoded in a distinct EXIF tag, called the 'Digital Zoom Ratio'. Currently, it seems that Hugin doesn't take advantage of this tag, hence wrongly assuming that all pictures taken with the same 'digital camera' have an identical HFOV. This causes Hugin to be unable to stitch the pictures, because it typically fails to find control points. This might be relatively straightforward to fix given that: - The digital zoom ratio affects the HFOV in a simple manner, so it should be possible to compute the HFOV by taking into account both the lense's focal length and the digital zoom ratio (when available) - Hugin seems to rely on Exiv2 to acquire EXIF data from files, which supports the 'Digital Zoom Ratio' tag, so it should be possible to access this tag with the existing infrastructure. I checked that the command `exiv2 -pt image.jpg` on my images return the tag `Exif.Photo.DigitalZoomRatio` with the correct value. The same values are also read by Exiftool (checked with command `exiftool image.jpg`). I'm using Hugin 2021.0.0.52df0f76c700 (built with Exiv2 0.27.5) on Ubuntu 22.04.1. The version of Exiv2 that I used in the command line is also 0.27.5. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/219/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 2000019] Re: Take into account digital zoom ratio EXIF tag in the computation of the HFOV
Hugin has already several ways to calculate the fov. The latest one especially for some cell phone cameras was added in 2022.0. Why can't the manufactures use the same tags? Why must everybody use it's own schema. So please test 2022.0 first. If it does not work please provide a link to some test images. ** Changed in: hugin Status: New => Incomplete -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/219 Title: Take into account digital zoom ratio EXIF tag in the computation of the HFOV Status in Hugin: Incomplete Bug description: The horizontal field of view (HFOV) property of a picture is critical to allow proper stitching. Inadequate values forbid automatic detection of control points, which is a central piece (and major added value) in Hugin's, and hence breaks the automated stitching workflow. Thankfully, Hugin automatically computes the HFOV value for pictures with valid EXIF data. Again, this is a great benefit which avoids manual computation for each lense and lengthy entry of manual data. In traditional cameras, the HFOV is mainly a function of the lense's focal length: adjusting the zoom between two shots with the same camera results in different focal lengths for each shot. This information is correctly read and interpreted into distinct HFOV by Hugin. In contrast, modern digital cameras, such as samsung cell phones to cite just one widely-spread example, typically feature fixed lenses with a unique focal length. Yet, it is still possible to take shots with different zoom factors (or, say, to be given pictures to stitch that were taken with such a device and with different zoom factors...). In this case, the focal length information is identical for all shots and the zoom information is encoded in a distinct EXIF tag, called the 'Digital Zoom Ratio'. Currently, it seems that Hugin doesn't take advantage of this tag, hence wrongly assuming that all pictures taken with the same 'digital camera' have an identical HFOV. This causes Hugin to be unable to stitch the pictures, because it typically fails to find control points. This might be relatively straightforward to fix given that: - The digital zoom ratio affects the HFOV in a simple manner, so it should be possible to compute the HFOV by taking into account both the lense's focal length and the digital zoom ratio (when available) - Hugin seems to rely on Exiv2 to acquire EXIF data from files, which supports the 'Digital Zoom Ratio' tag, so it should be possible to access this tag with the existing infrastructure. I checked that the command `exiv2 -pt image.jpg` on my images return the tag `Exif.Photo.DigitalZoomRatio` with the correct value. The same values are also read by Exiftool (checked with command `exiftool image.jpg`). I'm using Hugin 2021.0.0.52df0f76c700 (built with Exiv2 0.27.5) on Ubuntu 22.04.1. The version of Exiv2 that I used in the command line is also 0.27.5. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/219/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1998020] Re: Hugin Calibrate Lens asserts on start
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1998020 Title: Hugin Calibrate Lens asserts on start Status in Hugin: Fix Released Bug description: When I start "Hugin Calibrate Lens" from my Debian Testing Cinnamon Start Menu, a popup labelled "calibrate_lens_gui" pops up saying "An assertion failed!" Hugin version: 2021.0.0+dfsg-3 ASSERT INFO: ./src/gtk/bitmap.cpp(541): assert ""width > 0 && height > 0"" failed in Create(): invalid bitmap size BACKTRACE: [1] wxBitmap::Create(int, int, int) [2] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [3] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [4] wxEvtHandler::TryHereOnly(wxEvent&) [5] wxEvtHandler::ProcessEventLocally(wxEvent&) [6] wxEvtHandler::ProcessEvent(wxEvent&) [7] wxEvtHandler::SafelyProcessEvent(wxEvent&) [8] wxWindow::DoSetSize(int, int, int, int, int) [9] wxBoxSizer::RepositionChildren(wxSize const&) [10] wxStaticBoxSizer::RepositionChildren(wxSize const&) [11] wxSizer::Layout() [12] wxSizerItem::SetDimension(wxPoint const&, wxSize const&) [13] wxBoxSizer::RepositionChildren(wxSize const&) [14] wxSizer::Layout() [15] wxWindowBase::Layout() [16] wxWindowBase::InternalOnSize(wxSizeEvent&) [17] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [18] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [19] wxEvtHandler::TryHereOnly(wxEvent&) [20] wxEvtHandler::ProcessEventLocally(wxEvent&) [21] wxEvtHandler::ProcessEvent(wxEvent&) [22] wxEvtHandler::SafelyProcessEvent(wxEvent&) [23] wxWindow::DoSetSize(int, int, int, int, int) [24] wxWindowBase::WXSetInitialFittingClientSize(int, wxSizer*) [25] wxSizer::Fit(wxWindow*) [26] wxSizerXmlHandler::Handle_sizer() [27] wxXmlResourceHandlerImpl::CreateResource(wxXmlNode*, wxObject*, wxObject*) [28] wxXmlResourceHandlerImpl::CreateChildren(wxObject*, bool) [29] wxPanelXmlHandler::DoCreateResource() [30] wxXmlResourceHandlerImpl::CreateResource(wxXmlNode*, wxObject*, wxObject*) [31] wxSizerXmlHandler::Handle_sizeritem() [32] wxXmlResourceHandlerImpl::CreateResource(wxXmlNode*, wxObject*, wxObject*) [33] wxXmlResourceHandlerImpl::CreateChildren(wxObject*, bool) [34] wxSizerXmlHandler::Handle_sizer() [35] wxXmlResourceHandlerImpl::CreateResource(wxXmlNode*, wxObject*, wxObject*) [36] wxXmlResourceHandlerImpl::CreateChildren(wxObject*, bool) [37] wxFrameXmlHandler::DoCreateResource() [38] wxXmlResourceHandlerImpl::CreateResource(wxXmlNode*, wxObject*, wxObject*) [39] wxXmlResource::LoadFrame(wxFrame*, wxWindow*, wxString const&) [40] wxEntry(int&, wchar_t**) [41] __libc_start_main Clicking "Continue" brings the same popup again. Clicking "Stop" closes the program. So Calibrate lens is not usable. This reminds me of an earlier bug #1909484 (2020.0.0 calibrate_lens_gui - multiple assertions at startup) with the previous version. This one has been fixed by the wx-widgets team (issue 18520) - they said, they would check width/height instead bmpData. Seems, Hugin still calls wxBitmap:Create with an invalid bitmap. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1998020/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1999961] Re: arm64 build for macOS
We are only doing a source code release. The corresponding binaries are contributed by the community. So it needs volunteer to do the build. ** Changed in: hugin Status: New => Opinion -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/161 Title: arm64 build for macOS Status in Hugin: Opinion Bug description: Could you guys please release a binary for macOS users on the new Apple Silicon hardware? Apple won't be supporting x86_64 forever and it'd be great to have native builds for arm64 on macOS. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/161/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1998020] Re: Hugin Calibrate Lens asserts on start
I can't reproduce it. Assuming this is with wxWidgets 3.2 with GTK3? And it does not happen with wxWidgets 3.1.x? Trying to blind fix in repository. ** Summary changed: - Hugin Calibrate Lens crashes on start + Hugin Calibrate Lens asserts on start ** Changed in: hugin Status: New => Fix Committed ** Changed in: hugin Milestone: None => 2022.0rc1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1998020 Title: Hugin Calibrate Lens asserts on start Status in Hugin: Fix Committed Bug description: When I start "Hugin Calibrate Lens" from my Debian Testing Cinnamon Start Menu, a popup labelled "calibrate_lens_gui" pops up saying "An assertion failed!" Hugin version: 2021.0.0+dfsg-3 ASSERT INFO: ./src/gtk/bitmap.cpp(541): assert ""width > 0 && height > 0"" failed in Create(): invalid bitmap size BACKTRACE: [1] wxBitmap::Create(int, int, int) [2] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [3] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [4] wxEvtHandler::TryHereOnly(wxEvent&) [5] wxEvtHandler::ProcessEventLocally(wxEvent&) [6] wxEvtHandler::ProcessEvent(wxEvent&) [7] wxEvtHandler::SafelyProcessEvent(wxEvent&) [8] wxWindow::DoSetSize(int, int, int, int, int) [9] wxBoxSizer::RepositionChildren(wxSize const&) [10] wxStaticBoxSizer::RepositionChildren(wxSize const&) [11] wxSizer::Layout() [12] wxSizerItem::SetDimension(wxPoint const&, wxSize const&) [13] wxBoxSizer::RepositionChildren(wxSize const&) [14] wxSizer::Layout() [15] wxWindowBase::Layout() [16] wxWindowBase::InternalOnSize(wxSizeEvent&) [17] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [18] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [19] wxEvtHandler::TryHereOnly(wxEvent&) [20] wxEvtHandler::ProcessEventLocally(wxEvent&) [21] wxEvtHandler::ProcessEvent(wxEvent&) [22] wxEvtHandler::SafelyProcessEvent(wxEvent&) [23] wxWindow::DoSetSize(int, int, int, int, int) [24] wxWindowBase::WXSetInitialFittingClientSize(int, wxSizer*) [25] wxSizer::Fit(wxWindow*) [26] wxSizerXmlHandler::Handle_sizer() [27] wxXmlResourceHandlerImpl::CreateResource(wxXmlNode*, wxObject*, wxObject*) [28] wxXmlResourceHandlerImpl::CreateChildren(wxObject*, bool) [29] wxPanelXmlHandler::DoCreateResource() [30] wxXmlResourceHandlerImpl::CreateResource(wxXmlNode*, wxObject*, wxObject*) [31] wxSizerXmlHandler::Handle_sizeritem() [32] wxXmlResourceHandlerImpl::CreateResource(wxXmlNode*, wxObject*, wxObject*) [33] wxXmlResourceHandlerImpl::CreateChildren(wxObject*, bool) [34] wxSizerXmlHandler::Handle_sizer() [35] wxXmlResourceHandlerImpl::CreateResource(wxXmlNode*, wxObject*, wxObject*) [36] wxXmlResourceHandlerImpl::CreateChildren(wxObject*, bool) [37] wxFrameXmlHandler::DoCreateResource() [38] wxXmlResourceHandlerImpl::CreateResource(wxXmlNode*, wxObject*, wxObject*) [39] wxXmlResource::LoadFrame(wxFrame*, wxWindow*, wxString const&) [40] wxEntry(int&, wchar_t**) [41] __libc_start_main Clicking "Continue" brings the same popup again. Clicking "Stop" closes the program. So Calibrate lens is not usable. This reminds me of an earlier bug #1909484 (2020.0.0 calibrate_lens_gui - multiple assertions at startup) with the previous version. This one has been fixed by the wx-widgets team (issue 18520) - they said, they would check width/height instead bmpData. Seems, Hugin still calls wxBitmap:Create with an invalid bitmap. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1998020/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1955330] Re: Wrong hint text when stitching modified project file
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1955330 Title: Wrong hint text when stitching modified project file Status in Hugin: Fix Released Bug description: To reproduce it, start Hugin and load a .pto file that is already optimized so that it can be stitched. Change some settings, e.g. the size of the panorama in the "stitching" tab. Click on "stitch". Hugin will prompt that the panorama must be saved before stitching. In the "save" dialog enter a filename that is different from the name of the file that you loaded. Hugin will faultly overwrite the file that you loaded instead of saving it to the new .pto filename. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1955330/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1993959] Re: Lens calibration gui caches removed images
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1993959 Title: Lens calibration gui caches removed images Status in Hugin: Fix Released Bug description: OS: Windows 10 Hugin 2021.0.0.52df0f76c700, standalone lens calibration GUI run via start menu shortcut from installer. On the lens calibration GUI, if an image is removed (with "remove" button) then re-added with the "add" button, a cached copy of the image seems to be loaded, rather than the image file being reloaded. This prevents images from being edited externally then reloaded, because re-adding the removed image adds the old copy, not the new modified file. The workaround is to either rename the image file before re-adding, or restart the lens calibration GUI. Steps: 1. Add an image 2. Edit the image with an external program and save it with the same file name 3. Remove the image (this and previous step can be swapped) 4. Add the image again Expected: Edited image is loaded into lens calibration GUI Actual: Old image is loaded into lens calibration GUI Note: I am not sure what the purpose is of caching the images at all. It's not really a performance issue in the calibration GUI. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1993959/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1956715] Re: fulla flatfield extremely dark
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1956715 Title: fulla flatfield extremely dark Status in Hugin: Fix Released Bug description: fulla version: 2020.0.0.2f576e5d5b4a image resolution :6264 x 4180 x 3-channel x 16-bit , scaling down does not help. using 16-bit TIFF flat field, result is extremely dark, value <= 4 (full scale 65535) using 8-bit TIFF flat field, result value <= 4 (full scale 255) To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1956715/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1975825] Re: Image parameters d, e, Vx and Vy are incorrectly scaled when loading a project file as template
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1975825 Title: Image parameters d, e, Vx and Vy are incorrectly scaled when loading a project file as template Status in Hugin: Fix Released Bug description: 1: load a set of images that are larger than the images specified in the template .pto file 2: image parameters d, e and Vx, Vy are incorrectly scaled for the new images In this case, the original files were 4924 × 7378 pixels and the new files were 9824 × 14720 pixels in size. Hugin project file attached. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1975825/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1960217] Re: Slovak translation
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1960217 Title: Slovak translation Status in Hugin: Fix Released Bug description: Updates and fixes to Slovak translation are attached. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1960217/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1994039] Re: Hugin GUI doesn't support high DPI displays (Windows)
** Changed in: hugin Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1994039 Title: Hugin GUI doesn't support high DPI displays (Windows) Status in Hugin: Fix Released Bug description: OS: Windows 10 Display: 3840x2160, system scaling at 250% The Hugin Panorama Editor GUI does not scale correctly on high DPI displays. See attached screen grab. As a workaround, use of the system scaler can be forced through the compatibility settings, but the results are the usual amount of sketchy. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1994039/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1994984] Re: Importing raw files with Rawtherapee with prepared .pp3 doesn't rotate output files
> if all raw files have the same orientation, That's exactly the point. A fixed rotation goes havoc if this is not fulfilled. And Hugin does not force this. So the easier point is therefore to disable these additional rotation and relay that RawTherapee does already rotate all images according to the orientation tag. > There is no easy way in Hugin to simply rotate a panorama 90 or 270 degrees. Wrong. In the preview windows use rotate with roll 90 or -90 to simply rotate a panorama. -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1994984 Title: Importing raw files with Rawtherapee with prepared .pp3 doesn't rotate output files Status in Hugin: Opinion Bug description: Import raw files with Rawtherapee with prepared .pp3 doesn't rotate output files. For example, the relevant section from .pp3: [Coarse Transformation] Rotate=90 HorizontalFlip=false VerticalFlip=false The output tiff file has the same orientation as the input raw file. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1994984/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1994984] Re: Importing raw files with Rawtherapee with prepared .pp3 doesn't rotate output files
In Hugins raw import the rotation is intentionally disabled. Background: If the pp3 files of different files contains different rotation it results in problems in Hugin. (So the images gets different lenses assigned, which makes the default alignment more complicated.) So the rotation during raw import is disabled and the final rotation is done with nona. ** Changed in: hugin Status: New => Opinion -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1994984 Title: Importing raw files with Rawtherapee with prepared .pp3 doesn't rotate output files Status in Hugin: Opinion Bug description: Import raw files with Rawtherapee with prepared .pp3 doesn't rotate output files. For example, the relevant section from .pp3: [Coarse Transformation] Rotate=90 HorizontalFlip=false VerticalFlip=false The output tiff file has the same orientation as the input raw file. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1994984/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1994036] Re: [FR] Exclusion zones for edge detection in calibration GUI
You can already enable or disable individual lines. So you can easily disable individual lines an I don't see the need for such an additional feature. ** Changed in: hugin Status: New => Opinion -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1994036 Title: [FR] Exclusion zones for edge detection in calibration GUI Status in Hugin: Opinion Bug description: I'd like to request the ability to define a zone (or zones) of the input images that will be excluded from edge detection in the lens calibration GUI. Use case for me is processing images from security cameras that have two significant edge noise sources: - An overlaid black bar with date/time info, which creates a strong straight horizontal edge - A number of objects that are themselves not straight but which are misdetected as straight edges (for example, a vehicle with a slightly curved profile and high contrast against the background) It is possible to edit these false positives out by blurring / adjusting contrast in an external image editor and achieve good results after a bit of trial and error, but it would save a lot of steps if I could instead just exclude areas directly. Thank you! To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1994036/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1993959] Re: Lens calibration gui caches removed images
Fixed in repository. Note: Not sure what's the point of editing the image. Calibrate_lens_gui is intended to work on the images straight from the camera, so there should be no need to edit them in between. ** Changed in: hugin Status: New => Fix Committed ** Changed in: hugin Milestone: None => 2022.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1993959 Title: Lens calibration gui caches removed images Status in Hugin: Fix Committed Bug description: OS: Windows 10 Hugin 2021.0.0.52df0f76c700, standalone lens calibration GUI run via start menu shortcut from installer. On the lens calibration GUI, if an image is removed (with "remove" button) then re-added with the "add" button, a cached copy of the image seems to be loaded, rather than the image file being reloaded. This prevents images from being edited externally then reloaded, because re-adding the removed image adds the old copy, not the new modified file. The workaround is to either rename the image file before re-adding, or restart the lens calibration GUI. Steps: 1. Add an image 2. Edit the image with an external program and save it with the same file name 3. Remove the image (this and previous step can be swapped) 4. Add the image again Expected: Edited image is loaded into lens calibration GUI Actual: Old image is loaded into lens calibration GUI Note: I am not sure what the purpose is of caching the images at all. It's not really a performance issue in the calibration GUI. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1993959/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1994039] Re: Hugin GUI doesn't support high DPI displays (Windows)
Hugin and all its GUI tools *are* hidpi aware. The manifest is correctly added. This can be easily checked in the task manager. There were only 2 places (about dialog and overview panel) were still the old hard coded values were used. This is now fixed in the repository. ** Changed in: hugin Status: New => Fix Committed ** Changed in: hugin Milestone: None => 2022.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1994039 Title: Hugin GUI doesn't support high DPI displays (Windows) Status in Hugin: Fix Committed Bug description: OS: Windows 10 Display: 3840x2160, system scaling at 250% The Hugin Panorama Editor GUI does not scale correctly on high DPI displays. See attached screen grab. As a workaround, use of the system scaler can be forced through the compatibility settings, but the results are the usual amount of sketchy. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1994039/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1989723] Re: aborts on startup when built against wxwidgets3.2
Sorry, I wasn't aware of the OpenGL ES/GLEW/wxWidgets problems. The bug appeared some time ago: https://bugs.launchpad.net/hugin/+bug/1938453 And there the build fix for glew worked. Not sure how to work around. There are some functions in the fast preview which are using GLEW function. Not sure if it is feasible to find a replacement. -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1989723 Title: aborts on startup when built against wxwidgets3.2 Status in Hugin: Incomplete Bug description: Hello, I have tried building hugin 2021.0 against wxwidgets3.2. It builds fine (some new deprecation warnings), but the binary is non- functional. It aborts immediately on startup, offering to save some debugging info (attached). cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1989723/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1989723] Re: aborts on startup when built against wxwidgets3.2
Hi Andreas, does it works now? How can the build instruction be more clear? Suggestions are always welcome. -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1989723 Title: aborts on startup when built against wxwidgets3.2 Status in Hugin: Incomplete Bug description: Hello, I have tried building hugin 2021.0 against wxwidgets3.2. It builds fine (some new deprecation warnings), but the binary is non- functional. It aborts immediately on startup, offering to save some debugging info (attached). cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1989723/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1989723] Re: aborts on startup when built against wxwidgets3.2
This is a known build issue. >From the INSTALL_cmake file in Hugins base directory: Note: On Linux wxWidgets 3.1.5 and later is by default compiled with EGL support for the wxGLCanvas class. In this case you need to activate EGL support explicitly also in GLEW, otherwise there are crashes when intializing the wxGLCanvas. -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1989723 Title: aborts on startup when built against wxwidgets3.2 Status in Hugin: Incomplete Bug description: Hello, I have tried building hugin 2021.0 against wxwidgets3.2. It builds fine (some new deprecation warnings), but the binary is non- functional. It aborts immediately on startup, offering to save some debugging info (attached). cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1989723/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1989723] Re: aborts on startup when built against wxwidgets3.2
Please test the attached patch. I'm testing also with wxWidgets 3.2 and don't get the assert. So it just a guess. ** Patch added: "assert.diff" https://bugs.launchpad.net/hugin/+bug/1989723/+attachment/5616494/+files/assert.diff -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1989723 Title: aborts on startup when built against wxwidgets3.2 Status in Hugin: Incomplete Bug description: Hello, I have tried building hugin 2021.0 against wxwidgets3.2. It builds fine (some new deprecation warnings), but the binary is non- functional. It aborts immediately on startup, offering to save some debugging info (attached). cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1989723/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1989723] Re: aborts on startup when built against wxwidgets3.2
What was the last working wxWidgets versions? Was it from the 3.0.x series? If so then it is only faint related to the wxWidgets 3.2 version. It was already fixed in the repository (changeset edfddc6070ca). See also https://groups.google.com/g/hugin-ptx/c/kSrBFdINUnY If the last working version was from the 3.1.x series, we have to dig deeper. The debug report indicates to a crash in hugin_utils::GetUserAppDataDir in file src/hugin_base/hugin_utils/utils.cpp, line 461. But I hope it was the first one. ** Changed in: hugin Status: New => Incomplete -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1989723 Title: aborts on startup when built against wxwidgets3.2 Status in Hugin: Incomplete Bug description: Hello, I have tried building hugin 2021.0 against wxwidgets3.2. It builds fine (some new deprecation warnings), but the binary is non- functional. It aborts immediately on startup, offering to save some debugging info (attached). cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1989723/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1989024] Re: Geotagging information lost in the final output
First there are several GPS tags (e.g in Exif and/or XMP) possible. Second some GPS tags are indicating a direction and would be wrong in the final panorama. But the tags which are copied into the final panorama are customizable. Go to preferences, tab Stitching (2) and add the necessary tags to the final Exiftool arg file. If your images have the GPS info in the exif tags, you will probably need: -GPSLatitude -GPSLatitudeRef -GPSLongitude -GPSLongitudeRef -GPSAltitude -GPSAltitudeRef -GPSMapDatum -GPSDateStamp -GPSTimeStamp If you don't have direction GPS tags, maybe also -GPS:all will work. But this is untested. ** Changed in: hugin Status: New => Incomplete -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1989024 Title: Geotagging information lost in the final output Status in Hugin: Incomplete Bug description: My panorama input is a bunch of JPG photos - all are geotagged. When I use Assistant exporting the image to JPG the GPS location is stripped from Exif data - I would expect this information to be retained (e. g. use the GPS data from the first/last image in the list). To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1989024/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
[Hugin-bug-hunters] [Bug 1975825] Re: Image parameters d, e, Vx and Vy are incorrectly scaled when loading a project file as template
Now I see it. It is related to linked image variables. For unlinked image variables it worked fine. It should now be fixed in repository in changeset 490baa16aae6. ** Changed in: hugin Status: Incomplete => Fix Committed ** Changed in: hugin Milestone: None => 2022.0beta1 -- You received this bug notification because you are a member of Hugin Bug Hunters, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1975825 Title: Image parameters d, e, Vx and Vy are incorrectly scaled when loading a project file as template Status in Hugin: Fix Committed Bug description: 1: load a set of images that are larger than the images specified in the template .pto file 2: image parameters d, e and Vx, Vy are incorrectly scaled for the new images In this case, the original files were 4924 × 7378 pixels and the new files were 9824 × 14720 pixels in size. Hugin project file attached. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1975825/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-bug-hunters Post to : hugin-bug-hunters@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-bug-hunters More help : https://help.launchpad.net/ListHelp
