Какие факторы вызывают или предотвращают «потерю поколений» при многократном повторном сжатии файлов JPEG?

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

• Границы MCU остаются нетронутыми (блоки 8x8).

• Подвыборка цветности отключена.

• Постоянный DQT (такая же настройка качества).

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

Алгоритм сжатия JPEG

1. Преобразование цветового пространства. При желании понизьте дискретизацию информации о цвете (субдискретизация цветности) (с потерями) . Если нет субдискретизации, потеря информации является результатом ошибки округления .

2. Сегментация. Разделите каждый канал на блоки 8x8 (MCU = Minimal Coding Unit). (без потерь)

   Примечание. Если включена субдискретизация цветности, MCU могут эффективно иметь разрешение 16x8, 8x16 или 16x16 относительно исходного изображения. Тем не менее, микроконтроллеры по-прежнему состоят из блоков 8x8.

3. Дискретное косинусное преобразование (DCT) на каждом MCU. Потеря информации является результатом ошибки округления .

4. Квантование.  Значение в каждой ячейке MCU делится на число, указанное в таблице квантования (DQT). Значения округляются вниз, многие из которых становятся равными нулю. Это основная часть алгоритма с потерями.

5. Зигзагообразное сканирование. Переставьте значения в каждом MCU в последовательность чисел, следуя зигзагообразному шаблону. Нули, возникшие во время квантования, будут сгруппированы вместе. (без потерь)

6. DPCM = дифференциальная импульсно-кодовая модуляция. Преобразуйте числовые последовательности в форму, которую легче сжать. (без потерь)

7. RLE = кодирование длин серий. Последовательные нули сжимаются. (без потерь)

8. Энтропия/кодирование Хаффмана. (без потерь)

Повторное сжатие JPEG

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

В принципе, можно создать алгоритм передискретизации без потерь после первого прохода. Однако с реализацией в ImageMagick цвета могут резко измениться до того, как будет достигнуто устойчивое состояние, как видно на изображении.

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

Демонстрация (такая же настройка качества)

Я написал следующий bashскрипт, который использует ImageMagick для многократного повторного сжатия файла JPEG с заданной настройкой качества:

#!/usr/bin/env bash
n=10001; q1=90
convert original.png -sampling-factor 4:4:4 -quality ${q1} ${n}.jpg

while true ; do
   q2=${q1}            # for variants, such as adding randomness
   convert ${n}.jpg -quality ${q2} $((n+1)).jpg
   #\rm $((n-5)).jpg   # uncomment to avoid running out of space
   n=$((n+1))

   echo -n "$q2  "
   md5sum ${n}.jpg
done

Выполнив несколько сотен итераций, я пробежался md5sumпо результатам:

d9c0d55ee5c8b5408f7e50f8ebc1010e  original.jpg

880db8f146db87d293def674c6845007  10316.jpg
880db8f146db87d293def674c6845007  10317.jpg
880db8f146db87d293def674c6845007  10318.jpg
880db8f146db87d293def674c6845007  10319.jpg
880db8f146db87d293def674c6845007  10320.jpg

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

Я повторял это несколько раз с разными изображениями и настройками качества. Обычно достигается устойчивое состояние, и одно и то же изображение воспроизводится снова и снова.

А как насчет результатов @mattdm ?

Я попытался воспроизвести результаты mattdm с помощью Imagemagick в Ubuntu 18.04. Оригинал представлял собой необработанное преобразование в TIFF в Rawtherapee, но, похоже, он больше не доступен. Вместо нее я взял увеличенную версию и уменьшил ее до исходного размера (256x256). Затем я несколько раз пересжимал на 75, пока не получил конвергенцию. Вот результат (исходный, 1, n, разница):

Мои результаты другие. Без подлинного оригинала невозможно определить причину различия.

Как насчет монтажа @ths ?

Я пересжал изображение из левого верхнего угла монтажа до схождения на 90. Вот результат (исходник, 1, n, разность):

После включения субдискретизации цветности цвета меняются к моменту достижения устойчивого состояния.

Изменение среди небольшого количества настроек

Изменяя переменную q2, настройку качества можно ограничить набором равномерно распределенных значений.

q2=$(( (RANDOM % 3)*5  + 70 ))

Для небольшого количества вариантов настройки в конечном итоге может быть достигнуто равновесие , что видно, когда значения md5 начинают повторяться. Кажется, что чем больше набор, тем больше времени требуется и тем хуже становится изображение, прежде чем можно будет достичь равновесия.

Кажется, что в равновесии происходит то, что коэффициент DCT до квантования должен делиться на все (или большинство) квантовых значений. Например, при переключении между двумя DQT, где коэффициент DCT делится попеременно на 3 и 5, равновесие будет достигнуто, когда коэффициент DCT делится на 15. Это объясняет, почему падение качества намного больше, чем разница между исходными настройками.

Изменение среди большего количества настроек

Иа-Иа не в восторге, когда q2его меняют так:

q2=$(( (RANDOM % 9)  + 90 ))

Для создания видео используйте ffmpeg:

rename 's@1@@' 1*.jpg
ffmpeg -r 30 -i %04d.jpg -c:v libx264 -crf 1 -vf fps=25 -pix_fmt yuv420p output.mp4

Наблюдать за первыми 9999 итерациями почти все равно, что наблюдать за кипением воды. Возможно, потребуется удвоить скорость воспроизведения. Вот Иа-Иа после 11999 итераций:

Что, если границы MCU изменятся?

Если изменения происходят ограниченное количество раз, многократное повторное сжатие, скорее всего, достигнет устойчивого состояния. Если изменения происходят на каждой итерации, изображение, вероятно, будет ухудшаться так же, как при изменении DQT.

• Это то, что происходит в видеороликах, в которых вращается изображение с размерами, не кратными 8.

Как насчет редактирования?

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

Наибольшее падение качества изображения происходит при первом сжатии файла с заданной настройкой качества. Последующее повторное сжатие с той же настройкой не должно приводить к каким-либо изменениям, превышающим ошибку округления. Таким образом, я ожидаю, что циклы редактирования-повторного сохранения с заданной настройкой качества будут выглядеть как любое другое изображение, сохраненное с той же настройкой качества (пока границы MCU остаются нетронутыми и субдискретизация цветности отключена ).

А как насчет тех видео?

• Неправильная реализация JPEG? ( Пересохранение 500 раз с помощью Photoshop в 10/12. )

• Изменение настроек качества. (Большинство видео.)

• Нарушение границ MCU. (Обрезка или поворот )

• Другие маневры, которые снижают качество изображения или мешают работе алгоритма JPEG?

Могу ли я перезаписать мои оригиналы повторно сжатыми файлами JPEG?

Целесообразно сохранять резервные копии всех исходных файлов, но если вы случайно перезапишете один из них, ущерб, скорее всего, будет ограничен. Также было бы неплохо работать в JPEG с отключенной субдискретизацией цветности.

JPEG нельзя использовать для изображений, использующих более 8 бит на цвет.

Потери при повторном сжатии реальны, особенно при работе с более высокими уровнями сжатия JPEG.

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

Если вы пересохраните с низким уровнем сжатия (высокое качество, например, «100» в Gimp или 11 или 12 в Photoshop), любые вновь добавленные артефакты будет сложно заметить. Картинка от этого не улучшится , но и не сильно ухудшится. Однако это внесет изменения во все изображение.

В качестве быстрого теста я использовал ImageMagick для повторного сжатия изображения JPEG снова и снова на 75%. Образцы ниже загружены в виде файлов PNG, чтобы избежать дальнейшего повторного сжатия, и были удвоены в размере, когда я преобразовал в PNG, чтобы сделать эффект более очевидным. (Использовавшиеся в тесте оригиналы не дублировались.) Получается, что после восьми передискретизаций эффект сошелся к совершенно стабильному результату, когда повторное сжатие приводит к бит-в-битному идентичному файлу.

Вот несжатый оригинал:

Вот результат перехода на 75% JPEG:

И вот что пересохранилось:

Эта единственная секунда сохранения вызывает большое количество дополнительной деградации!

И вот окончательное совмещенное изображение (8-й проход):

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

Но вот то же самое с уровнем качества 99% после 9 проходов (точка, где он сходится, поэтому дальнейшие проходы идентичны):

Здесь разница едва заметна. (Я имею в виду это буквально; сравните их пиксель за пикселем с несжатой версией, и вы увидите, что отклонение — это просто очень небольшой случайный шум.) Итак, что, если я вернусь к этому первому изображению с размером 75%, а затем пересохраню с размером 99%? Ну, это, (после всего лишь один раз):

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

Об этих видео: я нашел это как главный хит Google. Обратите внимание, что в описании указано:

Вот что происходит, если вы многократно перекодируете изображение JPEG со случайными настройками высокого качества (85 или выше).

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

Во втором видео, которое я нашел , говорится:

Изображение JPEG было скопировано и повернуто на полный оборот для каждого изображения. [...] (596 действий "повернуть по часовой стрелке")

Итак, опять же, что-то было сделано, чтобы ошибки не накапливались.

В любом случае, для практического редактирования фотографий стоит упомянуть, что сохранение 75% один раз намного хуже, чем пересохранение 99% миллион раз . В моем примере артефакты на 75% настолько очевидны, что дальнейшая деградация похожа на сброс воды в океан. Если вы сохраняете на достаточно высоком уровне, чтобы эти артефакты на самом деле не были видны, хорошей стратегией будет повторное сохранение с исходными настройками. Конечно, если вы можете всегда работать с несжатыми оригиналами, вам лучше.

Если по какой-то причине вам приходится (или настоятельно предпочитаете) работать только с JPEG, настройте камеру на сохранение в максимально возможном качестве , даже если вы не заметите разницы в исходных файлах. См. Стоит ли использовать настройку качества Pentax Premium JPEG? подробнее об этом — не обязательно конкретно для Pentax.

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

В качестве быстрой проверки здесь приведены некоторые значения SSIM для операций, выполненных на тестовом изображении, содержащем комбинацию линейных и непрерывных функций. Я выбрал JPG95, потому что его учили использовать в школе Ad-photo, а JPG83 — потому что он распространен среди поставщиков цифрового контента.

• Сохранить изображение Tiff как JPG95 - .9989
• Сохранить изображение Tiff как JPG83 - .9929
• Пересохраните изображение JPG95 как JPG95 10 раз — .9998
• Пересохраните изображение JPG83 как JPG83 10 раз — .9993
• Пересохраните JPG95 как JPG83, затем сохраните как JPG95 - .9929.
• Пересохраните JPG95 как JPG83, затем JP83 в JP92, затем JPG92 в JPG86 — .9914

Таким образом, количество структурного сходства, потерянного при пересохранении при том же сжатии в 10 раз, составляет 1/10 от того, что теряется при сохранении с качеством от tiff. Однако потеря качества от изменения сжатия JPG даже один раз такая же, как потеря качества при сохранении этого изображения из Tiff в JPG.

Я проведу этот тест еще несколькими способами и обновлю.

Методология : В ImageJ:

1. Преобразование Tiff RGB в оттенки серого 8-бит
2. Сохраните JPG95 и JPG83 из Tiff Original
3. Выполните дальнейшие операции повторного сохранения, как указано
4. Загрузите сравнительные изображения и используйте плагин индекса SSIM.

ПРИМЕЧАНИЕ: многие люди, впервые рассматривающие значения SSIM, читают их как проценты и предполагают, что разница невелика. Это не обязательно правда. Значения SSIM следует сравнивать друг с другом, а не рассматривать как отклонение от 1.

Ничего похожего на некоторые эксперименты. Следующий скрипт bash (написанный для Linux, может работать на OSX, если у вас есть ImageMagick ):

• начиная с первого изображения (с именем step000.jpg)
• берет файл JPEG, добавляет белую точку (чтобы доказать, что это новое изображение) и сохраняет его как (без потерь PNG)
• берет PNG и повторно сжимает его как JPEG (поэтому мы никогда не сжимаем JPEG в JPEG и не можем предположить, что программа просто копирует закодированные блоки)
• создает изображение, которое показывает разные пиксели между двумя JPEG-файлами
• промойте и повторите, используя выходной JPG предыдущего шага

Результат таков:

1. нет больших потерь при высоком качестве JPG
2. ошибки округления в конце концов устраняются, после небольшого количества поколений вещи больше не ухудшаются.

Конечно, все это предполагает, что JPEG каждый раз сохраняется одним и тем же программным обеспечением с одними и теми же параметрами.

#! /bin/bash
# Runs successive JPEG saves on an image to evaluate JPEG losses

# convert & compare command from imagemagick
# if you use a recent version of IM, set these variables to:
# compare="magick compare"
# convert="magick convert"
convert=convert
compare=compare

dotradius=2
defaultsteps=10
defaultquality=90 # default quality for "convert"

function usage {
        echo "Usage: $0 [quality [steps]]"
        echo ""
        echo "Where:"
        echo "       - 'quality' is the quality factor of the JPEG compression "
        echo "          (1-100, 100 is best, default is $defaultquality)"
        echo "       - 'steps' is the number of successive steps to perform"
        echo "         (default is $defaultsteps)"
        echo ""
        echo "Produces:"
        echo "   - successive saves of a JPEG image to test JPEG-induced losses."
        echo "   - compare images with the original file and the 1st JPEG save."
        echo ""
        echo "Starts from a 'step000.jpg' file in the current directory."
        exit 1
}

[[ -n "$3" ]] && { usage ; exit 1 ; }
steps=${1:-$defaultsteps}
quality=${2:-$defaultquality}    
dotcolor="white" # change this if the top of the image is too clear

echo "Running with $steps steps with quality $quality"

for step in $(seq $steps)
do 
    echo "Step $step of $steps"
    src=$(printf step%03d $(( $step - 1 )) ) 
    dst=$(printf step%03d $(( $step )) )
    dif=$(printf diff%03d $(( $step )) )
    # dot coordinates
    let cxc="2 * $dotradius * $step"
    let cxr="$cxc + $dotradius"
    let cyc="$dotradius * 2"
    let cyr="$dotsradius * 2"

    $convert $src.jpg -fill white -draw "circle $cxc,$cyc,$cxr,$cyr" $dst.png
    $convert $dst.png -quality $quality $dst.jpg
    rm $dst.png
    $compare $src.jpg $dst.jpg $dif.jpg
done

Пока не буду показывать результаты, предоставлю вам поэкспериментировать со своими картинками. При наличии достаточного количества комментариев я добавлю образец.