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

[ryqndev]

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.

[russellwheatley]

Hey @ryqndev, thanks for the feature request. That doesn't seem unreasonable if the image is failing to be resized. Certainly something to consider for the Firebase Extension team. Not sure if this is a frequent occurrence for this extension.

Do you know what image type isn't being resized? Or do you have the error message from the extension's console logs that you could share, please? That would be great in helping us debug!

[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!

[russellwheatley]

@ryqndev Thanks for the quick response. I have a couple of questions.

Is it the very same image that works when uploaded via your computer, and errors when input through your mobile device?

You also mention it is stored in Google Photos. Is this where it is for mobile device and your computer before being uploaded to Firebase storage via your webpage?

Last thing perhaps, it would be nice to have a print out of the metadata in your JS code before being uploaded via mobile and web to Firebase storage 😄

[ryqndev]

I just realized my comment regarding my computer uploads is a little confusing. Super sorry about that!

Anyways, I did a little bit more in-depth testing and uploaded the same image that resulted in an error from phone to my computer (which still failed so I believe this is a faulty image and more info below) and I encountered a slightly different error:

Error when resizing image [Error: vips_realpath: unable to form filename unix error: No such file or directory 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 ]

This is the image I was working with: (I can try other images if that would help) Hopefully the attached image doesn't get modified

image background story

I took this picture with my Google Pixel 4 XL some time ago:

...and I was able to successfully upload to firebase storage as well as resize properly without errors using the storage-resize-images extension.

However, I posted the same image onto my Instagram which naturally crops (into a square) and filters the image and saved it into my camera roll. This resulting image is the one that ran into errors when I uploaded it to firebase storage and the extension tried to resize it. I believe the culprit here is how Instagram seems to be filtering images as they result in 'corrupting' the binary data yet keeping it intact enough to be displayed.

Not sure if this is something that should be noted in the sharp repo or maybe a ticket to Instagram since I'm pretty out of my depth with image processing but I wanted to try and help debug the issue.

Relevant but different issue

Another thing I noticed when I was looking at firebase storage was sometimes when the image resize failed, it still created one of the thumbnail sizes. I attached a screenshot of the console below:

I think this might be an issue since I believe the only way to tell if a resize was successful is to check for the existence of the new thumbnail image but this may not be the case. If you'd prefer it, I can open a separate issue but for now, this is what I've found. Thanks for the great work and hope this helps!

[russellwheatley]

Thanks for the excellent feedback, @ryqndev 😄 . I'll be sure to take a look into this and get back to you.

[mikemey01]

I'm getting the same error when attempting to upload an image taken directly from my google Pixel 2:

Error when resizing image [Error: vips_realpath: unable to form filename unix error: No such file or directory VipsJpeg: Corrupt JPEG data: 18 extraneous bytes before marker 0xe2 VipsJpeg: Corrupt JPEG data: 18 extraneous bytes before marker 0xe2 VipsJpeg: Corrupt JPEG data: 18 extraneous bytes before marker 0xe2 VipsJpeg: Corrupt JPEG data: 18 extraneous bytes before marker 0xe2 VipsJpeg: Corrupt JPEG data: 18 extraneous bytes before marker 0xe2 VipsJpeg: Corrupt JPEG data: 18 extraneous bytes before marker 0xe2 VipsJpeg: out of order read at line 0 VipsJpeg: out of order read at line 0 ]

the same image works when uploaded from my computer (after transferring it from my phone via USB cable).

[russellwheatley]

Thanks for the feedback! Do you mind letting me know the Android OS & also the storage-resize-image extension versions you're using? @mikemey01 @ryqndev

My sense is that the Android OS is altering the image that might not be compatible with the Sharp library, but would need to confirm and reproduce (🤞 ) before creating an issue with the Sharp repo.

[mikemey01]

@russellwheatley Android version: 11 Android security update: September 5, 2020 Google Play system update: September 1, 2020 Build number: RP1A.200720.009

Firebase storage-resize-image version: 0.1.12

Let me know if there's anything else i can help with!

[russellwheatley]

Thanks, @mikemey01. I've used a Pixel 2 & Pixel 4XL emulator with Android OS 11. I downloaded some images, uploaded them to my storage bucket and they resized without a problem. I guess this might be a physical device specific issue.

Ultimately, the problem is with the Sharp library erroring on the resize. It might be worth filing an issue here with the steps to reproduce this error. They probably won't be able to help if they don't have one of those two devices, however.

[jhuleatt]

Since this issue is now focused on errors with images uploaded from specific devices, I've opened https://github.com/firebase/extensions/issues/470 to track the original request: that the original image not be deleted if the resize fails.

[mikemey01]

Is there anyway we could toggle the failOnError param in the extension config as indicated in the Sharp issue tracker?

https://github.com/lovell/sharp/issues/2416#issuecomment-714329725

sharp(input, { failOnError: false })...

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