To add a bit: the spec uses the word "box", which is more of a JPEG or PNG term. Is a "box" in TIFF context an IFD, or the data of a tag? I think that may be the source of confusion.
W. Kemp Watson, Managing Director Objective Pathology Services Limited Toronto, Canada On Thu, 5 Mar 2026 at 07:18, Kemp Watson <[email protected]> wrote: > I just took a look at the CP2A spec, the JUMBF spec, and the actual bug > report submitted by Leonard. It appears that the TIFF file is malformed as > the JUMBF data is contained within a *new* IFD pointed to in the IFD > chain; this is incorrect according to the specifications, so the file is > malformed, and libtiff is quite reasonably attempting to parse the JUMBF > metadata container as an IFD, and failing. > > As far as I can tell, it's the c2patool signing the file incorrectly by > creating an extra IFD rather than simply inserting the JUMBF packet into > the "real" last IFD, which is valid image data. > > The submitter says "The C2PA spec (§A.2.5) says the C2PA manifest must go > in a dedicated last IFD in the TIFF file." It does not appear to say that. > My read is that it goes into the already existing last IFD. Here's the spec > text: > > *Although TIFF supports the concept of multiple pages or layers (via >> multiple IFD’s), there shall only be one C2PA Manifest Store for the entire >> asset - not one per IFD. As such, the C2PA Manifest Store shall be the only >> box present in the last IFD (the IFD whose next IFD offset is 0). To >> support update manifests, the C2PA Manifest Store should be located at the >> end of the file; this ensures that changes to the size of the C2PA Manifest >> Store do not impact any of the other tag offsets.* > > > So, the cp2atool appwars to be incorrecty creating a new IFD, inserting it > into the chain, and adding the JUMBF packet to that new (and otherwise > empty) IFD, rather that inserting it into the last extant IFD, is how I > read this. The spec's wording could be improved a bit, for example "C2PA > Manifest Store shall be the only box present in the last IFD" is rather > demanding as other JUMBF boxes, unrelated to C2PA, could also theoretically > be present, > > I can't say I like the idea of a tag in the first IFD pointing to data in > the last IFD, but that's how I'm interpreting the specification. Leonard, > have I got this right? This is just from reading, not experience. > > W. Kemp Watson, Managing Director > Objective Pathology Services Limited > Toronto, Canada > > > On Thu, 5 Mar 2026 at 06:45, Kemp Watson <[email protected]> > wrote: > >> When I read "The C2PA spec requires an IFD with a single entry >> containing their tag (52545) pointing to the data at the end of the file", >> I don't read anything about IFDs at all....sounds more to me like raw >> data appended to the end of the file after the last IFD. >> I also don't see anything there about not using the first IFD for the >> entry; although there's nothing there that mandates the entry location, >> either. >> >> The above is without reading the CP2A spec mind you, only my read from >> that sentence. Not that keen on "loose" data in the file, >> but likely that sentence does not tell the while story, >> >> W. Kemp Watson, Managing Director >> Objective Pathology Services Limited >> Toronto, Canada >> >> >> On Thu, 5 Mar 2026 at 00:02, Phillip Seaver via Tiff < >> [email protected]> wrote: >> >>> I don't think either spec says that the data is stored as an IFD. I >>> think they both say as an entry in an IFD. >>> >>> With regard to IFD's as non-images, the TIFF 6 spec says, "There may be >>> more than one IFD in a TIFF file. Each IFD defines a *subfile*," and >>> later, "TIFF readers must be prepared for multiple images (subfiles) per >>> TIFF file, although they are not required to do anything with images after >>> the first one." >>> >>> The ICC profile technote says, "as a single TIFF field or Image File >>> Directory (IFD) entry in the IFD". I read the "or Image File Directory >>> (IFD) entry in the IFD" as an alternate wording for "single TIFF field" >>> since it says "entry in the IFD". It then goes on to describe an IFD entry >>> for the profile. >>> >>> The TIFF 6 spec says, "A TIFF field is a logical entity consisting of >>> TIFF tag and its value. This logical concept is implemented as an IFD >>> Entry, plus the actual value if it doesn’t fit into the value/offset part, >>> the last 4 bytes of the IFD Entry. The terms TIFF field and IFD entry are >>> interchangeable in most contexts." >>> >>> The C2PA spec requires an IFD with a single entry containing their tag >>> (52545) pointing to the data at the end of the file. I think that means >>> it's not a valid TIFF file, since that IFD has no image data or tags. >>> >>> It seems like it wouldn't be hard to special-case, but I'm not sure why >>> they didn't use an entry in the first IFD, as Even mentioned. >>> >>> Phillip >>> On 3/4/2026 5:05 PM, Leonard Rosenthol via Tiff wrote: >>> >>> An IFD with that tag - see >>> https://archive.color.org/files/technotes/ICC-Technote-ProfileEmbedding.pdf >>> >>> Leonard >>> >>> *From: *Kemp Watson <[email protected]> >>> <[email protected]> >>> *Date: *Wednesday, March 4, 2026 at 5:00 PM >>> *To: *Leonard Rosenthol <[email protected]> <[email protected]> >>> *Cc: *Even Rouault <[email protected]> >>> <[email protected]>, [email protected] >>> <[email protected]> <[email protected]> >>> *Subject: *Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA >>> Manifests? >>> >>> *EXTERNAL: Use caution when clicking on links or opening attachments.* >>> >>> >>> Isn't an ICC profile supposed to go in a TIFF tag, not an IFD? Tag 34675. >>> >>> W. Kemp Watson, Managing Director >>> Objective Pathology Services Limited >>> Toronto, Canada >>> >>> >>> On Wed, 4 Mar 2026 at 15:51, Leonard Rosenthol via Tiff < >>> [email protected]> wrote: >>> >>> Looping back on this. >>> >>> Is there consensus that libTIFF’s implementation - assuming that all >>> IFD’s point to images - is incorrect as per the TIFF specification and well >>> known existing usage (e.g., ICC profiles, C2PA Manifests etc.)? >>> >>> If so, can we get a fix out ASAP? >>> >>> If not, what is the argument for why the current implementation is >>> correct? >>> >>> Thanks, >>> Leonard >>> >>> *From: *Even Rouault <[email protected]> >>> *Date: *Monday, March 2, 2026 at 1:43 PM >>> *To: *Leonard Rosenthol <[email protected]>, [email protected] < >>> [email protected]> >>> *Subject: *Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA >>> Manifests? >>> >>> *EXTERNAL: Use caution when clicking on links or opening attachments.* >>> >>> >>> Seems to me like a weird design to hijack a IFD (*Image* File Directory) >>> to put something different in it. Why not having used a TIFF tag in the >>> first IFD for example ? But I assume my question is mostly moot now if that >>> C2PA spec has progressed beyond being a draft? >>> >>> I guess if someone wanted those files to be read by libtiff, the best >>> course of action would be to silently ignore that final IFD, or just emit a >>> warning instead of an error ( I assume there must be a spefic TIFF tag to >>> recognize it?) >>> >>> Even >>> Le 02/03/2026 à 19:30, Leonard Rosenthol via Tiff a écrit : >>> >>> A person reported (https://github.com/contentauth/c2pa-rs/issues/1894) >>> that libtiff-based apps are failing to process TIFF files with embedded >>> C2PA Manifests ( >>> https://c2pa.org/specifications/specifications/2.3/specs/C2PA_Specification.html). >>> I’ve commented there that I don’t agree with their position on the >>> topic, nor can I verify their results. >>> >>> Would love for any/all of you to comment on the situation - either here >>> or there. >>> >>> Thanks, >>> Leonard >>> >>> >>> _______________________________________________ >>> Tiff mailing >>> [email protected]https://lists.osgeo.org/mailman/listinfo/tiff >>> >>> -- http://www.spatialys.com >>> My software is free, but my time generally not. >>> >>> _______________________________________________ >>> Tiff mailing list >>> [email protected] >>> https://lists.osgeo.org/mailman/listinfo/tiff >>> >>> >>> _______________________________________________ >>> Tiff mailing >>> [email protected]https://lists.osgeo.org/mailman/listinfo/tiff >>> >>> _______________________________________________ >>> Tiff mailing list >>> [email protected] >>> https://lists.osgeo.org/mailman/listinfo/tiff >>> >>
_______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
