openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Openexr-devel] Invert lines during reading process ?


From: Luc-Eric Rousseau
Subject: RE: [Openexr-devel] Invert lines during reading process ?
Date: Mon, 5 Dec 2005 12:55:24 -0500

You wouldn't flip the geometry, that would work only in trivial cases, you 
would only flip the UV coordinates used.

I haven't done this in a while, but can make OpenGL do this with something like 
this  (assuming you're not using a texture rectangle extension) :
        glMatrixMode(GL_TEXTURE); 
        glloadIdentity(); 
        glScale(1, -1, 1);

Images in opengl and several other libraries (even Windows .bmp) are not 
bottom-up because of hardware reasons, but rather because they are defined with 
a mathematical definition with (0,0) being the bottom left of the screen, so Y 
is defined going up, for everything.  In other APIs, engineers have put 0,0 at 
the top left to mimic the hardware frame buffer format or what's convenient for 
video.

------------------
Luc-Eric Rousseau
Team Leader, User Interface
Softimage|XSI


> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden Behalf
> Of Gernot Ziegler
> Sent: Monday, December 05, 2005 8:23 AM
> To: address@hidden
> Subject: Re: [Openexr-devel] Invert lines during reading process ?
> 
> 
> Hej !
> 
> > Bob, that'll flip your geometry in the Y axis but what 
> Gernot is talking
> > about is flipping the image data before uploading it as a 
> texture to OpenGL
> > with glTexImage2D (or similar).
> Yes, I already explained a bit for Bob (it is a real annoying 
> peculiarity
> of OpenGL, stemming from the old SGI hardware restrictions, I 
> believe -
> oh, I used "SGI" and "old" in one sentence now, hope I wont 
> get stoned for
> that :P  ).
> 
> > I personally would suggest flipping it in main memory. This 
> is what I'm
> > doing, and loading the EXR is already long enough that I 
> pretty much didnt
> > notice the flipping I'm doing afterwards. I would suggest 
> trying to call
> > memcpy instead of working per byte and all that, but it 
> should be quite fast
> > for even a several mb image!
> Jupp, that's what I did now, thanks for the reassurance - it is really
> quite fast, so it should suffice at the moment - otherwise I 
> can always
> flip on the GPU using
> render-to-texture/FBOs, but that way I "pollute" my graphics mem with
> some "wrong" textures which I certainly stumble over in the 
> wrong moment
> ;)
> 
> Servus,
>   Gernot




reply via email to

[Prev in Thread] Current Thread [Next in Thread]