|AWARE [SYSTEMS]||Imaging expertise for the Delphi developer|
|TIFF and LibTiff Mailing List Archive|
LibTiff Mailing List
2004.09.17 21:48 "Re: BigTIFF Tag Value Count issue", by Ross A Finlayson
> > Just to clarify, I'm not proposing that negative 64-bit values should > > have any meaning. They should be outlawed by the spec. I'm proposing > > that the spec outlaw values with the most-significant bit set, and > > this only to accommodate languages like Java that have a 64-bit signed > > type but no 64-bit unsigned type. > > There is also the option to use 64-bit unsigned types, but some > implementations may be severely limited by only supporting 63-bits > (gasp!). Hopefully I will still be alive when that last bit becomes a > serious issue. :-) > > I suggest that we stick with the 64-bit unsigned types with the > recognition that many systems/implementations have limited > capabilities. Signed vs unsigned is a minor issue as compared to > system limitations. Hi, I agree with Fernando, et al., that "Baseline" BigTIFF or so only require 63 of 64 bits in offset with file size support to 2^63-1. Any software is obviously free to support 64 bits in the 64 bit offset, but actually as some system file APIs such as UNIX do use signed offsets, those that don't should still offer relatively uncomplicated standard conformance. I guess it is so that TIFF 6.0 has a maximum file size of 2^32-1 utilizing the high bit of the 32 bit offset, but I think as register sizes probably increase to 128, 256, etcetera in the near future that that one extra bit decrease from 1/32, to 1/64, to 1/128, etcetera, of the available precision, with less significance for the offset yet still the flexibility of the I/O function to return an inline non-integer response code, in this case "EOF", also known as -1L or -1LL. TIFF is a vendor standard, if the standard says baseline support is 64 bits, then application vendors can implement it, particularly in generation of the files where an application that demands just barely 4 gigabyte images would probably not require 2^64 bits to represent its data. BigTIFF will be a useful file format for uncompressed video and tomographic imagery, except for lacking a timebase and other information general to the entire file and being less for lossy compressed motion picture imagery that often uses interframe differencing, with the rich image expression gamut of standard TIFF tags that could be used basically unmodifiedly. Extending the width of the field tag and field type elements to 32 bits is probably a good idea. Having an extra field for application data for each tag with the dictum that the private data must not be necessary to decode standard public tags for image conformance would be useful and aid in structure alignment for software uncaring of the private data. Having an extra data item for each strip or tile would be complicated and probably unnecessary. Warm regards, Ross F.