Разработка findcolor, findimage, Pure lua Опции

[sutra]

Сама по себе задача распознавания чего-либо непроста. Годами люди бились над этим. И в нашем случае много чего ещё можно добавить. Ну например искать те же пресловутые 22 картинки. Юзер точно знает, что их должно быть 22 и чтобы функция их нашла все 22. Тут уже должен быть реализован именно подход максимальной схожести картинок. Но тут уж вам всё это решать, мне достаточно того что есть. Ещё раз всем спасибо.

[Cockney]

Сама по себе задача распознавания чего-либо непроста. Годами люди бились над этим. И в нашем случае много чего ещё можно добавить. Ну например искать те же пресловутые 22 картинки. Юзер точно знает, что их должно быть 22 и чтобы функция их нашла все 22. Тут уже должен быть реализован именно подход максимальной схожести картинок. Но тут уж вам всё это решать, мне достаточно того что есть. Ещё раз всем спасибо.

А еще можно использовать OpenCV и не делать свои велосипеды)

[sutra]

А еще можно использовать OpenCV и не делать свои велосипеды)

Не хотел комментировать, но не сдержался.
Тут элементарщины не знаешь, а предлагается сразу на ИИ переходить. И я не жалею, что изобретал даже не велосипед, а всего лишь колесо. Во всяком случае я получал некоторые знания и положительные эмоции, когда получалось заставить всё это "ехать". Даже просто немного напрячь извилины и то полезно. Могу сказать только одно, если не использовать OpenCV и прочие достижения человечества, то поиск символов текста отсеиванием пикселей и схожестью (на мой взгляд) решить будет проблематично, а я со своими убогими трафаретами всё это уже давно делаю, во всяком случае с тем, с чем сталкивался, искал без проблем. И это с минимальнейшим уровнем образования и практики программирования.

[Cockney]

Не хотел комментировать, но не сдержался.
Тут элементарщины не знаешь, а предлагается сразу на ИИ переходить. И я не жалею, что изобретал даже не велосипед, а всего лишь колесо. Во всяком случае я получал некоторые знания и положительные эмоции, когда получалось заставить всё это "ехать". Даже просто немного напрячь извилины и то полезно. Могу сказать только одно, если не использовать OpenCV и прочие достижения человечества, то поиск символов текста отсеиванием пикселей и схожестью (на мой взгляд) решить будет проблематично, а я со своими убогими трафаретами всё это уже давно делаю, во всяком случае с тем, с чем сталкивался, искал без проблем. И это с минимальнейшим уровнем образования и практики программирования.

OpenCV это не ИИ, а математически обоснованная основа для распознавания (и не только) графики. Мы ищем пиксели, там ищутся дескрипторы (уникальные точки, не цвет, а именно точки, по математическим правилам). Это нисколько не преуменьшает желание развиваться как-то, просто для реальных задач, например, распознавание и точное позиционирование с учетом размытия, движения, поворотов и т.д. это стандарт.

[sutra]

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

Вот что ещё хотел сказать на эту тему. Я всегда ЗА если что-то предвосхищает мои ожидания. Но меня всегда бесит, если начинают думать за меня, не учитывая что я могу думать не так и хотеть что-то не то. Проще говоря, всегда нужно оставлять маневр за юзером, пусть в самой неочевидной вкладке меню, пусть в "глубоко зарытом" параметре под названием superadvanced. Но конечное решение всегда надо оставлять за пользователем. Ведь может кому-то, зачем-то, понадобятся ВСЕ найденные картинки, включая и дубликаты. А вот как раз шаг поиска - это выбор пользователя. Если пользователь "дремуче глуп", думаю он даже не поймёт как вообще пользоваться предоставленным функционалом, ну а если нет, что я думаю так и есть для большинства юзеров, то конечное решение должен принимать он сам. Для разрешения этого "вечного" конфликта и существует понятие "по умолчанию", устраивающее подавляющее большинство, ну а кто не согласен - "всё включено".

(уникальные точки, не цвет, а именно точки, по математическим правилам)

Ну про это самое я и тут 2 года назад говорил, ну а понимал это и 20 лет назад. Собственно мои трафареты - это и есть, пусть примитивные, но реперные точки, только тут мы их определяем сами, а в идеале это нужно ставить на автомат. Реализация от идей конечно может отличаться даже на десятки лет. Я то точно отстал от жизни и догнать не представляется возможным. Увижу всё уже в другой жизни.

[sutra]

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

[Cockney]

Вот что ещё хотел сказать на эту тему. Я всегда ЗА если что-то предвосхищает мои ожидания. Но меня всегда бесит, если начинают думать за меня, не учитывая что я могу думать не так и хотеть что-то не то. Проще говоря, всегда нужно оставлять маневр за юзером, пусть в самой неочевидной вкладке меню, пусть в "глубоко зарытом" параметре под названием superadvanced. Но конечное решение всегда надо оставлять за пользователем. Ведь может кому-то, зачем-то, понадобятся ВСЕ найденные картинки, включая и дубликаты. А вот как раз шаг поиска - это выбор пользователя. Если пользователь "дремуче глуп", думаю он даже не поймёт как вообще пользоваться предоставленным функционалом, ну а если нет, что я думаю так и есть для большинства юзеров, то конечное решение должен принимать он сам. Для разрешения этого "вечного" конфликта и существует понятие "по умолчанию", устраивающее подавляющее большинство, ну а кто не согласен - "всё включено".

Это очень спорно. Вопрос что давать пользователю даже под superadvanced. Например, excel хранит данные в xml, а если я знаю эффективный алгоритм парсинга другого формата ? Тут все упирается в эффективность и гибкость. Увеличь одно и уменьшится другое. Вопрос баланса. Касается любых систем, не только excel. Собственно по этому и есть куча решений, а не одно единственное.

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

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

[sutra]

Не совсем в тему, но интересный факт. Вот ведь какая математика на lua.
Ничего не тестил, как обычно напоролся чисто случайно.
Ищу картинки с ординаты 254 - три секунды.
Ищу с ординаты 255 - 4,5 секунды.
Бойтесь единичек, 255 и прочих пограничных значений, что-то видимо не так с приведением типов.
В общем математика - просто хлам, вот поэтому и скорость такая.
Надо будет попробовать если самому явно прописать все типы как СИ дата.

[sutra]

Да и не только "пограничных". И на 256 и на 257 - тормоз, а по логике должно быть наоборот.
Короче вообще непонятно как всё считается на lua - просто полнейшая бредятина.
Так что такие вещи делать на lua под большим большим вопросом.

[sutra]

Попробовал все переменные сделать си-шными - результат тот же.
Попробовал их сделать си-шным массивом - результат тот же.
Всё равно видимо lua сам выполняет всю математику и без разницы что ему подсовывать.

[Madeus]

Да все нормально в луа с математикой, если бы там такие проблемы были то lua и в частности luajit не использовали в таких проектах как tarantool, torch7, куче игровых движков и не только.

[Cockney]

Да все нормально в луа с математикой, если бы там такие проблемы были то lua и в частности luajit не использовали в таких проектах как tarantool, torch7, куче игровых движков и не только.

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

[sutra]

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

[sutra]

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

Конечно в большинстве случаев всё-таки логика работает, но ИНОГДА нет. Поэтому дать гарантию 100% что я что-то улучшил, а не ухудшил я не могу.

А вообще, трудно отследить поведение. В глобальном цикле на первой итерации можешь получить тормоз, а потом всё разгоняется и приходит в норму. Тестировать на локальных примерах просто не имеет смысла. В реальной задаче всё может быть иначе. Это уж я просто поделился опытом.

[Cockney]

И вот эта непредсказуемость и есть самый главный недостаток.

Удивительно, но и в c++ я столкнулся с подобным явлением. Решил собрать библиотечку со своим поиском, был написан интерфейс на Си, чтобы дергать функции можно было откуда угодно. Все, разумеется, работает, и отладка самой библиотеки это подтверждает. Но стоит ее подключить к тестовому проекту....

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

Код

#pragma pack(push,1)
struct FoundImage {
  int x1;
  int y1;
  int x2;
  int y2;
  double accuracy;
};
#pragma pack(pop)

С вероятностью 30% (да, да, это происходит не всегда) первый (и только первый) элемент этого массива будет битый. Т.е. значения там абсолютно рандомные. При том, что есть некая зависимость, например это выглядит так:

x1 = -3234234234
y1 = 441
x2 = -3234234234
y2 = 441

т.е. рандомные пары.

Хорошо, подумал я что съехало выравнивание. Да нет, во-первых стоят pragma'ы, во-вторых ломается всегда первый элемент, а не последующие.

Проверил заголовочники. Типы данных совпадают. Проверил опции компилятора. Совпадают. Да что уж, библиотека даже собрана со статическим рантаймом, что делает перемешивание памяти невозможным никак.

Осталась последняя надежда - может отдаю кривой адрес ? Да нет, адрес отдается нужный, и более того, библиотека залоггировала этот массив, и да, он полностью корректный. Но как только я отдаю этот адрес в тестовое приложение - первый элемент битый ( не всегда, как я и писал выше).

Т.е. в один момент времени по одному и тому же адресу лежат разные значения (в библиотеке свое, в тестовом проекте - свое). Дополню, что вся работа происходит в одном потоке, этот указатель не отдается в какие-то конкурентные моменты.

Я даже предположить не могу что это. Ну что же, еще не утро, можно и поотлаживать еще.

[Cockney]

Собственно, как и ожидалось, отладка ничего и не дала. Привожу наглядный кусок лога. Сначала идет лог из библиотеки, следом из приложения:

Код

Found: 6
Lib ptr: 000002AB95927E80
===============
X1: 408, Y1: 146, X2: 444, Y2: 183, accuracy: 100
X1: 28, Y1: 404, X2: 64, Y2: 441, accuracy: 100
X1: 123, Y1: 533, X2: 159, Y2: 570, accuracy: 100
X1: 1643, Y1: 662, X2: 1679, Y2: 699, accuracy: 100
X1: 218, Y1: 791, X2: 254, Y2: 828, accuracy: 100
X1: 503, Y1: 791, X2: 539, Y2: 828, accuracy: 100
===============
App ptr: 000002AB95927E80
X1: -1785674816, Y1: 683, X2: -1785703024, Y2: 683, accuracy: 100
X1: 28, Y1: 404, X2: 64, Y2: 441, accuracy: 100
X1: 123, Y1: 533, X2: 159, Y2: 570, accuracy: 100
X1: 1643, Y1: 662, X2: 1679, Y2: 699, accuracy: 100
X1: 218, Y1: 791, X2: 254, Y2: 828, accuracy: 100
X1: 503, Y1: 791, X2: 539, Y2: 828, accuracy: 100

Обратите внимание на указатели. Он один и тот же. Типы данных совпадают. Это простой int размера 4 байта. И на стороне библиотеки и на стороне тестового приложения. Понятно, что на ум приходит какая-то опция или каст, отвечающий за интерпретацию данных, но нет, их нет. И на стороне библиотеки и на стороне приложения все одинаково. Парадокс.

Если есть у кого мысли, предлагайте. Буду рад свежим идеям.

[cirus]

000002AB95927E80
Это простой int

В 4 байта оно конечно влезет, но только в unsigned int, в int это будет -1785561472.

[Cockney]

В 4 байта оно конечно влезет, но только в unsigned int, в int это будет -1785561472.

Адрес помещается в переменную с типом указателя, что по сути 8 байт unsigned на платформе x64. Да проблема не в том, что доступ по плохому адресу, это бы сразу всплыло, а то что по одному адресу данные интерпретируются по разному, хотя на обеих сторонах используется int для полей x1,y1 и т.д.

[Cockney]

Вот еще пример аномалии:

Код

Found: 6
Lib ptr: 000001DA0F9A5FB0
===============
X1: 408, Y1: 146, X2: 444, Y2: 183, accuracy: 100
X1: 28, Y1: 404, X2: 64, Y2: 441, accuracy: 100
X1: 123, Y1: 533, X2: 159, Y2: 570, accuracy: 100
X1: 1643, Y1: 662, X2: 1679, Y2: 699, accuracy: 100
X1: 218, Y1: 791, X2: 254, Y2: 828, accuracy: 100
X1: 503, Y1: 791, X2: 539, Y2: 828, accuracy: 100
===============
App ptr: 000001DA0F9A5FB0
X1: 261974496, Y1: 474, X2: 261786048, Y2: 474, accuracy: 100
X1: 28, Y1: 404, X2: 64, Y2: 441, accuracy: 100
X1: 123, Y1: 533, X2: 159, Y2: 570, accuracy: 100
X1: 1643, Y1: 662, X2: 1679, Y2: 699, accuracy: 100
X1: 218, Y1: 791, X2: 254, Y2: 828, accuracy: 100
X1: 503, Y1: 791, X2: 539, Y2: 828, accuracy: 100

А вот пример когда все нормально (код не меняется между запусками):

Код

Found: 6
Lib ptr: 00000231D5AC4880
===============
X1: 408, Y1: 146, X2: 444, Y2: 183, accuracy: 100
X1: 28, Y1: 404, X2: 64, Y2: 441, accuracy: 100
X1: 123, Y1: 533, X2: 159, Y2: 570, accuracy: 100
X1: 1643, Y1: 662, X2: 1679, Y2: 699, accuracy: 100
X1: 218, Y1: 791, X2: 254, Y2: 828, accuracy: 100
X1: 503, Y1: 791, X2: 539, Y2: 828, accuracy: 100
===============
App ptr: 00000231D5AC4880
X1: 408, Y1: 146, X2: 444, Y2: 183, accuracy: 100
X1: 28, Y1: 404, X2: 64, Y2: 441, accuracy: 100
X1: 123, Y1: 533, X2: 159, Y2: 570, accuracy: 100
X1: 1643, Y1: 662, X2: 1679, Y2: 699, accuracy: 100
X1: 218, Y1: 791, X2: 254, Y2: 828, accuracy: 100
X1: 503, Y1: 791, X2: 539, Y2: 828, accuracy: 100

[sutra]

А если попробовать unsigned int вместо int, какой будет результат? Вроде отрицательные координаты ни к чему. Хотя я понимаю, интересует вопрос ПОЧЕМУ так происходит.

Конечно надо понять причину, но принципе можно просто сдвинуть данные, пусть первые будут типа буфером.

По логике получается что адрес залезает на данные, в приложении. Как приложение интерпретирует адрес, во сколько байт? Одному приложению известно. Плюнуть и сделать запас, чем ломать голову над приложением.