PDA

View Full Version : reading the pixels from the image



sebjapon1
05-24-2010, 08:32 PM
Hello,

I am new to OpenGL. I would like to draw a man's silhouette in OpenGL and process it into OpenCV. I managed to draw some basic forms with glut. Then, I use
glReadPixels(0,0, 640, 480, GL_RGB, GL_UNSIGNED_BYTE, (unsigned int*) cvImage->imageData);

It sends the pixels to the cvImage buffer, and I can display the image in OpenCV. So basically it works, but it's veeeeeeeeeeeeeeeery slow. If I compare the program with and without this line, it's like 100 times slower. And I need to do it a lot.

Is there a way to do it faster ? It's just one loop through the image, it should be super fast !

And better, I don't need glut's window and mainloop. So if I could just know how to access the image buffer from OpenGL, it would be great !

Who is doing the conversion 3D, 2D ? glut or OpenGL ? And When ?

Sorry to bother you with all these questions, but I really don't know where to start looking.

ZbuffeR
05-25-2010, 01:23 AM
The most important thing you seem to ignore is that GPU and CPU are each very powerful at what they do, but any communication between them has a double cost :
1- bandwidth is not that great, especially compared to what a GPU is able to produce in terms of volume of data.
2- any time such communication occurs, it forces a synchronization between CPU and GPU, and breaks parallelism

Using the pixel buffer object extension (PBO), you will be able to read the pixels asynchronously, so while GPU renders frame 2, you download frame 1.
Read on :
http://www.songho.ca/opengl/gl_pbo.html
http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutorial3.html#transfers

You can also change the data type, RGB as a 3 byte pixel is sometimes not optimal and can force costly data conversions between 4 and 3 bytes. Try GL_RGBA and GL_BGRA.

Another point : why bother drawing with OpenCV, as you already have very fast OpenGL rendering ?

sebjapon1
05-25-2010, 02:38 AM
Thank you for your answer.
I'll look at these PBOs tomorrow I think.
Still for your question, displaying with OpenCV is just for debugging. What I want is generate a human body model and compare its silhouette with the silhouette of a real guy from the camera.

I'm supposed to do it at least 300 times per frame, which means between 1000 and 2000 times per second. After rendering a few cylinders in OpenGL, I'm starting to worry that it's not fast enough for this application, so I'm still working on the other solution: do the math on paper.

ZbuffeR
05-25-2010, 04:29 AM
300 per frame is really a lot. Once it is correct for one frame, you can probably get away with fewer tries for real time adjustments right ?

Budric
05-26-2010, 11:05 AM
One thing I found when using glReadPixels() is that it's MUCH slower when reading non power of 2 sizes. Try to see if your code gets faster if you read 512x512. This is actually implementation/driver dependent.