I don't have any strong opinions about the right way to store CP2A data in TIFF files, but as somebody who is both a big cheerleader for what C2PA is trying to do and also a quiet user of libtiff for probably 30 years across many products, I've just gotta say: It's stunning to me that C2PA could publish a spec about how C2PA manifests should go in TIFF files without discussing it with the libtiff community and leadership FIRST to make sure it makes sense, is cleanly implementable in the software that nearly everybody uses for TIFF I/O, and that everybody downstream is ready to hit the ground running as soon as they can. It's also nearly unfathomable that C2PA didn't do the libtiff-side implementation themselves, including documentation and example programs, and tie it with a bow as a MR to libtiff. The ability to do that kind of collaboration to get a standard working and the most widely used implementation completely nailed down and flawless ahead of time is exactly what open source is best for.
> On Mar 5, 2026, at 4:21 AM, [email protected] wrote: > Message: 1 > Date: Thu, 5 Mar 2026 07:20:47 -0500 > From: Kemp Watson <[email protected]> > To: Phillip Seaver <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA > Manifests? > Message-ID: > <CACp925So6gXMH+BE93s_jj2b1Z=D+6=x9b05uj8cejlsc+u...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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 >>>> > -- Larry Gritz [email protected]
_______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
