[GRASS5] pbmplus headers for r.in/out.png

Hi,

i checked in the netpbm/pbmplus header files to src/include.
Could someone please check if this is ok with the copyright in the
netpbm distribution, i am not sure. Please remove if not.

r.in.png and r.out.png compile on linux and IRIX, but i could not test
both modules. The code is a bit confusing (mildly put).

NB: r.in.tiff still segfaults on my linux machine (RH 7.0, Intel
processor). Could not test on IRIX.

cu,

Andreas
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de - A.C.Lange@GMX.net

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

On Fri, Jan 26, 2001 at 04:17:19PM +0100, Andreas Lange wrote:

Hi,

i checked in the netpbm/pbmplus header files to src/include.
Could someone please check if this is ok with the copyright in the
netpbm distribution, i am not sure. Please remove if not.

r.in.png and r.out.png compile on linux and IRIX, but i could not test
both modules. The code is a bit confusing (mildly put).

NB: r.in.tiff still segfaults on my linux machine (RH 7.0, Intel
processor). Could not test on IRIX.

Andreas,
   I had started a complete rewrite of r.in.tiff. However, I got stuck
on handling the TIFF world file a little. If the X-shift/Y-shift
parameters are not zero, then an Affine Transformation needs to be
applied. I got stuck at figuring out what the cell resolution of the
resulting CELL file is supposed to be (I only know it should come out
square). I searched and searched, but could not find an example of how
to calculate this crucial bit of information given the coefficients to
the Affine Transformation Formulas:

     x' = Ax + By + C, y' = Dx + Ey + F

     where the 'By' and 'Dx' terms affect rotation and shearing.

I know there's a relatively simple solution somewhere. I just never
found it. Hence, I've put r.in.tiff on the back burner. I know the
solution already exists in the GRASS code base, since i.rectify does
this very task, I just wanted to be able to handle it directly rather
than having to pass off the task to another module...

BTW: r.in.tiff mostly works here. It's really fragile though. It tends
to make the bad assumption of using one byte per band rather than an
unsigned short (which is allowed in the baseline 6.0 spec.). This
doesn't seem to be a problem for palette based rasters, but it
definitely can be a problem for true color.

Ciao,
--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'