storage-resize-images "Corrupt JPEG data" error when uploaded from some phones

Extension name

This feature request is for extension: storage-resize-images

What feature would you like to see?

An extra level of configuration for ‘deletion of original file’ where the file is only deleted if the resize is successful and all new specified resizes are created.

How would you use it?

I am using the resizing extension as a compression tool so I can save space. However, some images that are uploaded from my users using the File API in a PWA from their phones are resulting in errors in the resizing function but the original image is still functional. In cases where the image resize results in an error, I would like to use the original file and store/use the resized images only when the resize function is successful.

Note: Current behavior

If the ‘deletion of original file’ option is selected, the original file is deleted regardless of whether or not the resize function was successful.

[ryqndev]

I can’t seem to figure out what the pattern is with the errors since some images work and some don’t but I’m uploading images to my PWA using an html file input that only accepts images on my Google Pixel 4 XL. Uploading images from my computer works perfectly fine so I don’t think it’s an error in the code. I’m assuming some images formatted in Google Photos are kinda wonky?? Not really sure but I hope this helps.

These are the 2 types of errors I’m getting:

Error when resizing image [Error: VipsJpeg: Corrupt JPEG data: 18 extraneous bytes before marker 0xdb VipsJpeg: Corrupt JPEG data: 18 extraneous bytes before marker 0xdb VipsJpeg: Corrupt JPEG data: 18 extraneous bytes before marker 0xdb VipsJpeg: Corrupt JPEG data: 18 extraneous bytes before marker 0xdb VipsJpeg: Corrupt JPEG data: 18 extraneous bytes before marker 0xdb VipsJpeg: out of order read at line 0 VipsJpeg: out of order read at line 0 ]

Error when resizing image [Error: VipsJpeg: out of order read at line 0 ]

Let me know if you need any more info!

[jhuleatt]

@mikemey01 thanks for filing this with Sharp!

Unfortunately, since, per https://github.com/lovell/sharp/issues/2416, this was caused by an actual malformed JPEG file, and Sharp recommended we only turn on failOnError if we “trust the source of the images” (which we shouldn’t given that most uses of this extension probably involve uploads from end-users), I think we’re just going to have to call this “working as intended” and close this one out.