exif data handling for users

[Deb Nicholson]

At some point, we will need to address exif data. I think it would
be nice for the user to be able to access and search for their exif
data, but we also want to be able to let the user scrub it before
posting to their network. The best case is where the user has
access to exif data by default and the viewer does not.

Usecase 1: I want to search for all the photos from my trip to
Greece 4 years ago using my exif data.

Usecase 2: I do not want people to access the exif info for my
kid's elementary school or my company's colo.

Usecase 3: I want to see the exif info for last year's awesome
mushroom foraging spot, but absolutely do not want it made public.

Finely tuned control of exif data would represent a tangible
feature that we could offer that is not offered by flickr. I don't
have a strong opinion about how this would look on the back end. On
the front end it should be very clear what's happening and the
default should be to strip it out before posting so no one posts
exif data unless they specifically choose to.

[Aaron Williamson]

I've been slowly poking at this issue. It's easy enough to pull the
EXIF data out of a JPEG
`using PIL <http://stackoverflow.com/questions/765396/exif-manipulation-library-for-python/765403#765403;>`_
the tricky part is how to process and store it the right way. What
you get out of PIL is a list of the EXIF attributes (whichever
attributes that particular camera happens to store) and their
values. The attribute names are in semi-unpresentable CamelCase,
and some of the values require further processing (e.g. for an
"ExposureTime" of 1/160th of a second, you get this list: "(1,
160)").

If the data came out of the image ready to display, then we might
just modify the data structure slightly to add the user's display
preference ('none', 'public', 'friends', or whatever) but otherwise
leave it as is. But it's inefficient to convert (1, 160) to "1/160"
every time an image is displayed, and camel case is
display-unfriendly. To boot, there are scads of EXIF attributes
that might show up in a given image, many of them obscure and some
of them proprietary/nonstandard. Trying to handle them would be a
lot of effort for very little payoff.

Perhaps the better approach is to pick the most common/useful EXIF
values and support those. A good starter list is
`here <http://nicholasarmstrong.com/2010/02/exif-quick-reference/>`_
(ctrl-f for "EXIF Tag Reference" to skip fascinating C#
implementation details). We could then turn that fixed set into a
useful data structure, process the values upon upload, and ignore
any attributes we don't care about. Right now, it seems like the
best place for this data might be in a new model (with a foreign
key in MediaEntry), but I'm open to other ideas. Thoughts?

[Christopher Allan Webber]

Aaron,

That sounds right. Actually, we have the perfect place for this.
EXIF data is media-specific (that is to say, it's image-specific...
it doesn't apply to music).

I've already created a field for media-specific stuff. See
MediaEntry's 'media\_data' dict.

I think we could populate it like so:

::

    # media_data already should be set as a probably-empty dict
    media_entry['media_data']['exif'] = {
        'iso_speed': 100,
        'flash': 0}

etc.

[Caleb Davis]

I'm not sure how this would be indexed under the new regime.
Previously, it would have looked something like

::

    db.MediaEntry.ensureIndex( { media_data : 1 } );
    # not sure if this is realistic, but finding exifs with iso_speed >= 100:
    db.MediaEntry.find( { media_data { exif: { $gte : { iso_speed: 100 } } } } )

`http://www.mongodb.org/display/DOCS/Indexes <http://www.mongodb.org/display/DOCS/Indexes>`_

EDIT: maybe dot notation would also work well for exact matching:

::

    db.MediaEntry.find( { media_data.exif.iso_speed: 100 } )

If that works...gotta love mongodb

[Christopher Allan Webber]

Let's not worry about indexing this for now. I think most things in
here don't **need** to be indexed... I don't think we'll be
searching on them for now. We just want to display the data.

In the future, we may want to take advantage of the geospatial
indexing, but let's condsider that in the glorious future I guess
:)

[Will Kahn-Greene]

The original url for this bug was ​http://bugs.foocorp.net/issues/381 .

[Christopher Allan Webber]

I'm closing this bug... I really don't see any clear and interesting way to move forward on it. We *do* have exif support, and we do display it.

One thing that's different in Deb's original post was the ability to clean out EXIF during processing, or make EXIF only available to certain people. I think that sounds interesting-ish, but probably this could be done as a plugin now that we have such abilities.