I've been working on extending the JPEG redaction library to handle editing the metadata, and looking at storing proprietary metadata in the files. <br>I think it might be best to store our proprietary data in an APPn data structure rather than makernote. <br>

Then we can have the option to preserve makernotes, and not confuse other parsers with misleading makernote (I can't actually work out how image software is supposed to know<br>what format the makernote is in- if it's determined by the manufacturer tag, or if everyone just tries to decode makernotes and sees if they match their own format.<br>

If determined by the Manufacturer tag, then we'd have to change that too.)<br><br>APPn data on the other hand seems open for reuse. There are at least two standards using APP2 field. (Flashpix and ICC_PROFILE) and two for APP1 (EXIF and XMP)<br>

<br>XMP stands for extensible metadata, so we could use this standard, but I'm not sure it can coexist with EXIF, and I'm a wary of requiring XML and of fitting into this existing standard.<br><br>On the other hand the EXIF standard <a href="http://www.exif.org/Exif2-2.PDF">http://www.exif.org/Exif2-2.PDF</a> talks about storing multiple APP2 segments, and skipping APPn segments if a reader can't parse them. <br>

Flashpix seems less important to preserve, and I suspect that we can coexist with other APP2 - we just define our own header string. <br>Alternatively we can pick our own 'n'. I think 13 (Adobe photoshop and IPTC) is the only one I've seen in use, and <a href="http://www.ozhiker.com/electronics/pjmt/jpeg_info/app_segments.html">this page</a> only lists a few. I think this would be my inclination.<br>

<br>If the library is to construct this data segment, I would suggest that we store our metadata as a TIFF IFD, as that seems like a compact, flexible standard, for which some code already exists in the library.  It's pretty basic with a flat structure.<br>

APPn segments are supposed to be under 64KB, but you can have multiple segments to exceed that limit.<br><br>If the data segment were to be constructed inside the android app, then alternative (and richer) structures (XML or protobuffer?) might be more feasible or preferable. We have to think about the division of labour between the app and the JpegRedactionLibrary, and any other clients we may want in the future that might read/validate the data. The library has direct access to the raw data for signing/encryption, but the app has the metadata (and presumably the crypto libraries- I haven't looked at what we might use from the C++ code?)<br>

<br>Candidate information to store: <br><br>Consent information: face locations, identities and consent status.<br>Signatures<br>Key identities. <br>Actual public keys? <br>Obscura version information. <br>Redaction information: regions' coordinates and encrypted contents.<br>

Non-standard (e.g. sensor) metadata<br>Audit trail (details of obscura-cam operations)<br>Anything else? <br><br>We need to work out what needs to be/can be signed and what encrypted.<br><br>Andrew<br>