Предыдущий блок Следующий блок Вернуться в индекс
 RU.COMPRESS 
 From : Moderator of ru.compress             2:5020/500     04 May 99 22:04:34
 To   : Leonid Cherepanov
 Subj : New files in AUTLCOMP and ADEVCOMP fileechos

Wednesday April 28 1999 10:44, you wrote to All:
 BZ>>  Area : AUTLCOMP        Comment : Autoadded fileecho
 LC> Эге-гей! :) У кого в Москве можно утаскивать сабжевые фэхи?
 LC> P.S. Hу нету у моих знакомых этих фэх... :(
расширяй круг знакомых :)
 LC> @PATH: 5020/701 278 204 238 1851 423
# 26 Apr 22:09:43 AFIX Area ADEVCOMP
# 26 Apr 22:09:43 AFIX File MFARC.RAR
# 26 Apr 22:09:43 AFIX Path 2:5093/29.61 924997702 Sun Apr 25 02:48:22 1999
# 26 Apr 22:09:43 AFIX Path 2:5093/29 925066287 Sun Apr 25 21:51:27 1999
# 26 Apr 22:09:43 AFIX Path 2:5093/20@fidonet.org 925129783 MON APR 26 09:29:43
# 26 Apr 22:09:43 AFIX Path 2:5049/36 925108456 Mon Apr 26 09:34:16 1999
# 26 Apr 22:09:43 AFIX Path 2:5054/3 925108857 Mon Apr 26 11:40:57 1999
# 26 Apr 22:09:43 AFIX Path 2:5020/238 925134241 MON APR 26 09:44:01 1999
# 26 Apr 22:09:43 AFIX Path 2:5020/278 925108412 26 Apr 99  10:33:32
# 26 Apr 22:09:43 AFIX Path 2:5020/423 925115204 Mon Apr 26 11:26:44 1999
все что нужно сделать - это попросить босса подписаться у /278.
это, знаете ли, азы... стыдно! :-E
впредь прошу такие вопросы в эху не задавать.
теребите своих боссов и фэхокоординаторов.
Vsevolod,
moderator of ru.compress
---
 * Origin: ### VSF&K ### (2:5020/500)


 RU.COMPRESS 
 From : D.Shkarin                           2:5020/400      06 May 99  18:51:18
 To   : All
 Subj : Re: JPEG

From: "D.Shkarin" <shkarin@arstel.ru>
                         Hi, Сергей!
    Чой-то мы друг-друга никак не поймем.
>        Дык я же говорил о совсем другом случае, когда в картинке
содержится
>очень много избыточной информации
    Эти картинки настолько избыточны что сжатие без потерь дает зачастую
лучшие результаты чем JPEG.
>очень много избыточной информации (сканированный текст и т.п.), и jpeg
кодер ее
    JPEG не предназначен для таких картинок, лучше перевести изображение в
черно-белое (bi-level) и сжать любым факсимильным форматом(без потерь), еще
лучше использовать JBIG и совсем уж из области экзотики, сжать алгоритмом
сжатия bi-level изображений с потерями(есть и такие).
>до конца не убирает. Также я заметил что избыточность появляется при jpeg
>сжатии близом к максимальному (не оптимальному!). Примеры:
    Я говорил об оптимальных кодах, а не об оптимальной степени сжатия.
>Рисунок белое поле, quality 95%:
>>BMP - 1000K; JPG - 27K; RAR - 2K ( 7% );
    А если взять белое поле побольше(10МБ), то РАР сожмет сам-себя в 10 раз,
но это не доказывает что РАР плохой архиватор :).
--- ifmail v.2.14dev3
 * Origin: COMSTAR Telecommunications (2:5020/400)


 RU.COMPRESS 
 From : D.Shkarin                           2:5020/400      07 May 99  19:16:44
 To   : All
 Subj : Re: Compression Test 4/8

From: "D.Shkarin" <shkarin@arstel.ru>
                         Hi, Вадим!
    Вопрос: а зачем сжимать эксджипеги без потерь? Вроде-бы все что можно
там уже потеряно.
--- ifmail v.2.14dev3
 * Origin: COMSTAR Telecommunications (2:5020/400)


 RU.COMPRESS 
 From : Dmitry Subbotin                     2:5020/978.10   08 May 99  03:34:23
 To   : D.Shkarin
 Subj : WI

Hi, D.Shkarin!
"D.Shkarin" sendTo: "All" when: [02 May 99] msg:
 >> Мнэ... Hасколько я понимаю, убираемая РАРом избыточность происходит
 >> из-за того,
 >> что jpeg пакует одинаковые (после DCT+квантизации) блоки посредством
 >> одинакового кода, что на картинках с большими ~одноцветными областями
 DS> должно
 >> давать много повторов. И это вроде не зависит от используемого
 DS> хаффмановского
 >> кода. Или я не прав?
 DS>       Повторов-то одинаковое кол-во, но кодируются они в разное число
 DS> бит.
Факт, в разное. Речь, однако, шла о принципиальной дожимаемости jpeg'ов. Если
повторы кодируются в меньшее число бит, то дожиматься они все равно будут, хотя
может быть и не так сильно. Да?
 DS> Три искусственные картинки с РАРом из брэгзоны(и где тут 30%
 DS> выигрыш?):
 DS> Встроенные коды:
 DS> CLEGG.JPG      350521   345171   98%
 DS> Оптимальные коды:
 DS> CLEGG.JPG      338512   335298   99%
Действительно, и где тут 30% выигрыш? :) Hе, это картинки не в тему. Давай
лучше обсудим результаты сжатия моего десктопа:
DESKTOP  JPG       639 571    обычный код
DESKTOP  RAR        21 229
DESKTOP2 JPG       463 230    оптимальный
DESKTOP2 RAR        16 774
taste you later,
morf
--- GoldED 2.50+
 * Origin: morf@softhome.net (2:5020/978.10)


 RU.COMPRESS 
 From : Dmitry Subbotin                     2:5020/978.10   08 May 99  03:40:51
 To   : Leonid Broukhis
 Subj : русский народный rangecoder

Hi, Leonid!
"Leonid Broukhis" sendTo: "Dmitry Subbotin" when: [04 May 99] msg:
 >> Кстати про арифметическое кодирование. Приколитесь - самый простой в
 >> мире rangecoder, всего 10 строк вместе с ренормализацией. ;)
 LB> А декодер, ради того же прикола, можно ли увидеть?
В декодере все делается аналогично.
 uint Decode (uint Lo, uint Range, uint Total) {
        range /= Total;
        uint freq = (lo-lo2)/range;
        lo2 += range*Lo;
        range *= Range;
        while (range < 0x10000) {
            if ((lo2 & 0xff0000) == 0xff0000 && range+(lo2&0xffff) >= 0x10000)
              range = 0x10000-(lo2&0xffff);
            range = range<<8;
            lo    = lo<<8 | InByte();
            lo2 <<= 8;
        }
        if (freq >= Total)  throw("Input data corrupt");
        return freq;
      }
Hадо сказать, что основные потери таком в кодере происходят не из-за "ручного"
обрубания range'а (которое дает ~ дополнительный бит на 256 байт), а из-за того
что range периодически опускается до уровня 2**16, что увеличивает ошибки
округления. Вообще с этим можно бороться, делая нормализацию всякий раз, когда
range влазит в три байта и перенос заведомо не может произойти, но это пожалуй
будет уже не сильно проще обычного (i.e. шиндлеровского) rangecoder'a.
taste you later,
morf
--- GoldED 2.50+
 * Origin: morf@softhome.net (2:5020/978.10)


 RU.COMPRESS 
 From : Dmitry Subbotin                     2:5020/978.10   08 May 99  03:42:58
 To   : Vadim Yoockin
 Subj : szip

Hi, Vadim!
"Vadim Yoockin" sendTo: "All" when: [01 May 99] msg:
 >> Помнишь, ты когда-то хотел нам рассказать, как работает szip'ов
 >> кодер? :)
 VY> Виноват, все времени нет как следует за письмо сесть ;)
 >> От беглого просмотра субжа у меня сложилось впечатление ;) что там
 VY> используется
 >> MTF + структурная модель им. Фенвика +
 VY> Hе, это используется в BWC. И у меня тоже. А SZIP использует хитрую
 VY> смесь MTF и адаптивного кодера. Причем используется статистика только
 VY> последних 32 символов (не кодов MTF). Если не угадали с 32, далее
 VY> идет MTF-подобное кодирование (в котором я еще не разобрался до
 VY> мелочей - только в общих чертах).
Так вот почему он так хорошо жмет!
Спасибо, Вадик, это очень интересно. Можно я тебя еще немного поспрошаю? Как
Шиндлер предсказывает вероятность escape'а, то есть того что символ не найдется
среди последних 32? Я видел, там кодируется какой-то трехсимвольный алфавит.
Это случайно не оно? :) Если да, то что означает появление третьего символа?
И еще, как в szip'е определяется, какую rle-модель использовать для данного
символа? По позиции символа в mtf-списке?
 VY> В общем, достаточно громоздкая  схема. Более эффективна, чем простой
 VY> MTF + struct model на бинарниках, но немного хуже на текстах.
По моему разумению адаптивный кодер должен работать лучше MTF на длинных
устойчивых контекстах, и проигрывать ему там, где контексты быстро меняются.
Придумав, как скрестить одно и второе, можно получить что-то крутое. :)
 VY> И, на мой взгляд (не могу сказать точно - ибо полностью
 VY> воспроизводить SZIP мне лень и некогда, а все остальные компоненты у
 VY> нас слишком отличаются, чтобы сравнивать кодеры), медленнее.
И ты на голом MTF обходишь шиндлеровский кодер на текстах? Круто. Я пока до
такого не дошел.
 >> Hо что это означает? Шиндлер наврал в своей статье или szip использует
 >> какой-то другой алгоритм?
 VY> Hе разбирался, поскольку, при всем уважении к Шиндлеру, мне
 VY> не кажется, что ST может где-то иметь примущество над BWT.
 VY> Только у ST4 есть изюминка в быстром сжатии. Остальные -
 VY> не быстрее грамотно реализованого BWT, не говоря уж про расжатие.
У ST есть одно преимущество - устойчивость сортировки на любых входных данных.
Пока ни одна реализация bwt этим похвастаться не может. Самое лучшее что есть -
bzip - заметно притормаживает на длинных повторах, а с avi'шками, где есть куча
прогонов 0,80h,0,80h..., он ковыряется десятки минут.
С другой стороны, за стабильность работы, которая нужна для очень немногих
файлов, ST расплачивается чуть ли не вдвое более медленной распаковкой, что
тоже неприятно.
Кстати, как насчет сделать для bwt-архиваторов специальный тест с "плохими"
данными для анализа их устойчивости? Могу подбросить для такого теста пару
нехороших файлов. :)
 >> Собственно, интересно, можно ли использовать ST для сортировки на
 >> большую глубину, или это неизбежно будет приводить к большим тормозам
 >> при распаковке?
 VY> Тормоза при распаковке на ST больших порядков не такие большие, как
 VY> при малых порядков
Ммм... Сейчас посмотрел по твоему тесту - время распаковки szip'а монотонно
растет с увеличением порядка. Ты ничего не путаешь? Или этот эффект проявляется
только на каких-то особенных файлах?
taste you later,
morf
--- GoldED 2.50+
 * Origin: morf@softhome.net (2:5020/978.10)


 RU.COMPRESS 
 From : Vadim Yoockin                       2:5020/1042.50  08 May 99  12:56:04
 To   : D.Shkarin
 Subj : Re: Compression Test 4/8

Пpиветствую, D.Shkarin!
07 May 99, D.Shkarin писал к All:
 DS>                          Hi, Вадим!
 DS>     Вопрос: а зачем сжимать эксджипеги без потерь? Вроде-бы все что можно
 DS> там уже потеряно.
Да просто потому, что тест задумывался для безпотерьных компрессоров,
а на момент тестирования я не нашел у себя картинки, не прошедшей
через jpeg :)
  Всего доброго. Vadim Yoockin
... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru (2:5020/1042.50)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/1042.50 08 May 99 13:01:42
 To   : Dmitry Subbotin
 Subj : szip

Пpиветствую, Dmitry!
08 May 99, Dmitry Subbotin писал к Vadim Yoockin:
 >>> MTF + структурная модель им. Фенвика +
 VY>> Hе, это используется в BWC. И у меня тоже. А SZIP использует хитрую
 VY>> смесь MTF и адаптивного кодера. Причем используется статистика только
 VY>> последних 32 символов (не кодов MTF). Если не угадали с 32, далее
 VY>> идет MTF-подобное кодирование (в котором я еще не разобрался до
 VY>> мелочей - только в общих чертах).
 DS> Так вот почему он так хорошо жмет!
 DS> Спасибо, Вадик, это очень интересно. Можно я тебя еще немного поспрошаю?
 DS> Как Шиндлер предсказывает вероятность escape'а, то есть того что символ не
 DS> найдется среди последних 32? Я видел, там кодируется какой-то
 DS> трехсимвольный алфавит. Это случайно не оно? :) Если да, то что означает
 DS> появление третьего символа?
Да, ты верно подметил.
А третий символ - это кумулятивная вероятность ;)
 DS> И еще, как в szip'е определяется, какую rle-модель использовать для
 DS> данного символа? По позиции символа в mtf-списке?
По тому, как этот символ выступал в предыдущих rle.
 VY>> В общем, достаточно громоздкая  схема. Более эффективна, чем простой
 VY>> MTF + struct model на бинарниках, но немного хуже на текстах.
 DS> По моему разумению адаптивный кодер должен работать лучше MTF на длинных
 DS> устойчивых контекстах, и проигрывать ему там, где контексты быстро
 DS> меняются.
Дима, для MTF'a нет ничего лучше, чем длинные устойчивые контексты :)
А адаптивный кодер хорош там, где возникает неоднозначность
контекстов.
 DS> Придумав, как скрестить одно и второе, можно получить что-то
 DS> крутое. :)
Мне пока жалко жертвовать скоростью ради не столь уж большого
преимущества гибрида.
 VY>> И, на мой взгляд (не могу сказать точно - ибо полностью
 VY>> воспроизводить SZIP мне лень и некогда, а все остальные компоненты у
 VY>> нас слишком отличаются, чтобы сравнивать кодеры), медленнее.
 DS> И ты на голом MTF обходишь шиндлеровский кодер на текстах? Круто. Я пока
 DS> до такого не дошел.
MTF хорош еще простотой и быстротой.
Если хочешь, могу твой компрессор погонять на тестах.
 DS> У ST есть одно преимущество - устойчивость сортировки на любых
 DS> входных данных. Пока ни одна реализация bwt этим похвастаться не
 DS> может. Самое лучшее что есть - bzip - заметно притормаживает на
 DS> длинных повторах, а с avi'шками, где есть куча прогонов
 DS> 0,80h,0,80h..., он ковыряется десятки минут.
Положим, в bzip - уже не самая лучшая. К слову сказать, у
ybs круг "плохих файлов" на порядок меньше. И прогонами
0,80h,0,80h.. его не проймешь ;) Да и на обычных файлах
побыстрее будет...
 DS> С другой стороны, за стабильность работы, которая нужна для очень
 DS> немногих файлов, ST расплачивается чуть ли не вдвое более медленной
 DS> распаковкой, что тоже неприятно.
Причем особенно как раз на этих немногих файлах ;)
 DS> Кстати, как насчет сделать для bwt-архиваторов специальный тест с
 DS> "плохими" данными для анализа их устойчивости? Могу подбросить для такого
 DS> теста пару нехороших файлов. :)
Давай, с удовольствием погоняю. Лучше на e-mail.
 VY>> Тормоза при распаковке на ST больших порядков не такие большие, как
 VY>> при малых порядков
 DS> Ммм... Сейчас посмотрел по твоему тесту - время распаковки szip'а
 DS> монотонно растет с увеличением порядка. Ты ничего не путаешь? Или этот
 DS> эффект проявляется только на каких-то особенных файлах?
Видимо на файлах, при которых расход на разборку одинаковых контекстов
не оказывает решающего влияния. Таковых оказалось немало ;) Честно говоря,
я тоже ждал обратного результата.
  Всего доброго. Vadim Yoockin
... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru (2:5020/1042.50)


 RU.COMPRESS 
 From : Leonid Broukhis                     2:5020/400      08 May 99  13:03:18
 To   : Dmitry Subbotin
 Subj : Re: русский народный rangecoder

From: leob@asylum.mailcom.com (Leonid Broukhis)
Dmitry Subbotin wrote:
>Hi, Leonid!
> >> Кстати про арифметическое кодирование. Приколитесь - самый простой в
> >> мире rangecoder, всего 10 строк вместе с ренормализацией. ;)
>
> LB> А декодер, ради того же прикола, можно ли увидеть?
>
>В декодере все делается аналогично.
>
> uint Decode (uint Lo, uint Range, uint Total) {
>        range /= Total;
>        uint freq = (lo-lo2)/range;
>        lo2 += range*Lo;
>        range *= Range;
>        while (range < 0x10000) {
>            if ((lo2 & 0xff0000) == 0xff0000 && range+(lo2&0xffff) >= 0x10000)
>              range = 0x10000-(lo2&0xffff);
>            range = range<<8;
>            lo    = lo<<8 | InByte();
>            lo2 <<= 8;
>        }
>        if (freq >= Total)  throw("Input data corrupt");
>        return freq;
>      }
Lo и Range здесь откуда? От предыдущего freq?
  Leo
>Hадо сказать, что основные потери таком в кодере происходят не из-за "ручного"
>обрубания range'а (которое дает ~ дополнительный бит на 256 байт), а из-за
>того что range периодически опускается до уровня 2**16, что увеличивает ошибки
>округления. Вообще с этим можно бороться, делая нормализацию всякий раз, когда
>range влазит в три байта и перенос заведомо не может произойти, но это пожалуй
>будет уже не сильно проще обычного (i.e. шиндлеровского) rangecoder'a.
Все равно круто. В comp.compression написал?
  Leo
--- ifmail v.2.14dev3
 * Origin: leob@at-mailcom.dot-com (2:5020/400)


 RU.COMPRESS 
 From : Leonid Broukhis                     2:5020/400      08 May 99  13:03:21
 To   : All
 Subj : Как насчет такой модели для выхода BWT?

From: leob@asylum.mailcom.com (Leonid Broukhis)
Сперва несколько вводных замечаний.
Введем название "run(k)" ("ранк") для
последовательностей не более чем k различных символов. АААААААА - это run(1),
ААААББАААБАБББАААББ - это run(2), и т.п. Любой байт-ориентированный файл -
это, очевидно, run(256) или меньше.
Теперь, взяв какой-нибудь файл, для разных k рассмотрим среднюю длину
(возможно, перекрывающихся) ранков для разных k (Average run(k) = "авранк").
Так, например, для вышеприведенного ААААББАААБАБББАААББ
avrunk(1) = (4+2+3+1+1+3+3+2)/8 = 2.375, а для АБВГД avrunk(3) = 3.
Для файла на естественном языке авранк 1 очень близок к 1,
а, скажем, авранк 96 (или даже меньше) по порядку величины близок
к длине файла. Из тех же соображений, которые говорят, что MTF - хорошая
модель для выхода BWT, следует, что авранки у выхода BWT будут больше,
чем у исходного файла.
Возьмем, к примеру book1 из Calgary corpus. Для него (используя
bwt, приведенный у Марка Hельсона, с буфером 200000, поэтому avrunk-bwt
плохо растет ближе к концу - двоичные данные мешают)
k  Av.run(k) book1    Av.run(k) book1.bwt
1  1.02       1.87
2  2.08       4.41
5  5.77       15.91
10 14.50      56.63
20 49.71      428.00
30 171.96      1883.10
40 580.93      5687.37
50 1445.52     12101.97
60 3964.65     25107.76
70 13874.41    69522.61
80 378291      143950.90
82 768771      162838.90

Максимум отношения avrunk-bwt к avrunk - в районе k=30.
Отсюда можно эвристически предположить,
что лучше всего будет скользящий MTF глубиной около 30, как раз
столько, сколько у Шиндлера, согласно Вадиму Юкину.
Кстати, авранки для book1.bwt.mtf для любого k находятся примерно
посередине между avrunk и avrunk-bwt, а график отношения awrunk-bwt
к awrunk-bwt.mtf выглядит довольно странно (www.mailcom.com/images/avrunk.gif)
Графики же авранков для geo и geo.bwt медленно и плавно растут -
как две параболы - у geo.bwt чуть выше, чем у geo. Максимум отношения
достигается при k=2, из чего можно предположить, что простой
предиктороподобный алгоритм для geo будет лучше, чем MTF (кто проверит?).
Кто разовьет теорию?
  Leo
--- ifmail v.2.14dev3
 * Origin: leob@at-mailcom.dot-com (2:5020/400)


 RU.COMPRESS 
 From : Leonid Broukhis                     2:5020/400      08 May 99  13:11:58
 To   : All
 Subj : А вот, собственно, и runk.cc

From: leob@asylum.mailcom.com (Leonid Broukhis)
#include <stdio.h>
#include <set.h>
main(int argc,  char *argv[]) {
  int last[256];
  for (int i = 0; i < 256; last[i++] = -1);
  if (argc == 1) exit(1);
  int k = atoi(argv[1]);

  if (k <= 0 || k > 256) exit(1);
  set<unsigned char> lastk;
  int c, cold, curpos = 0, runstart = 0;
  int totruns = 0, runcnt = 0;

  while((c = getchar()) != EOF) {
   last[c] = curpos++;
   if (lastk.size() < k) {
      lastk.insert(c);
      continue;
   } else if (lastk.find(c) != lastk.end()) {
      continue;
   }
   int l = 0x7fffffff;
   set<unsigned char>::iterator it;
   for (it = lastk.begin();
   it != lastk.end(); it++) {
      if (last[*it] < l) {
       l = last[*it];
       cold = *it;
      }
   }
   totruns += curpos - runstart - 1;
   runcnt++;
   runstart = l + 1;
   lastk.erase(cold);
   lastk.insert(c);
  }
  totruns += curpos - runstart;
  runcnt++;
  printf("Average run(%d) = %.2f\n", k, (float) totruns / runcnt);
}
--- ifmail v.2.14dev3
 * Origin: leob@at-mailcom.dot-com (2:5020/400)


 RU.COMPRESS 
 From : Vadim Yoockin                       2:5020/1042.50  08 May 99  13:48:28
 To   : Bulat Ziganshin
 Subj : szip

Пpиветствую, Bulat!
У аплинка были затыки с почтой и твое письмо вытащил из i-net'a.
 >> И еще про szip. Кто-нибудь по шиндлеровской статье разобрался, как
 >> делать unST для старших порядков?
>  А простое хеширование не подходит? Та ведь, насколько я помню,
> единственная проблема - по N символам получить некоторое число. То есть
> можно использовать большую часть аппарата, наработанного для lz-поиска.
> Или там это сделано еще круче?
Может и можно. Только жаль это делать при расжатии.
Да и szip, судя по всему, не так уж много времени тратит на
разборку одинаковых контекстов.
 VY> Тормоза при распаковке на ST больших порядков не такие большие, как
 VY> при малых порядков, но здорово растут тормоза при самом сжатии.
>  В любом случае, st(n) не должно быть медленней bwt при любом порядке.
> Hу конечно, если не тратить слишком много времени на проверки "i<n?"
Да, скорее всего, дело в реализации. Может поэтому szip -o8 медленнее
ybs? Кроме того, эти проверки могут заметно сказываться только на больших
порядках.
  Всего доброго. Vadim Yoockin
... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru (2:5020/1042.50)


 RU.COMPRESS 
 From : D.Shkarin                           2:5020/400      08 May 99  20:27:35
 To   : All
 Subj : Re: WI

From: "D.Shkarin" <shkarin@arstel.ru>
                         Hi, Dmitry !
>
>Факт, в разное. Речь, однако, шла о принципиальной дожимаемости jpeg'ов.
Если
>повторы кодируются в меньшее число бит, то дожиматься они все равно будут,
хотя
>может быть и не так сильно. Да?
>
    Угу, в принципе, для любого компрессора можно подобрать такой источник,
что он будет выдавать повторяющуюся последовательность бит и его можно будет
опять дожать.
>
>Действительно, и где тут 30% выигрыш? :) Hе, это картинки не в тему. Давай
>лучше обсудим результаты сжатия моего десктопа:
>
>DESKTOP  JPG       639 571    обычный код
>DESKTOP  RAR        21 229
>DESKTOP2 JPG       463 230    оптимальный
>DESKTOP2 RAR        16 774
>
    Честно говоря не встречал таких картинок. А почему они такие большие? И
почему так хорошо жмутся РАРом? То есть ты просто скопировал экран? Я так
попробовал, у меня не получилось.
--- ifmail v.2.14dev3
 * Origin: COMSTAR Telecommunications (2:5020/400)


 RU.COMPRESS 
 From : Sergey Moskovchenko                  2:5037/9.36    08 May 99 21:53:04
 To   : D.Shkarin
 Subj : JPEG

Вот что решил ответить Sergey на письмо которое написал  D.Shkarin :
                        Hello D.Shkarin!
D>     А если взять белое поле побольше(10МБ), то РАР сожмет сам-себя в 10
D> раз, но это не доказывает что РАР плохой архиватор :).
        Действительно сжимает в несколько раз, как впрочем и zip,arj. Интересно
 что лучший результат был у HA, после него архив уже не дожимался ничем. Hо это
 не значит что HA хороший архиватор, просто рар (да все остальные, в т.ч. subj)
 мог бы сжимать в этом случае лучше, делая это 2 раза (например изходя из услов
ия когда данные сжимаются более чем в 10 раз, при этом ведь даже затраты на вре
мя повысятся несильно).
        А в JPEG-е конечно же его свойство оставлять избыточность, когда от нег
о требуется очень большой кооф. сжатия является недостатком. :( Hо устранимым.
:)
    Всего наилучшего!
                                     С уважением Сергей.
---
 * Origin: Дайте мне точку опоры или я переверну весь мир! (2:5037/9.36)


 RU.COMPRESS 
 From : Konstantin Scheglov                  2:5036/5.48    09 May 99 11:50:04
 To   : All
 Subj : Связь по медленному каналу.

Hello All.
  Есть две машины, связанные медленным каналом (9600 бод). Между ними требуется
передавать данные. Данные являются преимущественно текстом, но иногда
передаются
и картинки. Поток данных непостоянен, зависит от того, что делает пользователь
на удаленном компьютере. С обоих концов мои программы.
  Так как канал медленный, а работать хочется быстро, на ум приходит сжатие
данных перед передачей. Можно было бы просто сжимать пакеты данных и посылать
их
как самостоятельные архивы, но специфика задачи подсказывает, что это очень
неэффектино. Данные могут передаваться маленькими порциями, причем некоторые
пакеты очень похожи друг на друга, например:
1. "Something=SomeValue1"
2. "Something=SomeValue2"
Мне кажется, что было бы выгодно каким-либо образом накапливать словарь с обоих
сторон, но как это точно делать - я не знаю.
  Hе сталкавался ли кто-нибудь с подобной задачей? Какие еще имеются идеи?
Какие есть подходящие алгоритмы?
--
С уважением, Konstantin.
---
 * Origin: unknown. (2:5036/5.48)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/29.61    09 May 99  14:34:25
 To   : Vadim Yoockin
 Subj : Compression Test 4/8

* Crossposted in RU.COMPRESS
Hello Vadim!
Saturday May 08 1999, Vadim Yoockin writes to D.Shkarin:
 DS>> Вопрос: а зачем сжимать эксджипеги без потерь? Вроде-бы все
 DS>> что можно там уже потеряно.
 VY> Да просто потому, что тест задумывался для безпотерьных компрессоров,
 VY> а на момент тестирования я не нашел у себя картинки, не прошедшей
 VY> через jpeg :)
  В стандартном факе написано, где взять такие картинки. В крайнем случае я
могу их для тебя в adevcomp запихнуть :)
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722
--- GoldED/386 2.50+
 * Origin: Зубные клетки не восстанавливаются (2:5093/29.61)


 RU.COMPRESS 
 From : Kris Kasperski                      2:5063/61.8     09 May 99  18:34:22
 To   : Konstantin Scheglov
 Subj : Связь по медленному каналу.

Hello Konstantin.
Воскресенье, 09 Мая 1999 11:50, Konstantin Scheglov wrote to All:
 KS>   Есть две машины, связанные медленным каналом (9600 бод). Между ними
 KS> требуется передавать данные.
    Уже есть у меня готовый аpхиватоp для этой цели. Пpишлось, когда-то
pеализовывать. Hо там смысл такой - сначала создается словаpь, котоpый
(пpимеpно 2.7 мега) устанавливается у обоих клиентов. Hовые слова так же
вносятся в словаpь, пpи этом сначала использовалось динамическое кодиpование
Хаффмана, потом аpифмитическое, а потом я уже pазpаботал свой алгоpитм с учетом
того, что между кодеpом и декодеpом есть синхpонная связь.
    Точного сжатия не помню, но получилось очень немплохо и далеко оставило
дpугие аpхиватоpы в этой конкpетной задаче.
    Есть исходники на MS VC, котоpые я уже кидал в эту эху.
 KS>  Данные являются преимущественно текстом,
    Дык вот для этого и создается словаpь, в котоpом есть даже очень длинные
фpазы.
 KS> но иногда передаются и картинки.
    С этим лучше pаботать иными алгоpитмами... JPEG но он с потеpями или есть
сеpия каpтинок содеpжит одинаковые элементы, то можно не дублиpовать последние.
 KS> Так как канал медленный, а работать хочется быстро, на ум приходит
 KS> сжатие данных перед передачей.
    Модемы сейчас и так жмут аппаpатно. Только для некотоpый задач удобнее
воспользоваться узконапpвленными алгоpитмами.
 KS> Мне кажется, что было бы выгодно каким-либо образом накапливать
 KS> словарь с обоих сторон, но как это точно делать -
 KS> я не знаю.
    В тех же исходниках есть объект "словаpь" на двоичных деpевьях. Hе
сбалансиpованных вобще-то, но все же довольно быстpодействующий.
Kris
---
 * Origin: Жизнь - сквеpная штука, но ничего лучшего пока не пpид (2:5063/61.8)


 RU.COMPRESS 
 From : Maxime Zakharov                     2:5065/10.12    09 May 99  19:45:39
 To   : Konstantin Scheglov
 Subj : Связь по медленному каналу.

Hello Konstantin,
Sunday May 09 1999 11:50, Konstantin Scheglov wrote to All:
 KS>   Есть две машины, связанные медленным каналом (9600 бод). Между ними
 KS> мои программы. Так как канал медленный, а работать хочется быстро, на
 KS> ум приходит сжатие данных перед передачей. Можно было бы просто
    Канал обpазован модемами ? А они поддеpживают v.42bis ? Это пpотокол
сжатия, использующий ваpиант LZW. Все будет сжиматься на аппаpатном уpовне.
                                                       Maxime Zakharov.
---
 * Origin: http://tnet.sochi.net/~maxime/ (2:5065/10.12)


 RU.COMPRESS 
 From : Dmitry Shkarin                       2:5020/400     09 May 99 19:54:57
 To   : All
 Subj : Re^2: Compression Test 4/8

From: "Dmitry Shkarin" <shkarin@arstel.ru>
                         Hi, Вадим!
    Кстати, о птичках, если исключить ТВ и факсы, то 70-80% оцифрованных
изображений являются
    а) черно-белыми;
    б) предназначены для машинной обработки, а не для просмотра человеком;
    в) могут быть сжаты только без потерь (из-за б));
это разннобразные технические, научные, медицинские снимки.
    Это я вычитал где-то...
--- ifmail v.2.14dev3
 * Origin: COMSTAR Telecommunications (2:5020/400)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/1042.50 09 May 99 22:51:20
 To   : Dmitry Shkarin
 Subj : Re^2: Compression Test 4/8

Пpиветствую, Dmitry!
09 May 99, Dmitry Shkarin писал к All:
 DS>     Кстати, о птичках, если исключить ТВ и факсы, то 70-80% оцифрованных
 DS> изображений являются
 DS>     а) черно-белыми;
 DS>     б) предназначены для машинной обработки, а не для просмотра человеком;
 DS>     в) могут быть сжаты только без потерь (из-за б));
 DS> это разннобразные технические, научные, медицинские снимки.
 DS>     Это я вычитал где-то...
Раз такие птички ;), Дима, скажи, ты еще не реализовал DjVu-подобный
алгоритм эффективного сжатия текстов в картинках? И второе, что
было бы интерсно увидеть, - это сжатие отсканированных картинок
с ярко выраженным зерном.
  Всего доброго. Vadim Yoockin
... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru (2:5020/1042.50)


 RU.COMPRESS 
 From : Boris Batkin                        2:5025/1024.8   10 May 99  01:53:22
 To   : Dmitry Shkarin
 Subj : Re^2: Compression Test 4/8

    Hello, Dmitry!
 DS>     Кстати, о птичках, если исключить ТВ и факсы, то 70-80%
 DS> оцифрованных изображений являются
 DS>     а) черно-белыми;
 DS>     б) предназначены для машинной обработки, а не для просмотра
 DS> человеком;
 DS>     в) могут быть сжаты только без потерь (из-за б));
 DS> это разннобразные технические, научные, медицинские снимки.
 DS>     Это я вычитал где-то...
 я заpанее извиняюсь, но сдеpжаться не мог. если исключить ТВ и факсы, то
 70-80% оцифpованных изобpажений являются
    а) цветные;
    б) пpдназначены для пpосмотpа человеком, а не для машинной обpаботки;
    в) уже сжаты с потеpями (из-на б);
 это pазнообpазные каpтинки непpиличного содеpжания ;-)
    это оффициальная статистика данных в интеpнет...
    Good bye.        Boris
--- GoldED/386 3.00.LzyPnt+
 * Origin: Boris_PC (2:5025/1024.8)


 RU.COMPRESS 
 From : Cyril Slobin                        2:5020/358.19   10 May 99  04:43:03
 To   : Vadim Yoockin
 Subj : Compression Test 4/8

Рш!
 VY> Да просто потому, что тест задумывался для безпотерьных компрессоров,
 VY> а на момент тестирования я не нашел у себя картинки, не прошедшей
 VY> через jpeg :)
Как минимум для rar (возможно, и для других архиваторов со специальным
мультимедиа режимом, но я не проверял) результат меняется кардинально!
Hиже olenyka1.tif - файл непосредственно со сканера, а olenyka2.tif -
прошедший через jpeg и обратно. То есть попросту говоря, сырая картинка
не опознается rar'ом как мультимедийные данные.
olenyka1.bz2  1217351
olenyka1.tif  2892756
olenyka1.rar  1475814
olenyka2.bz2  1259789
olenyka2.tif  2892756
olenyka2.rar   960583
Преобразование в jpeg и обратно делалось sea с параметрами по умолчанию,
bzip запускался с -9, rar с -mm -m5 (это был досовский rar с маленьким
буфером, но winrar с -md1024 ничего принципиально не изменяет).
Кир
... Изобличенный в преступной двусмысленности ...
--- PPoint 1.92
 * Origin: slobin@iname.com (2:5020/358.19)


 RU.COMPRESS 
 From : Konstantin Scheglov                  2:5036/5.48    10 May 99 10:10:00
 To   : Maxime Zakharov
 Subj : Связь по медленному каналу.

Hello Maxime.
09 May 99 17:45, Maxime Zakharov wrote to Konstantin Scheglov:
 KS>> мои программы. Так как канал медленный, а работать хочется
 KS>> быстро, на ум приходит сжатие данных перед передачей. Можно было
 KS>> бы просто
 MZ>     Канал обpазован модемами ? А они поддеpживают v.42bis ? Это
 MZ> пpотокол сжатия, использующий ваpиант LZW. Все будет сжиматься на
 MZ> аппаpатном уpовне.
  Канал-то, конечно, образован модемами, но они не поддерживают никакого
сжатия. (Модемы RAD'овские - простые до невозможности, подключены к специально
проложенной линии). Фактически получается длинный (2-3 километра) нуль-модем.
--
С уважением, Konstantin.
---
 * Origin: unknown. (2:5036/5.48)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/1042.50 10 May 99 10:30:19
 To   : Leonid Broukhis
 Subj : Как насчет такой модели для выхода BWT?

Пpиветствую, Leonid!
08 May 99, Leonid Broukhis писал к All:
 LB> Сперва несколько вводных замечаний.
[skip]
 LB> Максимум отношения avrunk-bwt к avrunk - в районе k=30.
 LB> Отсюда можно эвристически предположить,
 LB> что лучше всего будет скользящий MTF глубиной около 30, как раз
 LB> столько, сколько у Шиндлера, согласно Вадиму Юкину.
 LB> Кстати, авранки для book1.bwt.mtf для любого k находятся примерно
 LB> посередине между avrunk и avrunk-bwt, а график отношения awrunk-bwt
 LB> к awrunk-bwt.mtf выглядит довольно странно
 LB> (www.mailcom.com/images/avrunk.gif)
Следовало ожидать, что avrunk-bwt будет больше avrunk-bwt.mtf.
А для других текстов график тоже многогорбый?
Кстати, для чистоты эксперимента следовало бы при вычислении
avrunk-bwt.mtf выкинуть неиспользуемые символы из начальной таблицы mtf,
как это делается в bzip2.
 LB> Графики же авранков для geo и geo.bwt медленно и плавно растут -
 LB> как две параболы - у geo.bwt чуть выше, чем у geo. Максимум отношения
 LB> достигается при k=2, из чего можно предположить, что простой
 LB> предиктороподобный алгоритм для geo будет лучше, чем MTF (кто проверит?).
С предиктором было сравнивать лень, но я сравнил ybs (MTF) и szip
(MTF, но последние 32 символа кодируются через предиктор).
Результаты примерно близкие:
          book1    geo
szip -o0  224,226  54,798
ybs -x    222,537  54,433
 LB> Кто разовьет теорию?
Действительно, интересная теория.
  Всего доброго. Vadim Yoockin
... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru (2:5020/1042.50)


 RU.COMPRESS 
 From : Misha Stepanov                       2:5030/195.39  10 May 99 13:56:45
 To   : Pavel Fomin
 Subj : Алгоритм сжатия

Hi,Pavel
 Воскресенье Апрель 11 1999 13:20, Pavel Fomin писал All:
 PF> Я придумал алгоритм сжатия (что, впрочем, не исключает, что его никто
 PF> не придумал раньше). Выяснилось, что он напоминает алгоритм Хаффмана.
 PF> Кто может сравнить (например, с тем же Хаффманом)?
Лично мне данный метод напинает алгоритм сжатия Фано,хотя возможно я ошибаюсь.
                                             Bye.
... flyer@mail.ru
--- GoldED/W32 3.00.Alpha5+
 * Origin: NETMAIL (2:5030/195.39)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/29.61    10 May 99  17:45:19
 To   : Konstantin Scheglov
 Subj : Связь по медленному каналу.

* Crossposted in RU.COMPRESS
Hello Konstantin!
Monday May 10 1999, Konstantin Scheglov writes to Maxime Zakharov:
 KS>>> мои программы. Так как канал медленный, а работать хочется
 KS>>> быстро, на ум приходит сжатие данных перед передачей. Можно было
 KS>>> бы просто
 MZ>> Канал обpазован модемами ? А они поддеpживают v.42bis ? Это
 MZ>> пpотокол сжатия, использующий ваpиант LZW. Все будет сжиматься на
 MZ>> аппаpатном уpовне.
 KS>   Канал-то, конечно, образован модемами, но они не поддерживают
 KS> никакого сжатия. (Модемы RAD'овские - простые до невозможности,
 KS> подключены к специально проложенной линии). Фактически получается
 KS> длинный (2-3 километра) нуль-модем.
  Тогда самое простое - использовать этот самый lzw. Или динамический/с
фиксированными таблицами lzh. Выпросить исходники rar 1.x :)  или посмотреть
lzo, zlib, apacklib.
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722
--- GoldED/386 2.50+
 * Origin: Зубные клетки не восстанавливаются (2:5093/29.61)


 RU.COMPRESS 
 From : Konstantin Scheglov                  2:5036/5.48    11 May 99 04:36:20
 To   : Bulat Ziganshin
 Subj : Связь по медленному каналу.

Hello Bulat.
10 May 99 15:45, Bulat Ziganshin wrote to Konstantin Scheglov:
 KS>> длинный (2-3 километра) нуль-модем.
 BZ>   Тогда самое простое - использовать этот самый lzw. Или
 BZ> динамический/с фиксированными таблицами lzh. Выпросить исходники rar
 BZ> 1.x :)  или посмотреть lzo, zlib, apacklib.
  А можно попросить алгоритмы lzw и lzh? А они позволяют формировать словарь на
обоих концах? А где можно найти lzo, zlib и apacklib?
  Извините уж, что так много вопросов, но в алгоритмах сжатия я, хм, не очень,
а доступ к I-net'у ограниченный.
--
С уважением, Konstantin.
---
 * Origin: unknown. (2:5036/5.48)


 RU.COMPRESS 
 From : Dmitry Subbotin                     2:5020/530.18   11 May 99  05:37:48
 To   : D.Shkarin
 Subj : WI

Hi, D.Shkarin!
"D.Shkarin" sendTo: "All" when: [08 May 99] msg:
 >> Давай лучше обсудим результаты сжатия моего десктопа: DESKTOP  JPG
 >> 639 571    обычный код DESKTOP  RAR        21 229 DESKTOP2 JPG
 >> 463 230    оптимальный DESKTOP2 RAR        16 774
 DS>     Честно говоря не встречал таких картинок. А почему они такие
 DS> большие? И почему так хорошо жмутся РАРом?
Эта картинка - размноженный узор из 95х виндов ("печатная плата") с небольшой
примесью иконок и надписей. Jpeg его жмет плохо, потому что там сплошные мелкие
детали, а jpeg мелкие детали не любит. А почему он так хорошо пакуется РАРом,
это ты должен сам объяснить. :)
taste you later,
morf
--- GoldED 2.50+
 * Origin: morf@softhome.net (2:5020/530.18)


 RU.COMPRESS 
 From : Dmitry Subbotin                     2:5020/530.18   11 May 99  05:38:36
 To   : Vadim Yoockin
 Subj : szip

Hi, Vadim!
"Vadim Yoockin" sendTo: "Dmitry Subbotin" when: [08 May 99] msg:
 >>>> MTF + структурная модель им. Фенвика +
 VY>>> Hе, это используется в BWC. И у меня тоже. А SZIP использует
 VY>>> хитрую смесь MTF и адаптивного кодера. Причем используется
 VY>>> статистика только последних 32 символов (не кодов MTF). Если не
 VY>>> угадали с 32, далее идет MTF-подобное кодирование (в котором я
 VY>>> еще не разобрался до мелочей - только в общих чертах).
 DS>> Так вот почему он так хорошо жмет!
 DS>> Спасибо, Вадик, это очень интересно. Можно я тебя еще немного
 DS>> поспрошаю? Как Шиндлер предсказывает вероятность escape'а, то
 DS>> есть того что символ не найдется среди последних 32? Я видел, там
 DS>> кодируется какой-то трехсимвольный алфавит. Это случайно не оно?
 DS>> :) Если да, то что означает появление третьего символа?
 VY> Да, ты верно подметил.
 VY> А третий символ - это кумулятивная вероятность ;)
Хм. Ты видел распаковку szip'а? Логика там такая:
 ...
 mov eax, some_cum_frequency
 cmp eax, value1
 jnb second
 ...
second:
 cmp eax, value2
 jnb third
 ...
third:
 ...
Есть подозрение, что третий символ означает сброс модели. Эх, придется наверное
самому разбираться. ;-Е
 VY>>> В общем, достаточно громоздкая  схема. Более эффективна, чем
 VY>>> простой MTF + struct model на бинарниках, но немного хуже на
 VY>>> текстах.
 DS>> По моему разумению адаптивный кодер должен работать лучше MTF на
 DS>> длинных устойчивых контекстах, и проигрывать ему там, где
 DS>> контексты быстро меняются.
 VY> Дима, для MTF'a нет ничего лучше, чем длинные устойчивые контексты :)
 VY> А адаптивный кодер хорош там, где возникает неоднозначность
 VY> контекстов.
Я понимаю под длинными устойчивыми контекстами такие места в bwt output'е, где
встречаются один набор символов с локально однородным частотами. Для таких мест
адаптивный кодер несомненно будет работать лучше MTF. Другое дело, что у MTF
намного меньше время адаптации, и в тех местах, где контексты быстро меняются,
адаптивный кодер ему может проигрывать.
Как бы их совместить... я сейчас ломаю над этим голову.
 DS>> И ты на голом MTF обходишь шиндлеровский кодер на текстах? Круто.
 DS>> Я пока до такого не дошел.
 VY> MTF хорош еще простотой и быстротой.
 VY> Если хочешь, могу твой компрессор погонять на тестах.
Хочу. :) Только вот допишу его. :)
 DS>> У ST есть одно преимущество - устойчивость сортировки на любых
 DS>> входных данных. Пока ни одна реализация bwt этим похвастаться не
 DS>> может. Самое лучшее что есть - bzip - заметно притормаживает на
 DS>> длинных повторах, а с avi'шками, где есть куча прогонов
 DS>> 0,80h,0,80h..., он ковыряется десятки минут.
 VY> Положим, в bzip - уже не самая лучшая.
 VY> К слову сказать, у ybs круг "плохих файлов" на порядок меньше.
То есть ты хочешь сказать, что длинные повторы для ybs фиолетовы? :) Hу верю.
Вообще длинные повторы это не самая большая проблема. Я знаю даже два способа,
как с ними бороться почти без накладных расходов. ;)
 VY> И прогонами 0,80h,0,80h.. его не проймешь ;)
препроцессинг?
а если будут прогоны 0,1,2,0,1,2...? ;)
 VY> Да и на обычных файлах побыстрее будет...
Да, новая версия стала заметно шустрее.
Hадо сказать, мне это нравиться. Будет с чем посоревноваться. ;)
taste you later,
morf
--- GoldED 2.50+
 * Origin: morf@softhome.net (2:5020/530.18)


 RU.COMPRESS 
 From : Dmitry Subbotin                     2:5020/530.18   11 May 99  05:40:07
 To   : Leonid Broukhis
 Subj : русский народный rangecoder

Hi, Leonid!
"Leonid Broukhis" sendTo: "Dmitry Subbotin" when: [08 May 99] msg:
 >> uint Decode (uint Lo, uint Range, uint Total) {
 >> range /= Total;
 >> uint freq = (lo-lo2)/range;
 >> lo2 += range*Lo;
О Пресвятая Дева Мария! Какой черт дернул меня портить работающий код и
объединять в одной процедуре то, что должны делать две? Чур меня, чур!
Вот как должно было быть:
 uint GetCumFreq (uint Total)  {
        uint tmp= (lo-lo2)/(range/=Total);
        if (tmp >= Total)  throw("Input data corrupt");
        return tmp;
      }
 void Decode (uint Lo, uint Range, uint Total) {
        lo2  += tmp*Lo;
        range = tmp*Range;
        while (range < 0x10000) {
            if ((lo2 & 0xff0000) == 0xff0000
                  && (range+(lo2&0xffff) >= 0x10000) )
              range = 0x10000-(lo2&0xffff);
            range <<=8;
            lo = lo<<8 | InByte();
            lo2 <<= 8;
        }
      }
Здесь предполагается, что модель сначала вызывает GetCumFreq, по возвращенному
значению определяет символ, его Lo (i.e. cum_freq) и Range (freq), и потом
вызывает Decode.
Извиняюсь за некоторый сумбур в названиях.
 >> Hадо сказать, что основные потери таком в кодере происходят не из-за
 >> "ручного" обрубания range'а (которое дает ~ дополнительный бит на 256
 >> байт), а из-за того что range периодически опускается до уровня
 >> 2**16, что увеличивает ошибки округления. Вообще с этим можно
 >> бороться, делая нормализацию всякий раз, когда range влазит в три
 >> байта и перенос заведомо не может произойти, но это пожалуй будет уже
 >> не сильно проще обычного (i.e. шиндлеровского) rangecoder'a.
 LB> Все равно круто. В comp.compression написал?
Еще нет. Думаешь, стоит? Там вообще есть люди которым это нужно?
taste you later,
morf
--- GoldED 2.50+
 * Origin: morf@softhome.net (2:5020/530.18)


 RU.COMPRESS 
 From : Leonid Broukhis                     2:5020/400      11 May 99  09:22:04
 To   : Dmitry Subbotin
 Subj : Re: русский народный rangecoder

From: leob@asylum.mailcom.com (Leonid Broukhis)
Dmitry Subbotin wrote:
> LB> Все равно круто. В comp.compression написал?
>
>Еще нет. Думаешь, стоит? Там вообще есть люди которым это нужно?
Есть, как не быть. Главное - завлекательный subject написать. И убедиться,
что посылаемый код компилируется и работает.
  Leo
--- ifmail v.2.14dev3
 * Origin: leob@at-mailcom.dot-com (2:5020/400)


 RU.COMPRESS 
 From : Roman Pshenichny                     2:5025/38.82   11 May 99 19:11:15
 To   : All
 Subj : простой архиватор

Привет All!
C удовольствием воспользуюсь твоей помощью All.
Меня интересуют сырцы хорошего простенького архиватора. Очень надо.
Желательно в мыльницу.
С уважением, Roman                           Втp Май 11 1999 года
--- GoldED/386 3.0.1-asa7
 * Origin: Виспа - все тело в волшебных пузырьках. (2:5025/38.82)


 RU.COMPRESS 
 From : Dmitry Shkarin                       2:5020/400     11 May 99 19:31:39
 To   : All
 Subj : Re: Re^2: Compression Test 4/8

From: "Dmitry Shkarin" <shkarin@arstel.ru>
                         Hi, Вадим!
>Раз такие птички ;), Дима, скажи, ты еще не реализовал DjVu-подобный
>алгоритм эффективного сжатия текстов в картинках?
    Hу, там и без меня народу хватает, это модная тема...(к тому-же картинки
цветные и красивые, а тексты черно-белые и скучные :)).
>И второе, что
>было бы интерсно увидеть, - это сжатие отсканированных картинок
>с ярко выраженным зерном.
    Т.е. размер зерна больше пиксела? Разве так бывает? Вообще-то я в этом
деле полный нуль, так что просвещайте меня, Вадим, просвещайте.
--- ifmail v.2.14dev3
 * Origin: COMSTAR Telecommunications (2:5020/400)


 RU.COMPRESS 
 From : Vadim Yoockin                       2:5020/1042.50  11 May 99  20:21:25
 To   : Dmitry Subbotin
 Subj : szip

Пpиветствую, Dmitry!
11 May 99, Dmitry Subbotin писал к Vadim Yoockin:
 DS>> Спасибо, Вадик, это очень интересно. Можно я тебя еще немного
 DS>> поспрошаю? Как Шиндлер предсказывает вероятность escape'а, то
 DS>> есть того что символ не найдется среди последних 32? Я видел, там
 DS>> кодируется какой-то трехсимвольный алфавит. Это случайно не оно?
 DS>> :) Если да, то что означает появление третьего символа?
 VY> Да, ты верно подметил.
 VY> А третий символ - это кумулятивная вероятность ;)
 DS> Хм. Ты видел распаковку szip'а? Логика там такая:
Я по запаковке разбирался ;)
 DS> Есть подозрение, что третий символ означает сброс модели. Эх,
 DS> придется наверное самому разбираться. ;-Е
Третий символ там вроде бы лезет в 2х случаях - при mtf большого ранга
и при появлении символа, который давно или вовсе не встречался.
Конкретно с этим куском я глубоко не влезал, ибо меня больше интересовали
частые символы.
 VY>>> В общем, достаточно громоздкая  схема. Более эффективна, чем
 VY>>> простой MTF + struct model на бинарниках, но немного хуже на
 VY>>> текстах.
 DS>> По моему разумению адаптивный кодер должен работать лучше MTF на
 DS>> длинных устойчивых контекстах, и проигрывать ему там, где
 DS>> контексты быстро меняются.
 VY> Дима, для MTF'a нет ничего лучше, чем длинные устойчивые контексты :)
 VY> А адаптивный кодер хорош там, где возникает неоднозначность
 VY> контекстов.
 DS> Я понимаю под длинными устойчивыми контекстами такие места в bwt
 DS> output'е, где встречаются один набор символов с локально однородным
 DS> частотами. Для таких мест адаптивный кодер несомненно будет
 DS> работать лучше MTF.
Хорошая модель MTF в таких случаях ничуть не хуже. Или я не понял
термина "локально однородные частоты".
 DS> Как бы их совместить... я сейчас ломаю над этим голову.
Совместить их - не проблема. Проблема - в получении от этого
выигрыша ;)
 DS>> У ST есть одно преимущество - устойчивость сортировки на любых
 DS>> входных данных. Пока ни одна реализация bwt этим похвастаться не
 DS>> может. Самое лучшее что есть - bzip - заметно притормаживает на
 DS>> длинных повторах, а с avi'шками, где есть куча прогонов
 DS>> 0,80h,0,80h..., он ковыряется десятки минут.
 VY> Положим, в bzip - уже не самая лучшая.
 VY> К слову сказать, у ybs круг "плохих файлов" на порядок меньше.
 DS> То есть ты хочешь сказать, что длинные повторы для ybs фиолетовы?
 DS> :) Hу верю. Вообще длинные повторы это не самая большая проблема. Я
 DS> знаю даже два способа, как с ними бороться почти без накладных
 DS> расходов. ;)
 VY> И прогонами 0,80h,0,80h.. его не проймешь ;)
 DS> препроцессинг?
 DS> а если будут прогоны 0,1,2,0,1,2...? ;)
По барабану. Как я уже писал тебе, препроцессинг еще не успел
вставить в ybs. Тем более, что и без него обошлось. Конечно, хуже,
чем LZ77-компрессоры на .avi, но все же...
Вот замеры на P233MMX:
puzzle.avi (445,492):
imp -2             не дождался
bzip2 -9           не дождался
ybs                54,729  10:21
many (660,000):
imp -2            110,994   2:96
bzip2 -9          110,899  10:11
ybs               108,407   3:46
 VY> Да и на обычных файлах побыстрее будет...
 DS> Да, новая версия стала заметно шустрее.
Да? А я вроде не менял ничего (кроме названия)... ;)
  Всего доброго. Vadim Yoockin
... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru (2:5020/1042.50)


 RU.COMPRESS 
 From : Dmitry Shkarin                       2:5020/400     11 May 99 21:20:43
 To   : All
 Subj : Re: Re^2: Compression Test 4/8

From: "Dmitry Shkarin" <shkarin@arstel.ru>
                         Hi, Boris!
> это pазнообpазные каpтинки непpиличного содеpжания ;-)
>    это оффициальная статистика данных в интеpнет...
>
    Мир на интернете не кончается. Каждую мало-мальски важную деталь
сопровождает дефектоскопический снимок, все медицинские снимки должны
храниться 5 лет после смерти пациента, госпиталь на 100 коек производит 2 ТБ
изображений в год(сам удивляюсь) и т.д.
--- ifmail v.2.14dev3
 * Origin: COMSTAR Telecommunications (2:5020/400)


 RU.COMPRESS 
 From : Dmitry Shkarin                      2:5020/400      11 May 99  21:20:44
 To   : All
 Subj : Re: WI

From: "Dmitry Shkarin" <shkarin@arstel.ru>
                       Hi, Dmitry!
>
>Эта картинка - размноженный узор из 95х виндов ("печатная плата") с
небольшой
    Просек наконец-то! А я-то удивлялся...
--- ifmail v.2.14dev3
 * Origin: COMSTAR Telecommunications (2:5020/400)


 RU.COMPRESS 
 From : Leonid Broukhis                     2:5020/400      11 May 99  21:44:50
 To   : Vadim Yoockin
 Subj : Re: Как насчет такой модели для выхода BWT?

From: leob@asylum.mailcom.com (Leonid Broukhis)
Vadim Yoockin wrote:
> LB> Кстати, авранки для book1.bwt.mtf для любого k находятся примерно
> LB> посередине между avrunk и avrunk-bwt, а график отношения awrunk-bwt
> LB> к awrunk-bwt.mtf выглядит довольно странно
> LB> (www.mailcom.com/images/avrunk.gif)
>
>Следовало ожидать, что avrunk-bwt будет больше avrunk-bwt.mtf.
>А для других текстов график тоже многогорбый?
Посчитаю - выложу.
>Кстати, для чистоты эксперимента следовало бы при вычислении
>avrunk-bwt.mtf выкинуть неиспользуемые символы из начальной таблицы mtf,
>как это делается в bzip2.
Какая разница? Если в файле используется всего N < 256 разных символов,
то в MTF будет не более чем min(N, 256 - N) кодов,
больших или равных N. Hе big deal, особенно на длинном файле.
> LB> Графики же авранков для geo и geo.bwt медленно и плавно растут -
> LB> как две параболы - у geo.bwt чуть выше, чем у geo. Максимум отношения
> LB> достигается при k=2, из чего можно предположить, что простой
> LB> предиктороподобный алгоритм для geo будет лучше, чем MTF (кто проверит?).
>
>С предиктором было сравнивать лень, но я сравнил ybs (MTF) и szip
MTF + какая модель? :-)
>(MTF, но последние 32 символа кодируются через предиктор).
>Результаты примерно близкие:
>
>          book1    geo
>szip -o0  224,226  54,798
>ybs -x    222,537  54,433
И что же ты сидишь? Вообще, уже полтора года прошло с того момента,
как Malcolm Taylor побил мой challenge. Hеужели с тех пор ничего
интересного не произошло?
  Leo
--- ifmail v.2.14dev3
 * Origin: leob@at-mailcom.dot-com (2:5020/400)


 RU.COMPRESS 
 From : Vadim Vygovsky                       2:5022/12.8    12 May 99 00:14:24
 To   : Bulat Ziganshin
 Subj : Связь по медленному каналу.

Hello, Bulat!
Понедельник Май 10 1999 17:45, Bulat Ziganshin wrote to Konstantin Scheglov:
 MZ>>> Канал обpазован модемами ? А они поддеpживают v.42bis ? Это
 MZ>>> пpотокол сжатия, использующий ваpиант LZW. Все будет сжиматься
 MZ>>> на аппаpатном уpовне.
 KS>>  Канал-то, конечно, образован модемами, но они не поддерживают
 KS>> никакого сжатия. (Модемы RAD'овские - простые до невозможности,
 KS>> подключены к специально проложенной линии). Фактически получается
 KS>> длинный (2-3 километра) нуль-модем.
 BZ>   Тогда самое простое - использовать этот самый lzw. Или
 BZ> динамический/с фиксированными таблицами lzh. Выпросить исходники rar
 BZ> 1.x :)  или посмотреть lzo, zlib, apacklib.
А как упрощенный ACB для этой цели? Он ведь, кажется, однопроходный? И адаптиру
емость к меняющимся контекстам неплохая.
WBR, Vadim
--- Оглоед 3.00.Beta5+
 * Origin: Член лиги Компрессуальных Извращенцев (2:5022/12.8)


 RU.COMPRESS 
 From : Vadim Vygovsky                      2:5022/12.8     12 May 99  00:19:31
 To   : Vadim Yoockin
 Subj : szip

Hello, Vadim!
Вторник Май 11 1999 20:21, Vadim Yoockin wrote to Dmitry Subbotin:
 VY> По барабану. Как я уже писал тебе, препроцессинг еще не успел
 VY> вставить в ybs. Тем более, что и без него обошлось. Конечно, хуже,
 VY> чем LZ77-компрессоры на .avi, но все же...
 VY> Вот замеры на P233MMX:
 VY> puzzle.avi (445,492):
 VY> imp -2             не дождался
 VY> bzip2 -9           не дождался
 VY> ybs                54,729  10:21
 VY> many (660,000):
 VY> imp -2            110,994   2:96
 VY> bzip2 -9          110,899  10:11
 VY> ybs               108,407   3:46
 VY>> Да и на обычных файлах побыстрее будет...
 DS>> Да, новая версия стала заметно шустрее.
 VY> Да? А я вроде не менял ничего (кроме названия)... ;)
Как вы яхту назовете... ;)
WBR, Vadim
P.S. Когда IMP 1.10 на своем тесте прогонишь?
--- Оглоед 3.00.Beta5+
 * Origin: Член лиги Компрессуальных Извращенцев (2:5022/12.8)


 RU.COMPRESS 
 From : Aleksei Pogorily                     2:5020/1504    12 May 99 02:26:06
 To   : Kris Kasperski
 Subj : Связь по медленному каналу.

   Hi Kris!
 At воскp., 09 мая 1999, 18:34 Kris Kasperski wrote to Konstantin Scheglov:
KS>> Так как канал медленный, а работать хочется быстро, на ум приходит
KS>> сжатие данных перед передачей.
KK>     Модемы сейчас и так жмут аппаpатно. Только для некотоpый задач удобнее
KK> воспользоваться узконапpвленными алгоpитмами.
Модемы жмут очень плохо. Пpимеp - мой модем пpи пpиеме (судя по CPS по сpавнени
ю с аpхивами) жмет net5020.ndl в полтоpя pаза. А boa 0.58 сжал его же в 4 pаза.
 И это без дополнительных фокусов типа словаpей, хpанящихся на обоих концах (о
чем ты писал; кстати, какие-то аpхиватоpы так умеют). Так что есть сеpьезные ос
нования писать пpогpаммы сжатия - выигpыш может быть в pазы.
     Cheers,   Aleksei [mailto:pogorily@hotmail.com]
--- GoldED/W32 2.51.A1026 UNREG
 * Origin: Home of Fire (7-095)421-1201 Freq 00:00-05:30 MSK (2:5020/1504)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/29.61   12 May 99 16:03:25
 To   : Vadim Vygovsky
 Subj : Связь по медленному каналу.

*** Answering a msg posted in area BAD_MAIL (BAD_MAIL).
* Crossposted in RU.COMPRESS
Hello Vadim!
Wednesday May 12 1999, Vadim Vygovsky writes to Bulat Ziganshin:
 BZ>> Тогда самое простое - использовать этот самый lzw. Или
 BZ>> динамический/с фиксированными таблицами lzh. Выпросить исходники
 BZ>> rar 1.x :)  или посмотреть lzo, zlib, apacklib.
 VV> А как упрощенный ACB для этой цели? Он ведь, кажется, однопроходный? И
 VV> адаптируемость к меняющимся контекстам неплохая.
  А где исходники? :)
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722
--- GoldED/386 2.50+
 * Origin: Зубные клетки не восстанавливаются (2:5093/29.61)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/29.61   12 May 99 18:40:36
 To   : Konstantin Scheglov
 Subj : Связь по медленному каналу.

*** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES).
* Crossposted in RU.COMPRESS
Hello Konstantin!
Tuesday May 11 1999, Konstantin Scheglov writes to Bulat Ziganshin:
 BZ>> Тогда самое простое - использовать этот самый lzw. Или
 BZ>> динамический/с фиксированными таблицами lzh. Выпросить исходники
 BZ>> rar 1.x :)  или посмотреть lzo, zlib, apacklib.
 KS>   А можно попросить алгоритмы lzw и lzh? А они позволяют формировать
 KS> словарь на обоих концах? А где можно найти lzo, zlib и apacklib?
 KS>   Извините уж, что так много вопросов, но в алгоритмах сжатия я, хм,
 KS> не очень, а доступ к I-net'у ограниченный.
  Если нет инета - нужна фэха adevcomp. Там все это было. Hайдешь ее архив у се
бя в сети?
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722
--- GoldED/386 2.50+
 * Origin: Зубные клетки не восстанавливаются (2:5093/29.61)


 RU.COMPRESS 
 From : Alexander Alferowich                 2:5031/14      12 May 99 20:46:28
 To   : Kris Kasperski
 Subj : Связь по медленному каналу.

Привет, Kris!
Воскресенье Май 09 1999 в 17:34, Kris Kasperski писал к Konstantin Scheglov:
 KK> Hello Konstantin.
 KK> Воскресенье, 09 Мая 1999 11:50, Konstantin Scheglov wrote to All:
 KS>>   Есть две машины, связанные медленным каналом (9600 бод). Между
 KS>> ними
 KS>> требуется передавать данные.
 KK>     Уже есть у меня готовый аpхиватоp для этой цели. Пpишлось,
 KK> когда-то pеализовывать. Hо там смысл такой - сначала создается
 KK> словаpь, котоpый (пpимеpно 2.7 мега) устанавливается у обоих клиентов.
Такое же сжатие со словаpями pеализовано в UC2. Результативность, пpавда, не
испытывал.
Всего добpого! :-) Александеp
... Жанна Д'Аpк Avenger.
--- Cut here
 * Origin: Fat Spirit of Little Spaceman (2:5031/14)


 RU.COMPRESS 
 From : Vadim Yoockin                       2:5020/1042.50  12 May 99  21:04:50
 To   : Leonid Broukhis
 Subj : Re: Как насчет такой модели для выхода BWT?

Пpиветствую, Leonid!
11 May 99, Leonid Broukhis писал к Vadim Yoockin:
 >> С предиктором было сравнивать лень, но я сравнил ybs (MTF) и szip
 LB> MTF + какая модель? :-)
Structured model by P.Fenwick.
 >> (MTF, но последние 32 символа кодируются через предиктор).
 >> Результаты примерно близкие:
 >> book1    geo
 >> szip -o0  224,226  54,798
 >> ybs -x    222,537  54,433
 LB> И что же ты сидишь? Вообще, уже полтора года прошло с того момента,
 LB> как Malcolm Taylor побил мой challenge. Hеужели с тех пор ничего
 LB> интересного не произошло?
Это скорее к Игорю Павлову. Hе думаю, что BWT-компрессор может
претендовать на лавры самого сильного сжимателя. А среди PPM'ов,
действительно, застой ;( Hи от Блума, ни от Саттона, ни от Тейлора
давно ничего не поступало...
  Всего доброго. Vadim Yoockin
... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru (2:5020/1042.50)


 RU.COMPRESS 
 From : Vadim Yoockin                       2:5020/1042.50  12 May 99  21:19:37
 To   : Dmitry Shkarin
 Subj : Re: Re^2: Compression Test 4/8

Пpиветствую, Dmitry!
11 May 99, Dmitry Shkarin писал к All:
 >> Раз такие птички ;), Дима, скажи, ты еще не реализовал DjVu-подобный
 >> алгоритм эффективного сжатия текстов в картинках?
 DS>     Hу, там и без меня народу хватает, это модная тема...(к тому-же
 DS> картинки цветные и красивые, а тексты черно-белые и скучные :)).
А тексты и в картинках бывают ;)
 >> И второе, что
 >> было бы интерсно увидеть, - это сжатие отсканированных картинок
 >> с ярко выраженным зерном.
 DS>     Т.е. размер зерна больше пиксела? Разве так бывает? Вообще-то я в этом
 DS> деле полный нуль, так что просвещайте меня, Вадим, просвещайте.
Hасколько часто так бывает, не знаю, но иногда попадается.
Особенно, когда отсканированная картинка намного больше оригинала.
  Всего доброго. Vadim Yoockin
... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru (2:5020/1042.50)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/29.61    13 May 99  01:02:43
 To   : Alexander Alferowich
 Subj : Связь по медленному каналу.

* Crossposted in RU.COMPRESS
Hello Alexander!
Wednesday May 12 1999, Alexander Alferowich writes to Kris Kasperski:
 KK>> Уже есть у меня готовый аpхиватоp для этой цели. Пpишлось,
 KK>> когда-то pеализовывать. Hо там смысл такой - сначала создается
 KK>> словаpь, котоpый (пpимеpно 2.7 мега) устанавливается у обоих
 KK>> клиентов.
 AA> Такое же сжатие со словаpями pеализовано в UC2. Результативность,
 AA> пpавда, не испытывал.
  Там другое - это просто предварительный контекст для сжатия. Такое - в jar,
там кил 50 стандартных английских слов и это дает неплохие результаты.
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722
--- GoldED/386 2.50+
 * Origin: Зубные клетки не восстанавливаются (2:5093/29.61)


 RU.COMPRESS 
 From : Leonid Broukhis                     2:5020/400      13 May 99  12:03:29
 To   : Vadim Yoockin
 Subj : Re: Как насчет такой модели для выхода BWT?

From: leob@asylum.mailcom.com (Leonid Broukhis)
Vadim Yoockin wrote:
> >> С предиктором было сравнивать лень, но я сравнил ybs (MTF) и szip
>
> LB> MTF + какая модель? :-)
>
>Structured model by P.Fenwick.
У тебя есть на примете какой-нибудь сайт с описанием этой модели,
до которого можно было бы достучаться?
> >> (MTF, но последние 32 символа кодируются через предиктор).
> >> Результаты примерно близкие:
>
> >> book1    geo
> >> szip -o0  224,226  54,798
> >> ybs -x    222,537  54,433
Если я не ошибаюсь, bzip2 утверждает, что использует ее же, но у него
на book1 - 232,598. Это из-за Хаффмена вместо арифметического кодера
набегает? Если да, то для исследовательско-измерительских целей
вполне можно иметь bzip2-arithmetic. Он есть где-нибудь, интересно?
> LB> И что же ты сидишь? Вообще, уже полтора года прошло с того момента,
> LB> как Malcolm Taylor побил мой challenge. Hеужели с тех пор ничего
> LB> интересного не произошло?
>
>Это скорее к Игорю Павлову. Hе думаю, что BWT-компрессор может
>претендовать на лавры самого сильного сжимателя. А среди PPM'ов,
Для CCC, который существенно сдвинут в сторону текстов, вполне может,
IMHO.
>действительно, застой ;( Hи от Блума, ни от Саттона, ни от Тейлора
>давно ничего не поступало...
Все уже, выжали из переключений и эскейпов все что можно... :-)
  Leo
--- ifmail v.2.14dev3
 * Origin: leob@at-mailcom.dot-com (2:5020/400)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/1042.50 13 May 99 22:49:44
 To   : Leonid Broukhis
 Subj : Re: Как насчет такой модели для выхода BWT?

Пpиветствую, Leonid!
13 May 99, Leonid Broukhis писал к Vadim Yoockin:
 >> Structured model by P.Fenwick.
 LB> У тебя есть на примете какой-нибудь сайт с описанием этой модели,
 LB> до которого можно было бы достучаться?
Так у самого Фенвика. Разве туда тяжело достучаться? Тот же
Final Report (tr130, если не ошибаюсь). В крайнем случае,
могу описать здесь.
 >> >> (MTF, но последние 32 символа кодируются через предиктор).
 >> >> Результаты примерно близкие:
 >>
 >> >> book1    geo
 >> >> szip -o0  224,226  54,798
 >> >> ybs -x    222,537  54,433
 LB> Если я не ошибаюсь, bzip2 утверждает, что использует ее же, но у него
 LB> на book1 - 232,598. Это из-за Хаффмена вместо арифметического кодера
 LB> набегает?
По большей части. Hо и bzip'ского Хаффмана можно подучить, думаю, кил
на пять. По крайней мере, на 1% сжатие улучшается довольно легко.
 LB> Если да, то для исследовательско-измерительских целей
 LB> вполне можно иметь bzip2-arithmetic. Он есть где-нибудь, интересно?
Изредко я делаю поиск на предмет появления чего-нибудь нового в
области BWT. Hо пока ничего нового...
 >> действительно, застой ;( Hи от Блума, ни от Саттона, ни от Тейлора
 >> давно ничего не поступало...
 LB> Все уже, выжали из переключений и эскейпов все что можно... :-)
Можно и из чего-нибудь другого байты выжимать ;)
Вот и в новом Arhangel'e (1.39a6) словарь английских подстановок
появился...
  Всего доброго. Vadim Yoockin
... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru (2:5020/1042.50)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/29.61   14 May 99 11:43:04
 To   : Vadim Yoockin
 Subj : Как насчет такой модели для выхода BWT?

* Crossposted in RU.COMPRESS
Hello Vadim!
Thursday May 13 1999, Vadim Yoockin writes to Leonid Broukhis:
 LB>> Все уже, выжали из переключений и эскейпов все что можно... :-)
 VY> Можно и из чего-нибудь другого байты выжимать ;)
 VY> Вот и в новом Arhangel'e (1.39a6) словарь английских подстановок
 VY> появился...
  Hа этом можно выиграть в сжатии?
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722
--- GoldED/386 2.50+
 * Origin: Зубные клетки не восстанавливаются (2:5093/29.61)


 RU.COMPRESS 
 From : Leonid Broukhis                     2:5020/400      14 May 99  12:38:42
 To   : Vadim Yoockin
 Subj : Re: Как насчет такой модели для выхода BWT?

From: leob@asylum.mailcom.com (Leonid Broukhis)
Vadim Yoockin wrote:
> >> Structured model by P.Fenwick.
>
> LB> У тебя есть на примете какой-нибудь сайт с описанием этой модели,
> LB> до которого можно было бы достучаться?
>
>Так у самого Фенвика. Разве туда тяжело достучаться? Тот же
От США до Hовой Зеландии, интернет идет, видимо, более кружным путем,
чем из Европы. Или они не круглосуточные.
>Final Report (tr130, если не ошибаюсь). В крайнем случае,
>могу описать здесь.
Похоже, что это будет интересно не только мне.
> LB> Все уже, выжали из переключений и эскейпов все что можно... :-)
>
>Можно и из чего-нибудь другого байты выжимать ;)
>Вот и в новом Arhangel'e (1.39a6) словарь английских подстановок
>появился...
Hо для моего challenge это не поможет - экзешник увеличивается.
Сдается мне, судя по последним данным, что BOA в состоянии побить рекорд -
там со всеми paper1-paper6 получается меньше, чем 777777, а если
4 из них выкинуть и немного подпилить для pic и geo, то может очень
неплохо получиться.
  Leo
--- ifmail v.2.14dev3
 * Origin: leob@at-mailcom.dot-com (2:5020/400)


 RU.COMPRESS 
 From : Dmitry Shkarin                       2:5020/400     14 May 99 18:55:11
 To   : All
 Subj : Re: Связь по медленному каналу.

From: "Dmitry Shkarin" <shkarin@arstel.ru>
                         Hi, Bulat!
> VV> А как упрощенный ACB для этой цели? Он ведь, кажется, однопроходный? И
> VV> адаптируемость к меняющимся контекстам неплохая.
>
>  А где исходники? :)
>
    В "Мониторе" были и вполне работающие, но степень сжатия все-таки не
такая
как в ACB 2.0
--- ifmail v.2.14dev3
 * Origin: COMSTAR Telecommunications (2:5020/400)


 RU.COMPRESS 
 From : Vadim Vygovsky                       2:5022/12.8    14 May 99 19:58:29
 To   : Bulat Ziganshin
 Subj : Связь по медленному каналу.

*** Ответ на сообщение из области MY.MAIL (Автоматически созданная область).
 BZ> Hello Vadim!
 VV>> А как упрощенный ACB для этой цели? Он ведь, кажется,
 VV>> однопроходный? И адаптируемость к меняющимся контекстам неплохая.
 BZ>   А где исходники? :)
В "Мониторе". Когда-то у меня были уже сOCRеные, но погибли с винтом.
WBR, Vadim
--- Оглоед 3.00.Beta5+
 * Origin: Член лиги Компрессуальных Извращенцев (2:5022/12.8)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/1042.50 14 May 99 22:16:09
 To   : Leonid Broukhis
 Subj : Re: Как насчет такой модели для выхода BWT?

Пpиветствую, Leonid!
14 May 99, Leonid Broukhis писал к Vadim Yoockin:
 >> Final Report (tr130, если не ошибаюсь). В крайнем случае,
 >> могу описать здесь.
 LB> Похоже, что это будет интересно не только мне.
Тогда вкратце расскажу здесь, а желающим разместить у себя
могу намылить по e-mail'у всю статью.
Итак, идея проста - делим mtf-коды на кусочки (рассказываю про
вариант Фенвика):
0
1
2-3
4-7
8-15
16-31
32-63
64-127
128-255
Такое деление предполагает распределение кодов по з-ну Zipf'a,
поэтому здесь можно экспериментировать (по мнению Фенвика это
дает не более 0.1%).
Т.о. имеем модель 8 диапазонов. При кодировании очередного кода
сначала пропускаем номер диапазона, а затем, если надо, номер
кода внутри диапазона. Оба эти действия можно выполнять через
Хаффмана или арифметический кодер.
Hа book1 вариант Фенвика дает 2.39 b/B, на весь CC - 2.34.
Авторский BW95 6/2 arith - 2.48 и 2.40 соответственно.
 >> LB> Все уже, выжали из переключений и эскейпов все что можно... :-)
 >> Можно и из чего-нибудь другого байты выжимать ;)
 >> Вот и в новом Arhangel'e (1.39a6) словарь английских подстановок
 >> появился...
 LB> Hо для моего challenge это не поможет - экзешник увеличивается.
Это необязательно. Впрочем, все равно, IMHO challenge - удел ppm'ов.
Вот чего современным ppm'ам не хватает, так это грамотного препроцессинга,
которым так щеголяют ушлые LZ-компрессоры.
 LB> Сдается мне, судя по последним данным, что BOA в состоянии побить
А что за "последние данные" - что-то есть свежее 0.58?
 LB> рекорд - там со всеми paper1-paper6 получается меньше, чем 777777, а
 LB> если 4 из них выкинуть и немного подпилить для pic и geo, то может
 LB> очень неплохо получиться.
Мне казалось, что в самом тормозном режиме rkive дожимает сильнее boa
(ну очень тормозном режиме :).
  Всего доброго. Vadim Yoockin
... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru (2:5020/1042.50)


 RU.COMPRESS 
 From : Vadim Yoockin                       2:5020/1042.50  14 May 99  22:55:54
 To   : Bulat Ziganshin
 Subj : Как насчет такой модели для выхода BWT?

Пpиветствую, Bulat!
14 May 99, Bulat Ziganshin писал к Vadim Yoockin:
 VY>> Можно и из чего-нибудь другого байты выжимать ;)
 VY>> Вот и в новом Arhangel'e (1.39a6) словарь английских подстановок
 VY>> появился...
 BZ>   Hа этом можно выиграть в сжатии?
А то. 5% на book1. Жаль, что language dependent - на моем тесте
не отразится ;)
  Всего доброго. Vadim Yoockin
... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru (2:5020/1042.50)


 RU.COMPRESS 
 From : Dmitry Shkarin                       2:5020/400     15 May 99 00:41:41
 To   : All
 Subj : Re: Как насчет такой модели для выхода BWT?

From: "Dmitry Shkarin" <shkarin@arstel.ru>
                         Hi, All!
>
>Мне казалось, что в самом тормозном режиме rkive дожимает сильнее boa
>(ну очень тормозном режиме :).
>
    А он работает в тормозном режиме? Или это мне такой попался, дальше -mt3
не  идет.
--- ifmail v.2.14dev3
 * Origin: COMSTAR Telecommunications (2:5020/400)
 Предыдущий блок Следующий блок Вернуться в индекс