pop-os / cosmic-files

COSMIC file manager
GNU General Public License v3.0
112 stars 84 forks source link

Image thumbnails/property-draw previews fail with very large images #162

Open XV-02 opened 6 months ago

XV-02 commented 6 months ago

While attempting to open an PNG of a package dependency tree, I found that the preview functionality of the properties tab failed with very large images, as did the picture thumbnail.

The file in question is a 25 MB (~12000 x ~21000 pixel) image. I'm uncertain of what point the preview fails at, and whether it is an issue of raw file-size, or of the pixel-area.

jackpot51 commented 6 months ago

Can you link to the file?

XV-02 commented 6 months ago

(For posterity) I've provided the file directly, as Github cannot support files of the size involved.

XV-02 commented 6 months ago

I believe it is an issue with the number of pixels. I created a test file with a file size of <800KB, smaller than known preview-able files of much smaller resolutions, but with a resolution of 12000 x 21000. This neither previews, not renders a thumbnail correctly.

The test image (png) is a single solid colour (an approximation of the default cosmic accent blue)

XV-02 commented 6 months ago

And, I'm fairly sure, whatever it is, it is an issue with the total number of pixels required. A file that is 12000 x 14925 will not correctly preview or have an image thumbnail. A file which is 6000 x 14925 will. So, I don't believe it is either the horizontal or vertical resolution individually causing an issue.

That total value is somewhere between 178950817 and 178957506 it seems (difference of 6689 between the values.)

Quackdoc commented 6 months ago

I havent checked the code but image-rs has a limits that need to be configured for very large images, The default is a fairly reasonable 512mb, if the decoder goes over that it will kill itself, this is likely whats happening https://github.com/image-rs/image/blob/1207aca6af0c808e00857fa2bf14fff3ccdee6ff/src/io/mod.rs#L52

this behavior iirc throws a specific error that can be handled, from there it could be punted to something else for decoding, it could be punted to the end of the decode sequence and then attempt to decode it with a higher limit.

ffmpeg required 700MiB to decode it to null magick required 2.8GiB to run the -bench 2 mode

it may be reasonable to raise the limits somewhat, the below code takes 720M to decode with --release. It may be reasonable to raise the limits, but only if decoding runs sequentially. Im not sure if they are currently in parallel or not, if they are it may be reasonable to punt failed images that reply with a "memory error" to a secondary queue to be processed in sequence after the main queue is finished

use image::io::Reader as ImageReader;
fn main() {
    let mut img = ImageReader::open(r"/tmp/test/test.png")
        .expect("File Error");

    img.no_limits();
    img.decode().expect("error");
}