[aprssig] Re: Symbol set revisions
hessu at hes.iki.fi
Fri Apr 18 01:16:54 CDT 2008
Hi Steven, & others,
On Thu, 17 Apr 2008, Stephen H. Smith wrote:
> Most applications don't use hundreds of individual images. APRSplus,
> UIview, UIpoint and findu all use GRIDS of multiple symbol images in two two
> graphics files. X,Y addressing is use to clip out the desired symbol for
> display from the grid.
Ok. Thanks for your insight - I haven't seen those formats documented
in clear terms before. I'm still wondering how each of these applications
/ formats do transparency?
I don't care so much whether the master symbol image set is distributed
in a single image file with the symbol images in a grid, or as individual
images. It was just a suggestion. It is straightforward to write
converters from a grid to pre-sliced images, and back. Steven, do you have
programs to convert between the different formats?
I am mainly interested in having a clear machine-readable specification
for each symbol, mapping the symbol tables and characters to each symbol
image, giving descriptions for the images, and other metadata (such as
whether the image can take overlays, and whether it can be rotated
meaningfully, and where it is initially pointing before rotating). Having
the configuration file with the metadata would make the downloaded symbol
image file automatically useful without a lot of manual work.
Bob also pointed out, that it'd be useful to specify the meanings of the
magic overlay characters in the metadata file, so that each application
could show the same longer description string for the symbol+overlay.
> Storing individual images is horribly inefficient use of disk space since
> each 16x16 pixel 256-color image that natively occupies less than one-half K
> (16x16 pixels x 1 byte-per-pixel + some overhead for the indexed pallette)
> winds up occupying the minimum allocation unit of the hard disk , typically
> 4K to 32 K per character.
Right. 4k blocks on the filesystem here (ext3).
> I would guess that it also yields a lot slower lookup since it would require
> (relatively slow) disk access every time a symbol is required (or require
> keeping HUNDREDS of individual images cached in RAM) rather than dicing and
> slicing two graphics images read once from the hard disk and cached in
On a busy web server, using individual pre-sliced images actually gives
much better performance. The web server software and the underlying
operating system has been heavily optimized to very, very quickly spit out
static files from the disk. It can easily do that at amazingly high rates.
If it, instead of simply spitting out a small existing file, would have to
actually open and decode a graphics file, crop a small part out of it,
maybe rotate it, and then encode it to a new small GIF/PNG file for each
and every request (I get a lot of them), it'd take plenty of CPU time to
do that, and more memory too, because the little bit of software needed to
do those conversions (for every request) would occupy some memory, too. It
is simply faster to cache the pre-sliced and pre-rotated images.
The symbol image set I have is only about 2 megabytes, + 9 for the
pre-rotated images, which nowadays, for a busy web server, is nothing -
it'll be cached all the time. And that was counted with the 'du -k'
command which counts real disk usage (including filesystem block
overhead). The servers have 4 or 8 GB of memory, and they need to, since
my database server processes are around 2 GB each. But that's OK, since 4
GB is roughly around $100 USD in the shop.
And I'm not going to worry about the couple megabytes of disk either.
With 120 to 750 GB disks being common, it doesn't really matter, the
actual APRS tracking history database is so big anyway.
I also have to serve both GIF files (for browser compatibility, IE6
doesn't do transparency in PNG images), and PNG files (for Google Earth,
it doesn't do transparency in GIF images). So that doubles the disk+cache
footprint again, but it's still insignificant, 2 MB (without rotated
I do understand that you'll have to worry about these issues in a
completely different light, when you're designing for a really small
embedded device, like a radio with only 256k of flash and 128k of RAM.
That's fun, too, a completely different set of interesting problems to
tackle. But if you're going to write a server application, or a fancy new
APRS application for today's computers, this is not an issue.
- Hessu, OH7LZB
More information about the aprssig