SUMMARY Plugin Panorama crashes when starting to prepare the final panorama. STEPS TO REPRODUCE 1. Start panorama tool. 2. Pictures are preprocessed, the optimizing step finishes and the preview of the panorama is displayed. 3. After clicking on "Next >", the assistent indicates that postprecessing is started, but then the assistent and the digiKam main window freezes. OBSERVED RESULT Refer to "Steps to reproduce" EXPECTED RESULT n.a. SOFTWARE/OS VERSIONS Windows: 10 Home 64 bit
Which Hugin version do you use ? Please install DebugView from Microsoft and take a debug trace of Panorama tool during processing files. Can you take a look to DrMinGW backtrace to see where the dysfunction appear ? Can you share images to process to try to reproduce the dysfunction here ? For more technical details, please look in digiKam web site : https://www.digikam.org/contribute/ Thanks in advance Gilles Caulier
I also rarely had a freezing on Linux after the preview. Now here with a test under Windows7 I can reproduce very often. I will look at it. Maik
(In reply to caulier.gilles from comment #1) > Which Hugin version do you use ? > > Please install DebugView from Microsoft and take a debug trace of Panorama > tool during processing files. > > Can you take a look to DrMinGW backtrace to see where the dysfunction appear > ? > > Can you share images to process to try to reproduce the dysfunction here ? > > For more technical details, please look in digiKam web site : > > https://www.digikam.org/contribute/ > > Thanks in advance > > Gilles Caulier Hi Gilles, Hugin tells me about my system: Betriebssystem: Windows 10 (build 17763), 64-bit edition Architektur: 64 bit Freier Speicher: 10252272 kiB Aktive Codepage: 1252 (Western European Windows) Hugin Version: 2018.0.0.5abfb4de7961 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\Ulrich Demlehner\AppData\Roaming\hugin\camlens.db Multi-Threading mittels C++11 std::thread und OpenMP Monitorprofile: C:\WINDOWS\system32\spool\drivers\color\GL2250H.icm Bibliotheken wxWidgets: wxWidgets 3.1.1 wxWidgets Library (wxMSW port) Version 3.1.1 (Unicode: wchar_t, debug level: 1), compiled at Nov 18 2017 10:28:15 Runtime version of toolkit used is 10.0. libpano13: 2.9.19 Exiv2: 0.26 SQLite3: 3.18.0 Vigra: 1.11.0 LittleCMS2: 2.9 The log file from MS DebugView is attached to this thread. Sorry, but what do you mean with "DrMinGW backtrace"? Sure, I can share the images if you need them. Just tell me where to upload them (8 files with approx 15 - 20 MB each). Thanks for your support -- Ulrich
Created attachment 122178 [details] Log file from MS DebugView
Git commit 03bb5ec7a6ff6308084bad94fe9576d29c17289e by Maik Qualmann. Committed on 16/08/2019 at 19:05. Pushed by mqualmann into branch 'master'. try it here with a process event M +3 -0 core/dplugins/generic/tools/panorama/wizard/panopreviewpage.cpp https://invent.kde.org/kde/digikam/commit/03bb5ec7a6ff6308084bad94fe9576d29c17289e
(In reply to Maik Qualmann from comment #5) > Git commit 03bb5ec7a6ff6308084bad94fe9576d29c17289e by Maik Qualmann. > Committed on 16/08/2019 at 19:05. > Pushed by mqualmann into branch 'master'. > > try it here with a process event > > M +3 -0 > core/dplugins/generic/tools/panorama/wizard/panopreviewpage.cpp > > https://invent.kde.org/kde/digikam/commit/ > 03bb5ec7a6ff6308084bad94fe9576d29c17289e Hi Maik, I guess this means that I should compile the C++ code your link points to? I'm sorry, I don't have a C++ compiler, I'm only able to work with already compiled code. Please don't forget I'm on Win10. Thanks and best regards -- Ulrich
No, you do not need to compile. This message just says that I made a change. Since I may be able to reproduce the problem only once in 2 months on Linux, I will compile a Windows test version and upload it to my GDrive. Maik
Problem still occurs on a Windows7 machine. After the debug messages, the code could get stuck on the QMutex...we continued... Maik
Git commit afc6d1475d9d55fd57db9c95ad37705613708d0e by Maik Qualmann. Committed on 18/08/2019 at 09:19. Pushed by mqualmann into branch 'master'. fix deadlock from Panorama plugin FIXED-IN: 6.3.0 M +2 -1 NEWS M +1 -1 core/dplugins/generic/tools/panorama/manager/panoactionthread.cpp M +6 -0 core/dplugins/generic/tools/panorama/wizard/panooptimizepage.cpp M +7 -2 core/dplugins/generic/tools/panorama/wizard/panopreprocesspage.cpp M +3 -2 core/dplugins/generic/tools/panorama/wizard/panopreviewpage.cpp https://invent.kde.org/kde/digikam/commit/afc6d1475d9d55fd57db9c95ad37705613708d0e
(In reply to Maik Qualmann from comment #9) > Git commit afc6d1475d9d55fd57db9c95ad37705613708d0e by Maik Qualmann. > Committed on 18/08/2019 at 09:19. > Pushed by mqualmann into branch 'master'. > > fix deadlock from Panorama plugin > FIXED-IN: 6.3.0 > > M +2 -1 NEWS > M +1 -1 > core/dplugins/generic/tools/panorama/manager/panoactionthread.cpp > M +6 -0 > core/dplugins/generic/tools/panorama/wizard/panooptimizepage.cpp > M +7 -2 > core/dplugins/generic/tools/panorama/wizard/panopreprocesspage.cpp > M +3 -2 > core/dplugins/generic/tools/panorama/wizard/panopreviewpage.cpp > > https://invent.kde.org/kde/digikam/commit/ > afc6d1475d9d55fd57db9c95ad37705613708d0e Hi Maik, I guess this means that the problem will be resolved in the upcoming v6.3.0? Any way to test it before the official release? Thanks and best regards -- Ulrich
You can test a current pre-release version of digiKam-6.3.0 (only Win64) from my GDrive. https://drive.google.com/open?id=1G5kbsfTXp8sWVj0qRxdXauBuXcTELisU ---------- Compute package checksums for digiKam 6.3.0-git File : digiKam-6.3.0-git-20190818T132445-Win64.exe Size : 170M MD5 sum : 1e6ad76d6fdde9cf20c2ca0da9509ac6 SHA1 sum : 70a4d11b72bec939bc8d2ee310138abbed16c7c4 SHA256 sum : 302eb8360ba0e4e55a8199229f9151a5b46c063c549f52c2806359a5dc5b4344 Maik
Just for info, I'm back at home next Friday, so i will able to rebuild weekly bundles at this date, not before, as i'm on front of Mont Blanc in French Alps with only a 3G connection... Gilles
(In reply to caulier.gilles from comment #12) > Just for info, > > I'm back at home next Friday, so i will able to rebuild weekly bundles at > this date, not before, as i'm on front of Mont Blanc in French Alps with > only a 3G connection... > > Gilles No problem -- have fun and take care! Ulrich
(In reply to Maik Qualmann from comment #11) > You can test a current pre-release version of digiKam-6.3.0 (only Win64) > from my GDrive. > > https://drive.google.com/open?id=1G5kbsfTXp8sWVj0qRxdXauBuXcTELisU > > > ---------- Compute package checksums for digiKam 6.3.0-git > > File : digiKam-6.3.0-git-20190818T132445-Win64.exe > Size : 170M > MD5 sum : 1e6ad76d6fdde9cf20c2ca0da9509ac6 > SHA1 sum : 70a4d11b72bec939bc8d2ee310138abbed16c7c4 > SHA256 sum : 302eb8360ba0e4e55a8199229f9151a5b46c063c549f52c2806359a5dc5b4344 > > Maik Hi Maik, works fine. The freezing problem is gone. Thanks -- Ulrich
> Hi Maik, > > works fine. The freezing problem is gone. > > Thanks -- Ulrich Hi Maik, I have now some experience with the panorama plugin. It appears to be really stable (I haven't had any crashes or freezes). It does a real good job to correct for perspective issues. I have had a few cases where Hugins and MS ICE were not able to merge pictures correctly, but the plugin has had no problems. Really great stuff! But what I see is that the resulting panoramas lose a lot of the original pictures' sharpness. I could upload some extreme examples if you would like me to do. Best regards -- Ulrich
I performed plenty of Panorama while this summer (French Alps - Mont Blanc) and i cannot reproduce this sharpness problem. I work only with JPEG, not RAW. Perhaps it's your problem here. RAW images can be handled by 3 way : preview (JPEG low resolution), half size decoding, full size decoding. I compare the sharpness result of 3 solutions in bug #409148 with a Sony A7r3 ARW file. Of course this comparison cannot be generalized to all RAW files, as the embedded JPEG preview can be in higher resolution as with NEF files from Nikon. I don't remember yet how Panorama plugin handle RAW data exactly. We must take a look in source code... Gilles Caulier
Panorama tool use the same default RAW decoding options set for the Image Editor. Code relevant is in this function : https://invent.kde.org/kde/digikam/blob/master/core/dplugins/generic/tools/panorama/tasks/preprocesstask.cpp#L180 Gilles Caulier
(In reply to caulier.gilles from comment #17) > Panorama tool use the same default RAW decoding options set for the Image > Editor. Code relevant is in this function : > > https://invent.kde.org/kde/digikam/blob/master/core/dplugins/generic/tools/ > panorama/tasks/preprocesstask.cpp#L180 > > Gilles Caulier I'm working with (HDR) JPEGs, no RAWs at all. I don't see how HDR should influence the sharpness, so I would exclude this at the moment. I have one example that has been done with Hugin (or MS ICE, I'm not sure) and with the panorma plugin using the same starting JPEGs. The Hugin (or MS ICE) result is without any problems, the panorama plugin result is basically useless due to unsharpness. Would you like me to uplaod the pictures? Best regards -- Ulrich
yes, please upload file somewhere in internet sharing files service... Also, i use Hugin 2016.0 here... Gilles Caulier
On another computer, i use also hugin 2019 (all under Linux, not Windows), and all work as expected. I would like also to post process your original files, to try to reproduce the problem here. Thanks in advance Gilles Caulier
(In reply to caulier.gilles from comment #20) > On another computer, i use also hugin 2019 (all under Linux, not Windows), > and all work as expected. > > I would like also to post process your original files, to try to reproduce > the problem here. > > Thanks in advance > Gilles Caulier The files are at https://1drv.ms/u/s!AoQtzCRSrbm6gaVf8-YiK1aK5p0feA?e=JMb0tj. But I have to correct my statements above, sorry for causing some confusion. When I uploaded the files, I checked them with my standard application for pictures (IrfanView 4.52). And was very suprised to see that Irfanview shows them with all the sharpness they should have. Both panoramas (the Hugin and the plugin one) are as sharp as the pictures they are composed from. So the good news is: the plugin does not have a sharpness problem. But if I check the panorams with the "big preview" in DigiKAM (not the thumbnails, but the "big mode" called "Vorschau" in the German translation) which I'm usually doing, both panoramas are displayed with a much lower sharpness. The plugin panorama is displayed even worse compared with the Hugin panorama, and both are displayed much worse than the single pictures. So it appears that the "big preview" in DigiKAM has a problem with the panoramas and that the exact severeness of this problem depends on the way the panorama has been composed. Does that make any sense? Best regards -- Ulrich PS: Sorry again for the confusion -- at least I learned that I will always use two different applications to look at a picture in the future ...;-))
That is clear. The preview shows in the basic settings the internal preview image in the Panarama (speed optimized), which is of course reduced. Go to the digiKam Setup-> View-> Preview tab and choose to show the full image. Maik
(In reply to Maik Qualmann from comment #22) > That is clear. The preview shows in the basic settings the internal preview > image in the Panarama (speed optimized), which is of course reduced. Go to > the digiKam Setup-> View-> Preview tab and choose to show the full image. > > Maik Perfect, Maik, that was the solution! Thanks and sorry again for the confusion. Ulrich