- 2004.05.27 07:30 "Re: [Tiff] large TIFF - two alternatives", by Andrey Kiselev
- 2004.05.27 09:25 "Re: [Tiff] large TIFF - two alternatives", by Rob van den Tillaart
-
2004.05.27 10:43 "Re: [Tiff] large TIFF - two alternatives", by John Aldridge
- 2004.05.27 12:49 "Re: [Tiff] large TIFF - two alternatives", by Andrey Kiselev
- 2004.05.27 13:05 "Re: [Tiff] large TIFF - two alternatives", by Frank Warmerdam
- 2004.05.27 18:31 "Re: [Tiff] large TIFF - two alternatives", by Chris Cox
- 2004.06.01 11:50 "Re: [Tiff] large TIFF - two alternatives", by John Aldridge
- 2004.05.27 16:37 "Re: [Tiff] large TIFF - two alternatives", by Frank Warmerdam
- 2004.06.04 13:31 "RE: [Tiff] large TIFF - two alternatives", by Ed Grissom
- 2004.06.09 20:33 "[Tiff] Re: large TIFF - two alternatives", by Steve Carlsen
2004.06.03 06:40 "Re: [Tiff] large TIFF - two alternatives", by Rob van den Tillaart
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