Hugin crash for large input image

[John Eklund]

I'm trying to stitch two large input images (27333 * 29633 and 27071 * 17489 pixels, respectively), and Hugin 2015.0 as well as 2017.0 crashes when I try to interact with the larger image, for example when going to the control points tab and selecting the image. Any ideas? (Stitching an old and new map).

[T. Modes]

Am Freitag, 21. Juli 2017 00:30:25 UTC+2 schrieb John Eklund:

I'm trying to stitch two large input images (27333 * 29633 and 27071 * 17489 pixels, respectively), and Hugin 2015.0 as well as 2017.0 crashes when I try to interact with the larger image, for example when going to the control points tab and selecting the image. Any ideas?

Probably set the zoom factor to >100 %?
The controls in the GUI can only display images up to 32767x32767 - inclusive the zoom factor. (The command line tools should also work with bigger images, but the window controls are limited to this size.)

[John Eklund]

No, it crashes even with zoom factor 100% or below.

The 32767x32767 limit you mention should manifest itself with images of 16384 pixels in either direction, when using a zoom fator of 200% - and it does, displaying a blank image. So that seems not to be the issue here.

[mh00h]

You could try using command line tools directly?

https://wiki.panotools.org/Panorama_scripting_in_a_nutshell 

Feel free to PM me if you need help with this.

[John Eklund]

I already solved it by cutting the images in two. I was just meaning to report a bug, hoping the developers read. And the bug remains.
I'm on Windows 7 by the way.

I regularly use some of the command line tools. In this case I was stitching an old map with a new map and had to create control points manually.

[T. Modes]

Am Mittwoch, 2. August 2017 02:31:06 UTC+2 schrieb John Eklund:

I already solved it by cutting the images in two. I was just meaning to report a bug, hoping the developers read. And the bug remains.

I have read it. But I can't reproduce it.
And the stack trace indicates that it crashes in wxImage::ResampleNearest + wxImage::Scale. But this does not match your statement that it crashes at 100 % scale, because at 100 % scale wxImage::Scale is not called. So with this conflicting statement I can't do more at the moment.

[John Eklund]

It seems a bit unpredictable. Sometimes it does not crash immediately. I tried a couple of scenarios (both starting from a fresh started empty Hugin project)

Use case 1:

1. Added problematic large image (27333 * 29633).
2. Went to Control Point tab. (Zoom pre-set to "Fit to window"). Crash! Dump included.

Use case 2:

1. Added smaller image (22287 * 16000).
2. Went to Control Point tab. Set zoom 50%.
3. Added problematic large image (27333 * 29633).
4. Went to Control Point tab. Changed zoom to 75%. Still works but the bottom ~ 1/7 of the image is garbled (see image).
5. Changed to 100%. Crash! In this case the crash handler doesn't catch it so I got no dump. (Repeated this twice with the same result).

[John Eklund]

Use case 3: (started fresh with empty project)

1. Added smaller image (22287 * 16000).
2. Went to Control Point tab. Set zoom 50%.

3. File --> New project (just to get zoom to remain at 50%).
4. Added problematic large image (27333 * 29633).
5. Went to Control Point tab (Zoom still at 50%). No image visible, only grey / white background.
6. Change zoom to 75%. Crash! Dump included.

[T. Modes]

Am Donnerstag, 3. August 2017 22:39:52 UTC+2 schrieb John Eklund:

Use case 3: (started fresh with empty project)

1. Added smaller image (22287 * 16000).
2. Went to Control Point tab. Set zoom 50%.
3. File --> New project (just to get zoom to remain at 50%).
4. Added problematic large image (27333 * 29633).
5. Went to Control Point tab (Zoom still at 50%). No image visible, only grey / white background.
6. Change zoom to 75%. Crash! Dump included.

All stack traces show the crash in a wxWidgets function (wxImage::ResampleNearest called from wxImage::Scale).
I will investigate this further (but it will take some time and in the next days I have no spare time.)