title: openGL invert textures orientation during pixel-transfer?
body: <p>as we all know, openGL uses a pixel-data orientation that has 0/0 at left/bottom, whereas the rest of the world (including virtually all image formats) uses left/top.
  this has been a source of endless worries (at least for me) for years, and i still have not been able to come up with a good solution.</p>
  
  <p>in my application i want to support following image data as textures:</p>
  
  <ol>
  <li>image data from various image sources (including still-images, video-files and live-video)</li>
  <li>image data acquired via copying the framebuffer to main memory (<code>glReadPixels</code>)</li>
  <li>image data acquired via grabbing the framebuffer to texture (<code>glCopyTexImage</code>)</li>
  </ol>
  
  <p>(case #1 delivers images with top-down orientation (in about 98% of the cases; for the sake of simplicity let's assume that all "external images" have top-down orientation); #2 and #3 have bottom-up orientation)</p>
  
  <p>i want to be able to apply all of these textures onto various arbitrarily complex objects (e.g. 3D-models read from disk, that have texture coordinate information stored).</p>
  
  <p>thus i want a single representation of the texture_coords of an object. when rendering the object, i do not want to be bothered with the orientation of the image source.
  (until now, i have always carried a <code>topdown</code>-flag alongside the texture id, that get's used when the texture coordinates are actually set. i want to get rid of this clumsy hack!</p>
  
  <p>basically i see three ways to solve the problem.</p>
  
  <ol>
  <li>make sure all image data is in the "correct" (in openGL terms this
  is upside down) orientation, converting all the "incorrect" data, before passing it to openGL</li>
  <li>provide different texture-coordinates depending on the image-orientation (0..1 for bottom-up images, 1..0 for top-down images)</li>
  <li>flip the images on the gfx-card</li>
  </ol>
  
  <p>in the olde times i've been doing #1, but it turned out to be too slow. we want to avoid the copy of the pixel-buffer at all cost.</p>
  
  <p>so i've switched to #2 a couple of years ago, but it is way to complicated to maintain. i don't really understand why i should carry metadata of the original image around, once i transfered the image to the gfx-card and have a nice little abstract "texture"-object.
  i'm in the process of finally converting my code to VBOs, and would like to avoit having to update my texcoord arrays, just because i'm using an image of the same size but with different orientation!</p>
  
  <p>which leaves #3, which i never managed to work for me (but i believe it <strong>must be quite simple</strong>).
  intuitively i though about using something like <code>glPixelZoom()</code>.
  this works great with <code>glDrawPixels()</code> (but who is using that in real life?), and afaik it should work with <code>glReadPixels()</code>.
  the latter is great as it allows me to at least force a reasonably fast homogenous pixel orientation (top-down) for all images in <em>main</em> memory.</p>
  
  <p>however, it seems that<code>glPixelZoom()</code> has no effect on data transfered via <code>glTexImage2D</code>, let alone <code>glCopyTex2D()</code>, so the textures generated from main-memory pixels will all be upside down (which i could live with, as this only means that i have to convert all incoming texcoords to top-down when loading them).
  now the remaining problem is, that i haven't found a way yet to copy a framebuffer to a texture (using <code>glCopyTex(Sub)Image</code>) that can be used with those top-down texcoords (that is: how to flip the image when using <code>glCopyTexImage()</code>)</p>
  
  <p>is there a solution for this simple problem? something that is <em>fast</em>, easy to maintain and runs on openGL-1.1 through 4.x?</p>
  
  <p>ah, and ideally it would work with both power-of-two and non-power-of-two (or rectangle) textures. (as far as this is possible...)</p>