Оказалось, что если, как описанно в книге сбрасывать, по одному байту, по всей видимости сразу же компрессирует этот байт. В результате никакой компрессии 559 Кб -> 528 Kб. Я ожидал, что GZipStream накапилвает эти байты в каком-то буфере и потом после заполнения этого буфера, компресирует данные и затем передает их в FileStream. Если в GZipStream передавать куски байтов, то компрессия на порядок лучше . Вопрос: можно ли как-то контроллировать буфер (размер, время сброса данных — типа AutoFlush = False и т.д) или для нормальной компрессии возможна только запись сегметами (например по 100 байт)?
Здравствуйте, SeLo, Вы писали:
SL>Оказалось, что если, как описанно в книге сбрасывать, по одному байту, по всей видимости сразу же компрессирует этот байт.
У тебя в коде где-то ошибка. Никакой разницы, блоками какого размера оперировать, нет.
Попробуй сначала написать программу, которая работает. А потом уже тренироваться в коэффициентах сжатия.
Как минимум, все потоки нужно закрывать:
int blockSize = 1; // вот этим будешь играть, меняя размер блокаstring inFileName = @"c:\test.txt";
string outFileName = @"c:\test_Compres.txt";
byte[] buffer = new byte[blockSize];
using(FileStream sourceFile = File.OpenRead(inFileName))
using(FileStream destFile = File.Create(outFileName)))
using(GZipStream compStream = new GZipStream(destFile, CompressionMode.Compress))
{
int actualSize;
while ((actualSize = sourceFile.Read(buffer, 0, blockSize)>0)
compStream.Write(buffer, 0, actualSize);
}
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Сжатие данных GZipStream
От:
Аноним
Дата:
06.04.08 10:20
Оценка:
Здравствуйте, SeLo, Вы писали:
SL>поскипано SL>Я ожидал, что GZipStream накапилвает эти байты в каком-то буфере и ..... SL>поскипано
Обычно чтобы не предугадывать как и что будет работать — читают MSDN, в крайнем случае берут рефлектор и смотрят напрямую.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, SeLo, Вы писали:
SL>>// Мой вариант (тестовый, плз. без критики) SL>>byte[] byteArray = new byte[sourceFile.Length]; SL>>sourceFile.Read(byteArray, 0, (int)sourceFile.Length); SL>>compStream.Write(byteArray, 0, byteArray.Length); SL>>// 559 -> 13
AVK>Без критики не получится. Кто исходный поток в начало перематывать будет?
S>У тебя в коде где-то ошибка. Никакой разницы, блоками какого размера оперировать, нет.
Пример проверил: в точности как в книге, ошибок нет
S>int blockSize = 1; // вот этим будешь играть, меняя размер блока
Получается размер буфера все-таки влияет на коэффициент сжатия. Именно это мне и было интересно
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, SeLo, Вы писали:
SL>>поскипано SL>>Я ожидал, что GZipStream накапилвает эти байты в каком-то буфере и ..... SL>>поскипано А>Обычно чтобы не предугадывать как и что будет работать — читают MSDN, в крайнем случае берут рефлектор и смотрят напрямую.
Вот в MSDN говориться что WriteByte по сути вызывает метод Write, который (извиняюсь немецкий мне роднее):
Der verwendete Puffer ist ein interner Puffer. Der Schreibvorgang wird möglicherweise nicht unmittelbar ausgeführt, wird jedoch gepuffert, bis die Puffergröße erreicht ist oder bis die Flush-Methode oder die Close-Methode aufgerufen wird.
ЗДесь говориться, что есть внутренний буфер. Запись не будет непосредственно выполненна, а проверенно заполненн ли буфер. Также можно выписать данные методо Flush и Close.
Но какой размер буфера? и как на этот размер влиять?
Re[3]: Сжатие данных GZipStream
От:
Аноним
Дата:
06.04.08 10:49
Оценка:
Здравствуйте, SeLo, Вы писали:
SL>Вот в MSDN говориться что WriteByte по сути вызывает метод Write, который (извиняюсь немецкий мне роднее):
у GZipStream нет реализации ReadByte\WriteByte
ReadByte Reads a byte from the stream and advances the position within the stream by one byte, or returns -1 if at the end of the stream. (Inherited from Stream.)
WriteByte Writes a byte to the current position in the stream and advances the position within the stream by one byte. (Inherited from Stream.)
SL>>Вот в MSDN говориться что WriteByte по сути вызывает метод Write, который (извиняюсь немецкий мне роднее):
А>у GZipStream нет реализации ReadByte\WriteByte
Если я не правильно выразился, то именно это я и имел ввиду. В Классе Stream эти методы создают массив с одним элементом и вызвают Read/Write
Здравствуйте, SeLo, Вы писали: S>>int blockSize = 1; // вот этим будешь играть, меняя размер блока SL>Получается размер буфера все-таки влияет на коэффициент сжатия. Именно это мне и было интересно
Охренеть дайте две. Ты прав, посыпаю голову пеплом. Век живи, век учись.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Сжатие данных GZipStream
От:
Аноним
Дата:
06.04.08 11:28
Оценка:
Здравствуйте, SeLo, Вы писали:
Вроде понял о чем речь
Это потоковый класс, соответсвенно сколько дашь, столько и сожмёт.
О чём и говорится в описании к классу:
The compression functionality in DeflateStream and GZipStream is exposed as a stream. Data is read in on a byte-by-byte basis, so it is not possible to perform multiple passes to determine the best method for compressing entire files or large blocks of data.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, SeLo, Вы писали:
А>Вроде понял о чем речь А>Это потоковый класс, соответсвенно сколько дашь, столько и сожмёт. А>О чём и говорится в описании к классу: А>
А>The compression functionality in DeflateStream and GZipStream is exposed as a stream. Data is read in on a byte-by-byte basis, so it is not possible to perform multiple passes to determine the best method for compressing entire files or large blocks of data.
Это описывает лишь суть алгоритма сжатия (как и распаковки), который не предусматривает многократного прохода по данным. Данный сжимаются налету, и потому вписываются в идиалогию потоков (Stream), от которого и наследуются. Не более. Наличие буфера этот подход не исключает, без него по сути и не обходится. Вот просто выписывание сжатых данных в поток могли бы сделать регулиремым (зачем-то же Flush метод придумали). У меня вообще такое впечатление, что класс на MS не доработали. Идея хорошая, но не доработали.
Здравствуйте, akasoft, Вы писали:
A>Хм. И какой оптимальный размер буфера? . Эксперименты не дали значительного улучшения коэффициента сжатия при увеличении объема буфера за 1 килобайт. Но размер входного окна у енкодера = 16646 байт, что бы это ни значило.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, SeLo, Вы писали:
SL>Это описывает лишь суть алгоритма сжатия (как и распаковки), который не предусматривает многократного прохода по данным. Данный сжимаются налету, и потому вписываются в идиалогию потоков (Stream), от которого и наследуются. Не более. Наличие буфера этот подход не исключает, без него по сути и не обходится. Вот просто выписывание сжатых данных в поток могли бы сделать регулиремым (зачем-то же Flush метод придумали). У меня вообще такое впечатление, что класс на MS не доработали. Идея хорошая, но не доработали.
Flush() это метод стрима. Идеология правильная. Сам создавай входной стрим, а уж как ты его будешь запонять это твои проблемы. Для сжатия данных нужен входящий поток и не более. Он сам будет брать данные нужными для него порциями.
и солнце б утром не вставало, когда бы не было меня
S>Flush() это метод стрима. Идеология правильная. Сам создавай входной стрим, а уж как ты его будешь запонять это твои проблемы. Для сжатия данных нужен входящий поток и не более. Он сам будет брать данные нужными для него порциями.
и...? или вы меня недопоняли, или я. какими порциями? где это регулируется? почему результыты компресси такие разные? понятно что идеалогия привильная, но вот класс этот GZip как-то криво реализованн
Здравствуйте, SeLo, Вы писали:
S>>Flush() это метод стрима. Идеология правильная. Сам создавай входной стрим, а уж как ты его будешь запонять это твои проблемы. Для сжатия данных нужен входящий поток и не более. Он сам будет брать данные нужными для него порциями.
SL>и...? или вы меня недопоняли, или я. какими порциями? где это регулируется? почему результыты компресси такие разные? понятно что идеалогия привильная, но вот класс этот GZip как-то криво реализованн
Прошу прощения. Замкнуло. Обычно (для компресси декомпрессии) На вход подается стрим, а не массив байт (что более логично). В этом его и не доделанность.
и солнце б утром не вставало, когда бы не было меня
Интересно а как с такой идеологией чтения части компрессированных данных? В лучшем случае контрольная сумма не сойдется. Недавно случай с 7 zip был. Данные были заархивированы по частям. Так вот если часть была не полной, или вообще отсутствовала, никаких предупреждений на этот счет не было. Ну а вообще при компресии чем больше данных подаешь тем больше коэффициент компресси и получишь (там как в алгоритме LZRW плавающее окно испльзуется), и никаких предварительных накоплений не происходит. Лучше было добавить два метода СжатьПоток, и РазжатьПоток, все таки объемы, могут быть большими
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали: S>Интересно а как с такой идеологией чтения части компрессированных данных?
Никак. Чтение всегда восстанавливает исходный поток. S>Ну а вообще при компресии чем больше данных подаешь тем больше коэффициент компресси и получишь (там как в алгоритме LZRW плавающее окно испльзуется), и никаких предварительных накоплений не происходит.
Вот это мне не вполне понятно. Я в компрессии слабо разбираюсь, но мне казалось, что потоковые алгоритмы на то и потоковые, что должны работать независимо от того, какими блоками подаются входные данные. S>Лучше было добавить два метода СжатьПоток, и РазжатьПоток, все таки объемы, могут быть большими
И как бы это работало? Поток — штука пассивная. Ты заталкиваешь в него данные, а не другой поток. Представь себе, что ты хочешь передавать пожатые данные по сети, при этом не делая 100% буферизацию. Ты заворачиваешь исходящий поток в GzipStream и запихиваешь в него данные по мере готовности. Эта готовность может происходить блоками произвольного объема. А в итоге получаешь какую-то нездоровую зависимость непонятно от чего.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Посмотрел DeflateStream там в Dispose(bool disposing)
вызывается deflater.Finish(this.buffer) который и заканчивает запись исходного кодировщика.
Но !!! сжимать он начинает сразу, поэтому чем больше ты подашь на вход данных тем больше сожмет, т.к. используется плавающее окно а в выходной файл записывается смещение этого окна и длина строки, поэтому чем дленее строка и есть ее значение в плавающем окне тем коэффициент сжатия больше.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>Вот это мне не вполне понятно. Я в компрессии слабо разбираюсь, но мне казалось, что потоковые алгоритмы на то и потоковые, что должны работать независимо от того, какими блоками подаются входные данные.
Вообще говоря, в сжатии по Хаффмэну очень важно, что выбирается за единицу алфавита и насколько удачно делается этот выбор. Из общих соображений понятно, что вполне возможны варианты, когда выбор единицы алфавита делается исходя из куска доступных данных, что неразрывно связано с размером буфера.
Здравствуйте, Кэр, Вы писали:
Кэр>Вообще говоря, в сжатии по Хаффмэну очень важно, что выбирается за единицу алфавита и насколько удачно делается этот выбор.
Только в GZip используется не сжатие по Хаффману.
Кэр> Из общих соображений понятно, что вполне возможны варианты, когда выбор единицы алфавита делается исходя из куска доступных данных, что неразрывно связано с размером буфера.
Попробуй поинтересоваться как работает тот же LZW.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1074 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
Кэр>>Вообще говоря, в сжатии по Хаффмэну очень важно, что выбирается за единицу алфавита и насколько удачно делается этот выбор. AVK>Только в GZip используется не сжатие по Хаффману.
Это был ответ на общую фразу по потоковым алгоритмам сжатия, цитата была приведена.
Кэр>> Из общих соображений понятно, что вполне возможны варианты, когда выбор единицы алфавита делается исходя из куска доступных данных, что неразрывно связано с размером буфера. AVK>Попробуй поинтересоваться как работает тот же LZW.
Всенепременно. Что конкретно смотреть в этом алгоритме?
Здравствуйте, _Morpheus_, Вы писали:
_M_>Здравствуйте, Serginio1, Вы писали:
S>>Посмотрел DeflateStream там в Dispose(bool disposing)
_M_>то что жмет сразу после записи, это хорошо, плохо вот именно с DeflateStream, см. тут
(Нужно же дать работу сторонним разработчика )
Жмет в методе write сразу поданный в него буфер.
Ну когда подают по одному байту, то не есть хорошо. Здесь как раз хофман хорошо подходит.
Но LZRW и чем он большую общую последовательность найдет в плавающем окне тем лучше для коэффициента сжатия.
Проще одним блоком все подать. А лучше из готового стрима в стрим.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, SeLo, Вы писали:
SL>Сжатие данных не работает так как хотелось бы:
и действительно, не работает. давненько хотел написать, да все рука не поднималась по-аглицки...
public static byte[] CompressData(byte[] data) {
if(data != null) {
using(MemoryStream ms = new MemoryStream()) {
using(GZipStream deflater = new GZipStream(ms, CompressionMode.Compress, true)) {
deflater.Write(data, 0, data.Length);
}
return ms.ToArray();
}
}
else {
return null;
}
}
[Test/*, Ignore("CompressionUtils.CompressData compresses 1Mb of data into 1.6Mb!!! of compressed data")*/]
public void TestCompressionRate() {
byte[] nonCompressableSource = new byte[1024 * 1024];
System.Random rnd = new Random();
rnd.NextBytes(nonCompressableSource);
byte[] compressedNonCompressableSource = CompressionUtils.CompressData(nonCompressableSource);
Assert.IsTrue(compressedNonCompressableSource.Length < nonCompressableSource.Length,
"{0} : {1}", compressedNonCompressableSource.Length, nonCompressableSource.Length);
}
-----------------
compressedNonCompressableSource.Length 1610496 int
nonCompressableSource.Length 1048576 int
-----------------
ну и кто мне объяснит, что я делаю не так??? почему и 1Мб получается 1.6Мб ????
поток в результате получается вполне читабельный для распаковщиков (pkunzip), но те же самые упаковщики (pkzip) делают из этого потока 1 049 004 bytes.
почему?
Здравствуйте, Dan Ignatov, Вы писали:
DI>Здравствуйте, SeLo, Вы писали:
SL>>Сжатие данных не работает так как хотелось бы:
DI>и действительно, не работает. давненько хотел написать, да все рука не поднималась по-аглицки...
Здравствуйте, Dan Ignatov, Вы писали: DI>ну и кто мне объяснит, что я делаю не так??? почему и 1Мб получается 1.6Мб ????
Потому что случайные данные плохо поддаются сжатию. DI>поток в результате получается вполне читабельный для распаковщиков (pkunzip), но те же самые упаковщики (pkzip) делают из этого потока 1 049 004 bytes. DI>почему?
Потому, что умные упаковщики, видя такую хрень, переключаются на метод компрессии "store".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Не читайте книги в которых стримы и IDisposable используют без оператора using.
Re[3]: Сжатие данных GZipStream
От:
Аноним
Дата:
10.07.08 12:28
Оценка:
Здравствуйте, Sinclair, Вы писали:
S>Потому что случайные данные плохо поддаются сжатию.
это-то как раз очевидно... S>Потому, что умные упаковщики, видя такую хрень, переключаются на метод компрессии "store".
хм.. не знал, что GZipStream не учитывает подобные данные...
спасибо.
Thanks,
Dan
Re[2]: Сжатие данных GZipStream
От:
Аноним
Дата:
20.07.08 09:03
Оценка:
A>Не читайте книги в которых стримы и IDisposable используют без оператора using.
А как быть с асинхронной моделью с функцией обратного вызова? использовования using — не панацея
. Эксперименты не дали значительного улучшения коэффициента сжатия при увеличении объема буфера за 1 килобайт. Но размер входного окна у енкодера = 16646 байт, что бы это ни значило.
Обычно (для компресси декомпрессии) На вход подается стрим, а не массив байт (что более логично). В этом его и не доделанность.
)
