Автокликер Clickermann :: Форум
Основной раздел => Общие вопросы => Topic started by: 123 on September 23, 2014, 04:45:58 PM
-
Есть ли где-то примеры, при каких его значениях определённые картинки будут считаться одинаковыми и найдутся, а при каких нет? Или можно на пальцах объяснить, какие значения оптимальны в каких ситуациях? Например, чтобы разные слова одинаковой длины текстом одинакового шрифта и размера не были на одно лицо и находились, если одинаковые; узнавалась несимметричная картинка, повёрнутая на небольшой или большой угол, меньшего или большего размера; узнавалась картинка, на которую "упала тень" - формы и очертания те же, но цвета темнее образца.
-
Функция сравнивает все пикселы в фрагменте поиска, с пикселами на экране. Цветокоррекция позволяет сократить цветовое разнообразие, а процент совпадения позволит опустить некоторое количество несоответствующих пикселов.
Вот скрипт, позволит выяснить на каком проценте картинка подошла.
http://crapware.aidf.org/forum/index.php?topic=1022.msg4329#msg4329 (http://crapware.aidf.org/forum/index.php?topic=1022.msg4329#msg4329)
-
Есть ли где-то примеры, при каких его значениях определённые картинки будут считаться одинаковыми и найдутся, а при каких нет? Или можно на пальцах объяснить, какие значения оптимальны в каких ситуациях? Например, чтобы разные слова одинаковой длины текстом одинакового шрифта и размера не были на одно лицо и находились, если одинаковые; узнавалась несимметричная картинка, повёрнутая на небольшой или большой угол, меньшего или большего размера; узнавалась картинка, на которую "упала тень" - формы и очертания те же, но цвета темнее образца.
Если картинка повёрнута хоть на малый угол (если конечно это не симметричный узор под 45/90 градусов) или изменён масштаб, а так же при равномерном затенении/осветлении всей площади процентом совпадения не обойтись. Его придётся снижать до очень малых значений. А уже при 30-50% как показывает практика, начинает реагировать на что попало.
При затенениях нужно использовать совместно цветокоррекцию+процент. Процент я рассчитываю сравнивая чуть разные картинки в ФШ тупо высчитав плюс запас.
При изменении размера или угла вроде вообще не применимо, нужно искать другие пути - делать несколько изображений для сравнения и т.п.
А примеры... покажи рабочие вопросы, на них и разберём примеры.
-
Спасибо. Ясно, что до интеллекта поисковиков и распознавалок текста тут далековато.
Кому из читающих тему приходилось пользоваться этой командой, чирканите плиз пару строк для статистики что да как бывает на практике, если не влом, народу пригодится.
А если подходящих картинок будет несколько, найдутся все или одна, если одна, то какая именно?
-
А при чём тут интеллект поисковиков? Представь, что этот "интеллект" встроен при распознавании в кликер. Как на таком "желе" можно писать скрипты и надеяться на определённые результаты действий.
Толи похожа, толь не похожа, где граница... Нужно как минимум обучение под конкретную задачу. Где-то нужно достаточно сильное совпадение, а где-то... "лишь бы цифры беленькие".
Если ты решаешь задачи предназначенные для искусственного интеллекта, то тогда это работа не кликера.
Или менять задачу или подход к реализации.
А если подходящих картинок будет несколько, найдутся все или одна, если одна, то какая именно?
Про это и так всё ясно. Всё в справке есть.
При использовании функций поиска IF_PIXEL_IN, IF_PICTURE_IN найдётся только одна картинка, самая первая по направлению поиска (слева-направо и сверху-вниз).
Т.е. найдётся самая верхняя, при равных верхних верхняя-левая.
Для всех картинок сразу раньше писали для этого целый кусок скрипта, потом после просьб Джони сделал функции SCANPICTURE, SCANPXL возвращающие одновременно найденные совпадения в массив.
-
А вообще, картинки и скриншоты в памяти лучше пропускать через как можно большее сокращение цветов? Чтобы небольшие различия не мешали опознаванию. Операции скриншот в буфер, его цветосокращение, поиск на нём картинки в сумме грузят систему меньше, чем они же при использовании большего числа цветов?
-
наоборот больше, в отличие от аппаратного видеоадаптера, где действительно менее богатая палитра дает прирост производительности, здесь реализация программная поэтому каждая лишняя операция преобразования дополнительно создает нагрузку.
цветовые преобразования были введены как дополнительное средство оптимизации чтоб не мешали всякие блики и свечения. если можно обойтись без них - обойдитесь. получите небольшой выигрыш в скорости особенно на слабых и\или виртуальных машинах.
что касается параметра погрешности ipi (и его наследника scanpicture) то тут еще интереснее дела. если с опущеным (т.е. 100%) параметром ему хватит одной ошибки что бы споткнуться, то с праметром < 100% ему нужно накопить некоторое количество несоответствий чтобы забраковать образец. в рамках всего экрана это увеличивает задержку в разы. поэтому если хотите максимальной скорости то так же обойдитесь без параметра погрешности. то же справедливо для параметра фона но в гораздо меньшей степени.
-
Без обоих преобразований можно обойтись только при каких-то идеальных сферических картинках в вакууме. :)
Сдвинута картинка на полпикселя - уже другие цвета на границах между разными цветами. Можно как-нибудь сравнить, при подгоне скриншота и картинки под опознавание операцией цветосокращения и параметром совпадения пикселей, что из этого сильнее загружает систему и в каком соотношении лучше использовать их?
-
Без обоих преобразований можно обойтись только при каких-то идеальных сферических картинках в вакууме. :)
Сдвинута картинка на полпикселя - уже другие цвета на границах между разными цветами. Можно как-нибудь сравнить, при подгоне скриншота и картинки под опознавание операцией цветосокращения и параметром совпадения пикселей, что из этого сильнее загружает систему и в каком соотношении лучше использовать их?
Зря ты про коней. Всё зависит от приложения. В части из них подвижек на пол пикселя нет, соответственно нет и пересчётов. И таких приложение не мало. Ещё в большем числе это касается элементов интерфейса, пусть даже казуальных игр. Там как раз большая часть не пересчитывается даже на разных разрешениях. Можно смело обходиться прямым сравнением.
По скорости, нужно смотреть конкретно. Раньше когда colormode был общий, без задания области, его старался избегать до тех пор пока возможно. Сейчас чуть по другому.
Если область поиска маленькая, то без разницы.
Если область большая и фрагмент поиска выбран правильно, должен быть выгодней %.
Если выбран неправильно - colormode.
Если случаи сложные: сдвигается цветовая гамма по большей площади или большая протяжённость сглаженных краев (сглаженный текст особенно) здесь colormode минимум, а иногда ещё и +%.
Для скорости главное ограничить область если возможно и правильно выбрать образец поиска.
Вот мини-опрос... Дан такой экран (см. скриншот). На нём нужно найти поиском картинки (не поиском браузера) слово "Тема" которое я пометил рамкой. Область - вся (может быть в любом месте). Кто какой заготовит образец для оптимизации скорости?
Ответы в студию в виде файла.
Потом представим, что тот же участок будет искаться с применением 70% совпадения и то же с colormode 7
-
WAITMS(500)
MOVE(1,1)
$s = $_ms
GETSCREEN
IF_PICTURE_IN (0,0, $_xmax,$_ymax, "01.bmp", -1, 100)
LOGWRITE ("Без прозрачности: ", $_ms-$s, " мс")
MOVE($_return1, $_return2)
WAITMS(500)
END_IF
MOVE(1,1)
$s = $_ms
GETSCREEN
IF_PICTURE_IN (0,0, $_xmax,$_ymax, "02.bmp", 65280, 100)
LOGWRITE ("С прозрачностью: ", $_ms-$s, " мс")
MOVE($_return1, $_return2)
WAITMS(500)
END_IF
HALT
-
Тут мне видится два этапа в распознавании изображения.
1) Предварительный (быстрый - с минимумом пикселей). Находим картинку 1 в координатах (0,0, $_xmax,$_ymax) и вычисляем точные координаты для окончательного поиска .
2) Окончательный. Находим картинку 2.
[spoiler=Картинки для поиска выделены на скриншоте.](http://s7.hostingkartinok.com/uploads/images/2014/10/778f5f29e7f89d83d56c5ff85de75add.png) (http://hostingkartinok.com/show-image.php?id=778f5f29e7f89d83d56c5ff85de75add)[/spoiler]
Картинку 2, наверно, можно выбрать более оптимальную. В конкретно этом примере, колормод и % совпадения не применяются.
Выигрыш в скорости предполагается получить за счет первого этапа распознавания (поиска маленького, уникального изображения, на большой площади) и за счет того, что вторая (большая) картинка, будет распознаваться в точно указанных координатах (т.е. всего один раз за цикл распознавания).
P.S. Провёл сравнительные испытания скрипта Андрея и своего скрипта. В результате мой сценарий проиграл по времени поиска картинки примерно в 2 раза(!). :'( Это только на этом конкретном задании. Если же на экране было бы больше двоеточий (которые я использовал как уникальные картинки), то потери скорости были бы нереальные просто.
Делаю для себя вывод, что ускорить IF_PICTURE_IN используя комбинации из IF_PICTURE_IN не получится! :(
Урок усвоен, спасибо, было интересно. :)
P.S.P.S В поисках истины я провёл еще несколько тестов с IF_PICTURE_IN. И оказалось, что что ускорить IF_PICTURE_IN используя комбинации из IF_PICTURE_IN всё таки можно. :) Ошибка моего первого теста была в том, что я взял для первого (предварительного) поиска слишком большую картинку (16 пикселей). Если же уменьшить её до 3 уникальных пикселей, то скорость поиска будет равной скорости скрипта Андрея, даже если уменьшить его картинку 01.bmp в 2 раза. Другими словами, поиск изображения в два прохода, при определенных условиях, очень даже оправдан, если удастся найти, для первого прохода, тот самый заветный уникальный пиксель, который поможет сузить зону поиска для второго окончательного поиска. :)
-
Ясно, что до интеллекта поисковиков и распознавалок текста тут далековато.
Вот обидно как то стало. Кому, по вашему, "до интеллекта поисковиков и распознавалок текста" дальше? Языку ассе́мблера или C++, а может быть Delphi? А на чём вообще написаны эти поисковики и распознавалки, знаете?
Не скрипке далековато до Бетховена, а тому кто на ней играет. Нам дали инструмент, а уж какой интеллект мы сможем из себя выдавить, зависит от нас самих.
Сорри, что не по теме.
-
Так не честно. Зачем ты сразу подсказал.