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

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.

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.

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, 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.

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.

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.

Friday, January 21, 2005

Testing Picasa and Blogger/Hello

I'm a dedicated iPhoto user, but I also have an XP Box with a large volume of photos on it. So I downloaded Picasa and gave it a try. Then I tested the Picasa/Blogger integration. Here's the photo I chose, it's of our dog Molly about 15 years ago - in her once-upon-a-time favorite chair.



A few impressions of the combination of Picasa/Blogger and (even) Firefox.
  • Picasa is very impressive. Unfortunately for OS X fans, it makes iPhoto look anemic. In particular, Picasa doesn't blink at handling a volume of photos that brings iPhoto to its knees. iPhoto is a spectacularly inefficient piece of software.
  • The Picasa/Blogger integration still requires use of "Hello", an addin software that acts like a robotic blogger. It's better than in the days when one had to use Flickr as an intermediate store, but getting it all working is strictly for geeks. When I went to the Hello site for downloading one of their inline images was missing -- not a good sign!
  • For geeks though, the Blogger integration works. I posted the above, then edited with the image displayed inline using the Blogger/Firefox "Compose" interface. It has a few bugs, but overall it's pretty impressive.
Points to Google. I hope Apple takes the competition to heart. iPhoto 5 is better than 4, but the performance issues are hard to get over.

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:

Wednesday, August 29, 2007

iPhoto beware: sharing doesn't include movies

I ran across yet another iPhoto "gotcha".

The only semi-approved way to migrate files with some metadata (caption, comments and date*) between iPhoto Libraries is by "sharing". It's a poor substitute for import capabilities, but this is what iPhoto's Product Management has given us. Among other limitations this kind of sharing allows one to import the last version, but not the original. The original is lost.

Tonight I tried sharing an iPhoto '08 Library from my MacBook to the main Library that sits on my iMac. (I've not yet updated to iMac to iPhoto '08 because I like to give Apple's releases two months to get the disastrous bugs out. One non-disastrous limitation is that Google's iPhoto Picasa Web Album plug-in doesn't work in iPhoto '08.) Sharing photos works, but movies aren't shared.

* I don't remember if keywords were preserved with iPhoto '07 sharing, but they aren't shared between iPhoto '07 and iPhoto '08.

So if you travel with one Library, then share your work back to the main Library on your return home, then delete the travel Library -- you lose your videos.

Lovely. Thanks again Apple!

PS. iPhoto '08 is a very good upgrade in most regards. There are lots of small fixes, overall it's a big enough improvement that even with the #$!$#!%! missing Library import it's well worth the price of iLife '08 to upgrade. I do recommend, however, using it in test mode only for at least one more month. Apple has a consistent history of disastrous iPhoto bugs with each major upgrade. Incidentally, there's something funny with the way the scroll bars work, they don't render correctly for me. I think that's because I enabled the "two arrow" hack years ago, I think I may need to undo that one.

Update 8/29: Wow, you can't even export movies from iPhoto 7.02 ('08). If you select movies then choose the "export" menu item, you get a "no item selected" message. The dialog's options make no sense for video only. It's pretty obvious Apple is trying to forget that they positioned iPhoto as a unified media library! You can click on the movie files and drag them to the desktop. When I copied them manually to my main Library they did keep the correct date attributes. I also saw my shared iPhoto 7.02 library vanish shortly after mounting in iPhoto 6. It took a while to get it back, I had to stop sharing the entire library and instead share a "smart folder" that had all photos but no movies. I was able to import all the versions (I compared counts). I confirmed that this type of "import" does discard the Originals.

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?

Monday, September 11, 2006

SmugMug + PictureSync vs. Google Picasa Web Albums

[Update 9/12/06: The CEO of SmugMug responds in the comments section. I'm impressed. I slightly edited one part of the original post as noted below. Also, I disovered on rereading it that my original post was mangled by an error in Blogger's RTF editor -- it choked on a less than sign and truncated a paragraph. I've added in the missing paragraphs from memory.]

Lately I've been disgusted with SmugMug's weak iPhoto uploader. Their latest OS X uploader is supposed to capture caption data from iPhoto, but it failed miserably for me on 10.3.9 (probably never tested on that platform) and 10.4.7 (though there subtle iPhoto issues may have played a role I think subtle iPhoto data bugs in my Library may be responsible, I need to retest on a clean Library).

This is more annoying than usual because Google's beta OS X uploader for their (beta) Picasa web albums works great. I payed Google $25 or so (love that Google checkout!) and I've used about 15% of my 9GB limit so far.

OTOH, Google Picasa albums don't have any printing services, you have to download images one at a time, and you can't password protect an album. SmugMug has passwords, though I don't recall if you can do multi-image download. If your Picasa "secret" URL is discovered anyone can view the album -- and I don't think there's any way to change the "secret" URL -- you'd have to create a new album, move the images, and delete the old one.

SmugMug has unlimited storage though images must be less than 10 MB, Google Picasa provides only up to 9GB though I expect that to increase. SmugMug, but not Google, will send a library CD to you for a fee -- a good backup to your backups. Both SmugMug and Google allow anyone to download a full resolution image, unlike stinky services like Ofoto/Kodak Gallery. Neither force viewers to sign up and both are very good about avoiding spam.

I don't believe either SmugMug or Google Picasa provide any facility to transfer images and metadata to a competing service, but I think both publish an API that might allow a developer to provide such a service.

Bottom line - I wouldn't mind if SmugMug were an option again. Happily the PictureSync Beta seems to have corrected the bug that rendered the production version useless. So SmugMug may turn out to be acceptable. I'm keeping them in the picture for now -- though if Google adds good print services SmugMug will be hanging by a thread.

If you do opt for SmugMug (always assume these services will go out of business tomorrow!), you can generate a kickback from me by using this link, or entering my email address (jfaughnan@gmail.com ) or my coupon number (sTHk2jeMi228c ) in the 'Referred by' field. Just don't blame me if the service goes under along with your photos -- only Google's still beta photo service is likely to last over 10 more years ...

Update: See the comments from SmugMug's CEO -- he's saying their finances are more solid than one might suspect ...

Friday, August 24, 2007

iPhoto '08 breaks Google (Picasa) web album Export

iPhoto '08 breaks the excellent Google (Picasa) export iPhoto Plug-In. Sigh.

I forgot, again, the #1 rule of life with Apple -- wait two months after any major update before use. Apple doesn't pre-release non-OS software to vendor partners, so they need at least two months to fix their software.

Update 10/13/07: It's been six weeks now. Google's Picasa Web Album Mac Tools page still says this:
The Picasa Web Albums Exporter is a plug-in that lives right inside iPhoto™. Select photos, choose Export in the File or Share menu, and upload them directly to your web album.
There's no mention that the plug-in no longer works. A month ago a developer commented on a post of mine saying that they were working on a fix, but there's been no communication since through any venue. Plaintive calls turn up every week or two on the Picasa Web Album Google Group.

I know a bit about the vertical IT market. In that market resources are very tight and timelines are long. This kind of thing happens in our market, but it's amazing to see it happening to Google. Microsoft moves with lighting speed by comparison, and they would have updated their publicly facing material weeks ago. Even Apple would have communicated better than this, and they're notoriously close mouthed.

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.

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.

Saturday, March 10, 2007

Shutterfly provides print services for Picasa

I've used both Picasa Web Albums and SmugMug for photo services. I've favored SmugMug for several reasons, including that they're much more serious about color profiles, password protection, backup services, unlimited uploads, and they're less expensive [1]. On the other hand Picasa has much better iPhoto integration. (I use PictureSync with SmugMug.) Most of all, however, Picasa hasn't offered print services.

Tonight SmugMug was very buggy. Not just one repeated bug, but several nasty time consuming bugs. I became seriously annoyed, and went back to Picasa. They offer print services, now, and one of my very first photo vendors, Shutterfly, is a featured provider. (I probably still have old albums on Shutterfly.)

So now Picasa offers reasonable print services, even if they may not be the equal of SmugMug's. On the other hand, Picasa has never been as buggy as SmugMug was tonight...

I'm still moving back and forth, but I'm going to use Picasa for a while. Sure SmugMug wins on big by the feature count, but time-eating bugs are intolerable. Also, they're incredibly late with good iPhoto integration.

[1] In fact an old blog posting of mine still generates sufficient SmugMug referalls that the service is free for me. If I really do switch I'll have to turn that link off, but maybe SmugMug will fix its bugs.


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.

Wednesday, May 09, 2007

AOL Pictures for iPhoto?!

When did AOL suddenly get interesting? I just registered for AOL's xdrive, and I saw a link to their xdrive photo service. There I read:
AOL Pictures - Create Album:

... Free, unlimited storage of your photos in original resolution.

... Download the AOL Pictures uploader and management tool for Mac. It also allows you to upload directly from iPhoto ...
I use Google albums because of the elegant iPhoto integration, and I've used SmugMug for years. Neither are free, I've used half by Picasa web album (google) quota, and SmugMug is not serious about OS X support.

So this is interesting, especially because of the upload speed I just saw with xdrive. Uploads to SmugMug is very slow, and Picasa Web Album is no speed demon either.

It would be hilarious if I returned to using AOL. I used them back when they were Mac only, before their was a publicly accessible net. I gave up on them in the 80s ...

Update: download the application here. It looks kind of crude and the install is a bit odd, but it respected admin rights and it uses the keychain. Drag the app to your Application folders. Then launch it, it will ask about installing the iPhoto plugin. It does a proper install with privilege request. There's even an iPhoto plug-in uninstaller built into the desktop AOL Pictures app, and the app is easy to remove. It doesn't work with all AOL/AIM names but it worked with mine, I suspect older AIM uses might need a full AOL account. The upload was smooth and quick.

Alas, that was the end of the good news. The iPhoto plugin doesn't transfer metadata. No title, comments, keywords, etc. Oh well, I'll uninstall but keep this in mind. Maybe they'll fix it later.

PS. iPhoto wasn't built to handle more than 2-3 plugins. There's no room to display all the names of the plugins!

Monday, September 03, 2007

The problems with Picasa Web Albums

I pay Google for my Picasa Web Album storage.

For this I get:
Picasa Help - What are your technical requirements for uploading videos?

Video uploading is only available through Picasa.
and no status updates or acknowledgement that iPhoto 2008 has broken the Picasa Web Album iPhoto plug-in.

I'm definitely feeling like a second class citizen on Google's Picasa web albums.

It doesn't help that Google Video is out of order today as well - no uploads (server failure).

.Mac is looking better these days.

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.

Tuesday, August 14, 2007

Google/Picasa Web Album API for OS X and others

I missed this June 5 Google Mac article: Picasa Web Albums meets Google data APIs. The author provides some interesting examples of using a data API with Picasa (combine webcam image feeds with RSS), shows examples from an OS X image upload application, and points to Google's open source Objective C (Mac) data API.

Of course if another photo service has an API, then one application is transferring images and metadata between services.

The Google Web Albums Data API has more information, I'm going to start hunting for people who've implemented their suggested examples:

  • Include your public photos in your own web page, and allow users to comment on them (and have the comments stored in Picasa Web Albums).
  • Write a plugin to manage your albums and photos from a desktop or mobile phone client.
  • Create a custom screensaver to display your Picasa Web Albums photos on your computer.
Some recent additions are documented here. You can even play with them directly from your web browser (click here for my last 25 public uploads in Feed (XML format, I've got them in a Bloglines feed now).

I wonder if it's possible to call these APIs from AppleScript written within Apple's Xcode IDE? If so, it might be possible to do some interesting things almost readily. (Or just use Python?)

I do need to think about this. Heck, it might be possible to suck images directly into iPhoto just by creating a URL-query that creates an RSS feed ...

Today, I do like Picasa, even if Google doesn't understand URLs.