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

[sutra]

И кстати, и вот это всё становится не нужным (с чем я так мучался изначально)

Код

local dwbuf = ffi.new'DWORD[1]'

Всё очень просто получается

Код

ffi.C.WriteFile(f,HeaderBMP,54,CI[0],0)  log(CI[0][0]) -- =54

Ещё раз всем спасибо!!! Наконец то я в своей среде обитания. Могу делать что хочу и как хочу.

[cirus]

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

В таком виде код становится трудно читаемым и понимаемым.
Первых четыре строки, а это 8 операций, можно заменить одним вызовом fii.new, в котором выделится память и заполнится структура.

[sutra]

в котором выделится память и заполнится структура

Это всё понятно, я тут просто изголялся. Но, иногда очень даже не вредно не трогать память. А главное, меня убивает тот факт, что напрямую ничего не сделаешь. Тут с типами просто беда (по крайней мере у меня). Даже странно, не знаю виноват ли тут lua, но если я подсовываю в тот же memcpy переменную созданную казалось бы точно также, тем же new - он ругается, мол число, а если элемент массива, заглатывает за милу душу. Хотя вроде должно быть понятно, что если я сую переменную в качестве буфера, так и воспринимать её надо как адрес. Короче, ни хрена я не понимаю как тут всё работает. Смысл получается такой, любое присваивание в lua запросто испоганит при этом тип, а закинуть самому в переменную нужное значение - нужен не числовой тип - круг замкнулся. Короче, сделал, победил и то ладно.


А про структуру я просто забыл. Надо будет попробовать, а возьмёт ли её WriteFile или опять будет ругаться.

[sutra]

По идее не хватает элементарного оператора типа addr(чего_угодно), хотя чего только остального не наворочано.

Спасибо Cirus, со структурой всё работает как надо. В смысле что создаёшь, правишь что хочешь и всё нормуль.

В общем, насколько я понял, если lua не может преобразовать тип данных, то всё нормально, в противном случае жди подвоха.

[sutra]

Да, главный метод - метод тыка. Я правильно понял что вот эта хрень, смысла которой я не понимаю

Код

  #pragma pack (push, 1)

означает перевёртывание младших и старших байтов?

Вот и думаю - это безграничные возможности или всё-таки отсутствие стандартов.

[Cockney]

Да, главный метод - метод тыка. Я правильно понял что вот эта хрень, смысла которой я не понимаю

Код

  #pragma pack (push, 1)

означает перевёртывание младших и старших байтов?

Вот и думаю - это безграничные возможности или всё-таки отсутствие стандартов.

Отключение выравнивания по машинному слову. Пригодно только для работы с сетью

[DarkMaster]

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

Скринилка на моем getimage/saveimage не сработала?

Нет смысла изголяться.

И да и нет. Есть старый getimage с методом 2, который нужно будет дотянуть.

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

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

Хм. Тестил спецом этот момент и вроде выравнивания не было. Перепроверю. Спасибо.

И мне как-то не понравилась запись в файл кусками

Возможно касательно заголовка - да. Тело не стоит слеплять. Просто потому что надо будет копировать битовую маску в некотоырй темп, а если это какие-нибудь 4-8к, то это и вовсе уже будет под 100 метров.

Отключение выравнивания по машинному слову. Пригодно только для работы с сетью

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

[Cockney]

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

А этого мало ? Это нужно только в форме клея между системами, а при интенсивной обработке это очень мешает. Ну собственно по этому Си и быстрее) Хотя в делфи тоже есть директивы подобные.

[DarkMaster]

А этого мало ?

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

[Cockney]

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

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

[sutra]

Я не знаю про сеть. Я ни в какой не в сети. Однако, если эту прагму не задействовать, структура bmp заголовка будет "битой", байты будут перевёрнуты (младшие - старшие). Вопрос другой, А вот если я копирую memcpy, то всё нормально (хотя я не знаю как должно быть "нормально"), сначала идут младшие, потом старшие байты. Собственно вопрос то в чём, а как лежат данные изначально (что самому проверять что где и как лежит)? И если данные расположены сикось накось - это влияет на скорость?? И если есть выравнивание по машинному слову, вопрос, так может всё надо выравнивать, чтоб машину не троллить? Может и в этом есть тормоза? В том же финде. Х. его знает что там подсовывается МАШИНЕ.

Дарк, твоя скринилка работает (я не тестил на всех прогах), вопрос все ли проги поймут косяк, а то что там косяк - это точно. Я тупо сравнивал файлы, кто, что и как делает. Все множат на ДЛИНУ. В обоих параметрах.

Короче, это выравнивание - штука очень интересная, надо глаз, да глаз за всем этим, особенно если ещё и описывать сии структуры битами, типа 0xFFFF00FF

[sutra]

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

[sutra]

Дарк, если будешь делать loadimage, используя структуру заголовков. Смотри какую я выявил вещь, совершенно случайно, сделав глупый тест, пробуя грузить и сохранять разные файлы, валявшиеся у меня в какой-то свалке. Короче параметр в заголовке, который определяет размер битовой маски - biSizeImage запросто может быть равен нулю. Что характерно, все вьюеры и редакторы понимают такие файлы без вопросов. Только вот читать их надо исключительно учитывая только размер файла и смещение данных. Короче надо читать в буфер такое количество байт: bfSize - bfOffBits , а не такое: biSizeImage. Названия полей структуры как у Cirus.

[cirus]

biSizeImage запросто может быть равен нулю.

В описании структуры это и так написано.
BITMAPINFOHEADER structure

biSizeImage
The size, in bytes, of the image. This may be set to zero for BI_RGB bitmaps.

все вьюеры и редакторы понимают такие файлы без вопросов

Потому что размер вычисляется исходя из ширины, высоты и битности.

[sutra]

Потому что размер вычисляется исходя из ширины, высоты и битности.

Так я про это и сказал. Вопрос только зачем тогда он вообще нужен этот параметр biSizeImage? Если он ну вот совсем не нужен по факту. Я просто как обычно сделал идеальный вариант, как ты говоришь исключил лишнее математическое действие, а получил фигу, пришлось добавить одно математическое действие. Но есть и плюс. Я вообще выкинул эти структуры за ненадобностью:

Код

//    typedef struct {BYTE rgbBlue; BYTE rgbGreen; BYTE rgbRed; BYTE rgbReserved;} RGBQUAD;
//    typedef struct {BITMAPINFOHEADER bmiHeader; RGBQUAD bmiColors[1];} BITMAPINFO;

Оставил только BITMAPINFOHEADER, не вижу никакого им применения, если ни о каких 8 и 4 битах цветности не может быть и речи, спрашивается зачем тащить этот хлам совместимости. Ну или может я как обычно ничего не понимаю. Только всё работает как надо, исключая лишние телодвижения.

В описании структуры это и так написано.

Извините - это я не читал, но читал пару других (попроще и короче), там про это ни слова.

Вывод напрашивается простой, как уже говорил, со стандартами - напряг, всё надо по 10 раз проверять.

Мы же не получаем сжатый вариант маски? Нет. 24 бита (ну или пускай 32) - Да. Вот я и выкинул всё ненужное. С точки зрения обучения - полезно было посмотреть что к чему, на практике всё проще.

И вообще я вынес формирование заголовков за пределы функции. Я сканирую экран десятки раз в секунду, часами и сутками. Спрашивается, зачем мне постоянно напрягать память? Только лишнее электричество потр<вырезано анти-матом>ть. Всё упростил до безобразия и всё работает как надо.

[cirus]

Можно не использовать выравнивание, массив бит GetDIBits всё равно получит.
Оно нужно только если заголовок записывать в файл, иначе вместо 14 байт запишет 16.

всё надо по 10 раз проверять.

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

Я вообще выкинул эти структуры за ненадобностью

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

[sutra]

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

А я именно это и отметил, что полезно посмотреть все возможности и отдельное спасибо за это. Только сообразить, не понимая основ, что является обязательным для конкретных действий, а что можно и проигнорировать - это тоже обучение, и это для меня намного сложнее. Потому что не зная откуда валятся ошибки, начинаешь тупо использовать метод тыка. Я достаточно долго чесал репу, дотошно пытаясь понять что и как делается, и в каких случаях, прежде чем понял, что эти структуры не нужны практически в 99,(9)% случаев, во всяком случае применимо к нашим задачам.
Теперь по поводу оптимизации кода. Может на скорость также влияет и тип используемых данных? Я использую для хранения и сравнения каналов RGB байтовые переменные, а может нужно использовать 32 битные типы или даже 64 битные? Наверное выравнивание по машинному слову делается не только для совместимости, а ещё и для оптимизации. И вопрос, а можно целиком сделать в скрипте блок на СИ? И если это возможно, может есть смысл использовать такие блоки для тяжело нагруженных циклов?

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

В общем то конечно ДА. Но обычно читаешь инструкцию, когда уже ничего не получается. (IMG:style_emoticons/default/biggrin.gif)
Хочется побыстрее и попроще достичь желаемого результата. Как правило, зачастую даже и не подозреваешь, что есть какие-то подводные камни, в казалось бы элементарных действиях. А по факту - настолько много разных нюансов и озвучиваются эти нюансы "на самой последней страничке", в теме "для самых продвинутых" - очень грубо конечно высказался, но смысл примерно такой.

[sutra]

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

if j>sim then ... -- j - счётчик пропускаемых пикселей, sim - максимум пропусков

Так вот если sim равен 1, то выполняется 37 831 490 итераций циклов за 38,5 секунды, менее 1 ляма в секунду.
А для примера если sim равен 3, выполняется 75 651 410 итераций циклов за 1,05 секунды, более 72 лямов в секунду.
ЭТО ДАЖЕ НЕ ПОРЯДОК - это просто мистика. Вот такая вот арифметика, я подумываю над тем, а не запретить ли вообще единицу, и насильно присваивать большее значение.
И попробую ещё на СИ-шных переменных проверить.

[sutra]

Вот ведь прикол, переделал sim в СИ-шную переменную - тормоз улетучился. НО, переделал опять на обычную - тормоз не возобновился, как-будто канализацию у lua пробило. Короче чудеса, та и только. Но лучше всё-таки всё по максимуму переводить на СИ.

Ни хрена не получается. Опять тормоза ВО ВСЕХ вариантах использования единички.

[sutra]

Победил тупорылость компилятора тупорылостью кода. Изначально счётчик j равнялся нулю.
Сделал так: j=1 sim=sim+1 тормоза остались
А вот так: j=2 sim=sim+2 всё летает.
Вот как хотите господа Профи, так и понимайте, что это за хрень и каким таким загадочным образом это влияет на скорость чуть ли не в 100 раз.

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