[Xastir] Automake & Bit Depth

[Tom Russo]

On Thu, Jan 07, 2010 at 01:04:58PM -0800, we recorded a bogon-computron collision of the <archer at eskimo.com> flavor, containing:
> On Thu, 7 Jan 2010, Chip G. wrote:
> 
> > 2. GraphicsMagick/ImageMagick. How can you tell what bit depth is
> > installed?
> 
> Do you mean the "--with-quantum-depth" configure flag you pass to
> GraphicsMagick, or do you mean what bit-depth you're running on your
> X11 server?

With GraphicsMagick:

  gm indentify -version | head -1

With ImageMagick:
  identify -version

This will print out a string that includes either "Q16" or "Q8" depending
on the quantum depth.  The GraphicsMagick version (gm identify -version) will
print out tons of other stuff after that first line, but the first line is
all you need for this question.

> Tom checked in a change to Xastir-CVS that fixes the quantum-depth
> problem with GM where it would display black images for maps.

Yes, and tested it both with 16 and 8 bit quantum depths on tigermaps.

> > The symptom is that
> > colors are way off on Tigermaps (online). I'm seeing parks in
> > black, highway labels are black (can't read the number as it's
> > black too). I have another computer with the exact same version of
> > the same program (im/gm) installed and it displays Tigermaps
> > properly. So I'm confused as to why one works and the other
> > doesn't.
> 
> What bit-depth are you running your X11 server at?  I generally run
> mine at 16-bits (65,536 colors).

That does sound like a server color issue to me.

With quantumdepth=16, Xastir takes the high byte of each component of the
RGB triplet and crunches it down to an appropriate number of bits for the
display.  For 24 bit displays, that means "use all 8 bits of all three
components."  For 16 bit displays that have rgb masks of 
"0xf800", "0x07e0" and "0x001f" respectively (as returned by xdpyinfo),
it uses the high-order 5 bits of red, high-order 6 bits of green, and 
high-order 5 bits of blue to construct a 16-bit color value.  
There's a third special case for visuals with the red mask  0x7c00,
green of 0x03e0 and blue of 0x001f where the high-order 5 bits of each
color are packed into 15 bits.  Everything else falls into the "RGB_OTHER"
category where the masks returned by XVisualIDFromVisual are cobbled together
somehow to make a mask and shift values to be used for constructing a pixel.

It sounds an awful lot like you must be getting caught in the "RGB_OTHER"
category.  That is, you either have an 8-bit (unlikely) or 32-bit visual,
and xastir is doing the Wrong Thing with the colors for that visual.

> "xdpyinfo" is one tool that can tell you a lot about your X11
> server.

I use 24 bit color for my X servers, and naturally those all look fine, too.
My current xdpyinfo output shows:
screen #0:
[...]
  default visual id:  0x21
  visual:
    visual id:    0x21
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    10 bits

My guess would be that your display is neither 16 nor 24, or that it has
an unusual set of red,green, blue masks that are causing Xastir's pixel
packing to be using the RGB_OTHER case, and doing the wrong thing.

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236        http://kevan.org/brain.cgi?DDTNM
  In some cultures what I do would be considered normal. 
                                  -- Ineffective daily affirmation