Привет всем!
Не подскажет ли уважаемая публика, какие есть алгоритмы,  специализирующиеся на сжатии изображения десктопа, то есть совокупности видимых окон с соответствующими им внутренностями? Потребность в специализированном алгоритме возникла по причине того, что для решения этой задачи 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