Setting to highest/major for the determining if this is really a bug part. I, very unfortunately, am not sure. I don't know all the details.

Jan: can you comment?

jgerber wrote:

this image is hitting the memory limit.

running
IM_CONCURRENCY=1 vips im_shrink 'Daedongyeojido-full.jpg' test.jpg 2.507838312829525478e+2 2.518363064008394474e+2

without memory limit, it is using about 3Gb here.

Ok, thanks.

So, is this something we can heuristically guard against (throw it back to default imagemagick)? What do you think the size limit is for vips on these image types? I see that the image on Commons was thumbnailed correctly: https://commons.wikimedia.org/wiki/File:Daedongyeojido-full.jpg

If you have a good idea about it, please do submit a merge request with the change to the default config settings (per bug 51370).

(In reply to comment #3)

Ok, thanks.

So, is this something we can heuristically guard against (throw it back to
default imagemagick)? What do you think the size limit is for vips on these
image types? I see that the image on Commons was thumbnailed correctly:
https://commons.wikimedia.org/wiki/File:Daedongyeojido-full.jpg

If you have a good idea about it, please do submit a merge request with the
change to the default config settings (per bug 51370).

That's a different version of the file. large progressive jpegs are broken on both scalars

Ah, my bad. Thanks for the correction.

So, everything else in my last comment though stands: what should the limit be and let's get that explicit in Gerrit :)

(In reply to comment #6)

So, everything else in my last comment though stands: what should the limit
be and let's get that explicit in Gerrit :)

Jan / bawolff: Any input?

[Pinging as this has been "highest" priority for amonth now.]

Reducing priority (its not that big a deal. Progressive jpegs aren't commonly used, and this bug is just the status quo. Enabling vips for tiffs is much more important).

Re greg:
*we don't know if a file is progressive or not at thumbnail time (this just simply would have to be changed in metadata extractor code)
*we would probably want to do more testing on such files to check what performance is like (make sure that we don't just have one outlier). If vips does decompress the whole gile into memory, 50 MP would probably be a good limit. (Our current limit for image magick, if it was enabled for jpeg). However if that's the case there isn't much point using vips for these files.