Генерация и сжатие TIFF-графиков: R против GIMP против IrfanView против Photoshop размеры файлов

Я сгенерировал несколько графиков высокого разрешения для публикации, например 

library(plot3D)
Volcano<-volcano
zf=10 #zoom factor
tiff("Volcano.tif", width=1800*zf, height=900*zf, res=175*zf, compression="lzw")
image2D(z = Volcano, clab = "height, m",colkey = list(dist = -0.20, shift = 0.15,side = 3, length = 0.5, width = 0.5,cex.clab = 1.2, col.clab = "white", line.clab = 2,col.axis = "white", col.ticks = "white", cex.axis = 0.8))
dev.off()

Размер файла-22 МБ.

Теперь я открываю файл с GIMP и , не делая ничего другого я экспортировать его как "вулкан gimp.tif" (не меняйте разрешение и не делайте ничего другого). GIMP создает файл ("Вулкан gimp.tif"), что составляет 1,9 Мб.

imagemagick сообщает похожие статы изображений: 

$ identify Volcano.tif
Volcano.tif TIFF 18000x9000 18000x9000+0+0 8-bit DirectClass 22.37MB 0.000u 0:00.000
$ identify "Volcano gimp.tif"
Volcano gimp.tif TIFF 18000x9000 18000x9000+0+0 8-bit DirectClass 1.89MB 0.000u 0:00.000

Даже при использовании identify -verbose 2 файла кажутся похожими.

В чем разница между этими файлами? Почему у них такие разные размеры файлов?

UPDATE : ладно, все становится еще безумнее. Я сделал то же самое с IrfanView, и я получаю разные размеры файлов. Начальный файл-это Volcano.tif, созданный из R с помощью compression="lzw". Проверьте, как Volcano irfan.tif и Volcano gimp.tif отличаются по размеру, но все остальные характеристики одинаковы. Объем памяти, DPI, цвета, разрешение идентичны. Размер диска отличается.

Введите описание изображения здесь

Обновление 2: Adobe Photoshop сохраняет файл вплоть до 2,6 МБ

Введите описание изображения здесь

WinRar сообщает, что исходный R-генерируемый TIFF очень сжимаем (от 22 МБ - >3,6 МБ)

Обновление 3: эта проблема может быть аналогична монтажу / соединению 2 изображений TIFF в плитке 2 col x 1 row без потери качества

Обновление 4: созданный R TIFF файл можно найти здесь http://ge.tt/7ZvRd4C1/v/0?c

1 7
imagemagick image-compression

1 ответ:

По-видимому, компрессор TIFF LZW, используемый R, не использует важную опцию (предиктор TIFF), которая приводит к чрезвычайно большому файлу. Сжатие данных работает лучше всего, когда оно может распознавать симметрии / избыточности в данных. В этом случае данные изображения состоят из 24-битных (3-байтовых) пикселей, содержащих красные, зеленые и синие 8-битные значения. Стандартное сжатие LZW смотрит на поток байтов для повторяющихся шаблонов. Если он смотрит на цветное изображение просто как на поток байтов, то он вы увидите повторяющиеся шаблоны 3-байт вместо повторяющихся шаблонов постоянного цвета. Включение предиктора TIFF для данных приводит к тому, что фильтр дифференцирования сохраняет дельту каждого пикселя с его соседом. Если соседние пиксели имеют тот же цвет, он будет хранить 0. длинная строка 0 сжимается намного лучше, чем повторяющиеся шаблоны ненулевых, которые имеют длину не менее 3 байт.

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

Original data:
2A 50 40 2A 50 40 2A 50 40 2A 50 40 2A 50 40 2A 50 40 (6 pixels of the same color)

After horizontal differencing (TIFF predictor):
2A 50 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The data is much more compressible after the predictor since long runs of the same value (0x00) are easier for LZW to compress.

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

9