Re: [Hugin-devs] [Bug 840677] Re: Fast Panorama Window always opens with Overview mode shown
The freezing FPW is fixed for me, but I cannot comment on hugin respecting the overview_hidden=1 preference. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/840677 Title: Fast Panorama Window always opens with Overview mode shown Status in Hugin - Panorama Tools GUI: Incomplete Bug description: Hugin 5543:5ae90ab6bbbd just built on Fedora 15 x86_64. my .hugin file has 'overview_hidden=1', but FPW always opens with overview mode shown. As my system seems to be very sensitive to the FPW bug, this has made this build unusable. Every project thus far, FPW opens and is frozen, trying to close FPW crashes hugin. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/840677/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
Re: [Hugin-devs] [Bug 792896] Re: Fast Preview Hangs or Crashes since 2011.0
Trying with 5584:9d07d4165d4 improves the situation dramatically. On a machine where hugin was freezing immediately when opening the FPW, it seems to be very stable now. I have been able to crash it only ones by clicking the FPW icon quickly after startup when it segfaulted. Have not been able to reproduce. There is one strange behaviour which I have not noticed yet: The overview only shows a black sphere when photometric correction is enabled. Disabling this AND clicking and dragging in the overview window updates the display and the panorama is visible again. Should I file as a new bug? -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/792896 Title: Fast Preview Hangs or Crashes since 2011.0 Status in Hugin - Panorama Tools GUI: Confirmed Bug description: EDIT (August 6, 2011): summarized known information *WORKAROUND FOR USERS*: disable the Overview 1- start Hugin 2- load a project 3- go to the Fast Preview Window. don't touch anything else but described below as this could trigger the bug 4- hit the button Show/Hide to hide the Overview 5- quit Hugin Now Hugin should perform well. *AFFECTED SYSTEMS* - CPU: all systems with more than one thread, that is multi-core CPUs as well as single-core CPUs with hyperthreading. - Operating Systems: due to the different implementations of threading and OpenGL on different platform, some systems are more prone to error than others. Mac OS X seems to be the least affected. Windows seems to be the most affected. *AFFECTED VERSIONS* - All versions of Hugin since the introduction of the Overview in the Fast Preview are affected. That is, all versions after revision 4808:8c577b320714 2011-01-09 12:21:18 - This includes the final releases of 2011.0.0 as well as all beta/candidate releases of 2011.2.0 *SUMMARY FOR DEVELOPERS / BUG HUNTERS* This is most likely a threading issue. Lukáš' hypothesis: a race condition in OpenGL calls, when OGL is called by separate threads from both overview and fast preview. The reason is that OpenGL is not thread-safe and it can cause various problems when used within multi- threaded application. Run 'valgrind --tool=helgrind hugin' and try to reproduce the error to produce a useful backtrace like https://bugs.launchpad.net/hugin/+bug/792896/+attachment/2253077/+files /valgrind-out.txt *ORIGINAL BUG REPORT BELOW FOR COMPLETION:* Upgraded from 2010.4 to 2011.0.0 and it has hung 3 times in about 15 sessions. All three hangs happened while doing the same thing. new session, load images, load a lens profile, set the canvas size (Calculate optimal size), save-as and save profile then click on GL (fast preview) button. Fast preview window comes up, shows anchor image and then hangs. Is not reproducible. Running 2011.0.0.0fd3e119979c built by Matthew Petroff on 64-bit Win7. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/792896/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 854181] [NEW] Overview mode shows black sphere when photometric correction is active
Public bug reported: Using rev. 5584:9d07d4165d4 the sphere in the overview window is rendered in solid black when the Photometrics check box is activated. At the same time the equirectangular view shows the images with normal brightness, the project has been exposure optimized at the point when this was observed. Also deactivated the check box is not enough to restore the overview rendering, but one needs to click and drag the sphere in order to force a render update. ** Affects: hugin Importance: Low Status: New ** Tags: fpw mode overview ** Changed in: hugin Importance: Undecided = Low -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/854181 Title: Overview mode shows black sphere when photometric correction is active Status in Hugin - Panorama Tools GUI: New Bug description: Using rev. 5584:9d07d4165d4 the sphere in the overview window is rendered in solid black when the Photometrics check box is activated. At the same time the equirectangular view shows the images with normal brightness, the project has been exposure optimized at the point when this was observed. Also deactivated the check box is not enough to restore the overview rendering, but one needs to click and drag the sphere in order to force a render update. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/854181/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 766501] Re: Enblend treats larger input tif as black with --fine-mask
This problem has now appeared for me for a few different panoramas, independent of the use of --fine-mask. Funny enough scaling the output images down has helped with one while with another one scaling up was avoiding the black spots. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/766501 Title: Enblend treats larger input tif as black with --fine-mask Status in Enblend: Confirmed Bug description: Blending two input tiff files (remapped files from hugin) with enblend results in one image treated as solid black during blending if: (a) --fine-mask is used, and (b) the input image size is large enough (here: 9000px high triggers the bug, 8000px and below is ok). The attached images illustrate the problem: 2 input files (input.tif and input0002.tif) and two output files, one with --fine-mask (bad_finemask_9000x4500.tif) and one without (good_nofinemask_9000x4500.tif). Unfortunately those are images reduced to a width of 2000px from an original width of 9000px. If needed I can provide the quite large originals as well. Version has been pulled yesterday: enblend 4.1-2f3c9caab556. Compilation was without OpenMP, trying with or without imagecache does not make a difference. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/766501/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
Re: [Hugin-devs] [Bug 718116] Re: Opening Fast Preview Window crashes Hugin
Tested on openSUSE 11.3 and 11.4 with boost 1.42, 1.44, 1.46. Can anybody test other systems? I'm not too sure what I'm testing here, but: $ ./button_click OK! $ Tested on Debian testing, boost 1.46 Fast preview has not been crashing for me for a long time now. Hope this helpss, Felix -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/718116 Title: Opening Fast Preview Window crashes Hugin Status in Hugin - Panorama Tools GUI: Confirmed Bug description: Whenever I open the FPW, Hugin segfaults. I've attached the full backtrace of the segfault triggered by manually opening the FPW, but here are the top 19 lines (of 62): #0 0x00f7eae1 in wxWindow::DoSetSize(int, int, int, int, int) () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #1 0x01072584 in wxSizerItem::SetDimension(wxPoint const, wxSize const) () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #2 0x01072f6b in wxGridSizer::SetItemBounds(wxSizerItem*, int, int, int, int) () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #3 0x010740ff in wxFlexGridSizer::RecalcSizes() () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #4 0x010722d4 in wxSizer::Layout() () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #5 0x01072409 in wxSizer::SetDimension(int, int, int, int) () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #6 0x010725c1 in wxSizerItem::SetDimension(wxPoint const, wxSize const) () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #7 0x01073512 in wxBoxSizer::RecalcSizes() () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #8 0x010722d4 in wxSizer::Layout() () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #9 0x01072409 in wxSizer::SetDimension(int, int, int, int) () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #10 0x01084f55 in wxWindowBase::Layout() () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #11 0x0107ee45 in wxTopLevelWindowBase::DoLayout() () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #12 0x0107fd2d in wxTopLevelWindowBase::OnSize(wxSizeEvent) () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #13 0x00d3dc2f in wxAppConsole::HandleEvent(wxEvtHandler*, void (wxEvtHandler::*)(wxEvent), wxEvent) const () from /usr/lib/libwx_baseu-2.8.so.0 #14 0x00ddc089 in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const, wxEvtHandler*, wxEvent) () from /usr/lib/libwx_baseu-2.8.so.0 #15 0x00ddd134 in wxEventHashTable::HandleEvent(wxEvent, wxEvtHandler*) () from /usr/lib/libwx_baseu-2.8.so.0 #16 0x00ddd233 in wxEvtHandler::ProcessEvent(wxEvent) () from /usr/lib/libwx_baseu-2.8.so.0 #17 0x00fcaf65 in wxFrame::GtkOnSize() () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #18 0x00f73e03 in wxTopLevelWindowGTK::Show(bool) () from /usr/lib/libwx_gtk2u_core-2.8.so.0 #19 0x080bb5f1 in MainFrame::OnToggleGLPreviewFrame(wxCommandEvent) () Running Ubuntu Maverick on an Intel DG45ID mobo with the G45 chipset and builtin GMA X4500HD GPU About→System says: Operating System: Linux 2.6.35-25-generic i686 Architecture: 32 bit Free memory: -1738088 kiB Hugin Version: 2010.4.0.854952d82c8f Path to ressources: /usr/share/hugin/xrc/ Path to data: /usr/share/hugin/data/ To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/718116/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 823823] Re: mask tab:images become white
Confirmed for 2011.3.0.b7f778d81beb on Linux. ** Changed in: hugin Status: New = Confirmed -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/823823 Title: mask tab:images become white Status in Hugin - Panorama Tools GUI: Confirmed Bug description: Hugin 2011.2.0-rc2_32bit on Windows Vista. In the Mask tab, after changing the image scale to 100%, the images lose contrast and/or saturation each time I switch images, until the images become almost entirely gray. A workaround is exiting Hugin and reloading the project, but the same issue then starts again as soon as I choose 100% scale. This problem does not appear in other scales (I tested all of them, 25%, 50%, 150% and 200%) but once Hugin starts graying the picture, changing the scale won't correct the contrast, the only way I could find is exiting Hugin entirely. Another workaround is never using 100% and using 75% or 150% instead. I tested 2 projects and both had the same issue. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/823823/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 785803] Re: Enblend --no-optimize produces black holes into panoramas
If I remove the --fine-mask option and process the pto with dummy images I can reproduce the problem in each of the 5 exposures. ** Changed in: enblend Status: New = Confirmed -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/785803 Title: Enblend --no-optimize produces black holes into panoramas Status in Enblend: Confirmed 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. ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 785803] Re: Enblend --no-optimize produces black holes into panoramas
I am moving this to the enblend bug tracker. ** Project changed: hugin = enblend -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/785803 Title: Enblend --no-optimize produces black holes into panoramas Status in Enblend: New 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. ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 766501] Re: Enblend treats larger input tif as black with --fine-mask
** Attachment added: Result using --fine-mask https://bugs.launchpad.net/enblend/+bug/766501/+attachment/2126106/+files/test_result.tif -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/766501 Title: Enblend treats larger input tif as black with --fine-mask Status in Enblend: New Bug description: Blending two input tiff files (remapped files from hugin) with enblend results in one image treated as solid black during blending if: (a) --fine-mask is used, and (b) the input image size is large enough (here: 9000px high triggers the bug, 8000px and below is ok). The attached images illustrate the problem: 2 input files (input.tif and input0002.tif) and two output files, one with --fine-mask (bad_finemask_9000x4500.tif) and one without (good_nofinemask_9000x4500.tif). Unfortunately those are images reduced to a width of 2000px from an original width of 9000px. If needed I can provide the quite large originals as well. Version has been pulled yesterday: enblend 4.1-2f3c9caab556. Compilation was without OpenMP, trying with or without imagecache does not make a difference. ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 766501] Re: Enblend treats larger input tif as black with --fine-mask
Today I have had that problem occur again processing a different image set. But this time it appeared on a 6 core i7 with roughly 6GB free RAM running a 64bit Linux. So this is probably not a memory problem. Again the problem vanished when dropping --fine-mask. ** Attachment added: Two input files that show the problem https://bugs.launchpad.net/enblend/+bug/766501/+attachment/2126105/+files/input_files.zip -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/766501 Title: Enblend treats larger input tif as black with --fine-mask Status in Enblend: New Bug description: Blending two input tiff files (remapped files from hugin) with enblend results in one image treated as solid black during blending if: (a) --fine-mask is used, and (b) the input image size is large enough (here: 9000px high triggers the bug, 8000px and below is ok). The attached images illustrate the problem: 2 input files (input.tif and input0002.tif) and two output files, one with --fine-mask (bad_finemask_9000x4500.tif) and one without (good_nofinemask_9000x4500.tif). Unfortunately those are images reduced to a width of 2000px from an original width of 9000px. If needed I can provide the quite large originals as well. Version has been pulled yesterday: enblend 4.1-2f3c9caab556. Compilation was without OpenMP, trying with or without imagecache does not make a difference. ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
Re: [Hugin-devs] [Bug 766501] Re: Enblend treats larger input tif as black with --fine-mask
what are the specs of the machine that produces the black areas? What was a very nice laptop back in 2004: Pentium M 1.7 GHz with 2GB RAM. Enblend might run out of memory, but shouldn't it fail/crash then instead of producing bogus output? It's easy to see in this 2 image case, but when blending a spherical pano and getting some strange grey/black smearing I was searching for the reason for what felt like eternity... :-) -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/766501 Title: Enblend treats larger input tif as black with --fine-mask Status in Enblend: New Bug description: Blending two input tiff files (remapped files from hugin) with enblend results in one image treated as solid black during blending if: (a) --fine-mask is used, and (b) the input image size is large enough (here: 9000px high triggers the bug, 8000px and below is ok). The attached images illustrate the problem: 2 input files (input.tif and input0002.tif) and two output files, one with --fine-mask (bad_finemask_9000x4500.tif) and one without (good_nofinemask_9000x4500.tif). Unfortunately those are images reduced to a width of 2000px from an original width of 9000px. If needed I can provide the quite large originals as well. Version has been pulled yesterday: enblend 4.1-2f3c9caab556. Compilation was without OpenMP, trying with or without imagecache does not make a difference. ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 766501] Re: Enblend treats larger input tif as black with --fine-mask
I could just reproduce the problem with enblend 4.1-2f3c9caab556 and the attached original size files. I hope this 50MB attachment does make its way to launchpad. Felix ** Attachment added: Original size images demonstrating the problem https://bugs.launchpad.net/enblend/+bug/766501/+attachment/2110089/+files/test_enblend_finemask.zip -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/766501 Title: Enblend treats larger input tif as black with --fine-mask Status in Enblend: New Bug description: Blending two input tiff files (remapped files from hugin) with enblend results in one image treated as solid black during blending if: (a) --fine-mask is used, and (b) the input image size is large enough (here: 9000px high triggers the bug, 8000px and below is ok). The attached images illustrate the problem: 2 input files (input.tif and input0002.tif) and two output files, one with --fine-mask (bad_finemask_9000x4500.tif) and one without (good_nofinemask_9000x4500.tif). Unfortunately those are images reduced to a width of 2000px from an original width of 9000px. If needed I can provide the quite large originals as well. Version has been pulled yesterday: enblend 4.1-2f3c9caab556. Compilation was without OpenMP, trying with or without imagecache does not make a difference. ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 766501] [NEW] Enblend treats larger input tif as black with --fine-mask
Public bug reported: Blending two input tiff files (remapped files from hugin) with enblend results in one image treated as solid black during blending if: (a) --fine-mask is used, and (b) the input image size is large enough (here: 9000px high triggers the bug, 8000px and below is ok). The attached images illustrate the problem: 2 input files (input.tif and input0002.tif) and two output files, one with --fine-mask (bad_finemask_9000x4500.tif) and one without (good_nofinemask_9000x4500.tif). Unfortunately those are images reduced to a width of 2000px from an original width of 9000px. If needed I can provide the quite large originals as well. Version has been pulled yesterday: enblend 4.1-2f3c9caab556. Compilation was without OpenMP, trying with or without imagecache does not make a difference. ** Affects: enblend Importance: Undecided Status: New -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/766501 Title: Enblend treats larger input tif as black with --fine-mask Status in Enblend: New Bug description: Blending two input tiff files (remapped files from hugin) with enblend results in one image treated as solid black during blending if: (a) --fine-mask is used, and (b) the input image size is large enough (here: 9000px high triggers the bug, 8000px and below is ok). The attached images illustrate the problem: 2 input files (input.tif and input0002.tif) and two output files, one with --fine-mask (bad_finemask_9000x4500.tif) and one without (good_nofinemask_9000x4500.tif). Unfortunately those are images reduced to a width of 2000px from an original width of 9000px. If needed I can provide the quite large originals as well. Version has been pulled yesterday: enblend 4.1-2f3c9caab556. Compilation was without OpenMP, trying with or without imagecache does not make a difference. ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 766501] Re: Enblend treats larger input tif as black with --fine-mask
** Attachment added: Zip containing the files showing the bug https://bugs.launchpad.net/bugs/766501/+attachment/2069531/+files/images.zip -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/766501 Title: Enblend treats larger input tif as black with --fine-mask Status in Enblend: New Bug description: Blending two input tiff files (remapped files from hugin) with enblend results in one image treated as solid black during blending if: (a) --fine-mask is used, and (b) the input image size is large enough (here: 9000px high triggers the bug, 8000px and below is ok). The attached images illustrate the problem: 2 input files (input.tif and input0002.tif) and two output files, one with --fine-mask (bad_finemask_9000x4500.tif) and one without (good_nofinemask_9000x4500.tif). Unfortunately those are images reduced to a width of 2000px from an original width of 9000px. If needed I can provide the quite large originals as well. Version has been pulled yesterday: enblend 4.1-2f3c9caab556. Compilation was without OpenMP, trying with or without imagecache does not make a difference. ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 766501] Re: Enblend treats larger input tif as black with --fine-mask
** Description changed: Blending two input tiff files (remapped files from hugin) with enblend results in one image treated as solid black during blending if: (a) --fine-mask is used, and (b) the input image size is large enough (here: 9000px high triggers the bug, 8000px and below is ok). The attached images illustrate the problem: 2 input files (input.tif and input0002.tif) and two output files, one with --fine-mask (bad_finemask_9000x4500.tif) and one without (good_nofinemask_9000x4500.tif). Unfortunately those are images reduced to a width of 2000px from an original width of 9000px. If needed I can provide the quite large originals as well. Version has been pulled yesterday: enblend 4.1-2f3c9caab556. Compilation - without OpenMP, with or without imagecache does not make a difference. + was without OpenMP, trying with or without imagecache does not make a + difference. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/766501 Title: Enblend treats larger input tif as black with --fine-mask Status in Enblend: New Bug description: Blending two input tiff files (remapped files from hugin) with enblend results in one image treated as solid black during blending if: (a) --fine-mask is used, and (b) the input image size is large enough (here: 9000px high triggers the bug, 8000px and below is ok). The attached images illustrate the problem: 2 input files (input.tif and input0002.tif) and two output files, one with --fine-mask (bad_finemask_9000x4500.tif) and one without (good_nofinemask_9000x4500.tif). Unfortunately those are images reduced to a width of 2000px from an original width of 9000px. If needed I can provide the quite large originals as well. Version has been pulled yesterday: enblend 4.1-2f3c9caab556. Compilation was without OpenMP, trying with or without imagecache does not make a difference. ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 726186] Re: Panosphere is drawn above the images
Some problem with dark overview here with linux. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/726186 Title: Panosphere is drawn above the images Status in Hugin - Panorama Tools GUI: New Bug description: The new transparent panosphere is drawn above the images which appear now darker. ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 708294] Re: Random crashes and extreme memory use with overview mode
Yes, it's still the same message that appears (modulo the typo you fixed). Apart from that there are a lot of the usual CacheEntry: and Image: lines but nothing more. BTW: Couldn't we disable all the Cache messages by default? They just make it very hard to find real error/debug messages without any added benefit. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/708294 Title: Random crashes and extreme memory use with overview mode Status in Hugin - Panorama Tools GUI: New Bug description: Since the merge of the panorama overview branch into default hugin is suddenly very unstable and memory hungry. After using the FPW for a while and going forth and back between optimizing and looking at the FPW, hugin uses more than 1.5Gb memory, which is a lot more than before the merge. This is with a fairly small project of 6 Mpix images covering the full sphere and happens with the overview tab hidden as well. On the terminal hugin prints debug messages like this: ERROR: 21:20:02.993563 (/home/flixh/install/pano/hugin/src/hugin1/hugin/ProjectionGridTool.cpp:469) createTexture(): GL Error when bulding mipmap levels: invalid value. When crashing: terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Looks like it's running out of memory? Should not happen on a machine with 2Gb RAM and 3Gb of swap, especially when I never saw that behaviour before. System: Hugin 2010.5.0.1fc6ad6e7c7a Linux system running Debian testing Regards Felix ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 708294] Re: Random crashes and extreme memory use with overview mode
This commit improves the memory usage quite a lot. It does not solve the problem completely as RAM usage is still increasing continiously when using the FPW (same project 1.5 GB after playing for 20 mins), though a lot slower than before. More memory leaks? -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/708294 Title: Random crashes and extreme memory use with overview mode Status in Hugin - Panorama Tools GUI: New Bug description: Since the merge of the panorama overview branch into default hugin is suddenly very unstable and memory hungry. After using the FPW for a while and going forth and back between optimizing and looking at the FPW, hugin uses more than 1.5Gb memory, which is a lot more than before the merge. This is with a fairly small project of 6 Mpix images covering the full sphere and happens with the overview tab hidden as well. On the terminal hugin prints debug messages like this: ERROR: 21:20:02.993563 (/home/flixh/install/pano/hugin/src/hugin1/hugin/ProjectionGridTool.cpp:469) createTexture(): GL Error when bulding mipmap levels: invalid value. When crashing: terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Looks like it's running out of memory? Should not happen on a machine with 2Gb RAM and 3Gb of swap, especially when I never saw that behaviour before. System: Hugin 2010.5.0.1fc6ad6e7c7a Linux system running Debian testing Regards Felix ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 708294] [NEW] Random crashes and extreme memory use with overview mode
Public bug reported: Since the merge of the panorama overview branch into default hugin is suddenly very unstable and memory hungry. After using the FPW for a while and going forth and back between optimizing and looking at the FPW, hugin uses more than 1.5Gb memory, which is a lot more than before the merge. This is with a fairly small project of 6 Mpix images covering the full sphere and happens with the overview tab hidden as well. On the terminal hugin prints debug messages like this: ERROR: 21:20:02.993563 (/home/flixh/install/pano/hugin/src/hugin1/hugin/ProjectionGridTool.cpp:469) createTexture(): GL Error when bulding mipmap levels: invalid value. When crashing: terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Looks like it's running out of memory? Should not happen on a machine with 2Gb RAM and 3Gb of swap, especially when I never saw that behaviour before. System: Hugin 2010.5.0.1fc6ad6e7c7a Linux system running Debian testing Regards Felix ** Affects: hugin Importance: Undecided Status: New -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/708294 Title: Random crashes and extreme memory use with overview mode Status in Hugin - Panorama Tools GUI: New Bug description: Since the merge of the panorama overview branch into default hugin is suddenly very unstable and memory hungry. After using the FPW for a while and going forth and back between optimizing and looking at the FPW, hugin uses more than 1.5Gb memory, which is a lot more than before the merge. This is with a fairly small project of 6 Mpix images covering the full sphere and happens with the overview tab hidden as well. On the terminal hugin prints debug messages like this: ERROR: 21:20:02.993563 (/home/flixh/install/pano/hugin/src/hugin1/hugin/ProjectionGridTool.cpp:469) createTexture(): GL Error when bulding mipmap levels: invalid value. When crashing: terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Looks like it's running out of memory? Should not happen on a machine with 2Gb RAM and 3Gb of swap, especially when I never saw that behaviour before. System: Hugin 2010.5.0.1fc6ad6e7c7a Linux system running Debian testing Regards Felix ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 685959] Re: create source images from PTO file.
ptodummy is a perl cript that does exactly this:http://search.cpan.org/dist/Panotools-Script/bin/ptodummy. It is a part of the Panotools::Script collection of useful perl scripts. I don't think such a specialized bug analysis tools needs to be implemented within hugin itself, therefore setting to Fix released. ** Changed in: hugin Status: Triaged = Fix Released -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/685959 Title: create source images from PTO file. Status in Hugin - Panorama Tools GUI: Fix Released Bug description: For bughunting it would be very useful if I can easily create a sample set of images that for most purposes would be useful as test-case images if a reporter only submits a PTO file. for each image in the PTO file, generate an image (with the name of the image in the pixels) of the specified size and type ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 685582] Re: enblend wrong lib extension
This looks a lot like a packaging problem. Where did you get your hugin from? -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/685582 Title: enblend wrong lib extension Status in Hugin - Panorama Tools GUI: Confirmed Bug description: When trying to stitch some photos, I kept getting errors similar to the following: enblend --compression=LZW -f3000x1500 -o PICT0828-PICT0832.tif PICT0828-PICT0832.tif PICT0828-PICT08320001.tif PICT0828-PICT08320002.tif PICT0828-PICT08320003.tif PICT0828-PICT08320004.tif enblend: error while loading shared libraries: libImath.so.2: cannot open shared object file: No such file or directory make: *** [PICT0828-PICT0832.tif] Error 127 To fix the issue I made a symbolic link to the lib as follows: sudo ln -s /usr/lib/libIlmImf.so.6.0.0 /usr/lib/libIlmImf.so.2 sudo ln -s /usr/lib/libImath.so.6.0.0 /usr/lib/libImath.so.2 sudo ln -s /usr/lib/libHalf.so.6.0.0 /usr/lib/libHalf.so.2 sudo ln -s /usr/lib/libIex.so.6.0.0 /usr/lib/libIex.so.2 Machine is running Lucid. Also attached one of the Hugin logs. ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 679398] Re: autopano-sift-c crashes with very wide photos
With a current snapshot this happens as well. Occurs with portait images of 2920x4386 when going from 199 degrees to 200 degrees fov. I have spend a bit of time trying to hunt this bug down. Preliminary result: 1. During image remapping in saRemap.c, saRemap_new(...) x[i] in this line y[i] = CamLens_RofA( pd, CamLens_AofR( ps, x[i] ) ) becomes Pi. 2. Therefore the calls to CamLens_RofA( pd, CamLens_AofR( ps, x[i] ) ) (itself calling a2r_ster which calculates tan(0.5 * x[i] ) returns a negative value for y[i]. 3. The negative value for y[i] makes the monoticity test of the following spline evaluation fail, making the whole saRemap_new return 0 and autopano-sift-c segfault when saRemap_inv tries to dereference the null pointer. Questions: A comment in CamLens.c indicates that A (or x[i] in the above) should be Pi for stereographic projection. Does this make sense? How did we end up with it being greater? Why does this trigger at fov 199 in portrait and 225 in landscape? Should we just remap all x pi to x = pi to get rid of the problem? Sorry for the chaotic braindump above, I need to go to sleep now and need to write the stuff down, otherwise a start from scratch is needed when I'm looking at the problem again. Regards Felix -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/679398 Title: autopano-sift-c crashes with very wide photos Status in Hugin - Panorama Tools GUI: Triaged Bug description: With autopano-sift-C 2.5.1 An 8mm fisheye on a full size sensor produces a landscape orientation photo with an angle of view of 260 degrees, calling apsc like this results in no features identified and a segfault: autopano-sift-c --projection 2,260 output.pto *.JPG The transition is sudden: 223, 224, 225 degrees are fine and hundreds of features are detected. 226 degrees and above and 0 features are detected and matching produces a segfault. ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
