Хотим что бы было в России

Иконки будут у всех.

Хэллоуин в Telegram

В Beta-версии Telegram для Android появились иконки в стиле Хэллоуина.

Ждём иконки и обновление стабильной версии мессенджера уже завтра.

#Android

Не знаю может будут может нет

Я тебе одно, а ты другое 🤦‍♂️

Не знаю может будут может нет

Хочешь сказать у всех появятся?

Они у всех есть/будут.
Есть (те, у кого бета), будут (те, кто обновит офф тг).

Они у всех есть/будут.
Есть (те, у кого бета), будут (те, кто обновит офф тг).

Beta у меня нту

Они будут у всех

Хочешь сказать у всех появятся?

Жду обновления

Большинству пользователей достаточно будет тѣхъ трёх преимуществ, которые перечислены в моём предшествующем сообщении, чтоб пожелать той увѣренности в ненапряжном будущем сёрверов Телеграма и в неискажённом будущем изображений, которую может принести отказ от сёрверного сжатия JPEGов и перенос обязанности сжатия на клиентские программы. Но и тѣ рѣдкіе среди нас пользователи, которые болѣе прочих заинтересованы в качестве изображений, поступающих в Telegram: фотодокументалисты, цифровые художники, авторы презентаций и им подобные — уж конечно, были бы рады скорѣе попасть в то будущее, в котором можно отправить JPEG по Телеграму «как есть», когда JPEG укладывается в заранее извѣстныя рамки размѣра, общего объёма, удельного объёма и всего такого. Клиентская программа, ориентируясь на потребности большинства пользователей, обречена имѣть нѣкій потолок качества: может запускать хороший кодировщик JPEG (такой, как MozJPEG под iOS), но пробовать только одно или два значения качества, чтоб не слишком задержаться с отправкою изображения. Но человѣкъ, сильнѣе обычного заинтересованный в качестве конкретного файла JPEG, может пробовать разные настройки качества гораздо дольше, чѣмъ средний пользователь готов бы был терпеть пред отправкою — скажем, десяток минут кряду — пока наконец не достигнет желаемого максимума качества в рамках, навязанных ему Телеграмом. Болѣе того: заинтересованный пользователь способен выйти за предѣлы простого перебора настроек и прибѣгнуть к такому алгоритму сжатия JPEG, который мы никогда не увидим в клиентских программах Телеграма — скажем, использовать экспериментальный яркостно-контролируемый метод цвѣтовой субдискретизации.

(Это хорошо понимают в Твиттере: там с начала 2020 года разрешили публиковать чѣмъ угодно сжатые файлы JPEG, лишь бы они укладывались в объём 5 мегабайтов, въ размѣръ 4096×4096 пикселов и не расходовали болѣе 8 битов на пиксел в среднем. Телеграму есть с кого брать примѣръ.)

Можно зайти и ещё далѣе: если сёрверы займутся одним только контролем объёма и размѣра файлов, то тогда, по идее, открывается несложный путь к началу употребления картинок ещё болѣе высокого качества, достигаемого употреблением алгоритмов, выходящих за предѣлы JPEG — употреблением форматов болѣе современных, чѣмъ JPEG.

Напримѣръ, ещё в январе 2015 года разработчики Телеграма распробовали достоинства формата WebP, упомянули его способность доставлять изображения впятеро быстрѣе, чѣмъ форматы, используемые в других мессенджерах, и съ тѣхъ пор поддержка WebP существует в каждом клиентском приложении Телеграма (даже в предназначенных для эппловских систем, гдѣ «родная» поддержка WebP появилась болѣе чѣмъ пятью годами позже — только нынешней осенью!), но используется только для передачи стикеров. Почему же достоинства WebP не используются при передаче обыкновенных картинок? Понять это не трудно: поглядите-ка, как налажена инфраструктура стикеров в Телеграме. Преобразование картинки в формат WebP происходит единожды (при попадании в стикерпак). В тот же момент совершается и контроль над её размѣромъ в пикселах. Дальнѣйшая доставка WebP происходит «как есть», и нигдѣ нѣтъ ненужного (и тягостного по усилиям и по послѣдствіямъ) перекодирования из WebP в WebP: ни на сёрверной стороне, ни при сохранении, ни при повторной отправке. Вам это ничего не напоминает? — вѣрно! — для WebP разработчики создали именно ту инфраструктуру экономия усилий и ненакопления артефактов сжатия, которой не существовало для обыкновенных картинок в Телеграме (и по сей день, через полдесятка лѣтъ, не существует!) и отсутствие которой помѣшало внедрить WebP в качестве алгоритма сжатия обыкновенных картинок и широчайше насладиться его достоинствами. Кроме того, предѣльный размѣръ стикера (512×512 пикселов) гарантирует ≈вшестеро меньшее количество пикселов, чѣмъ у картинок 1280×1280, и это опять же выглядит как мѣра строгой экономии вычислительных ресурсов, затрачиваемых при первоначальном сжатии изображения в формат WebP — затрачиваемых на стороне сёрвера, обслуживающего официальный стикербот.

Шире внедрив WebP, можно будет и про AVIF подумать.

))

Мне кажется D90 специально в нижнем регистре написал, потому что в верхнем может не влезать на маленьких экранах

У тебя есть канал в тг?

Большинству пользователей достаточно будет тѣхъ трёх преимуществ, которые перечислены в моём предшествующем сообщении, чтоб пожелать той увѣренности в ненапряжном будущем сёрверов Телеграма и в неискажённом будущем изображений, которую может принести отказ от сёрверного сжатия JPEGов и перенос обязанности сжатия на клиентские программы. Но и тѣ рѣдкіе среди нас пользователи, которые болѣе прочих заинтересованы в качестве изображений, поступающих в Telegram: фотодокументалисты, цифровые художники, авторы презентаций и им подобные — уж конечно, были бы рады скорѣе попасть в то будущее, в котором можно отправить JPEG по Телеграму «как есть», когда JPEG укладывается в заранее извѣстныя рамки размѣра, общего объёма, удельного объёма и всего такого. Клиентская программа, ориентируясь на потребности большинства пользователей, обречена имѣть нѣкій потолок качества: может запускать хороший кодировщик JPEG (такой, как MozJPEG под iOS), но пробовать только одно или два значения качества, чтоб не слишком задержаться с отправкою изображения. Но человѣкъ, сильнѣе обычного заинтересованный в качестве конкретного файла JPEG, может пробовать разные настройки качества гораздо дольше, чѣмъ средний пользователь готов бы был терпеть пред отправкою — скажем, десяток минут кряду — пока наконец не достигнет желаемого максимума качества в рамках, навязанных ему Телеграмом. Болѣе того: заинтересованный пользователь способен выйти за предѣлы простого перебора настроек и прибѣгнуть к такому алгоритму сжатия JPEG, который мы никогда не увидим в клиентских программах Телеграма — скажем, использовать экспериментальный яркостно-контролируемый метод цвѣтовой субдискретизации.

(Это хорошо понимают в Твиттере: там с начала 2020 года разрешили публиковать чѣмъ угодно сжатые файлы JPEG, лишь бы они укладывались в объём 5 мегабайтов, въ размѣръ 4096×4096 пикселов и не расходовали болѣе 8 битов на пиксел в среднем. Телеграму есть с кого брать примѣръ.)

Можно зайти и ещё далѣе: если сёрверы займутся одним только контролем объёма и размѣра файлов, то тогда, по идее, открывается несложный путь к началу употребления картинок ещё болѣе высокого качества, достигаемого употреблением алгоритмов, выходящих за предѣлы JPEG — употреблением форматов болѣе современных, чѣмъ JPEG.

Напримѣръ, ещё в январе 2015 года разработчики Телеграма распробовали достоинства формата WebP, упомянули его способность доставлять изображения впятеро быстрѣе, чѣмъ форматы, используемые в других мессенджерах, и съ тѣхъ пор поддержка WebP существует в каждом клиентском приложении Телеграма (даже в предназначенных для эппловских систем, гдѣ «родная» поддержка WebP появилась болѣе чѣмъ пятью годами позже — только нынешней осенью!), но используется только для передачи стикеров. Почему же достоинства WebP не используются при передаче обыкновенных картинок? Понять это не трудно: поглядите-ка, как налажена инфраструктура стикеров в Телеграме. Преобразование картинки в формат WebP происходит единожды (при попадании в стикерпак). В тот же момент совершается и контроль над её размѣромъ в пикселах. Дальнѣйшая доставка WebP происходит «как есть», и нигдѣ нѣтъ ненужного (и тягостного по усилиям и по послѣдствіямъ) перекодирования из WebP в WebP: ни на сёрверной стороне, ни при сохранении, ни при повторной отправке. Вам это ничего не напоминает? — вѣрно! — для WebP разработчики создали именно ту инфраструктуру экономия усилий и ненакопления артефактов сжатия, которой не существовало для обыкновенных картинок в Телеграме (и по сей день, через полдесятка лѣтъ, не существует!) и отсутствие которой помѣшало внедрить WebP в качестве алгоритма сжатия обыкновенных картинок и широчайше насладиться его достоинствами. Кроме того, предѣльный размѣръ стикера (512×512 пикселов) гарантирует ≈вшестеро меньшее количество пикселов, чѣмъ у картинок 1280×1280, и это опять же выглядит как мѣра строгой экономии вычислительных ресурсов, затрачиваемых при первоначальном сжатии изображения в формат WebP — затрачиваемых на стороне сёрвера, обслуживающего официальный стикербот.

Шире внедрив WebP, можно будет и про AVIF подумать.

Как же вы много настрочили, но кто это будет читать со старорусской грамматикой

Как же вы много настрочили, но кто это будет читать со старорусской грамматикой