[Xastir] [OZAPRS] XASTIR - maps

[Tony Hunt]

So what would be the problem if Hamish compiled against ImageMagick instead 
of
GraphicsMagick to make the deb packages ?

Tony Hunt VK5AH

----- Original Message ----- 
From: "Tom Russo" <russo at bogodyn.org>
To: "Xastir - APRS client software discussion" <xastir at lists.xastir.org>
Cc: "Tony Hunt" <wavetel at internode.on.net>; "Hamish Moffatt" 
<hamish at cloud.net.au>
Sent: Wednesday, November 25, 2009 5:53 AM
Subject: Re: [Xastir] [OZAPRS] XASTIR - maps


> On Tue, Nov 24, 2009 at 11:05:27AM -0800, we recorded a bogon-computron 
> collision of the <archer at eskimo.com> flavor, containing:
>> On Wed, 25 Nov 2009, Tony Hunt wrote:
>>
>> > I cant answer the question as to if it really needs the setting of 16 . 
>> > If
>> > you leave it at default 8 and use GM then all raster maps of a specific 
>> > file
>> > type (gif I think) just turn out as black rectangles and squares. JPG 
>> > from
>> > memory actually work ok.. Thats the effect anyway but it may be the 
>> > other way
>> > around.
>> >
>> > Many of us have been uninstalling and recompiling/reinstalling with IM
>> > instead for close on a year I think.
>>
>> Correct on all counts.  Can't remember which images come out black,
>> but it's either GIF or JPEG, maybe both.  Xastir requires quantum
>> depth of 16 as currently coded.
>
> Naturally, the *best* way to address this whole thing is for someone on a
> system that has this problem to go in and debug the QuantumDepth==8 pieces
> of the Xastir code.
>
> Looking over the code, I suspect that there are too many places in 
> map_geo.c,
> map_WMS.c and map_tiger.c (the only ones that use Magick) where we're 
> doing
> more low-level bit-fiddling on color values than is normal in Magick
> applications, and in a couple of those places we're probably not doing it 
> right
> when the depth is 8.  That code needs a major refactor.  Now some systems 
> are
> even shipping with Magick that has HDRI support enabled --- in which case
> pixels aren't even integers anymore, and our tacit assumption that we can
> bit-fiddle them directly makes the code not even compile on such systems.
> Since it's only going to get worse, we really need someone who can roll up
> some sleeves and just fix Xastir properly.
>
> While they're at it, maybe it would be best to consolidate the duplicated
> code in map_WMS, map_geo, and map_tiger.c so there aren't three places to
> fix.  Duplicated code bad.
>
> The number of lines of code that actually fiddles with color bits is not
> very large, so it's just a matter of finding someone with time to work on 
> it
> and enough experience with Magick's (current) API to fix it.
>
> -- 
> 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
>