glDrawPixels & glPixelZoom errors
V.Vasant
We are drawing a MPEG Frame data row by row using glRasterPos2i()
and glDrawPixels.
Error1:
when we are resizing the qglWidget along with a glPixelZoom( )
we obtained black horizontal lines uniformly distributed and
proportional to the zoom factor.
Error2:
Since our MPEG Frame data is flipped along vertically, we are
drawing the data row by row. We tried out a solution suggested in this
group.
The solution was to use a
glPixelZoom( 1, -1 );
glRasterPos2i( 0, Height);
glDrawPixels(...)
so as to undo the vertical flip
But it doesnot seem to be working.
Please guide us to a workable solution.
Thanking you in anticipation
César Blecua Udías
>
> Our applicaiton details:
> We are drawing a MPEG Frame data row by row using glRasterPos2i()
> and glDrawPixels.
> Error1:
> when we are resizing the qglWidget along with a glPixelZoom( )
> we obtained black horizontal lines uniformly distributed and
> proportional to the zoom factor.
So you're drawing an image using multiple glDrawPixels which should
stitch exactly, and using arbitrary zoom factors. If you get black
horizontal lines, I guess the cause can be one of the following (or
both!) :
A)Wrong rounding in glRasterPosi
--------------------------------
Keep in mind that you use arbitrary zoom factors, so the dimensions of
the zoomed image will be non-integer in general. But glDrawPixels always
draws an integer number of pixels (no sub-pixel support), and if you
round the coordinates in glRasterPos in a different fashion than
glDrawPixels, you'll get blank scans. Read the OpenGL spec to see how
glDrawPixels rounds non-integer to integer dimensions when using
glPixelZoom.
B)Lower internal precission of zoom factors
-------------------------------------------
OpenGL doesn't guarantee that the internal precission of zoom factors be
as exact as the glPixelZoom arguments' types.
For example, one implementation may choose to convert zoom factors to
fixed point, and use those values instead of the floating point original
ones. The Silicon Graphics O2 is an example of this.
It's obvious that if the precission of the internal zoom factors used by
OpenGL is different to the precission of your zoom variables, you'll get
blank lines when you use your variables to compute glRasterPos
coordinates.
I think that glGet returns the *internal* zoom factors, but I'm not sure
in this moment.
>
> Error2:
> Since our MPEG Frame data is flipped along vertically, we are
> drawing the data row by row. We tried out a solution suggested in this
> group.
> The solution was to use a
>
> glPixelZoom( 1, -1 );
> glRasterPos2i( 0, Height);
> glDrawPixels(...)
>
> so as to undo the vertical flip
> But it doesnot seem to be working.
Yes, glPixelZoom(1,-1) should flip the image vertically.
What do you get on screen with that code?
Did you try it with a different computer/graphics card ?
Hope this helps,
César
cesar...@iname.com
Santhosh Narayana
Thanx for ur immense help. The first error was resolved.
As directed, we have rectified the first error by reallocating the 2D
array such that its contiguous and glDrawPixels() accepted in a single
go. I'm doing the widget resize, so I used glPixelZoom( factorX,
factorY );
wherein the values are not always 1, 1.
Now the FLIPPING is not obtained after I negated the factorY. In order
to add flipping we put
glPixelZoom( factorX, -factorY ); //default 1, -1
glRasterPos2i( 0, Height );
The display goes black. With +ve factorY and without
glRasterPos2i()
everything is fine except for the Flip.. How should we go about. The
moment I give a negative value to glPixelZoom.. display turns black..
Thanking u in anticipation
César Blecua Udías
I think the correct coordinates should be glRasterPos2i( 0, Height-1 );
Note that any call to glRasterPos for setting the rasterpos outside the
viewport will generate an invalid current raster position, and so the
call to glDrawPixels won't have the desired effect. To make sure that
the cause of the problem is an invalid rasterpos, you can try the
following: glRasterPos2i( 0, Height/2 ); The frame will be drawn in the
middle of the view, but at least you should see something.
If the view is still black after those changes, the problem may be in
other different place that I don't imagine now.
César
cesar...@ono.com
Ruud van Gaal
<cesar...@ono.com> wrote:
...
>> Now the FLIPPING is not obtained after I negated the factorY. In order
>> to add flipping we put
>> glPixelZoom( factorX, -factorY ); //default 1, -1
>> glRasterPos2i( 0, Height );
>
>
>I think the correct coordinates should be glRasterPos2i( 0, Height-1 );
This, or try others, start with glRasterPos2i(0,Height/2) and proceed
from there. I don't know really, I have library calls inbetween this
to make the coordinate system like I'm used to (which is (0,0) at the
top left). Have had enough problems with glPixelZoom() which acts on
those coordinates (I flip all Y coordinates, which should be zoomed as
well when a non-1-1 pixel zoom is active).
>Note that any call to glRasterPos for setting the rasterpos outside the
>viewport will generate an invalid current raster position, and so the
>call to glDrawPixels won't have the desired effect. To make sure that
>the cause of the problem is an invalid rasterpos, you can try the
>following: glRasterPos2i( 0, Height/2 ); The frame will be drawn in the
>middle of the view, but at least you should see something.
Or use the glBitmap() trick; always use glRasterPos2i(), followed by
glBitmap() with a null bitmap, but offset x/y. That keeps the
RASTER_POSITION_VALID bit on, so glDrawPixels() will actually draw
something. (it's a FAQ btw)
Oh, I must read more carefully, the hgt/2 trick. ;-)
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Free car sim : http://www.marketgraph.nl/gallery/racer/
César Blecua Udías
>
> Oh, I must read more carefully, the hgt/2 trick. ;-)
The most fun of all is that both of us said height/2. We could have
chosen 100, 200, 300, but no way... it had to be height/2
:)
César
cesar...@ono.com
Ruud van Gaal
<cesar...@ono.com> wrote:
>Ruud van Gaal wrote:
>>
>> Oh, I must read more carefully, the hgt/2 trick. ;-)
>
>The most fun of all is that both of us said height/2. We could have
>chosen 100, 200, 300, but no way... it had to be height/2
Lol, yes. :) But 100 is too scary, you might have had a window that
was only 150 high!