Подскажите пожалуйста, может есть какие-то альтернативные способы скачать вложения? Не смогу я столько ждать

Вам предложили сделать это через unigram

Перепроверил, ошибся немного, в приватной всегда доступны 8/8 для редактирования, а блокируются они не из-за типа «группа»/«супергруппа», а из-за настройки приватности 😅

Увы, там нет функции экспорта

#лимиты

Узнать лимиты Telegram можно по ссылке

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

Поэтому радует появившееся в начале октября на канале Telegram Info сообщение о том, что в Telegram Desktop поддержка JPEG улучшилася до прогрессивной версии формата.

Ещё болѣе радует, что на одном этом не остановилось всё дѣло, а продолжило двигаться к ещё болѣе рѣшительнымъ улучшениям: на Гитхабе приуготавливаются дополнительные правки исходного кода, цѣль которых — замѣнить кодировщик JPEG, ранѣе в Telegram Desktop употреблявшийся, на улучшенный Фондом Мозиллы движок MozJPEG, способный создавать файлы JPEG меньшего объёма при равном качестве картинки (или при том же объёме файла сберегать качество картинки явно лучше, чѣмъ другие кодировщики) цѣною несколько бóльших вычислительных усилий.

Радует-то радует, а всё же не могу въ полной мѣрѣ порадоваться этим улучшениям: наперёд вижу мрачное, зловѣщее препятствие на этом пути к улучшению качества изображений в Телеграме — препятствие мощное и оттого способное, может быть, с непреоборимой силою перечеркнуть собою и обессмыслить всѣ, всѣ потуги и усилия дѣятельныхъ сторонников роста качества изображений.

Извѣстно, что в настройках у нѣкоторыхъ клиентов Телеграма (у альтернативных особенно — поглядите для примѣра на скриншот настроек чатника Telegraph, который по чату 10 октября пролетал) есть настройки, позволяющие задать размѣръ (в пикселах) и качество отправляемой картинки; вполне естественно поэтому, что два года назад (также в конце октября, но в 2018 году) один из пользователей предложил и Telegram Desktop оснастить какою-либо настройкою качества отсылаемых картинок. Он получил (хотя и не сразу, а только к середине 2019 г.) отклик от одного из участников разработки, и в том отклике говорилось, что наращивание качества отсылаемых картинок (а особенно приближение их качества к стопроцентному) не имѣетъ смысла, поскольку и на сёрверной стороне картинки также переужимаются — и, болѣе того, бóльшая часть сжатия картинок происходит именно на сёрвере.

Даже не знаю, способен ли я въ полной мѣрѣ передать то, насколько ужасен и сам смысл этого откровения, и его очевидные послѣдствія.

Во-первых, если бесполезно приближать качество картинки к стопроцентному (оттого что на сёрвере всё равно внесены будут потери), то вдвойне бесполезно заниматься внедрением прогрессивной версии формата и замѣной кодировщика на новый, потому что на сёрвере файл JPEG по-прежнему пересохраняться будет и непрогрессивно, и другим кодировщиком.

Во-вторых, что же такое тогда эта работа сёрвера по пересжатию ужé сжатых файлов JPEG? — кажется, есть основания повторить тот эпитет, которым в интервью 2007 года воспользовался Шанцев (тогдашний губернатор Нижегородской области), есть основания сказать, что по большей части это муда («無駄», что по-японски означает «пустая работа»).

Нетрудно догадываться, что Telegram не очень остро нуждается в экономии дискового пространства на стороне сёрвера, раз уж предѣльный объём файлов в июле нынешнего года был увеличен до двух гигабайтов, зато экономия вычислительных усилий на стороне сёрвера — дѣло совсем другое: объявив в сáмом начале 2016 года о перекодировании анимаций GIF в видеоформат MP4 (было объявлено, что при этом экономия объёма файла может доходить до 95%), Telegram принуждён был ограничиться только тѣми файлами GIF, объём которых не превосходит 10 мегабайтов, и съ тѣхъ поръ вот ужé пятый год как не отходит от этого самоограничения — стало быть, дальнѣйшее наращивание вычислительных усилий на стороне сёрвера было бы для Телеграма непосильным, то есть всѣ такие усилия Telegram принуждён экономить.

И вот на этом-то мѣстѣ, навѣрное, должны если не подпрыгнуть, то встрепенуться всѣ, всѣ тѣ пользователи Телеграма, которые обеспокоены были его будущностью и осаждали чат наш вопросами (иногда по нѣскольку раз въ недѣлю) о том, хватит ли Дурову денег на поддержание инфраструктуры Телеграма, да отчего до сих пор нѣтъ раздражающей рекламы, а вмѣсто того есть ещё болѣе (для кого-то) раздражающее отсутствие рекламы, порождающее собою гнетущую убеждённость в том именно, что Telegram не приносит ещё до сих пор никакой прибыли его основателям. А повод для того, чтобы подпрыгнуть и встрепенуться, есть: дѣло обработки изображений, сплошным потоком поступающих от сотен миллионов пользователей (нас тут 400 миллионов по августовскому подсчёту), гораздо сильнѣе влияет на баланс затрат и результатов, чѣмъ каждый из двух примѣров, приведённых въ послѣднемъ абзаце моего предшествующего сообщения.

Судите сами. Сильно ли выросли расходы Телеграма на хранение файлов, когда предѣлъ объёма файла возрос от полутора гигабайтов до двух? — выросли бы на треть, кабы так подрос каждый файл, а на практике многим хватает и меньшего объёма. Сильно ли выросли бы расходы Телеграма на обработку анимаций, если бы предѣлъ объёма GIF, преобразуемого в MP4, возрос бы от нынешних 10 мегабайтов до двадцати? — выросли бы не болѣе чѣмъ в два раза (поскольку вдвое больший файл GIF примѣрно вдвое дольше и оттого вдвое дороже обрабатывать, но многим хватало бы и меньшего объёма). И послѣдній вопрос: а сильно ли выросли бы расходы Телеграма на сжатие JPEG на сёрверной стороне, кабы и сёрверы (а не одни только клиентские программы) перевести на использование алгоритма MozJPEG для получения файлов JPEG болѣе высокого качества? — ну, сильно ли? — в полтора раза, в два раза, втрое, впятеро, вдесятеро? — нѣтъ, нѣтъ… в сорок пять раз с половиною, согласно оцѣнкѣ на сайте libjpeg-turbo.

Поэтому-то пишу в предшествующем сообщении: «на сёрвере файл JPEG по-прежнему пересохраняться будет другим кодировщиком» — непреодолимо высокою оказывается в этом случае цѣна централизации! На стороне клиентской программы потратить перед отправкою на сжатие картинки ½ секунды там, где раньше была сотая доля секунды — никто и глазом не моргнёт; но на сёрверной стороне закупить и взгромоздить не сóрок сёрверов, а сóрок сорокóв, с сопутствующими расходами на размѣщеніе, подключение, охлаждение, обслуживание и электричество — ѽ, тут не раз и не два придётся почесать в голове при мысли о том, что за мѣсяцъ расходуются такие деньжищщи, которых в противном случае хватило бы болѣе чѣмъ на три года с половиною! — а значит, дѣлать такое никто и не будет на сёрверной стороне. Можно изгнать из воображения эту ужасающую картину расточительства, можно наконец выдохнуть и расслабиться, не правда ли?

Нѣтъ, не правда! Не время, не время ещё расслабляться-то. Если только что в воображении своём вы всѣ готовы были (и небезосновательно, небезосновательно!) признать разорительною для Телеграма ту ситуацию, в которой обработка JPEG на стороне сёрвера усложнилась бы болѣе чѣмъ сорокакратно, то тогда должен же маятник качнуться и в обратную сторону, должен же возникнуть и противоположный вопрос: ну, а не способна ли сдѣлаться неожиданно спасительною для Телеграма та ситуация, в которой обработка JPEG на сёрверной стороне не усложнилась, а упростилась бы болѣе чѣмъ сорокакратно, так что на нѣсколько лѣтъ хватало бы тѣхъ денежных средств, которые прежде отводилися едва на мѣсяцъ такой обработки?

На словах выглядит увлекательно, но о чём рѣчь-то? — есть ли реальный способ такого (многодесятикратного!) упрощения сёрверной работы, над JPEG совершаемой? — есть, есть! — пусть сжатием файлов JPEG занимаются одни только клиентские программы (со всею совокупною мощью сотен миллионов пользовательских устройств), а сёрверы пусть по второму разу эту работу не дѣлаютъ, потому что такая работа — пустая работа (мудá, «無駄»), которая зря тратит дуровские денежки. На сёрверной стороне нужно только контролировать, правильно ли клиентские программы совершают сжатие JPEG; контроль-то и будет на ≈два порядка проще, чѣмъ JPEGование.

Очень важно, чтобы контроль, упомянутый въ послѣднемъ абзаце моего предшествующего сообщения, совершался совершенно гласным способом, то есть чтобы и для свѣдѣнія разработчиков клиентских программ (не только работающих в команде Телеграма, но и для разработчиков альтернативных клиентов, хотя бы даже и обладающих удивительными настройками отсылки изображений), и для свѣдѣнія пользователей были обнародованы всѣ тѣ простые дѣйствія (со сжатием не связанные), которые на сёрвере совершаются над файлами JPEG (ну, напримѣръ, ѿрѣзаніе лишних метаданных во имя бóльшей приватности, в особенности метаданных с географическими координатами фотосъёмки, а также ѿрѣзаніе хвостов файлов во избѣжаніе засовывания туда скрытых архивов, раздувающих объём, по принципу RARJPEG), и всѣ тѣ правила, которым файл JPEG должен соѿвѣтствовать для того, чтобы сёрвер счёл JPEG достаточно сжатым.

Первый шаг такого обнародования ужé сдѣланъ: общеизвѣстно, что картинки в Telegram по размѣру не должны выходить за предѣлы квадрата 1280×1280 пикселов.

Если Telegram желает, чтобы картинки не превосходили опредѣлённаго объёма (скажем, мегабайта или полумегабайта), то это требование также должно быть оглашено.

Если Telegram желает, чтобы отношение объёма файла JPEG к количеству его пикселов (среднее количество информации, приходящееся на один пиксел) также не превосходило опредѣлённаго значения (скажем, семь или пять битов на пиксел), то это требование также должно быть оглашено.

Вроде как на этом заканчивается список легко обнаружимых свойств хорошо сжатого файла. Но, безусловно, если въ дѣйствительности Telegram желает ещё бóльшего для того, чтоб счесть файл JPEG хорошо сжатым: чтобы команда magick identify -format "%[quality]" выдавала не слишком большое значение качества, чтобы цвѣтовая субдискретизация 4:2:0 была совершена, что угодно ещё другое — то и эти требования также должны быть оглашены.

Почему я пишу «очень важно»? — потому, что явствует цѣлый ряд крупных преимуществ.

Во-первых, как ужé было сказано, сёрверная часть разгрузится от задачи сжатия JPEGов почти полностью, за исключением разве что того сжатия, которого никак уж нельзя избѣгнуть — скажем, создания миниатюр JPEGов для альбомов — и которое вычислительно проще ввиду кратно меньшего числа пикселов.

Во-вторых, не бессмысленным, а вполне осмысленным и даже желательным станет наращивание качества отправляемых JPEGов (в заданных рамках хорошей сжатости) во всѣхъ официальных и неофициальных клиентских приложениях Телеграма: и переход на прогрессивный вариант формата, и замѣна кодировщика на MozJPEG выглядит гораздо лучше, когда результаты передаются по Сѣти «как есть» (не считая метаданных), без внесения дополнительной потери качества. Отойдёт в прошлое то (явно извращённое) положеніе дѣлъ, когда в настройках неофициального приложения повадно наращивать качество передаваемых файлов JPEG до упора (вообразите 100% на вышеприведённом скриншоте), чтобы замедлить накопление потерь качества цѣною замедления отправки изображений.

В-третьих, клиентские приложения, зная всё о требованиях, предъявляемых на сёрверной стороне, тоже научатся мудрому бездѣйствію во всѣхъ тѣхъ случаях, когда отправляемый пользователем файл JPEG сам по себѣ укладывается во всѣ требования, предъявляемые к его объёму и размѣру Телеграмом. Если всѣ клиентские приложения научатся и тому, что не надо переужимать картинки при сохранении их в JPEG (тут я укоризненно смотрю на Telegram Desktop), то мы всѣ войдём въ свѣтлое будущее совершенно избавленными от того ползучего накопления артефактов сжатия, которое превращает надежды на достоинства цифровизации в горькую насмѣшку, как подмѣтилъ Рэндалл Манро. Каждое изображение, сжатое при попадании в инфраструктуру Телеграма, будет во всю дальнѣйшую жизнь обходиться без переужатия. И популярные мемы, и зрѣлищныя фотографии, и скриншоты умопотрясающих новостей, циркулируя по каналам и группам в Телеграме, перестанут быть бичуемыми за свою популярность нынешним цифровым бичом их (накоплением артефактов от многократного сжатия JPEG), оставляющим уродливые рубцы на мѣстѣ прежней красоты.

Большинству пользователей достаточно будет тѣхъ трёх преимуществ, которые перечислены в моём предшествующем сообщении, чтоб пожелать той увѣренности в ненапряжном будущем сёрверов Телеграма и в неискажённом будущем изображений, которую может принести отказ от сёрверного сжатия 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 подумать.

😳

Вот да

Поехавший

В хорошем смысле.

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

В России хеллоуин будет?

Всем задание на каникулы, прочитать и написать эссе на тему «Как разгрузить сервера телеграм?»

😂

Ну че?

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