|AWARE [SYSTEMS]||Imaging expertise for the Delphi developer|
|TIFF and LibTiff Mailing List Archive|
LibTiff Mailing List
2004.09.17 13:08 "Re: BigTIFF Tag Value Count issue", by Ross A Finlayson
On Fri, 17 Sep 2004, Joris wrote: > > 0 - U16 - Tag identifying code > 2 - U16 - Datatype of tag data > 4 - 4 bytes padding - Unused > 8 - U64 - Number of values > 16 - U64 - Tag data or offset > 24 > The padding could be private use for hashing and cacheing. That means it would have absolutely no effect on the image data structure, but applications could use it to store data, although perhaps not an offset because it is only four bytes. For example an application could use it to store a CRC or other checksum, constructed however they wish. They could store a bitmask of application private intents, although that is more the realm of a separate private tag to indicate the meaning of an IFD. The necessary memory to plainly hold the tag in its own buffer that contains a copy of the input data could have its size indicated there, although that value is a simple function of the type and count. They could store a key there for encrypted private keys that do not affect the specification or the interpretation of the image where IFD and field level encryption is not addressed by the TIFF specification. Generally, having the padding data to help align the structures to word offsets and having the padding data have no assurances of its content and absolutely no need for any reader or writer to preserve its content makes it application private data for non-interchange use. It would be convenient to store intermediate calculations for the field there, for non-interchange use. Editor applications could politely copy the tag private data or erase it. A specified checksum might be considered. Modern storage systems are truly amazing, yet sooner or later one bit will get flipped. That could be a default where if the high bit of the padding is set then its the checksum, the editor is just responsible to set the high bit if it's a checksum, but that would only leave 3 bytes and 7 bits for application private data. Then, generator applications that do not set the checksum should zero the padding data or use it for private use but not use the high bit. Some of the modern compression systems are fragile with regards to error correction, that leads to the notion of considering checksums on each strip or tile, as well as each field, and perhaps even the IFD with the checksum only over the field definitions and not the data. You might catch a bad block, but four gigabytes of Group 4 is brisk. The checksums could be quite optional. A user could use the private data / checksum padding for other purposes by clearing the high bit, for example a cryptographic thumbprint, which is basically a checksum with private checksum algorithm, or a specified one that uses a public/private key algorithm. That easily gets out of hand, because the user might feel constrained with 3 bytes and 7 bits, well, tell them its better than 2 bytes or none. I think it's a good idea to preserve alignment of the values as possible. Software cares. Warm regards. Hey I have done some fizing on the TIFF Property Sheet Shell Extension Beta, there are still some issues with it not registering correctly on Windows 2000 except for administrator and perhaps because of "MSPaper.Document" which has been set as the default ProgID of the .tif key upon installation of Microsoft Office 2003 with Microsoft's image document viewer, that software sets a "PersistentHandler" for TIFF in the Windows Registry that does not recognize otherwise correctly installed shell extensions, for the instructions for prior versions. So I'm partially around that but not completely. On Windows XP there is a "SystemFileAssociations" key that can be set to get around the "persistent handler." Information about correct operation is appreciated. Another issue it has is that I am not correctly reading double precision floating point values. I use memory mapped files for files larger than a megabyte, I map a view of the entire file at once, it does seem more responsive but may not be for actually very large files. I hope someone will try it on a 1 or 2 gigabyte TIFF file and tell me of their experience. Currently it's set to not open the file if it's larger than 2 gigabytes. On UNIX I also map the entire file at once. Another issue is the drag and drop for copying the selected treeview item and its expanded descendents, it works for Word but not WordPad, I think because it is running in the Explorer process. The Copy context menu item works correctly. Also the context help information with the short and long descriptions is said to be working, with the same information as is on the "TIFF Information" web linked to the following. http://www.tiki-lounge.com/~raf/tiff/tiffprop.html Please try that shell extension if you use Windows and inform me of your results and requirements. Thank you. Ross F.