2expres
-
Количество публикаций
102 -
Зарегистрирован
-
Посещение
-
Days Won
3
Сообщения, опубликованные пользователем 2expres
-
-
1 час назад, DennerV сказал:одойдет, я потому-что заранее не известно что искать, Т.е. задача заключается в сравнении 2-х плат в показать расхождения (отсутствующий или лишний элемент), например показать синий кусок пластика на фото
При обработке приведенных Вами изображений я вижу следующие проблемы:
1. Это освещение. Оно должно быть мягким, равномерным и не давать бликов.
2. Как правило элементы на разных платах установлены по разному, могут быть смещения, резисторы, конденсаторы, транзисторы, диоды могут быть под небольшими углами (что допускается по ГОСТу). Как вы планируете это учитывать?
Я пытался решить вопрос с контролем качества печатных плат (целостность дорожек). Теоретически все получается, но столкнулся с проблемой освещения. Не удалось создать равномерное освещение. Сравнение проводил путем сегментации изображения и сравнения количества и площади сегментов. Если сегментов больше, то обрыв дорожки. Если меньше "закоротка".
-
А как будет с таким изображением?
или 
-
Я правильно понимаю, что это задача определения угла горизонта для беспилотника?
-
Спасибо, за ответы. Оставляю идею реализации детектора движению - значит, не мое это.
Тогда хочу реализовать определить товара соответствует он штрихкоду или нет. Это может быть интересно совместно с определителем штрихкодов, который я уже реализовал. Там нет ветра, снега и с тенями проще, можно сделать искусственное освещение. Товар, так же как и штрихкод должен определяться под любым углом и сравниваться с базой данных. Должно производится так же автоматическое формирование базы данных, т.е. раз сфотографировав новый товар он автоматически заносится в базу данных. Никто не встречал готовых решений в этом направлении?
-
Детектор движения можно реализовать и без суперпикселей, применяя сегментацию. Сравнили 2 картинки, нашли разность между нами. Предположим белый фон - это тот что не меняется, черным это изменение между 2 картинками (перемещаемые объекты). Провели сегментацию. Учитывая, что у нас только 2 цвета черный и белый сегментация будет очень быстрой. Самый большой черный сегмент и будет перемещаемым объектом, малые сегменты, которые могут быть из-за дождя, снега и/или ветра отбрасываем. Далее находим контур этого объекта и подсвечиваем. Как на Ваш взгляд нет тут подводных камней?
-
18 часов назад, Smorodov сказал:Ну и вот статейка http://graphicon.ru/html/2006/proceedings/papers/wr54_86_ZaugolnovaYurin.pdf близкая к теме ну на хабре https://habrahabr.ru/company/intel/blog/266347/ ну и марковские поля https://inclass.kaggle.com/c/mrf .
Спасибо, буду разбирать.
По поводу коэффициентов сегментации, мы выложили редактор в открытый доступ с надеждой, что какое то количество людей им будет пользоваться и расскажут, какие коэффициенты использовались в том или ином случае. Так же важна предварительная обработка исходного изображения, такая как размывка и преобразование цветов, то что делается онлайн трассировщике, ссылку на который Вы давали. Для преобразования цветов, есть мысли выполнять цветную гистограмму и оставлять ограниченное количество цветов. В трассировщике онлайн максимальное количество цветов всего 32!!! Это очень мало. Начинать надо с 256 и до 4096 цветов для получения более или менее реалистичного изображения. Алгоритм цвета наиболее часто встречаемые заполняются в таблицу, а остальные цвета заменяются на ближайшие из таблицы.
15 часов назад, Nuzhny сказал:Мне кажется, что одним из самых продуманных и математически обоснованных методов сегментации являются суперпиксели. Они локализованы, достаточно структурированы и, самое главное, достаточно понятно, что с ними делать дальше. Можно трекать их на видео, можно с уверенностью сказать, что какой-нибудь большой ошибки в сегментации не будет (как тот же flood fill с большим порогом). Прекрасно сокращают размерность по сравнению с обычными пикселями и не приносят лишней сложности.
Вот.
Получаемые нами сегменты можно рассматривать, как суперпиксели? Получили мы суперпиксели, как их дальше использовать?
-
Интересны Ваши идеи. Конечно можно было бы заполнять полученные сегменты кругами и другими фигурами. Можно заполнять фигурами с ободками, прямоугольники будут в виде кирпичной кладки. Развитие редактора в этом направлении - это арт-искусство, но нам более интересно техническое применение. По поводу сегментации написаны сотни статей, защитили десятки диссертаций, а по пост сегментной обработке очень мало информации. Может потому что не получены практические результаты?
http://www.nihilogic.dk/labs/evolving-images/ - ответ 404
-
Спасибо, за оценку. А что такое генетический алгоритм?
Как можно сравнить скорость выполнения сегментации и/или векторизации? По онлайн сравнить нельзя:(
-
Реальные фотографии очень плохо поддаются векторизации. Для них не проходит оптимизация векторного файла:( для нашей программы. Когда проводятся проводятся границы между сегментами, каждый сегмент описывается отдельно. А надо было бы использовать только одну границу или одного или другого. Иначе за счет погрешности апроксимации между сегментами появляются зазоры, которые сильно портят картинку. Так что у нас есть еще работа по совершенствованию наших алгоритмов.
Итак загружаем картинку. Выбираем Эффекты-Размыть-Легко!!! Сегментация - 8 связная сегментация. Погрешность устанавливаем в 2, повторения 4. Для более качественного изображения, количество повторений нужно уменьшить, но увеличится объем .svg файла. Нажимаем "Ok". Далее "Сегментация-векторный файл .svg"-БЕЗ ОПТИМИЗАЦИИ. Отбрасываемых сегментов выбираем "0". Результат: dev.svg.
На мой взгляд по качеству передачи исходного изображения она лучше, т.к. более естественный цвет глаз и меньше пятен. Объем файла чуть меньше. Если мы доработаем оптимизацию, как было сказано выше - это позволит сокращать размер файла или с тем же размером получать лучшее качество.
-
Да, есть проблема с мелкими отбрасываемыми сегментами. С этим, конечно, надо что делать, но пока процессе поиска решения. Буду рад любой наводке по этой теме. Прошу дать исходное изображение для экспериментов. Посмотрел сайт https://www.vectorizer.io/ :
1. Они обрабатывают изображения до 1 МБайта.
2. Перед обработкой они делают размытие изображения и преобразование полноцветного RGB в изображение 4, 8, 16 или 32 цвета.
Эти действия можно сделать в нашем или другом редакторе до сегментации. Я бы разделил сегментацию изображения на техническую сегментацию для определения объектов и творческую для получения красивых картинок. Красивые картинки можно получать и нашим редактором, нужно время и фантазия корректирую вручную исходное изображение.
Пример:
результат с сайта kot.svg. Результат 32 цвета и без размывки.
результат нашей программой после корректировки исходного изображения: kot1.svg
Погрешность - это разница в между объединяемыми пикселями. Повторения - количество проходов с добавлением на каждый проход погрешности.
Оптимизация SVG файла - это апрокимация прямыми линиями (хотелось бы кривыми Безье, но это в будущем). Погрешность - это максимальное отклонение прямой от реальных точек. Чем больше погрешность тем меньше файл, но и большее искажение объекта. Все зависит от конечных целей пользователя.
-
Спасибо, Smorodov! За первую найденную оплошность в обработчике клавиатуры не стоял ret. Если нажать не нужную клавишу программа вываливалась. А так как всегда нажимались только нужные клавиши - это и не видели. Это еще раз доказывает, что программу должны тестировать тестировщики, а не разработчики. Новая версия уже на нашем сайте http://esm.ho.ua/Automat.html.
P.S. Давайте отвлечемся от ассемблера. Интересно мнение людей, которые воспользовались программой в области сегментации/векторизации или определения штрихкода. Было интересно получить Ваше мнение в сравнение с другими продуктами. Остальные вещи можно наверняка найти в других редакторах.
P.P.S. Так же интересует тема пост сегментной обработки изображений.
-
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 пикселей. Количество проходов указывается в программе.
-
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
Мы начинали с фильтров выделения границ. Думаю, как и многие начинал со шрека:
Результат в редакторе "Лубок":
Это фильтр Соболя(Эффекты-Карандаш Т), который дополняется преобразованием в черно-белое изображение и инверсия. Не понятно, что дальше делать с этими выделенными краями, но это очень быстрый и простой алгоритм.
Мне не понятно почему алгоритм Канни выполняется быстрее, чем Соболя в OpenCV... Я не знаю OpenCV, но из ходя из теории алгоритм Канни требует больших вычислений.
Меня больше интересует сегментация изображений. Она позволяет вычислять размеры, форму, количество объектов. Это гораздо более ресурсоемкий процесс интересно сравнить получаемые результаты, например, с OpenCV. Хотелось сравнить результаты по быстродействию и качеству сегментации.
P.S. На каком процессоре вы получили данные результаты? замеры времени я делаю с помощью TimeGetTime. Бывает расхождение на 16 мс в исполнении на моем ноутбуке, я так понимаю это отнимает Windows.
-
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. Переключаться с одной архитектуры на другую я не вижу смыслу, буду пока узко направленным специалистом.
-
14 минуты назад, Nuzhny сказал:Зря вы так про ARM. Те же Nvidia Tegra активно используются в беспилотниках и других автономных устройствах и вполне успешно обрабатывают в реальном времени большие потоки данных.
Кроме того, все последние заказчики, которые у меня были хотели работу программ либо на Линукс серверах, либо на телефонах (Андроид и iOS). То есть места ассемблеру практически нет. Какие это были приложения:
- видеоаналитика для охранных систем (в том числе на поворотных камерах и камер с беспилотников);
- распознавание документов, визиток, кретидок;
- распознавание лиц;
- улучшение качества изображений.
Компьютерное зрение - очень обширная тема, в которой множество приложений. Мы для себя выбираем нишу быстродействующие процессоры и быстрые программы. Сравните параметры процессоров X86 и ARM по быстродействию, разница на порядок?! Я с вами согласен, что это узкое применение, но и моя программа не сильно привязана к Windows. Использовано только оболочка для запуска, отображения(WinAPi) и GDI+ (для преобразования форматов в BitMap). Поэтому мы можем перейти на любую операционную систему Linux, DOS или свою.
-
Добрый день!
Ищу задачи в области компьютерного зрения.Мной написана программа "Лубок" (http://esm.ho.ua/Automat.html) - это графический редактор с элементами компьютерного зрения. Он позволяет сегментировать изображения, преобразовывать растровые изображения в вектор, реализованное практическое применение определение штрихкодов. Что я могу предложить заказчику, перед тем как взяться за работу протестировать все имеющиеся у меня алгоритмы в программе "Лубок" применительно к вашей задаче. После этого я смогу сделать заключению смогу выполнить поставленную задачу или нет.
Специализация: построение быстро выполнимых алгоритмов для решения задач в реальном времени. Уже сейчас я могу находить объекты на изображении, оценивать их размеры, количество, форму. Я не могу выполнить абсолютно все задачи в компьютерном зрении - но перед тем, как взяться за новую задачу, я проверю возможность ее решения.
-
500 кадров в секунду при 4 МП - это конечно круто.
Такую обработку на одном процессоре, конечно, потянуть невозможно. Например, мы обрабатываем штрихкод 16 МП камерой за время 0,2 секунды. Итого только 5 кадров в секунду, но для некоторых применений этого вполне достаточно. На сегодня никакой процессор ARM такую обработку не потянет.
По поводу языка программирования теоретически можно писать даже на Delphi с ассемблерными вставками, но мы не хотим привязываться к Windows. В быстродействующих и надежных системах Windows вообще не должно быть. А редактор - это стенд для отладки наших возможностей в компьютерном зрении, просто тотальное большинство имеет Windows.
-
4 минуты назад, Smorodov сказал:Это сродни демо сцене
, не часто такое встретишь.
Правда где-то читал : "Ассемблер аналогичен мату, иногда без него не обойтись, но говорить на нем постоянно не приветствуется".
Если запустить программу и нажать ESC, то падает с ошибкой.
Функциональность пока не законченная, например при создании нового изображения не задать размер оного, навигация по изображению не очень удобна (привычно манипулировать масштабом и смещением при помощи мыши), предпросмотр при изменении параметров бы не помешал, ну и падает иногда.
Плюс к этому, ассемблер очень жестко привязан к архитектуре машины, на ARM, где это было бы уместно, этот редактор уже работать не будет, чего не скажешь о прогах на стандартном C, которые, если правильно написаны будут одинаково работать и на микроконтроллере и на настольной машине, при условии достаточности мощности конечно, и будут весить не намного больше, а то и меньше чем написанные вручную на асме, встроенные в СPP оптимизаторы сейчас работают очень хорошо, опять же при правильно написанном коде и грамотных настройках компилятора и линкера. Вот гляньте: https://forum.antichat.ru/threads/270620/ .
Мне кажется, оптимально было бы идти от прототипа к оптимизированной реализации. В начале обеспечить необходимый функционал и модульность на языке более высокого уровня (хоть на питоне), а затем проводить оптимизацию модулей (например переводя критические участки на ассемблер).
Спасибо, за первый обнаруженный ляп. Постараюсь исправить все обнаруженные ошибки.
У меня желание работать в области компьютерного зрения в реальном масштабе времени. Для этих задач подходят только быстродействующие процессоры, но даже зачастую сегодня не хватает их производительности. Процессоры ARM по производительности в разы хуже, пока переход на них не вижу смысла. В случае возникновения острой необходимости перевести программу на ARM - есть успешный опыт автоматического перевода ассемблера X86 на ассемблер Z80, PIC18F (архитектура RISC).
-
Примеры использования:
Допустим необходимо перевести данное изображение в вектор. Это изображение хорошего качества, потому отлично сегментируется. С помощью редактора "Лубок" загружаем картинку. Выбираем вкладку "Сегментация" - "8 связная сегментация". Для сглаживания структуры выбираем максимальную погрешность "25", а повторения достаточно "1". Нажимаем "Ok". Далее можно посмотреть удовлетворяет Вас сегментация включив "Выбор сегмента". Сегменты можно просмотреть нажимая левую кнопку мыши. Для получения векторного файла выбираем вкладку "Сегментация"-"Векторный файл .svg"-"3пкс". Далее смотрим папку, где расположен исходный файл и в ней будет файл *.svg с тем же названием. Масштаб - этого файла будет таким же, какой масштаб Вы выбрали перед векторизацией.
Пока все, отвечу на любые вопросы.
-
Добрый день!
Хочу представить свой графический редактор с элементами компьютерного зрения "Лубок". Ссылка на скачивание: http://esm.ho.ua/Automat.html На сегодня программа позволяет редактировать/создавать изображения, проводить сегментацию изображения, преобразовывать растровые изображения в вектор. В качестве практического применения определяет штрихкоды на фотографиях EAN8, EAN13. Размер программы 110 килобайт!!! (именно кило, не мегабайт). Малый размер удалось получить применяя ассемблер и WinApi. Но малый размер не означает, что программа не требовательна к железу. При обработке 24 Мегапиксельной фотографии требуется память и быстродействие компьютера для сегментации изображения. Рекомендуемый характеристики ПК: оперативная память 2ГБ, процессор не хуже Athlon 3000+. Работает с WinXP, Windows 7, Windows 10 - то что реально проверено.
Как пользоваться смотри в программе Справка-помощь!!! В случае возникновения вопросов по программе задавайте их в этой ветке форума. При возникновении, каких либо неполадок буду рад получить конкретные замечания. Надеюсь, что книги "Лубок для чайников", "Лубок для профессионалов" и "уроки компьютерной графики с помощью программы Лубок" будут впереди
.
Хочу так же отметить, что этот сайт 1 на котором даю ссылку на программу "Лубок".
P.S. Программа бесплатная!!!
P.P.S. Распространение программы приветствуется.
-
9 минут назад, Smorodov сказал:Да кривых рассеяния важно именно что там после рендеринга получается картинка очень близкая к исходному растру. А хранить нужно только эти самые кривые. Почему привел ? потому что это метод уменьшения избыточности изображения.
Сеперпиксели также позволяют уменьшить размерность задачи и поводить сегментацию изображения по меньшему количеству элементов. Можно провести каскадное преобразование или пропустить через классификатор и получить метки объектов.
Ваш метод безусловно интересен, и результаты очень хорошие, но пользы от количества предоставленной по нему информации не много.
Да, я погорячился по поводу метода векторизации рассеянных кривых. Метод интересен для реалистичного представления изображения в векторной форме. Но у меня другая цель. Я хочу обрабатывать реальные изображения, сегментировать и с помощью базы данных определять объекты на изображении. Поэтому реалистичное представление не требуется. Человек по картинке лубок или примитивному рисунку может определить, что на ней нарисовано, так же и программа должна определять по контуру, расцветке - что изображено на фотографии. Мне не понятно что такое каскадное преобразование, классификатор, метки объектов? Хотелось бы больше информации на эту тему. Так же интересно про детектор кожи, теория сравнения лиц.
На сегодня очень хорошо и быстро получается определять штрихкоды на фотографиях большого размера, где штрихкод занимает 1% площади всего изображения.
-
Посмотрев на результат обработки дельфина пришел к выводу, что результаты работы примитивного градиентного фильтра типа Соболя. Обработал моей программой исходное изображение фильтром Соболя, результаты выкладываю:
Исходное изображение
Результат фильтра Соболя
Дальше можно пропустить через пороговый фильтр, линии заменить одной толщиной по алгоритму Канни и получим результат французских ученных, ну если еще линии заменить синим цветом.
del.svg - результат в .svg. Сегментация моей программой. Можно рассмотреть CoralDraw предварительно разгруппировав. Море (верхняя часть) выделяется одним большим сегментом, дельфин состоит из небольшого количества сегментов. Нужна вторая часть программы, которая бы комбинировала эти сегменты и сравнивала с базой данных, для автоматического определения объекта. Нужна информация именно на этот предмет.
Суперпиксели, они не столько сжимают информацию, как моя программа и что с ними делать после их получения?
-
1
-
-
Что говорит теория на этот счет. Проводилась сегментация одних и тех же фотографий разными людьми вручную. В результате получали различные сегменты. Получить однозначную сегментацию на реальных изображениях часто не представляется возможным. Мое мнение, что вначале должна производится предварительная сегментация, которая дает большое количество сегментов. Таким образом мы резко уменьшаем объем информации по сравнению с растровым изображением, а следующий этап обработки - объединение и возможные комбинации этих сегментов между собой для индентификации объектов.
Формальную сегментацию и векторизацию я выполнил. А вот со вторым этапом есть только смутные идеи. Так же имею недостаток теории на этот предмет, буду благодарен если подскажете, что можно почитать из теории (только не OpenCV, т.к. строю быстродействующие программы).
-
Для получения сегментации задаются коэффициенты. И можно получать грубую и очень реалистичную сегментацию, но при реалистичной сегментации увеличится количество сегментов и соответственно размер файла. Все зависит от того какие задачи мы решаем, такие коэффициенты мы и подставляем. Если нужно найти объект, то берутся грубые коэффициенты, как на данных примерах.
Я не знаю что такое meanShif. За сколько времени он обрабатывает данные фотографии?
Алгоритм получения палитры цветов
в Обсуждение общих вопросов
Опубликовано · Report reply
У меня задача.
Задается количество цветов (16, 32, 64) и есть 24-битное изображение. Как правильно привести изображение к заданной палитре (16, 32 или 64 цвета), чтобы изображение сильно не искажалось. Простое отбрасывание разрядов не предлагать. Нужен именно алгоритм, а не готовое изображение.
Заранее спасибо за ответы.