Smorodov

Каждые N итераций, прогоняется тестовая выборка. Да вроде задается в solver.prototxt, но точно не скажу, давно не запускал caffe из командной строки. Обучал с основном через DIGITS.

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

Можно на хабре, например: https://habrahabr.ru/company/recognitor/blog/277781/ Ну и поиск в гугле по "habrahabr сверточная сеть", выдаст много материала на русском.

Еще одна сетка из последних (Mask R-CNN): https://arxiv.org/pdf/1703.06870.pdf Из поста google группы: "Facebook can do image segmentation which is essentially the ground truth now, using Mask R-CNN. And they can do it at 5 fps with code not optimised for speed. " Without tricks, Mask R-CNN outperforms all existing, single-model entries on every (COCO) task, including the COCO 2016 challenge winners."" Обещают исходники выложить.

Датасет можно взять здесь: http://www.robots.ox.ac.uk/~vgg/data/hands/ вроде неплохой. По поводу сети, здесь не все так тривиально, придется поизучать фреймворки (caffe, tensorflow, keras, ... ), лучше всего они сопряжены с питоном. Но у TF и caffe есть примеры сопряжения с CPP. И нужно отделить обучение сети от ее реализации в программе.

Можно еще Keras рассмотреть как упрощение к TF. Google вроде его хочет встроить в TF : http://www.fast.ai/2017/01/03/keras/

Из CUDA 8 убрали grab cut, на седьмую возвращаться не хочется, кто нибудь встречал вменяемую реализацию ?

Нашел хорошую либу (CPU) (headers only), здесь пишут что быстрее NPP-шной реализации. Взять можно здесь: http://www.gridcut.com/downloads.php . Бесплатна для некоммерческого использования. Проверил, примеры собираются без танцев, есть мультилейбл:

А гороскоп с магнетометром чем плохи ?

Вот эта штука умеет искать по штрих коду в google: https://play.google.com/store/apps/details?id=com.google.zxing.client.android&hl=ru и вот эта (правда она использует внешний детектор кодов, например тот что выше) и умеет искать по внешнему виду упаковки тоже: https://play.google.com/store/apps/details?id=com.google.android.apps.unveil&hl=ru Плюс встречал сканеры акцизных марок, и винных этикеток с отзывами о винах.

Если бы все было так просто, то не было бы огрмной кучи алгоритмов вычитания фона: https://www.behance.net/gallery/3943089/BGS-Library-A-Background-Subtraction-Library , а они есть, ибо снег, дождь, туман, тени, листья, трава, пыль, солнечный свет, который постоянно меняется, шум в сеноре камеры, ветер качающий камеру.... не дают делать простые алгоримы.

Да я в общем то не про заполнение фигурами говорю, просто можно рассматривать такое изображение как некоторую функцию от небольшого количества параметров. То есть у нас имеется генератор изображений, выход которого зависит от вектора параметров. В зависимости от значений этих параметров, изображение выходит более или менее похожим на оригинал. У Вас сейчас параметры выбираются наобум. Но можно выбирать исходя из некоторой целевой функции. То есть изменяя параметры, мы максимизируем или минимизируем значение целевой функции. Целевая функция, определяет формально что мы хотим. Допустим мы хотим чтобы изображения были похожи, добавляем в функцию измеритель похожести (PSNR например), хотим чтобы изображение было разумного размера и, следовательно, добавляем получаемый размер со знаком минус, т.к. хотим меньше, после этого балансируем слагаемые при помощи коэффициентов. Дальше запускаем оптимизацию целевой функции от параметров. Что касается пост обработки, то думается тут графовые методы должны неплохо работать (graph cut и ему подобные). Ну и вот статейка http://graphicon.ru/html/2006/proceedings/papers/wr54_86_ZaugolnovaYurin.pdf близкая к теме ну на хабре https://habrahabr.ru/company/intel/blog/266347/ ну и марковские поля https://inclass.kaggle.com/c/mrf .

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

Да, результат много лучше чем на vectorizer. Можно попробовать пристроить генетический алгоритм для оптимизации параметров, если получится будет супер.

Исходное изображение:

О векторизации могу сказать, что не понятно значение параметров алгоритма, и когда я установил количество пропускаемых сегментов при сохранении равным 1, у меня размер svg добрался до 1.7 Gb, дальше программу я остановил. Может задавать параметры как здесь: https://www.vectorizer.io/ например ? Ваш результат с установками по умолчанию: 123.svg Результат с https://www.vectorizer.io/ : 123 (1).svg Причем на экране после сегментации отображается картинка много лучшего качества, чем воспроизводится вектором. PS: Есть хороший сайт с алгоритмами обработки изображений : http://www.ipol.im/ там и реализации их на CPP.

Проц: Core i7-4790 3.6 GHz. В данном случае canny идет первым, и там выделяется память, это время. Если выделить вне цикла, то будет ближе ко второму набору значений. Знал бы что за алгоритмы вы использовали, сравнил бы, но боюсь готовых решений на этот счет в OpenCV нет.

Для Opencv, изображение 512x512: Для 100 циклов усреднения. Canny ~3 ms Sobel 3x3 1.7 ms Blur 3x3 0.2 ms Для 1000 циклов усреднения: Canny ~1.25 ms Sobel 3x3 1.62 ms Blur 3x3 0.2 ms Код: #include <iostream> #include <vector> #include "opencv2/opencv.hpp" using namespace std; using namespace cv; //----------------------------------------------------------------------------------------------------- // //----------------------------------------------------------------------------------------------------- int main(int argc, unsigned int** argv) { int64 t0, t1; double msecs; string fname = "F:/ImagesForTest/lena.jpg"; Mat src=imread(fname,0); if (src.empty()) { return 0; } Mat dst; // Canny cout << "Canny" << endl; t0 = cv::getTickCount(); for (int i = 0; i < 1000; ++i) { cv::Canny(src, dst, 100, 200, 3); } t1 = cv::getTickCount(); msecs = (t1 - t0) / cv::getTickFrequency()/1000.0*1000; cout << msecs << " ms"<< endl; imshow("src", src); imshow("dst", dst); waitKey(100); // Sobel cout << "Sobel 3x3" << endl; t0 = cv::getTickCount(); for (int i = 0; i < 1000; ++i) { cv::Sobel(src, dst, -1, 1, 0); } t1 = cv::getTickCount(); msecs = (t1 - t0) / cv::getTickFrequency() / 1000.0 * 1000; cout << msecs << " ms" << endl; imshow("src", src); imshow("dst", dst); waitKey(100); // Blur cout << "Blur 3x3" << endl; t0 = cv::getTickCount(); for (int i = 0; i < 1000; ++i) { cv::GaussianBlur(src, dst, Size(3, 3), 1.5); } t1 = cv::getTickCount(); msecs = (t1 - t0) / cv::getTickFrequency() / 1000.0 * 1000; cout << msecs << " ms" << endl; imshow("src", src); imshow("dst", dst); waitKey(0); } Здесь еще нужно время затрачиваемое на сам for вычесть, но думаю оно не очень существенно в данном случае.

Кстати, о быстрых программах. Вы сравнивали свою реализацию с OpenCV-шной для того же Canny или Sobel и других аналогов реализованного вами на асме ? Было бы интересно сравнить по скорости.

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

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

Это да, но если проект серьезный и нужно действительно быстро, есть камеры с GPU на борту, они работают быстрее чем CPU в большинстве случаев обработки изображений. Пример: https://www.ximea.com/en/products/application-specific-oem-and-custom-cameras/smart-cameras-with-gpu-enhancement и тут нужно еще сравнить стоимость написания кода на асме и стоимость покупки камеры с GPU на борту и написания кода для на CUDA / С. Не факт что асм прога будет дешевле. Но да, есть алгоритмы которые плохо ложатся на массовый параллелизм здесь CPU-шный асм может пригодиться. А трансляторы с асма на асм ... думаю вся оптимизация летит к чертям при таких действиях. Если это делается при переводе на некий мата-язык, то уж лучше C использовать там компилятор еще код посмотрит.

Это сродни демо сцене , не часто такое встретишь. Правда где-то читал : "Ассемблер аналогичен мату, иногда без него не обойтись, но говорить на нем постоянно не приветствуется". Если запустить программу и нажать ESC, то падает с ошибкой. Функциональность пока не законченная, например при создании нового изображения не задать размер оного, навигация по изображению не очень удобна (привычно манипулировать масштабом и смещением при помощи мыши), предпросмотр при изменении параметров бы не помешал, ну и падает иногда. Плюс к этому, ассемблер очень жестко привязан к архитектуре машины, на ARM, где это было бы уместно, этот редактор уже работать не будет, чего не скажешь о прогах на стандартном C, которые, если правильно написаны будут одинаково работать и на микроконтроллере и на настольной машине, при условии достаточности мощности конечно, и будут весить не намного больше, а то и меньше чем написанные вручную на асме, встроенные в СPP оптимизаторы сейчас работают очень хорошо, опять же при правильно написанном коде и грамотных настройках компилятора и линкера. Вот гляньте: https://forum.antichat.ru/threads/270620/ . Мне кажется, оптимально было бы идти от прототипа к оптимизированной реализации. В начале обеспечить необходимый функционал и модульность на языке более высокого уровня (хоть на питоне), а затем проводить оптимизацию модулей (например переводя критические участки на ассемблер).

Я делал threshold по вероятности, затем искал максимумы.

Не, не сложно, большую часть работы делает сглаживание. Я только нахожу 2-3 точки ( в осях "вероятнисть", "масштаб" ), где значения вероятности максимальны, считаю взвешенную вероятностями сумму масштабов и нормирую суммой вероятностей. Получается такая линейная интерполяция на вершине горки образованной размытием.