AWARE [SYSTEMS]
AWare Systems, , Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
November 1994

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
Archive maintained by AWare Systems



New Datamatrix section



Valid HTML 4.01!



Thread

1994.11.15 00:56 "Libtiff, DOUBLE and FLOAT", by Niles Ritter
1994.11.15 01:50 "Re: Libtiff, DOUBLE and FLOAT", by Sam Leffler

1994.11.15 00:56 "Libtiff, DOUBLE and FLOAT", by Niles Ritter

I've been working with some other people on developing new
TIFF tags (for storing Geographic Projection info) and we have
found need for the TIFF 6.0 DOUBLE format tags (SRATIONAL isnt enough). 
However, on looking through the libtiff code I noticed several
things:

1) The DOUBLE format is not fully supported: In the routine
TIFFFetchData() where bytes are supposed to be swapped on machines with
byte-order opposite that of the file, the FLOAT type is correctly 
swapped, but the DOUBLE is not (I think appending a TIFF_DOUBLE case
after TIFF_RATIONAL will do the trick, since the swap-procedure is the same). 
This has never been noticed because none of Sam's Tags are IEEE.

2) Also, when writing DOUBLE's there is no TIFFWriteDoubleArray() 
routine to handle the tag. This routine should in turn make a 
reference to a TIFFCvtNativeToIEEEDouble(), which brings me to
the next item:

3) The FLOAT tag is no longer handled for VAX (or a "tahoe", whatever
that is). Formerly the module "tif_machdep.c" had an IEEEFLOAT2NATIVE
macro for converting from IEEE to the perverse VAX formats. 
Theoretically, these should have been migrated over to the tif_vms.c 
module, along with the routine TIFFCvtNativeToIEEEFloat() (which gets 
#defined to no-op for IEEE machines, but it looks like they never 
made it. The same holds for DOUBLE.

Has anyone else implemented these tag types, yet? On the VAX?
If not, I'll probably wind up doing it, and will send the diffs
to Sam.

  --Niles.