SDL_image Oddities

I’ve isolated what I think is a problem with SDL_image.

When I load an image using SDL_image library I thought it
was safe to assume that if I tested to see if Rmask < Bmask
for the SDL_Surface format, it would mean that the image is
an RGB image. Similarly, if Rmask > Bmask I thought the
image would be a BGR image. This holds true on my friends
windows machine, but on my mac it’s the opposite way around.
I assume this has something to do with endianness.

Does this mean that Rmask and Bmask are messed up on big
endian machines? Or is SDL_image setting them improperly?

Thanks,
Randall Leeds

“Randall Leeds” wrote in message
news:mailman.1012004108.9204.sdl at libsdl.org…> I’ve isolated what I think is a problem with SDL_image.

When I load an image using SDL_image library I thought it
was safe to assume that if I tested to see if Rmask < Bmask
for the SDL_Surface format, it would mean that the image is
an RGB image. Similarly, if Rmask > Bmask I thought the
image would be a BGR image. This holds true on my friends
windows machine, but on my mac it’s the opposite way around.
I assume this has something to do with endianness.

Does this mean that Rmask and Bmask are messed up on big
endian machines? Or is SDL_image setting them improperly?

Thanks,
Randall Leeds

“Rainer Deyke” wrote in message
news:a2t8tc$o74$1 at ftp.lokigames.com

“Randall Leeds” wrote in message
news:mailman.1012004108.9204.sdl at libsdl.org

I’ve isolated what I think is a problem with SDL_image.

When I load an image using SDL_image library I thought it
was safe to assume that if I tested to see if Rmask < Bmask
for the SDL_Surface format, it would mean that the image is
an RGB image. Similarly, if Rmask > Bmask I thought the
image would be a BGR image. This holds true on my friends
windows machine, but on my mac it’s the opposite way around.
I assume this has something to do with endianness.

Does this mean that Rmask and Bmask are messed up on big
endian machines? Or is SDL_image setting them improperly?

Sorry about that empty message. Stupid Outlook Express…

Anyway, it depends on what you mean by RGB and BGR. In a sense, Rmask

Bmask always implies RGB. However, the bytes are stored in reverse
order on little endian systems. For example, say you have Rmask =
0xff0000, Gmask = 0x00ff00, Bmask = 0x0000ff, and you want to encode a
pixel of pure red. It would have a value of 0xff0000, but on little
endian systems the bytes are stored in reverse order: 00 00 ff. If
you just look at the bytes, it looks like BGR. But consider a
different set of masks: Rmask = 0xff8000, Gmask = 0x007f80, Bmask =
0x00007f. If you encode pure red, it will look like 0xff8000, but the
actual bytes on little endian computers look like 00 80 ff. So you
see, it is not really BGR, but RGB with the byte order reversed.

In 16 and 32 bit images, this shouldn’t matter because you can treat
the image as an array of Uint16 or Uint32 without looking at the
individual bytes. In 24 bit images things don’t work out as nicely.–
Rainer Deyke | root at rainerdeyke.com | http://rainerdeyke.com

Randall Leeds wrote:

When I load an image using SDL_image library I thought it
was safe to assume that if I tested to see if Rmask < Bmask
for the SDL_Surface format, it would mean that the image is
an RGB image.

If you by “RGB” image mean “the red byte comes first in memory, then the
green byte, then the blue byte”, then your criterion is wrong. The masks do
not apply to memory; they apply to pixel values. A pixel value is what you
get when you read a pixel as integer from memory in the native byte order
(what else)

Does this mean that Rmask and Bmask are messed up on big
endian machines? Or is SDL_image setting them improperly?

Nothing is messed up or set improperly except your understanding :slight_smile: