Bugs and Suggestions

Telegram clients (both official and unofficial) are then expected to adhere to these public rules and also to refrain from any JPEG-to-JPEG recompression of any files that already abide by the rules. The goal here is to ensure that the image becomes immutable (does not degrade and multiply further) after having entered Telegram. The goal here is to make the joke of https://xkcd.com/1683/ no longer relevant in Telegram.

MozJPEG compression needs so much CPU time (45½ times, see https://libjpeg-turbo.org/About/Mozjpeg for details) that it is probably not affordable on Telegram servers or would require ridiculous amounts of Telegram's monetization. However, the collective ability of many hundred millions of client-side devices to shoulder (almost effortlessly) their individual parts of the cost of such better JPEG compression is quite obvious.

Client-side applications can afford being better at JPEG compression than Telegram servers. Telegram users, however, can go even further if necessary. A typical Telegram client can only try one default setting of JPEG compression (and then maybe two or three backup settings) because it's inclined to send its results faster. And when Telegram users (such as digital artists or authors of some photo documentary) are ready to try many more compression settings for the sake of better-looking images in their Telegram channels (and when they spend much more time than the usual user can tolerate before an image is sent; ten minutes, for example), that's exactly when they are able to reach somewhat better JPEG quality within the same public set of constraints. They could find and try some experimental luma-controlled method of color subsampling (such as https://github.com/kornelski/jpeg-compressor#subsampling for example) that any Telegram developer could not know about or could not implement; and their resulting JPEG files would still be accepted and published in Telegram if the current server-side JPEG-to-JPEG recompression is stopped and abolished.

It is important to keep in mind that engineers in Twitter are one year ahead in understanding the benefits of incentivizing user-side compression efforts: Twitter allows any JPEG to be posted through their Web site “almost as is” (without server-side JPEG-to-JPEG recompression; nevertheless, any geotags are removed for the sake of better privacy) if that JPEG does not exceed 4096×4096 pixels, and does not exceed 5 megabytes, and does not spend more than 8 bits on an average pixel (since January 2020, see https://twittercommunity.com/t/upcoming-changes-to-png-image-support/118695 for details). Telegram might decide to follow that example not only because the practice seems rational, but also because that's exactly what is habitual for many millions of “digital refugees from Twitter” that are coming to Telegram.

Likewise, Telegraph (the site, not the Graph Messenger) should also stop its own server-side JPEG-to-JPEG recompression. Telegraph should keep uploaded JPEG files “as is” (like it keeps uploaded PNG files already) and only impose the usual Telegraph's limit on filesizes (5 megabytes).

Telegram Desktop should also refrain from further client-side JPEG-to-JPEG recompression when its users save JPEG files. Any saved JPEG files should be saved exacty as they were received.

Serhii Popov Jun 18, 2021

You can send jpgs without recompression in Telegram already. Select pictures, tap three dots menu and select "Send without compression".
But I think it's a nice default to rescale and recompress images so they don't take much space.

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

Serhii Popov

A common case is that the picture, if passed through Telegram channels, has already been recompressed twice or thrice: once when sent, once again on the server side, maybe once again if saved from Telegram Desktop. If you need to repost that picture, can you decide that it's not compressed enough (despite all the previous attempts to compress it) and justify its further recompression by the argument “so it doesn't take much space”? — also that argument may already be invalid if Telegram uses some single-instance storage (see https://en.wikipedia.org/wiki/Single-instance_storage for the definition) and an exact copy of the file is much cheaper than the recompressed version.

Khaled [E] Dec 11, 2021

Maybe offer conversion options in the client. Like video quality options for videos.

Сергѣй Юрьевичъ Соколовъ Mar 9, 2022

Сергѣй Юрьевичъ Соколовъ

A fix for one of the aforementioned issues (“Telegram Desktop should also refrain from further client-side JPEG-to-JPEG recompression when its users save JPEG files”) is delivered in Telegram Desktop 3.5.6 beta.

Its changelog at https://github.com/telegramdesktop/tdesktop/releases/tag/v3.5.6 says “Always try to save original photo bytes to disk”.

Сергѣй Юрьевичъ Соколовъ Apr 30, 2022

A further improvement is delivered in Telegram Desktop version 3.6.0 (see https://github.com/telegramdesktop/tdesktop/commit/6805259f74a163ea851fee0e1ae743e81bf75c61 for details).

Telegram Desktop no longer recompresses a JPEG file before sending if the following four rules are obeyed by that JPEG:

① JPEG format is progressive,

② JPEG's width is 1280 pixels or less,

③ JPEG's height is 1280 pixels or less,

④ JPEG's filesize is 4 bits (or less) per average pixel.

Such JPEG files are nevertheless recompressed (JPEG-to-JPEG), but only once (on the server side).

30598 Cards

Log In