Ugly images under 16bit X11

sirk · November 11, 2006, 11:13am

Hello. I have a question about image quality problems I’m seeing under X11 when
using a 16 bit color depth.

Specifically, images that have a lot of gradients show very distinct color
bands/stipes rather than smooth transitions from color to color. Similarly,
images with lots of shading tend to display with strange artifacts.

I assume it’s because, one way or another, the pixels are getting mapped to
their closest color value in the X11 color map. Since functions such as
SDL_SetPalette are for 8 bit surfaces I’m at a loss for how to improve the
display quality short of going with 24 or 32 which aren’t options for me.

Strangely, this even happens when the images themselves have been dropped
to 8bit and contain only 200 colors. I only tried this when I couldn’t
get the original 24 bit images to work.

I’m really at a loss, I’ve started messing around with X functions such
XAllocColor but I decided I’d rather not break out of SDL until I’ve asked
around a bit.

Any ideas? Could it be some problem with X initialization or other obscure
cause?

thanks in advance.

Stephane_Marchesin · November 11, 2006, 12:41pm

sirk wrote:

Hello. I have a question about image quality problems I’m seeing under X11 when
using a 16 bit color depth.

Specifically, images that have a lot of gradients show very distinct color
bands/stipes rather than smooth transitions from color to color. Similarly,
images with lots of shading tend to display with strange artifacts.

I assume it’s because, one way or another, the pixels are getting mapped to
their closest color value in the X11 color map. Since functions such as
SDL_SetPalette are for 8 bit surfaces I’m at a loss for how to improve the
display quality short of going with 24 or 32 which aren’t options for me.

Strangely, this even happens when the images themselves have been dropped
to 8bit and contain only 200 colors. I only tried this when I couldn’t
get the original 24 bit images to work.

I’m really at a loss, I’ve started messing around with X functions such
XAllocColor but I decided I’d rather not break out of SDL until I’ve asked
around a bit.

Any ideas? Could it be some problem with X initialization or other obscure
cause?

I think you’d have to resort to dithering. Which SDL doesn’t provide for
2D/X11.
So you’d have to implement it by hand.

Stephane

sirk · November 11, 2006, 11:45am

Stephane Marchesin <stephane.marchesin wanadoo.fr> writes:

I think you’d have to resort to dithering. Which SDL doesn’t
provide for 2D/X11.
So you’d have to implement it by hand.

Stephane

Thanks for the reply. Why do you suppose I’d have to dither an 8 bit
image with only 200 colors under 16 bit color display?

Sirk

Christophe_Cavalaria · November 11, 2006, 11:54am

sirk wrote:

Hello. I have a question about image quality problems I’m seeing under X11
when using a 16 bit color depth.

Specifically, images that have a lot of gradients show very distinct color
bands/stipes rather than smooth transitions from color to color.
Similarly, images with lots of shading tend to display with strange
artifacts.

I assume it’s because, one way or another, the pixels are getting mapped
to
their closest color value in the X11 color map. Since functions such as
SDL_SetPalette are for 8 bit surfaces I’m at a loss for how to improve the
display quality short of going with 24 or 32 which aren’t options for me.

Strangely, this even happens when the images themselves have been dropped
to 8bit and contain only 200 colors. I only tried this when I couldn’t
get the original 24 bit images to work.

I’m really at a loss, I’ve started messing around with X functions such
XAllocColor but I decided I’d rather not break out of SDL until I’ve asked
around a bit.

Any ideas? Could it be some problem with X initialization or other
obscure cause?

thanks in advance.
As was said already, what you see is a lack of dithtering in the images
( dithtering was made to prevent such banding effects )

Now, the question is, are your original images you are blitting/displaying
16bit or 24bit? If the later, them you should reduce them to 16bit with a
program that knows about dithtering ( more or less any image manipulation
tool that can do 16bit images ) If the former, then there is no solution.

Reducing them to 8bit is a bad idea because the colors choosen for the image
are in 24bit and still won’t map perfectly on the color space of a 16bit
mode.

sirk · November 11, 2006, 12:24pm

Christophe Cavalaria <chris.cavalaria free.fr> writes:

Now, the question is, are your original images you are blitting/displaying
16bit or 24bit? If the later, them you should reduce them to 16bit with a
program that knows about dithtering ( more or less any image manipulation
tool that can do 16bit images ) If the former, then there is no solution.

Reducing them to 8bit is a bad idea because the colors choosen for the image
are in 24bit and still won’t map perfectly on the color space of a 16bit
mode.

Hmm, thanks. Your answer tracks to my guess about what’s going on but I’m not
sure what I can do about it. All the original images are 24bpp but none of my
image programs (Photoshop, Photopaint) will save an image at 16bpp, I can either
have 24 or 8. What image format supports a native 16bpp image? Would the image
program have to understand a particular 16 bit color space?

thanks again.

Stephane_Marchesin · November 11, 2006, 1:46pm

sirk wrote:

Stephane Marchesin <stephane.marchesin wanadoo.fr> writes:

I think you’d have to resort to dithering. Which SDL doesn’t

provide for 2D/X11.

So you’d have to implement it by hand.

Stephane

Thanks for the reply. Why do you suppose I’d have to dither an 8 bit
image with only 200 colors under 16 bit color display?

8 bit is paletted, 16 bit is not. It’s possible to have, say, 100
different shades of blue using a 256-color palette which might not
translate well into 16bpp.

Stephane

Torsten_Giebl · November 11, 2006, 1:28pm

Hello !

of my image programs (Photoshop, Photopaint) will save an image at 16bpp,
I can either
have 24 or 8. What image format supports a native 16bpp image? Would the
image program have to understand a particular 16 bit color space?

Does Photoshop not support something like this ?
Have you tried irfanview ?

CU

David_Olofson · November 11, 2006, 1:30pm

[…]

Hmm, thanks. Your answer tracks to my guess about what’s going on
but I’m not sure what I can do about it. All the original images
are 24bpp but none of my image programs (Photoshop, Photopaint) will
save an image at 16bpp, I can either have 24 or 8. What image
format supports a native 16bpp image?

16 bpp is a rather strange pixel format, and I’m not even sure any
standard file formats support it direcly. Besides, there are at least
two commonly used 16 bpp formats, RBG 555 and RGB 565, and you need
to use the right one for prerendered dithering to work properly.

Would the image program have to understand a particular 16 bit color
space?

Not really. You can dither to 555 or 565 and then save the images in
24 bit (888) format. Might be tricky if the application doesn’t have
an explicit feature to do it, but it should be doable. (You only
actually have to apply the “dither offsets”, as the truncation to the
final bit depth will be done when you SDL_DisplayFormat() the images.
You can probably do it by just blending in a B/W layer with the
dither pattern.)

Either way, you’re still in trouble if the 16 bit mode you get does
not have the pixel format you expect, so I wouldn’t really recommend
messing with it.

I think the best and most flexible way is to implement your own
dithering filter, that is applied when loading and converting the
graphics to display format. This allows you to support any pixel
format, as well as non-dithered 24 bpp, using the same artwork.

There is some code in Kobo Deluxe that might be useful, in
s_filter_dither() found in graphics/filters.c around line 267. It
implements 2x2 and 4x4 “checkerboard patterns”, and noise dithering.

http://www.olofson.net/kobodl/download.html

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Saturday 11 November 2006 13:24, sirk wrote:

Ulrich_von_Zadow · November 11, 2006, 2:18pm

sirk wrote:

Christophe Cavalaria <chris.cavalaria free.fr> writes:

Now, the question is, are your original images you are blitting/displaying
16bit or 24bit? If the later, them you should reduce them to 16bit with a
program that knows about dithtering ( more or less any image manipulation
tool that can do 16bit images ) If the former, then there is no solution.

Reducing them to 8bit is a bad idea because the colors choosen for the image
are in 24bit and still won’t map perfectly on the color space of a 16bit
mode.

Hmm, thanks. Your answer tracks to my guess about what’s going on but I’m not
sure what I can do about it. All the original images are 24bpp but none of my
image programs (Photoshop, Photopaint) will save an image at 16bpp, I can either
have 24 or 8. What image format supports a native 16bpp image? Would the image
program have to understand a particular 16 bit color space?

Paint Shop Pro will dither images to 16 bpp. Alternatively, you can try
adding some noise to the image - not quite as good, but it’ll get rid of
the banding.

Cheers,

Uli

Simon_Roby · November 11, 2006, 7:00pm

Pardon me asking, but I’m curious as to why you can’t use 24/32 bit?
Are you running on some special embedded hardware? Or is it one of
those old 3dfx cards that could only do 16bit?On 11/11/06, sirk wrote:

Hello. I have a question about image quality problems I’m seeing under X11 when
using a 16 bit color depth.

Specifically, images that have a lot of gradients show very distinct color
bands/stipes rather than smooth transitions from color to color. Similarly,
images with lots of shading tend to display with strange artifacts.

I assume it’s because, one way or another, the pixels are getting mapped to
their closest color value in the X11 color map. Since functions such as
SDL_SetPalette are for 8 bit surfaces I’m at a loss for how to improve the
display quality short of going with 24 or 32 which aren’t options for me.

–

SR

sirk · November 12, 2006, 8:42am

Simon Roby <simon.roby gmail.com> writes:

Pardon me asking, but I’m curious as to why you can’t use 24/32 bit?
Are you running on some special embedded hardware? Or is it one of
those old 3dfx cards that could only do 16bit?

Yep, special embedded hardware.

Thanks to everyone for your answers, this won’t be the last you see of me.

regards,

Sirk

Bill_Kendrick · November 12, 2006, 6:12pm

Wow, I wouldn’t image you’d see THAT much banding at 16bpp. You sure
it’s not something wacky like 12bpp (4096 color)? :)On Sun, Nov 12, 2006 at 08:42:07AM +0000, sirk wrote:

Simon Roby <simon.roby gmail.com> writes:

Pardon me asking, but I’m curious as to why you can’t use 24/32 bit?
Are you running on some special embedded hardware? Or is it one of
those old 3dfx cards that could only do 16bit?

Yep, special embedded hardware.

Thanks to everyone for your answers, this won’t be the last you see of me.

–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

David_Olofson · November 13, 2006, 8:26am

12 bpp (RBG 444, like on the OCS and ECS Amigas) isn’t all that much
worse than 565 or 555, so I’d say 16 bpp is quite horrible
enough.

The bands just get twice as wide, or four times in the case of the
green channel of 565. (Which actually tends to look worse than 555
without dithering, as every other band in some scales becomes too
green…)

I didn’t think it would be that bad either - until I tried 16 bpp in
Kobo Deluxe with the new 24 bpp graphics. That’s why I implemented
dithering. Then again, I’m the kind of person who thinks current
generation DVD and DTV standards look like crap.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Sunday 12 November 2006 19:12, Bill Kendrick wrote:

On Sun, Nov 12, 2006 at 08:42:07AM +0000, sirk wrote:

Simon Roby <simon.roby gmail.com> writes:

Pardon me asking, but I’m curious as to why you can’t use 24/32
bit?
Are you running on some special embedded hardware? Or is it one
of
those old 3dfx cards that could only do 16bit?

Yep, special embedded hardware.

Thanks to everyone for your answers, this won’t be the last you
see of me.

Wow, I wouldn’t image you’d see THAT much banding at 16bpp. You
sure it’s not something wacky like 12bpp (4096 color)?

James_Haley · November 13, 2006, 4:50pm

Simon Roby <simon.roby gmail.com> writes:

Pardon me asking, but I’m curious as to why you can’t use 24/32 bit?
Are you running on some special embedded hardware? Or is it one of
those old 3dfx cards that could only do 16bit?

Yep, special embedded hardware.

Thanks to everyone for your answers, this won’t be the last you see of
me.

Wow, I wouldn’t image you’d see THAT much banding at 16bpp. You sure
it’s not something wacky like 12bpp (4096 color)?

–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

Actually you will. I wrote a menu subsystem for a game I was working on
that did the Final Fantasy VII-style fade from one side of the menu rect to
the other using a precalculated color ramp. In 32-bit it was perfectly
smooth,
but in 16-bit it looked like stripes. I added some code for such video modes
that randomized the edges and it looked a bit better (I didn’t know how to
implement true dithering ).

James Haley>On Sun, Nov 12, 2006 at 08:42:07AM +0000, sirk wrote:

Add a Yahoo! contact to Windows Live Messenger for a chance to win a free
trip!
http://www.imagine-windowslive.com/minisites/yahoo/default.aspx?locale=en-us&hmtagline

Bill_Kendrick · November 13, 2006, 6:16pm

Adding to Christmas list: Shiny new DVI LCD monitor to replace ~8 year old CRT.
(Email me privately if you need my shipping address. ;^) )On Mon, Nov 13, 2006 at 10:50:11AM -0600, James Haley wrote:

Wow, I wouldn’t image you’d see THAT much banding at 16bpp.

Actually you will.

–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

Kuisma_Salonen · November 14, 2006, 9:23am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bill Kendrick wrote:> On Sun, Nov 12, 2006 at 08:42:07AM +0000, sirk wrote:

Simon Roby <simon.roby gmail.com> writes:

Pardon me asking, but I’m curious as to why you can’t use 24/32 bit?
Are you running on some special embedded hardware? Or is it one of
those old 3dfx cards that could only do 16bit?
Yep, special embedded hardware.

Thanks to everyone for your answers, this won’t be the last you see of me.

Wow, I wouldn’t image you’d see THAT much banding at 16bpp. You sure
it’s not something wacky like 12bpp (4096 color)?

I might be little bit late for the discussion but here’s my suggestion:

dithering (yes, have been suggested by others). But basically you have
three possibilities:

Graphics production-time dithering. If you are making something
especially for that particular embedded platform and nowhere else, you
probably want to use your favorite image manipulation program to dither
your images to 565. Some programs cannot do this but in most you can at
least split the images and dither the channels separately to bit count
you have (in worst case you have to make grayscale palette to do that).
Build-time dithering. If you want that your package can be built into
various platforms, you probably want to insert into your build
scripts/Makefiles/etc automation for dithering and converting images to
target data format. SDL_Image should provide sufficient loaders for your
graphics files (it is good idea to have the original data files in some
common format, final distributed can be more optimized).
Load-time dithering. If you want that people could run it with little
bit different HW, like screen size/BPP variations (let’s say, same cpu
architecture but 12bpp video), you most probably would like to do this.
You would distribute the graphics in 24bpp format (or even higher) and
when you load the data for your application you would do
conversion/dithering round here. SDL_PixelFormat structure provides
enough information to do this.

Ok, in points 2 and 3 you would obviously need to implement the
dithering yourself (actually in alternative 2 if you have ImageMagick
installed on build machine, you can do this with ‘convert’ command-line
tool). I would suggest Floyd-Steinberg dithering as it’s fairly simple
and the quality is quite nice. Wikipedia has small page about that but
that should provide sufficient information:

Basically it just dumps accuracy loss to neighboring pixels. My
suggestion here is that with integer operations it’s definitely
recommend to increase accuracy, for example to convert the image to 48
bit 16-16-16 and perform the dithering with that data (for example for 8
to 6 bit conversion the maximum accuracy loss value is 3 and imagine
what accuracy you have when you divide it with 16).

I guess that was my 2 cents…

– Kuisma
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFFWYsMHIcMorDK+qsRAqpeAKCQ6BBB6wzLrmVjCVQ3QIOHD3WnbQCeOYBf
We9CnxwRK2HbOIuk/BuBvY8=
=utdS
-----END PGP SIGNATURE-----

Bill_Kendrick · November 14, 2006, 8:59pm

Build-time dithering. If you want that your package can be built into
various platforms, you probably want to insert into your build
scripts/Makefiles/etc automation for dithering and converting images to
target data format. SDL_Image should provide sufficient loaders for your
graphics files (it is good idea to have the original data files in some
common format, final distributed can be more optimized).

SDL_Image could be useful, but it’s probably even easier to just throw
ImageMagick or NetPBM in your workflow. As a lame example, something like:

production/images/foo.bmp: source/images/foo.png
pngtopnm source/images/foo.png | ppmquant -fs 256 | ppmtobmp > …

If you DO want to write something from scratch, it’s certainly reasonable
to use SDL_Image, but it seems like a little bit of overhead, when you could
simply utilize libPNG, libJPEG, etc. Though, I suppose they each have their
own crazy APIs that aren’t quite as simple as SDL_Image’s “IMG_Load()”

Load-time dithering. If you want that people could run it with little
bit different HW, like screen size/BPP variations (let’s say, same cpu
architecture but 12bpp video), you most probably would like to do this.
You would distribute the graphics in 24bpp format (or even higher) and
when you load the data for your application you would do
conversion/dithering round here. SDL_PixelFormat structure provides
enough information to do this.

Depending on your target audience, it may even make sense to cache the
converted images, so you only have to run through this process once.
(And do it again if they suddenly decide to upgrade their video card later
down the road )

Ok, in points 2 and 3 you would obviously need to implement the
dithering yourself (actually in alternative 2 if you have ImageMagick
installed

I should read the whole message before I begin replying. ;)On Tue, Nov 14, 2006 at 11:23:24AM +0200, Kuisma Salonen wrote:

–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/