Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx007.isp.belgacom.be (inmx007.isp.belgacom.be [195.238.3.89])
        by mailst034.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id i8HDDsFC018179
        for <joris.at.lebbeke@skynet.be>; Fri, 17 Sep 2004 15:13:54 +0200
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx007.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id i8HDDVfl025223
        for <joris.at.lebbeke@skynet.be>; Fri, 17 Sep 2004 15:13:33 +0200
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from adsl-065-083-169-202.sip.mco.bellsouth.net (localhost [127.0.0.1])
	by xserve.flids.com (Postfix) with ESMTP
	id 8B57A2F59D9; Fri, 17 Sep 2004 09:13:07 -0400 (EDT)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from tiki-lounge.com (tiki-lounge.com [199.181.107.26])
	by xserve.flids.com (Postfix) with ESMTP id E54012F59B2
	for <tiff@remotesensing.org>; Fri, 17 Sep 2004 09:13:04 -0400 (EDT)
Received: from tiki-lounge.com (localhost [127.0.0.1])
	by tiki-lounge.com (8.12.1/8.12.1) with ESMTP id i8HD8UTe009740
	for <tiff@remotesensing.org>; Fri, 17 Sep 2004 06:08:30 -0700 (PDT)
Received: from localhost (raf@localhost)
	by tiki-lounge.com (8.12.1/8.12.1/Submit) with ESMTP id i8HD8Upo009737
	for <tiff@remotesensing.org>; Fri, 17 Sep 2004 06:08:30 -0700 (PDT)
Date: Fri, 17 Sep 2004 06:08:30 -0700 (PDT)
From: "Ross A. Finlayson" <raf@tiki-lounge.com>
X-X-Sender: raf@tiki-lounge.com
To: tiff@remotesensing.org
Subject: Re: [Tiff] BigTIFF Tag Value Count issue
In-Reply-To: <006701c49cab$8ce64b60$4c24c850@dfgrrxsknr4e>
Message-ID: <Pine.GSO.4.43.0409170532550.8930-100000@tiki-lounge.com>
X-Ross: Ross
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: TIFF and libtiff discussion  <tiff.remotesensing.org>
List-Unsubscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://xserve.flids.com/pipermail/tiff>
List-Post: <mailto:tiff@remotesensing.org>
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Subscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
Sender: tiff-bounces@remotesensing.org
Errors-To: tiff-bounces@remotesensing.org
X-UIDL: 2e3572254f5c001a871b87df5234089d



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.

_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
