Feature --fields to be able to show "deep" attributes

[GoogleCodeExporter]

What service (Calendar, Docs, Picasa) should be enhanced?

All, but mainly Picasa.

What is the enhancement?

Be able to explore inside GData metadata. For instance, retriebe EXIF photo 
information 
(http://code.google.com/apis/picasaweb/docs/1.0/reference.html#exif_reference).

An example:

$ google picasa list --title some_album --fields exif/iso,exif/imageUniqueID
200,3c09af771787885dfc4e0cab2ba3858f
200,ef908e88df3a6e60e1a76dd6d62a2499
200,d2aee46f3bd82ca03cbf34dd8139669b
200,484820b57931905fb1a67c346fa48f75

I attached a patch proposal.

Original issue reported on code.google.com by ferranb@gmail.com on 2 Oct 2010 at 12:41

[GoogleCodeExporter]

The forgotten patch :-)

Original comment by ferranb@gmail.com on 4 Oct 2010 at 10:35

Attachments:

• fields_attrbypath.patch

[GoogleCodeExporter]

Hm, interesting idea. My old approach (using the above example) was to just 
implement a field for iso and a field for imageUniqueID. This approach should 
be more flexible.

Can you think of other fields (potentially in other services) that would 
benefit from specifying the "parent attribute"?

Actually, the more I think about it, the better this sounds. Just need a 
mapping of "quick names" to their attribute paths before the attribute path 
lookup (e.g. "iso" -> "exif/iso"), and this can probably be the default way to 
do listing.

Feeling ambitious? :) Check out contacts/base.py and see if you can get the 
functionality of ContactsEntryToStringWrapper with the approach you suggested.

Original comment by thmil...@google.com on 4 Oct 2010 at 7:45

• Changed state: Accepted

[GoogleCodeExporter]

I considered the option to derivate BaseEntryToStringWrapper. I Initially 
discarded it to avoid repeat blocks of similar code like "return 
self.entry.exif.XXX.text". Anyway, I know that I'm somewhat exaggerated about 
reducing lines of code... :-)

The approach can give the possibility to the end user to retrieve data not 
considered on development (new gdata fields, bugs, ...) and avoid forcing to 
wait for a new release. Maybe both options ("iso" and "exif/iso") can live 
together? But... I'm not sure about if the "EXIF" scenario happens in another 
entries of GData feeds..,

Anyway, I agree that "quick names" are more user-friendly. I attached a new 
patch proposal.

Original comment by ferranb@gmail.com on 5 Oct 2010 at 12:01

Attachments:

• exif_fields_for_picasa_r437.patch

[GoogleCodeExporter]

Looking good. I don't have any photos that filled in the "distance" field -- 
can you verify that field works / is populated by something?

Original comment by thmil...@google.com on 5 Oct 2010 at 12:39

[GoogleCodeExporter]

It seems that the "distance" field is not filled by most of the cameras. Not an 
empirical deduction, just based on Google searches... 

To demonstrate that works:

$ #To-install-exiftool-in-ubuntu: sudo apt-get install libimage-exiftool-perl
$ exiftool -exif:subjectdistance=1 distance.jpg
$ google picasa post --title test_album distance.jpg
$ google picasa list --title test_album --fields name,distance
distance.jpg,1.0

Original comment by ferranb@gmail.com on 5 Oct 2010 at 11:28

[GoogleCodeExporter]

Before I commit this, do you happen to know if there's an EV 
(http://en.wikipedia.org/wiki/Exposure_value) field in the exif data?

I wrote a quick calculation for it, assuming it doesn't exist, but I just 
realized that you might know if it's a field.

Original comment by tom.h.mi...@gmail.com on 6 Oct 2010 at 1:01

[GoogleCodeExporter]

Turns out there's no easily found ev value.

Patch submitted as part of r443!

I think the method of listing entry attributes that you initially proposed 
deserves to be looked at, so I'm going to keep this issue open at a low 
priority.

Original comment by thmil...@google.com on 6 Oct 2010 at 4:19

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Nice EV field and commit. Will see if the initial patch can be useful. 

Original comment by ferranb@gmail.com on 7 Oct 2010 at 9:27