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" <[email protected]>
To: "Xastir - APRS client software discussion" <[email protected]>
Cc: "Tony Hunt" <[email protected]>; "Hamish Moffatt"
<[email protected]>
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 <[email protected]> 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
[email protected]
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
_______________________________________________
Xastir mailing list
[email protected]
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
