#38 Sub IFD Pointers

[Daniel Rupe]

From an email from Ricky: The Tiff EP Spec defines SubIFDs (same as SubIfdPointers in Pmt) as:

This tag encodes the offsets from the beginning of the file to the location of IFDs that are "treeing" from
the current IFD. This tag-value is used to point from the thumbnail IFD to the IFD containing the full
resolution image...

What I understand from this definition is that the Tiff toolkit is going to set the value for this entry
depending on where in the file it writes the sub-IFDs. Therefore, this key should not be written or modified
by a PMT user. Actually, if it is modified, then the IFDs it is supposed to point to will just become
unreachable. Currently, this key doesn't work as a PMT user would expect it to work. If a value is written
to it from PMT and then the file is closed, the value read back when reopening the file isn't the same as
the value that was previously written. This is because the toolkit is trying to set the value to what it's
supposed to be before closing the file. I was wondering if this tag should be excluded from the default
schema.

In fact, there is another Tiff key that is very similar to this one: GPSInfo. This is an optional tag-field that
points to the offset of the GPS IFD. Both GPSInfo and SubIFDs are entries whose values point to the
offset of another IFD. However, GPSInfo is not a key in PMT's default schema and SubIFDs is. This is
inconsistent. Which is correct?

-----------------------

Some other ideas -- There are at least 3 different ways to potentially handle this:

1.) Return a read-only value of the IFD itself (zero if it doesn't exist).
2.) Return a read-only bool (true if exists)
3.) Remove keys from PMT's Schema altogether. NOTE: This is probably not feasible, unless in doing
so, it's okay to assume that a user never needs to know if the sub-IFD exists. If a user does want to
check for IFD existance, they would need to ask for a metadata key within the IFD. However, this is not
a dependable method, since the IFD could exist, but the metadata key within it may not (even though
other metadata keys could).

This entire thing needs to be researched further, to determine a complete problem definition and solution.
For now, this will not be fixed, since no one has mentioned it.