cosmic-files icon indicating copy to clipboard operation
cosmic-files copied to clipboard

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

Open XV-02 opened this issue 1 year ago • 6 comments

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.

XV-02 avatar May 15 '24 17:05 XV-02

Can you link to the file?

jackpot51 avatar May 15 '24 18:05 jackpot51

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

XV-02 avatar May 15 '24 19:05 XV-02

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 avatar May 15 '24 19:05 XV-02

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.)

XV-02 avatar May 15 '24 20:05 XV-02

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");
}

Quackdoc avatar May 16 '24 13:05 Quackdoc

Tested on this file

Files Version:

cosmic-files:
  Installed: 0.1.0~1741363853~24.04~63ab36a

iamkartiknayak avatar Mar 07 '25 20:03 iamkartiknayak