Якщо зображення обертається без втрат, чому розмір файлу змінюється?

Я шукав методи обертання зображень без втрат і трапився з цим питанням, яке це досить добре пояснює:

Чи обертання "Windows Photo Viewer" без втрат?

Тож я створив 256 × 256 JPEG із випадковими пікселями (хмарний фільтр Photoshop), а потім повернув його за допомогою Windows Picture Viewer. Після обертання розмір файлу фактично збільшився, але лише при першому обертанні. Після кожного наступного обертання розмір файлу залишався статичним. Я знаю, що він обертається без втрат, тому що я обертав його кілька разів без помітної втрати якості, тоді як зображення, розміщене 257 × 257, оберталося 20 разів, стало дуже втратним.

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

Коли JPEG-зображення не обертається без втрат, цей остаточний шар кодування без втрат повинен бути скасований, розпаковані коефіцієнти DCT перетасовуються навколо, а потім перемішані коефіцієнти потрібно знову закодувати. Оскільки ефективність шару ентропійного кодування залежить від порядку коефіцієнтів DCT всередині кожного блоку, який обертає зображення, зміниться, не повинно дивуватися, що повернутий файл зображення може бути на кілька відсотків меншим або більшим від початкового.

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

• вибір арифметичного кодування (рідкісне, але потенційно більш ефективне, використовуване для патентування) проти кодування Хаффмана (простіше, стандартніше);
• вибір послідовного (кожен блок 8x8 пікселів кодується по одному) проти прогресивного (компоненти низької частоти всіх блоків кодуються перед компонентами більш високої частоти, як правило, трохи більш компактними) порядком кодування;
• вибір використання стандартних таблиць символів Хаффмана (швидший, простіший, може бути ефективнішим для дуже маленьких зображень) порівняно з спеціальними таблицями, оптимізованими для кожного зображення (як правило, більш ефективними для великих зображень, повільнішими і складнішими для кодування);
• якщо використовуються спеціальні таблиці Хаффмана, різні кодери можуть потенційно генерувати різні таблиці для одних і тих же даних зображень;
• різні деталі самого низького рівня кодування, такі, як і коли включати маркери перезавантаження в потік даних, також можуть відрізнятися між кодерами.

Крім того, "JPEG файли", з якими зазвичай працюють люди, містять дані зображень, стиснуті JPEG, загорнуті в JFIF або контейнер Exif , який поєднує дані зображення з одним або декількома блоками метаданих, і вводить власний набір ускладнень. Навіть якщо програмне забезпечення, яке обертає зображення, насправді не вносить істотних змін у метадані JFIF / Exif, просто перестановка даних може потенційно вплинути на розмір файлу на кілька байт.

Зокрема, метадані JFIF / Exif можуть містити одну або більше ескізів повнорозмірного зображення, а програмне забезпечення, яке обертає зображення, дійсно повинно відновлювати (або також без втрат обертати!) Ескізів, щоб вони відповідали новій орієнтації повнорозмірних зображень, розмір зображення. Це одне може легко пояснити спостережувану різницю розмірів.

Я пішов вперед і повторив експеримент, щоб побачити, чи зможу я зрозуміти, що відбувається.

Порядок

Я генерував випадкове RGB зображення 256 на 256 пікселів, використовуючи фільтр "Суцільний шум" у GIMP (Фільтри> Візуалізація> Хмари> Суцільний шум ...), використовуючи параметри за замовчуванням (показано нижче):

І результат:

Потім я зберегла зображення як JPEG, використовуючи налаштування за замовчуванням:

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

Для кожного з нижчеперелічених тестів я розпочав копію оригінального зображення і повернув (натиснув на кнопку повороту) відповідну кількість разів перед збереженням. Ось відповідні розміри ( ls -l -r):

                    size in bytes    last-modified date 
                          VVVVV        VVVVV
-rwxrwx--- 1 root vboxsf   6258 Nov  8 11:24 original.jpg
-rwxrwx--- 1 root vboxsf  23645 Nov  8 11:30 cw.jpg
-rwxrwx--- 1 root vboxsf  23636 Nov  8 11:30 cw-cw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:30 cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf   6258 Nov  8 11:27 cw-cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:31 cw-cw-cw-cw-cw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:29 ccw.jpg
-rwxrwx--- 1 root vboxsf  23636 Nov  8 11:29 ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf  23645 Nov  8 11:29 ccw-ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf   6258 Nov  8 11:27 ccw-ccw-ccw-ccw.jpg
-rwxrwx--- 1 root vboxsf  23649 Nov  8 11:30 ccw-ccw-ccw-ccw-ccw.jpg

Негайні спостереження

• Windows Photo Viewer (WPV) значно збільшує розмір; сума збільшення цього тесту приблизно в чотири рази!
• Усі нові зображення збільшуються приблизно до однакового розміру, але вони не є однаковими.
• WPV не перекодує і не повторно зберігає зображення, коли воно обертається кратним на 360 градусів. (Часова позначка 11:27 - це коли файли були вперше скопійовані.)

Використання cmp -lфайлів, які мають однаковий вміст, дозволяє нам бачити, де файли відрізняються.

robert@unity ../jpeg-rotate-test % cmp -l cw.jpg ccw-ccw-ccw.jpg
 2223  63  62
 2224  60  71
 2226  60  64
 2227  60  66
robert@unity ../jpeg-rotate-test % cmp -l cw-cw.jpg ccw-ccw.jpg
 2223  63  62
 2224  60  71
 2226  60  64
 2227  62  64
robert@unity ..jpeg-rotate-test % cmp -l ccw.jpg cw-cw-cw.jpg
 2223  62  63
 2224  71  60
 2226  64  60
 2227  61  64
robert@unity ../jpeg-rotate-test % cmp -l cw.jpg cw-cw-cw-cw-cw.jpg
 2221  60  61
 2223  63  61
 2224  60  66
 2226  60  61
 2227  60  61
robert@unity ../jpeg-rotate-test % cmp -l ccw.jpg ccw-ccw-ccw-ccw-ccw.jpg
 2223  62  63
 2224  71  60
 2226  64  65
 2227  61  64

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

Детальні спостереження

Для цього я використовував JPEGsnoop, щоб побачити, що саме було на зображеннях.

Оскільки результати є досить довгими, я пов’язаний з ними як суть . Ось підсумок відмінностей:

• GIMP використовує для метаданих лише сегмент APP0(JFIF) та COM(коментар). WPV залишає APP0сегмент недоторканим, але з цікавістю додає нульовий байт до коментаря (так що він закінчується нулем).

• WPV додає два APP1сегменти, які є метаданими Exif та XMP. Ці сегменти мають 4286 та 12726 байт відповідно. Разом на них припадає майже повне збільшення розміру файлів.

• GIMP виробляє прогресивний JPEG, тоді як WPV виробляє базовий (непрогресивний) JPEG. З цієї причини зображення GIMP має кілька сегментів сканування, тоді як зображення WPV має лише один. На мій досвід, прогресивний образ іноді трохи менший.

• GIMP використовував 1 × 1 кольорову підсистему, тоді як WPV використовував 2 × 2 підсимуляцію. Це змушує мене вважати, що WPV не використовує "справжнього" обертання без втрат, якщо тільки якимось чином не вдається виявити це чорно-біле зображення.

Щоб вирішити ці проблеми, я пройшов другий тест.

Порядок

Я дотримувався аналогічних кроків до першого тесту. Я створив випадкове зображення 256 × 256 RGB за допомогою фільтра шуму RGB (Фільтри> Ніс> RGB Ніс ...) з такими налаштуваннями:

Ось результат:

Я експортував файл у форматі JPEG, використовуючи такі налаштування:

Прогресивно вимкнено, але підсистема підсистем все ще встановлена ​​в 4: 4: 4 (що є іншою назвою для 1 × 1 підсистеми). Якість підвищено до 98.

Я скопіював зображення і повернув копію за годинниковою стрілкою; потім скопіював обернену версію і повернув цю копію проти годинникової стрілки, щоб ми могли безпосередньо порівняти якість між оригіналом та обробленою WPV копією.

Результати

-rwxrwx--- 1 root vboxsf 159774 Nov  8 16:21 original-random.jpg
-rwxrwx--- 1 root vboxsf 222404 Nov  8 16:24 cw-random.jpg
-rwxrwx--- 1 root vboxsf 222467 Nov  8 16:24 cw-ccw-random.jpg

Незважаючи на те, що приріст цього разу є відносно меншим (близько 40%), абсолютний приріст ще більший - близько 62 кБ. Це говорить про те, що WMV використовує менш ефективне кодування.

Я буду використовувати ImageMagick для порівняння двох зображень:

robert@unity ../jpeg-rotate-test % compare -verbose -metric AE original-random.jpg cw-ccw-random.jpg null:
original-random.jpg JPEG 256x256 256x256+0+0 8-bit sRGB 160KB 0.000u 0:00.009
cw-ccw-random.jpg JPEG 256x256 256x256+0+0 8-bit sRGB 222KB 0.010u 0:00.010
Image: original-random.jpg
  Channel distortion: AE
    red: 0
    green: 0
    blue: 0
    all: 0
original-random.jpg=> JPEG 256x256 256x256+0+0 8-bit sRGB 0.050u 0:00.020

Є нуль пікселів різні між оригіналом і копією поверненою. Отже, навіть якщо WPV не використовує "справжнього" обертання без втрат, він робить досить хорошу роботу. Я підозрюю, що знаю, що відбувається, і щоб пояснити, я трохи відволікаюсь на математику за стисненням JPEG.

Алгоритм стиснення JPEG розбиває зображення на блоки 8 × 8 пікселів. Кожен з цих блоків потім піддається дискретному косинусному перетворенню (DCT) . Отримані коефіцієнти DCT описують блок як суму хвиль різної частоти. Потім алгоритм "викидає" деяку інформацію у високочастотних хвилях, що відповідають шуму та дуже дрібним деталям. Процес декодування повертає DCT, додаючи збережені хвилі разом, щоб повернути блок.

Можна обертати "хвилі" DCT, фактично не скасовуючи та повторюючи перетворення (в основному ви перетворюєте всі горизонтальні хвилі на вертикальні хвилі і навпаки). Що, на мою думку, трапляється в WPV, це те, що зображення насправді декодується, обертається та повторно кодується. Під час процесу повторного кодування, оскільки розмір нашого зображення є кратним 8 в обох вимірах, кожен з нових блоків відповідає одному з оригінальних блоків. Що важливо, оскільки кожен блок не має високочастотних компонентів, алгоритм не викидає ніякої інформації, і знаходить саме ті компоненти DCT, які матиме "справжнє" обертання без втрат.

Нарешті, я ще раз перегляну складові файли JPEG. Результати знову пов'язані як суть . Порівняння двох:

• Зображення WPV містить додаткові 4286 + 2 байти метаданих Exif, 1 додатковий байт у коментарі та 12 726 + 2 байти метаданих XMP. Це загалом 17 077 байт додаткових метаданих. Для чого використовуються ці дані? Я зазирнув у файл зі своїм надійним шестигранним редактором та копією відповідних стандартів:

  • Метадані Exif структуровані як зображення TIFF, яке містить низку тегів (є спосіб більш складний, але я пропускаю його прямо). Більшість байтів у сегменті Exif містяться у двох однакових тегах із номером тегів EA1C(59,932 десятків). Цей номер тегу не задокументований ніде, де я його міг знайти. Обидва теги містять 2060 байт типу "невизначений", які є усіма нульовими байтами, крім перших шести ( 1C EA 00 00 00 08). Я поняття не маю, що це за мітки, чому їх два та чому їх потрібно по 2 кБ.

  • Метадані XMP - це фактично цілий вбудований XML-документ із простором імен та довгими UUID, який просто містить рядок версії WPV (що вже було у метаданих Exif). Однак на це припадає лише близько 400 байт. Залишок у сегменті - 122 повтори з 100 пробілів з наступним новим рядком . Це понад 12 000 байт повністю витраченого простору.

• Як і в попередньому тесті, і GIMP, і WPV використовують однакові таблиці квантування DCT. Це означає, що вони повинні обчислювати однакові коефіцієнти DCT, тому зображення точно такі ж. Я не впевнений, чи WPV просто використовує одні і ті ж таблиці квантування чи він копіює таблиці з вхідних даних.

• На відміну від попереднього тесту, на цей раз WPV використовує 1 × 1 піддиагностику, тому може бути фактично виявлення, що це кольорове зображення (або принаймні, що більш високі зразки необхідні, щоб без втрат перекодувати зображення).

• GIMP і WPV використовують різні таблиці Хаффмана (частина кроку кодування ентропії). Таблиці для WPV більше на 279 байт, і в одному випадку містять у 7 разів більше кодів.

  Переглядаючи статистику JPEGsnoop, ми можемо побачити, що деякі з цих кодів використовуються рідко. Наприклад, у ID: 1, Class: ACтаблиці із 119 визначених 16-бітних кодів фактично використовується лише 23. Загалом у версії WPV фактичний сегмент сканування на 28,5% більший.

Підсумок

• WPV може не робити «справжніх» обертів без втрат, але обертання, здається, практично без втрат.

• Додатковий розмір частково обумовлений фіксованою кількістю доданих метаданих, а частково через менш ефективне ентропійне кодування.

Інформація про версію:

• ОС (Linux) ( uname -a):

  Linux unity 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux
  

• ОС (Windows):

  

• GIMP (Linux): 2.8.14 (з пакета gimp, версія 2.8.14-1+deb8u1)

  

• Переглядач фотографій у вікні (відповідно до метаданих зображень):

  Microsoft Windows Photo Viewer 10.0.10586.0
  

^{EDIT : Ця відповідь була розміщена ще до того, як я зрозумів, що файли збільшилися в розмірі приблизно на 9 KiB (9055 байт для зображення 256 × 256, 9612 KiB для зображення 512 × 512).}

Ймовірно, що коли ви вперше обертали зображення, програма Windows Picture Viewer зробила одну (або обидві) з наступних речей:

1. Додано тег EXIF, який не був у вихідному зображенні JPEG (можливо, тег Орієнтація);
2. Змінена / додана інформація до тегу, який вже існував (можливо, теги "Обробка програмного забезпечення" або "Теги графічного програмного забезпечення").

Це збільшило розмір файлу через додатковий тег EXIF ​​(та / або додаткових даних до існуючих тегів).

Подальші обертання не збільшили розмір файлу, оскільки всі теги та / або дані тегів, які WPV додав би / змінили, вже були там. Змінено лише значення орієнтаційного тегу (можливо, також значення тегів дати / часу).

EDIT : Майже певно, що це пояснення не може нараховувати близько 9 KiB додаткових даних у файлі. Крім того, якщо немає будь-яких інших причин збільшення розміру, це пояснення передбачає, що збільшення розміру буде більш-менш постійним (модульно деякі різниці довжин між рядковими представленнями числових даних, ймовірно, на кілька байт). Це, очевидно, не те, що відбувається тут, принаймні, не повне пояснення.

Без зворотної інженерії jpeg en / decoder сказати точно неможливо. Насправді існує ряд стандартів jpeg і всупереч поширеній думці, не всі вони можуть бути змінені без повторного кодування.

Можливо, що перше збереження - це збиткове перезапис у свій улюблений смак jpeg, а наступні обертання - це просте налаштування метаданих або операція безпосередньо на таблиці DCT (що можливо для деяких схем кодування).

Збільшення розміру файлів може також включати деякі додаткові метадані, хоча 9k здається багато, можливо. Збільшення також може бути пояснено додаванням ескізу, який, можливо, не був присутній у висновку від GIMP. Ми можемо отримати більше інформації з файлів безпосередньо (до WPV і після).

У будь-якому випадку, спроба працювати безвідмовно з jpeg - це дійсно дурне доручення, оскільки це корисно лише з певними розмірами зображення, не всі декодери та кодери однакові, і це вимагає, щоб ці редактори працювали безпосередньо із вмістом jpeg, на який ви не можете розраховувати. справа ... Тільки тому, що це робиться зараз, це не означає, що це буде продовжуватися і надалі.

Ваша краща ставка - працювати з форматом без втрат і повністю уникати болю.

Обертання JPEG без втрат можливе без введення граничних артефактів, якщо розміри зображення кратні розміру блоку (як правило, [/ завжди?] 8). Перегляньте сторінку man jpegtran (вибачте, що я не маю гарного канонічного посилання на неї; сміливо відредагуйте, якщо ви знайдете його), щоб отримати детальну інформацію про те, що стосується:

Транспонування перетворення не має обмежень щодо
розмірів зображення . Інші перетворення діють досить дивно, якщо розміри зображення не кратні розміру iMCU (зазвичай 8 або 16 пікселів), оскільки вони можуть трансформувати лише цілі блоки даних про коефіцієнт DCT потрібним способом.

Поведінка за замовчуванням jpegtran при перетворенні зображення непарного розміру
призначена для збереження точної оборотності та математичної
послідовності набору перетворень. Як зазначалося, транспонінг
може перевернути всю область зображення. Горизонтальне дзеркальне відображення залишає будь-який частковий стовпчик iMCU у правому краї недоторканим, але може перевернути всі рядки зображення. Аналогічно, вертикальне дзеркальне відображення залишає будь-який частковий рядок iMCU в нижньому краї недоторканим, але може перевернути всі стовпці. Інші перетворення можуть бути побудовані як послідовності операцій транспонування та перевертання; для послідовності їх дії на крайових пікселях визначаються такими ж, як і кінцевий результат відповідної послідовності переміщення та перевертання.

Для практичного використання ви можете відмовитись від будь-яких неперетворюваних
крайових пікселів, а не з дивною смужкою уздовж
правого та / або нижнього краю перетвореного зображення. Для цього додайте перемикач -trim:

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

Я не маю однозначної відповіді, але деякі можливі теорії того, чому це сталося. Деякі типи файлів працюють таким чином, що два різних коду для зображення цього типу файлів не обов'язково створюють різні зображення. Наприклад, тип файлу PNG працює таким чином, оскільки він забезпечує прозорий фон, але зображення з прозорим фоном і таке, що є тим самим, за винятком того, що той самий фон білий, виглядає точно так само. Кажуть, що файл зображення стискається, якщо він займає менше 3 байт пам'яті на піксель. Я вважаю, що за винятком файлів з прозорим фоном, жоден два файли PNG не генерують абсолютно однакове зображення. Коли ви коли-небудь зберігаєте зображення у форматі PNG, він перетворює його в код, який генерує оригінальне зображення, за винятком дуже незвичайних зображень, таких як одне, де кожен піксель є випадковим кольором усіх 2 ^ 24 кольорів, код займе менше пам’яті, ніж 3 байти на піксель, тому заощадження, оскільки, як кажуть, PNG стискається без втрат. З іншого боку, для економії пам’яті з коду файлу зображень JPEG можна генерувати лише певні зображення. Напевно, існує декілька типів файлів JPEG, і я не знаю, чи має будь-який з них властивість того, що два різних зображення цього типу файлів можуть генерувати абсолютно однакове зображення. Я припускаю, що кілька разів ви просто обертали зображення, а потім зберігали його як JPEG і надаєте пояснення того, що сталося за умови, що це ви зробили, я не знаю, чи це правда. Обертання, яке ви здійснили, не має втрат, якщо є спосіб повернути той самий код файлу зображення, який ви мали до того, як повернути його та зберегти. Ви можете не помилитися, що ви дійсно робили обертання без втрат. Якщо це справді було без втрат,

Причин тому кілька

спосіб кодування та стискання зображень змінить розмір просто через алгоритм стиснення. ви можете перевірити це, збереживши його як растрове зображення, а потім обертаючи його. У цьому форматі чи будь-якому необробленому форматі розмір повинен залишатися однаковим. Якщо цього не відбувається, програма збереження зображення додає нові дані, можливо, якісь метадані чи щось.

Але чому ви обертаєте jpeg 20 разів?

Через те, як працює стиснення зображень . Будь-який формат, наприклад PNG або JPG, взагалі не зберігає розмір файлу після обертання.

Для компресора обернене зображення - це просто інше зображення, завдяки тому, як працює евристичний компресія , немає гарантії, що він буде стискати обернене зображення однаково .

Звичайно, якщо стиснення без втрат, якщо ви обертаєте зображення 4 рази в четвертий раз, зображення знову таке ж (повертається, поки воно не стане нахилене як оригінальне): у такому випадку воно повинно стати знову такого ж стисненого розміру, якщо не тоді це тому, що одна з таких причин :

• Додані метадані : програма чомусь додала фрагмент тексту
• Компресор змінено: програма може вибрати просто відновити зображення як оригінальне, якщо немає змін, але якщо застосувати будь-яку зміну (навіть 4 обертання на 90 градусів), вона може вирішити повторно стиснути зображення за допомогою власного компресор (програма вже не знає, що це все одно те саме зображення).
• Взагалі той же компресор (libPNG або libJPG) дає дуже різні результати в різних реалізаціях, різних версіях тієї самої бібліотеки та з різними параметрами стиснення (також операційна система та компілятор тут іноді змінюють).

Стиснення зображення працює за рахунок стиснення зображень у шматки 4х4 чи інших розмірів. Як правило, компресор бачить обернене зображення як інше зображення, однак, оскільки стислий піксельний шматок - це просто лінійна декомпозиція, якщо шматки на зображенні однакові, можна просто перемістити / дзеркально лінійні матриці декомпозиції, ефективно зберігаючи те саме якість:

Зауважте, що це має бути реалізовано на основі функції , і це також пояснює початкове збільшення розміру => при першому обертанні, воно просто намагається стиснути зображення в кутах, які можна обертати:

• Якщо цього не зробити: якість зображення погіршується

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

• Ця операція є успішною, лише якщо зображення зроблене рівними шматками. (розмір зображення кратний розміру шматка).

Відповідь Scottbb неправильна, і ви можете зробити простий тест:

• Відкрийте оригінальне зображення: зніміть його
• Поверніть зображення 4 рази за допомогою WPV: Скріншот
• Порівняйте 2 скріншоти

Ви побачите змінене зображення (воно повторно стиснене під час першого обертання). Однак ця зміна обмежена в часі, тепер ви можете повернути її знову без втрати якості (якщо зображення має розмір, кратний 8)

Щоб безпосередньо відповісти на ОП:

Я знаю, що обертається без втрат

Він не обертається без втрат, він втрачає якість хоча б один раз (при першому обертанні: тому що спочатку він повинен стиснути його таким чином, який можна обертати), потім він підтримує свою якість.