[GRASS-dev] cause for bad colors in output from png driver

Glynn Clements glynn at gclements.plus.com
Thu May 10 06:38:10 EDT 2007

Hamish wrote:

> > The framebuffer is always stored as B,G,R,A (the format used by 32-bpp
> > BMP files).
> (answers my earlier r.what.color question)
> > This corresponds to 0xAARRGGBB on a little-endian system and
> > 0xBBGGRRAA on a big-endian system (e.g. Mac).
> dumb question: are Intel Macs now little endian?

Yes; the x86 is always little-endian; if you want to read big-endian
values, you have to do it in software.

> > Externally (DRV_color, DRV_lookup_color), the alpha value is always
> > zero (0 = opaque, 255 = transparent),
> in gis.h I used:
> typedef struct
> {
>     unsigned char r, g, b, a;  /* red, green, blue, and alpha */
> } RGBA_Color ;
> typedef RGBA_Color RGB_Color;
> /* RGBA_Color alpha presets */
> #define RGBA_COLOR_OPAQUE     255
> #define RGBA_COLOR_NONE         0
> Are the above alpha OPAQUE and TRANSPARENT values backwards? I had
> pictured alpha as opacity, with OPAQUE being 100% and TRANSPARENT as 0%.
> COLOR_NONE is used to indicate that the RGB array hasn't been filled.
> (d.vect color=none)

There's no "right" answer; "alpha" can represent either opacity (0 =
transparent, 255 = opaque) or transparency (0 = opaque, 255 =

The PNG driver uses transparency because all externally-specified
colours are opaque, and at that time, the integer colour number was
stored directly in the framebuffer. Transparent pixels can only arise
from erasing the framebuffer when GRASS_TRANSPARENT=TRUE, and (more
recently) with R_bitmap(). Note that R_bitmap() uses opacity.

When writing PPM/PGM files, the PGM file contains opacity values
(255-alpha). When writing PNG files, it calls png_set_invert_alpha(),
which causes the opacity values to be returned when reading.

I'm not sure which sense the 32-bit BMP format uses; the only
application I tested (gqview) simply ignores the alpha channel. If it
turns out that it's meant to be opacity, I'll need to invert the
internal format.

Glynn Clements <glynn at gclements.plus.com>

More information about the grass-dev mailing list