LINUX.ORG.RU

Сжатие сжатых файлов

 ,


1

1

Лет 20 назад архиватор StuffIt внедрил интересный метод упаковки в формат .sitx: для хорошо известных форматов, использующих сжатие, например, JPEG, исходный файл перед упаковкой разжимался, затем архиватор сжимал его методом PPMd. При распаковке те же данные распаковывались из PPMd, и затем упаковывались в JPEG методом Хаффмана. За счёт большей эффективности PPMd, обещали сжатие JPEG-ов на треть. (Википедия пишет, что на четверть.) Вроде бы то же делалось для PNG, GIF, ZIP, TIFF, PDF, адоубовских форматов… Но под Линукс для этого формата не было даже распаковщика.

Идея интересная. Кто-нибудь пытался реализовать что-то подобное в свободных архиваторах?

Сейчас наткнулся на информацию, что владельцы StuffIt прекратили его развитие и поддержку в 2019-м. Сайт https://stuffit.com/ пока жив, но сертификат истёк 1 октября.

★★★★★

При распаковке те же данные распаковывались из PPMd, и затем упаковывались в JPEG методом Хаффмана

Но это тогда будет не исходный файл, а ещё раз пережатый. Можно и просто JPEG посильнее зашакалить.

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

anonymous
()
Ответ на: комментарий от anonymous

Но это тогда будет не исходный файл, а ещё раз пережатый.

Нет, не будет. Если под «распаковывались» понимать не получение исходного изображения, а набор коэффициентов ДКП. Их можно сжимать разными способами, но восстановленное изображение будет идентичным.

anonymous
()
Ответ на: комментарий от anonymous

Но это тогда будет не исходный файл, а ещё раз пережатый. Можно и просто JPEG посильнее зашакалить.

Нет, не будет. Если под «распаковывались» понимать не получение исходного изображения, а набор коэффициентов ДКП. Их можно сжимать разными способами, но восстановленное изображение будет идентичным.

Именнно так. Распаковка-упаковка применяется только к последней стадии — сжатию Хаффмана, не трогая результаты разложения в ряд. Даже если файлы отличаются, изображения идентичны.

question4 ★★★★★
() автор топика

Сжатие сжатых файлов

ИМХО актуальная задача для работы с архивами - эффективный доступ к содержимому архивов.
Ныне ни в одном архиваторе этого нет.
Да и изменение архивов весьма неэффективно в архиваторах реализовано.

anonymous
()
Ответ на: комментарий от anonymous

ИМХО актуальная задача для работы с архивами - эффективный доступ к содержимому архивов. Ныне ни в одном архиваторе этого нет. Да и изменение архивов весьма неэффективно в архиваторах реализовано.

Архивы на то и архивы, чтобы лежать без изменений в архиве :) Просто за неимением лучшего, ZIP сделали универсальным контейнером.

На мой взгляд, нужно развивать файловые системы со сжатием. И тут тоже будет полезно разбирать внутреннюю структуру сжимаемого файла — что-то перепаковывать, что-то не пытаться сжимать, к чему-то применять дедупликацию; возможно, и в программе, пишущей на диск, сделать настройки, чтобы она не сжимала, если сжатие переложено на ФС.

question4 ★★★★★
() автор топика
Ответ на: комментарий от dataman

FreeArc Next

Если такой есть,

https://github.com/Bulat-Ziganshin/FA

Поддержка распаковки старого формата — в плане на следующий релиз. 2 года без движения.

Булат один из модераторов этого форума.

Он и на ЛОРе есть :)

question4 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Эффективный доступ - это библиотека, реестр.

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

У меня так.

anonymous
()

Для jpg есть был lepton

https://www.opennet.ru/opennews/art.shtml?num=44787

«Lepton позволяет сократить размер изображения JPEG в среднем на 22% без потери информации и с возможностью полностью бит в бит воссоздать исходный файл.»

Вроде ещё есть что-то подобное.

(jojpeg, packJPG, brunsli, lepton, JPEG-XL)

https://www.opennet.ru/openforum/vsluhforumID3/133309.html#61

greenman ★★★★★
()
Последнее исправление: greenman (всего исправлений: 3)