Pull to refresh

Comments 27

Такое кодирование, возможно, применяется в бекапах, обновлении данных, типа антивирусных баз.
UFO just landed and posted this here

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

UFO just landed and posted this here
Если Вы имеете в виду такой же революционный алгоритм, как и Пегий дудочник из сериала «Кремниевая долина», то я не готов его назвать революционным, но при сравнении с Xdelta3 преимущество у DBroo. А Xdelta3, на сколько мне известно, является одним из лучших в этом направлении.
Это была просто шутка, исходя из названия)
Тогда да))) Ищем теперь инкубатор)
А код-то покажут? Или бинари позапускать-побенчить?
Код — нет. На счет бинарей пока не знаю.
Так, а в чем профит статьи? Деталей алгоритма нет, кода нет, продукта с алгоритмом тоже. На две статьи сравниваем популярные алгоритмы сжатия со сферическими конями на конкретном железе. «Где ваши доказательства?» как говорится.
Какой план на выпуск это все в поля? На каких условиях хотя бы сильно на вскидку: open source/ freeware или как bpg только open source или только бинарные поставки?
Про лицензию тоже пока не думали, так как думаем что это не конечный результат и еще будет дорабатываться.

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

По поводу пруфов, если вам они нужны не только для того, что б убедиться в правдивости информации которую изложили выше, а еще и потому что хотели бы использовать где-то у себя, тогда какие вам нужны доказательства?
Говорю сразу, идея и код раскрываться не будут.
Т.Е. это абсолютно голословная статья для пира чтобы привлечь покупателей? Тогда почему он не в хабе «Я пиарюсь»?

Ведь никаких фактор не предоставлено. Алгоритма нет. Тесты есть только у вас и никто подтвердить и проверить их не может. Если это для того чтобы заинтересовать то отправьте в «я пиарюсь» и тогда все норм
На деле это выглядит просто балабольством. Вы просто пукнули в лужу, извиняюсь. Просто взгляните на ваш текст со стороны, без обид. Вы просто что-то говорите и думаете что все поверят просто так или для чего вы статью тогда кидаете? Или вы считаете что бизнес купит алгоритм по этой статье которая не имеет никаких доказательств?
Это тогда о чем статья? О цифрах? В чем разница между выдуманной статьей?
Дельта кодирование применяется в сжатии видео (целиком запоминаются опорные кадры, а движущееся изображение между ними сохраняется в виде разницы) и аудио (Так как звук представляет физический процесс, он не может изменяться бесконечно быстро/медленно, поэтому хотя дискретизация, условно, может иметь 1024 значения (10 бит), моментальные значения не изменяются сразу на такую величину, поэтому можно хранить не последовательность значений по 10 бит, а последовательность дельт по 8 и эффективнее паковать)
На скорость декодирования как-то такое повлияет?
Я знаком с принципом поверхностно.
Чистое дельта-кодирование может быть даже лучше. Чистая выгода — и по памяти и по производительности. Но это возможно только при специфических данных. Условно, звук на 98% можно упаковать дельта кодированием, но 2% содержат пики, которые не влезают в диапазон — для них нужно делать исключения, это уже может быть медленнее, чем воспроизводить поток.
Для видео требуются дополнительные операции для построения промежуточных изображений — это наверняка медленнее.
Ну и современные форматы применяют не один метод компрессии — достраиваемые картинки скорее всего еще и упакованы каким нибудь частотным алгоритмом с потерей качества и его обработка тоже не дается бесплатно. Сами эти алгоритмы тоже могут использовать дельта-кодирование.
Компрессию применяют для сжатия данных (оптимизация по размеру) ценой ухудшения по другим направлениям (больше вычислений от процессора или больше оперативной памяти для промежуточных данных и построения финального распакованного результата) — обычно все имеет цену.

Другое дело, что, к примеру, блочная компрессия текстур поддерживается железом на низком уровне — соответственно текстура меньше весит на диске, меньше весит в оперативной и видео памяти, быстрее грузится, а распаковывается прямо при рендере (и эту нагрузку на себя берет видеокарта) — получается выгода на всех этапах.
В первую очередь — спасибо за предыдущий комментарий. Натолкнули на мысли попробовать поработать с аудио и видео.
Во вторых, уже успели частично поработать с аудио и видео. По поводу аудио файлов, я пока не вижу применения дельта-кодирования, так как в аудио все идет одним потоком и нет каких то опорных данных которые изменяются с течением времени.
Но тем ни менее по текущим наработкам получилось тестовые wav файлы сжать до размера уровня flac, к примеру 30мб wav файла упаковываются в 21мб, что равняются размеру туго же файла упакованным в flac. Но это без использования дельта-кодирования, пока не вижу применения ему в аудио.

В видео чуть другая история, есть кадры которые могут выступать опорными и тут уже можно использовать дельта-кодирование. Первые результаты показали сжатие порядка 20% (если мне не изменяет память) от опорного кадра без какой-либо предварительной подготовки данных.
Ну по поводу аудио есть два замечания.
Во первых, опорных кадров может и не быть.
Например, есть у нас аудио поток в дискретизации 1024 уровней. Мы выставляем первый кадр в 0, либо в реальное значение с дискретизацией 1024.
А потом начинаем каждое следующее значение шифровать дельтой на 256 или 128 от предыдущего, пытаясь приблизиться к реальному значению. Иногда будут значения, отличающиеся больше, чем на 256. Они будут чуть сглаживаться (значения 0,1,0,1024,1023,1025,860 превратятся 0,1,0,255,512,768,860) — если это не скажется фатально на качестве звука — вполне рабочий метод.
Во вторых, можно использовать как опорные кадры периодические либо пиковые.
Например, каждый 1000, либо каждый, у которого уровень отличается больше, чем на 256. Одно из значений, условно ff мы берем на спец символ, с помощью которого кодируем, что этот кадр — опорный, либо этот кадр — пиковый. Он задается честно, значением от 0 до 1024. Собственно это может быть одним и тем же — механизм упаковки выбирает опорные кадры на свое усмотрение, а для распаковщика они выглядят одинаково.
Как-то это самое дельта-кодирование
Во время спектрумов выдумал (лет минус 25), пытаясь изобрести новый метод сжатия.
Будучи знакомым с литературой Р.Е. Кричевского и алгоритмами адаптивного хафмана и lz.
Но энтропия взяла свое!
Sign up to leave a comment.

Articles