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

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

И так просто всё было бы, если бы каждый такой сайт устанавливал очень простые и ясные правила: каким является допустимый размѣръ каждой картинки (ширина и высота, выраженные в пикселах)? — каким является допустимый объёмъ ея (в байтах)? — а есть ли ещё установленные на всякий случай ограничения удѣльнаго объёма (количества битов, приходящихся на один пиксел в среднем)? — и одним этим ограничился бы. В таких-то простых правилах трудно было бы найти и лазейки (да и зачѣмъ). Но неизбѣжно начинается своего рода «скатывание по наклонной плоскости»:

① Если иллюстрация используется не только в готовом виде, то есть если на сайте гдѣ-нибудь предусматривается такая миниатюра (thumbnail), которую надобно жмякнуть мышóю для открытия полноразмѣрнаго изображения, то тогда сайту нужен миниатюризатор. Но движок миниатюризатора воспринимает ограниченное количество форматов графических файлов (потому что их поддержку реализует не сам, а полагается на возможности операционной системы, или языка программирования, или какого-нибудь графического пакета), поэтому наиболѣе новые форматы будут запрещены. (Напримѣръ, пакет imagemagick в системе Debian в настоящее время доставляет шестую версию ImageMagick и оттого не понимает формат AVIF. Ещё примѣръ: функция getimagesize в языке PHP получила поддержку AVIF только тогда, когда версия 8.2.0 этого языка была выпущена в декабре 2022 года. Но это современные примѣры — а если миниатюризатор сочиняли в прошлом десятилѣтіи, то тогда и поддержку формата WebP могли не обеспечить, а не только формата AVIF.)

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

③ Большинство юзеров радуется тому, что можно кидать на сайт иллюстрации, не глядя на то, каков их размѣръ и качество — сайт сам ужмёт, если ему надо. Удѣломъ узкого круга (увлечённых фотографов, цифровых художников, etc.) становится само знание о том, как самостоятельно подогнать картинку под объём, не слишком похѣривая качество.

④ Сайт сталкивается съ тѣмъ, что обратною стороною сокращения расходов на объём (траффик, хранение) изображений становятся расходы на переужатие изображений. Поневоле сайт должен сократить затраты процессорного времени (которые не бесплатны), поэтому он приходит к использованию таких кодировщиков изображений, которые силе сжатия предпочитают скорость работы (напримѣръ, libjpeg-turbo может работать в 34—59 раз быстрѣе, но при этом сжимать JPEG в среднем на 20% хуже, чѣмъ MozJPEG). Но если файлы получаются больше при равном качестве, то тогда их качество сильнѣе страдает при том (большем) сжатии, которое требуется для того, чтобы уложиться в прежнее (малое) ограничение объёма.

Такое падение качества ужé печально, но «дальше — больше».