Hi Eric,
just saw this submission:
On Tue, May 07, 2002 at 07:10:41AM +0200, grass@intevation.de wrote:
Date: Tuesday May 7, 2002 @ 5:10
Author: eric
Update of /grassrepository/grass/src/raster/r.tiff
In directory doto:/tmp/cvs-serv28994
Modified Files:
r.in.tiff.c
Log Message:
Remove quantization code as huge stack memory caused program be unusable on
several architechtures (including mine ;). Also, d.rgb does good color
composition now, so I don't see how the degradation in image quality would
be desirable. All RGB TIFF's are now imported as band files.
Small mods to TIFF world code: Now imports as an XY image if there are
non-zero "shear" factors. Would like to handle these via i.rectify eventually,
but in practice they are rarely non-zero...
TODO: Need to look up the group file handling so a group can be made for
RGB color bands... Handle larger integer types (16bit, mostly)...
You may want to look at r.in.gdal, the group file handling is already
implemented there.
In general - do we want to maintain r.in.tiff when r.in.gdal does more
or less the same (eventually group file handling must be added explicitely
for RGB, if needed)? r.in.gdal writes a group file when GCPs are found
within SAR data (CEOS2 driver). This might be "easily" extended to also
generate GCPs from a TFW file.
Just my 0.02 Euro
Markus
Markus Neteler wrote:
In general - do we want to maintain r.in.tiff when r.in.gdal does more
or less the same (eventually group file handling must be added explicitely
for RGB, if needed)?
Unlike GDAL, r.in.tiff doesn't require a working C++ compilation
environment. TIFF is probably too important to impose any unnecessary
dependencies. Using tifftopnm -> r.in.p?m isn't adequate, as r.in.p?m
will ignore the .tfw file, and converting indexed (aka colourmapped,
paletted) images to true-colour destroys the underlying structure.
--
Glynn Clements <glynn.clements@virgin.net>
On Tue, May 07, 2002 at 08:50:18AM +0200, Markus Neteler wrote:
[snip]
You may want to look at r.in.gdal, the group file handling is already
implemented there.
In general - do we want to maintain r.in.tiff when r.in.gdal does more
or less the same (eventually group file handling must be added explicitely
for RGB, if needed)? r.in.gdal writes a group file when GCPs are found
within SAR data (CEOS2 driver). This might be "easily" extended to also
generate GCPs from a TFW file.
I think it's worthwhile to maintain r.in.tiff for the 5.0 series. We
can decide later if we want to keep it in 5.1.
As far as group handling and GCP's, it should be easy enough, I just
haven't looked at how to do it. Calculating GCP's from the TFW is
straight forward (probably I'd do three corners, for a suitable linear
transform). GCP's are only desirable when the rotation/shearing
terms of the affine parameters are non-zero (which is unusual).
--
Eric G. Miller <egm2@jps.net>