Converting SDL_Surface from 16,24,32 bit to 8-bit?

I’m looking for code that will take a given surface in either 15, 16, 24,
or 32 bit and convert it to an 8-bit surface.

I’m not concerned about losing any color information, since I know that
the original surface is using only 256 colors. What I’d like is to
convert to this new 8-bit surface and have it look exactly the same at
that depth, since I know that it is possible (only 256 colors actually
used).

Anyone have any advice on where to look?

Thanks,
Steve Anthony

Is the 8 bit mode paletted? If so this may be very difficult. The
16bit and higher modes use RGB values IIRC. This is different than
using a Palette of 256 possible colors.

Of course I haven’t played with this stuff since my DOS days so I could
be off my rocker altogether. :slight_smile:

DaveOn Tuesday, February 26, 2002, at 06:11 PM, Stephen Anthony wrote:

I’m looking for code that will take a given surface in either 15, 16,
24,
or 32 bit and convert it to an 8-bit surface.

I’m not concerned about losing any color information, since I know that
the original surface is using only 256 colors. What I’d like is to
convert to this new 8-bit surface and have it look exactly the same at
that depth, since I know that it is possible (only 256 colors actually
used).

Anyone have any advice on where to look?

Thanks,
Steve Anthony


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Is the 8 bit mode paletted? If so this may be very difficult. The
16bit and higher modes use RGB values IIRC. This is different than
using a Palette of 256 possible colors.

Of course I haven’t played with this stuff since my DOS days so I could
be off my rocker altogether. :slight_smile:

Dave

Yes, the 8 bit mode is paletted (by definition). Just to make sure that
everyone understands what I want to do:

Convert from a 15|16|24|32 bit RGB surface that I KNOW is only using 256
colors to an 8 bit paletted surface that consists of exactly those 256
colors.

In fact, it may be that the given surface isn’t even using all the 256
colors. Sometimes it may only use 32 or 64 of them. I suppose I could
step through each pixel, get the color info from it, and construct a
CLUT. Only problem is that for an 800x600 image, that is 800600256
operations. Is there a faster way?

Any suggestions??

Thanks,
SteveOn February 26, 2002 08:53 pm, you wrote:

On Tuesday, February 26, 2002, at 06:11 PM, Stephen Anthony wrote:

I’m looking for code that will take a given surface in either 15, 16,
24,
or 32 bit and convert it to an 8-bit surface.

I’m not concerned about losing any color information, since I know
that the original surface is using only 256 colors. What I’d like is
to convert to this new 8-bit surface and have it look exactly the
same at that depth, since I know that it is possible (only 256 colors
actually used).

Anyone have any advice on where to look?

Thanks,
Steve Anthony


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Stephen Anthony wrote:

Is the 8 bit mode paletted? If so this may be very difficult. The
16bit and higher modes use RGB values IIRC. This is different than
using a Palette of 256 possible colors.

Of course I haven’t played with this stuff since my DOS days so I could
be off my rocker altogether. :slight_smile:

Dave

Yes, the 8 bit mode is paletted (by definition). Just to make sure that
everyone understands what I want to do:

Convert from a 15|16|24|32 bit RGB surface that I KNOW is only using 256
colors to an 8 bit paletted surface that consists of exactly those 256
colors.

In fact, it may be that the given surface isn’t even using all the 256
colors. Sometimes it may only use 32 or 64 of them. I suppose I could
step through each pixel, get the color info from it, and construct a
CLUT. Only problem is that for an 800x600 image, that is 800600256
operations. Is there a faster way?

There are several ways to do this, you can, as you say step through the
original image and find the colors it actually uses and construct a CLUT
form it. This doesn’t actually take that long. You don’t need to use a
sequential search of the CLUT to find the color (as implied by the 256)
in you computation, you can use a hash to find it and reduce the time to
800
600*(small N). Also, since you “know” that the actual number of
colors is <= 256 you can do the conversion as you generate the CLUT so
that you only have to walk through the image once.

Or, you can just create a CLUT that is “good enough” such as the SDL
default 8 bit CLUT and do the conversion using that LUT. Also, since you
"know" that the image doesn’t use more than 256 colors you may well be
able to deduce the perfect CLUT from knowledge you already have about
how the images are generated.

If all else fails you need to find a copy of Graphic Gems II and look at
"Efficient Inverse Color Map Computation" by Spencer W. Thomas. I went
to school with this guy, he’s fscking brilliant.

	Bob P.> On February 26, 2002 08:53 pm, you wrote:

Any suggestions??

Thanks,
Steve

On Tuesday, February 26, 2002, at 06:11 PM, Stephen Anthony wrote:

I’m looking for code that will take a given surface in either 15, 16,
24,
or 32 bit and convert it to an 8-bit surface.

I’m not concerned about losing any color information, since I know
that the original surface is using only 256 colors. What I’d like is
to convert to this new 8-bit surface and have it look exactly the
same at that depth, since I know that it is possible (only 256 colors
actually used).

Anyone have any advice on where to look?

Thanks,
Steve Anthony


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


±-----------------------------------+

  • Bob Pendleton is seeking contract +
  • and consulting work. Find out more +
  • at http://www.jump.net/~bobp +
    ±-----------------------------------+

Stephen Anthony writes:

Yes, the 8 bit mode is paletted (by definition). Just to make sure that
everyone understands what I want to do:

This is rather out of topic - I don’t think the above statement is
true. Isn’t Windows 8bpp mode true color? From what I can remember,
that is the source of the concept of “web safe” colors (i.e colors
that are shown on 8bpp windows devices without dithering).–
[ Below is a random fortune, which is unrelated to the above message. ]
All syllogisms have three parts, therefore this is not a syllogism.

Sorry I wasn’t more clear. I meant that it is by definition in SDL,
which is what the question was concerning.

As for there being 8 bit true color images in Windows, I’ve never heard
of that before. But I don’t have much experience with Windows.

SteveOn February 27, 2002 09:39 pm, you wrote:

Stephen Anthony writes:

Yes, the 8 bit mode is paletted (by definition). Just to make sure
that everyone understands what I want to do:

This is rather out of topic - I don’t think the above statement is
true. Isn’t Windows 8bpp mode true color? From what I can remember,
that is the source of the concept of “web safe” colors (i.e colors
that are shown on 8bpp windows devices without dithering).

Stephen Anthony writes:

Yes, the 8 bit mode is paletted (by definition). Just to make sure that
everyone understands what I want to do:

This is rather out of topic - I don’t think the above statement is
true. Isn’t Windows 8bpp mode true color? From what I can remember,
that is the source of the concept of “web safe” colors (i.e colors
that are shown on 8bpp windows devices without dithering).
8bpp is literally 8 bits per pixel. 2^8 th allows for the
representation of 256 unique values. A Byte. I suppose technically
there’s no reason that a 8bpp mode couldn’t exist without an index
palette, but there would be so few shades of each colour (sic) that it
would be useless. After all, the colours mapped to each value of 8, 16,
24 and 32bpp is really arbitrary to whatever colour system is being
used.

Truecolour is (last I heard) defined technically (reality’s bpp is still
up for debate :)) as 32bpp. This is most likely because, to my
knowledge, the human eye is incapable of distinguishing the difference
between even the ~4 billion colours 32bpp provides, let alone more. In
fact, personally, I can see little or no difference between 16 and 32bpp
renderations.

And now that I’m SOOO far off topic for this list. I’ll be quiet.On Wed, 2002-02-27 at 20:09, David Hedbor wrote:


[ Below is a random fortune, which is unrelated to the above message. ]
All syllogisms have three parts, therefore this is not a syllogism.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

End of Rant.

Jimmy
JimmysWorld.org
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020227/5c35a9e5/attachment.pgp

Jimmy wrote:

Truecolour is (last I heard) defined technically (reality’s bpp is still
up for debate :)) as 32bpp. This is most likely because, to my
knowledge, the human eye is incapable of distinguishing the difference
between even the ~4 billion colours 32bpp provides, let alone more. In
fact, personally, I can see little or no difference between 16 and 32bpp
renderations.

Truecolour is 32bpp, but you don’t really get 2^32 different colours. 8 bits
are used as alpha values to indicate transparency. So you get R8_G8_B8_A8.
Which results in 2^24 different colours with each pixel having an alpha of
[0…255].

High colour is 24bpp, and you get 2^24 different colours. So you get R8_G8_B8.

Reality doesn’t really have bpp since we see in analog. So it has an infinite
number of colours. Actually, colour doesn’t really exist in reality, it is just
perception inside of our head. “Colour” in reality is a bunch of waves hitting
our eyes at different frequencies.

So what the hell was my point? …oh yeah. Only use 32bpp if you actually need
the alpha channel. Otherwise 24bpp gives you the exact same colour.

Anyway, getting back to the original, original question. If you want to build a
CLUT table, search google for the Median Cut Algorithm.

You said that the image is actually 8 bits stored in an image that is greater
than 8 bits. If the pixels are stored as xxxxxxxx--------, with the xxx’s being
the original 8 bits then you could just do a bunch of bit shifts for each pixel.
If the pixels are stored as --------xxxxxxxx, with the xxx’s still being the
original 8bits. Then you could just throw away the uninteresting bits.

P.

“Parveen Kaler” wrote in message
news:mailman.1014864668.24699.sdl at libsdl.org

High colour is 24bpp, and you get 2^24 different colours. So you
get R8_G8_B8.

High color refers to 16 bit.

So what the hell was my point? …oh yeah. Only use 32bpp if you
actually need
the alpha channel. Otherwise 24bpp gives you the exact same colour.

32 bit is often faster.–
Rainer Deyke | root at rainerdeyke.com | http://rainerdeyke.com

Stephen Anthony wrote:

Stephen Anthony writes:

Yes, the 8 bit mode is paletted (by definition). Just to make sure
that everyone understands what I want to do:

This is rather out of topic - I don’t think the above statement is
true. Isn’t Windows 8bpp mode true color? From what I can remember,
that is the source of the concept of “web safe” colors (i.e colors
that are shown on 8bpp windows devices without dithering).

IIRC the Windows 8BPP palette has a small number of colors preallocated
that Windows counts on being there. The web safe colors are basically
that set of colors. Long ago when I used to work on Windows 8 bit games
we would be very very careful that the palette for all the art in a game
used only palette entries that were NOT reserved by windows. You can
over write those entries in the palette, but then all the screen colors
out side your game window go wonky. Of course, you only have this
problem with windowed games.

BTW, the default 8bpp palette in SDL is what I would call a 232 direct
color palette but most people would call it a truecolor palette. The
difference between directcolor and truecolor is the use of a gamma
coorection table. Direccolor doesn’t use one and truecolor does.

You can have direct/true color systems with as few as 3 bits, on for
each of red, green, and blue. And you can use as many bits as you want
for each color channel you can even use arbitrary precision floating
point and fixed point numbers. The definitions are pretty general.

	Bob Pendleton> On February 27, 2002 09:39 pm, you wrote:

Sorry I wasn’t more clear. I meant that it is by definition in SDL,
which is what the question was concerning.

As for there being 8 bit true color images in Windows, I’ve never heard
of that before. But I don’t have much experience with Windows.

Steve


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


±-----------------------------------+

  • Bob Pendleton is seeking contract +
  • and consulting work. Find out more +
  • at http://www.jump.net/~bobp +
    ±-----------------------------------+

There are several ways to do this, you can, as you say step through the
original image and find the colors it actually uses and construct a CLUT
form it. This doesn’t actually take that long. You don’t need to use a
sequential search of the CLUT to find the color (as implied by the 256)
in you computation, you can use a hash to find it and reduce the time to
800
600*(small N). Also, since you “know” that the actual number of
colors is <= 256 you can do the conversion as you generate the CLUT so
that you only have to walk through the image once.

Yes, I guess I will do it that way. But you have given me ideas on how to
speed it up. You’re right that the operations won’t be x256, since I already
have the palette stored as uint32’s and can do a hash table on those.

One 256x loop for converting the uint32’s to SDL_Color’s array, then
width*height iterations to touch each pixel, using a hash table into the
unint32 CLUT array (asuming constant lookup time).

Or, you can just create a CLUT that is “good enough” such as the SDL
default 8 bit CLUT and do the conversion using that LUT. Also, since you
"know" that the image doesn’t use more than 256 colors you may well be
able to deduce the perfect CLUT from knowledge you already have about
how the images are generated.

Unfortunately, I need an exact representation, since it is creating an 8-bit
snapshot of the window. The snapshot will be useless if it isn’t the same as
the window contents :slight_smile:

If all else fails you need to find a copy of Graphic Gems II and look at
"Efficient Inverse Color Map Computation" by Spencer W. Thomas. I went
to school with this guy, he’s fscking brilliant.

Hopefully it won’t come to that :slight_smile: Anyway, thanks for the useful info.

SteveOn February 27, 2002 01:09 pm, you wrote: