Import albums/meta info from Picasa
Submitted by an unknown user
Link to original bug (#716180)
Description
---- Reported by shotwell-maint@gnome.bugs 2010-05-16 10:36:00 -0700 ----
Original Redmine bug id: 1930
Original URL: http://redmine.yorba.org/issues/1930
Searchable id: yorba-bug-1930
Original author: Monty Taylor
Original description:
I'm investigating importing my (extremely large) photo collection which is currently stored in Picasa. (Last thing in the way of me getting rid of my old Windows box) I'd like to get support added for reading Picasa.ini files from folders when importing and using those to create new events rather than just creating date events and grouping the photos by date into those events. This would make the migration potentially much less painful. (I don't want to go re-name a bazillion evens by hand)
I'm happy to help add this feature, but I might need a nudge in the right direction. (I'll keep looking through the code anyway)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:48:00 -0700 ----
History
Comment 1
Updated by Monty Taylor over 3 years ago
I've attached a patch which is not useful… but which is showing where I've gotten so far.
This lays the ground work for pulling a value out of Picasa.ini if it exists and passing that value along until photo_row creation. At that point, prepare_for_import is only creating a blank EventID. I'm guessing that when it goes all the way to actually being written to the db, that's when it gets filled in with a real non-invalid Event… but I haven't found where that happens yet. It may be that I need to hold that name around separate from the photo_row if we're late binding the Event.
I think if I can find that, adding a little code to read the name out of Picasa.ini will be cake.
Comment 2
Updated by Monty Taylor over 3 years ago
Ok. Got it all working. If a folder being imported has a Picasa.ini file with a name= entry, it reads it and applies that name to the Event for the imported files from that folder. Additionally, when generating events, it skips event generation if consecutive files sorted by time have the same imported name, and it forces a new event on different names regardless of time passed. As best I can tell right now, that's about as much information as we can safely infer purely from Picasa.ini:name= fields.
Comment 3
Updated by Monty Taylor over 3 years ago
Grabbed trunk from SVN and applied the patch there. Works!
Comment 4
Updated by Monty Taylor over 3 years ago
Whoops. Ignore against_trunk.2.diff. against_trunk.diff is the happy one.
Comment 5
Updated by Jim Nelson over 3 years ago
- Status changed from Open to Review
- Assignee changed from Anonymous to Monty Taylor
Hi Monty,
I looked over your patch and I can see what you're up to here. I'm responding to you a bit blind, in the sense that I don't know the total sum of data Picasa keeps and how it should map into Shotwell (if it can or should at all). But I did want to throw out some immediate observations about the code.
First, to clarify, it looks like what you're doing is parsing the Picasa.ini file that's stored in each directory beside the photos for the name of the event stored there. Does this then mean that all photos in the same directory belong to the same event? This seems odd to me.
Comments on the code:
- Be sure to look over Yorba's coding guidelines at http://trac.yorba.org/wiki/CodingConventions. Little things like open brackets on separate lines cause delays in getting any patch landed.
- When the event name is detected, it's stored in the LibraryPhoto object and directly accessed by Event. Two issues there. First, unless it's a small utility class/struct (i.e. Dimensions), we prefer to use accessors (get_event/set_event, etc.). Because it's being set in the constuctor and is read-only, you would only need to add a getter.
My other problem is that this bit of data is being used only when the LibraryPhoto is first imported, then recognized by Event to update its name. This is kind of hacky, and is not a very scalable method (by scalable I mean a technique we can use generically as other metadata is imported from Picasa). One ticket you should be aware of is #1151 (closed), which entails creating events as photos are imported. A more contained approach to what you're up to would be to track Picasa event names with each photo, and when the event is created rename it on the spot to the Picasa name. We're hoping to have #1151 (closed) in place for 0.6.
To reiterate, we haven't looked closely at Picasa or its data store to know that your technique is adequate, but I did want to give you a head's-up about what I'm seeing already. If we see additional problems/requirements, we'll post them here.
Comment 6
Updated by Jim Nelson 6 months ago
- Description updated (diff)
- Category set to web-sharing
-
Assignee deleted (
<strike>
_Monty Taylor_</strike>
)
--- Bug imported by chaz@yorba.org 2013-11-25 21:44 UTC ---
This bug was previously known as bug 1930 at http://redmine.yorba.org/show_bug.cgi?id=1930 Imported an attachment (id=261656) Imported an attachment (id=261657) Imported an attachment (id=261658) Imported an attachment (id=261659)
Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution
Resolution: RESOLVED OBSOLETE