PDA

View Full Version : image quality is bad when zoom factors >= 1.0 ?!



mehdi
10-07-2003, 10:00 AM
Hi,

In my application i use the OGL function "glDrawPixels" to draw images into screen; when the zoom factor(modified by glPixelZoom) is >= 1.0, the image quality becomes bad(a small rectangles appear on the screen replacing each pixel). i am searching a way to avoid this image quality (pixelization). I know that we can do it if we use texture mapping whit parameter "GL_LINEAR" in the OGL function "glTexParameteri", but i draw with "glDrawPixels".
can anyone help!
(sorry for bad english)

Machiavelli
10-07-2003, 10:28 AM
I, too, have a problem I am hopeful someone might be able to help me solve...

I am using a belt sander to hammer nails into my woodworking project, but I've found that very often, especially when I have the belt sander on at high speed, the heads of the nails become ground down because of the sandpaper. Then it becomes very difficult to get the nails pounded all the way into the wood.

Now I know that some folks use hammers to do this kind of work, but remember: I use a belt sander.

Any suggestions?

Thanks! http://www.opengl.org/discussion_boards/ubb/wink.gif

roffe
10-07-2003, 10:29 AM
The reason why texture mapping with GL_LINEAR looks good is because it interpolates between your existing samples when magnified.

If you have to use DrawPixels, you will need to interpolate your samples yourself taking the zoom factor into account before supplying them to DrawPixels.

It would be more interesting to hear why you can't use a texture map, unless this is a hw assignment.

mehdi
10-08-2003, 01:58 AM
Hi,

I now that in texture mapping the image data is interpolated with the GL_LINEAR parameter, it's for that i am asking if this possibility is available for drawing with "glDrawPixels"(an OGL routine for exemple). finally, the reason for what i use "glDrawPixels" routine is that it is fatest than drawing with Texture mapping(i have to load an important nbr of images continually) and i work in 2D scene. If u are not agree with my choice give me the reason.

thanks for ur reply

rgpc
10-08-2003, 02:45 AM
Originally posted by mehdi:
(i have to load an important nbr of images continually)

Perhaps you should define the above statement. What is an "important nbr of images"?

If you have lots of images you are still better off putting them in textures, as at least "some" of them will end up resident in memory. If you have dynamic, ever changing images (eg. video feed) then you can probably get similar performance out of glTexSubImage2D().

Machiavelli Use a finer grain paper, it wears the nails less. http://www.opengl.org/discussion_boards/ubb/biggrin.gif

roffe
10-08-2003, 10:59 AM
Originally posted by mehdi:
possibility is available for drawing with "glDrawPixels"(an OGL routine for exemple).

No.



finally, the reason for what i use "glDrawPixels" routine is that it is fatest than drawing with Texture mapping
DrawPixels is notorious for being a very slow operation. It is not a simple blit, it generates fragments that all pass through the pipeline like any other primitive call. You are probably better off with TexSubImage2D like rgpc recommended. If NV_PIXEL_DATA_RANGE (http://oss.sgi.com/projects/ogl-sample/registry/NV/pixel_data_range.txt) is available on your hw, you should definately look into that.

mehdi
10-09-2003, 12:38 AM
hi,

First, i mean by the expression "i have to load an important nbr of images continually" that in my application i have a lot of images with different properties(internal format, type...) that are opened according to the volition of users.
for this reason i choose drawing by "glDrawPixels" because texture build is slow.
finallly, if u mean by ur idea that with only one textue object i can draw all subsequent images using "glTexSub..." its a good idea(i use this idea in changing contrast for each image) but for drawing differnt images i build a new texture object, i will try this idea with different images.
i have another problem with texture: somme images have big dimensions(w & h)and the card dont support this texture; to avoid this pb i scale the image, but this idea render
the process of changing contrast(using the methode above)very slow because i have to scale the image each time the contrast change where the original buffer image change(=>must be scaled).
if u have some suggestions let me know.
thanks.