Помогите освоить LUA Опции

[DarkMaster]

Так что давайте закроем эту тему.

Эх. Жаль. Давно не было таких интересных и продуктивных дискуссий.

[sutra]

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

Эх. Жаль. Давно не было таких интересных и продуктивных дискуссий.

Да брось, я ляпнул - ты ответил. Ну если скажете чего, поддержу, а из пустого в порожнее чего переливать то!!
(IMG:style_emoticons/default/biggrin.gif)

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

[DarkMaster]

Лично меня подкупила скорость обработки

Можно прикрутить поиск с помощью пользовательской функции =)

[sutra]

Можно прикрутить поиск с помощью пользовательской функции =)

Ну всё верно. Кстати ты спрашивал типа чем мой не устроил? Твой - это какой? Ты про распознаватель который в теме cirus-а?


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

Всю статистику я всегда собирал и прямиком запихивал в эксель, поэтому сейчас у меня подробнейшая таблица на каждый символ и я до такой степени скрупулезно всё анализировал, что сейчас распознаю число аж вот так FindRGB(address,len,244,639, 688,639,825,639,"R(0-255)",10000)


Это ещё по старинке вызывается параллельный скрипт на lua.

[DarkMaster]

А когда ты дал СИ шный инструментарий, я вообще прямо загорелся - ну нет никаких ограничений, реально нет.

Могу еще рассказать, как сделать дллку и написать на реально чистом си и прилинковать через ffi. Соответственно скорость совсем улетит вверх) Знаний чтобы писать ифы и форы там не надо.

[sutra]

Обрати внимание достаточно анализ ОДНОЙ строки пикселей. Я точно знаю все варианты этой строки. Это я делал ещё для тормозного Пилота.

Могу еще рассказать, как сделать дллку и написать на реально чистом си и прилинковать через ffi.

Спасибо, Дарк, возможно обращусь. Спасибо, но надо пока хоть что-то доделать, а то я уже целый месяц топчусь на месте - результата конечного нет. Интерес есть, результата (ради чего всё затевалось) нет.


Это знаешь типа как раньше, полез поворотник в Жигулях посмотреть, подправить, а в итоге коробку передач разобрал.

[sutra]

Дарк, я тут просто пробежался по темам форума, по вопросам и ответам. Что могу сказать, конечно не все зададут вопрос, но всё-таки, статистика - вещь неумолимая. Кто спросил как работает findimage? Как сделать быстрее? Как воспользоваться той или иной функцией? Вот лично я задавал вопросы по синтаксису, потому, что не знаю ничего, а люди то вообще спрашивают А КАК? Там проблемки поглубже, там не синтаксис, там основы программирования и алгоритмирования. И мы им прикрутим deviation и accurace? Надо так ... чем проще, тем лучше, а для особо одарённых просто менюшку "advanced" и мелким шрифтом и в 3-й уровень вложенности.

[DarkMaster]

И мы им прикрутим deviation и accurace?

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

Код

local arr, err = findimage(
    x1,y1,x2,y2,
    {[[path]]},
    2, 90, 1, 4)

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

Сообщение отредактировал DarkMaster - 15.12.2018, 5:45

[sutra]

А вообще классная компания (чуть не сказал тусовка) собралась. Балом правит W(hite) Светлый Князь, Разруливает Тёмный Мастер. Незримое око у серого кардинала cirus (перевода не знаю). Ну и я в роли королевского шута (надеюсь мне простят мои шутки).

Так просто нагляднее и проще

Нет, ну ты красавец, мне нравится твой оптимизм, значит всё не так плохо.


cirus, наверное это RUS-сский СИ-шник. Я буду SovietUnion... дальше личная информация.

[sutra]

Анекдот из реальной жизни.
90-е годы. Формирование ЖКХ. Соседка встречает соседа и говорит
- Николай, за воду будем теперь платить отдельно.
Николай в ответ
- Какому на х..рен заводу?

[sutra]

В продолжение темы...
Жена мужу.
- Ты ребёнку на сок дал? (подразумевалось денег)
Ответ.
- Какой носок?

[sutra]

Код

local cscrX,cscrY,cfx1,cfy1,cfx2,cfy2,cl=ffi.new("uint16_t"),ffi.new("uint16_t"),ffi.new("uint16_t"),ffi.new("uint16_t"),ffi.new("uint16_t"),ffi.new("uint16_t"),ffi.new("uint16_t")

Как то можно от таких соплей избавиться? Чтобы нужные переменные объявить один раз нужным типом или придётся терпеть универсальность lua, которая в данном случае у меня вызывает улыбку.
И возникла ещё одна идея, но не уверен в правильности своих мыслей. Есть смысл перейти с for-ов например на repeat-ы, с использованием СИ переменных? Так как в for-ах переменные локальные и по определению lua-шные. Вроде по логике должно быстрее работать с репитами и вайлами?

[sutra]

Вроде допинал сравнение картинок. Убрал считывание картинки целиком в память. Считывается ровно столько, сколько необходимо. В нормальных ситуациях прирост по скорости несопоставимо быстрее. А вот если куча холостых сравнений, тогда может быть и хуже (но это уже вопрос, как правильно делать картинки). А ещё сделал возможность анализировать не все три канала RGB, а вплоть до одного. Если радуги нет, как в моём случае, скорость выростает ещё в 3 раза и всё работает как надо. Вроде удалось переплюнуть (только при правильных картинках) скорость моего джипеговского распознавателя. Всё-таки пока работал на Пилотовском языке - это был ПРОРЫВ, проверил его ещё раз досконально. Скорость его выполнения всего 15-20 миллисекунд и плюс его ещё и в том, что скорость не зависит от условий, сам алгоритм проверяет (отсекает) ВСЕ варианты картинок.

[sutra]

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

[DarkMaster]

Как то можно от таких соплей избавиться? Чтобы нужные переменные объявить один раз нужным типом или придётся терпеть универсальность lua, которая в данном случае у меня вызывает улыбку.

Все зависит от области, где вы их объявлете. Можно их просто сделать upvalue.

Код

local function my_func() end -- прототип функции
do -- создаем карман namespace, аналогичный while, for, function
    local my_var = 123
    function my_func()
        my_var = my_var + 1
        print(my_var)
    end
end

Обратите внимание, что upvalue в данном случае не будет высвобождаться и значение будет сохраняться, но за пределам do end вы его прочитать не сможете. Вообще это логично и очевидно - если вы используете переменную, то вы ее инициализруете каждый раз, если высвобождаете память. Где-то это не так? Конкретно в данном случае возможно имеет смысл объявить структуру, а не набор переменных.

А ещё сделал возможность анализировать не все три канала RGB, а вплоть до одного.

А теперь делай сравнение по минимальному значению канала и максимальному. Я фильтры покрутил и офигел =) Крайне полезная вещь. Так же в теории может пригодится сумма каналов. На самом деле я думал, что именно сумма даст лучший результат для того, чтобы избежать рендеринга и сглаживания шрифтов. Однако по тем случаям, что я анализировал лучшим результатом был минимум и максимум. Контраст оказался просто огромным.

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

Читай выше (IMG:style_emoticons/default/wink.gif)

Сообщение отредактировал DarkMaster - 18.12.2018, 5:06

[sutra]

Спасибо Дарк, да, я тут тоже всё экспериментирую. Вопрос по repeat снят. Я удивился, но скорость с репитом выросла ровно в 2 раза, а это очень нехило.

что именно сумма даст лучший результат для того

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

[sutra]

В общем в критичных по скорости функциях нужно использовать только СИ-шные переменные и следовательно избавляться от for-ов, а использовать репиты и вайлы в которых роль индексов выполняют СИ-шные переменные. Выигрыш по скорости колоссальный. Основные тормоза именно на циклах.

[sutra]

Ахренеть, добился скорости поиска среди 1000 картинок, размером 500х23, при условии просмотра ВСЕХ картинок аж всего за ТРИ тысячных секунды. Думаю на этом можно поставить жирную точку.

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

[sutra]

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

Код

      k=0
      repeat
        sg[k]=rmem("unsigned char*",indg+k)[0]
        sl[k]=rmem("unsigned char*",indl+k)[0]
        if math.abs(sg[k]-sl[k])>cdev then  return 0  end
        k=k+1
      until k>cch[code]

Вот такой цикл при сравнительном тесте выполнялся 2,559 сек.

А вот такой цикл 1,559

Код

      for k=0,2 do
        sg[k]=rmem("unsigned char*",indg+k)[0]
        sl[k]=rmem("unsigned char*",indl+k)[0]
        if math.abs(sg[k]-sl[k])>cdev then  return 0  end
      end

Надо тестить с разными типами переменных.

Этих типов мама не горюй. Дарк, есть предпочтения? Какие типы обрабатываются лучше? Знаковые? Беззнаковые? и скольки битовые? 16 32 или вообще 64?

[DarkMaster]

k=0

сишной объявите.

Этих типов мама не горюй. Дарк, есть предпочтения? Какие типы обрабатываются лучше? Знаковые? Беззнаковые? и скольки битовые? 16 32 или вообще 64?

n страниц назад я выкладывал тесты по типам и ваши результаты тестов там тоже есть =)

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

Попрбуй использовать для сравнения наименьший и наибольший каналы. Это дало лучший результат чем суммы. Т.е.:
rgb
100 255 35 -- берем 35
25 50 200 -- берем 25
сравниваем 25 и 35.
На первый взгляд маразм, но при анализе фильтрами в фоторедакторе именно этот вариант был очень хорош по результатам. Ну и наоборот максимумы.