Новая-старая функция IF_NOT_PIXEL_IN

[Vint]

Предлагаю вернуть если была или добавить функцию
IF_NOT_PIXEL_IN (x, y, x2, y2, color1, ...) - производит поиск пикселя НЕ СОВПАДАЮЩЕГО с заданными цветами в прямоугольной области буфера анализа.

Параметры
x, y - числовые координаты левого верхнего угла области поиска
x2, y2 - числовые координаты правого нижнего угла области поиска
color1, ... - цвета, игнорируемые фунуцией (цвета фона).

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

[dramster]

иии,ии,иии,  и дополнительный пораметр в ифпикселин (и в ифнотпикселин) - оначающий начальный угол сканирования экрана. 1, 2, 3 или 4 - с верхнего левого угла, с верх.правого, ниж.левого и нижнего правого соответственно. ну и тоже самое с ифпиктуреин  .

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

наглядно

[Johnny]

и позвольте спросить начерта? в чем практический смысл искать пиксель не совпадающий?

про направления - туда же. если вы знаете ожидаемое место появления - подгоняйте области.

[dramster]

про направления - туда же. если вы знаете ожидаемое место появления - подгоняйте области.

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

[Johnny]

таким образом можно определить только границы идеального объекта - прямоугольника. а вот простой ромб уже поставит в тупик данный подход.

[Vint]

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

и позвольте спросить начерта? в чем практический смысл искать пиксель не совпадающий?

Это же не сложно в отличии от направлений. Почти копи-паст.
А начерта? Часто нужно найти объекты произвольного цвета на равномерном фоне. Иногда можно выкрутится через колормод. Но бывают цвета близкие к фону и колормод их сжирает.
А уменьшать номер колормода... даже на 7 уровне уже 7 поисков.
И всё равно остаётся проблема если цвет отстоит от цвета фона < 0.5 расстояния между цветами в колормоде.
6 режим вообще не реальный с его 64 цветами.

[Johnny]

не хочу плодить костыли, которые выбиваются из общего стройного синтаксиса. вот это if_четотам с регистрами $_return - смотрится просто дико. теперь.

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

[Vint]

Нет сейчас рабочих примеров.
Ну что то типа этого...  Только переливов много. Это не реальный проект.

[Vint]

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

[Oraven]

Может проще добавить функцию обработки графики?!
Скажем задаем какие то цвета фона для исключения, а все остальные цвета функция перекрасит в заданный цвет. Таким образом останется только фон а все неизвестные цвета станут одним известным.
Дальше ищем его обычными функциями.

[Vint]

Можно и так, но чем это лучше?
Во первых дольше. Два раза нужно обработать графику.
А NOT это в условии чуть поменять и всё.

Можно и то и то сделать. Давно функционал не расширялся.

[Oraven]

Лучше тем что потребуется создать лишь одну функцию подобную PXLREPLACE. Можно визуально вывести  полученное в скриншот. Оценить что мы ищем. Можно даже искать одноцветную картинку по форме объекта.
Как твоя функция будет работать? Находить первый не совпадающий с фоном пиксел? А если надо найти все объекты то нужна уже NOT_SCANPXL что ли?

Во первых дольше. Два раза нужно обработать графику.

Да ладно, несколько дополнительных миллисекунд ничего не решат.

[dramster]

насчет обработки графики поддерживаю. бывает часто, что колормода мало, а в paint.net при коррекции можно вывести нужные зоны в нужные цвета.. конечно не знаю как это должно выглядеть, но если бы была обработка примерно как в paint.net - меню коррекция. инвертация, кривые, огрубление(тотже колормод), оттенок и насыщенность, чернобелый, сипея, уровни, яркость и контраст.
 конечно это я загнул, прям редактор какойто получится. но если так разобраться, вроде ничего сложного. вся эта коррекция сводится через определенные математические действия с цветами. даже можно их самому написать и менять в буфере через тотже  PXLREPLACE, но скорость...... . каждый пиксель менять придется.

во, я даже набросал по быстрому коррекцию в чернобелый:

Code: (clickermann) [Select]

$x1=578
$y1=962
$x2=718
$y2=1080

print("start")
GETSCREEN($x1,$y1,$x2,$y2)
SCREENSHOTEX($x1,$y1,$x2,$y2)
FOR($y=$y1,$y<$y2+1)
   FOR($x=$x1,$x<$x2+1)
      $c= pxl($x,$y)
      $gray=int((0.299*colorr($c))+(0.587*colorg($c))+(0.114*colorb($c)))
      PXLREPLACE($x,$y,$x,$y,$c,COLORGEN($gray,$gray,$gray))
   END_CYC
END_CYC
print("fin")

SCREENSHOTEX($x1,$y1,$x2,$y2)
haltбыло

стало

на выполнение ушло 16 сек.

[Vint]

Пришли отсюда:
http://crapware.aidf.org/forum/index.php?topic=2134.msg23102#msg23102

Для начала замерил у себя перевод в градации серого через PIXELREPLACE на образце 100х100 pxl.

// PXLREPLACE  100х100   10000 pxl
// 8100 ms                                0.81 ms/pxl

После попробовал через редактирование буфера.
Код такой:

Code: (clickermann) [Select]

STRSEPARATE("A:B:C:D:E:F", ":", $arr16) //===  перевод числа в HEX. Выход $HEX =
SUB(toHEX, $DEC)
    $HEX = ""
    WHILE($DEC > 0)
        $cel = INT($DEC/16)
        $ost = $DEC - $cel*16
        IF($ost > 9)
            $ost = $arr16[$ost - 10]
        END_IF
        $HEX = STRCONCAT($ost, $HEX)
        $DEC = $cel
    END_CYC
    //LOGWRITE($HEX)
END_SUB

SUB(GREYSCALE, $x1, $y1, $x2, $y2)
    GETSCREEN($x1, $y1, $x2, $y2)
    READMEM($pid, "004E20FC", 4)  // читаем адрес начала буфера в указателе
    $startbufwr = $_return1 + ($y1*($xmax+1)*4) + ($x1*4) // с этой ячейки начнем
    //LOGWRITE($_return1,"  $startbuf = ", $startbufwr)
   
    FOR($y=0, $y < ($y2 - $y1 + 1))
        $adrDECwr = $startbufwr + ($y*($xmax+1)*4)
        FOR($x=0, $x < ($x2 - $x1 + 1))
            $c = PXL($x1+$x, $y1+$y)
            $gray_canal = INT((0.299*COLORR($c)) + (0.587*COLORG($c)) + (0.114*COLORB($c)))
            $gray = COLORGEN($gray_canal, $gray_canal, $gray_canal)
            //LOGWRITE("$gray_canal = ", $gray_canal, "   ", $gray)
            toHEX($adrDECwr + $x)
            WRITEMEM($pid, $HEX, $gray, 4)
           
            $adrDECwr = $adrDECwr + 3
        END_CYC
    END_CYC
END_SUB
К сожалению выходит намного медленней, даже с учётом оптимизации

// GREYSCALE                           =  5.25 ms/pxl
// 10х10         ~555 мс,  ~552 мс        5.52 ms/pxl
//GREYSCALE(70, 75, 79, 84)
// 20х20   400 pxl  ~2167 мс              5.42 ms/pxl
//GREYSCALE(772, 432, 791, 451)
// 100х100  10000 pxl  ~53956 мс, 52431   5.25 ms/pxl
//GREYSCALE(750, 426, 849, 525)

Не просто медленней, а в 6.5 раз медленней. Я надеялся, что запись в память будет намного быстрее, чем не предназначенная для записи одного пикселя PXLREPLACE. Досадно.


Но движемся дальше, ради чего всё это затевалось.
Реализовал на AutoIt алгоритм из SCREENin3 и получил на 100х100  10000 pxl...

// 100х100  10000 pxl  ~1400 мс       0.14 ms/pxl

Всего в 6 раз быстрее кликера и PXLREPLACE. Ожидал большего.


Чуть оптимизировал и переделав структуру из DWORD (4 байта) в структуру равную длине строки пикселов стал читать и писать построчно по X.
Но ускорил всего на 9.2%

// 100х100  10000 pxl  ~1270 мс         0.127 ms/pxl

Дальше пока ничего не придумал. Позамеряв скорость разных этапов, выяснилось, сто чтение и обработка занимает примерно 400 мс и остальные 870 мс занимает запись. Как ускорить пока не знаю.

В любом случае пока итог:

Code: [Select]

100х100   10000 pxl
// PXLREPLACE    8100 ms            0.810 ms/pxl
// +AutiIt             1270 ms            0.127 ms/pxl

Для области 100х100    1.27 секунды вроде и ничего.
Но для 300х300 уже  11.43 секунды. Это медленно.
А не дай бог 1000х1000, то это уже 127 секунд. 2 минуты Карл!

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

[dramster]

http://crapware.aidf.org/forum/index.php?topic=2134.msg23102#msg23102
http://crapware.aidf.org/forum/index.php?topic=2390.msg23103#msg23103
да уж, у тебя пруха  .... у меня тоже такое бывает  .

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

будем надеяться, что джонни всеже прислушается к идее контраста. спрос на такую коррекцию, как видно, присутствует.


P.S.
да, контраст это здорово, но вот если бы максимально ускорить в кликере попиксельную запись в графический буфер  , так это бы вообще была сказка. каждый творил бы что хотел с этим буфером. жаль, что это скорее всего не так просто