Broken Image Formats - AVIF & JXL

[gianni-rosato]

• [X] I have searched open and closed issues for duplicates
• [X] I am using Signal-Desktop as provided by the Signal team, not a 3rd-party package.

---

Bug Description

Upon sending an image from the desktop client (any Linux desktop client will do) in the AVIF or JXL image format, it will display as broken on Android/iOS & will not show a preview on the desktop at all instead letting the image appear as a standalone file. I believe this can be replicated on Windows as well. Occasionally, the AVIF image will also corrupt, but I cannot reproduce this consistently. When sent from an Android device, AVIFs are transcoded to JPEG while JXL images simply fail to send.

Steps to Reproduce

1. Open a Signal Desktop client & send an image that is either an AVIF or JXL, depending on what you are trying to reproduce. Make sure the desktop client is synced to an Android client, so that you can observe the behavior on both sides.
2. Open the mobile client (Android or iOS will do) and observe the image's failure to load properly. on Android, it will show a failed prewiew; on iOS, the image will look like a file just like on the desktop.
3. Try to send an image back from the mobile device. If it is an AVIF, it will be transcoded; JXL images will simply fail to send.

Actual Result:

AVIF & JXL images will not display properly, showing an error icon instead of an image. On the desktop, they will not show previews at all. When sending a JXL from an Android phone, it will fail to send.

Expected Result:

Ideally, sending an AVIF or JXL image from the desktop should just display the image in Signal, untouched & without transcoding. Even transcoding would be preferable to the failure to present a preview at all though, which is the current situation.

Screenshots

Platform Info

Signal Version:

6.7.0

Operating System:

Arch Linux x86_64 (this will not matter, issue can be replicated on any Linux desktop)

Linked Device Version:

Android: 6.12.5 | iOS: 6.14.0.6

Link to Debug Log

Desktop: https://debuglogs.org/desktop/6.7.0/78aea3c0a9315512ecd4fcf886dd6afec55c89c21471c583badae753d341991b.gz Android: https://debuglogs.org/android/6.12.5/62afcb4ed4287dbd37ae6039827b0ae23957eccd6713c18f9e197757f6a4a799 iOS: https://debuglogs.org/ios/6.14.0/30f8dc454675e1de3bea918a4f677153f2c3087eeab24767f60ff3d92ac1472d.zip

[alvaro-signal]

@gianni-rosato As this is not supported by chromium and they themselves dropped support since they didn't think there was enough interest, we're not likely to support them either. If you think otherwise or you think we should render them differently, please discuss in the community forums. Closing.

[gianni-rosato]

@gianni-rosato As this is not supported by chromium and they themselves dropped support since they didn't think there was enough interest, we're not likely to support them either. If you think otherwise or you think we should render them differently, please discuss in the community forums. Closing.

I don't recall AVIF being dropped by Chromium. SVG images also do not work properly, I should add.

Are there any plans to fix AVIF support, ignoring JXL for a moment?

[alvaro-signal]

@gianni-rosato Ah, you're right. I believe AVIF support should be simple to add. I will add it to our plans.

[gianni-rosato]

I think it is already "supported" on android, in the form of being transcoded to JPEG (when it works) - now that everything supports AVIF though (even iOS devices) you could honestly use AVIF compression to transcode images instead of less efficient JPEG. It would save bandwidth or improve quality at the same bandwidth

[gianni-rosato]

Hey, just checking in on this issue - AVIF images coming from a desktop still show up corrupted on Android & not at all on iOS. Not sure why this is.

Additionally, JPEG-XL interest seems to be quite strong despite Google's insistance. Facebook, Adobe, Intel and the Video Electronics Standards Association, The Guardian, Flickr and SmugMug, Shopify, the Krita Foundation, and Serif Ltd. all have come out endorsing JPEG-XL along with Cloudinary & Google's research division. If this still doesn't make the issue worth reconsidering, I simply wanted to bring it up in case it does. In the meantime, AVIF is the real problem here in terms of partial/broken support.

[scottnonnenberg-signal]

@gianni-rosato If Android is having trouble with AVIF file attachments, you should probably file it here: https://github.com/signalapp/Signal-Android/issues

[gianni-rosato]

Is it that Android isn't decoding the AVIFs properly, or that the desktop client isn't sending them properly?

[scottnonnenberg-signal]

@gianni-rosato Do other desktops have problems with the send? If not, it's an Android-specific problem.

[gianni-rosato]

When sent from an Android device, AVIFs are transcoded to JPEG while JXL images simply fail to send.

This leads me to believe it is a desktop problem, which is why I filed the issue here initially. Unless Signal is aiming not to transcode AVIFs & this is incorrect behavior, although this has issues on iOS.

[gianni-rosato]

Will JPEG XL support be reconsidered in the wake of Apple's recent WWDC announcement regarding JXL in Safari?

[mgord9518]

I would also really like to see JXL support, I don't know much about Electron but I believe it shouldn't be terribly hard to add support using something like this

Should just be able to decode it into a raw image then display it like anything else

[EwoutH]

I would love you to reconsider both AVIF and JPEG XL support, at least as input format.

Note that I'm saying: Support decoding AVIF and JPEG XL images, so they can be send (and recoded to current file formats that alle devices support). In this case, only a AV1 and JPEG XL decoders need to be present. These can be (the very small and performant) dav1d AV1 decoder any one of a number of JPEG XL implementations (see https://jpegxl.info/). No need to add encoders.

The most important reason for this is so that people can send JPEG XL and AVIF images from their desktops without transcoding them manually first. Adobe now supports to export images in HDR, including in AVIF and JPEG XL (which are very suitable formats for HDR images).