Быстрое сравнение суб-изображений в C#

Question

Я работаю над алгоритмом photographic mosaic. Есть 4 этапов:

1. Определить регионы сегмента
2. Определить стоимость каждого кандидат изображений в каждой области сегмента
3. Определить лучшее назначение каждого кандидат изображений для каждого региона сегмента
4. Рендера фотографической мозаики ,

Весь процесс относительно прост, однако этап 2 включает в себя сравнение n изображений с m сегментами с n >> m. Это, безусловно, самый продолжительный шаг.

Вот процесс, который я пройти для каждого сегмента кандидата пары:

1. Определить, если кандидат изображения совместим с размерами сегмента. Если нет, назначение считается запрещенным.
2. Использование промежуточного дополнительного изображения Bitmap, созданного с помощью Graphics.DrawImage(Image, Rectangle, Rectangle, GraphicsUnit), преобразует данные растрового изображения в красные, зеленые и синие int[,] матрицы для сегмента исходного изображения. Я использую метод LockBits() вместо метода GetPixel(), поскольку он намного быстрее. Чтобы уменьшить время вычисления, эти матрицы составляют примерно 3x3 или 5x5, а не полные размеры исходного сегмента.
3. Я делаю тот же процесс с изображением кандидата, создавая красные, зеленые и синие матрицы 3x3 или 5x5 int[,].
4. Начиная с cost = 0, я добавляю величину разницы красных, зеленых и синих значений сегментов изображения источника и кандидата к стоимости. Сумма этих абсолютных разниц - это стоимость назначения.

В действительности, я проверяю каждый кандидат образ со всеми 16 RotateFlipType преобразований, так что есть 16 * п * т сравнения нужно, где п = число сегментов и т = число регионов размещения.

Мне интересно, могу ли я сделать БПФ каждого изображения и вместо сравнения каждого пикселя, я сравниваю только низкочастотные компоненты, так как высокочастотные компоненты существенно не влияют на выход. С другой стороны, многие накладные расходы, такие как получение суб-изображений и преобразование их в матрицы, все еще существуют, и моя кишка говорит мне, что спектральное сравнение будет медленнее, чем базовое сравнение значений 25 int.

Answer 1

Сначала я хотел бы сделать огромную скорость вверх

1. создать данные для каждого изображения, как:

   • среднего цвета
   • г, г, б гистограмм я думаю, 8 или 16 точек на канал хватает
   • может добавить любую другую информацию (самый темный/яркий цвет, ...)
   • , но это должно быть вращением/переворачивания инвариантного

2. индекса сортировки изображений по усредненному цвету

   • ограничить R, G, B до нескольких бит только как 4 ...
   • создать единое целое число от него, как col=R+(G<<4)+(B<<8);
   • индекс сортировки используемых изображений по этому номеру

3. сравнение

   • так бинарный поиск индекс сортировки изображений
   • (если вы создаете таблицу индексов в каждый уменьшенном цвете, то это приведет к снижению к O (1))
   • и найти изображения только с близкими или равный среднего цвета, как ваш сегмент
   • то поиск ближайших матчей гистограммы из этих
   • , а затем применить все, что вы только на тех изображениях ...
   • гистограммы комп Арисон может быть сделано с помощью коэффициента корреляции
   • или любого расстояния, или статистического отклонения ...

, как для FFT части вашего вопроса я считаю, что это более или менее уже ответил на комментарии

• да, вы можете использовать его, но я думаю, что это слишком для этого
• накладные расходы огромен, но вы можете изменить масштаб изображения с низким разрешением и использовать FFT на этом
• или просто сравнить с низким разрешением изображения только вместо

[Примечания]

• также HSV вместо RGB может улучшить визуальное сходство