1. Если вы только начинаете программировать на ассемблере и не знаете с чего начать, тогда попробуйте среду разработки ASM Visual IDE
    (c) на правах рекламы
    Скрыть объявление

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

Тема в разделе "WASM.A&O", создана пользователем Rel, 10 фев 2012.

  1. Rel

    Rel Well-Known Member

    Публикаций:
    0
    Регистрация:
    11 дек 2008
    Сообщения:
    2.248
    для определенных целей нужен маленький по объему кода, но достаточно неплохой алгоритм упаковки бинарных данных... главная загвоздка состоит в том, что для алгоритма невозможно выделить дополнительный буффер... посоветуйте пожалуйста алгоритм, который способен распаковывать данные из буффера со сжатыми данными в него же... то есть, поясню, если непонятно... у меня есть буффер, который гарантировано вмещает в себя распакованные данные, в этом буффере лежат сжатые данные, алгоритму необходимо распаковать данные в этот же буффер без создания дополнительных буфферов (канеш можно выделить на стеке пару килобайт, но этот объем существенно меньше объема распакованных данных)... и еще, в принципе мне не важно на каком языке программирования будет доступна реализация указанного вами алгоритма или даже может быть достаточно хорошей спецификации, но мне придется портировать этот алгоритм на С++ и Питон, так что канеш желателен код на С/С++... заранее спасибо!
     
  2. Marazm

    Marazm Member

    Публикаций:
    0
    Регистрация:
    8 мар 2004
    Сообщения:
    95
  3. Dmitry_Milk

    Dmitry_Milk Member

    Публикаций:
    0
    Регистрация:
    20 ноя 2007
    Сообщения:
    535
    Расположить исходные данные в буфере выровненные по концу буфера, а не по началу. А результат писать уже с начала буфера. Тогда наверное большинство алгоритмов сгодятся, скажем, те же коды Хаффмана.
     
  4. sl0n

    sl0n Мамонт дзена **

    Публикаций:
    0
    Регистрация:
    26 сен 2003
    Сообщения:
    610
    да обычный лзв, только распаковывай после данных упакованных а потом перетащигь вверх вчом проблема ?
     
  5. ava

    ava New Member

    Публикаций:
    0
    Регистрация:
    11 окт 2003
    Сообщения:
    169
    Не годится - длина части распакованных данных может оказаться меньше упакованных. Хаффман "сломается", если в конце окажутся символы с кодами длиной более 1 байта (большое количество различных символов, большая разница частот). Семейство LZ "сломается", если в конце окажутся уникальные комбинации символов.

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

    Rel Well-Known Member

    Публикаций:
    0
    Регистрация:
    11 дек 2008
    Сообщения:
    2.248
    спасибо, буду смотреть LZMAT и LZO, так как они поддерживают "decompression in place"... так же выяснилось, что есть алгоритмы из упаковщика UPX (UCL библиотека), которые тоже поддерживают подобные вещи... в любом случае большое спасибо за помощь!
     
  7. ava

    ava New Member

    Публикаций:
    0
    Регистрация:
    11 окт 2003
    Сообщения:
    169
    Гм, в описании LZO говорится, что он поддерживает "in-place decompression". Но не уточняется, что именно имеется в виду и как это сделано.

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