Ну что, довольно мрачно прозвучали послѣднія абзацы моего предшествующего сообщения?
Во всяком случае, я не желал бы того, чтобы это выглядѣло как какая-нибудь угроза или ультиматум. Не я, а Telegram технически поставил себя в этакую не очень уютную ситуацию, закладываясь на нераспространённость стремления к большему качеству иллюстраций до такой степени, что даже пятипроцентная распространённость такого стремления среди пользователей ужé угрожала бы удвоить расходы на хранение иллюстраций. И хороший выход наружу из этой ситуации — только один: заблаговременное (то есть не требующее провѣрки загрузкою в Telegram) знание о том, когда иллюстрация будет принята «как есть», а когда окажется принудительно переужатою из JPEG в JPEG.
Это знание могло бы достигаться гласным отказом от сёрверного переужатия JPEG в случае небольших по размѣру или по объёму иллюстраций — я предлагал такой отказ болѣе двухъ лѣтъ назадъ, однако моё предложение до сих пор не было принято и реализовано.
Это знание также могло бы быть достигнуто, если бы пользователи у себя на компé способны были запускать то средство, которым сам Telegram пользуется для переужатия JPEG, и наглядно убеждаться в том, получается ли результат переужатия больше или меньше исходного файла, то есть будет ли этот файл принят «как есть» или будет для того нуждаться в самостоятельном дополнительном доужатии. Но, разумѣется, для того нужно знать достовѣрнѣйше, какое средство сжатия JPEG используется на сёрверной стороне. «Мы не знаем, что это такое — если б мы знали, что это такое! — мы не знаем, что это такое».
Ну хорошо. Мы не знаем. Но в каких случаях и с какой точностью можно догадываться о том, какое средство и с какими настройками использует Telegram для сжатия JPEG?
Кажется, у меня есть вариант ѿвѣта на этот вопрос: как О'Брайен уподобил твиттеровский кодировщик работе libjpeg-turbo, так поступлю и я с телеграмным кодировщиком и декодировщиком.
Установите libjpeg-turbo версии 2.1.5.1 (эта версия — наиболѣе послѣдняя, если не считать бета-версии) и обработайте провѣряемый файл такой командою:
\путь\к\djpeg -fast -dct float провѣряемый.jpg | \путь\к\cjpeg -progressive -quality 87 -outfile результат.jpg
Если результат получится больше по объёму, чѣмъ провѣряемый файл JPEG (или меньше, но не болѣе чѣмъ на 256 байтов разницы), то тогда очень высока вѣроятность того, что провѣряемый файл будет принят «как есть» Телеграмом (но не забудьте отправить файл из Telegram Desktop, чтоб надёжно исключить ещё и переужатие файла, совершаемое перед отправкою), а переужат на стороне сёрвера он не будет. Но что значит «очень высока вѣроятность»? — на этот счёт я немедля должен сдѣлать сразу нѣсколько уточнений:
① Точно ли эта команда имитирует результат сжатия на сёрвере? — нѣтъ, не точно! — но разница по объёму файла, как правило, не превосходит собою разницу между файлами JPEG, изготовленными с двумя сосѣдними настройками качества. Поэтому для подбора необходимого порогового качества часто годится.
② Почему libjpeg-turbo? — потому, что другого быстрого кодировщика JPEG ещё не было, когда создавали Telegram. По-видимому, Telegram пользуется если и не libjpeg-turbo, то каким-нибудь близким аналогом.
③ Почему 87? — потому, что исходный код Telegram Desktop использует это некруглое число. (Должно быть, разработчики сёрверных и клиентских программ сговорились об одном и том же количестве баллов качества, но используют разные кодировщики JPEG.)
④ Когда эта команда перестаёт давать пусть неточный, но хотя бы подходящий по объёму результат? — ну, напримѣръ, когда провѣряемымъ оказывается не «голый» JPEG, а снабжённый дополнительными заголовками метаданных, то тогда исчезает возможность полагаться не только на результат работы приведённой выше команды, но даже ещё и на предположение (всегда казавшееся неколебимо надёжным) о том, что Telegram не будет использовать «распухший JPEG» (результат переужатия из JPEG в JPEG, оказавшийся превосходящим исходный файл по объёму) и что, дескать, сравнение объёмов достаточно для предсказания поведения Telegram. Примѣръ этого — въ слѣдующемъ сообщении.
Во всяком случае, я не желал бы того, чтобы это выглядѣло как какая-нибудь угроза или ультиматум. Не я, а Telegram технически поставил себя в этакую не очень уютную ситуацию, закладываясь на нераспространённость стремления к большему качеству иллюстраций до такой степени, что даже пятипроцентная распространённость такого стремления среди пользователей ужé угрожала бы удвоить расходы на хранение иллюстраций. И хороший выход наружу из этой ситуации — только один: заблаговременное (то есть не требующее провѣрки загрузкою в Telegram) знание о том, когда иллюстрация будет принята «как есть», а когда окажется принудительно переужатою из JPEG в JPEG.
Это знание могло бы достигаться гласным отказом от сёрверного переужатия JPEG в случае небольших по размѣру или по объёму иллюстраций — я предлагал такой отказ болѣе двухъ лѣтъ назадъ, однако моё предложение до сих пор не было принято и реализовано.
Это знание также могло бы быть достигнуто, если бы пользователи у себя на компé способны были запускать то средство, которым сам Telegram пользуется для переужатия JPEG, и наглядно убеждаться в том, получается ли результат переужатия больше или меньше исходного файла, то есть будет ли этот файл принят «как есть» или будет для того нуждаться в самостоятельном дополнительном доужатии. Но, разумѣется, для того нужно знать достовѣрнѣйше, какое средство сжатия JPEG используется на сёрверной стороне. «Мы не знаем, что это такое — если б мы знали, что это такое! — мы не знаем, что это такое».
Ну хорошо. Мы не знаем. Но в каких случаях и с какой точностью можно догадываться о том, какое средство и с какими настройками использует Telegram для сжатия JPEG?
Кажется, у меня есть вариант ѿвѣта на этот вопрос: как О'Брайен уподобил твиттеровский кодировщик работе libjpeg-turbo, так поступлю и я с телеграмным кодировщиком и декодировщиком.
Установите libjpeg-turbo версии 2.1.5.1 (эта версия — наиболѣе послѣдняя, если не считать бета-версии) и обработайте провѣряемый файл такой командою:
\путь\к\djpeg -fast -dct float провѣряемый.jpg | \путь\к\cjpeg -progressive -quality 87 -outfile результат.jpg
Если результат получится больше по объёму, чѣмъ провѣряемый файл JPEG (или меньше, но не болѣе чѣмъ на 256 байтов разницы), то тогда очень высока вѣроятность того, что провѣряемый файл будет принят «как есть» Телеграмом (но не забудьте отправить файл из Telegram Desktop, чтоб надёжно исключить ещё и переужатие файла, совершаемое перед отправкою), а переужат на стороне сёрвера он не будет. Но что значит «очень высока вѣроятность»? — на этот счёт я немедля должен сдѣлать сразу нѣсколько уточнений:
① Точно ли эта команда имитирует результат сжатия на сёрвере? — нѣтъ, не точно! — но разница по объёму файла, как правило, не превосходит собою разницу между файлами JPEG, изготовленными с двумя сосѣдними настройками качества. Поэтому для подбора необходимого порогового качества часто годится.
② Почему libjpeg-turbo? — потому, что другого быстрого кодировщика JPEG ещё не было, когда создавали Telegram. По-видимому, Telegram пользуется если и не libjpeg-turbo, то каким-нибудь близким аналогом.
③ Почему 87? — потому, что исходный код Telegram Desktop использует это некруглое число. (Должно быть, разработчики сёрверных и клиентских программ сговорились об одном и том же количестве баллов качества, но используют разные кодировщики JPEG.)
④ Когда эта команда перестаёт давать пусть неточный, но хотя бы подходящий по объёму результат? — ну, напримѣръ, когда провѣряемымъ оказывается не «голый» JPEG, а снабжённый дополнительными заголовками метаданных, то тогда исчезает возможность полагаться не только на результат работы приведённой выше команды, но даже ещё и на предположение (всегда казавшееся неколебимо надёжным) о том, что Telegram не будет использовать «распухший JPEG» (результат переужатия из JPEG в JPEG, оказавшийся превосходящим исходный файл по объёму) и что, дескать, сравнение объёмов достаточно для предсказания поведения Telegram. Примѣръ этого — въ слѣдующемъ сообщении.