ai-collab/bulk-image-organizer

Fork 0

[Bug]: 42,895 Pixel High Image Not Rendering in Image Viewer #117

New issue

Closed

opened 2026-06-22 00:05:06 +00:00 by ValleyGeek · 2 comments

ValleyGeek commented

2026-06-22 00:05:06 +00:00

Owner

App version

0.1.56 Beta

Platform

Windows

Steps to reproduce

Open a directory with an image that's 42,895 pixels high (1,569 wide in my instance) and attempt to open it in the image viewer.

Expected behavior

The image is displayed

Actual behavior

The image is not drawn, either the last viewed or first image in gallery is displayed instead. The duplicate multi-view has a blank canvas.

Additional context

No response

### App version 0.1.56 Beta ### Platform Windows ### Steps to reproduce Open a directory with an image that's 42,895 pixels high (1,569 wide in my instance) and attempt to open it in the image viewer. ### Expected behavior The image is displayed ### Actual behavior The image is not drawn, either the last viewed or first image in gallery is displayed instead. The duplicate multi-view has a blank canvas. ### Additional context _No response_

ValleyGeek added the

Kind/Bug

Priority/Medium

labels

2026-06-22 00:05:06 +00:00

Claude referenced this issue from a commit

2026-06-23 23:57:12 +00:00

fix(viewer): raise Qt image allocation limit so tall/large images load (#117)

Claude commented

2026-06-23 23:57:47 +00:00

Member

Root cause: QImage(path) implicitly loads through QImageReader with Qt's default 256 MB allocation limit before our viewer downscaling runs. A 1569x42895 image needs ~256.7 MB at 4 bytes/pixel — just over that limit — so Qt silently returns a null QImage (no exception, isNull() just returns True). That's why the viewer kept showing the previously-loaded image instead of an error, and the duplicate multi-view rendered a blank canvas.

Fix (pushed to 0.2.1/issue-117-tall-image-not-rendering): ViewerImageLoader now loads via QImageReader directly and raises the allocation limit to 1024 MB before reading, so the existing downscale-to-2048px logic still applies normally afterward. Added a regression test that reproduces the exact failing dimensions and confirms the load now succeeds and downscales correctly.

Will request a PR to main when ready.

Root cause: `QImage(path)` implicitly loads through `QImageReader` with Qt's default 256 MB allocation limit *before* our viewer downscaling runs. A 1569x42895 image needs ~256.7 MB at 4 bytes/pixel — just over that limit — so Qt silently returns a null `QImage` (no exception, `isNull()` just returns `True`). That's why the viewer kept showing the previously-loaded image instead of an error, and the duplicate multi-view rendered a blank canvas. Fix (pushed to `0.2.1/issue-117-tall-image-not-rendering`): `ViewerImageLoader` now loads via `QImageReader` directly and raises the allocation limit to 1024 MB before reading, so the existing downscale-to-2048px logic still applies normally afterward. Added a regression test that reproduces the exact failing dimensions and confirms the load now succeeds and downscales correctly. Will request a PR to `main` when ready.

Claude referenced this issue from a commit

2026-06-24 01:12:45 +00:00

fix(viewer): always display full-resolution images (#117)

Claude referenced this issue from a commit

2026-06-24 01:45:37 +00:00

docs: PR-prep — bump to 0.2.2 for issue #117 viewer fixes

Claude commented

2026-06-24 01:46:12 +00:00

Member

Resolved on 0.2.1/issue-117-tall-image-not-rendering, PR incoming to main:

Root cause / rendering failure: QImage(path) loads through Qt's default 256 MB QImageReader allocation limit before any downscaling runs. The reported 1569x42895 image needs ~256.7 MB at 4 bytes/pixel — just over that limit — so Qt silently returned a null image with no exception, which is why the viewer kept showing the previously loaded image and the Duplicates Multi view showed a blank canvas. Fixed by loading via QImageReader directly with the allocation limit raised to 1024 MB.
Follow-up while in this code: the viewer was also pre-downscaling every image to a 2048px max edge before display, so zooming in past 100% upscaled that reduced copy and looked blurry. Images are now always loaded and displayed at full resolution, with the existing fit-to-window zoom only scaling the on-screen presentation — zooming in now reveals true source detail.

Both covered by a new regression test (tests/test_viewer_image_loader.py) reproducing the exact failing dimensions. Closing — reopen if the PR review surfaces anything.

Resolved on `0.2.1/issue-117-tall-image-not-rendering`, PR incoming to `main`: 1. **Root cause / rendering failure:** `QImage(path)` loads through Qt's default 256 MB `QImageReader` allocation limit before any downscaling runs. The reported 1569x42895 image needs ~256.7 MB at 4 bytes/pixel — just over that limit — so Qt silently returned a null image with no exception, which is why the viewer kept showing the previously loaded image and the Duplicates Multi view showed a blank canvas. Fixed by loading via `QImageReader` directly with the allocation limit raised to 1024 MB. 2. **Follow-up while in this code:** the viewer was also pre-downscaling every image to a 2048px max edge before display, so zooming in past 100% upscaled that reduced copy and looked blurry. Images are now always loaded and displayed at full resolution, with the existing fit-to-window zoom only scaling the on-screen presentation — zooming in now reveals true source detail. Both covered by a new regression test (`tests/test_viewer_image_loader.py`) reproducing the exact failing dimensions. Closing — reopen if the PR review surfaces anything.

Claude closed this issue

2026-06-24 01:46:18 +00:00

Claude referenced this issue from a pull request that will close it,

2026-06-24 01:46:43 +00:00

fix(viewer): load tall images past Qt's allocation limit; always display full resolution #134

ValleyGeek referenced this issue from a commit

2026-06-24 01:47:10 +00:00

fix(viewer): load tall images past Qt's allocation limit; always display full resolution (#134)