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
