| Предыдущий блок | Следующий блок | Вернуться в индекс |
— 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)
Предыдущий блок Следующий блок Вернуться в индекс