Цитата(val @ 18.8.2006, 19:02  ) |
| а классический ZIP из-за своей сложности перегружает компьютер |
можно делать это в отдельном потоке с низким приоритетом, тогда не будет "перегружать".
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Алгоритмы > Сжатие изображения desktop(a) |
| Автор: val 18.8.2006, 18:02 |
| Привет всем! Не подскажет ли уважаемая публика, какие есть алгоритмы, специализирующиеся на сжатии изображения десктопа, то есть совокупности видимых окон с соответствующими им внутренностями? Потребность в специализированном алгоритме возникла по причине того, что для решения этой задачи Jpg и Gif не совсем подходят, так как работают крайне плохо, а классический ZIP из-за своей сложности перегружает компьютер, но тем не менее при этом выдаёт самые хорошие результаты. Спасибо за ответы. |
| Автор: DemoCode 18.8.2006, 18:17 | ||
можно делать это в отдельном потоке с низким приоритетом, тогда не будет "перегружать". |
| Автор: testsergej 18.8.2006, 19:03 |
| Насколько я знаю, так как окошки прямоугольные, только их координаты + вектор перемещения + "свежеоткрытые" части передаются. Ну и кубик вокруг стрелочки. Насчёт формата передачи изображений.. ЙПЕГ колбасит резкие переходы, гиф убивает цврета в фотографиях. Попробуй PNG, хотя он тоже бьёт цвета иногда, но это будет лучшей альтернативой гифам и жпегам. Ну наверное то, что при минимум изменений передавать надо минимум данных, ты и сам знаешь.. Можно кэшить изображения не клиенте.. |
| Автор: Romikgy 18.8.2006, 19:18 |
| PNG |
| Автор: allex 18.8.2006, 20:13 |
| val Что значит Jpg и Gif плохо работают? Jpg понятно, он с потерями. Gif ограничен 256 цветами, но для скриншотов офисных приложений и IDE этого обычно вполне достаточно. Странно, что Gif умудряется жать хуже, чем Zip - по идее, при уменьшении количества цветов отбрасывается часть информации и Gif должен получиться меньше. Особенно, если учесть, что в Gif тоже LZW алгоритм сжатия используется. Если нужен алгоритм сжатия без потерь и с бОльшим, чем у Gif количеством цветов - то PNG. А ещё можно посмотреть на то, что используется в VNC - навскидку в UltraVNC вижу ZRLE, Zlib, Hextile... |
| Автор: val 19.8.2006, 09:53 | ||||||
2 DemoCode,
Тогда скорость упаковки будет медленная, а мне жлательно хотя бы 5-6 фреймов в секунду обеспечить.
Обеспечивают низкий уровень сжатия.
На самом деле на вход поступают 2 256-ти цветные картинки, по-этому и ZIP и выигрывает. |
| Автор: esperant0 19.8.2006, 10:48 | ||||||||
Что значит Джпег - плохой уровень сжатия. Уровень сжатия джпег регулируется пользователем. Поставьте максимальное сжатие и поверьте будет намногно круче зипа сжиматься. |
| Автор: maxim1000 19.8.2006, 12:10 |
| xor каждого фрейма с предыдущим делается? (или какое-то более интеллектуальное выделение изменений) |
| Автор: val 19.8.2006, 12:44 | ||||||
Да, уточню, плохой уровень сжатия при требуемом качестве изображения.
Смысла нет, так как картинки уже 8-ми битные. Поверил, толку - нет, только дополнительный потери времени. Добавлено @ 12:46
Вот в этом и заковыка, какое именно интеллектуальное выделение изменений, приходиться всё равно по всем пикселям бегать, ах их немало...  |
| Автор: Romikgy 19.8.2006, 12:48 | ||
смысл есть, через xor можно решить какая часть кортинки изменилась и передавать только изменение!!!! Если на экране будет картинка статична (пошли покурить ) то передаватся вообще ничего не будет, вот это сжатие, а ! |
| Автор: val 19.8.2006, 13:20 | ||
Идея конечно неплохая, мы её пробовали, но если брать картинку 1024 * 768 имеем 786432 пикселя, тоесть такое вот большое количество ксоров, но и это не проблема, проблема в том, как выделить эту область, которая изменилась. Не буду же отправлять в сети каждый изменившийся пиксель и его координаты?! |
| Автор: Romikgy 19.8.2006, 13:43 | ||||
после ксора все что было одинаковым станет равным 0 я думаю не будет большой проблемой определить из массива чисел где 0 а где не 0, и после определить координаты изменившейся части окна
нет только коорд. верхней левой точки и размер самого изменения , ну и за ним уже саму картинку |
| Автор: val 19.8.2006, 13:48 | ||
Ага, а что делать если меняются не прямоугольные участки изображения, а попадаются отдельные точки, какие-то нелинейные их последовательности?! |
| Автор: Romikgy 19.8.2006, 13:53 | ||
Хде ты такое на экране видел? имхо всеравно надо передавать прямоугольники |
| Автор: val 19.8.2006, 13:56 | ||
Ну там самая примитивная анимация (  )Кроме того, каким, на Ваш взглят, может быть критерий выбора прямоугольников при нелинейном расположении изменившихся пикселей? |
| Автор: Romikgy 19.8.2006, 14:37 | ||||
на наш взлят (  ) как выше писалось уже верхняя левая точка изменения и нижняя правая
это к чему? |
| Автор: maxim1000 19.8.2006, 14:55 |
| xor я предлагал для gif, не для zip для zip кроме залезания в его исходники и оптимизации по скорости там (скорее всего, за счёт степени сжатия) лично я другого пути не вижу касательно gif, как я понял, скорость удовлетворительная, но степень сжатия недостаточная, так что можно попробовать сделать какие-то дополнительные действия дляеё улучшения (раз запас по времени есть) одно из этих действий - xor: 1. сжатие должно увеличиться, т.к. (как уже было сказано) все неизменившиеся точки он переведёт в 0, это приведёт к тому, что те участки, которые в исходном виде сжимались плохо (границы окон, текстуры) после xor'а будут сжиматься значительно лучше, тут даже не надо выделять прямоугольники, содержищие изменения... 2. скорость: gif в обязательном порядке должен обработать каждый пиксел, при чём алгоритм его обработки значительно сложнее xor'а, потому мне кажется (измерений не проводил), что время, занимаемое xor'ом будет значительно меньше времени, занимаемого gif'ом, так что сумма изменится ненамного вот... |
| Автор: maxim1000 19.8.2006, 15:24 |
| сделал небольшой тестик: взял 2 массива из 786432 байт, проксорил их (записывая в третий) получилось около 0.009 секунды (VC++2005, без оптимизации) |