OpenZL 0.1.0

На 4-м скриншоте сравнение сжатия небольшого (2.1M, специально!) файла UnicodeData.txt zli-git (с zstd-git внутри), zstd-git и kanzi-git.
Позже я планирую добавить OpenZL в lzbench, если никто не опередит. :)

Сложно-непонятно, но очень интересно.

С опеннета:

Для специфичных форматов требуется сформировать собственный профиль, используя команду «zli train», которая выявляет закономерности в данных и формирует профиль с оптимальным уровнем сжатия. Используя опцию «–pareto-frontier» созданный профиль можно модернизировать в сторону ускорения упаковки или распаковки, ценой снижения уровня сжатия. Для описания сложных форматов со вложенными структурами и определения раскладки форматов данных в структурах может применяться язык SDDL (Simple Data Description Language).

Я вот что не пойму — этот профиль как-то отдельно от сжатых файлов нужно передавать, чтобы на том конце разжать можно было, или же сжатый файл всё же самодостаточен, даже если использовать кастомные профили?

Пишут, что не надо:

Обратите внимание, что для декомпрессии не требуется никаких –profile: данные, сжатые с помощью openzl всегда поддается декодированию, независимо от того, какой –profile использовался для сжатия. Профиль влияет только на эффективность сжатия, но не на совместимость.
https://openzl.org/getting-started/quick-start/

или же сжатый файл всё же самодостаточен, даже если использовать кастомные профили?

https://openzl.org/getting-started/introduction/

OpenZL is a framework for building lossless data compressors. It provides a set of primitive codecs that can be composed in a DAG. Additionally, it allows for user-defined control flow to modify the DAG based on the data, at any point in the compression. OpenZL also provides a universal decompressor that can decompress anything produced by the compressor, independent of the compression DAG.

Насколько я понял, этот «универсальный декомпрессор» универсален. :)

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

Самое забавное, что у Zstd есть давно есть механика подготовки словаря. А ещё есть cmix, который, ЕМНИП, тоже строит свои кастомные трансформаторы.

Наконец-то можно писать «Не zli меня».

И у RAR, например, даже ещё раньше был фильтр для замены смещений в операциях перехода при сжатии x86 кода.

Но тут намного более обобщённый подход.

Спасибо, dataman. Интересная вещь.

Спасибо krasnh за наводку!
У новости сложная судьба: я ОРВИрую с воскресенья, а вчера ноут глюкнул. Но сегодня всё более-менее, так что получилось, как получилось.

Круть тогда!

О, спасибо, теперь понятно что это за сабжевая хрень и для чего

А что непонятного? Они придумали ультимативный способ сжатия данных, требующий ручного написания компрессора для каждого случая. Из плюсов - декомпрессор стандартный для всех.

Звучит интересно.
Интересно, как дела обстоят с производительностью компрессии? Можно ли этот профиль использовать для оптимизации производительности упаковки/распаковки, когда важнее пропускная способность, нежели компактность?

Мне кажется тут непонятно только как писать этот то ли профиль ,то ли компрессор на практике.

как писать этот … компрессор на практике.

openzl /examples.

Это был риторический вопрос! Любопытно конечно, но у меня нет хреновой тучи структурированных данных хотя бы для того чтобы собрать тестовый набор и поиграться! Даже будь у меня настолько лишнее время..

Интересно применение SDDL. Для BMP:

GenericU8 = UInt8
GenericU16 = UInt16LE
GenericU32 = UInt32LE

FileHeader = {
  signature   : GenericU16
  file_size   : GenericU32
  reserved    : GenericU32
  data_offset : GenericU32
}

file_header : FileHeader

expect file_header.signature == 0x4d42  # "BM"
expect file_header.reserved == 0

InfoHeader = {
  header_size      : GenericU32
  width            : GenericU32
  height           : GenericU32
  planes           : GenericU16
  bits_per_pixel   : GenericU16
  compression      : GenericU32
  image_size       : GenericU32
  x_pixels_per_m   : GenericU32
  y_pixels_per_m   : GenericU32
  colors_used      : GenericU32
  important_colors : GenericU32
}

info_header : InfoHeader

expect info_header.compression == 0

width = info_header.width
height = info_header.height
bits_per_pixel = info_header.bits_per_pixel

num_colors = (
  (bits_per_pixel == 1) * 2 +
  (bits_per_pixel == 4) * 16 +
  (bits_per_pixel == 8) * 256
)

ColorTableEntry = {
  red      : GenericU8;
  green    : GenericU8;
  blue     : GenericU8;
  reserved : GenericU8;
}

color_table_entries : ColorTableEntry[num_colors];

row1_bytes  = 4 * ((width + 31) / 32)
row4_bytes  = 4 * ((width +  7) /  8)
row8_bytes  = 4 * ((width +  3) /  4)
row16_bytes = 4 * ((width +  1) /  2)
row24_bytes = 4 * ((width +  1) * 3 / 4)

Image = {
  : GenericU8[row1_bytes][height][bits_per_pixel == 1]
  : GenericU8[row4_bytes][height][bits_per_pixel == 4]
  : GenericU8[row8_bytes][height][bits_per_pixel == 8]
  : GenericU16[row16_bytes / 2][height][bits_per_pixel == 16]
  : GenericU8[row24_bytes][height][bits_per_pixel == 24]
}

image : Image

первый_скриншот.png (88689 байта).

magick 1.png -compress none BMP3:2.bmp # -> 5591094 байта
zli compress --profile sddl --profile-arg bmp.sddl --train-inline 2.bmp -o 2.zl

Picked 1 samples out of 1 samples with total size 5591094
Benchmarking untrained compressor...
1 files: 5591094 -> 30679 (182.24),  711.74 MB/s  2932.91 MB/s
Selected greedy trainer by default since no trainer was specified
[==================================================] Calculating improvement by clustering tag 5/5
[==================================================] Training ACE graph 2 / 5: ACE progress
[==================================================] Training ACE graph 3 / 5: ACE progress
[==================================================] Training ACE graph 5 / 5: ACE progress
Benchmarking trained compressor...
1 files: 5591094 -> 20498 (272.76),  241.61 MB/s  1437.23 MB/s
Training improved compression ratio by 49.67%
Compressed 5591094 -> 20498 (272.76x) in 30.211 ms, 185.07 MB/s

zli d 2.zl -o 3.bmp
cmp 2.bmp 3.bmp
zstd -19 2.bmp # -> 2.bmp.zst, 24826 байта

Но обучение долгое.

И у RAR, например, даже ещё раньше был фильтр для замены смещений в операциях перехода при сжатии x86 кода.

В LZMA (7z и xz) с самого начала есть BCJ-фильтры, делающие подобные преобразования для нескольких архитектур.

Поправляйся!

Спасибо, буду!

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

с самого начала есть BCJ-фильтры

Да, есть. Но от того же xz повсеместно в итоге отказались в пользу zstd - что в пакетах дистров, что в LiveCD. Он хорошо жмет, но медленный в распаковке (чтении).

UPD.

что в LiveCD

Сужу по дистрам подобной конструкции, для которых скорость распаковки (чтения) на первом месте.

Но от того же xz повсеместно в итоге отказались в пользу zstd - что в пакетах дистров, что в LiveCD

Отказались там, где важны затраты CPU на распаковку и сжатие. А там, где важнее размер файла (и где имеют смысл такие фильтры) xz и 7z живее всех живых

ага, ты ему рандомный блоб - он тебе: я не лучше чем bz2, прости(с)
так-то понятно что давно все паттерны/словари посчитаны - rar/zip/gzip/bz2.
кто объяснит почему не инфоциганство?

Улучшение существенное – часто двузначное процентное увеличение, а иногда и больше.

Трехзначное сжатие, более 100%?

А так годная штука, думаю. Ждем повсеместного распространения.

Как оно в сравнении с xpack?

давно все паттерны/словари посчитаны - rar/zip/gzip/bz2. кто объяснит почему не инфоциганство?

И где скачать эти словари для zip?

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

Возвращаясь к вопросу, который я недавно задавал на форуме. Насколько сложно этот препроцессор обучить распаковывать сжимаемые данные, заведомо использующие неоптимальное сжатие? Например, если на выход подаётся ZIP, сжатый deflate, на лету преобразовывать его в ZIP с методом store (без сжатия), и уже его сжимать, что даст гораздо большее сжатие. Разумеется, потом, после распаковки архива, потребуется пережимать ZIP обратно deflate-ом, потребуются дополнительные программы для распаковки. Аналогично с PNG/JPG/GIF с deflate/Huffman/LZW.

Можно ли в SDDL специфицировать массивы данных, требующие сложных преобразований перед упаковкой и после распаковки?

Yann Collet. Menlo Park, California, United States

Что он вообще делает на форуме в домене su ? Он же француз!

А гигабайт фильмов в килобайт сожмет? А обратно разожмет?

ну если для вас это открытие, то словари строятся на основе входных данных.

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

Вот так вот, zstd скоро объявят устаревшим и выкинут отовсюду, заменив этим, и старые архивы будет сложно распаковать. Всякие модные архиваторы приходят и уходят, только gzip стандарт навсегда. Стабильность через десятилетия важнее процентов сжатия.

Вот так вот, zstd скоро объявят устаревшим и выкинут отовсюду, заменив этим, и старые архивы будет сложно распаковать.

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

Ой, нет, чушь морозная в моём предыдущем комментарии. Не получится скорее всего ничего полезного.

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

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

Где ты ворчание увидел? Я просто увидел очередное подтверждение своей позиции (о том что gzip хватит почти всем). Помню недавно мне втирали что вот gzip устарел вместо него теперь везде xz, потом втирали так же про zstd, теперь вот про openzl будут. А я везде как использовал так и буду использовать gzip - он совместим со всеми системами за последние 30 лет и в будущем тоже везде будет реализован, в отличие от всяких временных решений.

Сложно-непонятно, но очень интересно.

... но не очень нужно... ;) :))

Звучит круто, спасибо за новость

для восстановления исходного ZIP архива бит-в-бит понадобится запомнить определённое количество метаданных

Рассмотрим случай, когда это не требуется :)

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

Ты сказал, что всё давно посчитано. Где результаты этих расчётов?

… но не очень нужно… ;) :))

Думаю, ненужные точки и скобки будет хорошо сжимать.

zstd скоро объявят устаревшим и выкинут отовсюду

Не выкинут, это же RFC 8878.

заменив этим

🤬

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

крч, компрессия с помощью ии

Аналогично с PNG/JPG/GIF с deflate/Huffman/LZW.

Если они улучшат возможности SDDL до возможностей Kaitai Struct. Вот, например, png: https://formats.kaitai.io/png/.

Думаю, ненужные точки и скобки будет хорошо сжимать.

Софтина не должна решать, что в сжимаемом файле «нужно», а что «не нужно». А то нарешает...

Как и юзеры решать за всех, что им не нужно.

Юзеры не решают «за всех». Они решают за себя, когда работают со своими файлами.

Наконец-то можно писать «Не zli меня».

Наконец-то появилось чистое, открытое и свободное zlo!