Issues with control point setting GUI showing images as black rectangles

[Kyle Maas]

Hi all,

I'm glad to see this project is still active.  I used Hugin many years
ago and recently started needing it again.

I'm having some issues, however, with setting control points for large
images.  For some background, my main use case is stitching scans
together of antique large format paper engineering drawings where it has
to be captured in pieces and reassembled later due both to the size and
fragility of the paper, not being conducive to being scanned on a roll
scanner.  Since they're so old and the paper has become so fragile, I
try to scan once with the highest resolution I can so they can be put
back into storage, so the images I'm stitching are fairly large, as is
the output.  For example, one image I'm working with is 7584x17760
pixels.  Current project will have about 56 images of a similar size. 
And that's where the problems come in.

When I try to set control points on the larger images, it will show the
image shrunk to fit into the panel of the control point UI.  When I
click and hold the mouse button down, you can see the part of the image
around the cursor, so it's definitely reading the images okay.  But when
I release the mouse and it zooms in, the entire panel displays as black
with the new control point somewhere in the black.  Then if I click a
matching control point in a different image that does not display this
behavior, that image also displays as black, as do all other images
going forward until I restart the program.  Essentially, once you set a
control point on an image that's too big, it's like it locks all images
into only displaying black.  My workaround for this has been to set one
control point in an area where fine tuning is able to find the correct
spot to put it on the second image, since it still detects it just fine
but just doesn't display it, and then once that control point is set,
save the project and relaunch the program.  It severely hampers the
ability to set many control points when you have to restart the program
for every single one.

This problem only happens on larger image sizes, but I have not yet been
able to determine the size threshold this happens at, or whether it's a
single dimension or an area problem.

The version I'm running is 2025.0.1.9609d5726ad8 and it's on Gentoo
Linux, if that helps.  I can't post the problematic images here
(copyright and just plain too darn big), but I am happy to test
suggestions to see if it helps and gather more data.

Thank you!

Warm Regards,
Kyle Maas

[T. Modes]

Hi Kyle,

I can't reproduce this. I tried with 2 big images with 18200x13700 pixels and it worked fine without black rectangles. The images remain visible.

(tested on Windows and Ubuntu).

Have your images icc profiles? Have you install a monitor profile? It is display correctly by Hugin in the About dialog?

Thomas

[Kyle Maas]

Thank you for the reply.  If I open the image in GIMP, it shows it as being "GIMP built-in sRGB" color profile.  If I open the file, rotate it 180 degrees in GIMP (because it is upside down) and save it out from GIMP as a JPEG (same format as the original), to rule out any formatting issues from the scanner, I get the same behavior from the resaved version.

I do not have a monitor profile active as far as I know unless it was a default from XFCE.

I don't know what you mean by whether it displays correctly in the About dialog, since I don't see any information pertaining to specific images in there.

For me, steps to reproduce:

1. Launch Hugin Panorama Creator.

2. Drag rotated image that GIMP exported into Photos, just to make sure it isn't a format issue from the scanner.

3. Set lens to Rectilinear with a 2 degree HFOV.

4. Image shows up in the list.  I can click the image and the thumbnail shows up in the panel at the bottom and displays correctly as if everything is working.

5. I can make it do this with even only one image in the list, so go to Control Points.  Image shows correctly on both sides.

6. Click-and-hold-down on the left side.  Smaller targeting square pops up and shows the chunk of the image around the cursor.  Everything works as normal up to this point.

7. Release mouse.  Left side of the Control Points screen displays entirely black except the yellow "new" tooltip and the zoomed-in targeting square, which still displays correctly.  Right side of Control Points still shows the image, zoomed out.

8. Click in right side in a matching location.  Right side goes black except "new".  Targeting squares on both sides disappear, so now both sides just show "new" and crosshairs.

If I launch hugin from the command line, nothing is logged to stdout or stderr from 5-8.  There is a log message when I first drop in the rotated image because it doesn't have EXIF data ("Unable to read EXIF data from opened file"), but no other load errors.

About System tab (with a few redactions because this list is published to the public - oddly, free memory is lower than it should be - htop shows 124G/188G usage):

Operating System: Linux (redacted) x86_64
Architecture: 64 bit
Free memory: 8932964 kiB

Hugin
Version: 2025.0.1.9609d5726ad8
Path to resources: /usr/share/hugin/xrc/
Path to data: /usr/share/hugin/data/
Hugins camera and lens database: /home/(redacted)/.local/share/hugin/camlens.db
Multi-threading using C++11 std::thread and OpenMP

Libraries
wxWidgets: wxWidgets 3.2.8
wxWidgets Library (wxGTK port)
Version 3.2.8.1 (Unicode: wchar_t, debug level: 1),
compiled at Jul  2 2026 01:52:13

Runtime version of toolkit used is 3.24.52.
Compile-time GTK+ version is 3.24.51.

libpano13: 2.9.23 
Exiv2: 0.28.8
SQLite3: 3.53.1
Vigra: 1.12.2
LittleCMS2: 2.19

Warm Regards,
Kyle Maas

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hugin-ptx/6ef79c62-3db5-48b1-836d-df0dcc68edc1n%40googlegroups.com.

[Gunter K�nigsmann]

I had once black images with a system with the gl viewer and very little video ram...

[Kyle Maas]

This gave me the idea to watch amdgpu_top while doing this.  I had about 3GB of VRAM available on my video card before adding an image.  VRAM usage only climbed slightly when I went into the Control Point editor and it turned black.  There was still almost 3GB of VRAM available when the problem occurred.  Usage seems to be nearly identical to an image that works.

Also, the problem I'm describing is not in the OpenGL Panorama Preview window - this is in the Control Point editor.  I hadn't even really paid attention to that, but the OpenGL Panorama Preview window still shows the image even after the Control Point editor goes black, at least for my test case of one image.  I have had it display black rectangles in place of images in the OpenGL Panorama Preview window before, although I did not take note of the circumstances so I don't know how to duplicate that part.  The only part I can definitively duplicate reliably is the Control Point editor going black, and it appear that that doesn't crash the preview.

Warm Regards,
Kyle Maas

To view this discussion visit https://groups.google.com/d/msgid/hugin-ptx/477CCBB8-E9C7-4444-A18D-70C7DCCB3814%40gmail.com.

[Claudio Rocha]

Black rectangles sounds to me like corruption on the GPU. Maybe the images exceed the computer resources, or the GPU might be failing. I've never dealt with 17K images. I would try with smaller chunks and see if that helps. In the past when dealing with scanned maps (that are scanned at high dpi and yield huge files), I break them in smaller chunks before stiching. Do a test and find what is the size limit that your computer can deal with.

[Kyle Maas]

Smaller images definitely do work, and I have split images before so Hugin could read them without the black rectangle issue.  But when dealing with many images, that becomes quite burdensome.

On one example of a recent project, out of a project with 56 images (which is only about 2/3 complete so far), I had 54 images which did not display this behavior, the largest of them being 7584x17424.  Image #44 displays the black rectangle problem and is 7584x17952, and image #55 also has this problem and is 7584x17856.  So the limit seems to be somewhere in that range - 7584x17424 to 7584x17856.  The height's not over a power-of-two boundary, but that would be just over 400MB of data with 24-bit RGB, so maybe there's a hard-coded 400MB limit somewhere?

Warm Regards,
Kyle Maas

To view this discussion visit https://groups.google.com/d/msgid/hugin-ptx/b93a745c-327b-419b-bc4b-103e7f4cbe03n%40googlegroups.com.

[Claudio Rocha]

If you have access to a computer with more vram on the GPU make a test there.  

[Kyle Maas]

I don't have a more capable machine available.  This one already has two graphics cards totalling 32GB of VRAM with 192GB of system RAM (from before the great RAM crunch).

However, reading through the code, I didn't realize how much of the interface was just base wxWidgets functionality, and I think I may have found the culprit:

https://github.com/wxWidgets/wxWidgets/issues/25656

It's fixed in newer versions of wxWidgets, but Gentoo Linux doesn't have that version available yet.  So I may need to custom compile.

Warm Regards,
Kyle Maas

To view this discussion visit https://groups.google.com/d/msgid/hugin-ptx/006b4d7f-510b-47ea-b760-a10b77bee370n%40googlegroups.com.

[Kyle Maas]

Huh.  The new fixed version of wxWidgets was only released about 6 hours ago.  No wonder it's not in Gentoo's Portage repo yet.

Warm Regards,
Kyle Maas

[Kyle Maas]

Tried it with a custom compiled version of wxWidgets 3.2.11, and the problem is fixed with the same images as before.  So it was definitely an upstream wxWidgets problem and not a Hugin problem.  I'm sure it will eventually make its way into Gentoo, but it might not for other non-rolling-release distros, so this may pop up again for other users.  Sorry to bother you, but hopefully this will help with troubleshooting if someone else has this problem in the future.

Warm Regards,
Kyle Maas