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

[Cockney]

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

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

Ничего не поменяется. Просто числа будут не отрицательные. Кажется установил причину такого поведения. Вся проблема в таком участке кода:

Код

// std::get возвращает ССЫЛКУ на вектор
// при этом компилятор выведет тип res как std::vector<FoundImage>, т.е. полноценный ОБЪЕКТ
auto res = std::get<std::vector<FoundImage>>(m_storage);

Т.е. происходит неявное копирование данных из хранилища в объект на стеке, а дальше указатель на данные в этом объекте уходят в тестовое приложение. Разумеется, когда указатель приходит приложению, то объект разрушается (т.к. лежит на стеке), и адрес становится не валидным. А т.к. с++ нужно максимальное ускорение, то память не обнуляется что видно по логам.

фикс заключается в:

Код

auto& res = ....

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

Ладно я неопытный, но компилятору даже с самыми строгими настройками проверок на это пофиг, ну как так то.....

[sutra]

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

ОК. Удачи.

Я вот что ещё хотел сказать. Препроцессинг, а он вообще нужен? У тебя и так вроде всё быстро, какой смысл ещё чего-то придумывать. А самое главное, что вряд ли что-то можно сильно улучшить. В одном случае будет лучше, а в другом хуже. Фишка в том, что надо искать неизвестно что, на экране где тоже неизвестно что может находиться. Я не знаю какой тут надо разрабатывать ИИ и на какой основе.

[Cockney]

Я вот что ещё хотел сказать. Препроцессинг, а он вообще нужен? У тебя и так вроде всё быстро, какой смысл ещё чего-то придумывать. А самое главное, что вряд ли что-то можно сильно улучшить. В одном случае будет лучше, а в другом хуже. Фишка в том, что надо искать неизвестно что, на экране где тоже неизвестно что может находиться. Я не знаю какой тут надо разрабатывать ИИ и на какой основе.

В том то и дело, что быстро за счет него. По сути это "подготовка образов" для поиска, только автоматически. Т.е. выделение какой-то части по которой можно точно найти что-то на экране. Конечно, где-то хуже, где-то лучше, но и этот препроцессинг можно сделать как угодно. Можно выделять строго уникальные пиксели, можно скопления пикселей определенного цвета и т.д. Фишка в том, что основной алгоритм поиска не меняется, и мы просто снижаем кол-во данных для обработки. Да и утверждение о том, что ничего не известно немного неверно. У нас есть картинка, которую нужно найти, имеем пределы погрешности поиска, разбег каналов цвета и т.п.

[DarkMaster]

Cockney, подскажи, а можно как-то создать прозрачно указатель на массив битмапа с учетом выравниваний? Чтобы избежать лишней математики и копирования. pragma pack или еще как-то?

[Cockney]

Cockney, подскажи, а можно как-то создать прозрачно указатель на массив битмапа с учетом выравниваний? Чтобы избежать лишней математики и копирования. pragma pack или еще как-то?

Код

int stride = image->length - image->width * 3;
int pixelOffset = 0;

for (int y = 0; y < image->height; y++, pixelOffset += stride){
   for (int x = 0; x < image->width; x++, pixelOffset += 3) {
      image->data[pixelOffset] = 0;
      image->data[pixelOffset + 1] = 0;
      image->data[pixelOffset + 1] = 0;
   }
}

[Cockney]

Иначе говоря - просто создать указатель на непрерывный блок нельзя. Без копирования в смысле.

[DarkMaster]

Я, к сожалению, не случайно выбрал формулировку. Хотелось бы все-таки с луа все это делать (уж прости грешного). А по адресам там бегать только через cast, который садит скорость до безумия. Т.е. идейно обращение в виде arr[x][y], при этом очевидно, что компилятор должен понимать, что там есть выравнивание. Ну либо я просто не догоняю как без просадки скорости бегать чистыми указателями в рамках ffi.

Иначе говоря - просто создать указатель на непрерывный блок нельзя. Без копирования в смысле.

Ну вообще и да и нет. По крайней мере создав указатель на массив в ffi и указав тип данных ты спокойно можешь бегать индексами. Т.е. тут в чистом виде дает стрелять себе в ногу и речи о провеках чего либо просто нет - у тебя свободный доступ к памяти и ты спокойно можешь выйти за пределы массива с определенным шансом схватив эксепшн.

копировать же в память изображение, потом это изображения копировать еще раз меня коробит просто до какого-то безумия. быдлячество полное.

[Cockney]

при этом очевидно, что компилятор должен понимать, что там есть выравнивание.

Не должен. Да, выравнивание есть для полей структур и элементов массивов, но применить напрямую к битмапу нельзя, ибо компилятор вообще не в курсе, что вот у какого-то указателя там каждый условный 30 байт будет выравниванием и максимум что может сделать, это выравнивать каждый пиксель до машинного слова, а это несовместимо с самим форматом bmp + оверхед по памяти. А идея с доступом "arr[x][y]" (если речь именно о битмапе) не будет работать без просадок в чем-то ни на одном языке. Так устроен формат. Либо пихай в какие-то внутренние структуры и трать процессор на парсинг, либо каждый раз при обращении считай новое смещение.

Ну вообще и да и нет. По крайней мере создав указатель на массив в ffi и указав тип данных ты спокойно можешь бегать индексами. Т.е. тут в чистом виде дает стрелять себе в ногу и речи о провеках чего либо просто нет - у тебя свободный доступ к памяти и ты спокойно можешь выйти за пределы массива с определенным шансом схватив эксепшн.

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

Ну вообще и да и нет. По крайней мере создав указатель на массив в ffi и указав тип данных ты спокойно можешь бегать индексами.

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

быдлячество полное.

цена абстракций

[DarkMaster]

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

Я сказал, что дает стрелять в ногу - и это хорошо. Надо проверить - проверю.

Хочу посмотреть как будет выглядеть описание типа данных

Ну вот я тоже хочу, поэтому и спросил =)

[sutra]

Я уж просто перестал говорить на эту тему. Надоело. Смысл очень прост. Уйма примеров которые однозначно говорят, что при достижении какого-то количества итераций в циклах, lua начинает тормозить. Примерно в 4 раза, поэтому сделать скоростной и универсальный финд, на мой взгляд, проблематично. Буквально на днях, когда хотел попробовать сделать свой таймер (до того как мне показали красивое решение), натолкнулся опять на эти грабли. Там совсем всё просто было. НО при больших циклах - якорь. Это какая-то фишка компилятора, возможно и её можно обойти. Мне понятно одно, если этот якорь не устранить, то проблема со скоростью возникнет однозначно.

На своём финде тоже всё это обкатывал не раз. При малых зонах поиска - результат по скорости практически один в один как в бенчмарке (не учитывая потоки). Решил попробовать и распихал в разные потоки куски зон поиска - результат почти как в бенчмарке. НО стоило увеличить циклы (зоны поиска или величину картинок) - ЯКОРЬ.

[cirus]

Какой смысл играться со смещениями... работать с 32 битным изображением да и всё.

[DarkMaster]

НО при больших циклах - якорь.

Я наблюдал некоторые проблемы при большом количестве захватов изображений. Есть подозрение, что выделение памяти тут виновато. Для себя принял решение просто выделить постоянный буфер равный размеру экрана. Если что-то экстравагантное будет - увеличить буфер один раз и жить спокойно. По поводу пользовательских гетимиджей тоже можно подумать чтобы создавать некоторую область и не высвобожадть полностью даже при вызове deleteimage. Чтобы подобных граблей не было.

Какой смысл играться со смещениями... работать с 32 битным изображением да и всё.

Дергать изображение которое по факту 24 бита, конвертить в 32. В итоге время копирования больше, памяти жрется больше. Так сделать безусловно можно и на мой взгляд в данном случае очевидно, что лучше пожертвовать памятью, чем камнем при переборе, тем не менее хочется красиво.

[sutra]

Не думаю что память виновата. Устал повторять ... десятки раз, в разных случаях, наблюдались тормоза. Наверное просто так работает оптимизация. Сам момент тормозов я вычислить не смог. Каждый раз по разному реагирует. В том числе и при одновременной обработке нескольких изображений (тоже уже даже на реальных примерах показывал). Всегда ли наступают тормоза, я не знаю. Мне это уже не интересно. Ясно одно - факт тормоза присутствует, вот почему наверное на lua суперскорости на все случаи жизни получить не получится. Мне эти тормоза не мешают. Глупые гипотетические примеры ворочать фулХД для 1000 картинок я не рассматриваю. На практике всё очень даже неплохо выглядит. Во всяком случае всё что требуется искать лично мне ищется в разы быстрее, чем работает стандартный getimage. Теперь такой проблемы нет.

[sutra]

Вот буквально делал анализ экрана, снимал и записывал в файл образы размером 20*510 пикселей - почти 1000 кадров в секунду (749 файлов за 0,933 сек и теперь это точно 0,933). На адекватных циклах всё очень быстро работает.

[DarkMaster]

Мои подозрения подтвердились. Проблемы с падением производительности удалось воспроизвести. Резко росло количество GDI хендлов. Т.е. просто не удаляются старые изображения. У меня были изменения в delete и возвращаемых значениях getimage - отсюда несоответствие ожидаемых параметров, как следствие память и хендлы просто не чистились. Причем все было ровно, как говорил sutra - все начило работать медленнее и медленнее. При достижении ровно 10000 хендлов все умирало, количество больше не росло.

Вообще есть подозрения, что хендлы нужно убивать сразу. Как-то странно я разнес все это по разным функциям.

[Madeus]

Ждем фикса и рабочий findimage?)

[DarkMaster]

По колору фикс есть. Теперь стало интереснее и финдимидж довести. Скорее всего будет переход на 32 бита из-за проблем с выравниванием. Ибо читать по указателю можно только через cast, а cast оказался главным тормозом. Читать же через индексы массива хрен прочитаешь из-за друных смещений. Короче проблемы вроде как локализованы, дальше можно писать.

[DarkMaster]

Кстати по непоняткам с причинами, следствием и т.д. Оно тупить начинало не всегда. Обнаружено было, что только при отсутсвтии искомого цвета это происходило. А тестили естественно на живых примерах.

[sutra]

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

[Cockney]

Доброго времени суток. На протяжении долгого времени экспериментировал с подходами поиска когда была свободная минутка. Что изменилось:

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

2) Изменил алгоритм препроцессинга искомого изображения. Стало умнее, сильно режет нагрузку поиска, а значит ищется быстрее.

3) Различные недоработки которые смог поймать.


Если кому интересно - погоняйте, будет здорово если всплывет что-то серьезное.

P.s. пароль: uopilot

P.s.s. накидайте примеров в архивчиках вида (на чем идет поиск, что ищется и конфиг запуска, результаты)