Qt и OpenCV

Если я правильно понимаю, код должен бы был выглядеть как-то так:

IplImage* imgSrc;
...
QImage imgDst;
imgDst.loadFromData(imgSrc->imageData /* это uchar * */, img->width * img->height * 3, "RGB888");

Но как функция определит ширину и высоту потока байтов? В массиве-то только цвет пикселов, ни ширины, ни высоты...

Где что лежит внутри IplImage - знаю. Проблема вот в чем. Когда я передаю в функции imgDst.loadFromData() ссылку на массив пикселов - как QImage определит ширину/высоту массива пикселов? Пусть у меня картинка 3*4 пиксела, соответственно, imageData будет занимать 36 байт. Что может соответствовать картинкам 3*4, 4*3, 6*2, 2*6, 1*12, 12*1. И как QImage определит габариты? Я-то функции не передаю ширину с высотой, и в первых байтах блока данных этой инфы нет.

Или мне нужно перед loadFromData() создать картинку нужного размера?

P.S.: нашла вариант решения: http://www.qtforum.org/article/28481/cr … -data.html
Нужно использовать не loadFromData(), а сразу создавать в конструкторе - а потом, видимо, менять пикселы c gjvjom. loadFromData().

Пока я на работе - я работаю по основной работе, а не по собственным проектам. Проверять буду в течение часа дороги от офиса до дома.

Когда я сделала неправильный код, все прекрасно заработало:

IplImage* imgCam; // В область памяти uchar* imgCam->imageData библиотека OpenCV будет сбрасывать изображение с камеры
QImage* imgCam2; // Эту картинку я буду выводить на экран
...
void Widget::startCam() {
  //Инициализация переменных  запуск съемки
  imgCam = cvQueryFrame(capture);
  imgCam2 = new QImage
    ( (uchar*)(imgCam->imageData)
    , imgCam->width, imgCam->height
    , QImage::Format_RGB888
    );
  repaint();
  timerCam->singleShot(frameRate, this, SLOT(updateCam()));
}
...
void Widget::updateCam() {
  imgCam = cvQueryFrame(capture);
  repaint();
  timerCam->singleShot(frameRate, this, SLOT(updateCam()));
}

В чем неправильность этого кода - imgCam2 и capture используют для хранения пикселов одну и ту же область памяти. Но когда я попыталась переписать код более корректно, чтобы capture и imgCam2 использовали разные области памяти - но в результате картинка вообще перестала выводиться:

IplImage* imgCam; // В область памяти uchar* imgCam->imageData библиотека OpenCV будет сбрасывать изображение с камеры
QImage* imgCam2; // Эту картинку я буду выводить на экран
...
void Widget::startCam() {
  //Инициализация переменных  запуск съемки
  imgCam = cvQueryFrame(capture);
  imgCam2 = new QImage
    ( imgCam->width, imgCam->height
    , QImage::Format_RGB888
    );
  imgCam2->loadFromData
    ( (uchar*)(imgCam->imageData)
    , imgCam->imageSize
    , "BGR888"
    );
  repaint();
  timerCam->singleShot(frameRate, this, SLOT(updateCam()));
}
...
void Widget::updateCam() {
  imgCam = cvQueryFrame(capture);
  imgCam2->loadFromData
    ( (uchar*)(imgCam->imageData)
    , imgCam->imageSize
    , "BGR888"
    );
  repaint();
  timerCam->singleShot(frameRate, this, SLOT(updateCam()));
}

Второй день ломаю голову, что во втором, "исправленном" варианте не так. В imgCam->imageSize лежит правильное число байтов (ширина*высота*число каналов). QImage::loadFromData что ли не работает - впрочем, в такой баг Qt совсем не верится...

Hassium,
> Оно ожидает получить specified format, e.g., PNG or JPG или ещё какой другой. А у вас сырые данные.

Действительно. Полагала, что раз конструктор "ест" raw-формат, то и loadImageFromData() логически должен бы. Ну и не последнюю роль играет организация документации - вполне логично было бы или на аргумент format повесить ссылку на список форматов, или дать ссылку на их перечень в описании функции. Не сразу найдешь...

> А чем вам не нравится первый вариант? Вам же как раз сохранить надо в файл, заодно не тратим время на лишнее копирование.

Я не знаю, как именно работает OpenCV с этой областью данных. А заниматься обработкой данных, куда в любой момент могут начать сливаться данные нового кадра - не лучшая идея. Кроме того, у меня по большому счету задача не просто писать видеопоток, а обрабатывать его (поиск границ, распознавание маркеров и т.п.) - и это лучше делать в отдельной области памяти.

Еще вопрос по Qt. Я беру с камеры картинку 320*240 или 176 * 144. Если выводить ее 1 к 1, это будет маленький фрагмент на экране. Можно отмасштабировать картинку 320*240 на экран таким образом:

QRect* camRect = new QRect(0, 0, 640, 480);
painter.drawImage(*camRect, *imgCam2);

Но при этом вывод видео на экран начинает заметно тормозить. Понятно, что функция "заточена" под масштабирование картинки на произвольный прямоугольник. Можно предположить, что при кратном масштабировании 320 -> 640 функция будет выбирать более простой и быстрый вариант просчета. Но совершенно не факт, что это действительно будет так - при современной производительности компов программеры могли просто "забить" на такие оптимизации. Есть ли в QT гарантированно быстрый способ вывода кратно (вдвое втрое и т.д.) отмасштабированной картинки?

Вы достаточно интересную тему затронули, я в свое время много возился с производительностью при проигрывании видео.

Основной тезис заключается в том, что, несмотря на 21ый век на дворе, необходимо в том или ином виде использовать аппаратное ускорение, иначе будет мрак.

У вас кадры с камеры в каком формате цветности захватываются? тут есть 2 варианта :

1.) YUV. Это достаточно древний формат, пришедший с телевидения, тем не менее, практически все кодеки и девайсы используют его, и 90% из них - YUV420. Общепринятое решение - использовать аппаратный YUV Overlay на видеокарте, в таком случае и цветопреобразованием и масштабированием занимается видеокарта. На низком уровне для этого в X11 есть расширение XV, через которое и работают большинство плееров. SDL имеет достаточно удобное высокоуровневое API для использования YUV Overlay'ев. В Qt, к неприятному удивлению, в чистом виде работа с видео-оверлеями невозможна, они позиционируют Phonon, но он крайне негибок для любой задачи, отличающейся от "проиграть вот этот видеофайл без всяких наворотов".
Есть еще один извращенный путь, к которому мне приходилось прибегать в определенных ситуациях - гнать кадры в RECTANGLE текстуры, писать GLSL шейдер, который конвертирует YUV в RGB, и кидать эти текстуры на экран. В принципе, производительность была вполне приемлемая, а в качестве бонуса достигалась отвязка от фреймворка и хорошая переносимость, ибо OpenGL. Но как с RECTANGLE-текстурами (без них-то, в принципе можно обойтись) и шейдерами (а вот без них - никак, иначе вся затея теряет смысл) обстоит дело в GLES, сказать не могу.

2.) RGB. Если это rgb добывается софтверной конвертацией из yuv'а, идущего с камеры - то отказываться от такого решения, ибо оно само по себе уже должно неслабо жрать процессор. Если же этот RGB идет с камеры аппаратно, то поступать, как в хвосте предыдущего пункта - гнать текстурами через OpenGL.