Jump to content
Compvision.ru

Recommended Posts

Добрый день!

Хочу представить свой графический редактор с элементами компьютерного зрения "Лубок". Ссылка на скачивание: 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. Распространение программы приветствуется.

Share this post


Link to post
Share on other sites

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

detskiy43.thumb.png.0d4c77ea4d00566604b61d7a4546b37c.png

 

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

 

 

 

Share this post


Link to post
Share on other sites
4 минуты назад, Smorodov сказал:

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

 

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

 

Share this post


Link to post
Share on other sites
14 минуты назад, Nuzhny сказал:

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

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

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

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

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

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

 

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

 

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites
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. Переключаться с одной архитектуры на другую я не вижу смыслу, буду пока узко направленным специалистом.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites
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.

 

 

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites
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 пикселей. Количество проходов указывается в программе.

Share this post


Link to post
Share on other sites
4 hours ago, 2expres said:

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

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

Пример:

kot.thumb.png.585d6a4fa5b0efe55f8a9e9552e34eca.png

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

 

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

 

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

 

 

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Recently Browsing   0 members

    No registered users viewing this page.

×