tiff и jpg

[1998]

Ответ: tiff и jpg

Имеем исходник - jpeg. Ничего с ним особенного не делали - так... обрезали (Crop),

ну так если crop не пришелся точно на границы 8-ми пиксельных квадратов, которые используются механизмом компрессии jpeg, то при повторной записи в jpg по идее потери от сжатия даже на макс. качестве должны увеличиться

----------

что же касается того, смешно или нет архивировать jpeg, то есть такое наблюдение из области компрессии данных. РИП (некоторый) пишет отрипованные битмапы в тиффы со сжатием CCTIT or ZIP or LZW. Первое сжимает примерно на 50% лучше но и длится настолько же дольше. Однако, получаемые тиффы ужимаются RARом (даже на макс. скорости) еще на 30-40% в случае CCTIT, но никак не ужимаются никакими архиваторами в случае ZIP or LZW. Это около года назад была задача передавать мин. объём. Так что смеяться не о чем. Хотел я тогда поднять тему, да засомневался что получу ответы . Ну это так, наблюдение

 

[Ch]

Ответ: tiff и jpg

Алгориитм сжатия Zip`a или RARa близок к максимально возможному.

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

 

[JAW]

Ответ: tiff и jpg

Когда как. Лучше знать, что потери возможны, и каждый раз радоваться, чем один раз поплакать... да и понятие разумного у всех разное - сегодня получилось сжать на 10 степени сжатия, завтра поставим 6 и посмотрим, как получится...

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

Надо просто быть в курсе и не переусердствовать...
Кстати для примера
У меня фотик 3.1 мегапикселя, при самом высоком качестве получаю фотографию около 2х метров. При записи из Шопа в JPEG с минимальным сжатием получаю около 600-800 метров Возникает вопрос, нафига тогда в фотоаппарате ставить минимальное сжатие?

 

[JAW]

Ответ: tiff и jpg

что же касается того, смешно или нет архивировать jpeg, то есть такое наблюдение из области компрессии данных. РИП (некоторый) пишет отрипованные битмапы в тиффы со сжатием CCTIT or ZIP or LZW. Первое сжимает примерно на 50% лучше но и длится настолько же дольше. Однако, получаемые тиффы ужимаются RARом (даже на макс. скорости) еще на 30-40% в случае CCTIT, но никак не ужимаются никакими архиваторами в случае ZIP or LZW. Это около года назад была задача передавать мин. объём. Так что смеяться не о чем. Хотел я тогда поднять тему, да засомневался что получу ответы . Ну это так, наблюдение

Немного теории:
LZW и LZ сжатие, это поиск цепочек в 8 битном словаре.
CCTIT (это на самом деле вариант алгоритма Хафмана с определенным образом предопределенным словарем) работает на уровне битовых цепочек. т.е. понятно, что если мы сожмем сперва, например, байтовые цепочки, получим некий набор данных, то в нем еще можно будет найти закономерности (и сжать) на битовом уровне и наоборот.

Алгоритм ZIP, RAR и прочие жмут последовательно двумя алгоритмами, алгоритмом LZ и алгоритмом Хафмана. В результате закономерностей не на одном, не на другом уровне не остается.

Вообще говоря голый LZ пожмется даже RLE сжатием (сжатие сепочек одинаковых байт).

P.S. Да, CCTIT сжатие имеет смысл делать только для однобитных изображения, оно под него оптимизированно.

 

[1998]

Ответ: tiff и jpg

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

ZIP компрессия однобитного тифа продумана но ничем дальше не жмётся? CCITT -- отстой, но прекрасно дожимается RARом? что говорит математическая точка зрения?

 

[1998]

Ответ: tiff и jpg

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

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

 

[karabin]

Ответ: tiff и jpg

Пример JPEG-сжатия LAB-файла.
Поменять расширение на .tif и открывать в фотошопе.

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

 

[Ch]

Ответ: tiff и jpg

ZIP компрессия однобитного тифа продумана но ничем дальше не жмётся? CCITT -- отстой, но прекрасно дожимается RARом? что говорит математическая точка зрения?

ZIP компрессия и RAR компрессия - "хорошие". CCITT - "плохая".

Это значит, что после CCITT файл будет дальше сжиматься и ZIPом и RARом, а после ZIPа и RARа уже ничем сжиматься не будет. И если переименовать архив в ТИФ и попробовать сжать CCITT, то эффекта уже не будет.

Т.е. после более совершенного алгоритма использовать менее совершенный (или такой же совершенный) не имеет смысла. И ZIP и RAR по степени сжатия близки к теоретически возможному пределу - следовательно, если их использовать, то за один раз достигается задача, и другие методы, ИМХО, не имеют смысла.

С Jpegом все по другому. Там применяется сжатие С ПОТЕРЕЙ информации, следовательно он может быть сжат СИЛЬНЕЕ классических алгоритмов. Только утерянная при сжатии информация будет потеряна безвозвратно, и это отразится на файле при его обратном разворачивании.

Еще одно следствие - после цепочки TIFF->Jpeg->TIFF, последний файл будет жаться классическим архиватором примерно до размера Jpegа.

 

[Yaspersen]

Ответ: tiff и jpg

Но, чем Tif отличается еще от JPG—это возможность сохранять альфа каналы. Однако с ними, тот же Tif, с JPG сжатием не хочет сохранять.

а зачем в JPG альфа-канал?
на то есть разные форматы организации данных, у JPG другое предназначение

 

[karabin]

Ответ: tiff и jpg

...у JPG другое предназначение

Да все это понятно. Но человек в начале темы спросил: …Есть ли такие случаи, когда jpg абсолютно неприемлем?
Вот я и показал. А, то вдруг создаст файл с альфой, сохранит в JPG и не проверит. А потом будет в недоумении, и пенять на печатников.

 

[magneto]

Ответ: tiff и jpg

ZIP компрессия и RAR компрессия - "хорошие". CCITT - "плохая".

Все зависит от цели занятия. CCITT - заточен под сжатие графических битмапов глубиной в 1 бит и эти картинки он жмет прилично. ZIP, RAR и иже с ними - универсальные архиваторы и степень их сжатия не столько зависит от сущности сжимаемого контента, сколько от размера используемого алфавита (словаря), но размер словаря должен быть изрядно меньше пожатого файла (в противном случае выигрыш сомнителен). Джипег изначально заточен под графические файлы глубиной 8бит на канал (и кстати, может сжимать совсем без потерь).
Сравнивать же компрессоры путем сжатия одним компрессором файла уже пожатого более другим - некорректно, особенно если принимать во внимание их контекстную ориентированность (зип-файл, к примеру, уже не является графическим или текстовым).

 

[Ch]

Ответ: tiff и jpg

На "хорошие" и "плохие" я делил исключительно по степени сжатия, поэтому и взял слова в кавычки. А так, конечно, все инструменты как-то используются...

 

[1998]

Ответ: tiff и jpg

ZIP компрессия и RAR компрессия - "хорошие". CCITT - "плохая".

это всё понятно, но не объясняет того, почему "хороший" после "плохого" жмёт лучше, нежели "хороший" сам по себе. Конкретный пример:

uncompressed tiffs 1.25 Gb
(uncompressed tiffs).rar 19.9 MB
(tiffs with zip compression).rar 93.4 MB
(tiffs with ccitt compression).rar 15.0 MB

 

[JAW]

Ответ: tiff и jpg

После ZIP'а жать уже нечего (окромя всяких заголовков и прочей фигни), сами данные уже не содержат избыточности.
То, что непакованный TIFF пожатый RAR'ом оказался больше, чем пакованный CCITT и опять пожатый тоже понятно.
CCITT сжатие это, формально, Алгоритм Хафмана со статическим словарем оптимизированным под однобитные изображения (т.е. словарь не хранится вместе с данными), RAR использует алгоритм Хафмана с динамическим словарем, он дает меньшее сжатие, но более универсальный.
т.е. в RAR'е первый проход Хаманом дал худший результат чем CCITT сжатие.
А в уже пакованном битовые цепочки паковать уже бесполезно, впрочем может быть и попаковал еще по мелочи.

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

Разные словари, разные алгоритмы сжатия. Но они конечно жмутся в одном потоке.

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

 

[Ch]

Ответ: tiff и jpg

Разница там вообще копеечная - 20 и 15 МБ, при исходном файле в 1,25 ГБ!!!

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

И еще, я думаю, что если некомпрессионный ТИФ пожать РАР-ом с установленной максимальной степенью сжатия, то можно достинуть и 15-16 МБ (чуть больше за счет двух словарей).

Удивительно только, что РАР после ЗИПа такой большой!!! Может это ошибка какая? Там, по идее, файл должен быть тоже мегов 20...

 

[1998]

Ответ: tiff и jpg

кстати, для этого конкретного случая (не слишком показательного, см. сообщ. 21) (tiffs with zip compression) = (tiffs with ccitt compression), 100 плюс-минус 10 Мб

 

[Ch]

Ответ: tiff и jpg

А-а-а-а, так это просто ZIP - компрессия, а у Вас написано ZIP+RAR.

Тогда более понятно. ZIP-алгоритм внутри ТИФа наверняка урезанный, чтобы обеспечить какие-нибудь другие функции, например быстрый разворот для просмотра.