Images are converted to all black after compression on IPad pro

[Russell-Pollari]

No errors thrown, but image is uploaded as a black square.

I think the root cause is that the user agent string on an iPad pro presents as a Mac.

Since the user agent determines the browser and the max canvas size, this would mean that the library is assuming the wrong maximum canvas size for the Ipad.

I don't have an IPad pro myself to test on, this was reported by a customer. Will continue to do some debugging and update it here.

If you have an iPad pro and can share what the user agent is, that would be very helpful!

[Russell-Pollari]

Yes I think the solution will require other means of browser/device detection that does not depend on the user agent..

more context: https://stackoverflow.com/questions/57776001/how-to-detect-ipad-pro-as-ipad-using-javascript

[nrathi]

Any update on this? I'm seeing the same.

[Russell-Pollari]

Hi @nrathi, not sure if this repo is actively maintained. I have a fix for this in my fork here: https://github.com/Russell-Pollari/browser-image-compression/tree/fix-for-ipad

[nrathi]

@Russell-Pollari Amazing. While I have you... do you have any guidance on how to effectively process many hi-res images on mobile?

I just need a basic first-pass compression before sending images over the wire. I'm trying to get iPhone images that are ~12MB down to something more reasonable like 2MB. Then I use Sharp to normalize the images server-side.

   return await imageCompression(file, {
      maxSizeMB: 2,
      fileType: "image/jpeg",
      initialQuality: 0.95,
      // useWebWorker is true by default
    });

I'm using Promise.all to compress in parallel. The user can upload 24 pictures at a time (and, worst case, they can do this 30x in a matter of minutes). I'm having some iPhone users report slowness & timeouts. Any advice would be appreciated.

[Russell-Pollari]

@nrathi you might hit resource constraints if you try too many in parallel. Maybe try batching?