Які фактори спричиняють або запобігають «поколінню втрат», коли JPEG повторно стискаються?

Протягом багатьох років я вважав, що повторне стиснення файлів JPEG кілька разів поступово погіршить його якість, поки вони не стануть невпізнанним безладом, як це робить фотокопії фотокопій. Це інтуїтивно має сенс, оскільки JPEG - це формат втрат. Існують також інші запитання, які стверджують, що це так:

• Яка якість зображення втрачається при повторному збереженні зображення JPEG в MS Paint?

• Чи просто відкриття та закриття файлу JPEG знижує якість зображення?

Однак я також читав, що повторне стиснення JPEG на тому ж рівні якості не погіршить якість зображення. Це суперечить поступовій деградації, описаній в інших місцях.

Що технічно відбувається при повторному стисненні JPEG?  Що втрачається і як? Чи справді образ перетвориться на сніжний безлад, який раніше з'являвся на телебаченні? Що з тими відеозаписами, що показують зображення, що розпадаються після їх повторного стискання?

(Будь ласка, не просто махайте руками та звертайтесь до загальної концепції втрати.)

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

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

• Межі MCU залишаються недоторканими (8x8 блоків).

• Підсвідомість хроми вимкнено.

• Постійний DQT (однакова настройка якості).

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

Алгоритм стиснення JPEG

1. Перетворити кольоровий простір. При бажанні, декодують інформацію про кольорі (кольоровість підвибірки) (Lossy) . Якщо не зразок зразків, втрата інформації є результатом помилки округлення .

2. Сегментація. Розділіть кожен канал на 8x8 блоків (MCU = Мінімальна одиниця кодування). (Без втрат)

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

3. Дискретна косинова трансформація (DCT) на кожному MCU. Втрата інформації є результатом помилки округлення .

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

5. Зіг-Заг сканування. Впорядкуйте значення в кожному MCU у послідовність чисел за схемою зигзагу. Нулі, що виникли під час квантування, будуть згруповані разом. (Без втрат)

6. DPCM = диференціальна модуляція імпульсного коду. Перетворіть числові послідовності у форму, яку легше стиснути. (Без втрат)

7. RLE = Кодування довжини запуску. Послідовні нулі стискаються. (Без втрат)

8. Ентропія / кодування Хаффмана. (Без втрат)

Повторне стиснення JPEG

Зауважте, що зменшення тиску кольорових каналів та квантування - це лише навмисно втрачені кроки . Якщо поки що відхилити помилку округлення, всі інші кроки без втрат. Після того, як відбувається квантування, обернення та повторення кроку дає однакові результати. Іншими словами, повторна квантування (з тим же DQT) не має збитків .

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

Враховуючи оптимальні умови, повторне стиснення 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. Це пояснює, чому падіння якості значно більше, ніж різниця між початковими налаштуваннями.

Зміна більшої кількості налаштувань

Eeyore не раді, коли так 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 ітерацій майже як дивитися води закип'ятити. Можливо, хочеться подвоїти швидкість відтворення. Ось Eeyore після 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, налаштуйте камеру на максимально високу якість , навіть якщо ви не помічаєте різниці в початкових файлах. Дивіться, чи варто використовувати налаштування якості JPEG Premium 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 Index

ПРИМІТКА: багато людей, які вперше дивляться на значення 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

Поки що результати я не показуватиму, я вважаю за краще дозволити вам експериментувати зі своїми фотографіями. Маючи достатньо коментарів, я додам зразок.