[C#] Можно ли получить сжимаемость файла не сжимая оригинал?
del
Попробуй поискать информацию о транзакциях NTFS.
Померять энтропию файла, взвешенно, с учетом частотных характеристик выбранного алгоритма компрессии. 
Смотри расширение - если .txt то сжимается хорошо, если .exe - то не очень 
кстати, энтропия — это не мера упорядоченности
кстати, энтропия — это не мера упорядоченностиТермин взят из термодинамики, по определению, энтропия - мера беспорядка.
В сжатии информации и в термодинамике энтропия обозначает практически одно и то же, даже формулы почти совпадают. И смысл общий.
Другое дело, что на практике совет по измереню энтропии для заданного алгоритма означает реализацию большей части алгоритма с последующим измерением параметров. Возможно, проще и быстрее действительно сжать и посмотреть размер.
Другое дело, что на практике совет по измереню энтропии для заданного алгоритма означает реализацию большей части алгоритма с последующим измерением параметров. Возможно, проще и быстрее действительно сжать и посмотреть размер.
Спасибо за идею, вроде что-то в МСДН-е нашел - надо будет попробовать 
Померять энтропию файла, взвешенно, с учетом частотных характеристик выбранного алгоритма компрессии.
А как насчет конкретики?
Смотри расширение - если .txt то сжимается хорошо, если .exe - то не очень
Действительно, это идея как-то до меня сразу не дошла
Но наверное все таки надо использовать этот вариант только как один из вариантов проверки - то же расширение .dat - только по нему абсолютно ничего нельзя сказать об эффективности сжатия.
Как минимум, неплохо было бы проверять еще и заголовки файлов - есть ли в C#/.Net/WinAPI что-то готовое для этого?
Или мб какая библиотека есть сторонняя?
Другое дело, что на практике совет по измереню энтропии для заданного алгоритма означает реализацию большей части алгоритма с последующим измерением параметров.
А можно ссылочку? Хотелось бы получить представление об этом
На compression.ru выложили свою книжку по сжатию данных. Там и про энтропию, и про конкретные алгоритмы.
MSDN
Но работает только в Vista
Но работает только в Vista
Ватолин Д., Ратушняк А., Смирнов М., Юкин В. Методы сжатия данных. Устройство архиваторов, сжатие изображений и видео. - М.: ДИАЛОГ-МИФИ, 2002. - 384 с.
Это она?
Но работает только в Vista
Спасибо, я это находил.
Но вот только Висту ставить только ради этого не хочется
В принципе я находил, что можно использовать файл при открытии/создании файла, который позволяет делать транзакции, и там не было написано, что это только про Висту.
Или не по Висте такого в принципе быть не может?
А 2003-й сервер в этом смысле заменой не является?
Здесь транзакции NTFS обозначены как новая возможность Vista.
Да, она.
Очень жаль будет, если это только для Висты
Надо будет проверить.
Надо будет проверить.
Спасибо, почитаю
По области, кстати, до -10.
Кстати, win-rar может оценивать файлы довольно быстро при этом реально не сжимая их. Как он это делает не знаю
Наверняка просто небольшине части пробует сжимать и смотрит на эффективность.
Все равно он врал и в следующих версиях эту фичу убрали.
Все равно он врал и в следующих версиях эту фичу убрали.
Для Винрара это мб и критично, но в данном случае не очень.
Тут скорее интересует принципиальная сжимаемость/несжимаемость файла.
У mp3, avi, jpeg и подобных им файлов какой кусок ни возьми - он все равно будет плохо сжиматься.
То есть если кусок файла сжимается хорошо, то скорее всего его можно сжать и он неплохо сожмется.
Часть файла сжать стандартными средствами скорее всего нельзя или как-то можно?
Еще опять становится актуальным вопрос об организации всех этих операций в памяти (без записи на диск - тем более для этого она и не нужна).
Как это можно сделать? Ну без создания рамдиска не получится?
Тут скорее интересует принципиальная сжимаемость/несжимаемость файла.
У mp3, avi, jpeg и подобных им файлов какой кусок ни возьми - он все равно будет плохо сжиматься.
То есть если кусок файла сжимается хорошо, то скорее всего его можно сжать и он неплохо сожмется.
Часть файла сжать стандартными средствами скорее всего нельзя или как-то можно?
Еще опять становится актуальным вопрос об организации всех этих операций в памяти (без записи на диск - тем более для этого она и не нужна).
Как это можно сделать? Ну без создания рамдиска не получится?
читал раньше, что rar точно смотрит на расширение, но только что сам проверил и оказалось не так
Довольно простой способ, который однако может сработать во многих случаях - простой подсчет сколько раз встречается каждый символ. У уже пожатых файлов вроде видео, сжатого звука и архивов распределение будет близко к равномерному. А у текстов всяких весьма неравномерное. Можно посчитать классическую шенноновскую энтропию, уже что-то даст.
Если хочется чего-то покруче, можно посмотреть на то, как FreeArc определяет типы файлов и группирует их. Кажется, там на хаскеле эта логика была сделана...
Если хочется чего-то покруче, можно посмотреть на то, как FreeArc определяет типы файлов и группирует их. Кажется, там на хаскеле эта логика была сделана...
У mp3, avi, jpeg и подобных им файлов какой кусок ни возьми - он все равно будет плохо сжиматьсяНу-ну.
Метаданные сожмутся всего лишь чуть хуже обычного текста.
Можно посчитать классическую шенноновскую энтропию, уже что-то даст.Собственно, как я понимаю, это и будет минимальный размер после сжатия без потерь.
Нет, не будет. Большинство реальных алгоритмов жмут сильнее, чем это описывает простая формула энтропии. В этой формуле все символы как бы независимо сжимаются, а в реальных алгоритмах зависимости между ними эксплуатируются очень активно. В результате формула энтропии для текста может пообещать сжатие в полтора раза, а простой zip сожмет его во все 4.
В этой формуле все символы как бы независимо сжимаются, а в реальных алгоритмах зависимости между ними эксплуатируются очень активно.Э-э-э, а энтропия учитывает только частоту символов, без структуры? Блин, а я забыл...
Да, в шенноновсой формуле только частота символов. Почему и говорил, что для оценки реального алгоритма придется его почти целиком реализовать..
Э-э-э, а энтропия учитывает только частоту символов, без структуры? Блин, а я забыл...Это виндузятники, у них альтернатичное мышление!
Да, в шенноновсой формуле только частота символов.Насколько я понял ш-формулу, там говорится об элементарных событиях, что, вообще говоря, не есть то же, что символы.
В любом случае, ее можно обобщить для коррелирующих символов.
Так что тебе люркать.
И что такое "элементарное событие" для текста? А для произвольного файла?
А для произвольного файла?Как известно, нет алгоритма, хорошо сжимающего произвольные файлы.
более того, нет универсального алгоритма, сжимающего хоть на сколько-нибудь любой случайный файл
Ну это как бы очевидно, для этого вообще ничего знать не надо 
тебе дать определение или достаточно просто ткнуть пальцем и сказать: "вот пример элементарного события, не являющегося символом в программерско-типографском смысле слова"? Например, за редким исключением, "q" - не элементарное событие в тексте. Элементарным событием было бы "qu".
Например, за редким исключением, "q" - не элементарное событие в тексте. Элементарным событием было бы "qu".Скажем так, 'q' - элементарное событие, но гораздо более редкое, чем "qu"...
Да нет, просто на пальцах расскажите, что считаете элементарным событием.
Ведь никто не мешает оными считать биты. Или слова..
Ведь никто не мешает оными считать биты. Или слова..
элементарные события должны быть статистически независимы, насколько я понимаю
Тогда их вряд ли вообще возможно выделить в файле.
разве это претензия ко мне? никто вас не заставлял пользоваться приближениями, которые вы сами считаете неприменимыми
И не ко мне. Я изначально про символы говорил, там все просто, понятно и работает.
А мне тут про события всякие начали говорить..
Я изначально про символы говорил, там все просто, понятно и работает.А мне тут про события всякие начали говорить..
В данном случае элементарное событие - определённая буква на определённом месте.
Если определять так, то такие события сложно считать независимыми. И как определить их вероятность? Чтобы найти энтропию нужно знать вероятности.
Элементарное событие здесь - весь текст. Попался текст "тест" - одно событие, "привет" - другое, "маыпры ырпы рерырпцу" - третье.
Но это никак не поможет сосчитать энтропию.
Но это никак не поможет сосчитать энтропию.
Низач0т. Текст - это поток событий.
Если не рассматривать весь текст, ты не добьёшься независимости событий.
Оставить комментарий
durka82
Когда-то я спрашивал тут про то, ?Вот еще вопрос в развитие этой темы.
В чем проблема:
Если просто пробовать сжимать все подряд, а потом отказываться от сжатия уже сжатого (того, что плохо сжимается должна значительно ухудшаться фрагментированность данных на диске
Поэтому было бы идеально сначала попробовать сжать, а потом принять сжатие или отказаться от него.
Можно ли это как-то сделать средствами винды?
Или это нужно как-то самому реализовывать?
Если это реализовывать, то как лучше?
Например можно каждый файл копировать в новое место (в идеале на РАМ-диск - как это вообще можно реализовать пробовать его там сжимать и только если сжатие успешно либо копировать сжатый вариант на место оригинала (если замещать один файл другим, будут ли они физически начинаться в одном месте? либо сжимать заново оригинал (но думаю, что этот вариант хуже, так как сжатие приходится делать 2 раза
Спасибо за внимание