Разделение каналов из массива RGB в C ++ без OpenCV

Question

Разделение каналов из массива RGB в C ++ без OpenCV

0

Я работаю в C++ с массивом unsigned char, представляющим пиксели в изображении. Каждый пиксель имеет 3 канала (R, G, B). Изображение представлено линейно, вроде как

RGBRGBRGBRGB.....

Как я могу разделить каждый из R, G и B на отдельные массивы эффективно?

Я пытался:

  for(int pos = 0; pos < srcWidth * srcHeight; pos++) {
      int rgbPos = pos * 3;
      splitChannels[0][pos] = rgbSrcData[rgbPos];
      splitChannels[1][pos] = rgbSrcData[rgbPos + 1];
      splitChannels[2][pos] = rgbSrcData[rgbPos + 2];
  }

Но это удивительно медленно.

Благодарю!

OneSolitaryNoob 07 фев. 2014, в 06:43

Источник

1

Вы проверили, сколько времени занимает запуск этого цикла, не считая другого кода? Не похоже, что это должно быть очень медленно. Кроме того, есть ли причина, по которой вы должны разделить их? Почему бы просто не выполнить цикл и использовать pos <srcWidth * srcHeight * 3 и pos + = 3, если вам нужен определенный цвет?
drowdemon 07 фев. 2014, в 04:57
0

Да, это медленно. Около 7 миллисекунд для 3-мегапиксельного изображения. Я должен разделить их, чтобы вызвать другую библиотеку.
OneSolitaryNoob 07 фев. 2014, в 05:43
0

Ну, 7 * 10 ^ -3 секунд * 2 Гигагерц (например) получает 14 миллионов операций. 14 миллионов операций звучат как раз для 3-мегапиксельного изображения. Правильный порядок величины как минимум. Хотя это очень грубая оценка, и у меня нет большого опыта в этом, поэтому я могу быть совершенно неправ, но это кажется разумным.
drowdemon 07 фев. 2014, в 05:51
0

может быть, есть способ получить его в SSE? кажется медленным для перемещения байтов.
OneSolitaryNoob 07 фев. 2014, в 06:13
0

Массив 2d назначения устанавливается в главном порядке канала, поэтому три цветовых компонента одного пикселя разделяются в памяти байтами srcWidth * srcHeight, что может снизить эффективность кэширования. Попробуйте splitChannels [lotsa_pixels] [3].
Christopher Oicles 07 фев. 2014, в 07:14

Показать ещё 3 комментария

Теги:

c++

optimization

image-processing

image

2 ответа

0

Отличная методика, используемая для ускорения работы, - это цикл размотки. Вы можете прочитать об этом здесь: http://en.wikipedia.org/wiki/Loop_unwinding

avihayas 07 фев. 2014, в 06:49

0

Это не помогло. Я думаю, компилятор уже делает это, когда -O3 включен?
OneSolitaryNoob 08 фев. 2014, в 02:02
0

каков был твой фактор раскрутки?
avihayas 09 фев. 2014, в 08:52
0

Я не указал фактор, просто флаг? -О3 это я верю, но не уверен, сколько.
OneSolitaryNoob 10 фев. 2014, в 19:46

Показать ещё 1 комментарий

Ещё вопросы

Вы проверили, сколько времени занимает запуск этого цикла, не считая другого кода? Не похоже, что это должно быть очень медленно. Кроме того, есть ли причина, по которой вы должны разделить их? Почему бы просто не выполнить цикл и использовать pos <srcWidth * srcHeight * 3 и pos + = 3, если вам нужен определенный цвет?
Да, это медленно. Около 7 миллисекунд для 3-мегапиксельного изображения. Я должен разделить их, чтобы вызвать другую библиотеку.
Ну, 7 * 10 ^ -3 секунд * 2 Гигагерц (например) получает 14 миллионов операций. 14 миллионов операций звучат как раз для 3-мегапиксельного изображения. Правильный порядок величины как минимум. Хотя это очень грубая оценка, и у меня нет большого опыта в этом, поэтому я могу быть совершенно неправ, но это кажется разумным.
может быть, есть способ получить его в SSE? кажется медленным для перемещения байтов.
Массив 2d назначения устанавливается в главном порядке канала, поэтому три цветовых компонента одного пикселя разделяются в памяти байтами srcWidth * srcHeight, что может снизить эффективность кэширования. Попробуйте splitChannels [lotsa_pixels] [3].
Это не помогло. Я думаю, компилятор уже делает это, когда -O3 включен?
Я не указал фактор, просто флаг? -О3 это я верю, но не уверен, сколько.

Yves Daoust · Accepted Answer · 2014-02-07T05-21-00.000Z

Моя попытка: загрузить и сохранить байты четыре-четыре. Байт-скремблирование будет утомительным, но, возможно, пропускная способность улучшится.

// Load 4 interleaved pixels
unsigned int RGB0= ((int*)rgbSrcData)[i];
unsigned int RGB1= ((int*)rgbSrcData)[i + 1];
unsigned int RGB2= ((int*)rgbSrcData)[i + 2];

// Rearrange and store 4 unpacked pixels
((int*)splitChannels[0])[j]= 
    (RGB0 & 0xFF) | (RGB0 >> 24) | (RGB1 & 0xFF0000) | ((RGB2 & 0xFF00) << 16);
((int*)splitChannels[1])[j]= 
    ((RGB0 & 0xFF00) >> 8) | (RGB1 & 0xFF) | (RGB1 >> 24) | (RGB2 & 0xFF0000) >> 16;
((int*)splitChannels[2])[j]= 
    ((RGB0 & 0xFF0000) >> 16) | (RGB1 & 0xFF00) | ((RGB2 & 0xFF) >> 16) | (RGB2 & 0xFF000000);

(ПРЕДОСТЕРЕЖЕНИЕ: не отключено!) Возможна также версия с поддержкой сдвига.

Решение SSE было бы более сложным (шаг 3 не сочетается с степенями 2).

спасибо, это отличная идея Я попробовал это, и это примерно на 10% быстрее. трудно разобраться со всем порядком.
Здорово ! Я был не уверен, что это будет эффективно, учитывая большие накладные расходы. Даже если код содержит ошибки, измерения времени должны быть ориентировочными. Так что, возможно, стоит поцарапать код и сэкономить несколько циклов ...
Я на самом деле должен был бросить его, было улучшение, но не настолько, чтобы сделать его работоспособным. Это очень трудно понять правильно.
Если вы хотите добиться максимальной производительности, то инструкции MMX / SSSE3 pshufb и punpckxxx - ваши лучшие друзья. Загружайте 3 x 8/16 байтов за раз и переставляйте.