[GRASSLIST:2808] Re: r.in.tiff

[Glynn Clements]

ulf at mail.zmt.uni-bremen.de wrote:

> Many thanks for answering my question! I finally made a two-line Perl
> script to remove the header and imported the original data. The
> information about "colour depth" of the grey scale images came from
> Gimp's info dialog ...

It sounds like the image was an RGB colour image, where the only
colours were grey shades. This isn't the same thing as a grey-scale
image. If a colour image contains only grey shades, it is preferable
to convert it to a grey scale image before attempting to import it
into GRASS.

> BTW, I tried the suggested r.in.gdal program to import a (RGB) TIF
> file, which was imported with a strange colour map, while r.in.tiff
> preserved the "original" colour map (complaining, however, about
> "color level quantization" if "nlev" is not set to something very
> high). What does r.in.gdal do with the colour map? And how can I test
> quickly, how much information I loose using less colours than
> (theoretically) present in the image? "r.mapcalc
> x=morecolours-lesscolours" or something like that? 

The best way to import 24-bpp RGB colour images is with "r.in.ppm -b"
or "r.in.tiff -b". That will create three separate R/G/B layers, which
can be viewed with d.rgb (this requires a recent version of GRASS). On
a 24-bpp display, this will result in no loss of data.

Some programs will attempt to create a "composite" map, by quantising
the data into discrete levels then creating a layer with
red_levels * green_levels * blue_levels discrete categories, with a
colour table to match. Unfortunately, creating a colour table for a
24-bit RGB colour cube (with 2^24 == 16777216 categories) takes a long
time, and creates a massive colour table.

So, if you wish to maintain the intensity resolution, it's preferable
to store the data as separate R/G/B layers.

However, if the data consists of grey shades, you only need one
channel. But you have to convert the source data to a single-channel
(i.e. grey scale) image first.

-- 
Glynn Clements <glynn.clements at virgin.net>