Showing posts sorted by date for query picasa iphoto. Sort by relevance Show all posts
Showing posts sorted by date for query picasa iphoto. Sort by relevance Show all posts

Sunday, February 17, 2013

Flickr has a Snapfish problem

I've been hearing reassuring sounds on app.net about Flickr's resurrection. Since I've been unhappy with Picasa Web's disinterest in Aperture/iPhoto the app.net support meant I gave Flickr a try. Not least because Aperture has built in Flickr sharing features.

I signed up for the 3 month pro service. It auto-renews, but if you "cancel" you effectively turn off the auto-renewal and continue the term of your subscription.

I liked the Aperture integration, but Flickr felt old and clumsy. Worse, the sharing settings are difficult to revise for Sets, and there's no true equivalent of Google's share-by-unguessably-large-unique-URL.

I could live with that, more or less, but Snapfish did me in. 

Twice I sent "Sets" to print via Snapfish, and twice a few photos were "unavailable" (all seemed well in Flickr). Worse, when I tried to delete my new Snapfish account, I learned terminating a Snapfish Account isn't easy. That's a flagrant violation of clause 1 of Gordon's Laws for services.

Since I couldn't delete, I set a very long password, removed all my photos, and tried to change my email to my spam account. Alas, now I was forced to enter a (fake) postal address. 

Sorry Flickr, that's too many problems; I'll suffer with Picasa a bit longer. Call me back when you have a different print partner.

Thursday, November 22, 2012

Using iPhoto and Aperture together - and merging iPhoto Libraries

My first post on merging iPhoto Libraries was published on January 17th, 2004.

Gordon's Tech: Apple - Discussions - iPhoto 4: Consolidate multiple libraries

... Using iPhoto Library Manager or similar software, open Secondary Library. Adjust albums so all images appears in EXACTLY one album. (Apple has an AppleScript to find images not in any library, see AppleScript site for iPhoto.)
1b. OPTIONAL. In Secondary Library edit roll names to descriptive names.
2. Burn Secondary Library to iPhoto Disc from iPhoto.
3. Switch iPhoto to Main Library. Insert iPhoto Disc.
4. Expand view of iPhoto Disc. Select ALL albums. Drag and drop on Main Library icon.

Almost 9 years later Apple has posted an officially supported approach to merging iPhoto Libraries - using Aperture.

Nine years ... nine years ...

I could cry.

I did this the hard (hard, hard) way about 6 months ago. I am sure it works a hell of a lot better now. Album Descriptions are still a problem. Both iPhoto Albums and Events can have Descriptions, but only Aperture Events/Projects can have Descriptions. In my testing with iPhoto and Aperture's new unified Photo Library I can edit or create Album Descriptions, but they aren't shown in Aperture.

Maybe this will be fixed in an Aperture update -- but I'm not holding my breath. Apple's description of how they reconciled Aperture and iPhoto doesn't mention this gap (you can submit a request on Apple's Aperture Feedback form). It does list several other issues, these are the ones that seemed significant to me:

  • Smart albums from each application are visible and fully functional in the other. However, the album settings must be edited with the application in which you created the album. 
  • Photos hidden using iPhoto's Hide command cannot be accessed in Aperture.
  • PDF files in Aperture libraries are not visible or accessible in iPhoto. (I remember when iPhoto supported PDFs btw)
  • If you activate Photo Stream for a library in iPhoto and then open it in Aperture, that library is still linked to Photo Stream. Only one library can be linked to Photo Stream at a time, so if you subsequently open another library and activate Photo Stream, the previous library is no longer linked. (I try to avoid Photo Stream for now - feels like it needs several more iterations)

In keeping with Apple's deplorable documentation policies they omit mention of real issues. Besides the Album Description gap, I would be very careful about using Keywords. Aperture's Keywords use a fairly complex hierarchy model, iPhoto keywords are a flat list; true interoperability is mathematically impossible. On inspection iPhoto only shows the very top of the Aperture Keyword tree; unless you want to go to a flat keyword model don't touch Keywords in iPhoto. Interestingly Smart Albums defined against Aperture Keywords still work in iPhoto even though the Keywords can't be displayed in iPhoto.

Lastly, since the two apps support different numbers of 'Stars' the ratings mapping must be lossy.

I've started cautious use of both iPhoto and Aperture together. I liked iPhoto 9's Event Management tools, and even though they've been dumbed down in iPhoto 11 they're still better than Aperture's. I'd hoped to use iPhoto to export albums to Picasa, but Google stopped support on the Mac Picasa Web Albums exporter and iPhoto PlugIn. It still shows in my iPhoto since it was previously installed, and supposedly it still works if you can find it. (Proof that I am the proverbial dinosaur  -- few seem to care that this app was discontinued.)

I'll update this post with what I learn over time.

Tuesday, September 04, 2012

Don't bother with the open source Aperture to Picasa export plugin

I decided to try the open source Aperture to Picasa export plugin.

It worked for about 100 images, then died. I couldn't get it to upload additional images; I got a range of cryptic error messages.

There are 24 open defects, it was lasts uploaded Nov 2010, 3 years ago.

Don't bother with it.

Ubermind used to make a plug-in, but it's gone (I wouldn't trust the versions I can find around the net).

Once I get time to upgrade to Mountain Lion I'll presumably be able to share the library with iPhoto, I think Google still maintains an uploader for iPhoto.

Update: Google has discontinued support for the Mac uploader. I'm so glad I pay for Google storage for my photos.

Thursday, June 14, 2012

Aperture 3.3 is iPhoto Pro. At last. Sort of.

After years of false claims of iPhoto to Aperture migration support, and four months after I realized iPhoto was going down the wrong road for me, and three months after I began my extremely painful iPhoto to Aperture migration, Apple has released iPhoto Pro (aka Aperture 3.3).

Imagine my joy.

The only saving grace is that I might have saved a few people by advising them to wait for Aperture 4, which has now come in the form of iPhoto Pro 1.0/Aperture 3.3.

According to Apple's marketing claims, the latest (Lion-only) versions of Aperture and iPhoto  share a single database model. So, in theory, both apps can work on the database.

I doubt it works as advertised, but it has to be an improvement on my experience! I'd strongly advise waiting until September before doing a major iPhoto to Aperture migration. Now that you know the end is in sight the wait should be tolerable.

Personally, I'm looking forward to, at the least, using iPhoto's Picasa uploader and iPhoto's superior UI for Event/Project and many common image management operations.

Assuming the inevitable bugs get sorted out, this is an extraordinary conclusion to what must have been a formidable software effort. At one point Apple had two completely incompatible photo management products. One was a natural Mac app with an elegant UI and some infuriating limitations. The other looked like a port from NeXTStep [1]. They had almost nothing in common.

Slowly, painfully, Apple turned these two disparate products into iPhoto and iPhoto Pro. To do that they had to reconcile very different functional models and data models. It would have been a very hard, very long, glamor-free slog. I hope the team was at least paid well.

Now, if you'll excuse me, I'm going to go cry in my Scotch.

[1] I was never able to learn where the heck Aperture came from. It's neither Windows nor Mac.

Update: I remembered my underused MacBook Air runs Lion, so I tested the new Aperture and iPhoto together. Unsurprisingly, they failed my first test.

First -- the good news. Annotations on an iPhoto Event are now visible in Aperture.

The bad news -- Album annotations (descriptions) are still not viewable or editable in Aperture.

Maybe in another year or two?

Tuesday, March 20, 2012

Aperture to Picasa uploader: doesn't exist any more

Apple's Aperture site still markets an Aperture to Picasa Web Albums uploader, but the vendor has closed up shop. Just in time for my move from iPhoto to Aperture!

There's no alternative, which is a bit of an ominous sign for both Picasa Web Albums and Aperture.

Update: There's an open source alternative. Last updated 2010, and quite a few active defects logged.

Update b: Looking at this more closely, Aperture has some interesting web journal features -- that work with MobileMe. Which was shut down last year. This keeps looking worse. (Maybe it's because I'm on Snow Leopard.  I think Lion Users may see iCloud.) Incidentally, this is quite a good article on all the nasty bits of Aperture photo sharing.

Saturday, March 17, 2012

iPhoto 8 to Aperture 3.23: Migration notes

I'm migrating my image and video libraries from iPhoto to Aperture. This is a long and tedious process since the fully automated importer doesn't completely work, there's no Aperture help file documentation and few web discussions or knowledge base articles. Unfortunately iPhoto to Lightroom migration is even harder.

If you have older iPhoto Libraries like mine, you need to understand how Aperture Stacks work. That's because in old iPhoto any edited images are treated by Aperture as 'externally edited' versions of an iPhoto original and they "stack".

I hope this process will improve with Aperture 4. It is one of the most miserable computer tasks I have undertaken since the days of hacking WordPerfect printer drivers with a hex editor.

Why now

  • iPhoto 9.x (11) is a functional regression from iPhoto 8. I believe Apple has ceded the pro market to Adobe, and now markets Aperture to prosumers (that's me). That means iPhoto will continue to go downmarket even as it converges with iCloud and iPhoto for iOS. I don't want to go there.
  • Aperture 3 is a better photo management tool with only one gaping omission -- there's no place to store album descriptions (only events have descriptions).
  • I can work on Projects while traveling and integrate them.
  • I'm tired of working around two different sets of bugs. [1]
  • I need to be aligned with "power users" -- iPhoto users don't have much energy any more

What is lost

  • If you are not very careful, you will lose all of your iPhoto Titles.
  • Aperture is less stable than iPhoto. Aperture users learn to kill it and repair its database.
  • iPhoto 8.x has elegant shortcuts for creating and managing Events that Aperture lacks (splitting, etc.). iPhoto Events display is also much better than Aperture Projects in many ways. In iPhoto it's easy to go from an image to the container Event, in Aperture I can't see how to do that (the columnar browse view does tell you the Event container name and there's probably an AppleScript workaround. It's a funny miss.)
  • iPhoto 8 keyword entry is more efficient and better developed than in Aperture (though Aperture has other keyword features). I used the Command Editor to assign five keywords to numbers, I didn't like the default keyword modifier. (If you have a numeric keypad you don't need to worry about this.)
  • You can quickly edit photo captions in place in iPhoto. In Aperture you need to use the metadata inspector. It's slower.
  • In iPhoto when you select multiple photos you see a summary of the selection with a date range. In Aperture you only see metadata on the first photo selected.
  • iPhoto 8 has smarter batch change options
  • Aperture Libraries are about 25% larger than iPhoto Libraries for the same number of images. This might be partly related to how Aperture creates thumbnails for 'stacked' iPhoto images belonging to multiple Albums.
  • Quick navigation from iPhoto to image file.
  • I'd been processing raw images in Aperture but exporting JPEGs to iPhoto. I liked this as an archival strategy, RAW images won't be readable in ten years. I was, however, falling behind in processing images. Working only in Aperture will be faster even though the RAW images are significantly larger than the JPEGs. I've started shooting JPEG for less important jobs to reduce the storage consumed.
  • "Keepsakes" like Books - though I recently discovered that iPhoto 8 can't render the books I created with earlier versions - the layouts are gone. Whatever new layout one chooses there is some likelihood of losing content. Aperture did import a 'book' as though it were an album.
  • My iPhoto Slideshows (though I only ever did 1-2 of these) - UPDATE: I did get at least one when importing via iPhoto Library
  • It appears Aperture cannot import even modern iPhoto contrast settings (may differ in iPhoto 9?)
  • Aperture's video format support is weaker than iPhotos and it has video thumbnail creation bugs.

What I tried (and discarded)

I thought I could use IPLM to create a "clean" import Library while also allowing me to avoid the 'duplicate' image problem with older Libraries that have JPEGs for both current and revised images. I found, however, that Aperture does a better job importing an iPhoto Library than IPLM does migrating or merging libraries. In particular IPLM cannot recreate Smart Albums, but Aperture can. Also my IPLM migrated Library image ratings didn't import into Aperture, but the native iPhoto Library images do keep ratings.

What I'm doing now

I'm converting each iPhoto Library into a separate Aperture Library. This makes comparisons easier. Then, when i'm satisfied not much is lost, and I've moved over any missing Descriptions, I can start to combine the Aperture Libraries into one. Given the size of these Libraries and the backups needed it's wise to budget for some big disks and something like OWC's Newer Technology Disk Dock.

  • Prior to migrating an iPhoto Library I first reorganize it to be closer to the Aperture Model
    • Consolidate Events into Larger sets. For > 100 events/month I set up an event for each month and use that for most photos. Special 'events' stand alone.
    • Set a Key Photo for each Event and move Event Descriptions into the Key Photo Description. (I'm not certain, however, that Aperture preserves Event Key Photo when it turns Events into Projects.
    • Eliminate Albums that can be represented as Events, and move Album Description to Event Description. If an album is retained, set a Key Photo and move Album Description to Key Photo Description. If necessary create an Album Specific Key photo (you can assign these to a special "Album Event". For example
      • Take a screenshot of the description, save as PNG. Then copy the Description textDrop PNG into Event/Album and set date time so it's earliest by a minute.
      • Paste Description text from Event/Album into Image Description field.
  • Backup the iPhoto Library
  • repair iPhoto Library if using iPhoto 9.x or later. I run recover orphaned photos (backup first) in iPhoto and I compress the database.
  • Create a new Aperture Library for the import with these settings
    • Turn off Facebook synchronization
    • Turn off sharing photos with iLife (no preview generation)
    • Disable Faces
    • Disable Places
  • Choose Import iPhoto Library
    • You must set Version Name to Master File name. If you do this then your iPhoto Titles will become Aperture Version names and iPhoto Descriptions will become Aperture Captions. (The Aperture Title field is not used.) If you do not do this your iPhoto Titles will be lost. (It's ok throw your head back and scream now. I think this is a bug [2].)
  • From empty Aperture Library import iPhoto Library. Let it run. On my 27" iMac a large Library took about 8 hours to import (but I'd forgotten to turn off preview and Faces, that about doubled the time). Be sure this completes before doing anything else. Activity view should be empty.
  • Validate the the import succeeded
    • Filter on iPhoto Original, number should match number of items in Original iPhoto
    • Spot check for errors - confirm image counts match (keyword 'iPhoto Original', confirm event counts match.
    • Make sure Moview counts agree. Run a sample of Movies.
    • I spend a week or two on validation before I go to the next step.
  • When the import Library has been validated it's time to import it into the Master Aperture Library. I back up my Aperture Library prior to this step.
  • Prior to import process run repair Aperture Database on the Master Library to remove Aperture errors.
  • Import the Aperture Library you just created into the Master Aperture Library.
  • To show iPhoto metadata appropriately, change all metadata settings (at least six places!) to display Version Name, Caption, Keyword and Ratings in that order.
  • Keep old iPhoto Library onto an old hard drive for safe keeping for a year or two before deletion.

Working around Aperture's video import bugs

Importing videos from iPhoto was grueling. I've addressed this in a separate post. This goes beyond mere bugginess into realms of "never tested". I was able to move all my videos, including version names, captions, descriptions and so on -- but it took a lot of work. I had to combine iPhoto Library import with a separate import process using the iPhoto media browser, then use a range of Aperture views, queries, metadata inspection and so on to get a complete set with no extras.

Managing the botched video import made me an Aperture expert.

Keyword cleanup

It seems that Aperture is turning Project/Event names into keywords - at least under some conditions. No photos are assigned those keywords. They make quite a mess of the Keyword view. I'm deferring major keyword cleanup until I complete iPhoto Library import. I consider this one to be a bug.

Be very careful about rearranging the keyword hierarchy. Aperture assigned the keyword 'iPhoto Original' to over 18k images. When I moved that within the hierarchy the rearrangement pegged all my CPUs and seems likely to run overnight (or crash).

Reviewing Mistakes

Once you think you've managed your migration it's time to look for problems. You need two monitors, one for iPhoto, one for Aperture. Initially my photo counts matched but I had one extra Project/Event in Aperture.  On inspection a Facebook thumbnail had leaked into Aperture, perhaps related to Aperture's quirky Facebook support -- and it created an extra Project. I deleted that, but now my image counts were off (I'd collapsed the stacks, otherwise there are many more images in Aperture than iPhoto). I lined up my images so I could compare end-of-row images, then did a simple split-set search until I discovered a bizarre little iPhoto image that OS X couldn't recognize -- but it somehow rendered as a thumbnail. Aperture had been unable to import it (an error message would have been "nice").

Next is using Aperture's list view to look for abnormally small images (accidental thumbnail import), inspect by camera type, etc. There's no way to inspect tens of thousands of images for errors, so if my counts are correct I proceed with sampling by image type, camera type, etc. See above for the nighmarish task of resolving video import bugs.

Understanding Stacks and Splitting

If you've been using iPhoto for years then some of your imports will include two images -- original and 'externally edited'. (Externally edited is how Aperture classifies images edited in old versions of iPhoto).

During import these pairs are "stacked" and the "externally edited" is marked as the "key photo" in the stack.. Some things you need to know:

  • These images are stacked by Aperture, not auto-stacked. If you split the stack Aperture can't automatically unite it again. In my experiments a 2-5 sec auto-stack rule did stack most such images after I split them, but not all. So don't unstack recklessly!
  • Option - ; and Option-' will collapse and expand all stacks.
  • You may want to delete one member of the stack, perhaps the edited one, and redo the edit in Aperture. Unfortunately, the 'externally edited' one may belong to an Album. There's no way in Aperture to determine what Albums an Image belongs to.(I found an AppleScript that claimed to produce a list, but it didn't seem to work when I tried it.) In my testing it appears that if one member of a Stack is in an album then both are, even if the stack is later split. So it seems to be safe to delete either the original or edited version as desired.

The best guide to using Stacks is to browse the keyboard shortcut pamphlet or PDF.

Combining Aperture Libraries

  • I chose to convert each of my iPhoto Libraries into a single Aperture Library, then I combined those into a single Aperture Library. I discovered that merging Aperture Libraries is a risky business - in particular merging two smaller Libraries crashed Aperture. Expect frequent crashes.
  • I recommend backup the target Library prior to the Combination step (in addition to the usual backups).
  • Be sure no iPhones or other mountable devices are connected
  • Reboot your machine prior to attempting a merge
  • Consider repair Database prior to merge.
  • You can choose either "add" or "merge", the default is merge. I think the Import Aperture Library with Merge resolves duplicate photos (which is only safe if the developers are competent). More importantly, I think it tries to combine keywords rather than create separate keyword taxonomies (trees). That's a big plus.

See also

- fn -

[1] It's easy to find Aperture bugs btw, though usually restarting the app clears them. I thought I'd found a very nasty bug with iPhoto events, but it turns out it's simply very easy to accidentally select and merge multiple events when only one is wanted.

[2] Aperture handling of iPhoto Title data depends, mysteriously, on the iPhoto Version Name import setting that Apple documents as: "... choose Master Filename from the Version Name pop-up menu to have your files stored using the current master filenames from your camera or card". (Since we're importing from iPhoto, and not a camera or card, this documentation is misleading.)

In reality, during iPhoto import, setting Version Name = Master Filename does nothing of the sort. Instead, this is what happens:

  • The filename is equal to the filename used in iPhoto
  • Aperture.Version name is set equal to the iPhoto Title.

I don't know what Aperture would do if we set Version Name = a Custom name where one of the custom name components was "Master Filename". Would it still treat iPhoto.Title as "Master Filename"?

I think there are two bugs here. I think Aperture "Version Name=Master Filename" was supposed to set Aperture.Version to the file name, and that there was supposed to be ANOTHER drop down (and a custom name tag) that of the form "Version Name=iPhoto Title".

I've submitted this bug to Apple's developer bug reporting system as 11163418.

Thursday, January 12, 2012

iPhoto 9.2.1 to Aperture 3.2.1 - it doesn't actually work

Apple promotes Aperture's seamless import of iPhoto content.

I've been skeptical, but I gave it a try on a plane flight. I added 21 images to a brand new iPhoto 9.2.1 Library and I created albums and events. I then gave descriptions to images and to both albums and events. Then I imported the images into Aperture.
The iPhoto.Events became Aperture.Projects. The iPhoto.Albums became Aperture.Albums. iPhoto.Folders became Aperture.Folders.
Eventually. At first the iPhoto.Albums were missing. They showed up minutes later on reopening Aperture. This took so long it feels like a bug.

Image metadata seems to have been preserved - titles, captions, etc. I've written about this previously for iPhoto, Aperture and Picasa Web Albums.

That's the end of the good news. All of the descriptions I added to Albums/Events were lost. Aperture Projects/Albums can't have annotations. So that description you wrote in iPhoto about the family reunion? It's toast.

Aperture's iPhoto import is feeble - and Apple's marketing of Aperture's iPhoto import is deceptive.

Apple does stuff like this though. I'm not surprised they did a crappy job on iPhoto import.

What's truly weird however, is that nobody besides me seems to care. That means Apple isn't going to fix this.

There are times when I know I live in the Twilight Zone. This is one of those times.

See also:

Friday, September 02, 2011

Migration of metadata from Aperture to iPhoto and Google's Picasa web albums

There can't be more than one person in a million who cares about this.

This post is for you. Please comment so I know I'm not alone. (Just joking, I know I'm alone.)

I've been curious about how metadata (title, comment, etc) passes between Aperture 3 and iPhoto 8.1.2 [8]

I ran an experiment today to find out. I started with a RAW image. I exported a JPEG version to the desktop then dropped it into iPhoto. I also, for the heck of it, used iPhoto's Aperture browser and dropped an image in that way. [5]

Here's what I found (see [6] below for a note on the table).

  • n/d means not displayed
  • e- means it can be seen in the EXIF details on Picasa Web album
Aperture Attribute Name
iPhoto Name
Picasa [4]

File
Media browser
File
Version Name
n/d [3]
title
n/d
Caption
description
[2]
n/d
Rating
none
n/d
n/d
Keywords
keyword
n/d Tags, e-keyword
Title
title
n/d
Caption, e-object name
Event Name
n/d n/d n/d
Image Location (text)
n/d n/d e-location
State/Province (text)
n/d n/d e-state
Image Location using Places
n/d [1]
n/d
yes [1]

So if you, for some strange reason [7], edit in Aperture but store in iPhoto, don't bother rating photos. You can, however, use the following attributes and see useful information in iPhoto 8:

  • aperture.Title -> iPhoto.title
  • aperture.Caption -> iPhoto.description
  • aperture.Keyword -> iPhoto.keyword
  • aperture.Version Name -> file name if specified during export
  • aperture.Places -> not rendering for me in iPhoto 8, but it's stored correctly and Picasa Web Albums can use it.

When exporting from iPhoto to Picasa only iPhoto.title and iPhoto.keyword are used.

Based on this experiment, I crated a custom Aperture metadata set that included Title, Caption and Keywords. I also customized my Grid View - Expanded metadata (cmd-J) to include Title, Caption, Keywords and Version Name.

Update 9/7/11: It appears that the Aperture Project Name is written to JPEG EXIF during export and read by iPhoto during import. Most surprising.

-fn-

[1] This really surprised me. In the past this metadata had been preserved. I wonder if an Aperture update made it incompatible with my older version of iPhoto. Although iPhoto 8 couldn't read the location metadata, it was in the EXIF header because Picasa could read it.
[2] Something odd happened here. I'd assigned a Caption on Import and that's what showed up in iPhoto. I suspect it was IPTC metada from the RAW image.
[3] This can become part of the file name on export from Aperture. The iPhoto.title attribute can be set equal to the file name by batch update. So there's a way to pass this to iPhoto if desired.
[4] Exporting from Google to Picasa Web Albums using Google export
[5] This isn't something you'd normally do. It just saves a @500K JPEG Aperture uses as a preview images. Still, it's interesting to see what happens with the metadata. 
[6] When I tried to create this table I again mourned the passing of FrontPage, Windows Live Writer (all but gone) and the great wysiwyg editors of old. Neither MarsEdit (this tool) nor iWeb do tables. So I downloaded SeaMonkey (88MB - once that was a lot). Since I remembered Netscape Composer I had a major flashback with fascinating visuals.
[7] I'm stuck in iPhoto until Apple changes Aperture's iPhoto import to include more metadata. Also, I don't trust RAW for archival storage. I save JPEG and discard RAW.
[8] I haven't updated to iPhoto 9, the dead fish smell has been offputting.

Sunday, July 03, 2011

Lessons from sharing our team videos

In a burst of foolish optimism, I volunteered to do some videos of our team pitchers and share them.

This turned out to be much harder than I imagined. It's one of those tasks where each step has multiple options, but only a few choices really work.

Along the way I tested and abandoned MobileMe's video gallery [1] and Karelia Sandvox [2]. I briefly considered then discarded Picasa Web album video sharing.

I did figure out a path that works. Two of 'em actually. I'll share the easy one first.

The easy option

Use an iPhone. Take short clips. Don't edit. Upload. Share links.

The much more painful deluxe option

The deluxe option assembling multiple video fragments from a Canon dLSR HD video camera into a one video for each pitcher, then embedding them in a web page.

If I ever do this again, this is what I'll do for the deluxe option.

I. Getting the video

  1. Bring a tripod (!) and an external microphone.
  2. Have the coach use the external microphone to narrate comments.

II. Use iMovie and share via YouTube hidden links

This was the first time I used the new iMovie. I read a few pages in the surprisingly well done Portable Genius Guide to iLife (see [3]).

  1. Each player gets one Project/Movie.
  2. Edit in 3:4 ratio -- this is the pitcher we're working on.
  3. From iMovie share to YouTube as "private" at the highest available resolution.
  4. In YouTube change these to "hidden".

This is time consuming. It took about 10 minutes for each clip to create a movie and upload. An alternative would be to export as .mp4 (NOT default .m4v) then bulk upload overnight [4]

III. Share images using Blogger and MarsEdit or HTML markup

  1. I tried a few web page editors, but, as noted above, I didn't have much luck.
  2. Instead I used YouTube's embed code (iframe markup) and pasted the embed text into the MarsEdit HTML view for each video. It was tedious but gave good results.

- fn -

[1] I'd not tried it before. Now I see why Apple gave up on the Galleries.
[2] Crashed on me during my video uploading attempts. Could be just bad luck -- pretty much every OS X app I use crashes sooner or later. Almost like 10.6.7 is an unhappy host OS. Still, bad timing.
[3] iMovie notes

  • Clip Library is a pool of shared clips that can be included by reference in multiple Projects (movies). Clips can be stored in iPhoto, Aperture 3+ or iMovie. I think Clip processing is smoothest if they live in iMovie. Clips can be split, reorganized, rated, merged. Even deleted, though that's not obvious.
  • A "project" is a movie.
  • In a clip or a project/movie click to set start point, space to play
  • click then drag to create a frame within a single clip (can't span clip): Click into  this frame and drag and drop to the Project area. It took me forever to understand this. I kept thinking I had to edit the clip first.
  • Native export is .m4v -> evil, vile, worthless, foul spawn of satan. Want .mp4

[4] The settings to make this work are not obvious. I got decent results when I used Export to Quicktime, MP4, then set data rate to 4096, image size 768x576, Fit within size for crop, and "best quality" encoding mode in video options.

Sunday, April 17, 2011

Implementing Google's two factor authentication

I've been planning to switch to Google's two factor authentication once it was a few months old (time for bug fixing), so James Fallows recent experiences only confirmed my schedule. Interestingly he's not the only recent victim. I assume, based on my personal experience, James' wife was the victim of a keystroke logger infection (was she using a Mac client?) or password reuse.
It worked pretty much as per my notes. Google's setup process takes about 15 minutes, including installing the authenticator app on your iPhone or Android device (other phones get SMS authentication). A few things to note ...

  • Emily pointed out that I need to add two factor recovery directions to our password database, so if I become abruptly dead or incapacitated she knows how to get my stuff. In particular I will put the backup verification codes into a piece of paper she has access to.
  • I needed application-specific passwords created for OS X Mail, iOS Mail, Google Voice iPhone, Reeder.app, Spanning Sync (forgot that one) and probably a few more.
  • It is a nuisance to enter the generated 16 character app-specific passwords on the iPhone -- but the white space feature is very nice. Would be great if the Authenticator app on the iPhone could handle assigning app-specific passwords. Google.app on my iPhone works with two factor; when I tried entering an application specific password it told me to use my two factor password. Just like my desktop, it can be configured to "remember me" for 30 days. (If you lose a device, you have to get access to Google to remove its credentials).
  • I don't think you can copy paste the numeric codes to from Authenticator.app to Google.app. You have to load into short term memory and tap them in.

Two factor authentication means I'm willing to enter Google credentials on relatively untrusted machines (given https encryption). That means ...

  • Whatever password I enter on those machines will be public (that is a keystroke logger will catch it sooner or later). So there's no sense using a complex or difficult to type password. The main value of the password is to protect me when my phone is lost. I've reverted to an easy to type password that I expect will become "public". In other words, a Level I password.
  • I can now stop using the Google App identity I setup to facilitate access to shared resources from insecure machines (such as corporate/office laptops)
  • As per Google's recommendations, I carry the verification codes in my wallet. I also have a printed set Emily can access.

See also:

Update 4/18/11: I've found a hole in the system. You can set any computer to save 2nd factor authentication for up to 1 month, but you can't revoke this remotely and there's no UI to undo the change locally. Since the extended authorization cert is saved as a cookie, you need to delete cookies on the machine to re-enable Authenticator requests. So you should really reserve extended authentication for trusted machines. A corporate laptop, for example, should not be considered a trusted machine.

Update 5/1/11: I'm surprised how often I need to generate a single use application specific key. For example, I just had to do one for the Google's iPhoto PIcasa image uploader. I'm up to about 13 of 'em. Bit of a pain really. I've contemplated storing one for general reuse in my password database but haven't done that yet.

Update 7/4/11: I still rely on two-step verification, but Google needs to do a lot more work on this.

Update 9/8/11: I rethink it all.

    Sunday, March 20, 2011

    Migrating images from SmugMug to Google's Picasa image store - Lessons in data lock and business models

    Life is fractal. That is, sampled at scales small and large, it resembles itself. Sometimes I think this is profound, especially when looking at smoke rings of galaxies, but maybe I'm just having flashbacks.

    So you don't need to spend 15 years in healthcare IT to understand why progress is slow. You only need experience migrating an address book between a PalmOS device to a Windows platform to OS X to Google Contacts (see also: synchronization is hell). That will tell you everything you need to know.

    Similarly you don't need to be a corporate CEO to understand the strategic role of switching costs. It's very easy to switch between Subaru and Honda, not so easy to change checking accounts or move from Microsoft Office to Google Docs. Business strategies differ [2]; though this is never discussed in the sycophantic business book business. You only need to look at moving photo libraries from SmugMug to Picasa Web Albums [1] to learn this.

    I am doing this now, and it's an interesting process. As expected, the switching costs are high. In most cases it's not worth the bother; if you have the original collections in iPhoto or a similar app it's best to abandon the old image libraries and start over. I'll explain first what you can move and what you can't, and what the implications are.

    What you can move

    • SmugMug will bundle all images into a single archive, hosted on Amazon's S3 servers, and allow download. This is commendable, and better than many vendors offer.

    What you can't export from SmugMug (what you lose)

    • Original file names.
    • All metadata other than what's embedded in EXIF files (so you do get the image acquisition dates).
    • Any titles, comments, notes.

    This data lock story has interesting implications:

    1. If you have the original albums/libraries in iPhoto/Aperture then you usually don't want to bother migrating albums. (In my case I have them, but for a few albums it's marginally more convenient for me to download and upload again even without metadata.
    2. SmugMug is minimally useful for offsite image backup. Images without metadata are better than nothing, but you should not consider SmugMug to be any kind of alternative to image backup.
    3. If you ever edit annotations online, then you deepen your data lock. Nobody, not even Google, allows export of this kind of metadata (likes, commentary, etc.). The business advantage of  "social," and "Cloud services" comes from the high switching costs created by data lock.

    Fortune 500 corporation or photo hobbyist, fractal life means lessons are easy to learn.

    [1] Why am I moving? SmugMug decided years ago not to invest in OS X support. I gave them a few years, but then I reluctantly migrated my newer images to Picasa web albums, which had significantly better OS X (and later mobile) support. Now, in the interests of simplifying my online life, I am consolidating and giving up my old collections.

    FWIW, here's why I would start with Picasa today, though a professional photographer would certainly prefer SmugMug. My decision has nothing to do with price, SmugMug is $30 a year and if I promoted SmugMug I'd probably pay nothing (referral fees). In fact, since Google charges differently for storage, they might be marginally more costly.

    1. Google's data freedom policy (data liberation team) is enough by itself to make my decision. Google supports full data sync, including metadata, to a cross platform app. No other vendor does this.
    2. SmugMug's lack of support for metadata export means it's not a supplemental backup store. Google's data freedom means it is.
    3. SmugMug has wisely focused on the professional photographer, but that means most of their services aren't useful for me.
    4. SmugMug is vastly better for printing images, photo merchandise etc. I print about 3 images a year.
    5. Picasa has far better OS X integration, though Apple is no help here.
    6. Google's image sharing interface is easier for my mother to use.
    7. I need to simplify my technological life. That means Google and Apple for me -- the right balance of coopetition. Between the two of them I get what I need.
    8. I am very annoyed that SmugMug auto-renews my account, and offers only immediate cancellation rather than a non-renewal option.

    [2] Companies with captive customers face terrible temptations, companies with mobile customers have different temptations. Think of the relationship between divorce laws and the status of women.

    Update 3/26/11: I downloaded a few albums, but it was pretty tedious to connect what I downloaded to the album names shows in SmugMug. I have the originals, so I focused on a few albums for a group where I probably didn't keep every original. The rest I vaporized. One less vendor to deal with.

    See also:

    Thursday, October 14, 2010

    Downloading a shared Picasa web album in OS X

    Despite Google's data freedom record, they've done a mediocre job freeing Picasa web albums. I know of only two ways to download an entire album.

    You can use the Picasa Web Albums uploader tool to download albums that you own. I think this tool works with non-Intel machines.

    If you have an Intel machine you can use Picasa for OS X to download albums you own - and, more importantly, shared albums from other people.

    I've done the latter. It works - but it's a pain. Read the documentation: Downloading Albums and Photos. Here are a few additional notes to help out:
    1. When you install Picasa it starts indexing your drive. Go to Tools:Folder Manager and mark every folder as exempt. It will stop indexing.
    2. Don't bother looking for the option to download from an album URL. It's not there. Yes, this is very weird.
    3. Go to the shared album and look for the 'Download' menu item. Click on it. You may see that 'Download to Picasa' is unavailable -- grayed out. That's because you need to quit Safari and restart after Picasa is installed (and perhaps running). Now you should be able to see this option. Click it.
    Picasa stored my images in Pictures\Downloaded Albums. I dumped them from their into iPhoto then deleted them.

    Friday, December 11, 2009

    Creating a photo collage: Picasa on OS X (Intel)

    My family does some things well, but family pictures are not among them. So for the Solstice this year I had to go the "collage" route.

    iPhoto does many things well, but Collage creation is not among them. (Neither is Library merge, but don't get me started.) So for our Solstice collage I had to turn to Google's free Picasa 3.6 for OS X (Intel only). It worked very well.

    If you do go this way, and you're not a Picasa expert, these install and setup tips might help:
    1. Download and install Picasa 3.6 for OS X Intel. It's a very straightforward drag and drop to Applications install.
    2. Launch. It will start reading in your photo library. You don't have all day, so you want to turn this off. Go to Tools:Folder Manager and remove everything.
    3. Go to Preferences and turn off face recognition. You don't need it and it will slow things down.
    4. From iPhoto export your images to a desktop folder. (Picasa can browse your iPhoto albums (not events) in a mixed year/name hierarchy, but it won't let monitor just one album/folder. It's all or nothing for iPhoto monitoring. So you have to export.)
    5. Using Tools:Folder Manager monitor the folder you just created to.
    6. Select what you want to work with, and choose Create:Collage.
    I didn't fully investigate the Collage tools, but they're impressive. Right click on images to change their stacking order. Click and move the red dot to change size and orientation. There's a "Clips" view on the left side you can add from, but I didn't investigate it further.

    From here you can create your collage as a JPG that can be edited and exported. Export and them move it back into iPhoto.

    I might start using Picasa for Mac as a supplement to iPhoto. Among other things, it's a powerful tool for reviewing and managing Picasa Web Albums -- which Apple conspicuously fails to support. If I do I'll write more on that, and add a link to this post.

    Wednesday, September 23, 2009

    Picasa 3.5 for Mac with iPhoto integration

    With release 3.5 the free Google Picasa photo manager and editor app is now cross-platform (Intel only on Mac):
    Google Photos Blog: Announcing Picasa 3.5, now with name tags, better geotagging and more
    ... we launched Picasa for Mac as a beta Labs product 9 months ago. Now that Picasa for Mac has almost all the same features as the PC version, we've decided it's time to remove the beta label. Remember that Picasa for Mac is designed to 'play nice' with iPhoto -- Picasa takes a special read-only approach to editing photos stored in the iPhoto library, duplicating files as needed, so your iPhoto library isn't ever affected when you use Picasa.
    The appeal of Picasa 3.5 for iPhoto users is the tight integration with Picasa web albums, esp. with "Faces" and geotagging.

    Thursday, June 18, 2009

    Picasa web albums uploader for OS X now downloads entire albums and more

    Google's Data Liberation Front marches on. I didn't even know of the Dec update ...
    Official Google Mac Blog: Upload Your Photos, Download Your Albums

    ... In December, the Picasa Web Albums Uploader added support for downloading a photo album to your Mac. We've recently updated the Uploader to include the ability to download all photos from all albums in your account. To start the download, sign in to your account with the Picasa Web Albums Uploader application and select the Existing Album tab. Holding down the Mac's Option key will change the title of the Download Album button to Download All. Then one click will bring all of your albums home.

    This update also improves reliability of the uploader's iPhoto export plug-in. The uploader typically keeps itself up-to-date, but you can also get the latest version, 1.3.1, from the download page...
    This is why I like Picasa Web Albums.

    Very nice. Viva La Data Liberation!

    Monday, May 04, 2009

    Apple's iPhoto and MobileMe photo blunder: when full quality isn't.

    Adam Engst is far too kind to Apple in this article (emphases mine) ...

    TidBITS Media Creation: How to Share Full-Quality Photos via iPhoto

    A reader recently sent me email asking why sending a photo via email using the "Actual Size (Full Quality)" option in iPhoto resulted in a photo that was significantly smaller than the size of the photo within iPhoto...

    A quick test on my system confirmed his results. My Canon PowerShot SD870IS's test photo started out at 3.1 MB and 180 dpi before dropping to 1.7 MB and 72 dpi. When I opened both the original and the reprocessed photos, Preview's inspector window showed the change in dpi and file size, though the dimensions of the photos were indeed identical.

    ... iPhoto always compresses photos sent via email to reduce the file size...

    ... posting the photo to your MobileMe Gallery won't help either, since iPhoto compresses uploaded photos there as well, even when you use the Actual Size option in the Advanced preferences for a MobileMe Gallery album...

    ... is an EmailCompressionQuality key in the com.apple.iPhoto.plist file that's set to 0.75 ... When I bumped it up, the size of photos sent via email did increase, but when I set it to 1.0, the file size nearly doubled from the original....

    Arggghhhh.

    Adam is glossing over some key points in an understandable effort to be sweet to Apple.

    The problem is not that "iPhoto [always] compresses photos", it's that iPhoto is decompressing the original JPEG (SD870 is JPEG, not RAW), then recompressing it at a severe .75 JPEG compression factor. The decompression/recompression factor is why, when Adam moved the quality index to 1, the resulting JPEG was twice as big as the original. (You'll see the same thing with any image managed this way.)

    This is a big deal for photo geeks. Try putting an image through four sequential JPEG 0.75 save/edit cycles and you'll get a mess. When I put "full quality" images on Picasa Web Albums or SmugMug one of the things I get is a high quality backup of my image. We now know that's not true of MobileMe -- it only looks that way.

    The discovery that "full quality" images posted on MobileMe are being put through the same decompress/recompress cycle, while being sold as "full quality", ought to be red meat for a lawyer. Anyone know of a hungry lawyer taking charitable contributions for yet another Apple lawsuit? I don't care about winnings, I just want them to suffer.

    For my part I'm going to give this a try with Google's Picasa Web uploader and see what I get back. I don't use MobileMe, and I'm not likely to start now.

    Incidentally, a more subtle version of this stupidity occurs in Aperture. If you import a JPEG image into Aperture, don't apply any edits, then export it from Aperture using a standard JPEG setting with quality 1 you'll see the same (pointless) decompression/recompression at work.

    Update 5/26/09: Apple doesn't apologize, but it effectively confesses to the blunder. No promises of a fix, however.

    Sunday, December 07, 2008

    Pixelpipe, Picasa and my Google password

    I've used PictureSync for years to upload images from iPhoto SmugMug. Lately I've used a specific iPhoto plug-in for Picasa and SmugMug uploads, but the app did well when I needed it.

    Now the author has launched a web service that performs similar functions: Pixelpipe. The beauty of the service is that he can create single high quality uploader for OS X or iPhoto or Windows, and then the middleware will route the image to one or more services.

    The good news, at least with regard to Picasa, is that you don't have to provide Pixelpipe with your Picasa/Google password. That would be unthinkable -- I have far too much wrapped up in my Google password to hand it over to a 3rd party. [Update: see comments.]

    Google has a good API for this sort of thing. If you're authenticated with Google, then Pixelpipe requests access and Google asks if you want to grant it. Pixelpipe never gets your Google info.

    I'm sure not all the services work that way, but Google is the one I care about. My SmugMug un/pw is only for photos, but my Google un/pw is a big chunk of my digital identity.

    Update 11/9/08: Signing up for SmugMug does require a un/pw, but that's a much smaller risk than handing over my Google credentials. I commenter tells us that SmugMug will also move to the "OAuth" standard, so even that won't be necessary. I recommend, however, that when you share a password like this you use either a unique password or, more practically, the password you use for all the stuff you don't really care about.

    In the crash of '08 a big advantage of Pixelpipe is you can spread your risks. I pay for storage at both Picasa and SmugMug -- and I have lots of it. Might as well replicate anything I send to SmugMug at Picasa.

    Wednesday, September 03, 2008

    Picasa web album face tagging - not only fun

    I didn't think my wife and her brother looked that much alike, but I can't argue with Google's face recognition algorithm. At a particular angle, in a particular light, there's a definite resemblance!

    Yes, Picasa's facial recognition software is a grade 2 event ...
    Gordon's Notes: Singularity alert: Picasa web album face tagging

    ... Yeah, we all knew it was coming, but it's creepy-cool anyway. Not quite goose bumps, but a grade 2 singularity event. (Grade 7 is when the Great God Google refers you to your soylent green processing station, Grade 1 is personalized search.)

    So will Google link the faces to the appropriate Google Profile? You just know they've got that one on their social networking strategy. (So how do kids get their profiles? Is it like Confirmation?)

    I love it. Now if there were only some way to sync the tags back to iPhoto ...

    I'll report on my tech blog after I try it. I'm sure the servers will be smoking tonight, so it'll take a few days. (Update: yeah, it's pegged. Stuck at 44% of faces.)..
    It took a day or so, but a lot of faces are recognized. The tagging UI is excellent. I was joking about the Google Profile, but I wasn't far off. Google matches tags against one's Gmail contacts and attaches email addresses in the tags.

    Now we need to sync the tags back to iPhoto. This really needs to be in the next version of everyone's photo management software.

    Privacy? Hah. That's strictly for the impoverished and the ultra-rich.

    Wednesday, June 11, 2008

    How to decide software is worth testing

    I'm not that happy with Google's free web album plug-in for iPhoto, so I figured I'd try a commercial alternative.

    If it passed a simple test.

    The test?

    It had to be easy to find the uninstall directions:
    iPhoto to Picasa Web Albums F.A.Q. - Products | ubermind

    How can I remove this plug-in from my system?
    iPhoto to Picasa Web Albums can be removed by deleting the plug-in file located at:

    ~/Library/Application Support/iPhoto/Plugins/
    iPhotoToPicasaWebAlbums.iPhotoExporter

    (~ represents your home directory.)"
    Not too hard, so I'll try it out.

    This is a very good screening test for all OS X software ...

    Update: 6/11/08

    Testing concluded, software rejected because:
    1. Licensing is by license server. So I can't backup my license, if their server goes down I can't recover it, etc. That's an immediately fatal flaw.
    2. It's very, very, very slow to browse a large collection of albums. Something is broken, scrolling was awful.
    3. It doesn't add much to Google's free uploader. In particular, there's no option to combine titles and comments to fit Picasa's single title field.

    Monday, October 15, 2007

    Google/Picasa Web Album uploader for iPhoto 7

    Google could have done a much better communication job over the past two months, but there's news of an updated Picasa Web Album uploader.

    The web site says they now support iPhoto 4 to 7; the version commitment is a much requested improvement. iPhoto 7 comes with iLife '08, the blog posting here calls it iPhoto '08 (emphases mine):
    Today's release of version 1.1 of the Picasa Web Albums Uploaders adds support for Apple's new iPhoto '08... this release installs and updates via Google Updater to ensure that you are running the latest version.

    While our first release used a private API to talk with the Picasa Web Albums server, the new version is built on the public Google Data API interfaces and our Objective-C GData Library. This will make it easier for us to keep up with Picasa Web Albums' new features. For example, the iPhoto export plug-in now can convert keywords in iPhoto to tags in Picasa Web Albums.

    Our goal is to keep the Uploaders as quick, straightforward utilities that make Picasa Web Albums readily available to Mac users. You can give us feedback about them at the Picasa Help discussion group.
    The last bit almost sounds like an apology. The language of the post is a bit ambiguous, but it sounds like they've updated both the standalone OS X and the iPhoto plug-in uploaders. The Keyword to Tag conversion is much appreciated.

    Update 10/27/07: Unfortunately, there's a significant regression in the new uploader. The old uploader concatenated the iPhoto Name and Description fields. The new uploader maps the Name to PWA caption and ignores Description. This behavior should be configurable, but, more importantly, Google needs to open source the uploader so users can configure it.

    Update 10/27/07b: Someone who seems pretty knowledgeable responded to my Google Groups post. Their was real thought put into the design, though I fear the thought was misguided. It actually uses the Name field value if it's been changed, otherwise it uses the Description field value. So the behavior is going to seem unpredictable to many users. The author clearly is not an iPhoto expert, or he'd have known that Batch Update makes it trivially easy to set the Name value to a date or meaningful string with counter; so that edits to comments are an easy extension. This needs to be fixed.