Привет всем!
Не подскажет ли уважаемая публика, какие есть алгоритмы,  специализирующиеся на сжатии изображения десктопа, то есть совокупности видимых окон с соответствующими им внутренностями? Потребность в специализированном алгоритме возникла по причине того, что для решения этой задачи Jpg и Gif не совсем подходят, так как работают крайне плохо, а классический ZIP из-за своей сложности перегружает компьютер, но тем не менее при этом выдаёт самые хорошие результаты.
Спасибо за ответы.

можно делать это в отдельном потоке с низким приоритетом, тогда не будет "перегружать".

Насколько я знаю, так как окошки прямоугольные, только их координаты + вектор перемещения + "свежеоткрытые" части передаются. 
Ну и кубик вокруг стрелочки.

Насчёт формата передачи изображений..
ЙПЕГ колбасит резкие переходы, гиф убивает цврета в фотографиях. Попробуй  PNG,  хотя он тоже бьёт цвета иногда, но это будет лучшей альтернативой гифам и жпегам. 
Ну наверное то, что при минимум изменений передавать надо минимум данных, ты и сам знаешь..
 Можно кэшить изображения не клиенте..

PNG 

val
Что значит Jpg и Gif плохо работают? Jpg понятно, он с потерями. Gif ограничен 256 цветами, но для скриншотов офисных приложений и IDE этого обычно вполне достаточно. Странно, что Gif умудряется жать хуже, чем Zip - по идее, при уменьшении количества цветов отбрасывается часть информации и Gif должен получиться меньше. Особенно, если учесть, что в Gif тоже LZW алгоритм сжатия используется. Если нужен алгоритм сжатия без потерь и с бОльшим, чем у Gif количеством цветов - то PNG. 
А ещё можно посмотреть на то, что используется в VNC - навскидку в UltraVNC вижу ZRLE, Zlib, Hextile...

2 DemoCode, 


Тогда скорость упаковки будет медленная, а мне жлательно хотя бы 5-6 фреймов в секунду обеспечить.   



Обеспечивают низкий уровень сжатия.



На самом деле на вход поступают 2 256-ти цветные картинки, по-этому  и ZIP и выигрывает.

Что значит Джпег - плохой уровень сжатия. Уровень сжатия джпег регулируется пользователем. Поставьте максимальное сжатие и поверьте будет намногно круче зипа сжиматься.

xor каждого фрейма с предыдущим делается?
(или какое-то более интеллектуальное выделение изменений)

Да, уточню, плохой уровень сжатия при требуемом качестве изображения.



Смысла нет, так как картинки уже 8-ми битные. Поверил, толку - нет, только дополнительный потери времени.

Добавлено @ 12:46 


Вот в этом и заковыка, какое именно интеллектуальное выделение изменений, приходиться всё равно по всем пикселям бегать, ах их немало...   

Это сообщение отредактировал(а) val - 19.8.2006, 12:47

смысл есть, через xor можно решить какая часть кортинки изменилась и передавать только изменение!!!!
Если на экране будет картинка статична (пошли покурить ) то передаватся вообще ничего не будет, 
вот это сжатие, а !

Идея конечно неплохая, мы её пробовали, но если брать картинку 1024 * 768 имеем 786432 пикселя, тоесть такое вот большое количество ксоров, но и это не проблема, проблема в том, как выделить эту область, которая изменилась. Не буду же отправлять в сети каждый изменившийся пиксель и его координаты?!

после ксора все что было одинаковым станет равным 0
я думаю не будет большой проблемой определить из массива чисел где 0 а где не 0, и после определить координаты изменившейся части окна


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

Ага, а что делать если меняются не прямоугольные участки изображения, а попадаются отдельные точки, какие-то нелинейные их последовательности?!

Хде ты такое на экране видел?
имхо всеравно надо передавать прямоугольники

Ну там самая примитивная анимация (  )

Кроме того, каким, на Ваш взглят, может быть критерий выбора прямоугольников при нелинейном расположении изменившихся пикселей?

Это сообщение отредактировал(а) val - 19.8.2006, 13:57

на наш взлят () как выше писалось уже 
верхняя левая точка изменения и нижняя правая


это к чему?

xor я предлагал для gif, не для zip
для zip кроме залезания в его исходники и оптимизации по скорости там (скорее всего, за счёт степени сжатия) лично я другого пути не вижу
касательно gif, как я понял, скорость удовлетворительная, но степень сжатия недостаточная, так что можно попробовать сделать какие-то дополнительные действия дляеё улучшения (раз запас по времени есть)
одно из этих действий - xor:

1. сжатие должно увеличиться, т.к. (как уже было сказано) все неизменившиеся точки он переведёт в 0, это приведёт к тому, что те участки, которые в исходном виде сжимались плохо (границы окон, текстуры) после xor'а будут сжиматься значительно лучше, тут даже не надо выделять прямоугольники, содержищие изменения...

2. скорость: gif в обязательном порядке должен обработать каждый пиксел, при чём алгоритм его обработки значительно сложнее xor'а, потому мне кажется (измерений не проводил), что время, занимаемое xor'ом будет значительно меньше времени, занимаемого gif'ом, так что сумма изменится ненамного

вот...

сделал небольшой тестик:
взял 2 массива из 786432 байт, проксорил их (записывая в третий)
получилось около 0.009 секунды (VC++2005, без оптимизации)