A contributor to Telegram Desktop has once said at https://github.com/telegramdesktop/tdesktop/issues/5317#issuecomment-502341782 that it's not useful to raise the quality of JPEG photoes compressed by client-side applications because “the server itself compresses the photos” and “most of the compression is performed by the server”.
Hence the suggestion that is very simple: Telegram should stop performing server-side JPEG-to-JPEG recompression because such recompression has several important demerits.
Server-side JPEG-to-JPEG recompression results in generation loss (see https://en.wikipedia.org/wiki/Generation_loss for the definition). 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.) are the most “punished” by the quality loss.
Server-side JPEG-to-JPEG recompression is likely to incentivize unofficial clients to create JPEG files of exorbitant quality (when compressing PNG-to-JPEG, for example) and thus to lengthen the delivery in order to ensure that the only quality loss is server-side.
Server-side JPEG-to-JPEG recompression is costly. 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 larger filesize-related gains for them). In addition to that, and perhaps more importantly, server-side JPEG-to-JPEG 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 should get rid of all that demerits: Telegram should rely solely on client-side JPEG compression. The only server-side JPEG processing should be simple (not CPU-intensive) tasks such as removing of geotags (for the sake of better privacy) and trimming the files' tails (to prevent any RARJPEG) and the inevitable check of images' parameters to enforce the simple set of rules that are imposed on client-side JPEG compression; and these rules should be made public.
For example, compressed images in Telegram cannot exceed 1280×1280 pixels, and thus server should reject client-sent JPEG images wider or higher than this limit with an error (instead of attempting to recompress).
For example, Telegram servers can reject large JPEG files with an error if the file is larger than, say, one or two megabytes.
For example, Telegram servers can reject JPEG files based on their bytes-to-pixels ratio, requiring no more than 6 or 7 bits (of the encoded files) per pixel on average (not to be confused with https://en.wikipedia.org/wiki/8-bit_color of the decoded images).
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.
S
Serhii Popov ️
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.
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]
Maybe offer conversion options in the client. Like video quality options for videos.
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.
Log in here to report bugs or suggest features. Please enter your phone number in the international format and we will send a confirmation message to your account via Telegram.
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.
But I think it's a nice default to rescale and recompress images so they don't take much space.
Its changelog at https://github.com/telegramdesktop/tdesktop/releases/tag/v3.5.6 says “Always try to save original photo bytes to disk”.
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).