graphic image ordering question

Member
Posts: 321
Joined: 2004.10
Post: #1
I’m trying to get a better idea on some basic concepts. In other words, if this is a really stupid question, please don’t be too harsh.

Let’s say I create (paint, draw, whatever) a 3x3 RGBA pixel image using any graphical tool imaginable. It has the following structure on my display.

ABC
DEF
GHI

Now let’s say I save off this image as a .TGA, .BMP, and .PNG file. What the heck, let’s pretend I save the image off in every graphical format ever invented.

I can conceivably envision 8 possible ways the data could be saved off:

ABCDEFGHI (left to right; top to bottom)
Or
ADGBEFCFI (top to bottom; left to right)
Or
GHIDEFABC (left to right; bottom to top
Or
GDAHEBIFC (bottom to top; left to right)
Or
CBAFEDIHG (right to left; top to bottom)
Or
CFIBEHADG (top to bottom; right to left)
Or
IFCHEBGDA (bottom to top; right to left)
Or
IHGFEDCBA (right to left; bottom to top)

Granted, some seem pretty silly, but I’m aiming for completeness here. The first and third ordering seems most plausible to me.

Here’s my question: Of the previous eight sequences, IS ONE AND ONLY ONE WAY ALWAYS USED? Or can it vary between different graphical formats?

thanks.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #2
From what I've seen, the 2 main methods are ABCDEFGHI and GHIDEFABC.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #3
Depends entirely on the image file format and how it compresses its data. However, this is abstracted from your needing to know it by whatever API exports/imports the image. Presumably, the relevant thing to know is which way up that API organizes its data...
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #4
most image formats are compressed, and therefore do none of the above.

libjpeg and libpng both pretend that their format does the first. There are formats that (pretend to) do the third. There are formats (DDS in particular) where it really makes no sense to pretend that it does any of the above.
Quote this message in a reply
Member
Posts: 321
Joined: 2004.10
Post: #5
Quote:most image formats are compressed, and therefore do none of the above.

I'm going to respectfully disagree here. For compression to take place, doesn't the 2D image have to be streamed to a 1D structure (or at least "considered" a 1D stream. Then the byte stream is analyzed down the line and repeating bytes are compressed. Going from the 2D->1D step, requires that one of the above ordering is mandatory. Reverse the operations to create an image from a compressed file.

I briefly looked at the DDS format. (Oh joy, another format!) Looks like it basically consists of the ordered sequence of the mip maps. That is, it stores the 1x1, 2x2, 4x4...256x256 mip maps. However, doesn't each mip map have to be handled in one of the ways mentioned in my original posting? In other words, isn't DDS kinda like simply packageing up multiple (albeit differing sized) single images just into one big mipmap file?
Quote this message in a reply
Member
Posts: 114
Joined: 2005.03
Post: #6
What you describe is a rather easy compression algorithm. Many, especially lossy algorithms, transform the image in various ways before they do that, though. Also, the compression in DDS, for example, compresses squares of four pixels at a time (if I recall correctly).
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #7
Yes, DDS compresses 16 pixels in a 4x4 square at once. The blocks of 4x4 are taken left-to-right, top-to-bottom, but you can't claim that the image is stored in that way.

Most image compression, particularly lossy compression, looks at the image in two dimensions, not just one.
Quote this message in a reply
Member
Posts: 321
Joined: 2004.10
Post: #8
Wow. This is getting deep. Let's do a big picture sanity check.

From the perspective of the programmer, one shouldn't care or even need to know this much detail: Graphic Tools (well established - correct ones, that is) will save off the images correctly. Likewise, if you use a library routine to read in a data file, it will then be read in fine.

I only started this thread because I'm playing around with fonts (another person's code) and when I open my .png file, I see the ASCII characters fine. But when I them in, they are displayed upside down, or flipped, or mirrored. So I'm poking around wondering to myself: is it the .png file, the SDL read function, the OpenGL data[] array, or something else? I thought understanding first principles would clear stuff up but from what I've learned here, this is not the case.

Thanks all. Did look at GlyphTool and it looks sweet! I think I'll jump ship for this baby.


Edit: Maybe the question wan't completely worthless. Say I've got a square texture and I want to strip off a little square with that texture. I believe it is called Mosaicing. Assuming I don't have access to something like glTexSubImage2D, then I would have to know the ordering of the pixels, as I so tediously documented initially. Right?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #9
You still don't give a damn what order they're in in the file, only what your API shows you when it gives you uncompressed image data.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #10
WhatMeWorry Wrote:I only started this thread because I'm playing around with fonts (another person's code) and when I open my .png file, I see the ASCII characters fine. But when I them in, they are displayed upside down, or flipped, or mirrored. So I'm poking around wondering to myself: is it the .png file, the SDL read function, the OpenGL data[] array, or something else?
Ah, this is a simpler question, and easier to answer. OpenGL expects image data to be in left-to-right, bottom-to-top order. Most image loading APIs (presumably including the SDL read function) return image data in left-to-right, top-to-bottom order... So, your images will often appear upside-down when drawn via OpenGL.

Three reasonable solutions come to mind:
  • Invert the Y axis on your texture coordinates. (You can probably do this with the texture matrix if you don't want to change your glTexCoord calls.)
  • Flip the image vertically at runtime when you load it.
  • Save the image file upside-down.
Quote this message in a reply
Member
Posts: 321
Joined: 2004.10
Post: #11
Quote:OpenGL expects image data to be in left-to-right, bottom-to-top order. Most image loading APIs (presumably including the SDL read function) return image data in left-to-right, top-to-bottom order...

Ahhh. My itch has been scratched. Say, does anybody know what order DirectDraw expects the image data to be in? I'm curious if OpenGL is the odd duck here compared with other graphical APIs?

Also, are there any advantages or disadvantages of one order over the other or is it completely arbitrary?
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #12
Completely arbitrary.

(No idea about DirectDraw... Sorry.)
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #13
It's completely arbitrary, except for the fact that having the origin being the upper-left is the opposite of Cartesian coordinates. It could mean a little extra work or be irrelevant depending on how you use the coordinate system.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Z Ordering Nick 4 2,635 Aug 25, 2004 09:37 AM
Last Post: Nick