Signal silently destroys larger PNG images by lossfully compressing them as JPEGs

[sailbird]

• [x] I have searched open and closed issues for duplicates
• [x] I am submitting a bug report for existing functionality that does not work as intended
• [x] This isn't a feature request or a discussion topic

---

Bug description

My boss sent me a series of PNG images to concatenate into a single image. The problem is that some of them (and worse, only some of them) arrived as JPEGs. After a lot of wasted time, I realized that this is the old Signal problem that it destroys PNG data by lossfully compressing it if the original image is a certain size (over 256KB, looks like). Net result is that the images wouldn't line up properly due to compression artifacts, and all in all the result looked unprofessional. It's 2024 and Signal allows people to send videos of many megabytes (albeit also silently degraded by recompression). Why are we still stuck in the dark ages with PNG size limits? And if the size is really such a drag on your servers, then fine: just refuse to send it in the first place, or at least ask if the user is OK converting it to JPEG (with checkbox for "don't ask again"). Maybe I'm being deceived by random luck but I'm pretty sure this is what's going on.

Steps to reproduce

• Attach a PNG image file which is over 256KB (or maybe let's say 1MB) in size.
• Send to friend

Actual result: Describe here what happens after you run the steps above (i.e. the buggy behaviour)

• Friend receives image as JPEG

Expected result: Describe here what should happen after you run the steps above (i.e. what would be the correct behaviour)

• Friend receives unmodified PNG, or sender explicitly agreed to convert it to JPEG, or sender was blocked from sending it

Device info

Device: iPhone 15

iOS version: (latest)

Signal version: (latest)

[sailbird]

Related but not equivalent Android issue:

https://github.com/signalapp/Signal-Android/issues/10074

[Thireus]

By default the client app will convert the image. I propose to add an additional option in the settings, we already have "high" quality, we should have "original" quality as well which would not attempt to convert the image.

The code is there for reference:

• https://github.com/signalapp/Signal-iOS/blob/main/SignalUI/AttachmentApproval/AttachmentApprovalViewController.swift#L644
• https://github.com/signalapp/Signal-iOS/blob/main/SignalServiceKit/Attachments/SignalAttachment.swift#L274
• https://github.com/signalapp/Signal-iOS/blob/72431ae93040fdf28ec231fb9b70e6e903d2dfee/SignalServiceKit/Attachments/SignalAttachment.swift#L834

Not too hard to implement, however there are a few key implications:

• Storage on Signal servers
• Metadata which could contain privacy-related elements such as GPS location would not be purged (we could however add a note to the "original" option to mention this as a warning)

I leave it to the devs to comment further on the above.

Temporary solution for your use-case: Zip the images before sending them.

[sailbird]

@Thireus Brilliant! It would be also helpful to have "original but without JFIF header" to delete all the GPS/camera metadata before sending but otherwise leave every pixel unchanged. But even just your proposal as-is would be a great improvement if it would apply to images of all sizes. (If the size is too big then the upload to the server itself should fail, as in you don't even make it to the first checkmark, and get a big red bang instead.)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been closed due to inactivity.