PixelSearch - Вопросы относительно мироздания

[Belfigor]

Мы с приятелем собираемся переписать функцию пикселсеарч. Подскажите пожалуйста, в какую длл нужно обращаться, при попытке выяснить какого цвета пиксель она рисует на экране в заданых координатах?

Предпосылки такого порыва таковы:
когда мы указываем шейд пиксельсерчу - он начинает шагать по каналам в каждом элементе цвета (отдельно в р, отдельно в г, отдельно в б) или сразу во всех трёх?
т.е. получается. она может работать как вложенный, один в другой цикл фор некст на пиксельгетколор, и сличение с нужными параметрами.
А может работать вообще хз как.
Как это работает?
В любом случае, пока - это не удовлетворяет нашим потребностям в скорости работы. Мы хотим ускорить работу и переписать сам пиксель серч а при необходимости и пиксельгеткалор

[Nik_rus]

Думаю пиксель ищется алгоритмом:
1.Поиск по каналу R
2.Если совпал - проверка по G (если нет, топает дальше)
3.Если совпал и G, то проверка идет по B и тут уже реторн резулт.
Если это не так, то думаю на пару милисекунд этот способ бырее :)
А сам пиксел серч имхо зашит в компилятор и поставляется вместе с сабжем в откомпиленом скрипте.

[amel27]

не удовлетворяет нашим потребностям в скорости работы»
цитата из справки:Although PixelSearch is optimized, narrowing the search area helps speed up the result.это значит, что нужно:

- провести анализ контента сканируемого окна,
- отсечь области, где искомый объект никогда не появляется,
- разбить окно на блоки... скажем 3x3 = 9 прямоугольных областей,
- отсортировать эти области в порядке уменьшения вероятности появления искомого объекта,
- сканировать блоки в установленной последовательности.

Мы с приятелем собираемся переписать функцию пикселсеарч. Подскажите пожалуйста, в какую длл нужно обращаться, при попытке выяснить какого цвета пиксель она рисует на экране в заданых координатах?»для того, чтобы получить хоть какое-то ускорение, надо писать свою DLL, и желательно на АСМе

[Archy26]

это значит, что нужно:

- провести анализ контента сканируемого окна,
- отсечь области, где искомый объект никогда не появляется,
- разбить окно на блоки... скажем 3x3 = 9 прямоугольных областей,
- отсортировать эти области в порядке уменьшения вероятности появления искомого объекта,
- сканировать блоки в установленной последовательности.
-----=========---------

Добрый день! Я тот самый "приятель".
Дело вот в чём:
Мы всё это сделали.
У нас более 30 областей на экране размером 23х18 пикс.
И всё это должно сканироваться хотя бы раз в 50 мс.
А у нас получается 1 раз в 300-400 мс заканчивается сканирование.
Есть ли более быстрая альтернатива найти в искомых областях искомые пиксели?

Если уж с переписанием пиксельсерча всё так сложно?

[Nik_rus]

Ладно бы UDF, но тут то основной синтаксис... а он вшит в сам интерпретатор.
Топайте к создателям автоита и предлагайте свое решение.

[SyDr]

Много ли таких пикселей на экране?
Обязательно ли есть такой пиксел на экране?
Нужен один пиксел или все?
Это конкретно один пиксель или их целая группа? (Например прямоугольник на каком-то фоне).

Можно пример того, что надо найти? >_<

[Archy26]

1) На экране таких пикселей порядка 3-4х тысяч
2) Такой пиксел не обязательно есть в области сканирования
3) Нужны ВСЕ пикселы
4) Это последовательность белых или близких к белому цвету пикселей, напоминающая иконку размером 23х18 пикселей.
5)
ххххххххххххххххххххххх
ххххххх00000000ххххххх
ххх000000000000000ххх
ххх0000хххххххх0000ххх
х0х000хххххххххх0000хх
х00000хххххххххх0000хх
х00000хххххххххх0000хх
х000000ххххххххх0000хх
х0000000хххххххх0000хх
х00000000ххххххх0000хх
х0000000хххххххх0000хх
х000000ххххххххх0000хх
х00000хххххххххх0000хх
х0х000хххххххххх0000хх
ххх000хххххххххх0000хх
ххх000000000000000ххх
ххххххх00000000ххххххх
ххххххххххххххххххххххх

Примерно так.

[SyDr]

Ясно.

Думаю, все помнят морской бой? Так вот, стратегия нахождения четырёхклеточного корабля состояла в том, что обстреливался каждый четвёртый квадрат игрового поля. С такой тактикой его можно найти максимум за 24 хода. Если же просто стрелять по каждой клетке поля - вполне возможно, что он будет в правом нижнем углу. А на это нужно раза в 3 больше ходов.

Таким образом, необходимо выделить в сканируемой области пиксели, цвет которых необходимо обязательно проверить. И проверять только их. При совпадени - проверять область.

Пример:
x - любой не нужный цвет
o - нужный цвет
Нужная картинка имеет вид (квадрат три на три):
xxxxx
xooox
xooox
xooox
xxxxx

Тогда в поле размером 10 на 10 необходимо будет проверить:
xxxxxxxxxx
xxxxxxxxxx
xxhxxhxxxh
xxxxxxxxxx
xxxxxxxxxx
xxhxxhxxxh
xxxxxxxxxx
xxxxxxxxxx
xxhxxhxxxh
xxxxxxxxxx

Чтобы узнать есть ли здесь картинка нужно проверить 9 пикселей (из 100). Ну и потом уже просто будет найти сам квадрат.
Хотя с такой иконкой будет посложнее. Но принцип, думаю, понятен.

[Archy26]

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

[SyDr]

Тогда дайте картинку, которую надо найти.

В сканируемой области могут быть случайные пиксели такого же цвета?

[Belfigor]

Постараюсь объяснить более доступно что у нас есть и зачем нам нужна альтернатива пиксель гет калору.
У нас есть допустим поле 20х20 пикселейна этом поле рисунок, он тоже 20х20 пикселей Нам не надо искать где он может быть, мы уже знаем где он. Но на этом 20х20 поле может быть порядка сотни различных рисунков с уникальным набором пикселей каждый.

Мы сканируем все эти пиксели составляя разметку их расположения. Далее эту разметку мы сравниваем с базой уже имеющихся и таким образом понимаем что у нас на экране. Тоесть нам необходимо считать все 20х20 поле, каждый пиксель. Речь идет не о том как ускорить процесс путем считывания не всего поля а только его куска. Речь идет о том как это 20х20 поле считать быстрее чем с помощью пиксель гет калор.

Вот пример картинки. То что у нее по краям - чорный цвет - ничего не значит. У других картинок там может быть не чорный.

[SyDr]

В данном случае никак. Работу функций PixelSearch и PixelGetColor нельзя ускорить. Причём так сильно (вам ведь нужно примерно раз 6-8 быстрее.)
Ускорить общую работу можно, если бы, к примеру, 3-10 пикселей из этих 400 однозначано определяли саму картинку.


А вы уверены, что проблема в PixelSearch?

Сделал простой цикл поиска определённого пиксела в поле 100 на 100. 10000 проверок было сделано за:
225.176663514497 мс

[Belfigor]

Мы собираем всю инфу с 8694 пикселей, включая сопоставление с орегиналами за 77мс, но хотелось бы еще быстрее.

[SyDr]

"Копайте" в другую сторону.
1 пикселсеарч со всего моего экрана (1280*1024) делается за 0,04 мс


Здесь вы вряд-ли что-либо ешё оптимизируете...

[Belfigor]

В ближайшее время проведем исследовательскую работу по этому поводу :)
А в твоем случае пиксель находится в первом же из проверяемой области или же в самом правом нижнем углу?

[SyDr]

В моём случае пикселя вообще нет на экране. То есть он сравнивает вообще со всеми.
Я немного спутал. Не 0,04 мс, а 20. Но это при условии, что проверяются 1310720 пикселей.

Может быть вам стоит использовать PxelCheksum? Он работает примерно в два раза дольше, чем поиск. Но при этом позволяет уникально идентифицировать изображение.

[Belfigor]

Чек сумм отподает потому что обрабатываемый источник - корявый и там хоть где-то но цвет уплывает. Поэтому его надо сперва обработать отсеив все шумы и помехи и только потом сравнивать. :(

[amel27]

Нам не надо искать где он может быть, мы уже знаем где он. »тогда возникает вопрос: зачем тут вообще PixelSearch/PixelGetColor ?.. насколько я понял, тут нужно скопировать в массив все пиксели за один прием, и после этого IO вам не нужен... надеюсь, приложение оконное?

ADD: на оффсайте полно инфы по GDI для растра, родственная тема: Anything faster than Pixelgetcolor? (http://www.autoitscript.com/forum/index.php?showtopic=94738&st=0&p=681337&hl=GetDIBits&fromsearch=1&#entry681337) ;)

[Belfigor]

amel27, говорил уже десять раз в других темах но все же повторюсь. Ты ну просто бох ответов на мои вопросы ^_^. Щас покурю новую инфу и патом скорее всего отмечу тему как решенную :)