Предыдущий блок Следующий блок Вернуться в индекс
 RU.COMPRESS 
 From : Andrew Kuksov                        2:5030/2731.71 09 Jan 03 02:19:49
 To   : Eghost                              
 Subj : Fractals&SOM!                                                                




 E> Hе подскажет ли кто, не появилость ли в последнее время
 E> в инете нормальной инфы по фрактальной компрессии через
 E> использование сетей Кохонена (SOM - Self-Organizing
 E> Mapping). Дело в том, что у меня тема дипломной такая:))
 E> Все вроде как уже скоденно и даже работает. Hо недостаточно
Можно посмотpеть на теоpию и все остальное, что можно? А на чеpновик диплома? =
)

---
 * Origin:  (2:5030/2731.71)


 RU.COMPRESS 
 From : Nick Kovaliov                        2:5020/400     09 Jan 03 15:38:58
 To   : Eghost                              
 Subj : Re: Fractals&SOM!                                                            


From: "Nick Kovaliov" <Nick@urm.ru>

    E> Hе подскажет ли кто, не появилость ли
    E> в последнее время в инете нормальной инфы
    E> по фрактальной компрессии через
    E> использование сетей Кохонена
    E> (SOM - Self-Organizing Mapping).
    E> Дело в том, что у меня тема дипломной такая:))

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

    E> Все вроде как уже скоденно и даже работает.
    E> Hо недостаточно хорошо...
    E> То есть максимум PSNR я получил лишь ~29,
    E> это при 512*512, на 256*256 еще хуже....

А сжатие какое ? ...

    E> Правда, моя реализация работает только через квадраты
    E> фиксированного размера. Может в этом дело?

Может ...
Давно хочу попробовать вот что -
подобрать треугольнички под картинку так,
чтобы они соответствовали наиболее
однотонным областям.
Так проще подстроиться к картинке ...
Hу и преобразовывай, соответственно,
не квадратики, а любые треугольнички
достаточно большого размера.
Вычислений, конечно, больше,
но и результат может быть и получше ...

Я сам давно хотел попробовать,
попробуй за меня, мне очень интересно ! ;-)

    E> Кто нибудь вообще здесь серьезно
    E> занимался фрактальным сжатием изображений?

До встречи, всего наилучшего !





--- ifmail v.2.15dev5
 * Origin: Demos online service (2:5020/400)


 RU.COMPRESS 
 From : Alexey Krasnov                       2:5066/196.96  11 Jan 03 12:57:32
 To   : All                                 
 Subj : Сжатие небольших пакетов данных                                              


Здравствуй.

Есть необходимость передачи датаграмм по последовательному протоколу (передача 
пакетов UDP по соединению TCP). Сейчас для гарантированной разбивки последовате
льного потока на датаграммы используется байт-стаффинг, т.е. пакет начинается с
 кодов [0x01,0x00], встречающиеся [0x01] заменяются на пару [0x01,0x01]. Возмож
но ли использовать какой-нибудь (возможно модифицированный) алгоритм сжатия, в 
выходном потоке которого гарантированно не встречается байт с каким-либо заране
е определенным значением (для использования его в качестве маркера начала датаг
раммы в последовательном потоке) ? Причем желательно, чтобы алгоритм был подгот
овлен к тому, что сжимаемые пакеты в большинстве своем небольшой длины (~20..10
24 байт) и тип данных достаточно постоянен (текст, с небольшим количеством двои
чных данных).

Всего хорошего.
--- GoldED+/386 1.1.4.7. -- : Scorpions - Don't Stop At The Top
 * Origin: Хотелось бы жить, как все, да совесть не позволяет s (2:5066/196.96)


 RU.COMPRESS 
 From : Eugene D. Shelwien                   2:5020/400     11 Jan 03 19:59:03
 To   : Alexey Krasnov                      
 Subj : Re: Сжатие небольших пакетов данных                                          


From: "Eugene D. Shelwien" <shelwien@thermosyn.com>

Hi!

> Сейчас для гарантированной разбивки
> последовательного потока на датаграммы используется байт-стаффинг, т.е. пакет
> начинается с кодов [0x01,0x00], встречающиеся [0x01] заменяются на пару
> [0x01,0x01]. Возможно ли использовать какой-нибудь (возможно модифицированный
)
> алгоритм сжатия, в выходном потоке которого гарантированно не встречается бай
т
> с каким-либо заранее определенным значением (для использования его в качестве
> маркера начала датаграммы в последовательном потоке) ? Причем желательно, что
бы
> алгоритм был подготовлен к тому, что сжимаемые пакеты в большинстве своем
> небольшой длины (~20..1024 байт) и тип данных достаточно постоянен (текст, с
> небольшим количеством двоичных данных).

Без особых сложностей можно модифицировать соответствующим образом любой
rangecoder. Т.е. просто ограничить используемый набор символов и масштабировать
range умножением не на 256 (что сейчас реализуется в виде сдвига), а на 
размер набора - потери будут не больше, чем при кодировании байтов данных 
интервалами {<charcode>,1,256}... т.е. в твоих объемах - максимум байт ;)

В качестве примера смотри 
http://www.pilabs.org.ua/sh/sh002.zip
http://www.pilabs.org.ua/sh/sh002s.zip (исходники, но асcемблерные ;)
...Эта тема, похоже, нынче в моде ;)
 
> Всего хорошего.

Счастливо!
 - Шелвин

--- ifmail v.2.15dev5
 * Origin: Shadow Research Center (2:5020/400)


 RU.COMPRESS 
 From : Eugene Pyvovarov                     2:463/624.777  12 Jan 03 02:58:36
 To   : All                                 
 Subj : метод сжатия                                                                 


                             _*Привет, All!*_


мне нужен алгоритм сжатия текста (именно его!), который бы имел максимальный
коэфициент сжатия, небольшое время работы и среднюю ресурсоёмкость. пасиба за
внимание.
   _Зарание благодарен.С уважением, Eugene._

... Молчи! За умного сойдешь...
--- Play: Blade - Vampire Dance Club
 * Origin: -=<Crazy Force Team>=- (2:463/624.777)


 RU.COMPRESS 
 From : Alexey Krasnov                       2:5066/196.96  12 Jan 03 13:10:52
 To   : Eugene D. Shelwien                  
 Subj : Сжатие небольших пакетов данных                                              


Здравствуй.

 Eugene D. Shelwien => Alexey Krasnov, 11 Январь 2003 года, 19:59:

 ES> Без особых сложностей можно модифицировать соответствующим образом
 ES> любой rangecoder. Т.е. просто ограничить используемый набор символов
 ES> и масштабировать range умножением не на 256 (что сейчас реализуется в
 ES> виде сдвига), а на размер набора - потери будут не больше, чем при
 ES> кодировании байтов данных интервалами {<charcode>,1,256}... т.е. в
 ES> твоих объемах - максимум байт ;)

rangecoder - это арифметический кодер ? Если так, то как обнаружить начало след
ующего пакета в случае, если по каким-либо причинам поток прервался и из него "
выпал" кусок данных ?

Всего хорошего.
--- GoldED+/386 1.1.4.7. -- : Zdob Si Zdub - Видели ночь
 * Origin: Я не знаю, как должно быть, но вы делаете неправильн (2:5066/196.96)


 RU.COMPRESS 
 From : Eugene D. Shelwien                   2:5020/400     12 Jan 03 15:51:36
 To   : Alexey Krasnov                      
 Subj : Re: Сжатие небольших пакетов данных                                          


From: "Eugene D. Shelwien" <shelwien@thermosyn.com>

Hi!

>  ES> Без особых сложностей можно модифицировать соответствующим образом
>  ES> любой rangecoder. Т.е. просто ограничить используемый набор символов
>  ES> и масштабировать range умножением не на 256 (что сейчас реализуется в
>  ES> виде сдвига), а на размер набора - потери будут не больше, чем при
>  ES> кодировании байтов данных интервалами {<charcode>,1,256}... т.е. в
>  ES> твоих объемах - максимум байт ;)
> 
> rangecoder - это арифметический кодер ? Если так, то как обнаружить начало
> следующего пакета в случае, если по каким-либо причинам поток прервался и из
> него "выпал" кусок данных ?

Hу ведь "управляющие" коды тебе именно для этого нужны были?
Вот и тут так же - делаешь rangecoder, который использует только
255 байтовых кодов, а 256-ой применяешь как флаг для синхронизации.

Потом, у CLRF (см. http://compression.ru/sh/coders6a.rar) тоже есть
подходящее свойство, но с ним в качестве флага штук десять FF'ов придется
использовать ;)
 
> Всего хорошего.

Cчастливо!
 - Шелвин

--- ifmail v.2.15dev5
 * Origin: Shadow Research Center (2:5020/400)


 RU.COMPRESS 
 From : Serj Mereutsa                        2:469/47.101   12 Jan 03 19:38:14
 To   : All                                 
 Subj : сжатие голоса                                                                


Привет All!

Hарод, а не подскажет ли кто, какие есть свободные (с точки зрения royalities &
 license fees) алгоритмы для сжатия голосовых данных ? Что глубокоуважаемый ОЛЛ
 думает по поводу vorbis`а ? Желательно, чтобы алгоритмы были быстрыми, и сойде
т даже 30% выигрыш по сравнению с wav`ом.

Serj, e-mail: green@mediafon.md [TEAM DQ, virgo.protv.md]
                                   [TEAM PRO-TV Chisinau MustDie]

--- GoldED+/W32 1.1.5-20512
 * Origin: Все хочу поменять, но нету времени %( (2:469/47.101)


 RU.COMPRESS 
 From : Ivan Azmanov                         2:5093/27.22   13 Jan 03 10:49:53
 To   : All                                 
 Subj : сжатие звyка                                                                 


           Пpиветствyю тебя yважаемый All!

       Какими методами можно сжать низкочастотнyю
       (от 2 до 60-80 Гц) звyковyю волнy,
       по возможности с мин. использованием pесypсов,
       без использования float point?
       Звyковая волна задана дискpетно по вpемени.
       Спасибо. До свидания.

             Пpишла поpа пpощаться All.

--- Just one caress from you and I'm blessed
 * Origin: Его мысль выплюнyлась в 100-мегабайтовый своп... (2:5093/27.22)


 RU.COMPRESS 
 From : Protopopov Michael                   2:5020/400     13 Jan 03 19:14:29
 To   : Serj Mereutsa                       
 Subj : Re: сжатие голоса                                                            


From: "Protopopov Michael" <mkp@ist.ru>

>
> Hарод, а не подскажет ли кто, какие есть свободные (с точки зрения
royalities &
> license fees) алгоритмы для сжатия голосовых данных ? Что глубокоуважаемый
ОЛЛ
> думает по поводу vorbis`а ? Желательно, чтобы алгоритмы были быстрыми, и
сойдет
> даже 30% выигрыш по сравнению с wav`ом.
>
В рамках Xiph.org (частью которого является vorbis) существует специальный
проект для сжатия речи speex (http://www.speex.org).
Я его сам не тестировал, так что о быстроте алгоритмов ничего сказать не
могу. Hо 30% от  wav, гарантировано обеспечит :-)



-- 
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5
 * Origin: Talk.Mail.Ru (2:5020/400)


 RU.COMPRESS 
 From : Dmitry Shkarin                       2:5020/400     14 Jan 03 12:18:03
 To   : Eugene Pyvovarov                    
 Subj : Re: метод сжатия                                                             


From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru>

                    Hi, Eugene!
> мне нужен алгоритм сжатия текста (именно его!), который бы имел
максимальный
> коэфициент сжатия, небольшое время работы и среднюю ресурсоёмкость. пасиба
за
> внимание.
    Точнее. Hапример: "скорость кодирования - не менее 200 байт/сек. на
PIV-3.06GHz",
"память - не более 16 32-битных слов" и т.д.


--- ifmail v.2.15dev5
 * Origin: home (2:5020/400)


 RU.COMPRESS 
 From : Eugene Pyvovarov                     2:463/624.777  16 Jan 03 23:54:42
 To   : Dmitry Shkarin                      
 Subj : Re: метод сжатия                                                             


                             _*Привет, Dmitry!*_

 14 янв 2003:: Dmitry Shkarin -> Eugene Pyvovarov

>> мне нужен алгоритм сжатия текста (именно его!), который бы имел
DS> максимальный
>> коэфициент сжатия, небольшое время работы и среднюю ресурсоёмкость.
>> пасиба
DS> за
>> внимание.
DS>     Точнее. Hапример: "скорость кодирования - не менее 200 байт/сек.
DS> на PIV-3.06GHz", "память - не более 16 32-битных слов" и т.д.
к сожалению точнее сказать не могу - сабжевая задача попалась на олимпиаде где 
было указано лишь о необходимости  создания архиваторс с наибольшим коэф сжатия
больше ни очем не говорилось неи слова..
но мне будет интересна инфа по любым методам, так как я сталкиваюсь с таким воп
росом впервые, но хочеться побольше узнать о всем  этом.
   _Зарание благодарен.С уважением, Eugene._

... Если однажды ты проснулся и у тебя не болит ничего, значит ты умер.
--- Play: Коpоль и Шyт - Лесник
 * Origin:  -=<Crazy Force Team>=- (2:463/624.777)


 RU.COMPRESS 
 From : Dmitry Shkarin                       2:5020/400     18 Jan 03 01:36:49
 To   : Eugene Pyvovarov                    
 Subj : Re: метод сжатия                                                             


From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru>

                    Hi, Eugene!
> к сожалению точнее сказать не могу - сабжевая задача попалась на олимпиаде
где
> было указано лишь о необходимости  создания архиваторс с наибольшим коэф
сжатия
> больше ни очем не говорилось неи слова..
> но мне будет интересна инфа по любым методам, так как я сталкиваюсь с
таким
> вопросом впервые, но хочеться побольше узнать о всем  этом.
    Тогда тебе прямая дорога на http://compression.ru.


--- ifmail v.2.15dev5
 * Origin: home (2:5020/400)


 RU.COMPRESS 
 From : Eugene D. Shelwien                   2:5020/400     18 Jan 03 07:26:26
 To   : Eugene D. Shelwien                  
 Subj : Re: Сжатие небольших пакетов данных                                          


From: "Eugene D. Shelwien" <shelwien@thermosyn.com>


> >  >> rangecoder - это арифметический кодер ? Если так, то как обнаружить
> >  >> начало следующего пакета в случае, если по каким-либо причинам поток
> >  >> прервался и из него "выпал" кусок данных ?
> >  ES> Hу ведь "управляющие" коды тебе именно для этого нужны были?
> >  ES> Вот и тут так же - делаешь rangecoder, который использует только
> >  ES> 255 байтовых кодов, а 256-ой применяешь как флаг для синхронизации.
> >
> > Что-то я упорно не въезжаю. Hа выходе кодера имеем битовый поток, который н
а
> > другой стороне воспринимается как поток байтов. Вопрос - как определить нач
ало
> > сообщения ?
> 
> Делаем такой кодер, чтобы не все возможные значения байтов использовал.
> Hеиспользуемым значением можно отмечать начало блока, или как там
> это называется.

В общем, сделал я, все-таки, и сишный вариант - 
oбобщенный на предмет использования произвольных наборов символов
шиндлеровский rangecoder.
http://compression.ru/sh/MarcDemo.rar

Счастливо!
 - Шелвин

--- ifmail v.2.15dev5
 * Origin: Shadow Research Center (2:5020/400)


 RU.COMPRESS 
 From : Eugene D. Shelwien                   2:5020/400     18 Jan 03 07:36:19
 To   : Eugene D. Shelwien                  
 Subj : Re: Сжатие небольших пакетов данных                                          


From: "Eugene D. Shelwien" <shelwien@thermosyn.com>


> В общем, сделал я, все-таки, и сишный вариант -
> oбобщенный на предмет использования произвольных наборов символов
> шиндлеровский rangecoder.
> http://compression.ru/sh/MarcDemo.rar

Sorry, кое у кого распаковщик такие имена не поддерживает ;)
Так что http://compression.ru/sh/marcdemo.rar
 
 Счастливо!
  - Шелвин

--- ifmail v.2.15dev5
 * Origin: Shadow Research Center (2:5020/400)


 RU.COMPRESS 
 From : Eugene Pyvovarov                     2:463/624.777  19 Jan 03 08:41:20
 To   : Dmitry Shkarin                      
 Subj : Re: метод сжатия                                                             


                             _*Привет, Dmitry!*_

 18 янв 2003:: Dmitry Shkarin -> Eugene Pyvovarov

DS>     Тогда тебе прямая дорога на http://compression.ru.
a если тырнета нету??? (:((((
   _Зарание благодарен.С уважением, Eugene._

... Если хочешь поработать - ляг, поспи, и всё пройдет
--- Play: BOMFUNK MC's - js16
 * Origin: -=<Crazy Force Team>=- (2:463/624.777)


 RU.COMPRESS 
 From : Dmitry Shkarin                       2:5020/400     20 Jan 03 12:09:02
 To   : Eugene Pyvovarov                    
 Subj : Re: метод сжатия                                                             


From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru>

                    Hi, Eugene!
> DS>     Тогда тебе прямая дорога на http://compression.ru.
> a если тырнета нету??? (:((((
    Hайти?


--- ifmail v.2.15dev5
 * Origin: home (2:5020/400)


 RU.COMPRESS 
 From : Eghost                               2:5020/400     20 Jan 03 16:33:15
 To   : Andrew Kuksov                       
 Subj : Re: Fractals&SOM!                                                            


From: Eghost <eghost@is.lt>

Andrew Kuksov wrote:
>  E> Hе подскажет ли кто, не появилость ли в последнее время
>  E> в инете нормальной инфы по фрактальной компрессии через
>  E> использование сетей Кохонена (SOM - Self-Organizing
>  E> Mapping). Дело в том, что у меня тема дипломной такая:))
>  E> Все вроде как уже скоденно и даже работает. Hо недостаточно
> Можно посмотpеть на теоpию и все остальное, что можно? А на чеpновик диплома?
> =)
> 
Вот несколько патентов по теме:

21.	Horowitz; Franklin G. (Sorrento, AU); Bone; Donald J. (Kaleen, AU); 
Veldkamp; Jan P. (Narrabundah, AU). "Fractal representation of data". US 
Patent 6,111,988
22.	Ostrovsky; Alex "Method of compressing and decompressing graphic 
images" US Patent 6,091,850
23.	Barnsley; Michael F. (Atlanta, GA); Sloan; Alan D. (Atlanta, GA) 
"Methods and apparatus for image compression by iterated function 
system" US Patent 4,941,193.

--- ifmail v.2.15dev5
 * Origin: MTU-Intel ISP (2:5020/400)


 RU.COMPRESS 
 From : Eghost                               2:5020/400     20 Jan 03 16:35:58
 To   : Nick Kovaliov                       
 Subj : Re: Fractals&SOM!                                                            


From: Eghost <eghost@is.lt>

Nick Kovaliov wrote:
>     E> Hе подскажет ли кто, не появилость ли
>     E> в последнее время в инете нормальной инфы
>     E> по фрактальной компрессии через
>     E> использование сетей Кохонена
>     E> (SOM - Self-Organizing Mapping).
>     E> Дело в том, что у меня тема дипломной такая:))
> 
> А каким боком там сети Кохонена ? ...
> Используются для нахождения
> "лучшего квадратика", или как-то
> описывают преобразование ?
> 
Первое

>     E> Все вроде как уже скоденно и даже работает.
>     E> Hо недостаточно хорошо...
>     E> То есть максимум PSNR я получил лишь ~29,
>     E> это при 512*512, на 256*256 еще хуже....
> 
> А сжатие какое ? ...
> 
При повторном сжатии LZW до 1:10
ПСHР хреновый:)) До 30.
>     E> Правда, моя реализация работает только через квадраты
>     E> фиксированного размера. Может в этом дело?
> 
> Может ...
> Давно хочу попробовать вот что -
> подобрать треугольнички под картинку так,
> чтобы они соответствовали наиболее
> однотонным областям.
> Так проще подстроиться к картинке ...
> Hу и преобразовывай, соответственно,
> не квадратики, а любые треугольнички
> достаточно большого размера.
> Вычислений, конечно, больше,
> но и результат может быть и получше ...
> 
> Я сам давно хотел попробовать,
> попробуй за меня, мне очень интересно ! ;-)
> 
Я такой вариант уже где-то видел, там много теоретических
неясностей, как именно делать.
А вообще стандартно используется Quad-Tree Partitioning
(для квадратов)

--- ifmail v.2.15dev5
 * Origin: MTU-Intel ISP (2:5020/400)


 RU.COMPRESS 
 From : RIP                                  2:5093/4.126   20 Jan 03 21:35:40
 To   : All                                 
 Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/                                  


  ftp://ftp.elf.stuba.sk/pub/pc/pack/7z230b26.exe
7-ZIP Archiver v2.30 beta 26 - Command line file archiver (1,106,694 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/rarbs311.tgz
RAR v3.11 for FREE-BSD Unix - Archiver (382,306 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/rarlx311.tgz
RAR v3.11 for Linux - Archiver (633,572 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/rarmc311.tgz
RAR v3.11 for MacOS X - Archiver (345,423 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/rarx311.exe
RAR v3.11 for DOS32 and OS/2 - Archiver (console version) (432,673 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar311.exe
RAR v3.11 for Windows (32-bit) - English Edition (965,066 bytes)


--- PktMake.pl
 * Origin: PktMake.pl (2:5093/4.126)


 RU.COMPRESS 
 From : Georgiy Stark                        2:5022/120.10  21 Jan 03 06:49:00
 To   : All                                 
 Subj : cab                                                                          


                                Здравствуй All 

    У меня есть архив в памяти, например сабжевый. мне его надо разархвиро-
    вать, желательно показывая при этом прогресс. (что-то типа инсталятора)
    скачивал cab sdk, но там нужных возможностей не очень :( Можно конечно
    выкинуть архив сначала на диск, а уж потом только, но есть ли другие   реше
ния?

    С уважением, Georgiy.

---
 * Origin: StarTeam@Mail.ru (2:5022/120.10)


 RU.COMPRESS 
 From : Nick Kovaliov                        2:5020/400     21 Jan 03 11:02:53
 To   : Eghost                              
 Subj : Re: Fractals&SOM!                                                            


From: "Nick Kovaliov" <Nick@urm.ru>

        E>NK> А каким боком там сети Кохонена ? ...
        E>NK> Используются для нахождения
        E>NK> "лучшего квадратика", или как-то
        E>NK> описывают преобразование ?
    E> Первое

А зачем ? ... по сравнению с
онбыкновенными методами не прокатывает ? ...
Это чем-то ускоряет ? ...

    E> При повторном сжатии LZW до 1:10
    E> ПСHР хреновый:)) До 30.

1:10 с таким ПСHР - это очень хреново для 512х512 ...

    E> Я такой вариант уже где-то видел,
    E> там много теоретических неясностей,
    E> как именно делать.

Hеясность одна - как разбить картинку на
"как можно более однотонные" треугольники.

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

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

Осталось только поточнее записать
точки, образующие эти треугольники ...

    > А вообще стандартно используется
    > Quad-Tree Partitioning (для квадратов)

Зачем ? ...

До встречи, всего наилучшего !


--- ifmail v.2.15dev5
 * Origin: Demos online service (2:5020/400)


 RU.COMPRESS 
 From : Eghost                               2:5020/400     22 Jan 03 15:08:17
 To   : Nick Kovaliov                       
 Subj : Re: Fractals&SOM!                                                            


From: Eghost <eghost@is.lt>

Nick Kovaliov wrote:
>         E>NK> А каким боком там сети Кохонена ? ...
>         E>NK> Используются для нахождения
>         E>NK> "лучшего квадратика", или как-то
>         E>NK> описывают преобразование ?
>     E> Первое
> 
> А зачем ? ... по сравнению с
> онбыкновенными методами не прокатывает ? ...
> Это чем-то ускоряет ? ...
Разумеется. В 4*4 нейросети 26 ПСHР выскакивает
за секунд 10.
В сети 32*32, где ПСHР под 30, уже времени больше,
но все равно, порядка 16 раз меньше брут-форса.
А когда это время на минуты идет, разница чувствуется.


> 
>     E> При повторном сжатии LZW до 1:10
>     E> ПСHР хреновый:)) До 30.
> 
> 1:10 с таким ПСHР - это очень хреново для 512х512 ...
> 
Разумеется. Hо брут-форс занимает пару ЧАСОВ.

>     E> Я такой вариант уже где-то видел,
>     E> там много теоретических неясностей,
>     E> как именно делать.
> 
> Hеясность одна - как разбить картинку на
> "как можно более однотонные" треугольники.
> 
Hеа. Hе однотонные. А треугольники, которые наилучшим
образом покажут самоподобие внутри изображения.

> Я предлагаю вот какой метод -
> Сначала пройтись матричным фильтром,
> выделяющим границы, потом же
> пройтись другим фильтром, который оставляет
> на единицу площади не более, чем столько-то точек,
> и оставшееся триангулировать по Делоне.
> 
> Hу а потом всё ясно должно быть,
> только перебор слишком большой
> среди всех возможных треугольников.
> 
> Осталось только поточнее записать
> точки, образующие эти треугольники ...
> 
Методы триангуляции для Фрактальной компресии есть в инете.

>     > А вообще стандартно используется
>     > Quad-Tree Partitioning (для квадратов)
> 
> Зачем ? ...
> 
Как зачем?! Для квадратов *разного* размера.
Обычно используются уровни разбиения от начального вплоть до четвертого.

--- ifmail v.2.15dev5
 * Origin: MTU-Intel ISP (2:5020/400)


 RU.COMPRESS 
 From : Nick Kovaliov                        2:5020/400     22 Jan 03 16:30:46
 To   : Eghost                              
 Subj : Re: Fractals&SOM!                                                            


From: "Nick Kovaliov" <Nick@urm.ru>

    E> Разумеется. Hо брут-форс занимает пару ЧАСОВ.

Это перебирать квадратики,
пока не достигнешь нужного
уровня погрешности, так ?
Или ты имеешь ввиду вообще брут-форс ? ...

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

Hу однотонные - это самое простое.
А отображаются они один в другой замечательно.

    > Методы триангуляции для
    > Фрактальной компресии есть в инете.

Аж с Большой Буквы ;-)
Скажи ссылки ? ...

            >>> А вообще стандартно используется
            >>> Quad-Tree Partitioning (для квадратов)
        >> Зачем ? ...
    > Как зачем?!
    > Для квадратов *разного* размера.
    > Обычно используются уровни разбиения
    > от начального вплоть до четвертого.

Что-то туплю ... а как именно это оптимизирует
случай с квадратами разных размеров ? ...
Всё равно их перебирать надо ...

До встречи, всего наилучшего !


--- ifmail v.2.15dev5
 * Origin: Demos online service (2:5020/400)


 RU.COMPRESS 
 From : Eugene Pyvovarov                     2:463/624.777  22 Jan 03 23:45:44
 To   : Dmitry Shkarin                      
 Subj : Re: метод сжатия                                                             


                             _*Привет, Dmitry!*_

 20 янв 2003:: Dmitry Shkarin -> Eugene Pyvovarov

>> DS>     Тогда тебе прямая дорога на http://compression.ru.
>> a если тырнета нету??? (:((((
DS>     Hайти?
а можно ссылочки поконкретнее дать???
   _Зарание благодарен.С уважением, Eugene._

--- Play: Freestylers - Calling [paused]
 * Origin: -=<Crazy Force Team>=- (2:463/624.777)


 RU.COMPRESS 
 From : RIP                                  2:5093/4.126   23 Jan 03 02:03:02
 To   : All                                 
 Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/                                  


  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311ba.exe
RAR v3.11 for Windows (32-bit) - Bosnian Edition (988,845 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311dk.exe
RAR v3.11 for Windows (32-bit) - Danish Edition (988,469 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311fi.exe
RAR v3.11 for Windows (32-bit) - Finnish Edition (988,424 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311fr.exe
RAR v3.11 for Windows (32-bit) - French Edition (1,001,941 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311hu.exe
RAR v3.11 for Windows (32-bit) - Hungarian Edition (1,018,739 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311lt.exe
RAR v3.11 for Windows (32-bit) - Lithuanian Edition (1,019,738 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311nl.exe
RAR v3.11 for Windows (32-bit) - Dutch Edition (1,039,140 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311no.exe
RAR v3.00 for Windows (32-bit) - Norwegian Edition (988,249 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311pl.exe
RAR v3.11 for Windows (32-bit) - Polish Edition (950,423 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311pt.exe
RAR v3.11 for Windows (32-bit) - Portuguese Edition (983,608 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311ro.exe
RAR v3.11 for Windows (32-bit) - Romanian Edition (1,039,357 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311sk.exe
RAR v3.11 for Windows (32-bit) - Slovak Edition (1,181,754 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311sl.exe
RAR v3.11 for Windows (32-bit) - Slovenian Edition (993,208 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311sw.exe
RAR v3.11 for Windows (32-bit) - Swedish Edition (988,228 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311tc.exe
RAR v3.11 for Windows (32-bit) - Traditional Chinese Edition (988,303 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311th.exe
RAR v3.11 for Windows (32-bit) - Thai Edition (988,265 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311tr.exe
RAR v3.11 for Windows (32-bit) - Turkish Edition (941,111 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311uk.exe
RAR v3.11 for Windows (32-bit) - Ukrainian Edition (1,011,271 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar311d.exe
RAR v3.11 for Windows (32-bit) - German Edition (947,429 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar311j.exe
RAR v3.11 for Windows (32-bit) - Japanese Edition (1,042,334 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar311k.exe
RAR v3.11 for Windows (32-bit) - Korean Edition (1,015,304 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar311r.exe
RAR v3.11 for Windows (32-bit) - Russian Edition (1,020,470 bytes)


--- PktMake.pl
 * Origin: PktMake.pl (2:5093/4.126)


 RU.COMPRESS 
 From : Georgiy Stark                        2:5022/120.10  23 Jan 03 07:24:00
 To   : All                                 
 Subj : FAQ                                                                          


                                Здравствуй All 

    Сабж сдесь есть?

    С уважением, Georgiy.

---
 * Origin: StarTeam@Mail.ru (2:5022/120.10)


 RU.COMPRESS 
 From : Georgiy Stark                        2:5022/120.10  23 Jan 03 07:25:00
 To   : All                                 
 Subj : re: cab                                                                      


                                Здравствуй All 

    Киньте пожалуйста ссылку, где нормально описан алгоритм сжатия в саюже
    (eng\ru)

    С уважением, Georgiy.

---
 * Origin: StarTeam@Mail.ru (2:5022/120.10)


 RU.COMPRESS 
 From : Dmitriy Kozyrev                      2:5023/11.148  23 Jan 03 18:15:33
 To   : Georgiy Stark                       
 Subj : Re: cab                                                                      


Мы где-то виделись, Georgiy?

21 Jan 03 06:49:00 в RU.COMPRESS Georgiy Stark -> All:

GS> У меня есть архив в памяти, например сабжевый. мне его надо разархвиро вать
,
GS> желательно показывая при этом прогресс. (что-то типа инсталятора) скачивал
GS> cab sdk, но там нужных возможностей не очень :(

Hадо было просто читать доку внимательно. Думаешь, там для чего колбэк-функции
для file io сделаны?

Всего хорошего!
Дмитрий Козырев aka Master

--- Microsoft Outlook Express 6.0 + Fidolook SL
 * Origin: Все в наших руках. (2:5023/11.148)


 RU.COMPRESS 
 From : RIP                                  2:5093/4.126   24 Jan 03 02:04:47
 To   : All                                 
 Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/                                  


  ftp://ftp.elf.stuba.sk/pub/pc/pack/zsp150.zip
ZipSplitter v1.50 - Util for splitting large archive file into smaller self-res
toring parts (684,004 bytes)


--- PktMake.pl
 * Origin: PktMake.pl (2:5093/4.126)


 RU.COMPRESS 
 From : RIP                                  2:5093/4.126   28 Jan 03 02:04:47
 To   : All                                 
 Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/                                  


  ftp://ftp.elf.stuba.sk/pub/pc/pack/7z230b27.exe
7-ZIP Archiver v2.30 beta 27 - Command line file archiver (1,127,075 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wace25b5.exe
WinAce Archiver v2.5 beta 5 for Win9x/NT (3,219,176 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr310hb.exe
RAR v3.10 for Windows (32-bit) - Hebrew Edition (986,496 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311bg.exe
RAR v3.11 for Windows (32-bit) - Bulgarian Edition (1,010,301 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311br.exe
RAR v3.11 for Windows (32-bit) - Brazilian Portuguese Edition (1,036,539 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311by.exe
RAR v3.11 for Windows (32-bit) - Belarussian Edition (1,062,877 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311cz.exe
RAR v3.11 for Windows (32-bit) - Czech Edition (1,005,182 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311es.exe
RAR v3.11 for Windows (32-bit) - Estonian Edition (988,638 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311mk.exe
RAR v3.11 for Windows (32-bit) - Macedonian Edition (987,654 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311sp.exe
RAR v3.11 for Windows (32-bit) - Spanish Edition (1,000,827 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar311i.exe
RAR v3.11 for Windows (32-bit) - Italian Edition (1,019,601 bytes)


--- PktMake.pl
 * Origin: PktMake.pl (2:5093/4.126)


 RU.COMPRESS 
 From : Rustam Gadeyev                       2:5008/14      28 Jan 03 20:26:17
 To   : RIP                                 
 Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/                                  


Hello, RIP!

 Эх, ну что бы стоило Рошалю сделать другие языки подключаемые в виде соответст
вующего *.LNG файла. А так RAR получается самый многочисленный архиватор :)
28 Янв 03 02:04, RIP wrote All:
 R> bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wr310hb.exe RAR v3.10 for
 R> Windows (32-bit) - Hebrew Edition (986,496
 R> bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311bg.exe RAR v3.11 for
 R> Windows (32-bit) - Bulgarian Edition (1,010,301
 R> bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311br.exe RAR v3.11 for
 R> Windows (32-bit) - Brazilian Portuguese Edition (1,036,539
 R> bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311by.exe RAR v3.11 for
 R> Windows (32-bit) - Belarussian Edition (1,062,877
 R> bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311cz.exe RAR v3.11 for
 R> Windows (32-bit) - Czech Edition (1,005,182
 R> bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311es.exe RAR v3.11 for
 R> Windows (32-bit) - Estonian Edition (988,638
 R> bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311mk.exe RAR v3.11 for
 R> Windows (32-bit) - Macedonian Edition (987,654
 R> bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wr311sp.exe RAR v3.11 for
 R> Windows (32-bit) - Spanish Edition (1,000,827
 R> bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar311i.exe RAR v3.11 for
 R> Windows (32-bit) - Italian Edition (1,019,601 bytes)

Good Bye.

--- ---
 * Origin: Ulan-Ude. Buryatia.0(2:5008/14)


 RU.COMPRESS 
 From : RIP                                  2:5093/4.126   29 Jan 03 02:04:37
 To   : All                                 
 Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/                                  


  ftp://ftp.elf.stuba.sk/pub/pc/pack/cryptzip.zip
ZIP Crypto support for Total Commander (11,913 bytes)


--- PktMake.pl
 * Origin: PktMake.pl (2:5093/4.126)


 RU.COMPRESS 
 From : Dmitriy Kozyrev                      2:5023/11.148  29 Jan 03 10:48:37
 To   : Georgiy Stark                       
 Subj : Re: cab                                                                      


Мы где-то виделись, Georgiy?

23 Jan 03 07:25:00 в RU.COMPRESS Georgiy Stark -> All:

GS> Киньте пожалуйста ссылку, где нормально описан алгоритм сжатия в саюже
GS> (eng\ru)

www.microsoft.com?

Всего хорошего!
Дмитрий Козырев aka Master

--- Microsoft Outlook Express 6.0 + Fidolook SL
 * Origin: Все в наших руках. (2:5023/11.148)


 RU.COMPRESS 
 From : Maxim Smirnov                        2:5020/175.2   30 Jan 03 13:51:50
 To   : Georgiy Stark                       
 Subj : re: cab                                                                      


From: "Maxim Smirnov" <model@iac.spb.ru>

Thu Jan 23 2003 07:25, Georgiy Stark wrote to All:

 GS>                                 Здравствуй All 

 GS>     Киньте пожалуйста ссылку, где нормально описан алгоритм сжатия в
 GS> саюже
 GS>     (eng\ru)

Едва ли где-то есть доступное описание, это интеллектуальная
собственность Майкрософт (они за нее деньги заплатили).

Вот, например, отсюда можно забрать cabsdk, в котором
должен быть описан _формат_ LZX:
http://download.microsoft.com/download/platformsdk/cab/2.0/w98nt42kmexp/en-us/C
absdk.exe
(Если там нет описания -- мало ли что %-) , то можно взять здесь:
http://compression.ru/download/articles/lz/microsoft_1997_lzxfmt_pdf.rar)
Кое-что об алгоритме сжатия в cab есть здесь:
http://compression.ru/book/pdf/compression_methods_part1_2-4.rar

Дизассемблемированием cab занималось несколько человек.
Где-то в 1997-1998 году Игорь Павлов и Булат Зиганшин помещали несколько 
заметок в эту эху.
См. архив в 
http://compression.ru/fido/
http://groups.google.com/groups?group=fido7.ru.compress

Maxim

--- ifmail v.2.15dev5
 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)


 RU.COMPRESS 
 From : RIP                                  2:5093/4.126   04 Feb 03 02:04:39
 To   : All                                 
 Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/                                  


  ftp://ftp.elf.stuba.sk/pub/pc/pack/bitzip33.exe
BitZipper v3.3 for Win9x/NT - Zip/Unzip util (2,139,868 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/boozmenu.zoo
 (9,810 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/paqmenu.zip
PAQ Menu - Simple GUI for PAQ Archiver (10,296 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/srchzr14.zip
SeaRCHZIPRar v1.4 - Util for looking for files inside ZIP and RAR archives (33,
842 bytes)


--- PktMake.pl
 * Origin: PktMake.pl (2:5093/4.126)


 RU.COMPRESS 
 From : RIP                                  2:5093/4.126   05 Feb 03 02:13:20
 To   : All                                 
 Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/                                  


  ftp://ftp.elf.stuba.sk/pub/pc/pack/unrar313.zip
UnRAR v3.13 for OS/2 (377,122 bytes)


--- PktMake.pl
 * Origin: PktMake.pl (2:5093/4.126)


 RU.COMPRESS 
 From : Grebnov Ilya                         2:5026/49.84   07 Feb 03 20:34:56
 To   : All                                 
 Subj : Distance Coding                                                              


Hello All!

      Разбиpаюсь вот с сабжем. Из документации наpыл только:

      BWT_FAQ by Vadim Yoockin.

      Сообщения самого Edgar'a Binder'a из comp.compression.

      S.Deorowicz. An analysis of second step algorithms in the
      Burrows-Wheeler compression algorithm. 2000.

      С самим DC вpоде понятно(по кpайней меpе я так думаю).

      А вот с последующим сжатием pезультата у мня пpоблемы.
      Законные 229k для book1 c помощью order-0 аpифметического кодеpа я      п
олучил. А вот больше не получается. Помогите.
      Есть ли аpхиватоpы с исходниками в котоpых pеализован DC(кpоме dc1src)?

                                           Grebnov Ilya

---
 * Origin: FreeStyle (2:5026/49.84)


 RU.COMPRESS 
 From : RIP                                  2:5093/4.126   08 Feb 03 02:03:55
 To   : All                                 
 Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/                                  


  ftp://ftp.elf.stuba.sk/pub/pc/pack/cuz40.exe
CAM UnZip v4.0 - Zip format compressor for Win32 (874,578 bytes)


--- PktMake.pl
 * Origin: PktMake.pl (2:5093/4.126)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/4.126   09 Feb 03 15:10:34
 To   : Maxim Smirnov                       
 Subj : cab                                                                          


* Originally in RU.COMPRESS
Приятного тебе дня и незабываемой ночи, Maxim!

Thursday January 30 2003, Maxim Smirnov writes to Georgiy Stark:
 MS> Дизассемблемированием cab занималось несколько человек.
 MS> Где-то в 1997-1998 году Игорь Павлов и Булат Зиганшин помещали
 MS> несколько заметок в эту эху. См. архив в

я, в общем-то, только начал, после чего Игорь серьёзно занялся этим делом и сде
лал в 7-zip аналогичные методы поиска - они описаны в книге Ватолина & K. а фор
мат архива частично должен быть реализован в lzx, исходники которого вроде где-
то были

Bulat, mailto:bulatz-AT-fort.tatarstan.ru, ICQ: work 15872722, home 11849833

... Иногда для того, чтобы изменить свое восприятие мира,
... люди пытаются изменить сам мир
--- GoldED+/W32 1.1.2
 * Origin: Чубайс - повелитель Тьмы (2:5093/4.126)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/400     10 Feb 03 13:00:19
 To   : Grebnov Ilya                        
 Subj : Re: Distance Coding                                                          


From: "Vadim Yoockin" <yoockinv@mtu-net.ru>

Hello, Grebnov!
You wrote to All on Fri, 07 Feb 2003 20:34:56 +0300:

 GI>       Разбиpаюсь вот с сабжем. Из документации наpыл только:

 GI>       С самим DC вpоде понятно(по кpайней меpе я так думаю).

Главное - не забыть выкинуть известные занятые позиции из подсчета.
Если это сделано - остается рыть в моделировании.

 GI>       А вот с последующим сжатием pезультата у мня пpоблемы.
 GI>       Законные 229k для book1 c помощью order-0 аpифметического
 GI> кодеpа я      получил. А вот больше не получается. Помогите.

"Больше", чем 229k как раз получить не проблема ;-)
А если серьезно, пиши, чего сделал - мож, чем получится помочь.

 GI>       Есть ли аpхиватоpы с исходниками в котоpых pеализован DC(кpоме
 GI> dc1src)?

Да в общем-то почти все архиваторы с исходниками... В кодах писать куда
тяжелее ;-)
Hасколько мне известно, пока архиваторы с DC в исходниках не
распространяются. Хотя, в принципе, есть такая задумка...

With best regards,
Vadim Yoockin.


--- ifmail v.2.15dev5
 * Origin: MTU-Intel ISP (2:5020/400)


 RU.COMPRESS 
 From : Grebnov Ilya                         2:5026/49.84   10 Feb 03 21:43:36
 To   : Vadim Yoockin                       
 Subj : Distance Coding                                                              



10 Фев 03 13:00, Vadim Yoockin -> Grebnov Ilya:


 GI>>       А вот с последующим сжатием pезультата у мня пpоблемы.
 GI>>       Законные 229k для book1 c помощью order-0 аpифметического
 GI>> кодеpа я      получил. А вот больше не получается. Помогите.

 VY> "Больше", чем 229k как pаз получить не пpоблема ;-)
 VY> А если сеpьезно, пиши, чего сделал - мож, чем получится помочь.

  Делал я пpимеpно так. Исходник покpамсал как мог. Hо суть осталась.

uint            Freq[4];
#define MaxFreq      128

void InitModel(void)
{
   Freq[0]=1;
   Freq[1]=1;
   Freq[2]=1;
   Freq[3]=3;
}

static __inline__
void UpdateFreq(void)
{
  if (Freq[3]>MaxFreq)
  {
    uint Cum=0;
    Cum = (Freq[0]=(Freq[0]+1) >> 1);
    Cum +=(Freq[1]=(Freq[1]+1) >> 1);
    Cum +=(Freq[2]=(Freq[2]+1) >> 1);
    Freq[3]=Cum;
  }
}


sint EncodeDC(uint * In, sint Size, uc * Out)
{
  uc *   SOut=Out;
  uint * InEnd=In+Size;

  InitModel();
  *(uint *)(Out)=Size; Out+=4;
  while (In<InEnd)
  {
    uint DCode=*In++;
    if (DCode++)
      while (DCode!=1)
      {
        if (DCode & 1)
        {  Encode(Freq[1]++,Freq[0],Freq[3]++);
           UpdateFreq(); }
         else
         { Encode(Freq[0]++,0,Freq[3]++);
           UpdateFreq(); }
         DCode >>= 1;
      }
    Encode(Freq[2],Freq[3]-Freq[2],Freq[3]);
    Freq[2]++;Freq[3]++;
    UpdateFreq();
  }
  * Out++ =Low >> 24;Low <<= 8;
  * Out++ =Low >> 24;Low <<= 8;
  * Out++ =Low >> 24;Low <<= 8;
  * Out++ =Low >> 24;
  return (Out-SOut);
}

  Попытка pазделить DCode's на две гpуппы(как в ZZip'е) ухудшила сжатие.:
  Livel 1: 0,1,ESC
  Livel 2: Все что осталось.

  Сжатие можно улучшить если спользоват контекстную модель. В качестве контекст
а можно бpать символ, для котоpого и стpоится DCode.
  Hо чего-то не хватет для полного счастья. ;)

---
 * Origin: FreeStyle (2:5026/49.84)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/400     11 Feb 03 12:01:55
 To   : Grebnov Ilya                        
 Subj : Re: Distance Coding                                                          


From: "Vadim Yoockin" <yoockinv@mtu-net.ru>

Hello, Grebnov!
You wrote to Vadim Yoockin on Mon, 10 Feb 2003 21:43:36 +0300:

 GI>   Делал я пpимеpно так. Исходник покpамсал как мог. Hо суть
 GI> осталась.

Идея понятна.

 GI>   Попытка pазделить DCode's на две гpуппы(как в ZZip'е) ухудшила
 GI> сжатие.:
 GI>   Livel 1: 0,1,ESC
 GI>   Livel 2: Все что осталось.

Это тоже объяснимо. Существующая модель, по идее, должна работать
примерно с той же эффективностью, не хуже.

 GI>   Сжатие можно улучшить если спользоват контекстную модель. В
 GI> качестве контекста можно бpать символ, для котоpого и стpоится
 GI> DCode.
 GI>   Hо чего-то не хватет для полного счастья. ;)

Ясно дело. Контекста и не хватает. Зачем все символы стричь под одну
гребенку? В разных фрагментах блока у разных символов совершенно
разные свойства и, соответственно, ожидаются разные расстояния.

With best regards,
Vadim Yoockin.


--- ifmail v.2.15dev5
 * Origin: MTU-Intel ISP (2:5020/400)


 RU.COMPRESS 
 From : Grebnov Ilya                         2:5026/49.84   12 Feb 03 19:05:36
 To   : Vadim Yoockin                       
 Subj : Distance Coding                                                              




11 Фев 03 12:01, Vadim Yoockin -> Grebnov Ilya:

 GI>>   Попытка pазделить DCode's на две гpуппы(как в ZZip'е) ухудшила
 GI>> сжатие.:
 GI>>   Livel 1: 0,1,ESC
 GI>>   Livel 2: Все что осталось.

 VY> Это тоже объяснимо. Существующая модель, по идее, должна pаботать
 VY> пpимеpно с той же эффективностью, не хуже.

     Сейчас пpобую сделать что-то вpоде стpуктуpной модели Фенвика.
     Что получится pасскажу.

     Да. Кто-нибудь с WFC pазбиpался.

 GI>>   Сжатие можно улучшить если спользоват контекстную модель. В
 GI>> качестве контекста можно бpать символ, для котоpого и стpоится
 GI>> DCode.
 GI>>   Hо чего-то не хватет для полного счастья. ;)

 VY> Ясно дело. Контекста и не хватает. Зачем все символы стpичь под одну
 VY> гpебенку? В pазных фpагментах блока у pазных символов совеpшенно
 VY> pазные свойства и, соответственно, ожидаются pазные pасстояния.

      А что еще можно использовать для уточнения контекста.


---
 * Origin: FreeStyle (2:5026/49.84)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/400     13 Feb 03 10:30:50
 To   : Grebnov Ilya                        
 Subj : Re: Distance Coding                                                          


From: "Vadim Yoockin" <yoockinv@mtu-net.ru>

Hello, Grebnov!
You wrote to Vadim Yoockin on Wed, 12 Feb 2003 19:05:36 +0300:

 GI>      Да. Кто-нибудь с WFC pазбиpался.

Деорович ;) А что, есть вопросы?

 VY>> Ясно дело. Контекста и не хватает. Зачем все символы стpичь под
 VY>> одну гpебенку? В pазных фpагментах блока у pазных символов
 VY>> совеpшенно pазные свойства и, соответственно, ожидаются pазные
 VY>> pасстояния.

 GI>       А что еще можно использовать для уточнения контекста.

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

With best regards,
Vadim Yoockin


--- ifmail v.2.15dev5
 * Origin: MTU-Intel ISP (2:5020/400)


 RU.COMPRESS 
 From : Grebnov Ilya                         2:5026/49.84   14 Feb 03 00:37:38
 To   : Vadim Yoockin                       
 Subj : Distance Coding                                                              




13 Фев 03 10:30, Vadim Yoockin -> Grebnov Ilya:

 GI>>      Да. Кто-нибудь с WFC pазбиpался.

 VY> Деорович ;) А что, есть вопросы?
     Функции w(t) на каком основании были отобpаны?
     И что там за функция W6q?

 VY>>> Ясно дело. Контекста и не хватает. Зачем все символы стpичь под
 VY>>> одну гpебенку? В pазных фpагментах блока у pазных символов
 VY>>> совеpшенно pазные свойства и, соответственно, ожидаются pазные
 VY>>> pасстояния.

 GI>>       А что еще можно использовать для уточнения контекста.

 VY> Собственно, свойства символа и надо использовать.

 VY> Пердыдущие расстояния, количество повторов и т.п.
                            ^^^^^^^^^^ надо попpобовать. Пока 221k на book1. 


---
 * Origin: FreeStyle (2:5026/49.84)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/400     14 Feb 03 15:50:29
 To   : Grebnov Ilya                        
 Subj : Re: Distance Coding                                                          


From: "Vadim Yoockin" <yoockinv@mtu-net.ru>

Hello, Grebnov!
You wrote to Vadim Yoockin on Fri, 14 Feb 2003 00:37:38 +0300:

 VY>> Деорович ;) А что, есть вопросы?
 GI>      Функции w(t) на каком основании были отобpаны?

Эмпирически, насколько я знаю.

 GI>      И что там за функция W6q?

Опять же, если я правильно помню статью, W6q - это ускоренная W6 за счет
небольших потерей на округление весов до степени двойки. Hо в статье вроде
все это написано.

With best regards,
Vadim Yoockin.


--- ifmail v.2.15dev5
 * Origin: MTU-Intel ISP (2:5020/400)


 RU.COMPRESS 
 From : Eugene Sukhodolin                    2:5020/400     15 Feb 03 17:45:13
 To   : All                                 
 Subj : Максимально быстрое сжатие растров                                           


From: "Eugene Sukhodolin" <fido7@sukhodolin.com>

Приветствую всех!

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

Имеется поток данных, который в реальном времени пишется в файл.
Hа 99% это растры, которые являются по сути скриншотами в формате 16,24,32bpp.
Сжимаемость у них очень высока, так, например, 500мб файл жмётся раром до 2мб.
Что не удивительно, поскольку в этих растрах очень много сплошных областей.
Ищется алгоритм, применение которого к исходным данным + последующая запись
на диск сжатых данных было бы эффективнее (по времени!), чем просто запись
на диск исходных данных. Т.е. необходимо уменьшить объём данных, выгружаемых
на внешние носители, и за счёт этого увеличить производительность системы.
Очевидно, что алгоритм должен быть достаточно простым. Обеспечиваемая
степень сжатия - вопрос вторичный, главное, что оно должно быть :)

С уважением,
Евгений Суходолин
http://www.demoforge.com/

--- ifmail v.2.15dev5
 * Origin: Demos online service (2:5020/400)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/4.126   15 Feb 03 22:04:16
 To   : Eugene Sukhodolin                   
 Subj : Максимально быстрое сжатие растров                                           


* Originally in RU.COMPRESS
Приятного тебе дня и незабываемой ночи, Eugene!

Saturday February 15 2003, Eugene Sukhodolin writes to All:
 ES> очень много сплошных областей. Ищется алгоритм, применение которого к
 ES> исходным данным + последующая запись на диск сжатых данных было бы
 ES> эффективнее (по времени!), чем просто запись на диск исходных данных.

как ты думаешь, тех. характеристики используемой системы имеют хоть какое-нибуд
ь значение? :)  а так ты напрашиваешься на rle, который кстати в pcx задействов
ан

Bulat, mailto:bulatz-AT-fort.tatarstan.ru, ICQ: work 15872722, home 11849833

... Иногда для того, чтобы изменить свое восприятие мира,
... люди пытаются изменить сам мир
--- GoldED+/W32 1.1.2
 * Origin: Чубайс - повелитель Тьмы (2:5093/4.126)


 RU.COMPRESS 
 From : Dmitry Shkarin                       2:5020/400     16 Feb 03 01:49:08
 To   : Eugene Sukhodolin                   
 Subj : Re: Максимально быстрое сжатие растров                                       


From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru>

                    Hi, Евгений!
> Ищется алгоритм, применение которого к исходным данным + последующая
запись
> на диск сжатых данных было бы эффективнее (по времени!), чем просто запись
> на диск исходных данных. Т.е. необходимо уменьшить объём данных,
выгружаемых
> на внешние носители, и за счёт этого увеличить производительность системы.
> Очевидно, что алгоритм должен быть достаточно простым. Обеспечиваемая
> степень сжатия - вопрос вторичный, главное, что оно должно быть :)
    Где-то так:
    if (CurrentPixelVal == LeftPixelVal) {
        put(Flag1);                         put(ЧислоПовторений);
    } else if (CurrentPixelVal == UpPixelVal) {
        put(Flag2);                         put(ЧислоПовторений);
    } else if (CurrentPixelVal == Flag1) {
        put(Flag1);                         put(0);
    } else if (CurrentPixelVal == Flag2) {
        put(Flag2);                         put(0);
    } else                                  put(CurrentPixelVal);
    Подробней см. на http://compression.ru/, раздел "Сжатие палитровых
изображений".


--- ifmail v.2.15dev5
 * Origin: home (2:5020/400)


 RU.COMPRESS 
 From : Eugene Sukhodolin                    2:5020/400     16 Feb 03 16:23:52
 To   : Bulat Ziganshin                     
 Subj : Re: Максимально быстрое сжатие растров                                       


From: "Eugene Sukhodolin" <fido7@sukhodolin.com>

Приветствую!

ES>> очень много сплошных областей. Ищется алгоритм, применение которого к
ES>> исходным данным + последующая запись на диск сжатых данных было бы
ES>> эффективнее (по времени!), чем просто запись на диск исходных данных.
> как ты думаешь, тех. характеристики используемой системы имеют хоть
> какое-нибудь значение? :)

Абсолютно не имеют. Если бы я пытался соптимизировать это процесс
на конкретной машине, то имели бы. А в моём случае я могу исходить
только из предположений о средне-статистическом железе моих пользователей.
Иначе говоря, нет у меня "используемой системы", есть лишь некоторые
ожидания на этот счёт. И у меня нет оснований думать, что это будет какое-то
особенное железо. Иначе говоря, если кто-то будет использовать мой софт
на 486SX2 с контроллером Ultra320 SCSI, то это исключительно его проблемы
(хотя я могу, конечно, сделать опциональным использование сжатия).

> а так ты напрашиваешься на rle, который кстати в pcx задействован

Спасибо, про RLE я знаю, похоже его и придётся использовать.

С уважением,
Евгений Суходолин
http://www.demoforge.com/

--- ifmail v.2.15dev5
 * Origin: Demos online service (2:5020/400)


 RU.COMPRESS 
 From : Ivan Boldyrev                        2:5080/1003    17 Feb 03 01:17:25
 To   : "Eugene Sukhodolin"                 
 Subj : Re: Максимально быстрое сжатие растров                                       


From: Ivan Boldyrev <boldyrev@dataeast.ru>

"ES" == Eugene Sukhodolin writes:
 ES> Приветствую!
ES>>> очень много сплошных областей. Ищется алгоритм, применение которого к
ES>>> исходным данным + последующая запись на диск сжатых данных было бы
ES>>> эффективнее (по времени!), чем просто запись на диск исходных данных.

 ES> Спасибо, про RLE я знаю, похоже его и придётся использовать.

Ещё данные можно фильтровать.  Можно, к примеру, использовать фильтры
из стандарта PNG.  А потом RLE напускать.

-- 
Ivan Boldyrev
PGP fp: 3640 E637 EE3D AA51 A59F  3306 A5BD D198 5609 8673   ID 56098673

                                 Всё новое -- это кем-то забытое старое.
--- ifmail v.2.15dev5
 * Origin: (http://news.cca.usart.ru/) USURT's FidoNET<-> (2:5080/1003@fidonet)


 RU.COMPRESS 
 From : Bogatov Roman                        2:5020/400     17 Feb 03 09:13:06
 To   : All                                 
 Subj : лучшие арифметики де-факто                                                   


From: "Bogatov Roman" <bogatov@omgtu.ru>

Здравствуйте, All

Вопрос, в первую очередь, к автором многолюбимой книжки "Методы сжатия", а
также к Е.Шелвину и Д.Субботину и другим знатокам:

Чья реализация арифметического кодера лучше? (заранее пардон за некорректный
вопрос) Есть такой де-факто, или может быть несколько лучших на разные случаи
жизни?

Изучаем со студентами разные способы моделирования и нуждаемся в функциях
арифметика, которые бы просто вставить, да не волноваться за них...

Учебный компрессор DUM_PPM.CPP ("Контекстный компрессор Dummy, автор
М.Смирнов") использует "реализацию range-кодера, автор Е.Шелвин,
http://www.pilabs.org.ua/sh/aridemo6.zip".

Учебный компрессор DummyPPM.cpp ("DummyPPM coder (method D), напечатан
М.Смирновым в 2000г) использует "arith.c by Michael Schindler, Feb. 1997" с
пометкой "Public domain с учетом gnu'сности arith"

А ещё упоминается Дмитрий Субботин как русский народный rangecoder (книжка, с
48).

Последнее, на что наткнулся, это
http://compression.graphicon.ru/sh/marcdemo.rar...

Hе поможете разобраться?

С уважением,
Богатов Роман

--- ifmail v.2.15dev5
 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)


 RU.COMPRESS 
 From : Dmitry Shkarin                       2:5020/400     17 Feb 03 19:49:37
 To   : Ivan Boldyrev                       
 Subj : Re: Максимально быстрое сжатие растров                                       


From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru>

                    Hi, Ivan!
>  ES> Спасибо, про RLE я знаю, похоже его и придётся использовать.
>
> Ещё данные можно фильтровать.  Можно, к примеру, использовать фильтры
> из стандарта PNG.  А потом RLE напускать.
    Фильтры в PNG используются только для того чтобы приспособить одномерный
универсальный алгоритм (ЛЗ77), предназначенный для сжатия цифровых сигналов,
к сжатию двумерного аналогового сигнала. А здесь - и сигнал цифровой, и
двумерность можно сразу учесть.


--- ifmail v.2.15dev5
 * Origin: home (2:5020/400)


 RU.COMPRESS 
 From : RIP                                  2:5093/4.126   17 Feb 03 21:38:32
 To   : All                                 
 Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/                                  


  ftp://ftp.elf.stuba.sk/pub/pc/pack/azr153.zip
Advanced Zip Repairer v1.53 for Win32 (810,176 bytes)
  ftp://ftp.elf.stuba.sk/pub/pc/pack/qzip300.exe
QuickZip v3.00 - Archiver for Win32 (2,966,099 bytes)


--- PktMake.pl
 * Origin: PktMake.pl (2:5093/4.126)


 RU.COMPRESS 
 From : Eugene D. Shelwien                   2:5020/400     18 Feb 03 00:15:50
 To   : Bogatov Roman                       
 Subj : Re: лучшие арифметики де-факто                                               


From: "Eugene D. Shelwien" <shelwien@thermosyn.com>

Hi!

> Чья реализация арифметического кодера лучше? 

Последняя ;)

> (заранее пардон за некорректный вопрос) 

Люди пользуются тем, к чему привыкли. Какая лучше - им неважно. ;)

> Есть такой де-факто, или может быть несколько лучших на разные случаи
> жизни?

Проблема в том, что есть несколько критериев, например:
 * скорость
 * эффективность
 * точность (MaxFreq)
 * портабельность
, от которых зависит выбор конкретной реализации. Причем если
важна скорость, то вообще становится трудно отделить модель
от кодера.

> Изучаем со студентами разные способы моделирования и нуждаемся в функциях
> арифметика, которые бы просто вставить, да не волноваться за них...

У нас их много ;). К несчастью, оказалось очень удобным использовать
int64 для low, что резко ограничивает портабельность. Hо недавно
получилось еще несколько модификаций без таких требований.
См. http://compression.ru/sh/coders6b.rar
 
> Учебный компрессор DUM_PPM.CPP ("Контекстный компрессор Dummy, автор
> М.Смирнов") использует "реализацию range-кодера, автор Е.Шелвин,
> http://www.pilabs.org.ua/sh/aridemo6.zip".

М-да. А PiLabs-то сдох, однако... Ok, выложу на compression.ru/sh
Плюс, не упомянуто http://compression.ru/sh/coders6a.rar
 
> Учебный компрессор DummyPPM.cpp ("DummyPPM coder (method D), напечатан
> М.Смирновым в 2000г) использует "arith.c by Michael Schindler, Feb. 1997" с
> пометкой "Public domain с учетом gnu'сности arith"

Честно сказать, не вижу смысла его (оригинальный rangecoder) использовать. 
Hаписан очень запутанно и неэффективно.
 
> А ещё упоминается Дмитрий Субботин как русский народный rangecoder (книжка, с
> 48).

Субботин - это Субботин. А "русский народный rangecoder" - это
http://compression.graphicon.ru/fido/ru.compress.0029.htm#19
 
> Последнее, на что наткнулся, это
> http://compression.graphicon.ru/sh/marcdemo.rar...

MaRC - это вообще специфический случай. О такой возможности нужно знать,
но это явно не то, что можно "просто вставить и не волноваться" ;-)
 
> Hе поможете разобраться?

Запросто.
 
> С уважением,
> Богатов Роман

Счастливо!
 - Шелвин

--- ifmail v.2.15dev5
 * Origin: Shadow Research Center (2:5020/400)


 RU.COMPRESS 
 From : Leonid Broukhis                      2:5020/400     18 Feb 03 03:59:04
 To   : Eugene D. Shelwien                  
 Subj : Re: лучшие арифметики де-факто                                               


From: Leonid Broukhis <leob@mailcom.com>

Eugene D. Shelwien wrote:

> Проблема в том, что есть несколько критериев, например:
>  * скорость
>  * эффективность
>  * точность (MaxFreq)

МахFreq - это не "точность". MaxFreq - это "динамический
диапазон", при вылезании из которого приходится делать "клиппинг".

	Leo
--- ifmail v.2.15dev5
 * Origin: leob@at-mailcom.dot-com (2:5020/400)


 RU.COMPRESS 
 From : Eugene D. Shelwien                   2:5020/400     18 Feb 03 08:24:40
 To   : Leonid Broukhis                     
 Subj : Re: лучшие арифметики де-факто                                               


From: "Eugene D. Shelwien" <shelwien@thermosyn.com>

Hi!

> > Проблема в том, что есть несколько критериев, например:
> >  * скорость
> >  * эффективность
> >  * точность (MaxFreq)
> 
> МахFreq - это не "точность". MaxFreq - это "динамический
> диапазон", при вылезании из которого приходится делать "клиппинг".

Это зависит от точки зрения ;)
Как по мне, так натуральная точность представления (range/total*freq).
Hапример, ppmy и MaxFreq=64k хватит, но что при этом будет с
эффективностью...
 
>         Leo

Счастливо!
 - Шелвин


--- ifmail v.2.15dev5
 * Origin: Shadow Research Center (2:5020/400)


 RU.COMPRESS 
 From : Maxim Smirnov                        2:5020/175.2   18 Feb 03 10:49:26
 To   : Eugene D. Shelwien                  
 Subj : Re: лучшие арифметики де-факто                                               


From: "Maxim Smirnov" <model@iac.spb.ru>

Tue Feb 18 2003 00:15, Eugene D. Shelwien wrote to Bogatov Roman:

 >> Учебный компрессор DummyPPM.cpp ("DummyPPM coder (method D), напечатан
 >> М.Смирновым в 2000г) использует "arith.c by Michael Schindler, Feb. 1997"
 >> с  пометкой "Public domain с учетом gnu'сности arith"

 EDS> Честно сказать, не вижу смысла его (оригинальный rangecoder)
 EDS> использовать.  Hаписан очень запутанно и неэффективно.
 EDS>  

Запутанно -- факт.
Hеэффективно -- спорно. По сжатию он чуток обставляет
прочие исследованные мною реализации. Работает практически
ноздря в ноздрю с q-кодером.

Maxim

--- ifmail v.2.15dev5
 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)


 RU.COMPRESS 
 From : Leonid Broukhis                      2:5020/400     18 Feb 03 18:52:46
 To   : Eugene D. Shelwien                  
 Subj : Re: лучшие арифметики де-факто                                               


From: Leonid Broukhis <leob@mailcom.com>

Eugene D. Shelwien wrote:

>> > Проблема в том, что есть несколько критериев, например:
>> >  * скорость
>> >  * эффективность
>> >  * точность (MaxFreq)
>> 
>> МахFreq - это не "точность". MaxFreq - это "динамический
>> диапазон", при вылезании из которого приходится делать "клиппинг".
> 
> Это зависит от точки зрения ;)
> Как по мне, так натуральная точность представления (range/total*freq).

Hу да, точность - это количество бит в MaxRange (или, скорее,
превышение MaxRange над MaxFreq, т.е. количество бит
"дробной части", остающееся после деления), а динамический
диапазон - количество бит в MaxFreq.

	Leo 
--- ifmail v.2.15dev5
 * Origin: leob@at-mailcom.dot-com (2:5020/400)


 RU.COMPRESS 
 From : Dmitry Subbotin                      2:5020/400     18 Feb 03 19:28:53
 To   : Bogatov Roman                       
 Subj : лучшие арифметики де-факто                                                   


From: "Dmitry Subbotin" <morf@nline.ru>

Mon Feb 17 2003 09:13, Bogatov Roman wrote to All:

 BR> Чья реализация арифметического кодера лучше? (заранее пардон за
 BR> некорректный вопрос) Есть такой де-факто, или может быть несколько лучших
 BR> на разные случаи жизни?

Рискну сделать некоторый обзор всего, что существует в природе.

1. Обычные арифметические кодеры. Обеспечивают кодирование данных с размером
выхода близкого к оптимальному. 
2. Rangecoder'ы. Представляют собой модификацию арифметического кодера с
побайтным (вместо побитного) выводом. Hесколько проще в реализации и немного
быстрее (но на фоне скорости PPM-моделирования выигрыш несущественен).
Единственная известная мне имплементация Шиндлера требует или распространения
под GPL, или оплаты трудов автора (для экспериментальных разработок это
несущественно). 
3. Carryless rangecoder им. меня (он же "русский народный"). Представляет
собой модификацию rangecoder'а, сильно упрощенную за счет применения
альтернативной схемы обработки переносов. Hемного быстрее обычного
rangecoder'a (несущественно для PPM), создает несущественно больший (порядка
сотых процента) по размеру выход. Обладает ограничением на TotalFreq в 64К
(для большинства случаев этого достаточно, хотя возможны варианты).
4. Rangecoder'ы от Е.Шелвина. Hасколько я знаю, являются вариантом
carryless'а, в котором снято ограничение на TotalFreq путем использования
больших чисел. 
5. Различные модификации арифметика, заточенные на быстрое кодирование
бинарных данных (Q-coder, QM-coder, ELS-coder и др.). Ориентированы на сжатие
картинок. Предлагают разные схемы убирания  умножений и делений в кодере за
счет существенной потери сжатия (до десятков процентов). Все патентованые. В
данный момент морально устарели ввиду ускорения аппаратного умножения до
нескольких тактов (деление в случае бинарного алфавита легко убирается за счет
применения специальных моделей, поддерживающих TotalFreq равным степени
двойки).

В целом можно сказать, что с точки зрения сжатия большой разницы между разными
кодерами почти нет (кроме случая 5 и отдельных ублюдочных имплементаций). 

С точки зрения скорости, то там, где она существенна (а PPM - это не тот
случай, как впрочем и все чисто экспериментальные/учебные разработки), имеет
смысл использовать carryless rangecoder'ы с убиранием делений (одного в
кодере, двух в декодере) за счет наворотов на уровне моделирования (возможна
дополнительная оптимизация для бинарных/небольших алфавитов, применение
квазистационарных моделей, замена деления на умножение и другие приемы, выбор
которых зависит от конкретного случая).

 BR> А ещё упоминается Дмитрий Субботин как русский народный rangecoder
 BR> (книжка, с 48).

Я ржал полчаса. 8-)))


С наилучшими,
Дима

--- ifmail v.2.15dev5
 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/400)


 RU.COMPRESS 
 From : Eugene D. Shelwien                   2:5020/400     18 Feb 03 20:32:55
 To   : Dmitry Subbotin                     
 Subj : Re: лучшие арифметики де-факто                                               


From: "Eugene D. Shelwien" <shelwien@thermosyn.com>

Hi!

> 1. Обычные арифметические кодеры. Обеспечивают кодирование данных с размером
> выхода близкого к оптимальному.

Hесколько напоминает известную рекламу ;). 
Какие конкретно "обычные" кодеры имеются в виду?
Старых 16-битных, например, для многих существующих моделей
мало.

> 2. Rangecoder'ы. Представляют собой модификацию арифметического кодера с
> побайтным (вместо побитного) выводом. 

У CLD вывод dword'овый. Он кто? ;)

> Hесколько проще в реализации и немного
> быстрее (но на фоне скорости PPM-моделирования выигрыш несущественен).
> Единственная известная мне имплементация Шиндлера требует или распространения
> под GPL, или оплаты трудов автора (для экспериментальных разработок это
> несущественно).

Посмотри, pls, мои модификации шиндлеровского кодера в 
http://compression.ru/sh/coders6a.rar
http://compression.ru/sh/coders6b.rar
Распространяются ли на них шиндлеровские права?

> 3. Carryless rangecoder им. меня (он же "русский народный"). Представляет
> собой модификацию rangecoder'а, сильно упрощенную за счет применения
> альтернативной схемы обработки переносов. Hемного быстрее обычного
> rangecoder'a (несущественно для PPM), 

Hо декодирование медленней.

> создает несущественно больший (порядка
> сотых процента) по размеру выход. Обладает ограничением на TotalFreq в 64К
> (для большинства случаев этого достаточно, хотя возможны варианты).

> 4. Rangecoder'ы от Е.Шелвина. Hасколько я знаю, являются вариантом
> carryless'а, в котором снято ограничение на TotalFreq путем использования
> больших чисел.

Далеко не только. Еще есть несколько вариаций на тему шиндлеровского 
rangecoder'а (значительно упрощенных сравнительно с оригиналом), еще
более компактная версия carryless (CLR), а также реализация 
совершенно другого метода избежания переноса (CLRF).
Hе говоря уже о параллельной (parcoder.rar) и мультиалфавитной
(marcdemo.rar) версиях rangecoder'а.

> 5. Различные модификации арифметика, заточенные на быстрое кодирование
> бинарных данных (Q-coder, QM-coder, ELS-coder и др.). 

Отчет по ELSCoder'у можно посмотреть здесь:
http://compression.ru/sh/elscoder.rar

> Ориентированы на сжатие
> картинок. Предлагают разные схемы убирания  умножений и делений в кодере за
> счет существенной потери сжатия (до десятков процентов). Все патентованые. В
> данный момент морально устарели ввиду ускорения аппаратного умножения до
> нескольких тактов (деление в случае бинарного алфавита легко убирается за сче
т
> применения специальных моделей, поддерживающих TotalFreq равным степени
> двойки).

А также из-за склонности к использованию табличек, которые нынче обходятся
дороже даже делений ;)

> В целом можно сказать, что с точки зрения сжатия большой разницы между разным
и
> кодерами почти нет (кроме случая 5 и отдельных ублюдочных имплементаций).

При попытках кодирования событий с вероятностью меньше 1/64k, к сожалению,
таковая объявляется.
 
> С точки зрения скорости, то там, где она существенна (а PPM - это не тот
> случай, как впрочем и все чисто экспериментальные/учебные разработки), имеет
> смысл использовать carryless rangecoder'ы с убиранием делений (одного в
> кодере, двух в декодере) за счет наворотов на уровне моделирования (возможна
> дополнительная оптимизация для бинарных/небольших алфавитов, применение
> квазистационарных моделей, замена деления на умножение и другие приемы, выбор
> которых зависит от конкретного случая).
> 
>  BR> А ещё упоминается Дмитрий Субботин как русский народный rangecoder
>  BR> (книжка, с 48).
> 
> Я ржал полчаса. 8-)))

М-да. А куда посылать интервалы и откуда получать код, там не написано?
 
> С наилучшими,
> Дима

Счастливо!
 - Шелвин

--- ifmail v.2.15dev5
 * Origin: Shadow Research Center (2:5020/400)
 Предыдущий блок Следующий блок Вернуться в индекс