На какой стадии того пути, который очерчен двумя предшествующими сообщениями, располагается Twitter?
Наступил ли Twitter на грабли отказа от поддержки новых форматов и необходимости быстрого сжатия в ущерб качеству? — да, наступил: публикуемые файлы WebP автоматически перекодируются в JPEG (85 баллов качества из ста), и притом Нолан О'Брайен сообщил в январе 2019 года, что тогдашний твиттеровский кодировщик JPEG и в другом случае (при кодировании не WebP, а PNG в JPEG) напоминал собою libjpeg-turbo, работающий с этим же числом баллов качества (85 из 100) в режиме цвѣтовой субдискретизации 4:2:0 и постепенного «наведения на рѣзкость» (progressive encoding).
Наступил ли Twitter на грабли ограничения PNG и нечёткости правил? — увы, и в этом также замѣченъ.
Ещё в 2016 году мы видим в Твиттере обязательное перекодирование из PNG в JPEG для всѣхъ изображений, окромя прозрачных (потому что прозрачность в JPEG не поддерживается), и видим сообщество микроблоггеров наносящим ѿвѣтный удар: въ апрѣлѣ 2016 года создаётся translucent — средство для придания одному пикселу (в верхнем лѣвомъ углу изображения) небольшой прозрачности (0,4%), чтобы этим способом обдурить тогдашний движок Твиттера и отключить JPEGование обработанного этим способом изображения, сохранённого в формате PNG.
Я не слѣдилъ за происходящим, но вроде бы нѣкоторое время Twitter ужесточал требования, а поклонники PNG наращивали искусственную прозрачность. Это закончилось в феврале и марте 2019 года переходом на новый набор правил (дѣйствующій до сих пор), ориентирующийся на малый размѣръ или малый удѣльный объём файла PNG и совершенно игнорирующий количество прозрачных пикселов и степень их прозрачности. Обширные категории файлов PNG: малоразмѣрные PNG (900×900 пикселов и меньше), PNG с фиксированною палитрою, сѣрые PNG с небольшим числом оттѣнковъ сѣраго (однобитные, двухбитные, четырёхбитные) — объявлены были не подлежащими JPEGованию. (Узнав об этом в том же году, я порадовался.) Но для всѣхъ прочих файлов PNG обязательно происходило кодирование в JPEG, итог которого затѣмъ сравнивался с исходным PNG по объёму и публиковался вмѣсто него, если оказывался меньшим. Вы сознаёте, я надѣюсь, что это правило — нечёткое, опирающееся единственно на способности твиттеровского кодировщика JPEG, не доступного для скачивания пользователями, так что за предѣлами неJPEGуемых сортов PNG лишь экспериментально можно провѣрить, будет ли конкретный PNG оставлен «как есть» при публикации в Твиттере.
В 2020 год Twitter вступил с не менѣе ясными правилами и для JPEG, также заботящимися об исключении (въ нѣкоторыхъ разумных рамках) преобразования JPEG-в-JPEG с потерею качества. Теперь JPEG стали публиковаться «как есть», если одновременно выполняли четыре условия: не превосходили 4096 пикселов по большей стороне, не превосходили 5 мегабайтов, не тратили больше 8 битов на пиксел в среднем и не содержали в заголовке инструкцию о необходимости довернуть изображение (на 90° в ту или иную сторону или на 180°). Нетрудно видѣть, что эти правила чётко излагают желаемые ограничения и объёма, и размѣра, и частного ѿ дѣленія одного на другое. Сами по себе эти правила хороши, как и правила PNG — но контраст чёткости правил JPEG и нечёткости правил PNG создаёт обстоятельства взаимного проигрыша.
Микроблоггер, который желал опубликовать свой PNG, но нарвался на автоматическое перекодирование в JPEG, с 2020 года получил возможность стерѣть полученный JPEG (и всю свою микроблогозапись), а затѣмъ опубликовать заново, создав JPEG из PNG самостоятельно. Никто не мѣшаетъ ему выключить субдискретизацию и вообще придать этому JPEG максимум качества въ предѣлахъ 5 мегабайтов и 8 битов на пиксел. Но микроблоггер теряет время на попытку выложить PNG, а PNG теряет качество при любом преобразовании в JPEG (даже совершаемом на 100 баллах качества из 100 возможных и притом посредством кодировщика, ориентированного на качество — а не на скорость работы, как кодировщик самогó Твиттера), а Twitter принуждается хранить файл JPEG большего объёма, чѣмъ был PNG. Это и есть обѣщанная выше ситуация взаимного проигрыша.
Наступил ли Twitter на грабли отказа от поддержки новых форматов и необходимости быстрого сжатия в ущерб качеству? — да, наступил: публикуемые файлы WebP автоматически перекодируются в JPEG (85 баллов качества из ста), и притом Нолан О'Брайен сообщил в январе 2019 года, что тогдашний твиттеровский кодировщик JPEG и в другом случае (при кодировании не WebP, а PNG в JPEG) напоминал собою libjpeg-turbo, работающий с этим же числом баллов качества (85 из 100) в режиме цвѣтовой субдискретизации 4:2:0 и постепенного «наведения на рѣзкость» (progressive encoding).
Наступил ли Twitter на грабли ограничения PNG и нечёткости правил? — увы, и в этом также замѣченъ.
Ещё в 2016 году мы видим в Твиттере обязательное перекодирование из PNG в JPEG для всѣхъ изображений, окромя прозрачных (потому что прозрачность в JPEG не поддерживается), и видим сообщество микроблоггеров наносящим ѿвѣтный удар: въ апрѣлѣ 2016 года создаётся translucent — средство для придания одному пикселу (в верхнем лѣвомъ углу изображения) небольшой прозрачности (0,4%), чтобы этим способом обдурить тогдашний движок Твиттера и отключить JPEGование обработанного этим способом изображения, сохранённого в формате PNG.
Я не слѣдилъ за происходящим, но вроде бы нѣкоторое время Twitter ужесточал требования, а поклонники PNG наращивали искусственную прозрачность. Это закончилось в феврале и марте 2019 года переходом на новый набор правил (дѣйствующій до сих пор), ориентирующийся на малый размѣръ или малый удѣльный объём файла PNG и совершенно игнорирующий количество прозрачных пикселов и степень их прозрачности. Обширные категории файлов PNG: малоразмѣрные PNG (900×900 пикселов и меньше), PNG с фиксированною палитрою, сѣрые PNG с небольшим числом оттѣнковъ сѣраго (однобитные, двухбитные, четырёхбитные) — объявлены были не подлежащими JPEGованию. (Узнав об этом в том же году, я порадовался.) Но для всѣхъ прочих файлов PNG обязательно происходило кодирование в JPEG, итог которого затѣмъ сравнивался с исходным PNG по объёму и публиковался вмѣсто него, если оказывался меньшим. Вы сознаёте, я надѣюсь, что это правило — нечёткое, опирающееся единственно на способности твиттеровского кодировщика JPEG, не доступного для скачивания пользователями, так что за предѣлами неJPEGуемых сортов PNG лишь экспериментально можно провѣрить, будет ли конкретный PNG оставлен «как есть» при публикации в Твиттере.
В 2020 год Twitter вступил с не менѣе ясными правилами и для JPEG, также заботящимися об исключении (въ нѣкоторыхъ разумных рамках) преобразования JPEG-в-JPEG с потерею качества. Теперь JPEG стали публиковаться «как есть», если одновременно выполняли четыре условия: не превосходили 4096 пикселов по большей стороне, не превосходили 5 мегабайтов, не тратили больше 8 битов на пиксел в среднем и не содержали в заголовке инструкцию о необходимости довернуть изображение (на 90° в ту или иную сторону или на 180°). Нетрудно видѣть, что эти правила чётко излагают желаемые ограничения и объёма, и размѣра, и частного ѿ дѣленія одного на другое. Сами по себе эти правила хороши, как и правила PNG — но контраст чёткости правил JPEG и нечёткости правил PNG создаёт обстоятельства взаимного проигрыша.
Микроблоггер, который желал опубликовать свой PNG, но нарвался на автоматическое перекодирование в JPEG, с 2020 года получил возможность стерѣть полученный JPEG (и всю свою микроблогозапись), а затѣмъ опубликовать заново, создав JPEG из PNG самостоятельно. Никто не мѣшаетъ ему выключить субдискретизацию и вообще придать этому JPEG максимум качества въ предѣлахъ 5 мегабайтов и 8 битов на пиксел. Но микроблоггер теряет время на попытку выложить PNG, а PNG теряет качество при любом преобразовании в JPEG (даже совершаемом на 100 баллах качества из 100 возможных и притом посредством кодировщика, ориентированного на качество — а не на скорость работы, как кодировщик самогó Твиттера), а Twitter принуждается хранить файл JPEG большего объёма, чѣмъ был PNG. Это и есть обѣщанная выше ситуация взаимного проигрыша.