Author Topic: Более подробная инфа о параметре точности поиска в IF_PICTURE_IN  (Read 5770 times)

0 Members and 1 Guest are viewing this topic.

123

  • Освоившийся
  • **
  • Posts: 31
    • View Profile
Есть ли где-то примеры, при каких его значениях определённые картинки будут считаться одинаковыми и найдутся, а при каких нет? Или можно на пальцах объяснить, какие значения оптимальны в каких ситуациях? Например, чтобы разные слова одинаковой длины текстом одинакового шрифта и размера не были на одно лицо и находились, если одинаковые; узнавалась несимметричная картинка, повёрнутая на небольшой или большой угол, меньшего или большего размера; узнавалась картинка, на которую "упала тень" - формы и очертания те же, но цвета темнее образца.
« Last Edit: September 23, 2014, 04:57:20 PM by 123 »

Oraven

  • Супермодератор
  • Герой форума
  • *
  • Posts: 3685
  • Котэ
    • View Profile
Функция сравнивает все пикселы в фрагменте поиска, с пикселами на экране. Цветокоррекция позволяет сократить цветовое разнообразие, а процент совпадения позволит опустить некоторое количество несоответствующих пикселов.

Вот скрипт, позволит выяснить на каком проценте картинка подошла.
http://crapware.aidf.org/forum/index.php?topic=1022.msg4329#msg4329

Vint

  • Супермодератор
  • Герой форума
  • *
  • Posts: 3935
  • Лечу куда хочу. cman 4.13.014x32, 4.14.003 W10
    • View Profile
Есть ли где-то примеры, при каких его значениях определённые картинки будут считаться одинаковыми и найдутся, а при каких нет? Или можно на пальцах объяснить, какие значения оптимальны в каких ситуациях? Например, чтобы разные слова одинаковой длины текстом одинакового шрифта и размера не были на одно лицо и находились, если одинаковые; узнавалась несимметричная картинка, повёрнутая на небольшой или большой угол, меньшего или большего размера; узнавалась картинка, на которую "упала тень" - формы и очертания те же, но цвета темнее образца.
Если картинка повёрнута хоть на малый угол (если конечно это не симметричный узор под 45/90 градусов) или изменён масштаб, а так же при равномерном затенении/осветлении всей площади процентом совпадения не обойтись. Его придётся снижать до очень малых значений. А уже при 30-50% как показывает практика, начинает реагировать на что попало.
При затенениях нужно использовать совместно цветокоррекцию+процент. Процент я рассчитываю сравнивая чуть разные картинки в ФШ тупо высчитав плюс запас.
При изменении размера или угла вроде вообще не применимо, нужно искать другие пути - делать несколько изображений для сравнения и т.п.
А примеры... покажи рабочие вопросы, на них и разберём примеры.


123

  • Освоившийся
  • **
  • Posts: 31
    • View Profile
Спасибо. Ясно, что до интеллекта поисковиков и распознавалок текста тут далековато.
Кому из читающих тему приходилось пользоваться этой командой, чирканите плиз пару строк для статистики что да как бывает на практике, если не влом, народу пригодится.

А если подходящих картинок будет несколько, найдутся все или одна, если одна, то какая именно?

Vint

  • Супермодератор
  • Герой форума
  • *
  • Posts: 3935
  • Лечу куда хочу. cman 4.13.014x32, 4.14.003 W10
    • View Profile
А при чём тут интеллект поисковиков? Представь, что этот "интеллект" встроен при распознавании в кликер. Как на таком "желе" можно писать скрипты и надеяться на определённые результаты действий.
Толи похожа, толь не похожа, где граница... Нужно как минимум обучение под конкретную задачу. Где-то нужно достаточно сильное совпадение, а где-то... "лишь бы цифры беленькие".

Если ты решаешь задачи предназначенные для искусственного интеллекта, то тогда это работа не кликера.
Или менять задачу или подход к реализации.

А если подходящих картинок будет несколько, найдутся все или одна, если одна, то какая именно?
Про это и так всё ясно. Всё в справке есть.
При использовании функций поиска IF_PIXEL_IN, IF_PICTURE_IN  найдётся только одна картинка, самая первая по направлению поиска (слева-направо и сверху-вниз).
Т.е. найдётся самая верхняя, при равных верхних верхняя-левая.

Для всех картинок сразу раньше писали для этого целый кусок скрипта, потом после просьб Джони сделал функции SCANPICTURE, SCANPXL возвращающие одновременно найденные совпадения в массив.
« Last Edit: September 25, 2014, 12:25:22 PM by Vint »


123

  • Освоившийся
  • **
  • Posts: 31
    • View Profile
А вообще, картинки и скриншоты в памяти лучше пропускать через как можно большее сокращение цветов? Чтобы небольшие различия не мешали опознаванию. Операции скриншот в буфер, его цветосокращение, поиск на нём картинки в сумме грузят систему меньше, чем они же при использовании большего числа цветов?
« Last Edit: October 23, 2014, 02:57:01 PM by 123 »

Johnny

  • Создатель
  • Герой форума
  • *
  • Posts: 593
    • View Profile
наоборот больше, в отличие от аппаратного видеоадаптера, где действительно менее богатая палитра дает прирост производительности, здесь реализация программная поэтому каждая лишняя операция преобразования дополнительно создает нагрузку.
цветовые преобразования были введены как дополнительное средство оптимизации чтоб не мешали всякие блики и свечения. если можно обойтись без них - обойдитесь. получите небольшой выигрыш в скорости особенно на слабых и\или виртуальных машинах.

что касается параметра погрешности ipi (и его наследника scanpicture) то тут еще интереснее дела. если с опущеным (т.е. 100%) параметром ему хватит одной ошибки что бы споткнуться, то с праметром < 100% ему нужно накопить некоторое количество несоответствий чтобы забраковать образец. в рамках всего экрана это увеличивает задержку в разы. поэтому если хотите максимальной скорости то так же обойдитесь без параметра погрешности. то же справедливо для параметра фона но в гораздо меньшей степени.
« Last Edit: October 23, 2014, 03:10:34 PM by Johnny »

123

  • Освоившийся
  • **
  • Posts: 31
    • View Profile
Без обоих преобразований можно обойтись только при каких-то идеальных сферических картинках в вакууме. :)
Сдвинута картинка на полпикселя - уже другие цвета на границах между разными цветами. Можно как-нибудь сравнить, при подгоне скриншота и картинки под опознавание операцией цветосокращения и параметром совпадения пикселей, что из этого сильнее загружает систему и в каком соотношении лучше использовать их?

Vint

  • Супермодератор
  • Герой форума
  • *
  • Posts: 3935
  • Лечу куда хочу. cman 4.13.014x32, 4.14.003 W10
    • View Profile
Без обоих преобразований можно обойтись только при каких-то идеальных сферических картинках в вакууме. :)
Сдвинута картинка на полпикселя - уже другие цвета на границах между разными цветами. Можно как-нибудь сравнить, при подгоне скриншота и картинки под опознавание операцией цветосокращения и параметром совпадения пикселей, что из этого сильнее загружает систему и в каком соотношении лучше использовать их?

Зря ты про коней. Всё зависит от приложения. В части из них подвижек на пол пикселя нет, соответственно нет и пересчётов. И таких приложение не мало. Ещё в большем числе это касается элементов интерфейса, пусть даже казуальных игр. Там как раз большая часть не пересчитывается даже на разных разрешениях. Можно смело обходиться прямым сравнением.

По скорости, нужно смотреть конкретно. Раньше когда colormode был общий, без задания области, его старался избегать до тех пор пока возможно. Сейчас чуть по другому.
Если область поиска маленькая, то без разницы.
Если область большая и фрагмент поиска выбран правильно, должен быть выгодней %.
Если выбран неправильно - colormode.

Если случаи сложные: сдвигается цветовая гамма по большей площади или большая протяжённость сглаженных краев (сглаженный текст особенно) здесь colormode минимум, а иногда ещё и +%.
Для скорости главное ограничить область если возможно и правильно выбрать образец поиска.

Вот мини-опрос... Дан такой экран (см. скриншот). На нём нужно найти поиском картинки (не поиском браузера) слово "Тема" которое я пометил рамкой. Область - вся (может быть в любом месте). Кто какой заготовит образец для оптимизации скорости?
Ответы в студию в виде файла.
Потом представим, что тот же участок будет искаться с применением 70% совпадения и то же с colormode 7

« Last Edit: October 23, 2014, 05:22:23 PM by Vint »


Oraven

  • Супермодератор
  • Герой форума
  • *
  • Posts: 3685
  • Котэ
    • View Profile
Code: (clickermann) [Select]
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

Atas

  • Активный участник
  • ***
  • Posts: 147
    • View Profile
Тут мне видится два этапа в распознавании изображения.
1) Предварительный (быстрый - с минимумом пикселей). Находим картинку 1 в координатах (0,0, $_xmax,$_ymax) и вычисляем точные координаты для окончательного поиска .
2) Окончательный. Находим картинку 2.
[spoiler=Картинки для поиска выделены на скриншоте.][/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 раза. Другими словами, поиск изображения в два прохода, при определенных условиях, очень даже оправдан, если удастся найти, для первого прохода, тот самый заветный уникальный пиксель, который поможет сузить зону поиска для второго окончательного поиска. :)
« Last Edit: October 23, 2014, 11:15:55 PM by Atas »

Atas

  • Активный участник
  • ***
  • Posts: 147
    • View Profile
Ясно, что до интеллекта поисковиков и распознавалок текста тут далековато.

Вот обидно как то стало. Кому, по вашему, "до интеллекта поисковиков и распознавалок текста" дальше? Языку ассе́мблера или C++, а может быть Delphi? А на чём вообще написаны эти поисковики и распознавалки, знаете?
Не скрипке далековато до Бетховена, а тому кто на ней играет.  Нам дали инструмент, а уж какой интеллект мы сможем из себя выдавить, зависит от нас самих.
Сорри, что не по теме.

Vint

  • Супермодератор
  • Герой форума
  • *
  • Posts: 3935
  • Лечу куда хочу. cman 4.13.014x32, 4.14.003 W10
    • View Profile
Так не честно. Зачем ты сразу подсказал.