Архивация.NEW!

Цитата evilive, 18.08.02, 02:21:07

Я об этом тоже думал, но проблема то в том что изображения не всегда состоят всего из двух цветов  :-/, как это бывает в японских кроссвордах. Разве что создавать несколько матриц для трех цветов и альфа канала(или скорее каналлов для каждого цвета). Но и тут есть проблемы.

mozhno obojtis' 2umja matricami 1 pikseli 2 cvet sootvetstvueshego pikselja v 1oj matrice

Сообщение отредактировано: Outlander - 19.08.02, 09:45

Цитата Outlander, 19.08.02, 13:43:59

mozhno obojtis' 2umja matricami 1 pikseli 2 cvet sootvetstvueshego pikselja v 1oj matrice

 Во-первых я что-то не понимаю как это можно в матрице, составленной по принципу японского кроссворда, менять какие-то значения в диапазоне большем чем 2 значения (клеточка либо черная, либо белая, все, других вариантов быть не может), так что как ты собираешься записывать цвет каждого пикселя в одной матрице я так и не понял.
 Во-вторых, что значит твое высказывание по поводу 1-ой матрицы которую ты собрался использовать для записи пикселей, каких пикселей и что значит для тебя вообще это слово...???
 И наконец в-третьих если описывать цвет каждого пикселя, то где же тут сжатие данных, в обычном BMP-формате при описании картинки получится меньший размер (в нем не надо строить никаких японских кроссвордов, а просто попорядку описываем каждый пиксель ).

Цитата DimA2, 19.08.02, 11:16:05

Как вы оцениваите мои идеи?

По поводу твоих идей, DimA2, насчет матриц третьего порядка, боюсь что при разворачивании (т.е. разархивации) в первоначальное состояние невозможно будет проконтролировать порядок коэффициентов при x,y,z. Ведь от перемены мест слогаемых сумма не меняется .

Кажись придумал?!! 8) Аж синий от осинения

число Х:=255255255255255255255255255(9 символов 255, т.е. возможный максимум.)


Находим(Расчитываем)  1 число - число, при возведении в степель 255 дающее >X(Находится легко)

Находим  2 число - число < число 1

3,4,5 число  - думаю гдето 2

Все эти числа(1,2,3,4,5) - константы, и всегда неизменны!

Что выходит?

Архив.:
Находим степень1, при которой чило1 в этой степени < X.(Максимально приближено)

Х-число1^степень1:=остаток1(Всегда недРОБНЫЙ!)

остаток1-число2^степень2:=остаток2

остаток2-число3^степень3:=остаток3
остаток3-число4^степень4:=остаток4
остаток4-число5^степень5:=остаток5;

Так!  остаток5 - вот что нам по сути и нужно ухитрится записать 2-3 символами(числами по 255!)

В результирующем(Заархив.) файле:
степень1,степень2,степень3,степень4,степень5,2-3(символы,показ остаток5)!!!

Разархив. наоборот!

ЗЫ!

Ну как? Вопросы...

В итоге 9 символов заархивируются в 8!!!ВСЕГДА!!!!

Ошибок в алгоритме не найдено, в теории тоже.


Т.е. применяя несколько раз алгоритм к одному и тому-же файлу получаем, что файл любых размеров умещается в 9+0..8(неархив. остаток!)

А че такое число X ? Я не понял...

2Dima2 ты статью ,на которую давали линк прочитал?

ладно, предлагаю тебе попробовать реализовать твой алгоритм на практике.
вот тебе число
123 098 435 567 032 006 435 231  856
(9 символов) предлагаю его запаковать в 8 по твоему алгоритму.
ЗЫ, число1 наверное будет равно 2, тк 2 в степени 255 больше число, которое может быть записано в 9 байт (9 байт - 56 бит, следовательно твое числ Х <= 2 в степени 56, а 2 в степени 255 всяко больше 2 в степени 56\%) )

Сообщение отредактировано: Demo_S - 20.08.02, 21:48

Хм...

Вчера алгоритм свой я реализовал, но результаты... оказаливь немного не те...

Сегодня попробую не
остаток1-число2^степень2:=остаток2(после каждой операции на 2 порядка сокращение), а

остаток1/число2^степень2:=остаток2


И ещё... почему при ВЫЧИТАНИИ получается дРоБнОе число? nnn.5

Dr_Freemen! Число Х - это ASCII коды дивети чисел.

Насчёт методов сжатия графики:
Часто бывает что в картинке в 256 цветов получается несколько символов подряд:

abcdefg или 123456 или наоборот gfedcba, но факт то, что почему бы их не записать переходом? от 1 до 6.

Незнаю, может ясказанул, чего не понял, н идея хороша! а есл графика в 24 а не 256 цветов, её можно разложить по цветам, r g b, каждый опять же от 0 до 255!

Подумайте на эту тему, сам всю ноч кшмарил, кто что-лбо придумает, пишите тут!

Ребята!!!!
ау!
почитайте сначала какие-нить алгоритмы сжатия, тот же RLE или LZW, доки+примеры могу дать
а то просто заново изобретаете велосипед, причем очень кривой!.
ЗЫ извиняюсь если кого обидел
ЗЗЫ кстати, 2purpe, я когда то кидал сюда(тебе в смысле) сорс архиватора + дока, оно к сожалению так и не появилось, может кинуть снова?.

Сообщение отредактировано: Demo_S - 23.08.02, 18:26

Цитата fog, 15.08.02, 10:44:32

файл есть оооочень болльшое число, находим ближайшее простое
в качестве результата сжатия записываем порядковый номер этого числа
1   2
2   3
3   5
4   7
5   11
6   13
7   17
...
и разницу между исходным числом и ближашим простым
для 32 бит сжатия нет вообще, а дальше... кто его

Пусть f - очень большое число (последовательность нулей и единиц архивируемого файла). Вы хотите представить его в виде
  f = p + d,
где p - ближайшее простое число, d - добавка. Вы хотите в "архивном" файле хранить числа {n,d}, где n - порядковый номер простого числа p. Поскольку  n < p, значит, казалось бы, места должно занимать меньше. На самом деле это не так. Дело в том,
что с ростом p число n тоже растет достаточно быстро (простых чисел много). Поэтому сумма размеров чисел n и d не будет заметно меньше размера f.

Вместо доказательства, давайте рассмотрим еще более "выгодный" случай. Представим число f в виде "полного квадрата" плюс добавка
 f = g*g + d.
Размер числа g в два раза меньше размера числа f. Значит, если добавка d будет не большой, то мы "заархивируем" почти в два раза!!! Но не тут-то было. Дело в том, что в большинстве случаев размер добавки d тоже равен половине размера числа f (это я оставлю без доказательства), и сохранение вместо f чисел {g,d} не приводит к уменьшению размера. Количество простых чисел растет быстрее чем квадратный корень, поэтому "архивация" f = p + d, тем более не эффективна.

Предлагаю воспользоваться принципом НАОБОРОТ. Будем считать, что число f есть  результат подобного сжатия (g*g+d), при этом число f оказывается с большим количеством знаков, чем изначальное. Теперь проводим операцию РАССЖАТИЯ и получаем исходное число с меньшим количеством знаков. Т.е. фактически получаем сжатие.
Так выглядит теория. Можно ли получить такое на реальных числах - не знаю.

ребята вы меня извините, но вы математику учили.

Не возможно написать ВЗАИМНООДНОЗНАЧНУЮ функцию из пространства с большим числом измерений в меньшее. (поясню нельзя написать архиватор который для ЛЮБОГО ввода в 9 символов кодирует в 8)

это достаточно очевидно ведь различных текстов в 9 байт некоторое число в степени 9, а в 8 байт тоже число в степени 8 , ясно что второе меньще первого.

так что очевидно что бессмысленно изобретать что-то сжимающее все и без потери

на самом деле вы от jpg зря отказались, происходит потеря только высоких частот, которые для   человека неинформативны, и если хотите что-то изобрести, то найдите базис по которому будет легче архивировать типа фурье иди адамара

с уважением

Demo_S можешь по RLE алгоритм + пример написать...или приложить файликом...а то очень нада для работы!

Сейчас я вам скажу способ идеального сжатия!!!

На входе алгоритма есть последовательность символов.
Находим в последовательности символов все возможные комбинации подпоследовательностей.
Это можно делать так же, как и строится контекстная модель. Только её глубину при максимальном сжатии нужно выбрать равной длине исходной последовательности. На практике при достаточно длинных последовательностях это не реализуемо ввиду большого расхода памяти. Поэтому её глубину можно выбирать разумно, чтобы хватило памяти.
Находим такую подпоследовательность, чтобы её длина была больше 1 и произведение её длины на количество её вхождений в исходную последовательность минус один было максимальным. L * (N - 1).
Расширяем алфавит символов ещё одним символом, который будет обозначать найденную подпоследовательность. Заменяем все её вхождения в исходную последовательность этим символом, а саму подпоследовательность добавляем в словарь.
Повторяем эти действия, пока не можно найти такие подпоследовательности. В итоге в исходной последовательности не останется ни одной пары рядом стоящих символов, которая бы повторялась два раза. То есть каждая пара рядом стоящих символов будет уникальна.
Далее полученную последовательность можно сжать арифметическим кодированием. Так же можно сжать некоторые последовательности из словаря.
Вот так вот!