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?I agree, but I did notice that converting from PICT -> ppm -> sunrast
caused the lut's to get stuffed up a bit (this was in my Monash Uni
incarnation a few months ago).Simon Cox
The lut's get "stuffed" because while PICT & sunrast use 8bit look up
tables, ppm doesn't, using 8bits for each of Red, Green, & Blue to represent
"True Color" instead. (Actually sunrast has a True Color flavor, but
the one r.in.surast accepts is the color look up table flavor.)
Because ppm is "True Color", you can get all those colors you never see
on your 8bit screen from your "continuous" raster maps if you use r.out.ppm,
then send the ppm to a slide recorder or other 24bit output device.
So in the conversion from ppm to sunrast, the
look up table has to be inferred from a look at the color distributions
in the ppm, and depending on the algorithm used, this is probaly where
it gets messed up. It would be better to go from PICT -> sunrast
directly, since both formats use look up tables.
However, I am unaware of any public domain "one step, all purpose"
converters (neither xv or alchemy are PD).
...
--Darrell
And that give me a chance to plug MY favorite FREE image tools,
SDSC Image Tools, from San Diego Supercomputer Center, available at:
ftp.sdsc.edu via anonymous ftp
in the directory: /pub/sdsc/graphics/imtools
This tool suite works with the following formats:
bmp Microsoft Windows bitmap image file
cur Microsoft Windows cursor image file
eps Adobe Encapsulated PostScript file
gif Compuserve Graphics image file
hdf Hierarchical Data File
ico Microsoft Windows icon image file
icon Sun Icon and Cursor file
iff Sun TAAC Image File Format
mpnt Apple Macintosh MacPaint file
pbm PBM Portable Bit Map file
pcx ZSoft IBM PC Paintbrush file
pgm PBM Portable Gray Map file
pic PIXAR picture file
pict Apple Macintosh QuickDraw/PICT file
pix Alias image file
ppm PBM Portable Pixel Map file
pnm PBM Portable aNy Map file
ps Adobe PostScript file (write only)
ras Sun Rasterfile
rgb SGI RGB image file
rla Wavefront raster image file
rle Utah Run length encoded image file
synu SDSC Synu image file
tga Truevision Targa image file
tiff Tagged image file
viff Khoros Visualization image file
x AVS X image file
xbm X11 bitmap file
xwd X Window System window dump image file
And yes, Darrell, it works with standard input/output.
These are the tools you get (imconv being the most useful):
Tool Description
--------------- ------------------------------------------------
imadjust Adjust image colors, desaturate, brighten, etc.
imcat Concatenate images into multi-image files
imcltroll Cycle a color lookup table
imcomp Digitally composite images
imconv Convert between all supported image file formats
imcopy Copy a portion of an image into a new file
imfile Display image attributes
imfill Fill a region of an image with a color or gradient
imflip Flip an image horizontally or vertically
imformats Describe image file format support
imgray Convert to grayscale
imhist Compute an image histogram
immono Convert to monochrome
impaste Paste an image into another
imroll Cycle an image horizontally or vertically
imrotate Free rotate an image
imscale Scale an image up or down
imshear Shear an image horizontally or vertically
imsplit Split apart multi-image files
imconv is especially easy to use - if your image files have the right
extension, all you have to do is type:
imconv infile.ppm outfile.gif
and the conversion automagically happens, creating the new outfile.gif.
There are lots of options to these tools and so far there isn't much
I've found that they can't do (although read support for postscript
would be nice).
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.]--Darrell
The r.in.ppm I mentioned doesn't allow use of stdin, but that would be
great. I glanced at the code & it looks like it quantizes the colors it
finds in the ppm file to a maximum no. of colors of 32,768, which seems
like a reasonable number to deal with in a GRASS color file. (ppm files
could theoretically contain ~16 million different colors) I don't
know who wrote this - it's from SCS - anybody out there who could
accept credit/responsibility and verify this info?
- Bill B.
***************************************************************************
Bill Brown e-mail: brown@zorro.cecer.army.mil
USACERL - ECS phone: (217) 352-6511 ext 7676
PO Box 9005
Champaign, IL 61826-9005
See our visualization demo at URL:
http://www.cecer.army.mil/grass/viz/VIZ.html
***************************************************************************