36 сообщений в этой теме

Добрый день!

Хочу представить свой графический редактор с элементами компьютерного зрения "Лубок". Ссылка на скачивание: http://esm.ho.ua/Automat.html На сегодня программа позволяет редактировать/создавать изображения, проводить сегментацию изображения, преобразовывать растровые изображения в вектор. В качестве практического применения определяет штрихкоды на фотографиях EAN8, EAN13. Размер программы 110 килобайт!!! (именно кило, не мегабайт). Малый размер удалось получить применяя ассемблер и WinApi. Но малый размер не означает, что программа не требовательна к железу. При обработке 24 Мегапиксельной фотографии требуется память и быстродействие компьютера для сегментации изображения. Рекомендуемый характеристики ПК: оперативная память 2ГБ, процессор не хуже Athlon 3000+. Работает с WinXP, Windows 7, Windows 10 - то что реально проверено.

Как пользоваться смотри в программе Справка-помощь!!! В случае возникновения вопросов по программе задавайте их в этой ветке форума. При возникновении, каких либо неполадок буду рад получить конкретные замечания. Надеюсь, что книги "Лубок для чайников", "Лубок для профессионалов" и "уроки компьютерной графики с помощью программы Лубок" будут впереди:D.

Хочу так же отметить, что этот сайт 1 на котором даю ссылку на программу "Лубок".

P.S. Программа бесплатная!!!

P.P.S. Распространение программы приветствуется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Примеры использования:

detskiy43.thumb.png.93102a3b6d5a0dc745d3d890ce94f623.png

Допустим необходимо перевести данное изображение в вектор. Это изображение хорошего качества, потому отлично сегментируется. С помощью редактора "Лубок" загружаем картинку. Выбираем вкладку "Сегментация" - "8 связная сегментация". Для сглаживания структуры выбираем максимальную погрешность "25", а повторения достаточно "1". Нажимаем "Ok". Далее можно посмотреть удовлетворяет Вас сегментация включив "Выбор сегмента". Сегменты можно просмотреть нажимая левую кнопку мыши. Для получения векторного файла выбираем вкладку "Сегментация"-"Векторный файл .svg"-"3пкс". Далее смотрим папку, где расположен исходный файл и в ней будет файл *.svg с тем же названием. Масштаб - этого файла будет таким же, какой масштаб Вы выбрали перед векторизацией.

Пока все, отвечу на любые вопросы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это сродни демо сцене :), не часто такое встретишь.

Правда где-то читал : "Ассемблер аналогичен мату, иногда без него не обойтись, но говорить на нем постоянно не приветствуется". 

Если запустить программу и нажать ESC, то падает с ошибкой.

Функциональность пока не законченная, например при создании нового изображения не задать размер оного, навигация по изображению не очень удобна (привычно манипулировать масштабом и смещением при помощи мыши), предпросмотр при изменении параметров бы не помешал, ну и падает иногда.

Плюс к этому, ассемблер очень жестко привязан к архитектуре машины, на ARM, где это было бы уместно, этот редактор уже работать не будет, чего не скажешь о прогах на стандартном C, которые, если правильно написаны будут одинаково работать и на микроконтроллере и на настольной машине, при условии достаточности мощности конечно, и будут весить не намного больше, а то и меньше чем написанные вручную на асме, встроенные в СPP оптимизаторы сейчас работают очень хорошо, опять же при правильно написанном коде и грамотных настройках компилятора и линкера. Вот гляньте: https://forum.antichat.ru/threads/270620/ .

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

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
4 минуты назад, Smorodov сказал:

Это сродни демо сцене :), не часто такое встретишь.

Правда где-то читал : "Ассемблер аналогичен мату, иногда без него не обойтись, но говорить на нем постоянно не приветствуется". 

Если запустить программу и нажать ESC, то падает с ошибкой.

Функциональность пока не законченная, например при создании нового изображения не задать размер оного, навигация по изображению не очень удобна (привычно манипулировать масштабом и смещением при помощи мыши), предпросмотр при изменении параметров бы не помешал, ну и падает иногда.

Плюс к этому, ассемблер очень жестко привязан к архитектуре машины, на ARM, где это было бы уместно, этот редактор уже работать не будет, чего не скажешь о прогах на стандартном C, которые, если правильно написаны будут одинаково работать и на микроконтроллере и на настольной машине, при условии достаточности мощности конечно, и будут весить не намного больше, а то и меньше чем написанные вручную на асме, встроенные в СPP оптимизаторы сейчас работают очень хорошо, опять же при правильно написанном коде и грамотных настройках компилятора и линкера. Вот гляньте: https://forum.antichat.ru/threads/270620/ .

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

Спасибо, за первый обнаруженный ляп. Постараюсь исправить все обнаруженные ошибки. 

У меня желание работать в области компьютерного зрения в реальном масштабе времени. Для этих задач подходят только быстродействующие процессоры, но даже зачастую сегодня не хватает их производительности. Процессоры ARM по производительности в разы хуже, пока переход на них не вижу смысла. В случае возникновения острой необходимости перевести программу на ARM - есть успешный опыт автоматического перевода ассемблера X86 на ассемблер Z80, PIC18F (архитектура RISC).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это да, но если проект серьезный и нужно действительно быстро, есть камеры с GPU на борту, они работают быстрее чем CPU в большинстве случаев обработки изображений. 

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

Но да, есть алгоритмы которые плохо ложатся на массовый параллелизм здесь CPU-шный асм может пригодиться.

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

500 кадров в секунду при 4 МП - это конечно круто.

Такую обработку на одном процессоре, конечно, потянуть невозможно. Например, мы обрабатываем штрихкод 16 МП камерой за время 0,2 секунды. Итого только 5 кадров в секунду, но для некоторых применений этого вполне достаточно. На сегодня никакой процессор ARM такую обработку не потянет.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Зря вы так про ARM. Те же Nvidia Tegra активно используются в беспилотниках и других автономных устройствах и вполне успешно обрабатывают в реальном времени большие потоки данных.

Кроме того, все последние заказчики, которые у меня были хотели работу программ либо на Линукс серверах, либо на телефонах (Андроид и iOS). То есть места ассемблеру практически нет. Какие это были приложения:

- видеоаналитика для охранных систем (в том числе на поворотных камерах и камер с беспилотников);

- распознавание документов, визиток, кретидок;

- распознавание лиц;

- улучшение качества изображений.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
14 минуты назад, Nuzhny сказал:

Зря вы так про ARM. Те же Nvidia Tegra активно используются в беспилотниках и других автономных устройствах и вполне успешно обрабатывают в реальном времени большие потоки данных.

Кроме того, все последние заказчики, которые у меня были хотели работу программ либо на Линукс серверах, либо на телефонах (Андроид и iOS). То есть места ассемблеру практически нет. Какие это были приложения:

- видеоаналитика для охранных систем (в том числе на поворотных камерах и камер с беспилотников);

- распознавание документов, визиток, кретидок;

- распознавание лиц;

- улучшение качества изображений.

 

Компьютерное зрение - очень обширная тема, в которой множество приложений. Мы для себя выбираем нишу быстродействующие процессоры и быстрые программы. Сравните параметры процессоров X86 и ARM по быстродействию, разница на порядок?! Я с вами согласен, что это узкое применение, но и моя программа не сильно привязана к Windows. Использовано только оболочка для запуска, отображения(WinAPi) и GDI+ (для преобразования форматов в BitMap). Поэтому мы можем перейти на любую операционную систему Linux, DOS или свою.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Было бы интересно сравнить по скорости.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я сравниваю не столько x86 и ARM, сколько x86 и GPU (а это CUDA или OpenCL). Разница в быстродействии между последними Теграми и core i7 может вдруг оказаться не в пользу последнего. Такова реальность.

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

P.S. Агнера Фога читал, немного в оптимизации разбираюсь.

Глюков много.

1. Курсор постоянно мигает при движении со стрелочки на крести.

2. Тултипы прорисовываются плохо.

3. Интерфейс постоянно тормозит и замирает.

4. При размытии или детекции объектов у меня часть изображения (полоска внизу) не перерисовывается.

5. В меню пункт "Закрыть" ничего не делает.

6. На диск сохраняются временные файлы, которые не удаляются. Я открыл картинку на много мегапикселей, потыкал мышью в него и получил несколько гигабайт на диске.

Ну и всякое другое. Для того, чтобы пользоваться было комфортно, я бы добавил двойную буферизацию и многопоточность. Простой MS Paint работает намного быстрее! Тестировать и тестировать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
10 минут назад, Smorodov сказал:

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

Было бы интересно сравнить по скорости.

Фильтр Соболя выполняется должен выполнятся быстро, хотя измеритель времени туда мы не подключили. Это примитивная функция обработки окном 3х3 изображения за один проход (модифицированный быстрый алгоритм). Измерители времени подключены только к программам, которые выполняются долго - это сегментация изображения, векторизация и определение штрихкода. Время выполнения вы можете посмотреть в нижнем статусном окне в миллисекундах. Если нужно можем вставить измеритель времени и на другие подпрограммы - это не сложно. Мне будет сложнее разобраться с OpenCV и честно говоря обломно:( , т.к. большое количество людей с ним уже работает, а я хочу найти свою не затоптанную поляну. Но буду очень признателен, если Вы проведете измерения.

24 минуты назад, Nuzhny сказал:

Я сравниваю не столько x86 и ARM, сколько x86 и GPU (а это CUDA или OpenCL). Разница в быстродействии между последними Теграми и core i7 может вдруг оказаться не в пользу последнего. Такова реальность.

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

P.S. Агнера Фога читал, немного в оптимизации разбираюсь.

В данный момент снова началась гонка между двумя мастодонтами AMD и Intel. AMD выпустила Ryzen, теперь подождем чем ответит Intel. Переключаться с одной архитектуры на другую я не вижу смыслу, буду пока узко направленным специалистом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Для 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 вычесть, но думаю оно не очень существенно в данном случае.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проблема с быстродействием примитивов типа Собеля или Гаусса в целом успешно решается индустрией без участия конечных программистов предметной области.

Есть уже бесплатные Intel IPP, появляется OpenVX. Мне под Интел из базовых вещей самому ничего оптимизировать уже и не надо. Всё есть.

AMD выпустила Ryzen? Пусть выпускает и OpenVX под него.

Есть ArrayFire и другие библиотеки.

Кто в том же OpenCV пишет код на CUDA? Добровольцы? Нет, в основном сама Nvidia и пишет. OpenCL? Intel, AMD. Производители железа сами заботятся о быстродействии, сами оптимизируют алгоритмы, раздают свои библиотеки, пишут на ассемблере (интрисиках) библиотечный код. Им же продавать железо надо.

Qualcomm делает свою библиотеку компьютерного зрения под свою платформу.

 

Я лучше сосредоточусь на задаче в прикладной области. Сейчас зачастую даже С++ и OpenCL - это слишком низкий уровень для разработки алгоритмов. Хватает того же Питона с головой. Таковы времена.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, Smorodov сказал:

Для 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 вычесть, но думаю оно не очень существенно в данном случае.

abcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabc

Мы начинали с фильтров выделения границ. Думаю, как и многие начинал со шрека:

shrek.PNG.2c9a16e1779d3bbaeae04e9419043668.PNG

Результат в редакторе "Лубок":

shrek1.PNG.099136249df0a22ea98ab57ebd94ce87.PNG

Это фильтр Соболя(Эффекты-Карандаш Т), который дополняется преобразованием в черно-белое изображение и инверсия. Не понятно, что дальше делать с этими выделенными краями, но это очень быстрый и простой алгоритм. 

Мне не понятно почему алгоритм Канни выполняется быстрее, чем Соболя в OpenCV... Я не знаю OpenCV, но из ходя из теории алгоритм Канни требует больших вычислений. 

Меня больше интересует сегментация изображений. Она позволяет вычислять размеры, форму, количество объектов. Это гораздо более ресурсоемкий процесс интересно сравнить получаемые результаты, например, с OpenCV. Хотелось сравнить результаты по быстродействию и качеству сегментации.

P.S. На каком процессоре вы получили данные результаты? замеры времени я делаю с помощью TimeGetTime. Бывает расхождение на 16 мс в исполнении на моем ноутбуке, я так понимаю это отнимает Windows.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Проц: Core i7-4790 3.6 GHz.

В данном случае canny идет первым, и там выделяется память, это время. Если выделить вне цикла, то будет ближе ко второму набору значений. 

Знал бы что за алгоритмы вы использовали, сравнил бы, но боюсь готовых решений на этот счет в OpenCV нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, Nuzhny сказал:

Проблема с быстродействием примитивов типа Собеля или Гаусса в целом успешно решается индустрией без участия конечных программистов предметной области.

Есть уже бесплатные Intel IPP, появляется OpenVX. Мне под Интел из базовых вещей самому ничего оптимизировать уже и не надо. Всё есть.

AMD выпустила Ryzen? Пусть выпускает и OpenVX под него.

Есть ArrayFire и другие библиотеки.

Кто в том же OpenCV пишет код на CUDA? Добровольцы? Нет, в основном сама Nvidia и пишет. OpenCL? Intel, AMD. Производители железа сами заботятся о быстродействии, сами оптимизируют алгоритмы, раздают свои библиотеки, пишут на ассемблере (интрисиках) библиотечный код. Им же продавать железо надо.

Qualcomm делает свою библиотеку компьютерного зрения под свою платформу.

 

Я лучше сосредоточусь на задаче в прикладной области. Сейчас зачастую даже С++ и OpenCL - это слишком низкий уровень для разработки алгоритмов. Хватает того же Питона с головой. Таковы времена.

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

4 минуты назад, Smorodov сказал:

Проц: Core i7-4790 3.6 GHz.

В данном случае canny идет первым, и там выделяется память, это время. Если выделить вне цикла, то будет ближе ко второму набору значений. 

Знал бы что за алгоритмы вы использовали, сравнил бы, но боюсь готовых решений на этот счет в OpenCV нет.

В основном все и простые и сложные алгоритмы обработки в области компьютерного зрения, на мой взгляд, сводятся к последовательному прохождению одним или несколькими окнами обрабатываемого изображения. Это относится к фильтру Соболя, детектору определения кожи, быстродействующей сегментации. Для 4-х связной сегментации берем окно из 5 пикселей, для восьмисвязной сегментации окно 3х3 пикселей. Количество проходов указывается в программе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
4 hours ago, 2expres said:

Мне будет сложнее разобраться с OpenCV и честно говоря обломно:( , т.к. большое количество людей с ним уже работает, а я хочу найти свою не затоптанную поляну.

Традиционный vision - это поляна, которую уже все затоптали и ушли с неё...

Ну а что касается оптимизаций, путем переписывания всего алгоритма на асме, то это крайне не рационально. Под CPU заоптимизировать boatleneck'и на TBB. или в крайнем случае на C + SIMD интринсиках - это куда быстрее, а результат, скорей всего, будет +/- тот-же (я ставлю на то, что опытный оптимизатор при таком подходе обойдет асемблерную реализацию). 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо, SmorodovЗа первую найденную оплошность в обработчике клавиатуры не стоял ret. Если нажать не нужную клавишу программа вываливалась. А так как всегда нажимались только нужные клавиши - это и не видели. Это еще раз доказывает, что программу должны тестировать тестировщики, а не разработчики. Новая версия уже на нашем сайте http://esm.ho.ua/Automat.html

P.S. Давайте отвлечемся от ассемблера. Интересно мнение людей, которые воспользовались программой в области сегментации/векторизации или определения штрихкода. Было интересно получить Ваше мнение в сравнение с другими продуктами. Остальные вещи можно наверняка найти в других редакторах.

P.P.S. Так же интересует тема пост сегментной обработки изображений.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

О векторизации могу сказать, что не понятно значение параметров алгоритма, и когда я установил количество пропускаемых сегментов при сохранении равным 1, у меня размер svg добрался до 1.7 Gb, дальше программу я остановил. Может задавать параметры как здесь: https://www.vectorizer.io/ например ?

Ваш результат с установками по умолчанию: 123.svg

Результат с https://www.vectorizer.io/ : 123 (1).svg

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

 

PS: Есть хороший сайт с алгоритмами обработки изображений : http://www.ipol.im/ там и реализации их на CPP.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, есть проблема с мелкими отбрасываемыми сегментами. С этим, конечно, надо что делать, но пока процессе поиска решения. Буду рад любой наводке по этой теме. Прошу дать исходное изображение для экспериментов. Посмотрел сайт https://www.vectorizer.io/ :

1. Они обрабатывают изображения до 1 МБайта.

2. Перед обработкой они делают размытие изображения и преобразование полноцветного RGB в изображение 4, 8, 16 или 32 цвета.

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

Пример:

kot.thumb.png.585d6a4fa5b0efe55f8a9e9552e34eca.png

результат с сайта kot.svg. Результат 32 цвета и без размывки.

результат нашей программой после корректировки исходного изображения: kot1.svg 

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Реальные фотографии очень плохо поддаются векторизации. Для них не проходит оптимизация векторного файла:( для нашей программы. Когда проводятся проводятся границы между сегментами, каждый сегмент описывается отдельно. А надо было бы использовать только одну границу или одного или другого. Иначе за счет погрешности апроксимации между сегментами появляются зазоры, которые сильно портят картинку. Так что у нас есть еще работа по совершенствованию наших алгоритмов.

Итак загружаем картинку. Выбираем Эффекты-Размыть-Легко!!! Сегментация - 8 связная сегментация. Погрешность устанавливаем в 2, повторения 4. Для более качественного изображения, количество повторений нужно уменьшить, но увеличится объем .svg файла. Нажимаем "Ok". Далее "Сегментация-векторный файл .svg"-БЕЗ ОПТИМИЗАЦИИ. Отбрасываемых сегментов выбираем "0". Результат: dev.svg.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо, за оценку. А что такое генетический алгоритм?

Как можно сравнить скорость выполнения сегментации и/или векторизации? По онлайн сравнить нельзя:(

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну вот например:

 

 

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

 

Тут я игрался с прямоугольниками: 

 

 

Кстати есть и исходник: 

правда он был написан 2012 году, может что то уже устарело. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте учётную запись или войдите для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать учётную запись

Зарегистрируйтесь для создания учётной записи. Это просто!


Зарегистрировать учётную запись

Войти

Уже зарегистрированы? Войдите здесь.


Войти сейчас

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу