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

[Madeus]

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

2 поиска) Если одна картинка ищем быстро, если больше то извините ожидайте мы ищем (с) Почта России

[sutra]

2 поиска) Если одна картинка ищем быстро, если больше то извините ожидайте мы ищем

Да на самом деле если не использовать процентовку схожести картинки, то ищется всего 1 сотую секунды. Я по этому и не парюсь. По факту всё изумительно ищется, тут просто вопрос принципа, откуда потеря скорости.

[DarkMaster]

Процентовка нужна. Надо мне искать сотню изображений - я не буду сидеть и рисовать их неделю, мне сделать надо) Если так каждый раз подбирать, то это можно бросать все дела в жизни и только сидеть и рисовать их, резать. Помню был проект, так там было под 1к изображений. Это же сколько надо их обрабатывать потом?

[sutra]

Да почему рисовать, почему резать? Всё ищется без процентовки, у меня это параметр sim (similar - похожесть) . Лично я её использую только при поиске перекрытых друг другом картинок (мишеней например и там нет таких размеров, всё быстро поэтому) ну и иногда возможен вариант, когда тоже без similar не получается, если может быть расположен на картинке прицел (и тоже нет пропуска такого гигантского количества пикселей). Всё остальное ищется диапазоном, который я задаю 2-мя параметрами dev - абсолютное отклонение (требуется обычно для тёмных пикселей) и acc - процент отклонения цвета. Мой алгоритм как раз и позволяет автоматом задавать поиск. Надо мне искать только "красненькое", не обращая внимание на другие пиксели картинки. Я и формирую псевдокартинку условием r=100, R=255 или как в твоём примере задал фон r=195 и всех делов.
На самом деле всё чудесненько и быстренько ищется. Просто если и similar ускорить - это будет КОСМОС.

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

[sutra]

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

[DarkMaster]

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

Частично прозрачный текст на изменяющемся фоне с нечеткими границами, отрисованный через сглаживание шрифтов. У меня было... Печальная история.

Полсекунды поиска на твою картинку - это всё равно очень много.

Стандартный финд - 7 соток. Я бы может и не трогал даже, но меня совсем не устраивает то, как там задается deviaton.

[sutra]

И ещё один довод, тоже уже говорил про это. Иногда наоборот эта процентовка только мешает искать то, что надо. Тоже надо думать и понимать какой процент схожести задавать. 80% - это очень много. Пятая часть предполагается мусор - это что же за картинка такая???

Частично прозрачный текст на изменяющемся фоне с нечеткими границами, отрисованный через сглаживание шрифтов. У меня было... Печальная история.

Да не поможет тут процентовка, диапазоном надо играть. ПРОЦЕНТОМ отклонения цвета, а не пропуском мусора.

Я понял про что ты говоришь. Так буковки то МАЛЕНЬКИЕ, там даже пропуск мусора не влияет на скорость. Да - это наиболее сложный поиск. Без головы юзер его не выполнит, а с головой я тебе найду запросто. Возможно придётся создать несколько наборов картинок, я такими наборами влёгкую побеждаю сглаживание. Всё ищется, на практике уже, а не в теории.

[DarkMaster]

Да не поможет тут процентовка, диапазоном надо играть. ПРОЦЕНТОМ отклонения цвета, а не пропуском мусора.

Угу, а потом оказывается, что один из самых контрастных и значимых пикселей прыгает в право-влево на единичку. А такие будут в каждом изображении при выше описанных условиях. И тут как раз точность очень сильно поможет. Обрезать весь фон тоже не реально. В итоге приходится искать не понятно что, и не дай бог еще спутать разные символы. Частично перекрытые изображения тоже бывают не так редко. Вообще из практики могу сказать, что если задаешь больше 95% точности, то это к прекрасным вечерам в пэинте. 92% самая золотая середина.

[sutra]

Я не возражаю 90% для буковок - ты даже не заметишь потерь скорости.

И, как правило, буковки ты ведь не ищешь по всему фулХД.

[DarkMaster]

Я не возражаю 90% для буковок

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

[sutra]

Вопрос стоит конкретно - АЛГОРИТМ - найти причину, вот и всё. Это даст прирост, а он лишним не бывает.

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

Да буковки ищутся (в смысле процесс поиска, а не результат )мгновенно при любых параметрах - они же МАЛЕНЬКИЕ!!!

[DarkMaster]

МАЛЕНЬКИЕ!!!

Это пока у тебя их не тыща картинок) Сглаживание, jpg эффекты, фон, прозарчность.

[sutra]

Это пока у тебя их не тыща картинок) Сглаживание, jpg эффекты, фон, прозарчность.

А ты пробовал? Я одним образом ищу примерно полторы тысячи, причём некоторые по нашим меркам огромные, типа 500*20, конечно я не лопачу весь экран, ищутся позиции, а по ним картинки.

До последнего времени самое долгое 27-28 тысячных - это был getimage.

Дарк, я же тебя не отговариваю, наоборот говорю, ищи причину, делай! (IMG:style_emoticons/default/biggrin.gif) Ну а если не получится, ну тогда обращайтесь, 12$ в час, буду искать ваши картинки. (IMG:style_emoticons/default/biggrin.gif)

[sutra]

И у тебя Дарк, всё-таки короткая память. Я ведь ещё в 19 году тебе говорил, в смысле спрашивал, а как ты игнорируя мусор (отсеивая какую-то часть пикселей) будешь отличать например "О" от "Q" или "1" от "l" . Пропуск мусора - это крайний случай, прибегать к которому надо абсолютно осознанно и понимая что должно искаться, а что нет. В большинстве случаев пропуск - это минус, так как это говорит лишь о том, что либо ищется не то что надо, либо что надо не ищется вовсе. Ну а в каких случаях требуется отсев уже устал повторять. У Кнайта изначально не было deviation и отсев нежелательных пикселей - это была просто необходимая данность. Потом всё было уже серьёзно переработано, но по умолчанию так остались 20% отсева (80% точности).

[sutra]

Главный минус у Кнайта, почему и используется так называемая точность, без которой частенько не ищется картинка - это то, что deviation - это процент отклонения. А какой процент отклонения задавать для пикселя с RGB (0,0,0)? У меня этот параметр - абсолютное значение (которое и нужно чтобы искались "тёмные" пиксели), процентовка идёт плюсом, и всё это в любых вариантах использования.

[sutra]

Я даже специальный скрипт делал, который мне показывал с какой гарантией ищется та или иная картинка, показывая допустимые граничные значения используемых мною параметров dev и acc в различных их сочетаниях. И я выбирал средние значения. Судя по моим экспериментам, запас варьирования всегда очень нехилый.

[sutra]

Дарк, наверное в скринилке, нужно всё-таки положительную высоту всегда прописывать - это типа норма. Наткнулся, что один старенький редактор не понимает файлы с отрицательной высотой. Короче, для себя принял именно общепринятый стандарт. Редактор - Paint Shop Pro 6 . Я им частенько пользуюсь. Установки не требует, простенький, не прихотливый.

Нет смысла изголяться. Перевёртывание происходит мгновенно, да и не только перевёртывание. Образ + скрин = молниеносно.

[sutra]

Дарк, у тебя там косячки в скринилке, забыл наверное, на автомате клепал - исправь. Они вроде ни на что не влияют, но чисто для порядка.

C.WriteFile(f, ffi.new("uint32_t[1]", h*w*3+54 )

Надо множить не на тройную ширину, а на длину строки, ну и далее тоже. Про то что там далее я не в теме (хотя все пишут по длине строки), но размер то файла точно врёт.

[sutra]

И мне как-то не понравилась запись в файл кусками. По древней, старпёрской привычке делать запись в файл одним оператором я сделал по-своему. Сначала сформировал единый заголовок, а потом допинываю требуемыми значениями.

Код

  ffi.C.memcpy(bmpHeader+2,ffi.new("uint32_t[1]",h*lD+54),4)
  ffi.C.memcpy(bmpHeader+18,ffi.new("uint32_t[1]",w),4)
  ffi.C.memcpy(bmpHeader+22,ffi.new("uint32_t[1]",h),4)
  ffi.C.memcpy(bmpHeader+34,ffi.new("uint32_t[1]",h*lD),4)

Соответственно запись заголовка в файл идёт за один заход.

[sutra]

Парни, спасибо вам за моё обучение! Как хорошо, что надоумили плюнуть на память!
Надоела мне эта возня с типами данных и адресами. Сделал один глобальный СИ-массив, под разные случаи жизни, видимый всеми и везде и никаких проблем. Например нулевой массив содержит 4-х байтовые величины, с индексами 1 и 2 - байтовые и т.д.. И теперь работа с выделением памяти под переменные просто отсутствует. И можно пихать что угодно, куда угодно, с минимальными потерями времени. Да, не эстетично, не правильно с точки зрения организации кода. Только на кой мне эта правильность, если lua (на мой вкус) сам трижды неправильный. Для примера, как переделал код и избавился от этих "режущих глаз" new:

Код

  CI[0][0]=h*lD+54  ffi.C.memcpy(HeaderBMP+2,CI[0],4)
  CI[0][0]=w        ffi.C.memcpy(HeaderBMP+18,CI[0],4)
  CI[0][0]=h        ffi.C.memcpy(HeaderBMP+22,CI[0],4)
  CI[0][0]=h*lD     ffi.C.memcpy(HeaderBMP+34,CI[0],4)
  for i=y2,y1,-1 do   -- цикл перевёртыш
      ffi.C.memcpy(CI[d]+iD,CI[s]+iS,w*3)  iD,iS=iD+lD,iS-lS
  end