Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests?
Hi – needed to shorten the e-mail - My reading of the C2PA specification is: (https://spec.c2pa.org/specifications/specifications/2.3/specs/C2PA_Specification.html#_embedding_manifests_into_tiff_based_assets) “As such, the C2PA Manifest Store shall be the only box present in the last IFD (the IFD whose next IFD offset is 0).”: ==> For me, this “last IFD” is the IFD of the last image in a multi-image or multi-page TIFF file. It is NOT an ADDITIONAL IFD. ==> In other words, the IFD of the last image in the file shall add an additional tag entry with ID 52545 (decimal) or 0xCD41 (hexadecimal), with a tag type of 7. The offset shall point to the binary data of the C2PA manifest. ==> For TIFF files with one image, there is only one IFD for that image, which has also the C2PA tag. “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.” ==> For me, this means that the C2PA manifest data (not the tag with the offset to these data) shall be put at the end of the file. ==> Then, a skilled application can update the C2PA data and it’s tag, without touching any other tags or offsets. So, I agree with Even that the provided example file, with that additional 6th. IFD only having the C2PA tag, is a malformed TIFF file, even in sense of the C2PA specification. Hopefully, this helps a little. Su Von: Tiff [mailto:[email protected]] Im Auftrag von Kemp Watson via Tiff Gesendet: Donnerstag, 5. März 2026 13:21 An: Phillip Seaver mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> Betreff: Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests? 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 mailto:[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 ___ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests?
@Larry – thumbs up for your answer !! I fully agree. We should not implement everything in LibTIFF that is defined somewhere, somehow. Especially if the concept does not fit. Furthermore, LibTIFF has not fully implemented other specifications (eg. a lot of DNG tags due to various backward compatibility issues). @Leonard: 1.Would you kindly provide the TIFF tag registration list of Adobe? 2. What is the process for registering new TIFF tags with Adobe? Is there a check to ensure that they comply with the TIFF 6.0 specification? Su Von: Tiff [mailto:[email protected]] Im Auftrag von Larry Gritz via Tiff Gesendet: Donnerstag, 5. März 2026 18:49 An: [email protected] Betreff: Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests? 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] <mailto:[email protected]> wrote: Message: 1 Date: Thu, 5 Mar 2026 07:20:47 -0500 From: Kemp Watson mailto:[email protected]> > To: Phillip Seaver mailto:[email protected]> > Cc: "[email protected] <mailto:[email protected]> " mailto:[email protected]> > Subject: Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests? Message-ID: mailto: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 mailto:[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 Service
Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests?
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 > To: Phillip Seaver > Cc: "[email protected]" > Subject: Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA > Manifests? > Message-ID: > > 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 > 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 >> 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 allsounds 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, >>
Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests?
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 >>> >>> *Date: *Wednesday, March 4, 2026 at 5:00 PM >>> *To: *Leonard Rosenthol >>> *Cc: *Even Rouault >>> , [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 >>> *Date: *Monday, March 2, 2026 at 1:43 PM >>> *To: *Leonard Rosenthol , [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]://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]://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
Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests?
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 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 allsounds 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 > 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://ar
Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests?
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 allsounds 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 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 > > *Date: *Wednesday, March 4, 2026 at 5:00 PM > *To: *Leonard Rosenthol > *Cc: *Even Rouault > , [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 > *Date: *Monday, March 2, 2026 at 1:43 PM > *To: *Leonard Rosenthol , [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.h
Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests?
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 *Date: *Wednesday, March 4, 2026 at 5:00 PM *To: *Leonard Rosenthol *Cc: *Even Rouault , [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 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 *Date: *Monday, March 2, 2026 at 1:43 PM *To: *Leonard Rosenthol , [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 list [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 list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff___ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests?
Example TIFF with Manifest at https://www.dropbox.com/scl/fi/7qnfrxufmc2aslbfjh7nd/leonard.tif?rlkey=4ul5ayzh87kq4davfd7b2vs0c&st=678llpv7&dl=0 From: Tiff on behalf of Leonard Rosenthol via Tiff Date: Wednesday, March 4, 2026 at 3:51 PM To: Even Rouault , [email protected] Subject: Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests? EXTERNAL: Use caution when clicking on links or opening attachments. 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 Date: Monday, March 2, 2026 at 1:43 PM To: Leonard Rosenthol , [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 list [email protected]<mailto:[email protected]> https://lists.osgeo.org/mailman/listinfo/tiff -- http://www.spatialys.com<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
Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests?
An IFD with that tag - see https://archive.color.org/files/technotes/ICC-Technote-ProfileEmbedding.pdf Leonard From: Kemp Watson Date: Wednesday, March 4, 2026 at 5:00 PM To: Leonard Rosenthol Cc: Even Rouault , [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 mailto:[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 mailto:[email protected]>> Date: Monday, March 2, 2026 at 1:43 PM To: Leonard Rosenthol mailto:[email protected]>>, [email protected]<mailto:[email protected]> mailto:[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 list [email protected]<mailto:[email protected]> https://lists.osgeo.org/mailman/listinfo/tiff -- http://www.spatialys.com<http://www.spatialys.com/> My software is free, but my time generally not. ___ Tiff mailing list [email protected]<mailto:[email protected]> https://lists.osgeo.org/mailman/listinfo/tiff ___ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests?
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 > *Date: *Monday, March 2, 2026 at 1:43 PM > *To: *Leonard Rosenthol , [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]://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 list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests?
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 Date: Monday, March 2, 2026 at 1:43 PM To: Leonard Rosenthol , [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 list [email protected]<mailto:[email protected]> https://lists.osgeo.org/mailman/listinfo/tiff -- http://www.spatialys.com<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
Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests?
Leonard, where is the Adobe TIFFtag registry? It's been AWOL for years, good to hear it still exists... W. Kemp Watson, Managing Director Objective Pathology Services Limited Toronto, Canada On Mon, 2 Mar 2026 at 13:51, Leonard Rosenthol via Tiff < [email protected]> wrote: > Yes, the C2PA TIFF tag is registered with Adobe and specific details on > TIFF embedding at > https://spec.c2pa.org/specifications/specifications/2.3/specs/C2PA_Specification.html#_embedding_manifests_into_tiff_based_assets > > TIFF already supports using IFDs for things other than images - consider > ICC profiles, for example. > > Leonard > > *From: *Even Rouault > *Date: *Monday, March 2, 2026 at 1:43 PM > *To: *Leonard Rosenthol , [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]://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 list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests?
Yes, the C2PA TIFF tag is registered with Adobe and specific details on TIFF embedding at https://spec.c2pa.org/specifications/specifications/2.3/specs/C2PA_Specification.html#_embedding_manifests_into_tiff_based_assets TIFF already supports using IFDs for things other than images - consider ICC profiles, for example. Leonard From: Even Rouault Date: Monday, March 2, 2026 at 1:43 PM To: Leonard Rosenthol , [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 list [email protected]<mailto:[email protected]> https://lists.osgeo.org/mailman/listinfo/tiff -- http://www.spatialys.com<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
Re: [Tiff] Libtiff failing on TIFFs with embedded C2PA Manifests?
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 list [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
