Раздвоение личности std::string под minGW (сборка openCV)

http://mxe.cc
make opencv

Копать надо, прежде всего, с того, что не использовать OpenCV! Зачем тебе эта жирная тормозная библиотека?

Есть вероятность, что в сторону _GLIBCXX_USE_CXX11_ABI

Можно подумать его ещё как-то собрать можно... Он уже собран, вопрос - как с этим теперь жить.

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

Спасибо, похоже что-то в этом есть. В minGW такого макроса нет и в opencv он не упоминается, однако какие-то макросы из этой серии есть. Надо копать...

стандартный MinGW раньше вообще не умел в unicode. был отдельный пропатченный MinGW-w64, который в юникод умел. может, ты на эти старые грабли наступил? правда, это было давно. но мало ли. может, они так и не запилили поддержку.

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

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

Не очень понял, как его использовать. Попробовал просто определить в самом начале - эффекта ноль.

через флаг компилятора -D, вестимо.

но это моё предположение. флаг может быть другой. он может требоваться самой библиотеке. надо смотреть хэдеры.

Пробовал ещё шаманить с дефайнами и прочим в обоих проектах. Пока результатов никаких. Они и теже функции упорно не совпадают сигнатурами. :(

Use mingw-w64. Это раз. Сверься, чтобы линковало к одной и той же libstdc++, а то вроде как раз в мингв его джва. Это два.

Так я изначально писал, что проблема была у тех, у кого их две. Но вот про mingw как раз информации на эту тему нет. Как определить, что их две и какая именно используется? Не понимаю, почему расхождения под одинм компилятором.

С 64 как-то пробовал работать пару лет назад (надо было 64 что-то собрать) - что-то там не зашло. Так на 32 и сижу.

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

Неоткуда. Свежая система. Там из нестандартного только сам mingw которого я руками прописывал.

Я сам писал.

Знакомый вообще нафигачил такое, что целый спектрограф трассирует! И модель практически 1-в-1 реальное железо повторяет!!!

А OpenCV — говно. Это как абдурина, только та для далеких от электроники, а эта для далеких от нормальных численных методов.

Та у меня тож один такой есть. Фотоны считает. Можно подумать так мало людей, далёких от численных методов. Не нужно путать рабочий девайс и прототип. Одно дело нужен софт/железо для использования в продакшене, а другое - мне вот прямо сейчас нужно запилить прототип, для проверки идеи, при этом никаких наработок в этой области нет. Для второго и на констркторе лего с моторчиками запилить не грех если оно заработает.

при чём тут численные методы? это способ задействовать видеокарту в вычислениях. причём в параллельных. в каком месте их использовать - дело десятое.

а делать повторение осцилла 1-в-1 в софте - вот это точно наркомания.

ты путаешь opencv и opencl.

так это одно и то же, только в профиль. железо-то других функций не имеет.

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

OpenCV (Open Source Computer Vision Library)

OpenCL (Open Computing Language)

Каким раком они друг к другу (кроме того, что наверно OpenCV можно собрать под OpenCL)

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

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

всё это заточено именно на параллельность и GPU. можно GPU не юзать. будет медленно и печально.

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

opencv собирался тем же самым компилятором, что и проект?

Тем же, на той же машине. В этом и загадка.

Но opencv собирался через cmake со всеми настройками, которые там были. Я пытался разобраться, что там происходит, но мало что понял. Никогда с ним сам не работал. Ничего особенного вроде указания конкретной библиотеки или специфичных дефайнов не заметил, но мог и пропустить что-нибудь.

Я не очень помню чё там как под виндой, но, вроде бы бинари собранные с дебажным рантаймом и с релизным не совместимы. Так же как и бинари собранные со статическим и динамическим рантаймом.

О чём линкер может тебе и намекать ;)

Если сложно - скачай cmake-gui и разберись с флагами. Вангую, что у тебя проблема с ABI строк. Отсюда и куча ошибок линковки.

Да ладно! Тогда бы невозможно было подключить в дебаге ни одной чужой либы, которые в дебаге никто (в здравом уме) распространять не будет. Но я проверю...

OpenCV можно юзать и без GPU. Из всего вышесказанного видно, что Вы просто пытаетесь каким-то странным образом оправдать свой фейл. Выше уже на это намекали ни раз. OpenCV - сборник алгоритмов для работы с изображениями. OpenCL - всего лишь один из фреймворков для написания параллельных алгоритмов. Внезапно, OpenCV может собираться с поддержкой OpenCL.

Был бы весь OpenCV про параллельность, все бы алгоритмы параллельные наверное были. Но это не так.

Да он в комплекте с cmake есть, через него и собирал. Но там никаких интересных параметров не заметил за те н-дцать раз, что я пытался его пересобирать с разными флагами.

Что у меня проблема в нём - это понятно. Непонятно - откуда и как она случилась. И что с ней делать.

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

OpenCV создан специально для GPU? А где это написано, можно ссылочку, пожалуйста?

Есть аналоги OpenCV, которые не заточены под GPU и которые следует выбирать вместо OpenCV, если я планирую запускать их на CPU? Leptonica что ли? Или Leptonica тоже для GPU? Я сейчас говорю про обработку изображений: бинаризации там всякие, Canny и иже с ними.

Парадоксально, но факт. При переключении на релиз один из референсов пропал (в смысле - ошибка пропала). Но не все. И сигнатуры пропавшего в либах нет. Та, что есть - с либами как и раньше не совпадает. Скорее всего его оптимизатор просто выпил за ненадобностью.

Покажи флаги, с какими собрал OpenCV. И флаги, с каким собираешь своё приложение.

OpenCV пофиг на гпу. Его можно собрать и без его поддержки. Да и не все алгоритмы вообще на нём работают.

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

Ты это не мне рассказывай :-)

Ну не абстрактно говори «огромное множество», а назови конкретные либы, которые следует использовать вместо OpenCV, если мне не нужна параллельность и работа на GPU.

как математик, открою тебе секрет: любые либы для работы с матрицами. там ничего кроме этого нет.

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

Своё - стандартно. Пробовал включать/выключать с11 только и принудительно указывать либу -lstdc++ Сейчас дефолт только: -m32 -g С opencv сложнее. Где там смотреть их? Там cmake что-то химичит по результатам настроек. В гуи видны некоторые очевидные, но там дофига всего, в т.ч. и малопонятного. И как оттуда скопировать неясно. Вроде в makefile ничего особенного не видел.

как математик, открою тебе секрет: любые либы для работы с матрицами. там ничего кроме этого нет.

Это логически вытекло из того, что изображения представляются в памяти матрицами что ли? Серьезно?

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

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

Генерится файл CMakeCache.txt, в котором будет указано, что ты там поменял в cmake-gui. Также при запуске cmake он в лог пишет, какие опции с какими значениями были выбраны

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

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

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

Кстати вышеперечисленное как раз не очень сложно. Только писанины много.

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

Просто назови эти библиотеки. Мне действительно хочется на них взглянуть. Раз ты утверждаешь, что они есть и тем более в изобилии, то думаю не составит труда назвать хоть одну.

Я выше называл уже Leptonica (и то это немного другое). Ещё?