[aprssig] Re: Symbol set revisions

[Heikki Hannikainen]

   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 
> RAM.

   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
symbols).

   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