Каков «оптимальный» размер файла изображений JPEG по отношению к их размерам?

Я планирую написать скрипт, который будет сканировать более 100 000 изображений в формате JPEG и повторно сжимать их, если они «слишком велики» с точки зрения размера файла. Сценарий — это простая часть, но я не уверен, как классифицировать изображение как «слишком большое».

Например, есть изображение размером 2400x600 пикселей с размером файла 1,81 МБ. Команда Photoshop «Сохранить для Интернета» создает файл размером 540 КБ с качеством 60 и теми же размерами. Это примерно 29% от исходного размера.

Теперь я думаю о том, чтобы использовать эти цифры в качестве ориентира. Что-то вроде 540 КБ / (2400 * 600 / 1 000 000) = 375 КБ на мегапиксель. Любое изображение большего размера считается большим. Это правильный подход или есть лучший?

Редактировать 1: изображения должны быть оптимизированы для отображения на веб-сайтах.

Редактировать 2: я могу определить желаемое качество вывода, экспериментируя, мне нужно знать, являются ли изображения большими с точки зрения размера файла по сравнению с размерами и должны быть сохранены в более низком качестве.

@xiota размер полученного файла не важен, если он составляет где-то около n КБ, где я точно не знаю n , но он должен быть намного меньше, чем у меня сейчас. Я планирую использовать одинаковое качество для всех изображений.
первый комментарий xiota должен быть ответом! Кстати, что у вас в приоритете? если по какой-то причине вам нужны только небольшие файлы, качество может иногда страдать. легко создавать неоправданно большие файлы jpeg без ощутимого прироста качества. обнаружение и повторное сжатие таких изображений — хорошая идея, просто используйте настройку качества jpeg, как сказал xiota.
@szulat изображения были созданы кем-то, кто не знал, что изображения нужно уменьшать для Интернета (люди, как правило, уходят с вашего сайта, если загрузка занимает много времени). Итак, в основном я хочу идентифицировать смехотворно большие файлы, которые можно было бы уменьшить, немного пожертвовав качеством.
"Оптимальный" для чего ? Даже фраза «использование в Интернете» в наши дни звучит несколько расплывчато. Будут ли предполагаемые зрители смотреть изображения на компактном телефоне? Смартфон большего размера? Планшет или планшет? Блокнот? Большой компьютерный монитор? 60-дюймовый 8K-телевизор? Джамботрон?
Если написание сценариев — это простая часть, вот что я бы попробовал в вашей ситуации: установить численно определенный предел, до которого сжатое изображение может отличаться от оригинала (например, сумма разницы яркости каждого пикселя). Начните с более низкого качества (например, 60), экспортируйте, и, если разница с оригиналом слишком велика, снова экспортируйте с более высоким качеством, пока ваше условие качества не будет удовлетворено (вам может потребоваться настроить расчет - используйте экспоненциальную шкалу или что-то более причудливое, чтобы получить лучший результат).
@Pavel Зачем пытаться изобретать колесо, используя менее эффективные и действенные методы? Используйте минимизатор JPEG, написанный разработчиками, которые понимают алгоритм JPEG и используют проверенные показатели сравнения изображений.
@xiota Почему бы не быть конструктивным и не связать его здесь? Я бы тоже приветствовал его, даже больше с некоторыми «проверенными показателями сжатия изображений», что я и предлагаю.
@Pavel Как называется проверенная метрика, которую вы предлагаете? Подтвержденный означает, что исследователи проверили алгоритм в различных контекстах, провели тесты AB и сравнили производительность с другими алгоритмами, чтобы убедиться, что он работает. Такие фразы, как «подкорректировать расчет» и «что-то более причудливое», указывают на подход ad hoc (придумывайте на ходу).
@xiota В вашем ответе в первом пункте указано то же самое, что и я. «Подтверждено» может означать «подтверждено для цели», что я имею в виду, или «подтверждено научными данными», что вы, кажется, имеете в виду. Я считаю, что ОП должен определить, что лучше всего соответствует его потребностям, а не мне, - поэтому я предлагаю осуществимое и проверенное решение и воздерживаюсь от высказывания абсолютных суждений, основанных на моей точке зрения. Я приветствую вас, чтобы сделать то же самое (и не буду обсуждать это дальше, так как это явно основано на мнении).
@Pavel Ваше определение подтвержденного эквивалентно утверждению, что «теория» является необоснованной гипотезой. Многие люди используют это слово таким образом, но это не то, что оно на самом деле означает. Поскольку вы заявляете, что не будете обсуждать дальше, я не жду ответа.

Ответы (8)

В среднем наилучшее качество JPEG составляет около одного бита на пиксель .

Это, конечно, будет варьироваться в зависимости от содержимого изображения, потому что некоторые типы графики (например, плоские области и плавные градиенты) сжимаются лучше, чем другие (шум, текст), поэтому слепое применение этого метода к каждому изображению не является надежным.

У вас также есть проблема с отсутствием несжатого эталонного изображения для сравнения, поэтому вы не знаете наверняка, каково текущее качество изображений, которые у вас есть, и насколько еще вы можете понизить качество, чтобы оставаться приемлемым. О качестве в определенной степени можно судить по таблицам квантования в JPEG, но это также ненадежный метод (в частности, оценка качества ImageMagick очень неверна для JPEG с пользовательскими оптимизированными таблицами квантования).

Сказав это, существует разумный практический подход:

  1. Выберите максимальную настройку качества JPEG, которой вы довольны (где-то в диапазоне от 70 до 85).
  2. Повторно сжимайте изображения до этого уровня качества.
  3. Если повторно сжатое изображение меньше более чем на ~10% , сохраните повторно сжатое изображение.

Важно не просто выбирать меньший размер файла, а вместо этого требовать значительного уменьшения размера файла. Это связано с тем, что повторное сжатие JPEG имеет тенденцию всегда незначительно уменьшать размер файла из-за потери деталей, вызванной характером JPEG с потерями и преобразованием в 8-битный RGB, поэтому небольшое уменьшение размера файла может привести к непропорционально большому падению качества, которое не стоит это.

Это именно то, что я сделал в конце. Я использовал один бит на пиксель в качестве руководства для фильтрации 30 000 изображений из 100 000+ и повторно сжал их с помощью imagemagick с качеством 85%. Если полученное изображение было более чем на 50% меньше, я сохранял новое. В моем случае это сработало, потому что «большие изображения» были созданы с помощью Photoshop с использованием 100% качества. Остальные 70 000+ изображений были в порядке с точки зрения размера файла, и их повторное сжатие не привело к достаточной экономии (в процентном отношении) или была заметна потеря качества.
Мне нравится ваш второй абзац, но поддерживаете ли вы эмпирическое правило один бит на пиксель (24-кратное сжатие), которое вы используете?

Размер файлов, сжатых с помощью JPEG, зависит от сложности изображения. Попытка управлять размерами файлов так, как вы описываете, приведет к сильно различающемуся восприятию качества изображения.

Вместо этого рассмотрите следующие варианты:

  • Достаточно хороший подход.  Используйте параметр качества, который вы считаете приемлемым, например 75. Сравните размер результата с исходным изображением и сохраните файл меньшего размера. См. Какое качество выбрать при конвертации в JPG?

  • Используйте минимизатор JPEG , например JPEGmini или jpeg-recompressиз jpeg-архива . По сути, они предназначены для того, чтобы делать то, что вы, кажется, пытаетесь сделать, но с большей осведомленностью о внутренностях алгоритма JPEG.

  • Создавайте миниатюры разных размеров , как предлагает Натанкахилл , с точки зрения веб-разработчика.

Или, если вы хотите «экстремально» минимизировать размер JPEG, guetzli . Обратите внимание на требования к памяти и времени.
Я пробовал гецли, но не был очень впечатлен. Это очень медленно и только уменьшает размеры примерно на 20-30%. С jpeg-recompress файлы могут быть уменьшены на 80% с помощью алгоритма smallfry.

Нет. Это неправильный подход.

Размер файла в пикселях, да, как-то связан с конечным весом, но это не единственный фактор.

Сделайте тест. Возьмите полностью белый файл тех же 2400x600px и сохраните его в формате JPG.

Теперь сделайте фотографию леса (те же 2400x600px) с большим количеством деталей и сохраните ее. Этот файл будет больше при тех же настройках сжатия.

Окончательный размер зависит от этих 3 факторов:

  • Размер пикселя
  • Параметры сжатия
  • Контент (детализация и сложность изображения)

Таким образом, вы не можете и не должны определять вес на основе размера пикселя.

Но я понимаю вашу проблему.

Без анализа текущего сжатия изображения трудно определить «оптимальный» вес (относительно наблюдателя или использования изображений).

Вы, вероятно, можете определить настройку сжатия и повторно сжать «все». Я не знаю, хотите ли вы сделать это перед «загрузкой», что, вероятно, сэкономит вам больше времени, чем сохранение, пропускающее некоторые из них.

Есть несколько инструментов, которые анализируют изображение и вычисляют текущую степень сжатия. Но я сомневаюсь, что это так важно.

Я понимаю часть о белом изображении против изображения леса. Не могли бы вы предложить мне взять случайную выборку изображений, повторно сохранить их с помощью фотошопа (качество 70) и использовать в качестве эталона самое большое соотношение пикселей и размера файла? Я предполагаю, что те, у кого более низкий коэффициент, будут теми, у кого меньше деталей.
По поводу вашей последней фразы. Коэффициент сжатия на самом деле примерно соответствует тому, что вычисляет OP , поскольку он jpeg size / raw sizeи составляет 3 октета для 24-битного цветового пространства RGB. И, как вы сами говорите, этой метрики недостаточно, чтобы определить, достаточно ли сжато изображение. raw size = pixel size * number of pixelpixel size
@SalmanA Нет, я бы посоветовал вам вообще отказаться от этого подхода. Файлы JPEG настолько велики, насколько это необходимо для обеспечения заданного качества. Ваше предложение увидеть, насколько велико самое большое изображение в вашем образце с качеством 70%, просто выбирает уровень сложности изображения и говорит: «Все, что сложнее, чем это, слишком сложно и будет ухудшено». Однако, если почти все изображения меньше этого порога при качестве 70%, в чем проблема с небольшим количеством «слишком больших» файлов?
Похоже, это соответствует выводу, к которому я пришел, когда рассматривал подход к определению того, какая из серии фотографий одного и того же объекта, но с разным разрешением и качеством, была «лучшей» (т. е. наиболее близкой к оригиналу) картинкой.

Веб-разработчик здесь. Вот как я бы подошел к этому:

1. Определите размеры отображаемого изображения и требуемые разрешения экрана.

Ваша первая задача — определить, с каким размером пикселей будут отображаться изображения. Это фотографии товара в интернет-магазине? Фотогалерея? Фотографии профиля пользователя? Несколько разных размеров? Составьте список размеров в пикселях, которые вам понадобятся. Проверьте, нужны ли вам изображения @2x для экранов с высоким разрешением, таких как последние модели телефонов и планшетов.

2. Используйте сценарий миниатюр для создания новых файлов изображений.

Они называются сценариями миниатюр, но их можно использовать не только для миниатюр. Скриптов много или можно написать свой. Не изменяя размер исходных файлов, вы можете сделать это заново, если допустите ошибку в своем сценарии или со временем поймете, что вам нужно изображение с более высоким разрешением. Обычной практикой является указание суффикса в имени выходного файла. Например:

lena.jpg (Original, 2000x3000)
lena-thumb.jpg (100x150)
lena-thumb@2x.jpg (200x300)
lena-product.jpg (400x600)
lena-product@2x.jpg (800x1200)

3. Сжать.

Сценарий эскиза должен указывать сжатие jpg при вырезании новых файлов изображений. Однако есть и другие минификаторы, которые могут еще больше уменьшить размер файла.

Вот как это будет решаться в будущем: попросите фотографов разместить оригиналы в высоком разрешении в каталоге, а затем используйте скрипт для создания меньших размеров (миниатюры разных размеров и более крупные для настольных компьютеров и мобильных устройств) и поместите их под www с URL-адресом. переписывание. Но сейчас у меня нет доступа к оригиналам.

В то время как ответ @ Rafael объяснил сжатие JPEG внутри и снаружи, я постараюсь ответить на ваш веб-сайт и загрузить проблематично.

Использование изображения на веб-сайте (для дизайна или контента) будет диктовать некоторые императивы: для чего будет использоваться мое изображение? Логотип, обложка, миниатюра, фотография в блоге, полноэкранная фотография для галереи... Кроме того, если вы используете ее для нескольких целей (например, фотография и ее миниатюра в галерее), вы хотите отклонить ее во всех требуемых размерах. Однако, если вы не создаете свой собственный веб-сайт, большинство современных веб-сервисов будут генерировать изображения меньшего размера из вашей более крупной картинки для использования на сайте.

Теперь, когда вы знаете назначение своего изображения, веб-сайт (или CMS, или интерфейсная платформа) всегда будет требовать максимального размера в пикселях, чтобы ваше изображение соответствовало. Логотипы могут иметь максимальный размер 600x600 пикселей, фоновое покрытие может быть максимальным размером 1280x720 пикселей, фотография содержимого для полноэкранного отображения 1920x1080 или исходное разрешение камеры для абсолютного сохранения деталей. Проверьте правильный размер на веб-сайте, на который вы хотите загрузить. Вы хотите сопоставить хотя бы один из максимального требуемого размера пикселя, в зависимости от соотношения, которое вы хотите достичь. Остерегайтесь, некоторые сервисы обрежут и растянут ваше изображение, если соотношение сторон не совпадает. В этом случае вам придется повторно обрезать изображение, чтобы оно соответствовало требуемому максимальному размеру и соотношению.

Затем веб-сайт может установить ограничение на размер файла (или нет, в зависимости от цели изображения). Что касается времени загрузки страницы, то чем светлее, тем лучше. В вашем примере изображения с высоким разрешением 2400x600 пикселей от 300 до 500 КБ — это вполне подходящий размер для времени загрузки. Изображения контента (например, фотографии) могут быть тяжелее, если этого требует цель изображения (например, полноэкранное отображение), вплоть до родного разрешения вашей камеры, если это необходимо. Если указание не указано, ограничение размера файла может быть трудно угадать, так как оно может зависеть от оборудования аудитории (мобильное, настольное...), качества сети в стране аудитории... Для максимального качества и обслуживания обрабатывайте фотографии одну за другой, чтобы получить минимальный размер файла без видимых артефактов. Для удобства или ускорения обработки измените размер сценария, используя общий удовлетворительный уровень сжатия (около 70 должно быть достаточно).Ответ @xiota также может быть тем инструментом, который вам нужен. Установите свой собственный стандарт здесь.

TL; DR цель изображения на веб-сайте является ключевой для изменения размера / степени сжатия.

То, что вы вычисляете, является средним сжатым размером пикселя изображения, если вы разделите его на необработанный размер пикселя (обычно 3 октета для 24-битного RGB), вы получите степень сжатия.

Это хорошая метрика, которая дает вам информацию о состоянии сжатия изображения, но ее недостаточно, чтобы судить о том, достаточно ли сжато изображение или нет, потому что степень сжатия не зависит только от профиля сжатия (алгоритм = JPEG, качество = 60/100), но также и на возможности сжатия изображения: разные изображения с одинаковым исходным размером и одним и тем же профилем сжатия дадут разный размер jpeg, потому что изображения более или менее легко сжимаются (пустое изображение очень легко сжимается, белое шума нет).

Из-за этого, а также из-за того, что «последний использованный» профиль качества не сохраняется в этом изображении (ни в метаданных, ни в структуре заголовка jpeg), наиболее часто используемый подход при повторной публикации изображений с целевым профилем размера/качества фактически состоит в том, чтобы просто повторно сжать ( и потенциально изменить размер) всего (автоматически) независимо от исходного состояния изображения.

Да, вы можете повторно сжимать, когда в этом нет необходимости, да, вы можете даже потерять место при повторном сжатии с профилем более высокого качества, но это крайние случаи, и в больших масштабах проще всего обеспечить профиль целевого качества. Конечно, вы хотите сделать это только один раз, чтобы постепенно не ухудшать изображения, и вам, вероятно, следует хранить две библиотеки изображений: исходную «нетронутую» и «для публикации / повторного сжатия».

Существует множество инструментов для повторного сжатия кучи файлов, вы также можете написать свой собственный сценарий и, используя правильный технический стек (в основном C++ и libjpeg), это может быть чертовски быстро даже для > 100 000 файлов.

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

Изображения JPG обычно передискретизируют цветность с соотношением 4:2:2 или 4:2:0 ( en.wikipedia.org/wiki/Chroma_subsampling#4:2:2 ), поэтому «сырые» пиксели, сжимаемые JPG, имеют 2x или в 4 раза больше пикселей яркости, чем в каждом канале цветности. (Пополам по горизонтали и, возможно, по вертикали). Возможно, вы захотите принять это во внимание при рассмотрении того, «насколько сжато» изображение. Но да, как вы сказали, это не лучший показатель для неизвестного содержимого изображения.
+1 за масштабирование. В какой-то момент вы получите лучшее качество изображения за счет уменьшения масштаба, чем за счет еще большего уменьшения количества бит на пиксель. В отличие от современных видеокодеков, таких как h.264 или h.265 (которые могут сигнализировать декодеру о необходимости большего сглаживания и устранения блочности) или версии неподвижного изображения HEIF, которая представляет собой I-кадр HEVC(h.265) , JPEG не поддерживает У него нет ничего из этого, и он просто станет блочным с множеством артефактов звонка, если вы будете голодать по битам. Таким образом, вам нужно уменьшить масштаб, а не просто уменьшить качество, если у вас есть входные изображения с очень высоким разрешением.
For example there is a 2400x600px image with a file size of 1.81MB.
Photoshop's save for web command creates a 540KB file at 60 quality and same dimensions.    
This is about 29% of original size.

Исходный несжатый размер составляет 2400 x 600 x 3 = 4 320 000 байт (4,1 МБ), поскольку 24-битный цвет всегда представляет собой три байта данных RGB на пиксель . Нет никакого способа обойти эту абсолютную истину.

Однако размер JPG также зависит от детализации изображения. Большие гладкие области (например, небо или окрашенные стены) сжимаются лучше, но области с большей детализацией (например, дерево, полное листьев) также не сжимаются. Так что абсолютного числового показателя не существует.

Но 540 КБ — это 0,540/4,1 = 13% от исходного размера 4,1 МБ . Это может быть 29% от предыдущего размера JPG, но это 13% от исходного несжатого размера. Так что это 1/8 исходного несжатого размера, что обычно считается «приличным» качеством. Не оптимальное, не максимальное качество, но в целом приличное, возможно, достаточно хорошее для некоторых целей. Просто говорю, что это уже мало.

Чем больше файл JPG, тем лучше качество изображения, а меньше размер, тем хуже качество изображения. Вы должны решить, что достаточно хорошо, но JPG никогда не бывает «слишком большим», так как качество изображения снижается при сжатии JPG. 24-битный цвет имеет три несжатых байта на пиксель.

Таким образом, решение состоит в том, хотите ли вы, чтобы он был маленьким или вы хотите, чтобы он был хорошим.

Но увеличение существующего JPG еще хуже, так как добавляется больше артефактов JPG, а когда он становится маленьким, данные изменяются, и он никогда не станет лучше.

Артефакты JPG обычно проявляются двумя способами: в виде видимых блоков 8x8 пикселей одного цвета в гладких областях без деталей или в виде видимых шероховатых краев вокруг краев деталей.

При редактировании и повторном сохранении JPG добавляются дополнительные артефакты JPG. Если это необходимо, рекомендуется всегда повторно сохранять файлы, чтобы они соответствовали исходным настройкам сжатия.

Число 4,1 МБ верно только при полном отсутствии сжатия, однако даже JPEG с идеальным качеством может иметь меньший размер файла из-за сжатия без потерь .
Да, именно поэтому я назвал это «несжатым», так начинается каждое цифровое изображение, что, конечно же, является фактическим и исходным размером данных, вот почему это важно. Да, даже самый высокий уровень JPG 100 сжимается значительно меньше, а не без потерь. JPG без потерь — это неправильное название. У нас нет программ, предлагающих это. Его использование называет это как-то иначе (Википедия говорит, что это DNG, а некоторые — Raw). Однако JPEG2 может предлагать сжатие без потерь, но у него есть другие проблемы, например, веб-браузеры не поддерживают отображение JPEG2, и фотоателье, вероятно, не принимают его.
Нет никакого способа обойти эту абсолютную истину. ... за исключением подвыборки цветности, которую использует JPEG. JPEG сжимается в цветовом пространстве YUV (яркость + два компонента цвета), а не в RGB. Обычно 4:2:2 или 4:2:0, уменьшая количество пикселей в каждом из двух каналов цветности в 2 или 4 раза. en.wikipedia.org/wiki/Chroma_subsampling#4:2:2 . После преобразования из RGB в YUV и субдискретизации эта информация о цветовом разрешении полностью исчезает и не является частью того, что JPEG тратит биты на кодирование. Если вы хотите посмотреть бит/пиксель, он должен быть в цветовом формате JPEG, который вы рассматриваете.
Давай, читай текст. Вторая абсолютная истина заключается в том, что он специально говорил и ссылался на «несжатый» и говорил, что 24-битный цвет всегда составляет три байта на пиксель. :)

«Сохранить для Интернета» в Photoshop на самом деле является довольно хорошим компромиссом между размером файла и качеством, поэтому, если у вас нет более конкретных требований, вам следует использовать его. Типичный совет для веб-разработчиков — придерживаться диапазона качества 50-70%. Конечно, есть исключения: вам понадобится качество 90-95% на логотипе компании, который всегда должен отлично выглядеть (или даже преобразовать его в формат без потерь), и снизить качество до 30% на большом, но едва заметном логотипе. видимый фон страницы.

Также не забудьте масштабировать изображения. Изображение 2400x600 будет отлично смотреться на дисплее 4K, но будет масштабировано на экранах меньшего размера, что приведет к потере пропускной способности канала передачи данных без улучшения визуального восприятия для пользователя. Проверьте шаблон веб-сайта, который вы будете использовать, чтобы узнать оптимальную ширину изображений. Как правило, на момент написания статьи это будет где-то около 1200-1300 пикселей (самое популярное разрешение см. здесь ).

Не забудьте сохранить оригиналы изображений, которые вы конвертируете в веб-качество. Если вам когда-нибудь понадобится переработать или распечатать этот материал, вы пожалеете, что он у вас только с качеством 60% и разрешением 1 Мпикс.

Каков «оптимальный» размер файла изображений JPEG по отношению к их размерам?
СпросиСетьПолитика конфиденциальности1y, 0v