Black Images

[springiemedia]

Recently, this package has started producing black images from a number of newer devices e.g. Samsung s20 ultra.

[paul-thebaud]

Hi!
Same problem on Macbook Pro 16" 2019 (MacOS BigSur) with Google Chrome 87.0.4280.66.
PNG with transparency are getting black backgrounds.

[paul-thebaud]

Locking the package version to 1.0.12 resolved the problem for me.
It seems it is due to 1.0.13 version.

[springiemedia]

Locking the package version to 1.0.12 resolved the problem for me.
It seems it is due to 1.0.13 version.

Interesting, the issue was present on 1.0.12 for me. However the black is resulting from jpegs not PNG.

[paul-thebaud]

@springiemedia black on JPEG? There is no transparency on JPEG, so what the black is replacing?
(on PNG, it replaces transparent background with black)

[ndanvers]

I am essentially working with stock images, none of these have been taken with a newer phone or device to my knowledge.

Current Package version : 1.0.13 => Transparency is replaced by a Black backgrounds on PNG
Revert to Package version : 1.0.12 => Re-upload images => Black backgrounds are no longer present.

Secondly, 1.0.13 seems to have caused an issue for PNG encoding on my end.
1.0.13 : PNG files are being encoded "incorrectly" => data:image/png;base64 is proceeded by what looks like JPG base64
1.0.12 : PNG files are being encoded "correctly" => data:image/png;base64 is proceeded by png b64 "IVBOR..."

At the moment => JPEG files are not causing me an issue.

[paul-thebaud]

Hi everyone,
I do not have the issue on MacOS with 1.0.12, but I tried with Windows and the issue is present with Chrome and Firefox.
@Donaldcwl, is a fix for this issue planned soon?

[Donaldcwl]

Thanks for raising this issue. I am looking into the problem.
It would be nice if you can also fork the repo and do some debugging together :)

[paul-thebaud]

Hi @Donaldcwl,
I searched inside the diff between 1.0.12 and 1.0.13, and tested on my side.
It seems the bug for PNG on 13 is due to this line : v1.0.12...v1.0.13#diff-323d121619a5b1b8d744f61f889b377cba0feef34cb341ba78c79966386212b7R100
When I change the tempFileType to outputFileType (inside canvasToFile call), it seams the bug is fixed.
I tested on MacOS, so the problem might not be fixed on Windows.

[xmd5a]

@Donaldcwl do you still need help with this issue?

[Donaldcwl]

Hi all, the issue has been fixed in v1.0.14.

[paul-thebaud]

@Donaldcwl Hi, seems working on MacOS BS+Chrome and Windows10+Chrome, thanks!

[xmd5a]

1.0.14 do not fix this at all.
Still I have this error on iPhone 7 + iOS 14 + chrome or/and safari browser using jpeg photos (if you need sample photo I can send it to you because not every jpeg is invalid converted)

[Donaldcwl]

@xmd5a This black image issue we fix here is related to transparent PNG image only, isn't it?
What issue do you encounter on your iPhone with JPEG image?
Please send me the images either upload them here in github or email me.

[paul-thebaud]

Locking the package version to 1.0.12 resolved the problem for me.
It seems it is due to 1.0.13 version.

Interesting, the issue was present on 1.0.12 for me. However the black is resulting from jpegs not PNG.

@Donaldcwl see this. Issues appears on JPEG too (I didn't faced this case).

[Donaldcwl]

@xmd5a @springiemedia, Would you mind to upload the JPEG images that you have encountered this issue? Thanks.

[bill-thedbaguy]

@Donaldcwl I am having a similar issue with images being cut off at the bottom when the original file is over 1.6 mb.
I first encountered this on version 1.0.9. Yesterday, I switched to 1.0.14 and still have the problem.
The first picture (SnowyMississippiBackwaters) is the original that I found the problem with. It is 5.08mb in size.

The next is the compressed file pulled from our storage location.

This last one is a screen shot of the a portion of the web page that uses the compressed file. The image should be just as tall as the partial image to the left.

Also, when we use the original file in your demo web page it works fine.

It does not just happen with this one file. we tried multiple files with different sizes. the problem starts at 1.6mb but is really noticeable when the file is greater than 1.97mb.

What additional information do you need?

[springiemedia]

@Donaldcwl sorry for the delay, not the best photo but this one results in a black image:

Also if it helps the image brings up and error and won't load in Photoshop CS6

"Could not complete your request because JPEG Marker segment length is too short (the file may be truncated or incomplete)"

It does however open fine in other programs, such as MS Paint.

[hugorezende]

Hello folks!
TL;DR
This problem is caused because IOS has a limit for the canvas, which seems to be the device memory / 4. Just get a very large image file, like 50MB and you will probably get this error on iPhone.

Now a bit further explanation:
I found the root of this issue after investigating the react-easy-cropper lib that I was using in my project, and there, some users also reported this black image problem for IOS.

So, my first attempt as suggested was to use the Pica library, set a max-width to reduce the canvas before using the crop.
Pica is great because they already know this problem, and it deals with that limitation (https://github.com/nodeca/pica/wiki/iOS-Memory-Limit)

However, there was no file compression for the blob, and I was getting a significantly large file.
At this point, I tried to use this lib without Pica, and it did the job perfectly indeed, reducing the file size, but again I got the black picture for big files.
I haven't investigated it in deep but as far as I understood, at least when you use the maxWidthOrHeight, the function drawFileInCanvas creates a canvas with the size of the original image, right @Donaldcwl?

Well, in the end, for those that are fighting with this as I was, what fixed my problem was to set a size limit with the lib that Pica recommends: https://www.npmjs.com/package/image-blob-reduce

Hope it can help someone.

Ps: In this issue nodeca/pica#199, there is a comment saying a possible workaround for this.

[Donaldcwl]

Thanks for the sample images and useful information.
When I have time, I will look into the issues and will use a workaround for IOS limit.

[springiemedia]

Thanks for the sample images and useful information.
When I have time, I will look into the issues and will use a workaround for IOS limit.

Just so you are aware this also occurs on Samsung S20's, so it looks like it could be a canvas limit on iOS and Android. Perhaps due to the newer phone camera's having higher megapixel cameras leading to larger file sizes.

[toastyghost]

This is happening for me with a JPEG in Firefox 87 on macOS Big Sur. The file is unfortunately too large to upload here or any of the free sites I've found for image hosting, so not sure how to pass it along as test data. It's the 80 MB version of the blue marble image from NASA, if that helps.

e: I take that back, this appears to be happening with ALL JPEGs now, and neither 1.0.12 or 1.0.14 seems to resolve it.

[zhicong]

This is happening for me with a JPEG in Firefox 87 on macOS Big Sur. The file is unfortunately too large to upload here or any of the free sites I've found for image hosting, so not sure how to pass it along as test data. It's the 80 MB version of the blue marble image from NASA, if that helps.

e: I take that back, this appears to be happening with ALL JPEGs now, and neither 1.0.12 or 1.0.14 seems to resolve it.

Do you have a link to the 80 MB image you used? I was unable to reproduce this with the few JPEGs I tried on the package demo site on Firefox 87.0 on macOS Big Sur 11.2.3.

[pradeep-here]

Hi @Donaldcwl, I see similar issue on two user's device

using

"browser-image-compression": "^1.0.14",

Issue:
On converting *.jpg image, the compressed image with issue (all black), is always 9.82 KB (10054)

Original file was: 1117740 bytes
Compressed-all-black-file (with the issue) is only : 9.82 KB (10054 bytes)
Sometimes the compression works fine on same device, and compressed images are varying in size (ex: 180 KB)

Impacted device info - gathered using Sentry:

browser: Chrome Mobile 93.0.4557
device: RMX2189
os: Android 10

User-2 with similar issue
In this case, black images are always - 9500 bytes (9.28 KB)

Mobile: Oppo A12 (CPH2083)
Android Version: 9

Have also verified, user's device has few GB free storage space available, so free space should not be an issue .

The compression is working fine on many other users using various devices and mostly chrome.
On the impacted user's device also, as mentioned earlier, the compression works fine sometimes, but most of the time compressed image (jpeg) is all black, and is only 10054 bytes

[Donaldcwl]

fixed in v1.0.15