biziclop
commented
4 months ago It should be trivial/automatic:
12.3.1.1. Embedding manifests into JPEG
The C2PA Manifest Store shall be embedded as the data contained in an APP11 Marker as defined in JPEG XT, ISO/IEC 18477-3.
Since a single marker segment in JPEG 1 cannot be larger than 64K bytes, it is likely that multiple APP11 segments will be required, and they shall be constructed as per the JPEG 1 standard and ISO 19566-5, D.2. When writing multiple segments, they shall be written in sequential order, and they shall be contiguous (i.e., one segment immediately following the next).
12.3.1.2. Embedding manifests into PNG
The C2PA Manifest Store shall be embedded using an ancillary, private, not safe to copy, chunk type of 'caBX' (as per PNG, 4.7.2). It is recommended that the 'caBX' chuck precede the 'IDAT' chunks. Although PNG supports it, it’s considered bad-form to have a data block after the 'IDAT' and before the 'IEND'. (The exception being animated PNG blocks)
12.3.1.3. Embedding manifests into SVG
SVG is an XML-based format that can exist either stand-alone or embedded into other text-based formats such as HTML. As such, it is necessary to Base64 encode the binary C2PA Manifest Store to perform the embedding. While this section describes how to do that, the use of an external manifest is preferred.
The C2PA Manifest Store shall be embedded as the Base64-encoded value of a c2pa:manifest element in the metadata element of the SVG.
An example might look like this (with the actual C2PA Manifest’s data left out)
<?xml version="1.0" standalone="yes"?> <svg width="4in" height="3in" version="1.1" xmlns = 'http://www.w3.org/2000/svg'> <metadata> <c2pa:manifest>...Base64 data goes here...</c2pa:manifest> </metadata> </svg>
A new and alarming development is occurring that grinds against privacy in the form of the C2PA specification that Photoshop and other tools are beginning to integrate. Please integrate a method to remove this via the metadata removal functionality.
I am hearing that this new functionality adds anywhere from 3% to 50% to the file sizes... This is also not acceptable.
It appears there are ways to remove and mitigate this in a lossless manner. Could you please implement this?