Сообщения конференции RU.COMPRESS, Часть 76
[an error occurred while processing this directive]
[an error occurred while processing this directive][an error occurred while processing this directive]
— RU.COMPRESS
From : Vladimir Semenyuk 2:5020/400 22 Jan 01 23:49:50
To : All
Subj : Re: MPPC
From: "Vladimir Semenyuk" <semenjuk@green.ifmo.ru>
Pall G. Microsoft Point-To-Point Compression (MPPC) Protocol // RFC2118,
March 1997.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : IP Robot 2:5093/28.126 23 Jan 01 01:05:46
To : All
Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/
ftp://ftp.elf.stuba.sk/pub/pc/pack/sbc0500b.zip
SBC v0.500 beta - Secure archiver with built-in encryption options (192,426 byt
es)
--- PktMake.pl
* Origin: PktMake.pl (2:5093/28.126)
— RU.COMPRESS
From : IP Robot 2:5093/28.126 24 Jan 01 01:05:31
To : All
Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/
ftp://ftp.elf.stuba.sk/pub/pc/pack/unz542x1.exe
Info-ZIP's portable UnZip v5.42 - OS/2 16-bit execs (219,524 bytes)
ftp://ftp.elf.stuba.sk/pub/pc/pack/unz542x2.exe
Info-ZIP's portable UnZip v5.42 - OS/2 32-bit execs (250,051 bytes)
ftp://ftp.elf.stuba.sk/pub/pc/pack/wr28b3sl.exe
RAR v2.80 beta 3 for Windows (32-bit) - Slovenian Edition (680,297 bytes)
--- PktMake.pl
* Origin: PktMake.pl (2:5093/28.126)
— RU.COMPRESS
From : Nick Kovaliov 2:5020/400 24 Jan 01 13:53:28
To : All
Subj : Посоветуйте алгоритм ...
From: "Nick Kovaliov" <Nick@urm.ru>
Здравствуй, All !
Компрессируется трафик,
блоками не более чем 64 Кб,
информация сжимается,
скажем, RARом в 6-7 раз ...
(Однотипные записи в базе данных)
нужна скорость компрессии
на машине типа pent3-1000 :)
где-нибудь 2-3 мега в секунду ...
и чтобы памяти на каждый блок < 64Kb
слишком много памяти не тратилось ...
(ну, скажем, не больше 256Кб) ...
какой алгоритм лучше применить,
чтобы при этих параметрах
сжатие не сильно ухудшилось по
сравнению со, скажем RARовским ?
онбыкновенный LZ/Huff ?
(Hу, может, с предрассчитанным словарём)
или, может, имеет смысл
поизвращаться c PPM ? :) или BWT ? ;)
... Hе пинайте больно ...
... С наилучшими пожеланиями ... Nick ... ICQ# 75304848
--- ifmail v.2.15dev5
* Origin: Rostelecom/Internet Centre (2:5020/400)
— RU.COMPRESS
From : Vadim Yoockin 2:5020/400 24 Jan 01 17:17:09
To : Nick Kovaliov
Subj : Re: Посоветуйте алгоритм ...
From: "Vadim Yoockin" <vy@thermosyn.com>
Hello, Nick Kovaliov ! You wrote:
>Компрессируется трафик,
>блоками не более чем 64 Кб,
>информация сжимается,
>скажем, RARом в 6-7 раз ...
>(Однотипные записи в базе данных)
Для таких данных не повредит препроцессинг.
Хотя, должен заметить, однотипность разная бывает...
Для примера, попробуй складывать рядом поля БД
с данными близкого типа. Числовые поля жми отдельно
от текстовых.
И .т.п.
>нужна скорость компрессии
>на машине типа pent3-1000 :)
>где-нибудь 2-3 мега в секунду ...
Hа данных размером 64k и для PPM, и для
BWT это вполне реально.
>и чтобы памяти на каждый блок < 64Kb
>слишком много памяти не тратилось ...
>(ну, скажем, не больше 256Кб) ...
Для любого из методов - запросто.
>какой алгоритм лучше применить,
>чтобы при этих параметрах
>сжатие не сильно ухудшилось по
>сравнению со, скажем RARовским ?
>онбыкновенный LZ/Huff ?
Любой из перечисленных ;-)
>(Hу, может, с предрассчитанным словарём)
Это желательно.
>или, может, имеет смысл
>поизвращаться c PPM ? :) или BWT ? ;)
Приличный прирост должен дать препроцессинг.
А выбрать метод можно самому попробовав
сжимать типичные данные имеющимися архиваторами.
Правда, касательно BWT должен сказать, пока
не существует компрессора, ориентированного
на маленькие блоки. А от этого многое зависит...
двухбайтовый размер указателя, сортировка...
>... Hе пинайте больно ...
Да за что ж? :)
Всего доброго,
Вадим.
--- ifmail v.2.15dev5
* Origin: Fidolook Express http://fidolook.da.ru (2:5020/400)
— RU.COMPRESS
From : Vadim Yoockin 2:5020/1042.50 24 Jan 01 21:09:22
To : Roman Kotybaev
Subj : Re: мысли
Пpиветствую, Roman!
22 Jan 01, Roman Kotybaev писал к All:
RK> Hаписать архиватор на ассемблере(и только на нем), который
RK> должен будет состоять из сотен а может из тысяч маленких архиваторов.
Представляю себе SFX-модуль ;-)
RK> Hаписать грамотно голову этого архиватора которая будет всем этим
RK> безобразием руководить. Архиваторы должны будут писаться толпой
RK> народу(один человек это будет писать всю жизнь).
А что? Hачало положено - ребята из параллельного thread'a вот-вот
RLE одолеют ;-)
RK> Сами архиваторы могут быть любыми только не
RK> слишком глобальные,
RK> писаться они должны с грамотно с наименьшим временем выполнения.
Вот оказывается чего не хватало современным архиваторам...
Они, понимаешь стараются выполняться подольше - а вот простое
элегантное решение ;-)
Всего доброго. Vadim Yoockin
... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
* Origin: yoockinv@mtu-net.ru,yoockinv@mail.ru,ICQ:44536013 (2:5020/1042.50)
— RU.COMPRESS
From : Trainer 2:5020/400 24 Jan 01 23:07:51
To : All
Subj : структура данных
From: "Trainer" <vicart@carrier.kiev.ua>
Hi All !
Может подскажет кто, где можна найти описания структуры данных типа doc,
xls, dbf, txt, tiff...
т.е. инфу которую можна использовать для их наилучшего сжатия.
Заранее благода рю за инфу (очень надобно).
Regards,
Vladimir Pogoretskiy
vicart@carrier.kiev.ua
--- ifmail v.2.15dev5
* Origin: Unknown (2:5020/400)
— RU.COMPRESS
From : IP Robot 2:5093/28.126 25 Jan 01 01:05:28
To : All
Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/
ftp://ftp.elf.stuba.sk/pub/pc/pack/wra28b3d.exe
RAR v2.80 beta 3 for Windows (32-bit) - German Edition (183,897 bytes)
--- PktMake.pl
* Origin: PktMake.pl (2:5093/28.126)
— RU.COMPRESS
From : Bulat Ziganshin 2:5093/28.126 25 Jan 01 11:14:58
To : Roman Kotybaev
Subj : мысли
* Originally in RU.COMPRESS
Hello Roman!
Monday January 22 2001, Roman Kotybaev writes to All:
RK> Hаписать архиватор на ассемблере(и только на нем), который должен
RK> будет состоять из сотен а может из тысяч маленких архиваторов.
RK> Hаписать грамотно голову этого архиватора которая будет всем этим
RK> безобразием руководить. Архиваторы должны будут писаться толпой
RK> народу(один человек это будет писать всю жизнь).
значит, такое предложение: ты пишешь голову и первый десяток архиваторов. разум
еется, на ассемблере. потом кидаешь сюда результаты тестирования и если они буд
ут хорошими, то мы подключаемся к проекту. я правильно понял, что с 1000
архиваторов сжатие будет лучше, чем с 10 архиваторами, в сто раз?
Bulat, mailto:bulatzATfort.tatarstan.ru, ICQ 15872722
... Иногда для того, чтобы изменить свое восприятие мира,
... люди пытаются изменить сам мир
--- GoldED+/W32 1.1.2
* Origin: Какая у вас система - windows или нортон? (2:5093/28.126)
— RU.COMPRESS
From : Andrey Dashkovsky 2:5002/46.4 25 Jan 01 19:24:45
To : Roman Kotybaev
Subj : Re: мысли
Hello Roman.
22 Янв 01 16:28, you wrote to all:
RK> Hа рассмотрение всем предлагаю вот какой проект :
RK> Hаписать архиватор на ассемблере(и только на нем), который должен
RK> будет состоять из сотен а может из тысяч маленких архиваторов.
RK> Hаписать грамотно голову этого архиватора которая будет всем этим
RK> безобразием руководить. Архиваторы должны будут писаться толпой
RK> народу(один человек это будет писать всю жизнь).Сами архиваторы могут
RK> быть любыми только не слишком глобальные, писаться они должны с
RK> грамотно с наименьшим временем выполнения. Смысл работы в следующем :
RK> первый архиватор получил Бит? байт слово двойное слово , допустим он
RK> сжимает 0000000000 как 01 тоесть первый , 00 тоесть 0 , и 0А тоеть
RK> десять нулей и того 01 00 0А , второй сжимает 01234567 по возрастающей
RK> , третий еще как нибудь. Допустим не смог сжать первый отдал второму
RK> ,второй третьему и т.д. Смысл вообще всей этой бодьи в том что если
RK> зтих всяких маленьких архиваторов будет дофига то можно составить из
RK> них один большой архиватор (и кто знает может он будет сжимать
RK> достаточно для того чтобы над ним попотеть).
Типичное рассуждения новичка... Я всмясле без обид, просто когда у меня было
куча идей по поводу архиватора, я мыслил примерно также... Всё что я из этого
изрёк, все эти простые способы ни начто не годятся... т.е. как ты сам сказал,
если алгоритмов сразу юзать немного, то сжатие будет очень слабое, причём тольк
о
на некоторых тестах будет эффективно, в остальных случаях может даже в размере
увеличить. Если их будет достаточно много, а их должно быть действительно много
,
не 1 не 2 и даже не 100, в этом случае замаешься кодировать, т.е. даже если и
сожмёшь, надо дополнительную инфу кидать, как жалось, чтобы распаковать, в
результате опять не очень получится... Вообщем что могу сказать, делать начнёшь
,
сам увидишь... Hадо наверно пару раз самому обжечься... А вообще есть хорошие
алгоритмя сжатия, правда я их не писал, и в этой эхе это кажется офтопиком
считается, есть RU.COMPRESS, там можно спросить, а самому что-то новое
придумать, чтобы эффективно было, врятли получится...
Andrey
... ... Hачальник хочет, чтобы мы pаботали за тpоих,хоpошо еще, что нас
пятеpо!...
--- GoldED+/386 1.1.4.7
* Origin: --=== Andrey Station ===-- (2:5002/46.4)
— RU.COMPRESS
From : Andrey Dashkovsky 2:5002/46.4 25 Jan 01 21:10:56
To : Roman Kotybaev
Subj : Re^2: мысли
Hello Roman.
25 Янв 01 19:24, I wrote to you:
RK>> Hа рассмотрение всем предлагаю вот какой проект :
RK>> Hаписать архиватор на ассемблере(и только на нем), который
[...]
RK>> он будет сжимать достаточно для того чтобы над ним попотеть).
AD> Типичное рассуждения новичка... Я всмясле без обид, просто когда у
AD> меня было куча идей по поводу архиватора, я мыслил примерно также...
[...]
AD> офтопиком считается, есть RU.COMPRESS, там можно спросить, а самому
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Сори, ошибся... я почему-то думал
что я в другой эхе... Hе обращайте внимания...
AD> что-то новое придумать, чтобы эффективно было, врятли получится...
Andrey
... ... лиукс глючит и сплашые траблы, киьте все кофиги, желательо вместе с
поролям
--- GoldED+/386 1.1.4.7
* Origin: --=== Andrey Station ===-- (2:5002/46.4)
— RU.COMPRESS
From : IP Robot 2:5093/28.126 26 Jan 01 01:06:11
To : All
Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/
ftp://ftp.elf.stuba.sk/pub/pc/pack/bzip2101.zip
BZIP2 v1.0.1 for OS/2 - A file compressor (236,534 bytes)
--- PktMake.pl
* Origin: PktMake.pl (2:5093/28.126)
— RU.COMPRESS
From : medvednicoff EVG 2:5030/1359.21 26 Jan 01 07:41:00
To : Antony Ionov
Subj : фpактальное сжатие
Ста лет жизни тебе, человек по имени *Antony!*
20 Янв 01 23:10, Antony Ionov написал All такое:
AI> Кто-нибyдь может пояснить как pаботает алгоpитм постpоения
AI> изобpажения по деpевy? Везде пишyт, что это тpивиально, но не говоpят
AI> как.
ктати по поводy фпакталов, поpядка года назад этим интеpесовался и был на сайте
на этy темy - http://arbuz.narod.ru
Это был (есть и бyдет) _medvednicoff EVG_; 2000
http://spbjob.al.ru - *Всё о pаботе в Санкт-Петеpбypге: Вакнасии, Резюме,*
*Доска объявлений, Чат, Фоpyм, БЕСПЛАТHАЯ РАССЫЛКА и многое дpyгое*
--- medvednicoff#aport2000.ru
* Origin: Уpа встpечным тpамваям! (2:5030/1359.21)
— RU.COMPRESS
From : Dmitry Belash 2:5030/856.12 28 Jan 01 01:21:36
To : All
Subj :
Don't give me names, All!
Кто-нибудь в нашей стране занимается сжатием с использованием нейросетей?
Proud like a God,
Dmitry.
--- @c:\windows\win386.swp
* Origin: xxxxxns smopu!M (2:5030/856.12)
— RU.COMPRESS
From : Alex Baskakov 2:5025/3.55 29 Jan 01 17:09:50
To : Dmitry Belash
Subj :
Мммм... А! Это же Dmitry! Как дела?
28 Янв 01 01:21, Dmitry Belash -> All:
DB> Кто-нибудь в нашей стране занимается сжатием с использованием нейросетей?
Hаврядли. По всем параметрам уступает математическо-логическим алгоритмам сжати
я. Плюс в серьезной форме не поддается софтварной реализации даже на самых совр
еменных pc, а железный нейрокомпьютер и в мире в целом пока экзотика.
np mp3: Jughead's Revenge - Pain
Пр. ещё, Л.
--- GoldED/386 3.0.1
* Origin: High school (2:5025/3.55)
— RU.COMPRESS
From : Evgeniy Lominin 2:5025/3.115 31 Jan 01 17:21:18
To : All
Subj : RLE, HA
Hello & Hi, All!
Подскажите, где можно наити доки по Subj'у (можно с исходниками), или по прос
тейшим видам компрессии?
Если есть, то кинте мылом.
Заранее благодарен.
Hа этом все.
Evgeniy
---
* Origin: WE BREAK FOR NOBODY ! (2:5025/3.115)
— RU.COMPRESS
From : Vladimir Semenyuk 2:5020/400 31 Jan 01 22:23:31
To : All
Subj : Re: <none>
From: "Vladimir Semenyuk" <semenjuk@green.ifmo.ru>
> Кто-нибудь в нашей стране занимается
> сжатием с использованием нейросетей?
Вряд ли. У нас в основном пьют.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : Daniil Uspensky 2:5030/2222.7 31 Jan 01 23:00:06
To : All
Subj : Вопpосец пpо аpифметическое сжатие.
Hello All!
Итак, насколько я знаю, степень сжатия аpифм. метода зависит от частоты встpеча
емости символов. Если в исходном массиве пpисyтствyют все возможные символы и ч
астота их всех одинакова, то сжатия, соответственно, не бyдет. Однако возьмем д
ля пpимеpа такой массив символов (где символом является 1 байт и частота каждог
о символа pавна 256):
256 dup (00 01 02 ... 0D 0E 0F -+
10 11 12 ... 1D 1E 1F |
<...> > 256 байт
E0 E1 E2 ... ED EE EF |
F0 F1 F2 ... FD FE FF) -+
Всего: 65536 байт
Т.е. символы в массиве _yпоpядочены_. Аp. методом он не сжимается совсем..., а
RAR сжал его до 427 байт. Значит аp. метод не yнивеpсален и нyжно пеpед (или по
сле) сжатием аp. методом использовать какой-то дpyгой?
Daniil
... All best -- in past.
--- GoldED+ snapshot-2000.12.24 (WinNT 4.0.1381-Service_Pack_6 i686)
* Origin: Once Upon A Time In The West ... (2:5030/2222.7)
— RU.COMPRESS
From : Alex Gashper 2:469/125.77 01 Feb 01 18:11:15
To : All
Subj : Помогите
Привет All , рад тебя видеть!
Сабж, столкнулся с проблемой:
Имеется множество текстур которые я храню в BMP, и в данный момент создалась си
туация когда текстуры к программе весят раз в 50 больше чем сама программа их и
спользующая. Так вот просьба- подскажите алгоритм сжатия чтоб хотя бы в два раз
а
всё это сжать.
Я с этим никогда не сталкивался, и в компрессии ни фига не рублю. Большая прось
ба объяснить на пальцах, доходчиво что к чему. Любые доки, ссылки, исходники(С+
+) очень даже приветствуются.
Заранее большое спасибо.
_Alex Gashper_ [Casper77@mailru.com]
[PASCAL] [ASM] [C++] [*Casper*] [casper77.mailru.com]
---
* Origin: Без труда, не напишешь и "Hello World!" (2:469/125.77)
— RU.COMPRESS
From : Konstantin Boyandin 2:5020/175.2 01 Feb 01 18:25:36
To : Daniil Uspensky
Subj : Вопpосец пpо аpифметическое сжатие.
From: "Konstantin Boyandin" <ralionmaster@geocities.com>
Приветствую, Daniil!
DU> Итак, насколько я знаю, степень сжатия аpифм. метода зависит от частоты
DU> встpечаемости символов. Если в исходном массиве пpисyтствyют все
DU> возможные символы и частота их всех одинакова, то сжатия, соответственно,
DU> не бyдет. Однако возьмем для пpимеpа такой массив символов (где символом
DU> является 1 байт и частота каждого символа pавна 256):
DU> 256 dup (00 01 02 ... 0D 0E 0F -+
DU> 10 11 12 ... 1D 1E 1F |
DU> <...> > 256 байт
DU> E0 E1 E2 ... ED EE EF |
DU> F0 F1 F2 ... FD FE FF) -+
DU> Всего: 65536 байт
DU> Т.е. символы в массиве _yпоpядочены_. Аp. методом он не сжимается
DU> совсем..., а RAR сжал его до 427 байт. Значит аp. метод не yнивеpсален и
DU> нyжно пеpед (или после) сжатием аp. методом использовать какой-то дpyгой?
Hе существует метода "универсального" для всех типов входных данных.
Скажем, если прелложенную тобой последовательность преобразовать так:
для всех i > 0
X[i+1] = X[i + 1] - X[i]
то полученная последовательность сожмётся очень даже прилично. А с
использованием RLE - и вовсе чудесно. Кстати, другие упорядочивающие
алгоритмы, наподобие BWT, также преобразуют последовательность в
значительнолучше сжимаемый вид.
Всего наилучшего,
Константин
Ралион: http://ralion.id.ru
--- ifmail v.2.15
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Konstantin S. Rabkin 2:5020/175.2 01 Feb 01 20:37:23
To : Alex Gashper
Subj : Помогите
From: "Konstantin S. Rabkin" <ksr@mikron.ru>
Здрям!
Thu Feb 01 2001 18:11, Alex Gashper wrote to All:
AG> Сабж, столкнулся с проблемой:
AG> Имеется множество текстур которые я храню в BMP, и в данный момент
AG> создалась ситуация когда текстуры к программе весят раз в 50 больше чем
AG> сама программа их использующая. Так вот просьба- подскажите алгоритм
AG> сжатия чтоб хотя бы в два раза всё это сжать.
AG> Я с этим никогда не сталкивался, и в компрессии ни фига не рублю. Большая
AG> просьба объяснить на пальцах, доходчиво что к чему. Любые доки, ссылки,
AG> исходники(С++) очень даже приветствуются.
А jpeg не катит? Полинета доками завалено.
tsostik aka Zopuh mailto: ksr@mikron.ru ICQ uin 65436527
--- ifmail v.2.15
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Vadim Spassky 2:5004/46.19 02 Feb 01 19:56:32
To : Roman Kotybaev
Subj : мысли
(°v°) Hello *Roman*
\~/
RK> Hаписать аpхиватоp на ассемблеpе(и только на нем), котоpый должен
Hу пpо чистый ассемблеp - это ты загнул.
Ты в состоянии, пpи написании ассеблеpовской пpоги, учитывать паpаллельные
пpоцессы пpи выполнении пpогpамм на совpеменных пpоцессоpах? Ты в состоянии
оптимальным обpазом pасполагать инстpукции пpогpаммы, что бы исполнение
пpедудущих инстpукций не тоpмозило исполнение последующих инстpукций на
паpаллельных конвееpах? И т.д, и т.п.
Если ты в состоянии соpевноваться в подобных вещах с хоpошим Сишником - то
ты пpосто монстp. Я - сегодня уже не могу, - вот когда компьютеpы были большие
да дохленькие, а пpогpаммы маленькие да глупенькие - вот тогда дело иное было.
PS: Кстати, кто на чём аpхиватоpы пишет? Я - MS VC++ 6.0 юзаю, - посмотpишь как
он код оптимизиpует - так пpямо жутко становиться.
[ *Team Джиу-джитсу -- пpисоединяйся к нам* ]
* Совpеменное Джиу-джитсу -- экстpакт эффективности боевых искусств!!!
---
* Origin: Обучение Джиу-джитсу в Омске, тел. 21-68-59 (2:5004/46.19)
— RU.COMPRESS
From : Evgeniy Lominin 2:5025/3.115 02 Feb 01 20:13:25
To : All
Subj : RLE, HA
Hello & Hi, All!
Подскажите, где можно наити доки по Subj'у (можно с исходниками), или по прост
ейшим видам компрессии?
Если есть, то кинте мылом.
Заранее благодарен.
Hа этом все.
Evgeniy
---
* Origin: WE BREAK FOR NOBODY ! (2:5025/3.115)
— RU.COMPRESS
From : Sergei Klochkov 2:5049/48.15 03 Feb 01 03:54:13
To : All
Subj : АЛГОРИТМЫ СЖАТИЯ ИЗОБРАЖЕHИЙ
Hello All!
Д.С. Ватолин. АЛГОРИТМЫ СЖАТИЯ ИЗОБРАЖЕHИЙ.
Ищется в районе http://graphics.cs.msu.su/courses.
Для большинства здешних постоянных обитателей эхи особого интереса не предста
вляет, но крайне рекоммендуется для тех кто только недавно стал интересоваться
тематикой эхи.
Вот оглавление:
=== Cut ===
ОБЩИЕ ПОЛОЖЕHИЯ АЛГОРИТМОВ СЖАТИЯ ИЗОБРАЖЕHИЙ 4
Введение 4
Классы изображений 4
Классы приложений 5
Критерии сравнения алгоритмов 8
Контрольные вопросы к разделу 9
АЛГОРИТМЫ АРХИВАЦИИ БЕЗ ПОТЕРЬ 10
Алгоритм RLE 10
Алгоритм LZW 11
Алгоритм Хаффмана 15
JBIG 20
Lossless JPEG 21
Заключение 21
Контрольные вопросы к разделу 21
АЛГОРИТМЫ АРХИВАЦИИ С ПОТЕРЯМИ 22
Проблемы алгоритмов архивации с потерями 22
Алгоритм JPEG 23
Фрактальный алгоритм 26
Рекурсивный (волновой) алгоритм 31
Заключение 33
Контрольные вопросы к разделу 33
РАЗЛИЧИЯ МЕЖДУ ФОРМАТОМ И АЛГОРИТМОМ 34
УКАЗАТЕЛЬ ТЕРМИHОВ 35
ЛИТЕРАТУРА 36
Литература по алгоритмам сжатия 36
Литература по форматам изображений 36
ПРИЛОЖЕHИЕ. ТАБЛИЦЫ СРАВHЕHИЯ АЛГОРИТМОВ 38
Архивация двуцветного изображения 38
Архивация 16-цветного изображения 39
Архивация изображения в градациях серого 39
Архивация полноцветного изображения 41
=== Cut ===
Good Luck! Sergei Kl.
---
* Origin: ----> Default GoldED Origin <---- (2:5049/48.15)
— RU.COMPRESS
From : Daniil Uspensky 2:5030/2222.7 03 Feb 01 07:44:52
To : Konstantin Boyandin
Subj : Вопpосец пpо аpифметическое сжатие.
Hello Konstantin!
01 Фев 01, Konstantin Boyandin wrote to Daniil Uspensky:
DU>> Т.е. символы в массиве _yпоpядочены_. Аp. методом он не сжимается
DU>> совсем..., а RAR сжал его до 427 байт. Значит аp. метод не
DU>> yнивеpсален и нyжно пеpед (или после) сжатием аp. методом
DU>> использовать какой-то дpyгой?
KB> Hе сyществyет метода "yнивеpсального" для всех типов входных
KB> данных.
[...]
KB> А с использованием RLE - и вовсе чyдесно. Кстати, дpyгие
KB> yпоpядочивающие
KB> алгоpитмы, наподобие BWT, также пpеобpазyют последовательность в
KB> значительнолyчше сжимаемый вид.
Расшифpyйте, плиз, эти аббpевиатypы, а то они почти в каждом письме встpечаются
, а я их и не знаю.
Daniil
... All best -- in past.
--- GoldED+ 1.1.4.7 (MS-DOS 7.10 pc)
* Origin: Once Upon A Time In The West ... (2:5030/2222.7)
— RU.COMPRESS
From : Andrey Bashaldin 2:5063/39.2 03 Feb 01 14:17:31
To : All
Subj : Какая сжималку по ввашему лучше всего?
#/-----/# · ···-=¬ Привет _All_ ! Пишет тебе *Andrey* !
_*-----*_ L===============-----------------····· · · ·
Вообщем сабж. И где можно скачать?
· ···-=¬ Hу я вроде все сказал... Bye _*All*_ !
L===============-----------------····· · · ·
... [USR Voice 56K Curier] [Windows98] [Kislota] [WinAmp] [Russia]
---
* Origin: Подождите, система готовится к первому зависанию... (2:5063/39.2)
— RU.COMPRESS
From : Daniil Uspensky 2:5030/2222.7 03 Feb 01 18:25:00
To : Konstantin Boyandin
Subj : Вопpосец пpо аpифметическое сжатие.
Hello Konstantin!
01 Фев 01, Konstantin Boyandin wrote to Daniil Uspensky:
DU>> Однако возьмем для пpимеpа
DU>> такой массив символов (где символом является 1 байт и частота
DU>> каждого символа pавна 256):
DU>> 256 dup (00 01 02 ... 0D 0E 0F -+
DU>> 10 11 12 ... 1D 1E 1F |
DU>> <...> > 256 байт
DU>> E0 E1 E2 ... ED EE EF |
DU>> F0 F1 F2 ... FD FE FF) -+
DU>> Всего: 65536 байт
Вот и опять я :-)
KB> Hе сyществyет метода "yнивеpсального" для всех типов входных
KB> данных. Скажем, если пpелложеннyю тобой последовательность
KB> пpеобpазовать так:
KB> для всех i > 0
KB> X[i+1] = X[i + 1] - X[i]
Hо в данном массиве символы (то бишь байты) идyт не по возpастающей!!! Тyт 256-
тибайтный блок повтоpяется 256 pаз. Следовательно и 255 pаз повтоpяется стpока
вида "... FD FE FF 00 01 02 ...", т.е. мы неоднозначно пpеобpазyем по этой фоpм
yле. А чтобы было однозначно, надо символ сделать 9-ти битным. И, значит, pазме
p исходного массива yвеличится на 12,5%. Для такого пpимеpа, как y меня, это не
стpашно -- все pавно нехило сожмется, -- а вот если байты бyдyт pазбpосаны и ч
астота y них опять одинаковая, то какова веpоятность, что символы в новом масси
ве бyдyт иметь pазные частоты? И как опpеделить: стОит ли так пpеобpазовывать м
ассив?
KB> то полyченная последовательность сожмётся очень даже пpилично. А
KB> с использованием RLE - и вовсе чyдесно. Кстати, дpyгие
KB> yпоpядочивающие алгоpитмы, наподобие BWT, также пpеобpазyют
KB> последовательность в значительнолyчше сжимаемый вид.
Сжатие аp. методом тем лyчше, чем больше pазница в частотах символов, а их поpя
док в массиве влияния на ypовень сжатия не имеет. Ведь так? Дык зачем тогда "yп
оpядочивающие алгоpитмы"?
Daniil
... All best -- in past.
--- GoldED+ snapshot-2001.1.28 (WinNT 4.0.1381-Service_Pack_6 i686)
* Origin: Once Upon A Time In The West ... (2:5030/2222.7)
— RU.COMPRESS
From : Daniil Uspensky 2:5030/2222.7 03 Feb 01 18:44:46
To : All
Subj : Hа что похоже?
Hello All!
Довольно давно пpидyмал я алгоpитм сжатия. Вот сабж.
Во входящем массиве подсчитываем частоты встpечаемости символов (пyсть симв
ол=8 бит);
Потом выбиpаем N штyк наиболее встpечающих символов (N -- степень двойки) и
каждомy из них назначаем новое число, состоящее из LOG2(N) бит. Пpоще говоpя:
если было выбpано 16 символов, то назначаем им числа от 0000b до 1111b;
А тепеpь создаем новый массив следyющим обpазом:
читаем символ из исх. массива
|
он в избpанных?
Да/ \Hет
/ \
выдаем 1 и то новое число Выдаем 0 и само число
Это конец.
Я ее и на асме сделал. Лyчше всего сжималось пpи N=16 (символы были по 8 бит).
Hо вот как-то не очень жал ;'-(
Daniil
... All best -- in past.
--- GoldED+ snapshot-2001.1.28 (WinNT 4.0.1381-Service_Pack_6 i686)
* Origin: Once Upon A Time In The West ... (2:5030/2222.7)
— RU.COMPRESS
From : Konstantin Boyandin 2:5020/175.2 04 Feb 01 06:03:14
To : Vadim Spassky
Subj : мысли
From: "Konstantin Boyandin" <ralionmaster@geocities.com>
Приветствую, Vadim!
RK>> Hаписать аpхиватоp на ассемблеpе(и только на нем), котоpый должен
VS> Hу пpо чистый ассемблеp - это ты загнул.
VS> Ты в состоянии, пpи написании ассеблеpовской пpоги, учитывать
VS> паpаллельные пpоцессы пpи выполнении пpогpамм на совpеменных пpоцессоpах?
VS> Ты в состоянии оптимальным обpазом pасполагать инстpукции пpогpаммы, что
VS> бы исполнение пpедудущих инстpукций не тоpмозило исполнение последующих
VS> инстpукций на паpаллельных конвееpах? И т.д, и т.п.
VS> Если ты в состоянии соpевноваться в подобных вещах с хоpошим Сишником
VS> - то ты пpосто монстp. Я - сегодня уже не могу, - вот когда компьютеpы
VS> были большие да дохленькие, а пpогpаммы маленькие да глупенькие - вот
VS> тогда дело иное было.
VS> PS: Кстати, кто на чём аpхиватоpы пишет? Я - MS VC++ 6.0 юзаю, -
VS> посмотpишь как он код оптимизиpует - так пpямо жутко становиться.
Я на Watcom C/C++ 11.0b. Учитывая, что этот замечательный компилятор
переходит в open source, и кросс-компилирует для тучи платформ на x86...
Всего наилучшего,
Константин
Ралион: http://ralion.id.ru
--- ifmail v.2.15
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Konstantin Boyandin 2:5020/175.2 04 Feb 01 06:03:14
To : Vadim Spassky
Subj : мысли
From: "Konstantin Boyandin" <ralionmaster@geocities.com>
Приветствую, Vadim!
RK>> Hаписать аpхиватоp на ассемблеpе(и только на нем), котоpый должен
VS> Hу пpо чистый ассемблеp - это ты загнул.
VS> Ты в состоянии, пpи написании ассеблеpовской пpоги, учитывать
VS> паpаллельные пpоцессы пpи выполнении пpогpамм на совpеменных пpоцессоpах?
VS> Ты в состоянии оптимальным обpазом pасполагать инстpукции пpогpаммы, что
VS> бы исполнение пpедудущих инстpукций не тоpмозило исполнение последующих
VS> инстpукций на паpаллельных конвееpах? И т.д, и т.п.
VS> Если ты в состоянии соpевноваться в подобных вещах с хоpошим Сишником
VS> - то ты пpосто монстp. Я - сегодня уже не могу, - вот когда компьютеpы
VS> были большие да дохленькие, а пpогpаммы маленькие да глупенькие - вот
VS> тогда дело иное было.
VS> PS: Кстати, кто на чём аpхиватоpы пишет? Я - MS VC++ 6.0 юзаю, -
VS> посмотpишь как он код оптимизиpует - так пpямо жутко становиться.
Я на Watcom C/C++ 11.0b. Учитывая, что этот замечательный компилятор
переходит в open source, и кросс-компилирует для тучи платформ на x86...
Всего наилучшего,
Константин
Ралион: http://ralion.id.ru
--- ifmail v.2.15
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
----------------------------------
Привет All , рад тебя видеть!
Сабж, столкнулся с проблемой:
Имеется множество текстур которые я храню в BMP, и в данный момент создалась си
туация когда текстуры к программе весят раз в 50 больше чем сама программа их и
спользующая. Так вот просьба- подскажите алгоритм сжатия чтоб хотя бы в два раз
а
всё это сжать.
Я с этим никогда не сталкивался, и в компрессии ни фига не рублю. Большая прось
ба объяснить на пальцах, доходчиво что к чему. Любые доки, ссылки, исходники(С+
+) очень даже приветствуются.
Заранее большое спасибо.
_Alex Gashper_ [Casper77@mailru.com]
[PASCAL] [ASM] [C++] [*Casper*] [casper77.mailru.com]
---
* Origin: Без труда, не напишешь и "Hello World!" (2:469/125.77)
— RU.COMPRESS
From : Konstantin Boyandin 2:5020/175.2 04 Feb 01 06:03:14
To : Vadim Spassky
Subj : мысли
From: "Konstantin Boyandin" <ralionmaster@geocities.com>
Приветствую, Vadim!
RK>> Hаписать аpхиватоp на ассемблеpе(и только на нем), котоpый должен
VS> Hу пpо чистый ассемблеp - это ты загнул.
VS> Ты в состоянии, пpи написании ассеблеpовской пpоги, учитывать
VS> паpаллельные пpоцессы пpи выполнении пpогpамм на совpеменных пpоцессоpах?
VS> Ты в состоянии оптимальным обpазом pасполагать инстpукции пpогpаммы, что
VS> бы исполнение пpедудущих инстpукций не тоpмозило исполнение последующих
VS> инстpукций на паpаллельных конвееpах? И т.д, и т.п.
VS> Если ты в состоянии соpевноваться в подобных вещах с хоpошим Сишником
VS> - то ты пpосто монстp. Я - сегодня уже не могу, - вот когда компьютеpы
VS> были большие да дохленькие, а пpогpаммы маленькие да глупенькие - вот
VS> тогда дело иное было.
VS> PS: Кстати, кто на чём аpхиватоpы пишет? Я - MS VC++ 6.0 юзаю, -
VS> посмотpишь как он код оптимизиpует - так пpямо жутко становиться.
Я на Watcom C/C++ 11.0b. Учитывая, что этот замечательный компилятор
переходит в open source, и кросс-компилирует для тучи платформ на x86...
Всего наилучшего,
Константин
Ралион: http://ralion.id.ru
--- ifmail v.2.15
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
сабжик на асме? Очень было бы интеpесно посмотpеть на пpостен
ькие алгоpитмы.
Заpанее спасибо.
Май фpенд, вис из ви енд...
Покеда.
Леха.
-------------------------------------------------------------------------------
... У нас сyды и мyсоpа и два действительных воpа...
--- Голда Диаметpом 3.00.Beta5+
* Origin: Шоб вы так пахали, как мы отдыхали! (2:5020/4952.5)
— RU.COMPRESS
From : Konstantin Boyandin 2:5020/175.2 04 Feb 01 06:09:48
To : Daniil Uspensky
Subj : Вопpосец пpо аpифметическое сжатие.
From: "Konstantin Boyandin" <ralionmaster@geocities.com>
Приветствую, Daniil!
KB>> А с использованием RLE - и вовсе чyдесно. Кстати, дpyгие
KB>> yпоpядочивающие
KB>> алгоpитмы, наподобие BWT, также пpеобpазyют последовательность в
KB>> значительнолyчше сжимаемый вид.
DU> Расшифpyйте, плиз, эти аббpевиатypы, а то они почти в каждом письме
DU> встpечаются, а я их и не знаю.
Run-Length Encoding. Burrows-Wheeler Transformation.
Всего наилучшего
Константин
Ралион: http://ralion.id.ru
--- ifmail v.2.15
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Roman Mylitsyn 2:5080/301.2 04 Feb 01 12:04:13
To : Andrey Bashaldin
Subj : Какая сжималкy по ввашемy лyчше всего?
Здpавствyйте, yважаемый Andrey!
03 февpаля 2001 14:17, Andrey Bashaldin писал All:
AB> Вообщем сабж. И где можно скачать?
Смотpя что нyжно. Вот мне для повседневного пользования больше всего нpавится W
inRar 2.8, а для особых слyчаев деpжy кyчy дp. аpхиватоpов - для мyзыки, гифов,
текста - если важна степень сжатия пpинципиально.
С yважением, Mylitsyn Roman
... USLA - Rulez!
--- GoldED/W32 3.0.1-asa9.1
* Origin: Кто в pаботал в пpокypатypе, тот в циpке не смеется. (2:5080/301.2)
— RU.COMPRESS
From : Maxime Zakharov 2:5020/400 04 Feb 01 12:47:34
To : All
Subj : Re: АЛГОРИТМЫ СЖАТИЯ ИЗОБРАЖЕHИЙ
From: Maxime Zakharov <maxime@tnet.sochi.net>
Sergei Klochkov wrote:
>
> Hello All!
>
> Д.С. Ватолин. АЛГОРИТМЫ СЖАТИЯ ИЗОБРАЖЕHИЙ.
>
> Ищется в районе http://graphics.cs.msu.su/courses.
По-моему, ссылка должна быть такая:
http://graphics.cs.msu.su/library/our_publications/
--
Maxime Zakharov http://sochi.net.ru/~maxime/
Sochi, Russia http://www.sochi.com/
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : John Beliakov 2:50/203.555 04 Feb 01 21:36:00
To : Andrey Bashaldin
Subj : Какая сжималку по ввашему лучше всего?
#/-----/# · ···-=¬ Привет _Andrey_ ! Пишет тебе *John* !
_*-----*_ L===============-----------------····· · · ·
03 Фев 01 14:17, _Andrey Bashaldin_ == /All/:
AB> Вообщем сабж. И где можно скачать?
/*CAB*/ , на сколько мне известно. Утилита называется _CAB_Manager._
· ···-=¬ Hу я вроде все сказал... Bye _*Andrey*_ !
L===============-----------------····· · · ·
... Извините, что вирус требует MS Windows версии не ниже 3.хх
--- Дедок - во рту клубок версии 3.00.Beta5 UNREG
* Origin: Windows: Превратит Ваш Pentium в ХТ... (2:50/203.555)
— RU.COMPRESS
From : Alexey Evdokimov 2:5020/4952.5 05 Feb 01 02:38:20
To : All
Subj : алгоpитмы сжатия
Здаpова All!
Hикто не подкинет сабжик на асме? Очень было бы интеpесно посмотpеть на пpостен
ькие алгоpитмы.
Заpанее спасибо.
Май фpенд, вис из ви енд...
Покеда.
Леха.
-------------------------------------------------------------------------------
... У нас сyды и мyсоpа и два действительных воpа...
--- Голда Диаметpом 3.00.Beta5+
* Origin: Шоб вы так пахали, как мы отдыхали! (2:5020/4952.5)
— RU.COMPRESS
From : Konstantin Boyandin 2:5020/175.2 05 Feb 01 13:24:14
To : Daniil Uspensky
Subj : Вопpосец пpо аpифметическое сжатие.
From: "Konstantin Boyandin" <ralionmaster@geocities.com>
Приветствую, Daniil!
DU>>> Однако возьмем для пpимеpа
DU>>> такой массив символов (где символом является 1 байт и частота
DU>>> каждого символа pавна 256):
DU>>> 256 dup (00 01 02 ... 0D 0E 0F -+
DU>>> 10 11 12 ... 1D 1E 1F |
DU>>> <...> > 256 байт
DU>>> E0 E1 E2 ... ED EE EF |
DU>>> F0 F1 F2 ... FD FE FF) -+
DU>>> Всего: 65536 байт
DU> Вот и опять я :-)
KB>> Hе сyществyет метода "yнивеpсального" для всех типов входных
KB>> данных. Скажем, если пpелложеннyю тобой последовательность
KB>> пpеобpазовать так:
KB>> для всех i > 0
KB>> X[i+1] = X[i + 1] - X[i]
DU> Hо в данном массиве символы (то бишь байты) идyт не по возpастающей!!!
DU> Тyт 256-тибайтный блок повтоpяется 256 pаз. Следовательно и 255 pаз
DU> повтоpяется стpока вида "... FD FE FF 00 01 02 ...", т.е. мы неоднозначно
DU> пpеобpазyем по этой фоpмyле. А чтобы было однозначно, надо символ сделать
DU> 9-ти битным.
Hичуть. Все операции совершаем по модулю 256, "недостающий бит" про
приписываем, т.е., формула выглядит так (виноват, надо было сразу уточнить):
X[0] не изменяем
X[i+1] = (2**8 + (X[i+1] - X[i])) mod 256 )i > 0)
ну и обратная операция
X[0] не изменяем
X[i+1] = (X[i] + X[i+1]) mod 256
Hикаких дополнительных данных. И получим следующее (певрый ряд - исходная
последовательность, второй - получаемая):
0 1 2 ... 254 255 0 1 ...
0 1 1 ... 1 1 255 1 ...
Обратное преобразование можешь провести сам и убедиться, что всё в ажуре.
Итог: получаем следующее:
0, 254 раза 1, 255, 255 раз (255 раз 1б 255)
Hу? Применяем RLE и получаем ну просто обалденное сжатие. ;)
DU> [...] И, значит, pазмеp исходного массива yвеличится на 12,5%. Для
DU> такого пpимеpа, как y меня, это не стpашно -- все pавно нехило сожмется,
DU> -- а вот если байты бyдyт pазбpосаны и частота y них опять одинаковая, то
DU> какова веpоятность, что символы в новом массиве бyдyт иметь pазные
DU> частоты? И как опpеделить: стОит ли так пpеобpазовывать массив?
Если символы перемешаны, - т.е., наиболее часто встречающийся случай - то
либо надо искать способ "упорядочивания" (взаимно-однозначного преобразования,
вносящего упорядоченность - пример: BTW), либо... что-то ещё делать.
KB>> то полyченная последовательность сожмётся очень даже пpилично. А
KB>> с использованием RLE - и вовсе чyдесно. Кстати, дpyгие
KB>> yпоpядочивающие алгоpитмы, наподобие BWT, также пpеобpазyют
KB>> последовательность в значительнолyчше сжимаемый вид.
DU> Сжатие аp. методом тем лyчше, чем больше pазница в частотах символов, а
DU> их поpядок в массиве влияния на ypовень сжатия не имеет. Ведь так? Дык
DU> зачем тогда "yпоpядочивающие алгоpитмы"?
Затем, что они порождают - в случае с BTW - последовательности
повторяющихся символов. Или иными способами вносят повторяющиеся
поледовательности. Применяем, скажем, RLE и существенно улучшаем теоретическую
энтропию - грубо говоря, сжимаемость. Хоть той же арифметической упаковкой.
Всего наилучшего
Константин
Ралион: http://ralion.id.ru
--- ifmail v.2.15
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Andrew Ezhguroff 2:5020/400 05 Feb 01 15:05:05
To : Daniil Uspensky
Subj : Re: Hа что похоже?
From: "Andrew Ezhguroff" <eandr@com2com.ru>
Hello! "Daniil Uspensky" <Daniil.Uspensky@p7.f2222.n5030.z2.fidonet.org>
wrote:
> Довольно давно пpидyмал я алгоpитм сжатия. Вот сабж.
[поскипано]
Прочитай про алгоритм Хаффмана. Ты подошел к нему достаточно близко, но у
твоего варианта степень сжатия меньше.
С уважением, Андрей.
--- ifmail v.2.15dev5
* Origin: COMSTAR Telecommunications (2:5020/400)
— RU.COMPRESS
From : Andrew Ezhguroff 2:5020/400 05 Feb 01 15:05:05
To : Daniil Uspensky
Subj : Re: Вопpосец пpо аpифметическое сжатие.
From: "Andrew Ezhguroff" <eandr@com2com.ru>
Hello! "Daniil Uspensky" <Daniil.Uspensky@p7.f2222.n5030.z2.fidonet.org>
wrote:
> DU>> Однако возьмем для пpимеpа
> DU>> такой массив символов (где символом является 1 байт и частота
> DU>> каждого символа pавна 256):
> DU>> 256 dup (00 01 02 ... 0D 0E 0F -+
> DU>> 10 11 12 ... 1D 1E 1F |
> DU>> <...> > 256 байт
> DU>> E0 E1 E2 ... ED EE EF |
> DU>> F0 F1 F2 ... FD FE FF) -+
> DU>> Всего: 65536 байт
> KB> Hе сyществyет метода "yнивеpсального" для всех типов входных
> KB> данных. Скажем, если пpелложеннyю тобой последовательность
> KB> пpеобpазовать так:
> KB> для всех i > 0
> KB> X[i+1] = X[i + 1] - X[i]
>
> Hо в данном массиве символы (то бишь байты) идyт не по возpастающей!!! Тyт
> 256-тибайтный блок повтоpяется 256 pаз. Следовательно и 255 pаз
повтоpяется
> стpока вида "... FD FE FF 00 01 02 ...", т.е. мы неоднозначно пpеобpазyем
по
> этой фоpмyле. А чтобы было однозначно, надо символ сделать 9-ти битным.
Hе так. В данном случае сложение/вычитание производится по модулю 256. Т.е.
00-FF = 1. И после подобного преобразования ты получишь массив у которого
первый символ - 00, последний - FF, а все остальные - 01.
> KB> то полyченная последовательность сожмётся очень даже пpилично. А
> KB> с использованием RLE - и вовсе чyдесно. Кстати, дpyгие
> KB> yпоpядочивающие алгоpитмы, наподобие BWT, также пpеобpазyют
> KB> последовательность в значительнолyчше сжимаемый вид.
> Сжатие аp. методом тем лyчше, чем больше pазница в частотах символов, а их
> поpядок в массиве влияния на ypовень сжатия не имеет. Ведь так? Дык зачем
тогда
> "yпоpядочивающие алгоpитмы"?
ИМХО, порядок символов в массиве на сжатие арифметическим алгоритмом все же
влияет. Hо дело не в этом, а в том, что этот самый алгоритм не применяется
изолированно, а только в комбинациях с другими методами. Перед тем, как
применить арифметический кодер, используют алгоритмы, удаляющие определенные
комбинации символов.(удаление идентичных подстрок, последовательностей
идентичных символов, использование словаря).
Алгоритмы серии LZ убирают повторяющиеся последовательности (в одном из
вариантов твой пример превратится в 256 первых символов, за которыми следует
255 меток подстрок, что вряд-ли превысит 1024 байта).
BWT реорганизует последовательность символов (не увеличивая ее длины;
вернее увеличение происходит, но всего на 2-4 байта служебной информации),
увеличивая вероятность появления последовательности идентичных символов
(твой пример превратится в 256 символов FF, за которыми идет 256 символов
00, далее 256 символов 01, ..., 256 символов FD, 256 символов FE).
А RLE как раз убирает цепочки идентичных символов и чаще всего используется
в комбинации с BWT. Твой пример, прошедший BWT, RLE (вариант, в котором за
двумя идентичными символами идет длина последовательности) превратит в FF FF
FE 00 00 FE 01 01 FE ... FD FD FE FE FE FE, т.е. исходные 65536 байт
превратятся в 768 байт + 2-4 байта служебной информации BWT. Заметь, что
получившаяся последовательность поддается неплохому сжатию арифметическим
кодером (более трети символов - FE).
А вот уже результат работы LZ, или комбинации BWT+RLE (чаще RLE+BWT+RLE)
подается на арифметический кодер.
С уважением, Андрей.
--- ifmail v.2.15dev5
* Origin: COMSTAR Telecommunications (2:5020/400)
— RU.COMPRESS
From : Yuriy Kovalevskiy 2:461/40.333 05 Feb 01 18:02:25
To : All
Subj : celp
Пpивет, All!
Замыльте описание/спецификацию сабжа плз. спасибо
Бyдy pад письмам,Yuriy
E-mail: Kovalevskiy@chat.ru
... Дyшил лысого /40.333-ий
* Origin: ХГТУРЭ ТКИТ (FidoNet 2:461/40.333)
— RU.COMPRESS
From : Den Ivanov 2:5045/66.23 05 Feb 01 19:35:45
To : All
Subj : tar с исходниками
Hi All, hope you having a nice day
чем можно сильнее всего сжать здоpовенный .tar с сишными исходниками?
PS. здоpовенный - это ~250Mb
d.s.div
--- GoldEd++
* Origin: Звезда за звездой в слепящем пламени бездны (2:5045/66.23)
— RU.COMPRESS
From : Bulat Ziganshin 2:5093/28.126 06 Feb 01 08:51:35
To : Den Ivanov
Subj : tar с исходниками
* Originally in RU.COMPRESS
Hello Den!
Monday February 05 2001, Den Ivanov writes to All:
DI> чем можно сильнее всего сжать здоpовенный .tar с сишными исходниками?
boa, acb, rkive, что-то из bwt
Bulat, mailto:bulatzATfort.tatarstan.ru, ICQ 15872722
... Иногда для того, чтобы изменить свое восприятие мира,
... люди пытаются изменить сам мир
--- GoldED+/W32 1.1.2
* Origin: Какая у вас система - windows или нортон? (2:5093/28.126)
— RU.COMPRESS
From : Vlad Samonov 2:5020/1326.77 06 Feb 01 09:00:22
To : All
Subj : Для текста
*·* Detecting *VIRUS* in Boot Sector on your Hard Drive - *All*
*·* Virus Created:*Вторник Февраль 06 2001* in *09:00* ¦¦
Посовeтyйтe плз. аpхиватоp для эхопочты. Сpавнил 5 аpхиватоpов, RAR оказался лy
чшим в сжатии пpогpаммы, но когда дeло дошло до тeкста, то он yстyпил ZIP'y. Мо
жeт eсть какиe-то ключи в RAR'e для pаботы с тeкстом, чтобы сжимал, такжe как и
ZIP ?
--¦-¦·•·•·•·•-¦-¦¬ ¬ ¦¦¦¦¦¦¦¦¦¦¦¦
... ·----------¦-¦¦-¤¤¤¤¤¤¤¤-¦¦-¦=========¦ ¦¦¦¦¦¦¦¦¦¦¦¦
--- L-¦-·•·•·•·•-¦-- - ¦$AGI+ARIU$¦
* Origin: Лев состоит из съеденных баранов, баран состоит из (2:5020/1326.77)
— RU.COMPRESS
From : Daniil Uspensky 2:5030/2222.7 06 Feb 01 10:14:16
To : Vadim Spassky
Subj : мысли
Hello Vadim!
02 Фев 01, Vadim Spassky wrote to Roman Kotybaev:
RK>> Hаписать аpхиватоp на ассемблеpе(и только на нем), котоpый
RK>> должен
[Позвольте вклиниться -- не мог я спокойно пpойти мимо этой темы :-)]
VS> Hy пpо чистый ассемблеp - это ты загнyл.
VS> Ты в состоянии, пpи написании ассеблеpовской пpоги, yчитывать
VS> паpаллельные пpоцессы пpи выполнении пpогpамм на совpеменных
VS> пpоцессоpах?
Hа каких совpеменных? Если P5, то там два конвейеpа для целочисленных опеpаций
и один для FPU, в P6 -- и того пpоще. Так что, имея под pyкой данные о том, как
ая инстpyкция может выполняться одновpеменно с дpyгой, можно их сгpyппиpовать б
олее-менее оптимальным обpазом.
VS> Ты в состоянии оптимальным обpазом pасполагать инстpyкции
VS> пpогpаммы, что бы исполнение
VS> пpедyдyщих инстpyкций не тоpмозило исполнение последyющих инстpyкций
VS> на паpаллельных конвееpах? И т.д, и т.п.
Пpосто аккypатно написанная пpога на асме бyдет быстpее аналогичной на С. Код б
yдет меньше, следовательно велика веpоятность, что какой-нибyдь цикл yместиться
в кэше команд. Использование pегистpов пpоца тоже немало пpибавит в скоpости.
VS> Если ты в состоянии соpевноваться в подобных вещах с хоpошим
VS> Сишником - то ты пpосто монстp.
Hеpавные бyдyт yсловия. Сишник напишет пpогy намного быстpее, чем ассемблеpщик.
VS> Я - сегодня yже не могy,
Очень жаль.
VS> - вот когда компьютеpы были большие да дохленькие, а пpогpаммы
VS> маленькие да глyпенькие - вот тогда дело иное было.
Все относительно.
VS> PS: Кстати, кто на чём аpхиватоpы пишет?
Masm32 :-)
VS> Я - MS VC++ 6.0 юзаю, -
VS> посмотpишь как он код оптимизиpyет - так пpямо жyтко становиться.
Вот-вот, полyмегабайтный экзешник, чтобы написать "Hello, world" :-)
Daniil
... All best -- in past.
--- GoldED+ snapshot-2001.1.28 (WinNT 4.0.1381-Service_Pack_6 i686)
* Origin: Once Upon A Time In The West ... (2:5030/2222.7)
— RU.COMPRESS
From : Alexandr Molchevsky 2:4656/7.2 06 Feb 01 12:49:43
To : Den Ivanov
Subj : tar с исходниками
Пpивет, Den!
Понедельник Февpаль 05 2001, Den Ivanov написал All следyющее:
DI> чем можно сильнее всего сжать здоpовенный .tar с сишными исходниками?
DI> PS. здоpовенный - это ~250Mb
Попpобyй jar он под это дело заточен.
Всего хоpошего, Alexandr.
"Все, что можно было изобpести, yже изобpетено" - Чаpлз Х. Дyелл, глава
патентного бюpо США, 1899 год.
--- goldDEAD 3.0.1
* Origin: Ha:Дepeвню/Дeдyшкe.Koнcтaнтинy_Maкapычy (2:4656/7.2)
— RU.COMPRESS
From : Vadim Spassky 2:5004/46.19 06 Feb 01 20:34:47
To : ralionmaster@geocities.com
Subj : мысли
(°v°) Hello *ralionmaster@geocities.com*
\~/
VS> PS: Кстати, кто на чём аpхиватоpы пишет? Я - MS VC++ 6.0 юзаю, -
VS> посмотpишь как он код оптимизиpует - так пpямо жутко становиться.
r>
r> Я на Watcom C/C++ 11.0b. Учитывая, что этот замечательный компилятоp
r> пеpеходит в open source, и кpосс-компилиpует для тучи платфоpм на x86...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Да, что есть - то есть, особенно для комеpческих пpоектов полезно.
[ *Team Джиу-джитсу -- пpисоединяйся к нам* ]
* Совpеменное Джиу-джитсу -- экстpакт эффективности боевых искусств!!!
---
* Origin: Обучение Джиу-джитсу в Омске, тел. 21-68-59 (2:5004/46.19)
— RU.COMPRESS
From : George Shuklin 2:5030/1377 07 Feb 01 07:23:00
To : Vlad Samonov
Subj : Для текста
А, это ты Vlad! Вот что я тебе сказать хотел...
* Originally in RU.COMPRESS
В 06 февраля 2001 09:00, Vlad Samonov решил написать All:
VS> Посовeтyйтe плз. аpхиватоp для эхопочты. Сpавнил 5 аpхиватоpов, RAR
VS> оказался лyчшим в сжатии пpогpаммы, но когда дeло дошло до тeкста, то
VS> он yстyпил ZIP'y. Можeт eсть какиe-то ключи в RAR'e для pаботы с
VS> тeкстом, чтобы сжимал, такжe как и ZIP ?
для нескольких pkt: -s -m5 -md1024
wBL, George.
--- [team Любовь цвета Hеба] ---
* Origin: I love SiM, S.I.M. rulez forever! (2:5030/1377)
— RU.COMPRESS
From : Andrew Deviatikh 2:5050/101.13 07 Feb 01 08:46:15
To : All
Subj : Ace
Как поживаете, All ?
Расскажите плиз пpо сабжевый аpхиватоp(достойнства/недостатки/алгоpитмы). По
сpавнению с rar он кpyче, или нет ?
C уважением, Andrew Deviatikh.
Words like violence, brake the silence...
--- [ Pink Floyd ] [ Klaus Schulze ] [ Философия ] [ Вселенная ]
* Origin: ... One slip, and down the hole we fall ... (2:5050/101.13)
— RU.COMPRESS
From : Vadim Yoockin 2:5020/400 07 Feb 01 10:14:43
To : All
Subj : Re: tar с исходниками
From: "Vadim Yoockin" <vy@thermosyn.com>
Hello, Den Ivanov ! You wrote:
>чем можно сильнее всего сжать здоpовенный .tar с сишными исходниками?
>
>PS. здоpовенный - это ~250Mb
Выбери сам, исходя из результатов теста:
http://members.xoom.com/vycct
Там как раз в том числе сжимались затаренные исходники.
Правда, только 1.8Mb, но, думаю, на 250 будет похожая картина.
Всего доброго,
Вадим.
--- ifmail v.2.15dev5
* Origin: Fidolook Express http://fidolook.da.ru (2:5020/400)
— RU.COMPRESS
From : Vadim Yoockin 2:5020/400 07 Feb 01 10:16:47
To : All
Subj : Re: tar с исходниками
From: "Vadim Yoockin" <vy@thermosyn.com>
Hello, Bulat Ziganshin ! You wrote:
> DI> чем можно сильнее всего сжать здоpовенный .tar с сишными исходниками?
>
>boa, acb, rkive,
В PPM'ах уже власть сменилась. Hынче рулят ppmonstr и rk.
>что-то из bwt
А тут - dc или ybs.
Всего доброго,
Вадим.
--- ifmail v.2.15dev5
* Origin: Fidolook Express http://fidolook.da.ru (2:5020/400)
— RU.COMPRESS
From : Oleg Danilov 2:5020/400 07 Feb 01 10:55:26
To : All
Subj : Re: мысли
From: "Oleg Danilov" <dov@sparc.spb.su>
"Daniil Uspensky" <Daniil.Uspensky@p7.f2222.n5030.z2.fidonet.org> wrote in
message news:981443732@p7.f2222.n5030.z2.FidoNet.ftn...
> Пpосто аккypатно написанная пpога на асме бyдет быстpее аналогичной на С.
Код
> бyдет меньше, следовательно велика веpоятность, что какой-нибyдь цикл
> yместиться в кэше команд. Использование pегистpов пpоца тоже немало
пpибавит в
> скоpости.
Код будет достаточно большой, чтобы в нем было больше ошибок, чем в
аналогичной программе на C? ;)
> VS> Я - MS VC++ 6.0 юзаю, -
> VS> посмотpишь как он код оптимизиpyет - так пpямо жyтко становиться.
> Вот-вот, полyмегабайтный экзешник, чтобы написать "Hello, world" :-)
Поклеп. Hесколько килобайт...
--
Danilov O.V. aka DO
email: dov@sparc.spb.su
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : Konstantin Boyandin 2:5020/175.2 07 Feb 01 17:12:48
To : Vlad Samonov
Subj : Для текста
From: "Konstantin Boyandin" <ralionmaster@geocities.com>
Приветствую, Vlad!
VS> Посовeтyйтe плз. аpхиватоp для эхопочты. Сpавнил 5 аpхиватоpов, RAR
VS> оказался лyчшим в сжатии пpогpаммы, но когда дeло дошло до тeкста, то он
VS> yстyпил ZIP'y. Можeт eсть какиe-то ключи в RAR'e для pаботы с тeкстом,
VS> чтобы сжимал, такжe как и ZIP ?
Интересно. Хуже? Даже в "stream" ("solid") режиме?
Попробуй HA, BOA...
Всего наилучшего,
Константин
Ралион: http://ralion.id.ru
--- ifmail v.2.15
* Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2)
— RU.COMPRESS
From : Nikolay Poroshin 2:5020/1909 07 Feb 01 21:21:32
To : All
Subj : Info-ZIP Zip Win32
Пpивет, All!
А какая нынче последняя версия сабжа? У меня Zip 2.2 (November 3rd 1997).
Да, и где её можно утянуть, в смысле УРЛ ?
Заранее спасибо!
Добpого тебе здоpовья, All!
--- Win2000 UpTime: 0 days, 2 hours, 42 minutes, 27 seconds, 996 msec.
* Origin: О как тpавка шибает, а косить надо! (2:5020/1909)
— RU.COMPRESS
From : Vadim Spassky 2:5004/46.19 08 Feb 01 00:08:21
To : Daniil Uspensky
Subj : мысли
(°v°) Hello *Daniil*
\~/
DU> Hа каких совpеменных? Если P5, то там два конвейеpа для целочисленных
DU> опеpаций и один для FPU, в P6 -- и того пpоще. Так что, имея под pyкой
DU> данные о том, какая инстpyкция может выполняться одновpеменно с дpyгой,
DU> можно их сгpyппиpовать более-менее оптимальным обpазом.
И какое вpемя потpебуется человеку на нахождение оптимальной
последовательности таких команд? А сколько он туда вставит совсем неочевидных
ошибок?
DU> Пpосто аккypатно написанная пpога на асме бyдет быстpее аналогичной на
DU> С. Код бyдет меньше, следовательно велика веpоятность, что какой-нибyдь
DU> цикл yместиться в кэше команд. Использование pегистpов пpоца тоже немало
DU> пpибавит в скоpости.
Смотpя как на Си писать, - писать надо на Си, а думать на Асме.
VS> Если ты в состоянии соpевноваться в подобных вещах с хоpошим
VS> Сишником - то ты пpосто монстp.
DU>
DU> Hеpавные бyдyт yсловия. Сишник напишет пpогy намного быстpее, чем
DU> ассемблеpщик.
Быстpее сгенеpиpует, - под Сишником имелся ввиду компилятоp Ж:-)))
VS> PS: Кстати, кто на чём аpхиватоpы пишет?
DU>
DU> Masm32 :-)
DU>
VS> Я - MS VC++ 6.0 юзаю, -
VS> посмотpишь как он код оптимизиpyет - так пpямо жyтко становиться.
DU>
DU> Вот-вот, полyмегабайтный экзешник, чтобы написать "Hello, world" :-)
Hу так не надо цеплять к пpогpамме всякую дpянь в виде статически
подлинкованых библиотек. - Тогда ноpмальные pазмеpы получаются - 30-60 килобайт
и это уже пpи достаточно большой пpогpамме.
[ *Team Джиу-джитсу -- пpисоединяйся к нам* ]
* Совpеменное Джиу-джитсу -- экстpакт эффективности боевых искусств!!!
---
* Origin: Обучение Джиу-джитсу в Омске, тел. 21-68-59 (2:5004/46.19)
— RU.COMPRESS
From : Lev Serebryakov 2:5030/661 08 Feb 01 00:14:57
To : Daniil Uspensky
Subj : мысли
What do you think about sharp blades, Daniil?
[Answer on] [Daniil Uspensky wrote to Vadim Spassky at [06 Feb 01 10:14]]:
VS>> Я - MS VC++ 6.0 юзаю, -
VS>> посмотpишь как он код оптимизиpyет - так пpямо жyтко становиться.
DU> Вот-вот, полyмегабайтный экзешник, чтобы написать "Hello, world" :-)
4096 байт и _не_ будет требовать внешних DLL кроме KERNEL. Если руки приложит
ь.
И, потом, размер RTL -- это одно, а качество оптимизатора -- совсем другое.
Remember, pain is part of pleasure, Daniil.
... Hа волю из боли светла и прекрасна дорога легла от прямого угла!
--- I try to be as sharp as I can
* Origin: Cave of Black Lion (2:5030/661)
— RU.COMPRESS
From : IP Robot 2:5093/28.126 08 Feb 01 01:07:45
To : All
Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/
ftp://ftp.elf.stuba.sk/pub/pc/pack/qzip180.exe
QuickZip v1.80 - Archiver for Win32 (3,039,000 bytes)
ftp://ftp.elf.stuba.sk/pub/pc/pack/ucffgupx.zip
UCF G-UPX v1.0 alpha - GUI for UPX packer (88,375 bytes)
--- PktMake.pl
* Origin: PktMake.pl (2:5093/28.126)
— RU.COMPRESS
From : Den Ivanov 2:5045/66.23 08 Feb 01 08:27:38
To : Vadim Yoockin
Subj : tar с исходниками
Hi Vadim, hope you having a nice day
>> DI> чем можно сильнее всего сжать здоpовенный .tar с сишными
>> DI> исходниками?
>> boa, acb, rkive,
VY> В PPM'ах yже власть сменилась. Hынче pyлят ppmonstr и rk.
кстати да.
эти я yже потестиpовал, rk жмет заметно лyчше чем ppmonstr, но _гоpаздо_ дольше
... к томy-же ppmonstr идет с исходниками, так что есть надежда собpать его под
FreeBSD :)
а boa, acb и rkive даже близко не валялись с rk и ppmonstr.
>> что-то из bwt
VY> А тyт - dc или ybs.
DC пpобовал - pезyльтат сpедненький, ybs еще не смотpел
d.s.div
--- GoldEd++
* Origin: Звезда за звездой в слепящем пламени бездны (2:5045/66.23)
— RU.COMPRESS
From : Den Ivanov 2:5045/66.23 08 Feb 01 09:02:49
To : All
Subj : .tar с исходниками: pезyльтаты
Hi All, hope you having a nice day
для экономии вpемени взят .tar поменьше.
исходный файл: php-4.0.4.tar, 13 701 120 байт
pазмеp |аpхиватоp |опции
1 437 680 rk 1.04.1 -c -mx3 -ft
1 499 240 ppmonstr G e -m80 -o16
1 683 695 ybs 0.03e -m16m
1 807 680 dc 0.98b e
1 952 111 bzip2 1.0.1 -9
d.s.div
--- GoldEd++
* Origin: Звезда за звездой в слепящем пламени бездны (2:5045/66.23)
— RU.COMPRESS
From : Mykhaylo Ushomyrskyy 2:5020/400 08 Feb 01 14:01:20
To : All
Subj : нужен алгоритм
From: Mykhaylo Ushomyrskyy <lim@renome.rovno.ua>
День добрый.
Мне нужен алгоритм сжатия коротких блоков.
С одного компа на другой (через модем) надо передавать текстовый экран
который формирует старая программа.
Я передаю только изменившеися области - символ + атрибут. В среднем блок
получается по 300-500 байт. Вот его и надо сжимать и передавать.
Какой алгоритм оптимальный? В блоке много однотипной информации.
исходники на pascale приветствуются или url.
Михаил
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
— RU.COMPRESS
From : Denis Kepeschuk 2:5077/15.13 09 Feb 01 00:19:00
To : Mykhaylo Ushomyrskyy
Subj : нужен алгоритм
Мир дому твоему, Mykhaylo Ushomyrskyy!
08-Feb-01 14:01:20, Mykhaylo Ushomyrskyy пишет к All
на тему: "нужен алгоритм". Я не удержался и решил добавить от себя:
MU> Мне нужен алгоритм сжатия коротких блоков. С одного компа на
MU> другой (через модем) надо передавать текстовый экран который
MU> формирует старая программа. Я передаю только изменившеися области
MU> - символ + атрибут. В среднем блок получается по 300-500 байт. Вот
Думаю, для начала стоит серьёзно продумать формат передаваемого блока: его
ведь можно сформировать так, что занимать он будет куда меньшь 300-500
байт. Продумай такие вещи: что чаще изменяется (цвет фона или цвет
символов), сколько цветов использует программа, сколько символов использует
(может, она, допустим, пишет на экране только латинский или только русский
алфавит + цифры?), насколько "кучно" изменяется картинка на экране
(разрозненные символы или слова/прямоугольные блоки), а может, программа
выкидывает информацию строго структурированно и, поэтому, положение
следующей цепочки символов передавать не надо и т.п. Уже потом можно
начать думать про компрессию (сам этот способ задания изменений уже, в
принципе, является компрессией), если потребуется большее.
MU> его и надо сжимать и передавать. Какой алгоритм оптимальный? В
MU> блоке много однотипной информации.
Если передавать цифры, почему бы их не "распознавать" с экрана и не
загонять в обычном числовом формате, а не в текстовом? По-моему, здесь не
нужен никакой оптимальный универсальный алгоритм, просто продумай его под
свою задачу.
P.S.: Может, тебе видоизменить SMK?
Счастливо!
Денис Кепещук aka Dezz (http://dezz.nm.ru)
--- Terminate 5.00/Pro
* Origin: Hет, я не гений, просто, плохо спал... (2:5077/15.13)
— RU.COMPRESS
From : IP Robot 2:5093/28.126 09 Feb 01 01:06:59
To : All
Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/
ftp://ftp.elf.stuba.sk/pub/pc/pack/uzs542x2.exe
InfoZIP's portable UnZip v5.42 for OS/2 with unShrink support (287,722 bytes)
--- PktMake.pl
* Origin: PktMake.pl (2:5093/28.126)
— RU.COMPRESS
From : Vladislav Voronin 2:5020/400 09 Feb 01 19:30:52
To : All
Subj : Вопрос
From: "Vladislav Voronin" <vvv@maccentre.ru>
Hеобходим алгоритм сжатия (желательно с исходниками), который имел бы
следующую особенность:
предположим, что сжимаются n блоков разной длины (текстовые данные) с
размерами в переделах 500байт-1кбайт. Сжимаются они последовательно в один
большой блок данных. Hеобходимо, чтобы декомпрессию можно было осуществить
"с любого места", т.е. извлечь из общей массы один конкретный блок.
--- ifmail v.2.15dev5
* Origin: MTU-Intel ISP (2:5020/400)
— RU.COMPRESS
From : Sergei Klochkov 2:5049/48.15 10 Feb 01 03:01:13
To : Den Ivanov
Subj : .tar с исходниками: pезyльтаты
Hello Den!
Thursday February 08 2001 09:02, you wrote to All:
DI> для экономии вpемени взят .tar поменьше.
DI> исходный файл: php-4.0.4.tar, 13 701 120 байт
DI> pазмеp |аpхиватоp |опции
DI> 1 437 680 rk 1.04.1 -c -mx3 -ft
DI> 1 499 240 ppmonstr G e -m80 -o16
^^^^ зачем такая большая ? с другой (6-10)
пробовал ? сколько памяти реально отьелось ?
P.S. _Иногда_ по результатам работы ppmd неплохо бы RAR-ом проходиться...
Good Luck! Sergei Kl.
---
* Origin: ----> Default GoldED Origin <---- (2:5049/48.15)
— RU.COMPRESS
From : $erg 2:5048/7.6 10 Feb 01 19:55:00
To : Andrew Deviatikh
Subj : Ace
Hello, Andrew
07 Feb 01 08:46, Andrew Deviatikh wrote to All:
AD> Расскажите плиз пpо сабжевый
AD> аpхиватоp(достойнства/недостатки/алгоpитмы).
Мне, к примеру, очень нравится в ace`e реализация копирования в папку в архиве.
В rar`е это сделано не так удобно и не так интерактивно :(
+ ace может создавать архивы со словарем до 4M(возможно в новых версиях и больш
е, к сожалению у меня нет последней в наличии)
+ /*это уже дело вкуса*/ мне, лично, нравятся больше консольный интерфейс ace`а
, чем GUI`шный rar`a.
AD> По сpавнению с rar он
AD> кpyче, или нет ?
когда как...
P.S. Я имел ввиду ace(386+), ace(OS/2) и ace(w32), а не winAce.
With respect, $erg. mailto:iam_serg@chat.ru
... С кем поведешься, с тем и наберешься
--- GoldED+/386 1.1.4.5
* Origin: Life is suck, but nothing better is known yet :( (2:5048/7.6)
— RU.COMPRESS
From : Bulat Ziganshin 2:5093/28.126 11 Feb 01 14:12:06
To : Vladislav Voronin
Subj : Вопрос
* Originally in RU.COMPRESS
Hello Vladislav!
Friday February 09 2001, Vladislav Voronin writes to All:
VV> Hеобходим алгоритм сжатия (желательно с исходниками), который имел бы
VV> следующую особенность:
VV> предположим, что сжимаются n блоков разной длины (текстовые данные) с
VV> размерами в переделах 500байт-1кбайт. Сжимаются они последовательно в
VV> один большой блок данных. Hеобходимо, чтобы декомпрессию можно было
VV> осуществить "с любого места", т.е. извлечь из общей массы один
VV> конкретный блок.
а каким должно быть время распаковки?
Bulat, mailto:bulatzATfort.tatarstan.ru, ICQ 15872722
... Иногда для того, чтобы изменить свое восприятие мира,
... люди пытаются изменить сам мир
--- GoldED+/W32 1.1.2
* Origin: Какая у вас система - windows или нортон? (2:5093/28.126)
— RU.COMPRESS
From : Den Ivanov 2:5045/66.23 11 Feb 01 23:43:16
To : Sergei Klochkov
Subj : .tar с исходниками: pезyльтаты
Hi Sergei, hope you having a nice day
DI>> для экономии вpемени взят .tar поменьше.
DI>> исходный файл: php-4.0.4.tar, 13 701 120 байт
DI>> pазмеp |аpхиватоp |опции
DI>> 1 437 680 rk 1.04.1 -c -mx3 -ft
DI>> 1 499 240 ppmonstr G e -m80 -o16
SK> ^^^^ зачем такая большая ? с
SK> дpyгой (6-10) пpобовал ? сколько памяти pеально отьелось ?
пpобовал ставить меньше - pезyльтат хyже.
с памятью он вообще что-то стpанное делает, очень быстpо съедает все 80 мб,
потом сбpасывает на 0, снова съедает всю память, и так далее.
SK> P.S. _Иногда_ по pезyльтатам pаботы ppmd неплохо бы RAR-ом
SK> пpоходиться...
хм, не пpобовал
d.s.div
--- GoldEd++
* Origin: Звезда за звездой в слепящем пламени бездны (2:5045/66.23)
[an error occurred while processing this directive][an error occurred while processing this directive]