![]() |
|
|
![]()
|
|
| h3d0 |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 2 Регистрация: 26.3.2008 Репутация: нет Всего: нет |
Добрый день. Я пишу программу, аналог RАdmina. Столкнулся с промлемой, попробую её описать. Например, есть два компа: удаленный и комп админа. С удаленного компа должен прийти снимок экрана.
![]() Но представим, что на компе админа этот снимок экрана удалённого компа отображается не в полный размер, а в окне – в окне моей программы. Значит снимок размером 1024х768 сожмется, ширина и высота умножатся на коефициент. И на экране админа будет виден не оригинал – а сжатая в размерах версия снимка экрана удалённого компа. ![]() Но на удаленном компе поменялся не весь экран, а только определённая область – значит мне нужно чтоб пришел только этот кусочек экрана и «вклеился» в старый снимок экрана (который уже есть на компе админа). ![]() Так вот вся проблема заключается в том, что моя программа использует специальную функцию, которая сжимает снимок экрана удаленного компа и вклеивает ёё в окно программы на компе админа, НО! На удалённом компе левый верхний угол оригинала снимка имел, например, координаты Х=22 У=18, но когда снимок приходит на комп админа и прграмма пытается впихнуть его в маленькое окно программы – координаты тоже множатся на коэфициент сжатия. По этому в новом окне тот же верхний левый угол окна имеет координаты, скажем Х=4.4 У=2.6. Поскольку координаты должны быть целыми числами – они округляются (Х=4 У=3) и картнинка смещается!!! ![]() В результате появляются глюки, визуально это выглядит на экране админа - как будто взяли кусок экнана и сдинули его на пиксель. Мне нужно добиться того, чтобы алгоритм работал правильно - не было артефактов-смещенй. Или же сменить стратегию сжатия совсем (взять другую функцию-алгоритм). Программу прикрепил (язык Delphi). Возможно кто-нибудь уже сталкивался с подобной проблемой. Буду очень признателен за помощь! Это сообщение отредактировал(а) h3d0 - 26.3.2008, 19:18 Присоединённый файл ( Кол-во скачиваний: 14 )
Scaling.rar 193,18 Kb |
|||
|
||||
| mmvds |
|
|||
![]() Бывалый ![]() Профиль Группа: Участник Сообщений: 230 Регистрация: 22.12.2007 Репутация: 1 Всего: 6 |
Может попробовать заменить округление round() на trunc()?
|
|||
|
||||
| 4d5a |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 29 Регистрация: 10.6.2007 Репутация: 1 Всего: 1 |
А что мешает использвать такую схему: Пересылая фрагменты, обновлять буфер (в натуральную величину) в памяти компа админа, а потом уже масштабировать весь буфер ? Артефактов не будет по определению, правда замедлится процедура перерисовки. Это сообщение отредактировал(а) 4d5a - 27.3.2008, 09:54 |
|||
|
||||
| SoWa |
|
|||
![]() Харекришна ![]() ![]() ![]() ![]() Профиль Группа: Комодератор Сообщений: 2422 Регистрация: 18.10.2004 Репутация: 6 Всего: 74 |
Понимаешь, в чем штука. Такие смещения появляются из-за размеров кусочка.
Вот смотри. 1024*768 преспокойно коэффициентом сжимается без потерь(имеется ввиду без округления). А вот 329*127 без тких потерь не сжать коэффициентом. Возмоный вариант решения- передавать картинку в несжатом формате, а только на админском компе сперва склеивать, потом сжимать. По проблемме передачи несжатой(по размерам ш*в) можно сжимать картинку в качестве. Там же рабочий стол. Найди оптимальный коэффициент потерь качества(например, чтоб буквы были читаемы при максимальном коэффициенте), сжимай там картинку по качеству, отсылай, склеивай, сжимай по размеру. -------------------- Всем добра |
|||
|
||||
| RockClimber |
|
|||
|
Опытный ![]() ![]() Профиль Группа: Участник Сообщений: 848 Регистрация: 5.5.2006 Где: планета 013 в тен туре Репутация: нет Всего: 15 |
Э-э-э... Я в-общем-то, в такого рода алгоритмах дилетант, но может стоит попробовать сделать так: пусть функция, которая вырезает и масштабирует кусок экрана, сначала будет расширять область до значений, которые масштабируются до целых значений? Т. е. если коэффициент масштабирования 0.75, начальная точка имеет координаты (15, 21) и конечная - (321, 425), то заменить сначала координаты на (12, 20) и (324, 428) соответственно, после чего масштабирование пройдет без проблем - получится (9, 15) и (243, 321). Только в этом случае ограничивается разнообразие коэффициентов масштабирования...
Как вариант, можно таким образом минимизировать величину разницы между точным и округленным значением (если масштаб, например, 0.9). Я не думаю, что эти вычисления займут много ресурсов... -------------------- Хорошо кинутый дятел далеко летит, крепко встревает, долго торчит. |
|||
|
||||
| asd |
|
|||
|
Шустрый ![]() Профиль Группа: Участник Сообщений: 89 Регистрация: 25.6.2006 Репутация: нет Всего: 1 |
h3d0,
Почитай вот эту тему http://www.wasm.ru/forum/viewtopic.php?id=14540 на предмет того, как лучше передавать изменения на экране уд-го компа. |
|||
|
||||
| Exaktus |
|
|||
![]() Шустрый ![]() Профиль Группа: Участник Сообщений: 135 Регистрация: 15.4.2007 Репутация: нет Всего: 4 |
Думаю, стоит посмотреть на вопрос с другой стороны. Исходя из поставленный задачи не помешает глянуть на схему работы VNC. Если не натолкнет на мысли, то можно порытся в исходниках TightVNC.
В любом случае, просто сжатие в картинку и передача не катит. Тогда уже надо сжимать в картинку только первый кадр, и затем передавать только измененные пиксели. Но тут имеется ряд недостатков. --------------------
Ничто так не бодрит по утрам, как свежеупавший сервер |
|||
|
||||
| h3d0 |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 2 Регистрация: 26.3.2008 Репутация: нет Всего: нет |
Есть, правда, ещё вариант - попробовать после вклеивания "усреднять" цвет пикселей на стыке...
|
|||
|
||||
![]()
|
| Правила форума "Алгоритмы" | |
|
|
Форум "Алгоритмы" предназначен для обсуждения вопросов, связанных только с алгоритмами и структурами данных, без привязки к конкретному языку программирования и/или программному продукту.
Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, maxim1000. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | Алгоритмы | Следующая тема » |
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |