• Notice: Undefined index: href in oa_comment_preprocess_comment() (line 113 of /easy/www/tiffa-intranet/profiles/openatrium/modules/apps/oa_comment/oa_comment.theme.inc).
  • Notice: Undefined index: href in oa_comment_preprocess_comment() (line 113 of /easy/www/tiffa-intranet/profiles/openatrium/modules/apps/oa_comment/oa_comment.theme.inc).
  • Notice: Undefined index: href in oa_comment_preprocess_comment() (line 113 of /easy/www/tiffa-intranet/profiles/openatrium/modules/apps/oa_comment/oa_comment.theme.inc).
  • Notice: Undefined index: href in oa_comment_preprocess_comment() (line 113 of /easy/www/tiffa-intranet/profiles/openatrium/modules/apps/oa_comment/oa_comment.theme.inc).
  • Notice: Undefined index: href in oa_comment_preprocess_comment() (line 113 of /easy/www/tiffa-intranet/profiles/openatrium/modules/apps/oa_comment/oa_comment.theme.inc).
  • Notice: Undefined index: href in oa_comment_preprocess_comment() (line 113 of /easy/www/tiffa-intranet/profiles/openatrium/modules/apps/oa_comment/oa_comment.theme.inc).

Evidence of lack of support for features that should be present in TIFF/A

Based on discussions in the kick off meeting, the restrictions that TIFF/A might place on the construction of a TIFF file seem to be almost solely targetted at features or tags that might not be supported well in viewer software. Eg. multiple images per file, or JPEG compression.

The critical word here is *might*. What I think we need is some evidence of which tags are poorly supported. This should be fairly easy to discover by constructing some test files and seeing if they render correctly in a selection of open source and commercial viewers and graphics manipulation applications. In particular verifying what is supported by libTIFF may actually be quite useful in guiding the TIFF/A discussion.

Is this something that the project could undertake?

Paul

Comments

#1

Per TIFF Tech Note 2 the original JPEG compression scheme of TIFF 6.0 is generally considered broken. The compression value of 6 and tags 512 through 521 should be disallowed. There was discussion of whether to allow JPEG compression at all, but if it is, it should be just the new scheme with a compression value of 7.

#2

TIFF/A needs to look into the content of tags as well as the choice of tags. One of the most common ways TIFF files fail against JHOVE is that the DateTime tag (306) fails to follow the YYYY:MM:DD HH:MM:SS format.

This isn't a new restriction on the format, since the TIFF 6.0 spec says what DateTime should consist of, but so much software gives it a pass that it should somehow be emphasized. A lot of other bad tag content will result in broken TIFF, but I don't think it's necessary to do more than incorporate the spec by reference on these cases.

Another question is whether TIFF/A should insist on word alignment as required in the spec (Image File Directory: IFD Entry: Bytes 8-11). This requirement is widely ignored, to the point that JHOVE makes it optional whether to test for it. Personally, I think this is a case where TIFF/A should be more relaxed than the official spec. The reasons for word alignment went away many years ago with computer architectures that bore a significant cost for reading at odd byte boundaries.

#3

These are interesting questions. What's the goal of TIFF/A? It is to guarantee that the image and it's essential metadata can be read in the unspecified future. There are to points to consider: simplicity and tolerance.

From this point of I would for example exclude JPEG compression from the TIFF/A specs. On the other hand, It should tolerate some inconsistncies (e.g. a mal formatted date), but the conformance checker should issue a warning in such cases. But I'm looking forward to a lively discussion about these topics!

#4
I'd argue for treating a malformed date as non-conforming. The date format is part of the spec, and archiving needs good metadata. This gets into the question of what metadata, if any, should be required. The home page says "Having descriptive metadata available (such as content description, iconography, copyright and ownership information etc.) is crucial for every archive." That's stronger than just guaranteeing it can be read. Does it imply certain tags should be required? TIFF 6.0 doesn't have that many descriptive metadata tags, so files intended for archival may rely on XMP (tag 700) instead. Perhaps TI/A should specify that conforming documents need to have either certain TIFF native metadata tags or an XMP tag?
#5

You make a good point. Indeed metadata is very important for memory institutions, but how much is really needed? Sometimes just a good (full text) description of image content is sufficient. In the ideal world, we would have plenty of metdata in best quality. Our reality we see from the work of many archives ist that often only a minmal set of metadata is available. Still such images can represent a valuable asset and must be preserved (digitally). There are two views: a more technical view and a more (metadata-)content centric view.

I believe that the TI/A should first guarantee that from a technical point of view the image can be read in the far future; thus we should warn of problematic (=implying unncessary complexity) tags. The integration of metadata into the header is (highly) recomended, but – I believe – must be a decision each memory institution takes based on what they have (I would give these tags the "recomended" flag). If a tag is used, it certainly should be well formed (I agree on this). Otherwise a it could rise a lot of problems if this tag is used later by some extraction software.

I really like XMP and would suggest that TI/A explicitly allows and ecourages the use of XMP.

#6

In regards to the inital post. Paul writes:

"Based on discussions in the kick off meeting, the restrictions that TIFF/A might place on the construction of a TIFF file seem to be almost solely targetted at features or tags that might not be supported well in viewer software."

This is – at least form my point of view – not the exact intention. In fact, I would like to put these restriction on TIFF/A that will prevent a future software to render the software correctly. Many of todays renderer use legacy code (e.g. libtiff), but how long will this ocde be supported? 10y? 20? With the advance of software technology I see a risk that in some future these legacy programs wil not work any more. It should be easy – in terms of time and money – to write a renderer of TIFF/A in some distant future using the technology that is prevalent at this time. Therefore the TIFF/A should clarify and simplify the current standards, remove amiguities etc.. This gets especially tricky where TIFF includes other formats as opaque objects such as ICC or XMP. While XMP can be considered to some degree open, documented and "simple" (or not so ;-), this is definitively not the case of ICC profiles (in fact we should define a ICC/A :-)

Current renderers are not so my concern, but having to read a TIFF file in 30 yeas (that would be 2046 !!).

Regarding formats such as the date I vode for being strict. Possibly these tags have to be parsed with automated process. To be efficient, the formats have to be well defined and consistent.

Should we require metadata tags? For some archives, allrelevant metadata might be the filename, others entered all descriptive tags? Should we exclude the first and only allow the latter? I think no...