[an error occurred while processing this directive][an error occurred while processing this directive][an error occurred while processing this directive]
— 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)
[an error occurred while processing this directive][an error occurred while processing this directive]