View Full Version : Is it possible to using OpenGL to produce 2D image FX?

07-06-2003, 07:33 AM
I plan to write my 2D image FX(such as "Erode","Noise","Blur",...) program using OpenGL just for saving CPU usage,but I am not sure whether OpenGL can implement it,and I am still finding some documents about using OpenGL to deal 2D processing.My idea is viable?Is there any 2D image FX code using OpenGL?

lost hope
07-06-2003, 08:05 AM
all your effects are going to be algorithms that run on, and consequently modify, image data. this portion of the program is in no way related to opengl. you certainly could, however, use opengl to display your images -- thus allowing you to see your changes. opengl can be used for 2D imaging applications (or any other type of 2D/3D application), but you will still have to write the algorithms that actually modify the image data yourself.

07-06-2003, 10:05 AM
You can have these effects done on the GPU using programmable shaders.


07-06-2003, 05:15 PM
Yes you can do this in OpenGL. There are the ARB imaging extensions, for image processing like convolution, on anything you pass through the imaging pipeline (image reads/writes).

More likely to be accelerated there are programmable things you can do either using multipass storing blended results to the framebuffer or using fragment operations and programmable shaders with multiple texture taps into any fragment program you care to write. There's also a middle ground between multi-pass and full programmability where you could use texture environments & combiners but it would be more limited than full programmability.

Anyway, you have lots of options and you can do this stuff easily with hardware acceleration on modern OpenGL hardware.

[This message has been edited by dorbie (edited 07-06-2003).]

07-06-2003, 05:59 PM
I know many algorithms of 2D image FX is some matrix,and the GPU is faster than CPU to do matrix stull,so I want to can I transplant the calcualtion of FX to GPU and the way to implement it

07-06-2003, 07:46 PM
I would make a texture of the pic, use rectangle texturing, then it involves using fragment programming (you are free to do lots of calculations there). I think this method is very suitable.
If you are interested in making a "paint" app, it may require render to texture and other things.

PS: it will only run on modern hardware. That's always a catch.

07-06-2003, 09:03 PM
pango, this is not the same type of matrix. If you try to use matrices you'll get very confused.

Read the posts above and try to understand what they're suggesting.

07-06-2003, 09:41 PM
There are several reasons not to use opengl for 2d image processing, however. The overall speed win isn't going to be that great, especially if you do everything in unextended gl. If you don't, well, there goes compatibility. Even worse, you're in many cases limited to frame buffer precision, which can be whatever the user has set it to, and it gets really complicated to allow more than 8 bits per channel.

In summary, it's difficult and incompatible. If there's some specific reason to use gl for 2d processing, like post-processing rendered images, you can, but in general I don't think it's such a good idea.

Please don't take this the wrong way, I don't mean to get you down, just thought you should be aware of the problems.


07-07-2003, 07:18 AM
OTOH there are some very good reasons in favor and it can be extremely fast compared to CPU solutions depending on your operation. Precision is pretty good now and there's support for signed types & extended range. Data transport too & from the card is improving, and common extensions now exist for multiple vendors.

Whether it's worth it can depend on whether you want a result back on the CPU or wheher you simply want to display the result to video. This can make it a real no brainer, but it is also often worthwhile to use the GPU anyway.

There are many application dependant issues like storing images on the card, interactivity of image processing & kernel adjustments, other CPU useage, the system memory performance vs the graphics memory performance, etc. I'd say it's definitely a win especially for interactive layered compositing operations, larger filter kernels, warps and countless other operations. Software just can't come close to graphics hardware performance if you know how to write the code, and it's definitely beyond the stage now where you could read the result back as a production result for some applications on some hardware, although interactivity is really the biggest win and that applies to almost all applications.

[This message has been edited by dorbie (edited 07-07-2003).]