видео детектор объекта
картинку суешь в массив массивов, следующую картинку(снятую через 5 секунд например) тоже суешь в массив массивов, потом вычитаешь их один из другого. если отличается сильно по сумме элементов например, то картинку сохраняешь как задетектившую человека. зачем считать корни и прочее?
по-моему это как раз тот случай, когда "трясти надо"
артинку суешь в массив массивов, следующую картинку(снятую через 5 секунд например) тоже суешь в массив массивов, потом вычитаешь их один из другого. если отличается сильно по сумме элементов например, то картинку сохраняешь как задетектившую человека. зачем считать корни и прочее?По сумме каких элементов? зачем тут массив массивов?
картинка что в твоём понимании? вообще то картинка у меня - это уже двух мерный массив из чиселкоторый в BITMAP суть цвета пикселей.
ты предлагаешь цвета друг из друга вычитать? что будет если ты порог "сильного отличания" задашь на картинках по красному каналу а потом придёт картинка зеленого цвета?
что-то типа такого?
здесь я фоновый кадр вычислял на основе нескольких предыдущих, потсчитывал сумму модулей разностей компонент по блокам, при превышении порогового значения считал что в блоке есть движение. для наглядности в блоках где считается обнаруженным движение на 2 картинку с фоном наложена подсветка разностью фиолетового цвета. люди за столиком сидят давно и не делают резких движений поэтому он на данном кадре не подсвечены.
здесь я фоновый кадр вычислял на основе нескольких предыдущих, потсчитывал сумму модулей разностей компонент по блокам, при превышении порогового значения считал что в блоке есть движение. для наглядности в блоках где считается обнаруженным движение на 2 картинку с фоном наложена подсветка разностью фиолетового цвета. люди за столиком сидят давно и не делают резких движений поэтому он на данном кадре не подсвечены.
Неплохо . я в итоге почти так сделал - фоном считаю предыдущий кадр.
Дельту считаю по корню из суммы квадратов компонент
Дельту считаю по корню из суммы квадратов компонент
что будет если ты порог "сильного отличания" задашь на картинках по красному каналу а потом придёт картинка зеленого цвета?
сведи все к черно белому и детекти через разность массивов, ты что разноцветных героев чтоли вылавливаешь? Тоесть если герой красный - ты его не пропускаешь, а если он зеленый то его детектить надо?
Ну дак вор, зная что камеры детектят только в красном, оденется в зеленую одежду и все украдут - следовательно грошь цена твоей программе.
http://opencv.willowgarage.com/wiki/
всё уже давно придумано до нас
Вики у них страшноватое, но в качестве примера простоты использования кину ссылку. Мужыг там конечно халявит, в том смысле что он по цвету выделяет сначала, а потом уже ищет мячик. Но в плане демонстрации работы и объема необходимого для этого кода (внизу) вполне показательно.
всё уже давно придумано до нас
Вики у них страшноватое, но в качестве примера простоты использования кину ссылку. Мужыг там конечно халявит, в том смысле что он по цвету выделяет сначала, а потом уже ищет мячик. Но в плане демонстрации работы и объема необходимого для этого кода (внизу) вполне показательно.
Я посмотрел как происходит конвертация RGB в черно белый. там оказывается не все так прозрачно
вот ты какие коэффициента предлагаешь использовать чтоб осуществить конвертацию
Твой метод тоже цветозависим/ я нашел формулу .3r + .59g + .11b - получается вор в зеленом более значим для твоего алгоритма?
вот ты какие коэффициента предлагаешь использовать чтоб осуществить конвертацию
Твой метод тоже цветозависим/ я нашел формулу .3r + .59g + .11b - получается вор в зеленом более значим для твоего алгоритма?
Стоит задача именно разработать или можно взять готовую программу?
еще может подойдёт Motion: http://www.lavrsen.dk/foswiki/bin/view/Motion/WebHome
разработать . более того я уже все давно разработал (а хуле, там пара циклов получилось).
формулу взял такую как я написал чуть выше и всё работает.
теперь вот немного спорю с фильфредом.
ну и ты включись в спор, прочитай его точку зрения и мой довод
формулу взял такую как я написал чуть выше и всё работает.
теперь вот немного спорю с фильфредом.
ну и ты включись в спор, прочитай его точку зрения и мой довод
а для чего это нужно?
если эта прога будет использоваться для чего-то мало-мальски серьезного и при этом будет важно, чтобы она работала хорошо, стоит посмотреть в сторону более умных алгоритмов. У этого будут ложно положительные срабатывания на вещах типа колышущейся занавески или игры тени от листвы (ну либо наоборот, не будет замечать вообще ничего, если поднять порог чувствительности)
если эта прога будет использоваться для чего-то мало-мальски серьезного и при этом будет важно, чтобы она работала хорошо, стоит посмотреть в сторону более умных алгоритмов. У этого будут ложно положительные срабатывания на вещах типа колышущейся занавески или игры тени от листвы (ну либо наоборот, не будет замечать вообще ничего, если поднять порог чувствительности)
.3r + .59g + .11bну типа из фотографии - зеленый - по большей части шумы, красный - основные контуры, синий - я не помню
что-то такое
эти коэффициенты вообще-то соответствуют чувствительности глаза к красному, зеленому и синему цветам
(подобраны в результате долгих и нудных экспериментов на живых людях)
А смысл использования именно этих чисел в том, чтобы при переводе получить из RGB grayscale-изображение, т.е. яркость, а не что-нибудь другое
картинку суешь в массив массивов, следующую картинку(снятую через 5 секунд например) тоже суешь в массив массивов, потом вычитаешь их один из другого. если отличается сильно по сумме элементов например, то картинку сохраняешь как задетектившую человека. зачем считать корни и прочее?А если ниндзя будет красться?
Если проекция ниндзя на камеру будет двигаться со скоростью менее 1 пиксела за тик времени (кадр то система может на него не отреагировать. Для картинки шириной 768 пикселов и камеры, смотрящей на стену шириной в 5 метров при фреймрейте 16к/с эта скорость должна быть не более 16*5/768 м/с = 0.104 м/с, и чем ближе к камере - тем медленнее.
Я посмотрел как происходит конвертация RGB в черно белый. там оказывается не все так прозрачнода, формула такая, ну если в зеленом на уровне шумов, значит детекти дополнительно еще отдельно и зеленый...
вот ты какие коэффициента предлагаешь использовать чтоб осуществить конвертацию
Твой метод тоже цветозависим/ я нашел формулу .3r + .59g + .11b - получается вор в зеленом более значим для твоего алгоритма?
мне кажется не нужны тут все эти усложения... корни, коэффициенты и прочее, зачем? Ну хотя впрочем если шашечки, а не ехать, то можно сделать как ты делаешь.
А какова цель всего этого действия? Для души разобраться или все-таки для дела?
Для дела (которое для души но дело уже сделано — камера работает уже 48 часов и сохраняет имено то что мне нужно
теперь просто спорим насчет коэффициентов
А спорим мы вот о чем :
Вильферд и я сошлись на том что надо сравнивать предыдущую и текущую картинки попиксельно
Пусть имеется BITMAP с пикселями и ммы сравниваем два пикселя R1G1B1 и R2G2B2
пусть DELTA - разница между пикселями.
У Вилферда формула такая
V1=.3R1 + .59G1 + .11B1
V2=.3R2 + .59G2 + .11B2
DELTA=ABS(V1-V2)=.3(R1-R2)+.59(G1-G2)+.11(B1-B2)
У меня такая
DELTA= sqrt(sqr(V1-V2)+sqr(G1-G2)+sqr(B1-B2
тут sqrt- корень , sqr- квадрат
Тема свелась к тому какая формула круче и у кого хуй длинне. кто что скажет?)
теперь просто спорим насчет коэффициентов
А спорим мы вот о чем :
Вильферд и я сошлись на том что надо сравнивать предыдущую и текущую картинки попиксельно
Пусть имеется BITMAP с пикселями и ммы сравниваем два пикселя R1G1B1 и R2G2B2
пусть DELTA - разница между пикселями.
У Вилферда формула такая
V1=.3R1 + .59G1 + .11B1
V2=.3R2 + .59G2 + .11B2
DELTA=ABS(V1-V2)=.3(R1-R2)+.59(G1-G2)+.11(B1-B2)
У меня такая
DELTA= sqrt(sqr(V1-V2)+sqr(G1-G2)+sqr(B1-B2
тут sqrt- корень , sqr- квадрат
Тема свелась к тому какая формула круче и у кого хуй длинне. кто что скажет?)
Если у тебя работает, работает хорошо, быстро, значит твой способ применим. Если у Вильфреда его способ заработает, значит он тоже применим.
да понятно что его заработает
я не пойму в чем прелесть его формулы перед той что я написал
Ну мб он счас сам напишет
я не пойму в чем прелесть его формулы перед той что я написал
Ну мб он счас сам напишет
У Вильфреда порог чувствительности более "естественная" величина. В человеческом восприятии разница двух цветов отличается от евклидова расстояния между ними в RGB-пространстве (которое у тебя считается). Зато у Вильфреда дельта не покажет изменение цвета, если яркость не меняется, тут это, имхо, более важно.
А хуй длиннее в этом вопросе, очевидно, у тех, кто занимается софтом для видеонаблюдения
Если хочется прогу улучшить, не усложняя сильно, то можешь считать расстояние не в RGB, а в CIE Lab
А хуй длиннее в этом вопросе, очевидно, у тех, кто занимается софтом для видеонаблюдения
Если хочется прогу улучшить, не усложняя сильно, то можешь считать расстояние не в RGB, а в CIE Lab
суть твоего высказывания - его алгоритм более восприимчив к ЗЕЛЕНЫМ объектам
мой - равномерен.
так?
мой - равномерен.
так?
нет
самая существенная разница в том, что ты считаешь разницу между цветами, а он - между яркостью двух цветов. У метода вильфреда нет повышенной чувствительности к зеленым объектам, т.к. он не отличает красный (196, 0, 0) от зеленого (0, 100, 0 т.к. у этих 2х цветов одинаковая яркость.
Менее существенное отличие - вильфред считает разницу так, что она соответствует восприятию глаза (именно для этого нужны те коэффициенты а ты считаешь разницу так, что она не соответствует восприятию
самая существенная разница в том, что ты считаешь разницу между цветами, а он - между яркостью двух цветов. У метода вильфреда нет повышенной чувствительности к зеленым объектам, т.к. он не отличает красный (196, 0, 0) от зеленого (0, 100, 0 т.к. у этих 2х цветов одинаковая яркость.
Менее существенное отличие - вильфред считает разницу так, что она соответствует восприятию глаза (именно для этого нужны те коэффициенты а ты считаешь разницу так, что она не соответствует восприятию
Хочешь сказать что если с камер поступают два пикселя (255,0,0)
и (0,0,255) то они для человеческого глаза имеют разную яркость?
Я слышал что в матрицах камеры уже происходит нормализация под человечский глаз
и
(255,0,0)
и (0,0,255) выдаются дл тех пикселей, для которых в реале имеют одинаковую яркость для человеческого глаза
и (0,0,255) то они для человеческого глаза имеют разную яркость?
Я слышал что в матрицах камеры уже происходит нормализация под человечский глаз
и
(255,0,0)
и (0,0,255) выдаются дл тех пикселей, для которых в реале имеют одинаковую яркость для человеческого глаза
А с разрешением не перепутал?
Большинство матриц в камерах устроены так, что разрешение зеленого цвета вдвое больше, чем красного и синего (байесовский паттерн ибо к зеленому глаз больше восприимчив.
Все основные фото и видеокодеки переводят RGB данные в цветовое пространство YUV (или YCbCr где Y - как раз яркость, считаемая по приведенной выше формуле (или очень близкой, если выходной интервал не 0-255). Т.е. то, что синий цвет сильно менее яркий, чем зеленый, это повсеместно используемый факт. Если бы камеры делали компенсацию, эта формула бы не применялась.
Большинство матриц в камерах устроены так, что разрешение зеленого цвета вдвое больше, чем красного и синего (байесовский паттерн ибо к зеленому глаз больше восприимчив.
Все основные фото и видеокодеки переводят RGB данные в цветовое пространство YUV (или YCbCr где Y - как раз яркость, считаемая по приведенной выше формуле (или очень близкой, если выходной интервал не 0-255). Т.е. то, что синий цвет сильно менее яркий, чем зеленый, это повсеместно используемый факт. Если бы камеры делали компенсацию, эта формула бы не применялась.
Тема свелась к тому какая формула круче и у кого хуй длинне. кто что скажет?
У Вилфреда короткий, потому что в данной задаче воспринимаемая человеком яркость вообще не имеет отношения к делу. Его формула считается быстрее, но за счет уменьшения чувствительности. С тем же успехом можно было просто сложить три компоненты, так еще быстрее, а точность (чувствительность) не хуже.
С другой стороны, честно считать квадраты и тем более корни (почему не сравнить с квадратом порога?) тоже необязательно, суммы модулей разностей вполне достаточно, поэтому у тебя тоже короткий.
Согласен, этот пост можно сказать итог всей темы
я не пойму в чем прелесть его формулы перед той что я написаля ценю скорость... у меня была гигагерцовая тачка, которая обрабатывала видео с трех камер одновременно в реалтайме, кадры были 768х576, 75 кадров в секунду надо было успевать... мне тогда не до цветности было
Перечитай еще раз пост . У него очень хорошо написано, что «суммы модулей разностей вполне достаточно».
Оставить комментарий
freako
Камера фиксирована и с нее поступает серия картинок. нужно сохранять те катринки на которых есть люди и т.п.алгоритм который возник в голове - фон почти не меняется. сохранить его один раз как эталон и потом поступившую картинку сравнивать с эталоном
как сравнивать - попиксельно, вычислия сумму от abs(r1-r2)+abs(g1-g2)+abs(b1-b2) где пиксели имею цвета r1g1b1 и r2b2bg2 соотвственно для поступившей картинки и эталона
Вопрос - подойдет ли такой алгоритм. надо ли брать корень от суммы квадратов разностей или можно просто обойтись суммой модулей?)