Comments 25
Проблема баланса белого решается переводом камеры в прибитый гвоздями ручной режим.
кроме баланса белого есть еще набигание облаков и вылезание лун
Я, будучи полным нубом в работе с фото, буквально вчера взялся за решение простой задачи — есть фото текстовых документов (черное на белом, рукописный текст), сделанных под углом, с неравномерным освещением, — нужно подготовить на основе этого печать копии этих документов (достаточных для чтения).
Исправить наклон бумаги дело пары десятков секунд, да и по теме статьи совершенно не требуется, а вот проблему с неравномерным освещением (в т.ч. во времени, в моем случае разные фото имели разную яркость)
И я нашел, мне кажется, просто гениальное решение (использовал GIMP), берем копию изображения, сильно размываем ее (чтобы исчезли значимые элементы, используется простое гауссовое размытие), затем вычитаем (лучше деление и нормализуем) результат из оригинала, получаем яркое изображение, которому абсолютно пофиг на плавные разводы освещения.
Для объектов с четким границами мне кажется метод идеальный, не требует заметных вычислений.
Исправить наклон бумаги дело пары десятков секунд, да и по теме статьи совершенно не требуется, а вот проблему с неравномерным освещением (в т.ч. во времени, в моем случае разные фото имели разную яркость)
И я нашел, мне кажется, просто гениальное решение (использовал GIMP), берем копию изображения, сильно размываем ее (чтобы исчезли значимые элементы, используется простое гауссовое размытие), затем вычитаем (лучше деление и нормализуем) результат из оригинала, получаем яркое изображение, которому абсолютно пофиг на плавные разводы освещения.
Для объектов с четким границами мне кажется метод идеальный, не требует заметных вычислений.
Шикарная статья, хочу повторить) А у Вас есть гитхаб проекта или другой доступ к нему?
Интересно почему отдано предпочтение среде HDL Designer от Mentor's? Там тоже свой VIP или они пользуются альтеровским, судя по рисункам? было упоминание ранних опытов про частичную обработку фреймов на A9, данные капчились из сквозного потока между камерой и монитором в память hps, или или рип из фреймбуфера как конечный блок потока, dma при заполнении кадра ?
HDL Designer использую потому, что осваивать ПЛИС начал на FPGA Advantage под Windows, затем переехал на Linux и FA в полном наборе не нашел, а к HDS привык. На А9, да, данные брал из фреймбуфера. Первые опыты были на SAM9G20 лет 5 назад. Результаты меня не впечатлили. Сейчас в ящике лежит платка на Allwinner H3, вот на ней стоит попробовать, но это потом.
HDL Designer хорош даже в отрыве от любых библиотек. Он может работать и с Альтерой и Ксайлинксом. В графическом виде HDL код намного понятнее и нагляднее. а если не хватает графики, то можно вставить embedded block и будут кусок необходимого кода прям на графике.
UFO just landed and posted this here
Нет, задача выравнивания неравномерной яркости пороговой обработкой не решается — спокойно может быть так, что чёрная буква на яркой части изображения ярче, чем белая бумага на тёмной части. Поэтому действительно, как писал rPman, стандартный и часто используемый для этого способ — поделить изображение на сильно размытую свою копию.
Наверно, было бы проще делать стабилизацию изображения, если бы с видеопотоком были бы данные акселерометров камеры.
Классная статья. Можете теперь попробовать копать в сторону optical flow и сжатия видео. Ну а дальше можно превращать хобби в профессию.
Чисто теоретический вопрос, чтобы понять есть ли какие то очевидные неточности в следующей достаточно топорной логике:
Если предположить, что камера не движется быстрее чем снимает и что резких действий произойти не может, то возможно для нахождение и отличие шумов, движения камеры и… стоит искать не движущее изображение, а искать максимально схожее изображение (то есть, последовательность точек)…
Соответственно, чисто теоретически
Если камера движется или не идеально зафиксирована, то по контрольным точкам понятно на сколько куда она продвинулась и можно соответственно скорректировать. Она же не может частично двигаться.
Если появляется лишний свет/блик/тень, то это влияет на все точки в области и так же можно скорректировать. Свет же не может отразиться только 1 точке, по идее он отразиться на всём изображении так или иначе…
Если предположить, что камера не движется быстрее чем снимает и что резких действий произойти не может, то возможно для нахождение и отличие шумов, движения камеры и… стоит искать не движущее изображение, а искать максимально схожее изображение (то есть, последовательность точек)…
Соответственно, чисто теоретически
Если камера движется или не идеально зафиксирована, то по контрольным точкам понятно на сколько куда она продвинулась и можно соответственно скорректировать. Она же не может частично двигаться.
Если появляется лишний свет/блик/тень, то это влияет на все точки в области и так же можно скорректировать. Свет же не может отразиться только 1 точке, по идее он отразиться на всём изображении так или иначе…
Существует метод под названием Adaptive background subtraction model или что-то в этом роде. Он как раз и призван компенсировать неточности в референсном кадре. До него у меня пока руки не дошли, но я пару раз задумывался о его воплащении в проекте.
Она же не может частично двигаться.камера нет но большая часть изображения может двигаться сама по себе, например автомобиль, на фоне которого мы детектируем движение людей
Sign up to leave a comment.
Детектирование движения в видеопотоке на FPGA