Какие факторы вызывают или предотвращают «потерю поколений», когда JPEG повторно сжаты несколько раз? - Фотопедия
29 голосов
/ 27 июня 2018

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

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

Что технически происходит при повторном сжатии JPEG? Что теряется и как? Будет ли изображение действительно превратиться в снежный беспорядок, который раньше появлялся на телевидении? А как насчет тех видео, где изображения распадаются после многократного повторного сжатия?

(Пожалуйста, не просто махайте рукой и обращайтесь к общей концепции потерь).

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

Ответы [ 4 ]

31 голосов
/ 27 июня 2018

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

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

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

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

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


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

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

  2. сегментация. Разделите каждый канал на блоки 8x8 (MCU = минимальная единица кодирования). (Lossless)

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

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

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

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

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

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

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

Повторное сжатие 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, но, похоже, он больше не доступен. Вместо него я взял увеличенную версию и уменьшил ее до исходного размера (256х256). Затем я неоднократно сжимался до 75, пока не получил схождение. Вот результат (оригинал, 1, n, разница):

attempt to replicate mattdm

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

А как насчет @ тыс. Монтажа ?

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

attempt to replicate ths-montage

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

ths-color-shift

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

Путем изменения переменной 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 итераций:

11999 iterations, random DQT

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

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

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

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

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

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

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

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

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

20 голосов
/ 27 июня 2018

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

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

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

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

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

original, no jpeg compression

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

first jpeg

И вот что спас:

second pass

Эта единичная секунда сохранения приводит к значительному ухудшению!

И вот окончательное конвергентное изображение (8 проход):

converged jpeg

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

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

99% 9 times

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

75% once and then 99% once

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

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

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

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

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

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

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

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

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

5 голосов
/ 27 июня 2018

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

В качестве быстрой проверки здесь приведены некоторые 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.

4 голосов
/ 27 июня 2018

Ничего подобного экспериментам. Следующий скрипт 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

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

Добро пожаловать на сайт Фотопедия, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...