» Форматы сжатия статических изображений без потерь

ALL

Итак, субж. JPEG сильно ограничивает, чтобы не сказать - практически исключает редактирование изображений с последующим сохранением их в этот же формат, хотя в части касающейся соотношения степени сжатия и качества материала - надо отдать должное, JPEG рулит. Тем не менее, подобно тому как для звука меня не устраивает МР3, по ряду причин не подходит и JPEG; и хотя у меня весьма обширная коллекция изображений именно в этом формате, хочется перейти на что-то более новое и безпотерьное, хотя бы еще и потому что редактируя и сжимая имеющийся материал без потерь, не будет наблюдаться дальнейшего ухудшения качества.

Насколько мне известно, TIFF в одном из своих вариантов жмет битмапы без потерь? Ну, RLE для BMP - тоже, а что еще существует в природе, предпочтение отдается максимальному сжатию? Я также знаю о существовании LWF - Lura Wavelet Format, иб0 насколько афаик из теории, сжатие статических изображений весьма сродни сжатию волновых форм?

Короче, гуру и профи - поделитесь инфой с юзером в данном вопросе, плз.

Darth_Vader

Мне кажется нет смысла искать подобный формат. Любые беспотерьные форматы будут занимать много места, чудес не бывает. Так что если твой исходники в jpg - оставь их в jpg. Только если тебе нужно многократно пересохранять (редактировать) картинку конвертируй её в беспотерьный формат. Выбор же формата в этом случае будет обусловлен только лишь той программой которую ты используешь для редактирования. Так как Фотошопу альтернатив практически нет то этим форматом скорее всего будет *.psd

GoodCos13

Цитата:

Любые беспотерьные форматы будут занимать много места, чудес не бывает.

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


Цитата:

Так что если твой исходники в jpg - оставь их в jpg. Только если тебе нужно многократно пересохранять (редактировать) картинку конвертируй её в беспотерьный формат.

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


Цитата:

Выбор же формата в этом случае будет обусловлен только лишь той программой которую ты используешь для редактирования. Так как Фотошопу альтернатив практически нет то этим форматом скорее всего будет *.psd

Понимаешь, на мой взгляд PSD слабоват по части оптимизации объема финальных файлов, кроме того - любой проприетарный формат любого редактора оптимизирован для хранения проприетарных данных этого редактора, как скажем в фотошоппере - это слои, а картинка составленная из многих слоев, может занимать ОЧЕНЬ много места, кроме того такие форматы ограничены по совместимости для чтения, т.е. скажем если еще PSD в большинстве случаев читается ACDSee, но не всегда, а уже кореловский формат открывается весьма ограниченным кругом навороченного софта который есть далеко не у всех... а что если я хочу раздавать финал, созданный на базе JPEG, но всего с одним слоем, никаких проприетарных данных для дальнейшего редактирования мне не нужно (скорее, наоборот - хай будет дальнейшее редактирование усложнено), для раздачи юзерам и хранения у себя в галерее? Все что мне затем еще может понадобиться редактировать, я уже давно бакаплю на DVD в форматах редакторов.
А ведь иногда даже особых извратов не требуется - просто гамму подкорректировать, элемент-другой убрать/закрасить, поменять размеры/соотношение сторон, подрезать, итп? Для этого мне 20 слоев в Шопе создавать не надо, а вот сохранить без ухудшения исходника не помешает.

Darth_Vader
TIFF в Шопе сейчас (Шоп ЦС) поддерживает всё (слои, маски, пути) и жмётся лучше ПСД, и просматривать мона через АСДСю.... и конечно же можно без потерь
Единственное - Корел не понимает такой ТИФ с прозрачностью, в отличие от ПСД.

Darth_Vader

Цитата:

По моим наблюдениям и опыту

наблюдение и опыт - вещь, но против матчасти не попрешь ;)
мифы всё это, чтоб морочить себе голову

я, например, храню оригиналы (РАВы) и все обработки в маскимальном (по качеству) фотошоповом джпеге - эпоха тиффонатства у меня уже прошла ;)

slava_kry
Ну, фенькс а TIFF любой жмет без потерь, или?

xy
Шо именно таки мифы? То что данные любого типа жмутся без потерь до 55-60 процентов, или что PSD весит дофига и больше в сравнении с TIFF? Повторюсь, я не профессионал, к навороченным нелинейным эффектам прибегаю крайне редко. Так что дистрибуторный формат для мну удобнее проприетарного.

Darth_Vader
Может имеет смысл пользоваться архиваторами? А для каталогов использовать Where Is It!, или типа этого (он читает архивы)? Но если тебе действительно не надо много пересохранять (все равно исходная версия остается на бакапе), сохраняй все в JPG максимального качества...

Darth_Vader

Цитата:

То что данные любого типа жмутся без потерь до 55-60 процентов

это, да-да, именно это

простейший контрпример: возьми сжатые таким образом данные и, по сделанному тобой предположению, сожми это дело еще на 55-60 процентов.. ну ты понял ;)

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

но опять-же, помоему игра не стоит свечЪ ;) кол-во потерянного места (в сравнении с жпегом) не оправдает никакие затраты в эмпирической потере качества при стандартном постредактировании (а в нормальных ситуациях это очень редкий процесс)

Добавлено:
PSD - нет, это зло, примерно как тиф сжатый места занимает, оно тебе надо?

xy
Darth_Vader хочет чтобы слои в файлах были и всё остальное.... исходники то бишь. Чтобы по-новой ничего не делать.
Про экономию места он немножко загнул, но сейчас вроде с этим не слишком напряжно

Darth_Vader

Цитата:

а TIFF любой жмет без потерь, или?

Это как выбрать при сохранении... в Шопе можно и как JPG сжать (т.е. TIF используется как контейнер для JPG'а), но сей изврат редко кто понимает
А так LZW или ZIP (но он не всеми понимается).

slava_kry
точнее ZIP - всеми, а LZW - не всеми
судя по первому посту ему слои как раз не нужны, а нужна картинка хорошая.. впрочем пусть сам уточнит%)

xy

Цитата:

это, да-да, именно это
простейший контрпример: возьми сжатые таким образом данные и, по сделанному тобой предположению, сожми это дело еще на 55-60 процентов.. ну ты понял

Не, не понял. Объясни как прапору Из того что знаю я - могу сказать, что никаким другим алгоритмом пожатый таким арбузом файл дальше никуда не жмется. Я говорю, основываясь на опыте сжатия данных WinRAR (не текст, а скажем - игры, где есть все: код, графические ресурсы, мультимедия, итп.), музыки (Monkey's Audio v.3.99, Lossless Audio <LA>, сжатие wav-файлов тем же WinRAR, в рарах вавы и не только может проигрывать Фубар-2000).

У меня масса рар-архивов с играми, где исходные данные ужаты до 55-60%, большинство Lossless Audio кодеков жмут так же.

Так что нащет того что 55-60%, это факт. А ты хотел сказать, больше или меньше жмется? Ну, допустим можно оптимизировать алгоритм под тип данных, так это ж х0р0ш0!

Понятно что с потерями можно сжимать намного сильнее, например то же видео в MPEG-4 жмется и 100:1 и выше, но на то оно и с потерями...

И что нащет того что сжатие статической графики сродни сжатию волновых форм? Как насчет формата LWF - был к ACDSee триальный плугин, который позволял сейвить в этот формат, и смотерть его?

Samovarov

Цитата:

Может имеет смысл пользоваться архиваторами? А для каталогов использовать Where Is It!, или типа этого (он читает архивы)? Но если тебе действительно не надо много пересохранять (все равно исходная версия остается на бакапе), сохраняй все в JPG максимального качества...

Ну, есть у меня и архивы с графикой - ACDSee может в них смотреть, плугины есть, но медленно и не слишком удобно. Я хочу, чтобы подправленный файл мог лежать сам по себе рядом с джейпегами, чтобы его можно было отдельно раздавать кому угодно и этот кто угодно мог его открывать и смотреть без геморроя, а вот редактировать - необязательно. А сохранение в формат с потерями, но максимальным качеством - сродни кодированию музыки в МР3 при 320 кбпс CBR Simple Stereo, убожество психоакустики самого алгоритма + дофига занимает места, постредактирование все равно приведет к неприемлемым искажениям... хотя я и так, сохраняя JPEG - не скуплюсь, ставлю обычно десятку, но есть еще куча файлов которые созранял не я...

slava_kry

Цитата:

Darth_Vader хочет чтобы слои в файлах были и всё остальное.... исходники то бишь. Чтобы по-новой ничего не делать.

Не, вот тут ты понял как раз неправильно. Мне нужен финальный формат для распространения файлов, который просто было бы открывать, смотреть/печатать, но НЕ редактировать. Для дальнейшего редактирования я у себя храню бакапы в PSD, сверху зараренные (и хорошо им ужатые, кстати) и сброшенные на DVDR.


Цитата:

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

Кто загнул? Где загнул? Кому не напряжно? У меня 600 Гб на локальной машине, 300 и 200 - на двух других и 3Тб на файл-сервере, все забито под завязку только САМЫМ НЕОБХОДИМЫМ, тем что нужно все время держать под рукой. На каждом разделе свободно бывает гектар, ну полтора...


Цитата:

а TIFF любой жмет без потерь, или?
Это как выбрать при сохранении... в Шопе можно и как JPG сжать (т.е. TIF используется как контейнер для JPG'а), но сей изврат редко кто понимает
А так LZW или ZIP (но он не всеми понимается).

Ага, уже лучше - ситуация проясняется... не, я конешна помнил что TIFF это контейнерный формат аля AVI или OGG / MP4, но смутно и отдаленно

xy

Цитата:

PSD - нет, это зло, примерно как тиф сжатый места занимает, оно тебе надо?

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


Цитата:

но опять-же, помоему игра не стоит свечЪ кол-во потерянного места (в сравнении с жпегом) не оправдает никакие затраты в эмпирической потере качества при стандартном постредактировании (а в нормальных ситуациях это очень редкий процесс)

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

Darth_Vader

Цитата:

Не, не понял.

ну смотри - ты говоришь, что _любые_ данные можно ужать - ужми архив ;)
картинка - это хаотичные данные (так же как и звук и видео) - жать их без потерь эффективно нельзя.. можно подстроится под природу и что-то там мутить, но 2:1 не получится никак, я такого еще не видел

З.Ы. AFAIK, HuffYUV жмет видео тоже чуть меньше чем в 2 раза, получается примерно та же ситуация?

Darth_Vader
и можно потом распокавать и получить побайтовое совпадение с оригиналом?

xy
HuffYUV - кодек безпотерьного сжатия, применяемый для захвата "на лету" и дальнейшей обработки видео со сжатием в финальный формат для хранения и распространения.


Цитата:

ну смотри - ты говоришь, что _любые_ данные можно ужать - ужми архив

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


Цитата:

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

Таким образом, ты отрицаешь существование эффективных универсальных или проприетарных алгоритмов архивации вообще? Извини конешна, но это даже не ересь - отрицать очевидное, это... трудно как-нибудь определить, никого при этом не обидев Никакие это не "хаотичные" данные, звук и графика в построчном представлении - это волновые формы, для которых давно есть эффективные алгоритмы безпотерьного сжатия до 55-60% от оригинала.
Я пришел сюда спросит о конкретике у профессионалов, пользующихся сжатием каждый день и способных рекомендовать что-то исходя из своего опыта, а столкнулся с тем что очевидное и элементарное подвергается оспариванию... печально.
Конешна понятно, что для человека творческого и гуманитария вникнуть в такие материи, как "высокоуровневое абстрактное описание многомерных массивов данных" - сложновато, поэтому не буду никого отправлять изучать теорию алгоритмов архивации, просто предложу тебе взять любую игру на диске весом в пару гектар и ужать ее последней версией WinRAR с максимальным сжатием, "непрерывный архив" (solid archive), или взять любой Audio CD, извлечь с него любую дорожку в несжатый WAV, а затем сжать ее с помощью WinRAR, Monkey's Audio и сравнить результат, потом - попробовать сжать обезьяний файл тем же винраром и посмотреть на размер.

Дело в том, что универсальные алгоритмы аля RAR, ZIP, LZW, LZMA etc. плохо сжимают или не сжимают вообще, а наоборот - пакуют в файлы б0льшего размера - только данные, сжатые проприетарным алгоритмом, то есть тем который помимо общих методов сжатия еще и оптимизирован для предсказания структуры данных конкретного типа - графики, звука итп. Ну или сжатые другим универсальным алгоритмом, что тоже понятно: уже оптимизированный и утрамбованный массив с точки зрения архиватора как раз и представляет собой хаотические, далее неупорядочиваемые данные (если только не создать алгоритм на порядок более высокой сложности и ресурсоемуости).

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

Только EXE, DLL и другие бинарные модули, сжатые специальными алгоритмами наподобие EXEPACK, ASPACK etc., еще более-менее заметно сжимаются универсальными архиваторами, хотя и хуже чем вообще несжатый код, но тут объяснение простое: эти проприетарные ЕХЕ-компрессоры реализуют компромисс между размером файла и скоростью его загрузки в память в виде полноценного исполняемого кода, ведь все пожатые ЕХЕ-упаковщиками модули могут непосредственно исполняться, все процедуры "разжатия" осущетсвляются над ними "на лету", в процессе загрузки в память, в то время как чтобы запустить на исполнение файл из архива, его приходится распаковывать, при этом зачастую потратив дополнительно немало времени и ресурсов на обработку почти всего массива сжатых данных, чтобы восстановить требуемый фрагмент (читаем теорию).

Тоже заинтересовала эта тема, посему провел такой простенький тест: создал в фотошопе файл, куда я засунул разные эффекты на разных слоях и сохранил этот файл в форматах: .psd, .raw, .tif, после чего сжал их архиватором WinRar 3.41. Ужатые файлы получились соответственно на 45%, 56% и 59% меньме оригиналов, и ведь после этого я уверен, что я смогу разархивировать эти файлы и будет именно побайтное совпадение. Разве нет такого формата графики, подобного указанному алгоритму?

Добавлено:
Еще в продолжение темы сжатия - сделал следующее: tif(размер 14 673 040 байт), ужат архиватором при максимальном сжатии, получился .rar (размер 4 669 484 байт), расширение .rar было изменено на .qwerty и полученный файл снова был сжат в .rar (размер 4 644 320 байт). Последующие циклы изменения расширения+сжатие не приводят к уменьшению размеров. А за счет чего произошло некоторое уменьшение при первом цикле?

Darth_Vader

Цитата:

Мне нужен финальный формат для распространения файлов, который просто было бы открывать, смотреть/печатать, но НЕ редактировать.

Имеет смысл присмотреться к формату MrSID (расширение .sid). Он широко используется для распространения космоснимков, жмет очень хорошо и без потери качества. Имеет пирамидальную структуру, поэтому открывается и перерисовывается при масштабировании очень быстро.
На офсайте http://www.lizardtech.com можно скачать бесплатный плагин для браузеров, позволяющий его просматривать. Ранее был и бесплатный отдельный вьювер, но теперь за его новую версию хотят денежку. Распространенные просмотрщики тоже его понимают, но значительно хуже, практически на уровне превью.
Для кодирования в MrSID Lizardtech выпускает GeoExpress, текущая версия 5, крек ищется давно и пока безуспешно. Версия 1.4 сейчас лежит здесь:
http://forum.ru-board.com/topic.cgi?forum=35&topic=11333&start=40#20
Ставить надо в варианте Workstation, и номер при активации вводить соответствующий, тогда не будет ограничений на размер входного файла (в Desktop - 500 Mb).

Krechet

Цитата:

А за счет чего произошло некоторое уменьшение при первом цикле?

Спасибо, интересная инфа, практически подверждающая теорию. За объяснением см. мой предыдущий постинг.

tumber
Фенькс, хотя звусит довольно замороченно - похоже, по совместимости у данного формата есть серьезные ограничения...

ALL
Хотелось бы услышать хоть одно мнение от людей, юзавших LWF.

Есть еще такой формат - PNG - Portable Network Graphics, был разработан как альтернатива GIF, когда за него хотели начать деньги требовать. Сжимает без потерь, и достаточно неплохо. А просматривать его умеет даже IE а также и все остальные обозреватели интернета
http://rus-linux.net/zen/png_feature/png_feature.html

Провел небольшой тест - файл tiff 1024х768х24bit - размер 2 мб, png - 1,2 мб, jpeg - 1,1 мб.

Akama
Это все х0р0ш0, только как у него с потерями при сжатии?

Добавлено:
Ага, выясняется что PNG - формат безпотерьный... зд0р0в0 10ххх за совет, это именно то что нужно

Darth_Vader
Я только одного не понял: почему тут ни словом не обмолвились о JPEG2000? Ну, разве что полсловом, упомянув его предшественника LWF. Оба формата имеют режим сжатия без потерь данных, и PNG, насколько я понимаю, по степени упаковки тут отдыхает.

DimmY

Цитата:

и PNG, насколько я понимаю, по степени упаковки тут отдыхает.

НО... поддержка от производителей, то бишь открытие файлов на любой машине.

DimmY
Подробнее инфу, ссылку можно?

Darth_Vader
http://forum.ru-board.com/topic.cgi?forum=36&topic=0263#1
Уже обсуждали... кратко

slava_kry
DimmY
Ага, почитали-сс... что-шш, действительно печально, вынужден согласиться с xy: формат без стандартной поддержки большинством "народного" софта, прежде всего - фотожоппером и ACDSee, а хорошо бы - и встроенным вьювером оболочки ХР - для моих целей не подходит, да и вообще, ИМХО - сугубо весч в себе.
Что же касается PNG, то я от него просто учитывая степень сжатия и тот факт, что оно безпотерьное + достаточно широко распространненую его поддержку.
Правда, я уже нашел немало файлов JPG, которые при пережатии после элементарной правки (удаление пары мелких объектов итп) в PNG оказывались раз в 5 толще чем в JPG, но там на самом деле имеется масса сложных цветовых переходов по всему фону, немеряно оттенков, итп. В большинстве же случаев PNG весит на копейку больше, а иногда и меньше, чем JPG.
И еще, кстати: при пересохранении ряда ВМР-файлов, фотожоппер громко кричал, что сохранять надо только как копию, иначе не все "фичи" картинки будут сохранены. При этом выбрать сохранение с альфа-каналом не дает, да и вроде картинка вообще без него, и после сохранения выглядит абсолютно идентично оригиналу. Соответственно, вопрос: какие-такие "фичи" могут быть в обычном ВМР, которые не может сохранить PNG? Ну, одна картинка была 15-битовая, а другие вроде нормальный TrueColor...

И еще, вопрос: а где хомяк JPEG2000?

ALL

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

Правда, надо отдать должное: помимо того что скажем безпотерьный jp2 весит 400k там же где PNG весит 500, файл сжатый с потерями при размере в 3 раза меньше обычного джейпега визуально выглядит практически так же. Остается загадкой, почему ЛюраТек включила столь неудачные сэмплы в поставку своего плугина.

Другой геморрой заключается в поддержке вьюверами. Я юзаю сишку своей собственной сборки "3.5" - ядро от 3.1, большинство плугинов - от 5.0 и выше, а семерку, в которую стандартно входит плугин для jp2, позавчера полностью выкинул, включая все копии инсталляхи. Немного жаль, потому что я не забрал из нее новые плугины, а ст0ило бы, так мне пришлось прикручивать плугин для фотошопа через враппер - оно конешна работает, но медленно: юзеру "слонов" от 4.0 и выше оно возможно и незаметно, а мне с моей 3.5, которая обычно делает все в реальном времени - жЮткие тормоза.

Darth_Vader

вот и я говорю
Цитата:

геморрой

а польза от всех этих форматов сомнительная.

для фотографа есть только один полезный безпотерьный формат - RAW...

GoodCos13

Цитата:

вот и я говорю
Цитата:
геморрой
а польза от всех этих форматов сомнительная.

Не-а во-первых, я не фотограф; во-вторых, для кого угодно может быть полезным PNG, с его кросплатформенностью и посвеместной поддержкой браузерами, не гря уже о редакторах и вьюверах - можно выкладывать безпотерьные картинки в инете например без лишнего кариеса

Darth_Vader

Цитата:

можно выкладывать безпотерьные картинки в инете например без лишнего кариеса

а зачем? ты визуально не отличишь шоповский Джпег12 (и даже 10) от ТИФа
поэтому выкладывать в инете лучше в Save As For Web.. качество не сильно пострадаеть ;)

а по поводу безпотерьности ПНГ у меня большие сомнения, хотя пока поверю вам на слово ;)

xy

Цитата:

ты визуально не отличишь шоповский Джпег12 (и даже 10) от ТИФа

Отличу.... на 300-х процентах