[Xastir] [OZAPRS] XASTIR - maps

Ray Wells vk2tv at exemail.com.au
Tue Nov 24 18:32:00 EST 2009


FWIW, I compiled xastir 1.9.6 on Kubuntu 9.10 with Imagemagick a couple 
of days back and it works fine. I followed the howto for 9.04 except for 
libax25-dev which came from compiling libax25 from sources.

Ray vk2tv

Tony Hunt wrote:
> 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
>>
>
> _______________________________________________
> Xastir mailing list
> Xastir at lists.xastir.org
> http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
>




More information about the Xastir mailing list