LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
May 2004
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2004.06.03 06:40 "Re: large TIFF - two alternatives", by Rob Tillaart
Steve Carlsen wrote:
>
> At 11:27 -0500 6/1/04, Grissom, Ed wrote:
> > As far as Endian issues, lets share the pain, and don't put it all on one
> > platform to have to swap. As the number of multibyte sensors grows, I
> > can
> > see that all of my work in a few years will be 16bit/band image or
> > greater.
> > This will require swapping every pixel value all the time on read and
> > write.
> > Let me write what is convenient for my platform and read whatever is
> > thrown
> > at me.
>
> There may be a compromise position here: let the directory/dictionary
> structure be always Big-endian, but allow pixel data to be either (and
> flagged as such). This may simplify "New TIFF" readers a bit (?), and yet
> gives the desired performance.
Such compromise might introduce confusion as it mixes two mental models;
I agree with Ed's proposal because often (not always) there is only one
platform involved in a typical tiff-enabled workflow. Reading & writing
in both (BE/LE) formats gives a developer the chance to get most
performance out of the tiff format for the platform.
Listening to the discussion on the topic there is a need for a 'ASCII'
format for the dir/dict to make the new format human readable. Drawback
of this is that a dir/dict would use approx 4 times as much bytes and
quite some conversion, in essence it would be a convenience format no
performant format.
Readers and writers would be simplified by reducing the number of
datatypes (no 10 types of integers).
- LONG64 {Z}
- RATIONAL64 LONG64/ LONG64 (16 bytes) {Q}
- DOUBLE {R}
- COMPLEX LONG64, LONG64 (16 bytes) {C}
- ASCII string 0 terminated (padded for 8 byte alignment)
- BLOB bytearray (padded for 8 byte alignment)
Integers smaller than LONG64 [(u)int8,16,32, and boolean] are mapped
upon LONG64. This adds overhead but it simplifies the layout of the "new
tiff"
regards,
rob tillaart
> I think you're the first "vote" for a more general make-over of TIFF. I'm
> happy that there's at least one. :-)
> SteveC