Bugs and Suggestions

The choice of the first or the second of these options is ubiquitously presented in the current interfaces of Telegram by the notion of recompression to JPEG; for example, Telegram Desktop has the checkbox “compress images” and Telegram for Android has the menu item “send without compression”. However, Telegram should refrain from AVIF-to-JPEG recompression because that would introduce longer delivery and costly storage without any real benefit and thus it would be silly. Telegram should even refrain from AVIF-to-AVIF recompression (on the client side before sending the file, and on the server side, and again on the client side before saving the file) because such recompression would have several demerits:

➊ Recompression causes generation loss (see https://en.wikipedia.org/wiki/Generation_loss for the definition, see also https://youtu.be/FtSWpw7zNkI for an example of generation loss in AVIF files compared to other image types). The most popular pictures (the pictures that are saved and sent again the most often: the memes, the spectacular photoes, the screenshots of awesome news, etc.) would become the most affected, the most “punished” by the quality loss; and they don't deserve that. Therefore recompression efforts on the server side are likely to incentivize unofficial clients to create AVIF files of exorbitant quality and filesizes (when compressing PNG-to-AVIF, for example) and thus to lengthen the delivery in order to ensure that the only significant quality loss is on the server side.

➋ Server-side recompression is costly. First of all, it involves the expenditure of the precious server-side CPU cycles (and these are so precious that Telegram intentionally refrains from GIF-to-MP4 recompression of files greater than 10 megabytes despite the obviously larger filesize-related gains for them). In addition to that, and perhaps more importantly, server-side recompression also generates (because of the generation loss) many files containing the same image on different stages of recompression and thus the expenditure of server-side storage for all of these files. (Telegram would not be able to deduplicate that storage and lessen the cost even if it involves some content-addressable filesystem because formally such files are different before and after the recompression.)

➌ Automatic compression is not very intellectual. The software is likely to try only one setting of the encoder (or maybe two or three more settings if the result of the first compression does not fit in some self-imposed limit) because it prioritizes fast delivery. And usually that is correct, that is the priority. Telegram users, however, can go much further if necessary. For example, it's not unlikely for digital artists (or for authors of some photo documentary, or for hardcore fans visually quoting their beloved masterpieces, etc.) to accept slower encoding for better quality, or to play with encoder's settings for dozens of minutes, or even to find newer or experimental encoders (that would never make it to Telegram apps) with different settings and algorithms if they are able to reach somewhat better AVIF quality within the same public set of constraints. Of course, that may happen only if that set of constraints is indeed public, and obeyed, and the results are not ruined by further recompression.

Refraining from AVIF-to-AVIF recompression, Telegram should limit the server-side image processing to a few simple (not CPU-intensive) tasks, such as:

⒈ Privacy protection by removing metadata (such as geotags) from the images.

⒉ Steganography suppression by removing behind-the-tail data (similar to RARJPEG) from the images.

⒊ Rejecting the images that won't fit in the enforced constraints.

It's okay for Telegram to enforce many constraints on AVIF images as long as the rules are public, for example:

① “Filesize shall not exceed 2 MB” (such is the current rule for stickers in WebP files).

② “File shall not contain more than 6553600 pixels” (such is the current rule for stickers in WebP files in Telegram Desktop).

③ “The number of bytes shall not exceed the half of the number of pixels” (if Telegram decides to limit the quality of smaller files).

If the image does not fit, then it might be silently “sent as a file” (for example, that is exactly what currently happens if a WebP file is larger than 2 MB and thus deemed unfit for a sticker in Telegram) or rejected with an error.

When a PNG file is being sent, Telegram should offer PNG-to-AVIF compression as an alternative to PNG-to-JPEG and probably even prefer the former.

Telegram should also consider using AVIF images (instead of JPEG images) where recompression is desirable: AVIF thumbnails, AVIF small avatars, AVIF previews (under messages that refer to images or to illustrated web pages), etc.

Telegraph (the site, not the Graph Messenger) should also support AVIF images and let its users upload AVIF files or embed them by URLs pasted on empty lines. The uploaded AVIF files (like the already supported PNG uploads) should not be recompressed after upload or face worse limits than the usual 5 megabytes.

Moritz May 17, 2021

When it´s license free, it´s a good addition to WebP

Сергѣй Юрьевичъ Соколовъ May 17, 2021

Why “when it's license free”, what's wrong with the https://aomedia.org/license/

Сергѣй Юрьевичъ Соколовъ Oct 11, 2021

AVIF support becomes wider in October 2021:

① Android 12 is released and it supports AVIF: https://android-developers.googleblog.com/2021/10/android-12-is-live-in-aosp.html

② Firefox 93 is released and it supports AVIF: https://www.mozilla.org/en-US/firefox/93.0/releasenotes/

Show next 6 comments