Importing common bitmaps

[James Darrell McCauley]

motte (motte at xs4all.nl) writes on 8 Sep 94:
>> ideally, we should have r.in.ppm since netpbm (pbmplus) is distributed
>> with grass. That way we don't need r.in.sunrast, r.in.tiff,
>> r.in.gif, etc. Am I correct in this thinking? Is there any instance
>> where ppm is not generic enough?

>> --Darrell

>Am I right in stating that ppm is not the ideal format to use as standard 
>input (or output) from GRASS, even when it's PD? To my experience ppm 
>files become very large and pbmplus is definitely slower than for 
>example xv or Image Alchemy - maybe that's not an issue for everyone, but 
>on my Sun IPC I don't want to spend much CPU and disk space on converting 
>images. The real problem with pbmplus seems that it uses ppm,pgm and pbm as 
>an intermediate format for every conversion, whereas e.g. Image Alchemy 
>(at least that's what it seems to do) converts directly from one format 
>to the other. But I totally agree with Darrell that it's completely 
>useless to write conversion routines for GRASS where there are several 
>packages around that do that kind of stuff; maybe we should try to 
>convince the authors of the other packages to include an export option to 
>GRASS.

It would certainly be good if someone could write some
generic routines and send them the handmade software and
what's his name (author of xv). However, I am unaware
of any public domain "one step, all purpose" converters
(neither xv or alchemy are PD).

The disk space problem could be minimized if an r.in.ppm command
worked on stdin. Then, if users would find it simpler, a bunch of
scripts could be written for specific formats (e.g.,
   #!/bin/sh
   # r.in.gif (sans bells and whistles)
   giftoppm $1 | r.in.ppm -
   exit
)

[disclaimer - I haven't had a chance to look at the contrib
program that (Brown?) mentioned earlier - maybe it already
does this.]

I've been considering this feature (being able to accept data
from stdin) for site programs.

--Darrell