*** Bug 482554 has been marked as a duplicate of this bug. ***

Qt6 introduced a limit on how much memory a QImage can allocate. This is useful for security reasons, you don't want a malformed image to allocate all your memory.

In the case of Gwenview the default limit seems to be too low, so we should increase that

When it will be fixed? I need gwenview.

The problem is not only in Gwenview. 

Okular and Kolourpaint used to be able to open large images, and since I upgraded to Plasma 6 they both give an error. The same image opens fine in Gwenview, Okular and Kolourpaint on a Plasma 5.27 machine.

The images I can't open aren't even that big, some of them are only 6 MB. It's just the resolution that's very high, around 14000x10000 pixels.

There is a workaround posted in https://bugs.kde.org/show_bug.cgi?id=483534 which I think is a duplicate bug.

Look here https://bugs.kde.org/show_bug.cgi?id=483534#c3
I added comment , how to run gwenview when you using fish shell.

*** Bug 483534 has been marked as a duplicate of this bug. ***

I'm not sure this allocation limit makes sense in an app whose purpose is opening and displaying images. Yes, you don't want a malformed image to gobble up all your memory or crash the app, but you also don't want the attempt at preventing this to make the app unusable for its primary function with legitimate content.

Ideally, the app should detect this issue, then present a dialog to the user saying something like:

  Image is too large for the current safety limits. Would you like to load the image anyway?
      [Yes]  [No]
 [_] Permanently increase limits to allow opening images of this size in the future.

GIMP does something similar if you try to work with very large images.

Then if the user clicks "Yes", you can iterate over the limit size until you can find a size that works (or reach a really high hard-limit), and if the user checked "Permanently increase" you save that to a config value that will set the default size. Alternatively, it can just use setAllocationLimit(0) to disable the limit.

But this problem is not with very large images. I have images in my library, some only 6 mb big, which I currently cannot open with anything but GIMP. And GIMP does not show the warning, it just opens it.

Okular, Gwenview and Kolourpaint all have the "Rejecting image as it exceeds the current allocation limit of 256 megabytes" error when I try to open these images.

(In reply to Sjoerd from comment #10)
> But this problem is not with very large images. I have images in my library,
> some only 6 mb big, which I currently cannot open with anything but GIMP.

When we talk about "size" here, we don't mean "file size" - we mean "image size" i.e. how much memory it takes to hold the uncompressed pixels of the image. You have to remember that image file formats are usually highly composed. A 6MB JPEG image is quite a large file and probably contains a file with more than 100 megapixels.

> And GIMP does not show the warning, it just opens it.

GIMP has a higher limit (I think 400MP or something like that) and when it encounters it, it will show a dialog box and will let you override the limit.

A possibly relevant merge request was started @ https://invent.kde.org/graphics/gwenview/-/merge_requests/262

(In reply to Bug Janitor Service from comment #12)
> A possibly relevant merge request was started @
> https://invent.kde.org/graphics/gwenview/-/merge_requests/262

I saw that the proposal is to increase the limit to 400 mb. If I set QT_IMAGEIO_MAXALLOC to 400 and open images in Gwenview, I am still hitting the limit. 

I need at least 600 mb to open some of my images, and I think if I need this much others will too, and probably even more. The original poster of this bug was talking about 200 megapixel photos which is bigger than what I tested with.

(In reply to Sjoerd from comment #13)
> ... was talking about 200 megapixel photos which is bigger than what I
> tested with.

A 200MP image at standard RGB 24bpp is 600MB uncompressed.

The current default of 256MB is enough to open a 85MP image.

(In reply to Oded Arbel from comment #14)
> (In reply to Sjoerd from comment #13)
> > ... was talking about 200 megapixel photos which is bigger than what I
> > tested with.
> 
> A 200MP image at standard RGB 24bpp is 600MB uncompressed.
> 
> The current default of 256MB is enough to open a 85MP image.

If I read the Qt docs right (https://doc.qt.io/qt-6/qimagereader.html#setAllocationLimit), it internally converts images to 32 bits, so the effective limit is smaller. A 200MP image would then be ~760 MB. 

So to fix the issue for the person who opened this bug the limit would need to be at least 800 MB.

(In reply to Oded Arbel from comment #14)
> The current default of 256MB is enough to open a 85MP image.

I have various image projects that range between ~70MP and ~150MP, both 24 bit and 48 bit color. As far as I can tell all of them fail to load, even the smaller ones.
Seeing how I literally have tens of gigabytes of memory available I don't see why this limit needs to be so low, or why it couldn't be configurable.

*** Bug 485289 has been marked as a duplicate of this bug. ***

*** Bug 485372 has been marked as a duplicate of this bug. ***

I think there are several improvements which can be made:

* If the limit is hit the app should display this as the reason why it failed to load the image (my first guess was that the image was corrupted but that is obviously not the case).
* The limit might be better as a ratio of installed (or free) memory instead of a hardcoded limit.
* If the limit is encountered the user should be shown a prompt to raise or temporarily suppress the limit.

Git commit f980675af672e6fd27270f1542baebdde1e3cde9 by Méven Car.
Committed on 27/04/2024 at 11:26.
Pushed by meven into branch 'master'.

ImageReader: allow 2Gb max allocation

M  +3    -0    app/mainwindow.cpp

https://invent.kde.org/graphics/gwenview/-/commit/f980675af672e6fd27270f1542baebdde1e3cde9

A possibly relevant merge request was started @ https://invent.kde.org/graphics/gwenview/-/merge_requests/268

Effectively fixed by that commit, which restores the limit to what it was in Qt 5 times--so it's at least no worse now than what it was before.

Git commit dd56729aa39d33b5be2e1a788b032fd2edee6e80 by Nate Graham, on behalf of Méven Car.
Committed on 29/04/2024 at 15:09.
Pushed by ngraham into branch 'release/24.05'.

ImageReader: allow 2Gb max allocation


(cherry picked from commit f980675af672e6fd27270f1542baebdde1e3cde9)

M  +3    -0    app/mainwindow.cpp

https://invent.kde.org/graphics/gwenview/-/commit/dd56729aa39d33b5be2e1a788b032fd2edee6e80