Если изображение вращается без потерь, почему размер файла изменяется?

Question

Я искал способы поворота изображения без потерь и натолкнулся на этот вопрос, который довольно хорошо объясняет это:

Вращается ли «Просмотр фотографий Windows» без потерь?

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

Answer 1

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

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

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

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

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

В частности, метаданные JFIF / Exif могут содержать одну или несколько миниатюр полноразмерного изображения, и программное обеспечение, которое вращает изображения, действительно должно восстанавливать (или также вращать без потерь!) Миниатюры, чтобы они будет соответствовать новой ориентации полноразмерного изображения. Одно это может легко объяснить наблюдаемую разницу в размерах.

Answer 2

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

Процедура

Я сгенерировал случайное RGB-изображение размером 256 на 256 пикселей, используя фильтр «Solid Noise» в GIMP («Фильтры»> «Рендеринг> Облака> Solid Noise ...») с использованием настроек по умолчанию (показано ниже):

И результат:

Затем я сохранил изображение в формате JPEG, используя настройки по умолчанию:

Затем я перенес изображение в Windows и открыл его с помощью Windows Photo Viewer, щелкнув правой кнопкой мыши изображение в проводнике и выбрав Preview в меню. Затем я повернул изображение с помощью кнопок внизу и сохранил изображение, перейдя к следующему изображению с помощью клавиш со стрелками.

Для каждого из приведенных ниже тестов я начинал с копии исходного изображения и поворачивал (нажимал на кнопку поворота) соответствующее количество раз перед сохранением. Вот остальные размеры (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 & times; 1 подвыборку цветности, в то время как WPV использовал 2 & times; 2 подвыборки. Это заставляет меня поверить, что WPV не использует «истинное» вращение без потерь, если только оно каким-то образом не может обнаружить это черно-белое изображение.

Чтобы решить эти проблемы, я провел второй тест.

Процедура

Я следовал шагам, подобным первому тесту. Я создал случайное изображение 256 & times; 256 RGB, используя фильтр шума RGB (Фильтры> Нос> Нос RGB ...) со следующими настройками:

Вот результат:

Я экспортировал файл в формате JPEG, используя следующие настройки:

Прогрессивный был отключен, но Субсэмплинг все еще установлен на 4: 4: 4 (что является еще одним именем для 1 & times; 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 & times; 8-пиксельные блоки. Каждый из этих блоков затем подвергается дискретному косинусному преобразованию (DCT) . Результирующие коэффициенты DCT описывают блок как сумму волн различной частоты. Затем алгоритм «выбрасывает» в высокочастотные волны некоторую информацию, соответствующую шуму и очень мелким деталям. Процесс декодирования инвертирует DCT, складывая сохраненные волны вместе, чтобы вернуть блок.

Можно вращать «волны» DCT, фактически не отменяя и не переделывая преобразование (в основном вы превращаете все горизонтальные волны в вертикальные волны и наоборот). Я думаю, что в WPV происходит то, что изображение фактически декодируется, поворачивается, а затем перекодируется. Во время процесса перекодирования, поскольку размер нашего изображения кратен 8 в обоих измерениях, каждый из новых блоков соответствует одному из исходных блоков. Важно отметить, что поскольку в каждом блоке нет высокочастотных компонентов, алгоритм не выбрасывает какую-либо информацию и находит именно те компоненты DCT, которые имел бы «истинный» поворот без потерь.

Наконец, я еще раз посмотрю на компоненты файлов JPEG. Результаты снова связаны как суть . Сравнивая два:

• Образ WPV содержит дополнительные 4286 + 2 байта метаданных Exif, 1 дополнительный байт в комментарии и 12 726 + 2 байта метаданных XMP. Это всего 17 017 байтов дополнительных метаданных. Для чего используются все эти данные? Я заглянул в файл с моим верным шестнадцатеричным редактором и копией соответствующих стандартов:

  • Метаданные 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 & times; 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
  

Answer 3

^{РЕДАКТИРОВАТЬ : Этот ответ был опубликован до того, как я узнал, что размер файлов увеличился примерно на 9 КиБ (9055 байт для изображения 256 × 256, 9612 КиБ для изображения 512 × 512 ).}

По всей вероятности, когда вы впервые повернули изображение, Windows Picture Viewer сделал одно (или оба) из следующих действий:

1. Добавлен тег EXIF, которого не было в исходном изображении JPEG (возможно, тег Orientation);
2. Изменена / добавлена ​​информация к тегу, который уже существовал (возможно, теги Software Processing или Image Software).

Это увеличило размер файла из-за дополнительного тега EXIF ​​(и / или дополнительных данных к существующим тегам).

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

---

РЕДАКТИРОВАТЬ : Почти наверняка это объяснение не может содержать около 9 КиБ дополнительных данных в файле. Кроме того, при отсутствии каких-либо других причин увеличения размера это объяснение предполагает, что увеличение размера будет более или менее постоянным (по модулю некоторых различий в длине между строковыми представлениями числовых данных, вероятно, в несколько байтов). Это, очевидно, не то, что здесь происходит, по крайней мере, не полное объяснение.

Answer 4

Без обратного инжиниринга jpeg en / decoder невозможно сказать наверняка. На самом деле существует ряд стандартов jpeg, и вопреки распространенному мнению, не все они могут быть изменены без перекодирования.

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

Увеличение размера файла может также включать некоторые дополнительные метаданные, хотя 9k кажется большим, это возможно. Увеличение также может быть объяснено добавлением миниатюры, которая может отсутствовать в выходных данных GIMP. Возможно, мы сможем получить больше информации из файлов напрямую (до WPV и после).

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

Лучше всего работать с форматом без потерь и полностью избежать боли.

Answer 5

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

Транспонирование не имеет ограничений относительно изображения
размеры. Другие преобразования работают довольно странно, если размеры изображения не кратны размеру iMCU (обычно 8 или 16 пикселей), потому что они могут преобразовать только целые блоки Данные коэффициента DCT желаемым образом.

Поведение jpegtran по умолчанию при преобразовании изображения нечетного размера
предназначен для сохранения точной обратимости и математического
согласованность набора преобразований. Как уже говорилось, транспонирование это
возможность перевернуть всю область изображения. Горизонтальное зеркальное отображение оставляет любое Частичный столбец IMCU на правом краю не тронут, но может перевернуться все строки изображения. Точно так же вертикальное зеркальное отражение оставляет любой частичный ряд iMCU у нижнего края не тронут, но может перевернуться все столбцы. Другие преобразования могут быть построены как последовательности операции транспонирования и переворачивания; для последовательности, их действия на крайние пиксели определены так же, как конечный результат соответствующая последовательность транспонирования и переворота.

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

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

Answer 6

У меня нет определенного ответа, но есть несколько возможных теорий, почему это произошло. Некоторые типы файлов работают таким образом, что два разных кода для изображения этого типа файла не обязательно создают разные изображения. Например, тип файла PNG работает таким образом, потому что он допускает прозрачный фон, но изображение с прозрачным фоном и одно и то же, за исключением того, что один и тот же фон белого цвета, выглядит точно так же. Файл изображения считается сжатым, если он занимает менее 3 байтов памяти на пиксель. Я считаю, что кроме тех, которые имеют прозрачный фон, никакие два файла PNG не генерируют точно такое же изображение. Когда вы сохраняете изображение в формате PNG, оно преобразует его в код, который генерирует исходное изображение, и, за исключением очень необычных изображений, таких как одно, где каждый пиксель является случайным цветом всех 2 ^ 24 цветов, код будет занимать меньше памяти, чем 3 байта на пиксель, поэтому сохранение в формате PNG называется сжатием без потерь. С другой стороны, для экономии памяти с помощью кода файла изображения JPEG можно генерировать только определенные изображения. Вероятно, существует несколько типов файлов JPEG, и я не знаю, обладает ли какой-либо из них свойством, что два разных изображения этого типа файлов могут генерировать одно и то же изображение. Я предполагаю, что несколько раз вы просто поворачивали изображение, а затем сохраняли его в формате JPEG и объяснили, что произошло, исходя из предположения, что это то, что вы сделали, и я не знаю, правда ли это. Вращение, которое вы сделали, без потерь, если есть способ вернуть тот же код файла изображения, который вы использовали до того, как повернули и сохранили его. Возможно, вы не правы, что вы действительно сделали вращение без потерь. Если это действительно было без потерь, одна из возможных причин состоит в том, что два разных кода изображения действительно генерируют одно и то же изображение, и именно код изображения, которое вы имели, а не то, какое изображение у вас было, определяло изображение, которое вы получили после того, как вы повернули его и сохранили. это.

Answer 7

Из-за , как работает сжатие изображений . Любой формат, такой как PNG или JPG в целом, не сохраняет размер файла после поворота.

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

Конечно, если сжатие выполняется без потерь, если вы поворачиваете изображение 4 раза в 4-й раз, изображение снова становится таким же (поворачивается до тех пор, пока оно не станет наклонено как оригинальное): в этом случае оно должно снова стать таким же сжатый размер, если нет, то это из-за одной из следующих причин :

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

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

Обратите внимание, что это должно быть реализовано для каждого элемента , и это также объясняет начальное увеличение размера => при первом повороте он просто пытается сжать изображение в виде фрагментов, которые могут вращаться:

• Если это не удается сделать, качество изображения ухудшается

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

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

Скоттбб ответит неправильно, и вы можете сделать простой тест:

• Открыть исходное изображение: Скриншот it
• Поворот изображения 4 раза с WPV: Снимок экрана:
• Сравните 2 скриншота

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

Для прямого ответа OP:

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

Он не вращается без потерь, он теряет качество хотя бы один раз (при первом вращении: потому что сначала он должен сжиматься так, чтобы его можно было вращать), затем он сохраняет свое качество.

Answer 8

Причины этого несколько

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

Но почему вы вращаете JPEG в 20 раз?