unsafe
{
byte* baseSrc = (byte*)imageData.Scan0.ToPointer();
byte* baseTpl = (byte*)templateData.Scan0.ToPointer();
int sourceOffset = imageData.Stride - templateWidth * pixelSize;
int templateOffset = templateData.Stride - templateWidth * pixelSize;
for (int y = 0; y < mapHeight; y++)
{
for (int x = 0; x < mapWidth; x++)
{
byte* src = baseSrc + sourceStride * y + pixelSize * x;
byte* tpl = baseTpl;
int dif = 0;
for (int i = 0; i < templateHeight; i++)
{
for (int j = 0, maxJ = templateWidth * pixelSize; j < maxJ; j++, src++, tpl++)
{
int d = *src - *tpl;
if (d > 0)
{
dif += d;
}
else
{
dif -= d;
}
}
src += sourceOffset;
tpl += templateOffset;
}
int sim = max - dif;
if (sim >= threshold)
map[y + 2, x + 2] = sim;
}
}
}
Сводимость двух изображений на основе коэфициента корреляции. (Помогите ускорить алг)
Задача решаемая данной программой следующая:
Что мы имеем :
1) Ряд изображение одинакового разрешения, каждое из которых имеет фрагмент изображения идентичный следующему фрагменту изображения другой картинки (В нашем случае картинок две.[ATTACH]4330[/ATTACH] (1z.jpg)[ATTACH]4331[/ATTACH] (2z.jpg) но смысл в том, что анализ этих изображений занимает довольно - таки продолжительный период времени из - за того, что процесс обработки загружает сильно оперативную память )
2) Привести к такому виду
[ATTACH]4332[/ATTACH]
т.е собрать два изображения в одно.
Как это работает :
1) Обе картинки переводятся в гродацию серого 8bit
2) Изображения разбивается на фрагменты и сравнивается со второй картинкой. (между ними просчитываются коэфициенты корреляции и заносятся в массив)
3) Максимум коэфициента корреляции и будет искомый нами эталонный фрагмент изображения
4) Имея координаты положения эталонного фрагмента в первой и во второй картинки, находятся координата точки отсчета второй картинки.
x0=|x+x'| y0=|y+y'|
5) Две картинки сводятся в одну.
Алгоритм программы рабочий, но в нем минус - очень долго все это дело просчитывается на компьютере, хотелось бы , что бы вы мне помогли разобраться в чем дело.
Ах да. Я новичёк в программировании, не судите строго.
Исходник прилагается, сорс с картинками см. ниже
http://narod.ru/disk/21835213000/temp_match.rar.html
Что мы имеем :
1) Ряд изображение одинакового разрешения, каждое из которых имеет фрагмент изображения идентичный следующему фрагменту изображения другой картинки (В нашем случае картинок две.[ATTACH]4330[/ATTACH] (1z.jpg)[ATTACH]4331[/ATTACH] (2z.jpg) но смысл в том, что анализ этих изображений занимает довольно - таки продолжительный период времени из - за того, что процесс обработки загружает сильно оперативную память )
2) Привести к такому виду
[ATTACH]4332[/ATTACH]
т.е собрать два изображения в одно.
Как это работает :
1) Обе картинки переводятся в гродацию серого 8bit
2) Изображения разбивается на фрагменты и сравнивается со второй картинкой. (между ними просчитываются коэфициенты корреляции и заносятся в массив)
3) Максимум коэфициента корреляции и будет искомый нами эталонный фрагмент изображения
4) Имея координаты положения эталонного фрагмента в первой и во второй картинки, находятся координата точки отсчета второй картинки.
x0=|x+x'| y0=|y+y'|
5) Две картинки сводятся в одну.
Алгоритм программы рабочий, но в нем минус - очень долго все это дело просчитывается на компьютере, хотелось бы , что бы вы мне помогли разобраться в чем дело.
Ах да. Я новичёк в программировании, не судите строго.
Исходник прилагается, сорс с картинками см. ниже
http://narod.ru/disk/21835213000/temp_match.rar.html
Вы простите, но я пока исходники посмотреть не могу, но...
Ну а если предоставить пользователю возможность указать в обеих
пикчах зоны, в которых нужно произвести анализ? Вот на приведенном примере ясно видно, что нужно анализировать нижнюю часть пикчи 1 и верхнюю часть пикчи 2. И это будет, т.с. - быстрый режим.
Посмотю ваши исходники, может по "фулпикчерному" анализу еще что подскажу
Ну а если предоставить пользователю возможность указать в обеих
пикчах зоны, в которых нужно произвести анализ? Вот на приведенном примере ясно видно, что нужно анализировать нижнюю часть пикчи 1 и верхнюю часть пикчи 2. И это будет, т.с. - быстрый режим.
Посмотю ваши исходники, может по "фулпикчерному" анализу еще что подскажу
Идея не плохая, возможно ,если не найдется другого выхода, приму на вооружение ваше предложение.
Но все таки, хотелось обойтись без этого, так как изображений будет очень много и их все надо будет собрать в одно, при этом наслоенность этих изображений может быть и подругому, не только сверху и снизу, но и со смещением как по вертикали, так и по горизонтали.
А кликать каждый раз на канву, выделяя область для новых изображений, никак не назовешь автоматизацией.
Возможно есть более рациональный способ нахождения данных областей, например по именам файлов, но все равно - это не дело , так как реально разрешения картинок 3000X2000 , согласитесь, даже если область разбить на 1/4 просчитывать будет долго.
Но все таки, хотелось обойтись без этого, так как изображений будет очень много и их все надо будет собрать в одно, при этом наслоенность этих изображений может быть и подругому, не только сверху и снизу, но и со смещением как по вертикали, так и по горизонтали.
А кликать каждый раз на канву, выделяя область для новых изображений, никак не назовешь автоматизацией.
Возможно есть более рациональный способ нахождения данных областей, например по именам файлов, но все равно - это не дело , так как реально разрешения картинок 3000X2000 , согласитесь, даже если область разбить на 1/4 просчитывать будет долго.
Можно сдвинуть вычисления на видеокарту. Я недавно сделал привязку OpenCL к .NET, в скором времени планирую опубликовать наработки.
На видео память нагрузку сделать - неплохо, а смысл , просто , нагрузка большая да и процессе занимает памяти в 10 ток раз больше, чем весят сами файлы.
Я вот думаю, может как нибудь можно освобождаться подгружаемую память процессом.
Если есть подскажите как ?
Я вот думаю, может как нибудь можно освобождаться подгружаемую память процессом.
Если есть подскажите как ?
Цитата: Chekis-stet
На видео память нагрузку сделать - неплохо, а смысл , просто , нагрузка большая да и процессе занимает памяти в 10 ток раз больше, чем весят сами файлы.
Я вот думаю, может как нибудь можно освобождаться подгружаемую память процессом.
Если есть подскажите как ?
Я вот думаю, может как нибудь можно освобождаться подгружаемую память процессом.
Если есть подскажите как ?
При чем тут память? Я говорю о вычислениях. Большую часть времени в вашем алгоритме занимает фильтрация изображений (параллелизм по данных), которую можно выполнять на GPU.
Толком не смотрел но вот эти три вложенных цикла:
Код:
можно если не полностью то частично разложить в CUDA / OpenCL код, который будет выполняться на видеокарте раз в 10 быстрее, чем на CPU.
Это понятно, что проблемма в этом участке программного кода, да и не только.
Но в голову, ничего не приходит пока, как это дело упростить.
Да и в CUDA перегонять пока не имеет смысла, а вдруг у человека карточка не от Nvidia , тогда как ?
Но на заметку я бы взялбы несколько твоих сорсов работы с видео памятью.
Но опять же, мне не понятно, почему в процессах , программа столько много жрет оперативы ?
Насчет же OpenGL то я сейчас попробую на многопоточность перейти в просчетах.
Но в голову, ничего не приходит пока, как это дело упростить.
Да и в CUDA перегонять пока не имеет смысла, а вдруг у человека карточка не от Nvidia , тогда как ?
Но на заметку я бы взялбы несколько твоих сорсов работы с видео памятью.
Но опять же, мне не понятно, почему в процессах , программа столько много жрет оперативы ?
Насчет же OpenGL то я сейчас попробую на многопоточность перейти в просчетах.
Цитата: Chekis-stet
Насчет же OpenGL то я сейчас попробую на многопоточность перейти в просчетах.
Где я писал про OpenGL и видеопамять? Читайте внимательно, я писал об OpenCL - стандарте исполнения программ на векторных ускорителях. Более-менее новые чипы NVidia и ATI поддерживают этот стандарт, помимо этого они предоставляют CPU-реализации этого стандарта.
Цитата: Chekis-stet
Но опять же, мне не понятно, почему в процессах , программа столько много жрет оперативы ?
Вероятно очень много раз производится копирования битмапов, которые вообще-то очень требовательны к ОЗУ.
А еще вы видимо некорректно измеряете потребление памяти, для более менее точного измерения нужно смотреть иноформацию о памяти предоставляемую .NET рантймом (CLR как правило занятую виртуальную память очень неохотно возвращает в систему, хотя мусор собирает исправно) - счетчики управляемых и неуправляемых куч, их можно увидеть в Process Explorer'е.
Буду копаться и разбираться, спасибо за наводку :)
Но все же было бы не плохо, если бы тыкнули носом откуда плясать :(
Я насчет памяти. :)
В процессах копаться, это конечно супер, но проблема в исходном коде программы, а вот где эта зараза зарыта, я не могу найти, вот именно поэтому я и обратился на этот форум, в надежде, что подскажут, что же я упустил.
Поэтому теория - это супер, любой работодатель примет вас себе на работу, а вот , что касается поисков, то мне кажется меня отправили куда подальше.
Ребята, я только начинающий - пришел к мастерам за помощью, а тут на тебе иди грызи литературу :)
Но все же было бы не плохо, если бы тыкнули носом откуда плясать :(
Я насчет памяти. :)
В процессах копаться, это конечно супер, но проблема в исходном коде программы, а вот где эта зараза зарыта, я не могу найти, вот именно поэтому я и обратился на этот форум, в надежде, что подскажут, что же я упустил.
Поэтому теория - это супер, любой работодатель примет вас себе на работу, а вот , что касается поисков, то мне кажется меня отправили куда подальше.
Ребята, я только начинающий - пришел к мастерам за помощью, а тут на тебе иди грызи литературу :)