[Ssc-dev] Storing Obscura metadata in JPEG files

[Andrew Senior]

I've been working on extending the JPEG redaction library to handle editing
the metadata, and looking at storing proprietary metadata in the files.
I think it might be best to store our proprietary data in an APPn data
structure rather than makernote.
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
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.
If determined by the Manufacturer tag, then we'd have to change that too.)

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)

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.

On the other hand the EXIF standard http://www.exif.org/Exif2-2.PDF talks
about storing multiple APP2 segments, and skipping APPn segments if a
reader can't parse them.
Flashpix seems less important to preserve, and I suspect that we can
coexist with other APP2 - we just define our own header string.
Alternatively we can pick our own 'n'. I think 13 (Adobe photoshop and
IPTC) is the only one I've seen in use, and this
page<http://www.ozhiker.com/electronics/pjmt/jpeg_info/app_segments.html>only
lists a few. I think this would be my inclination.

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.
APPn segments are supposed to be under 64KB, but you can have multiple
segments to exceed that limit.

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?)

Candidate information to store:

Consent information: face locations, identities and consent status.
Signatures
Key identities.
Actual public keys?
Obscura version information.
Redaction information: regions' coordinates and encrypted contents.
Non-standard (e.g. sensor) metadata
Audit trail (details of obscura-cam operations)
Anything else?

We need to work out what needs to be/can be signed and what encrypted.

Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/ssc-dev/attachments/20111128/f6bc2a99/attachment.htm>