Hi folks,
The requirements repository now includes Technical Note 3, thanks to Chris Cox.
So that’s all of the core TIFF specifications in place that I think exist
(that matter for libtiff). What’s missing now are the additional
specifications (DNG, EXIF, IPTC etc. should it be legally acceptable to host
them here as well).
Today, I’ve been through quite a lot of standards documents:
Adobe Photoshop File Formats Specification.html
BigTIFF.txt
CIPA-DC-008-2010_E.pdf
DNG_Spec_1_7_1_0.pdf
ICC.1-2022-05.pdf
IPTC Photo Metadata User Guide.html
jgtpap1.pdf
rfc2301.txt
rfc3949.txt
TechNote2.txt
TIFF4.txt
TIFF5.txt
TIFF6.pdf
TIFFphotoshop.pdf
TIFFPM6.pdf
TIFFTN3.pdf
XMPSpecificationPart1.pdf
XMPSpecificationPart2.pdf
XMPSpecificationPart3.pdf
I used Claude Fable to extract and cross-reference every single TIFF
requirement from all of the specifications. Then I had it look at the libtiff
implementation and do a gap analysis. It’s all here:
https://gitlab.com/libtiff/libtiff/-/tree/requirements/requirements with the
source material here:
https://gitlab.com/libtiff/libtiff/-/tree/requirements/requirements/sources,
even noting ambiguities in the original material.
https://gitlab.com/libtiff/libtiff/-/merge_requests/925 is the first fix from
that analysis (and the simplest).
This is just the starting point though. As I’ve mentioned in earlier emails, I
would like to improve the quality of the libtiff implementation. This is one
means to that end. We can use this to check that the implementation correctly
matches the requirements, and that the requirements match the file format
specifications. And we can then start to write tests that verify that the
implementation matches the specification, with full end-to-end traceability.
TIFF is a very complex specification when it comes to the details, and one
thing you’ll see in the above requirements set is that it has generated
validation rules to ensure that the tags and tag values in use conform to the
specification. So logically inconsistent combinations will be identified. And
it also has flags to allow relaxation of certain rules to allow handling of
nonconforming TIFF files. This is logic we could add to libtiff to validate
directories when reading and writing, making it harder to unintentionally
generate nonconforming TIFF files. YAML has been used for the requirement
databases, but that’s just a detail—it can be swapped for something else. The
main point is that we can write tools that read the database and then do stuff
with it. It’s a formal description of how libtiff should behave, and if the
implementation is not conforming in any aspect, it’s authoritative since it’s
entirely based upon the published specification documents. I hope this can be
used to prove libtiff is compliant, and if there are subtle deviations it will
also allow them to be identified and corrected.
We can also find libtiff implementation details not backed by requirements, and
write them up. Libtiff-specific compression tags would be one of them, and
also tags for adding the Z dimension for 3D datasets.
This was my first attempt at this, so it’s likely imperfect and needing
improvement. But I thought it would be worth sharing it so you can take a look
and provide some feedback. If anyone has any additional thoughts on other uses
this could be put to and how we could apply it effectively, that would also be
very useful.
Kind regards,
Roger
_______________________________________________
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff
