<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	xmlns:series="http://unfoldingneurons.com/"
	>

<channel>
	<title>Tom Gidden &#187; iphoto</title>
	<atom:link href="http://gidden.net/tom/tag/iphoto/feed/" rel="self" type="application/rss+xml" />
	<link>http://gidden.net/tom</link>
	<description></description>
	<lastBuildDate>Fri, 02 Jul 2010 13:00:07 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1-alpha-15359</generator>
		<item>
		<title>iPod Photo Bloat</title>
		<link>http://gidden.net/tom/2007/05/10/ipod-photo-bloat/</link>
		<comments>http://gidden.net/tom/2007/05/10/ipod-photo-bloat/#comments</comments>
		<pubDate>Thu, 10 May 2007 12:47:57 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[Techie]]></category>
		<category><![CDATA[bloat]]></category>
		<category><![CDATA[iphoto]]></category>
		<category><![CDATA[ipod]]></category>
		<category><![CDATA[itunes]]></category>
		<category><![CDATA[rant]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/05/10/ipod-photo-bloat/</guid>
		<description><![CDATA[In the process of replacing my iPod, I've noticed a couple of things "I Don't Like About iTunes and iPod".  After my previous rant about iPod reliability, I'm now onto the sloppy programming behind iPod's photo functions.

So, I started transferring all my media to the new unit.  The music went across fine.  Videos, not so much, but more on that later.  Photos, however, were taking hours to transfer.  iTunes was "optimising" the photos.  I remember this taking a while back when I got the previous iPod, but I'd forgotten how slow it was.
I've got about 19GB of photos, all neatly keyworded in iPhoto.  Since I got my iPod Photo two-and-a-bit years ago, I've kept a copy of my collection on my iPod: usually with "Include full resolution photos" ticked.
So, what's it doing?
It's decompressing the photos into YUV format at iPod screen resolution.
Each photo, regardless of the original file size is "thumbnailed" to a new file of about 851K on the new iPod Video, and marginally less on the iPod Photo and the Nano.  This is allegedly to offload some of the processing effort from the iPod to the host computer, so the iPod doesn't burn through batteries trying to do the instant photo scrolling thing.
Problems with this approach:

It takes a long time to convert all my photos.  I've got an iBook G4 1GHz, not an eight-core Big Mac.  Since the screen size is different on the new iPod, the whole process has to be done again.  I'm also not convinced it's thumbnailing particularly efficiently.  I bet ImageMagick would be faster.
It uses up a lot of space on the iPod.  Okay, I'm not likely to use up the 80GB any time soon, especially since my iBook doesn't have the disk space to store all that anyway.
It uses up a lot of space on the host machine: in my case, 9GB extra!  That's almost 10% of my laptop's HDD.
iTunes/iPhoto isn't well-behaved enough to clean up after itself.  The thumbnails have a nasty habit of sticking around.  If a photo is deleted, there's no guarantee the thumbnail will be deleted.  If you change iPod model (like I did), the old, useless, wrong-sized thumbnail will stay there.  If, after noticing this bloat, you disable some or all Photo syncing, the cache still sits there.  Considering how long the process can take, I understand this design decision, but I don't necessarily agree with it.
It takes ages just to transfer these thumbnails compared to transferring the (smaller!) originals.  Now that they've canned FireWire over the slower, less reliable USB2.0, iPod syncing is sluggish.  Piping this crapload of excess data around really doesn't help.

The thing is, I really don't think any of this is necessary!
Now that the iPod Video is better specced, why can't it do its own thumbnailing, and cache them locally?
And at the very least, why do they have to be possibly the least efficient file format?  JPEGs aren't hard to decode, and while I could understand the need for keeping lower resolution thumbs on the iPod, I can't see why JPEGs wouldn't do.  While admittedly the iPod uses hardware to decode video, it still manages to do some reasonably sweet 3D graphics in the new iPod Games, and I don't think they shoehorned a Radeon into the iPod, so the thing's capable of doing maths, to say the least.
As far as the hard drive is concerned, the standard reply is to get a bigger drive.  I've already got a 100GB drive in my iBook, and I still cling to the concept of portability, so an external drive is out.  If there was a good reason for this, I'd think about being more selective, but it's just waste and sloppy programming on the part of Apple.
It seems probable that Apple crammed in this functionality with the underpowered iPod Photo, and then failed to update the codebase.  I accept that the Nano might not have the oomph to do the work and would need the offloaded conversion, but then again, the Nano's not going to store a huge cache anyway!  When it comes to the larger, more powerful iPods, it should act differently.
I'm sure Apple aren't losing any sleep over this problem:  they're too busy working on the OS X-based iPhone and the inevitable touchy-feely non-phone-iPhone iPod that will accompany it.  That thing will presumably be able to do the thumbnails itself.
It still doesn't excuse the sloppy coding that's currently there.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/05/10/ipod-photo-bloat/feed/</wfw:commentRss>
		<slash:comments>-6</slash:comments>
	
		<series:name><![CDATA[iTunes and iPod rant]]></series:name>
	</item>
		<item>
		<title>iPhoto, Flickr and EXIF munging using Perl</title>
		<link>http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/</link>
		<comments>http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/#comments</comments>
		<pubDate>Wed, 27 Dec 2006 18:21:00 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[albumdata.xml]]></category>
		<category><![CDATA[apple]]></category>
		<category><![CDATA[cocoa]]></category>
		<category><![CDATA[exif]]></category>
		<category><![CDATA[flickr]]></category>
		<category><![CDATA[flickr::api]]></category>
		<category><![CDATA[geocoding]]></category>
		<category><![CDATA[geotag]]></category>
		<category><![CDATA[geotagging]]></category>
		<category><![CDATA[iphoto]]></category>
		<category><![CDATA[iptc]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[mac::iphoto]]></category>
		<category><![CDATA[metadata]]></category>
		<category><![CDATA[OS-X]]></category>
		<category><![CDATA[perl]]></category>
		<category><![CDATA[PerlObjCBridge]]></category>
		<category><![CDATA[picasa]]></category>
		<category><![CDATA[scripting]]></category>
		<category><![CDATA[xmp]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/</guid>
		<description><![CDATA[EXIF/IPTC/XMP tagging of GPS coordinates, folksonomy tags, and other goodness is a nice idea, but unfortunately, iPhoto and Flickr don't play too well together.  Couple this with the fact that any decent support those products now have is not included for photos already imported into them.  So, here are some notes resulting from some experimentation, along with the Perl code I wrote along the way.

(Note: for the rest of this post, I'll refer to all metadata stored in the image file itself such as EXIF, IPTC, XMP, etc. as "EXIF" data.  This isn't strictly correct.  However, using the term "metadata" could be confused with such data held in other files, such as iPhoto's own database.)
For Christmas, my dad bought my mum a decent photo printer: the Canon PIXMA iP5200R.  Very nice piece of kit, with good printouts, and most importantly, easy setup, with no CUPS and Windows -v- Mac issues.  Anyway, as an upshot of this, my dad wants some of my photos for building a Picasa library for her to print stuff from.  Specifically, the photos from the Caribbean holiday we had earlier in the year.
I've been playing with Picasa a bit, and I must say I love it.  It's what iPhoto should be.  It's a good deal faster for a start.  That's comparing my iBook G4 1GHz against my mum's Compaq Deskpro Pentium III 733MHz, which is a few years older.  Secondly, it doesn't use a horrible non-scalable monolithic database like iPhoto does.  Thirdly, it seems to deal with metadata a bit more sensibly.
On the downside, neither iPhoto or Picasa handle collaboration functions very well.  Both have publishing functions, and iPhoto has a read-only "sharing" function, but I mean the true sharing of photo libraries.  My mum and dad have separate computers, but they share a camera, so it would be incredibly useful to have a shared photo library which either could use.  On this count, Picasa wins slightly, because although it has no true sharing ability, there doesn't seem to be anything wrong with two copies of Picasa working on the same directory on a shared drive.  I'm not sure how it would handle conflicts though, due to the lack of locking.  For now, I'll advise my parents not to run it at the same time.
I usually manage all of my photos in iPhoto.  However, due to the lack of decent keywording and other metadata in iPhoto, I ended up adding a lot of metadata in Flickr instead.  As a result, my iPhoto library is woefully out-of-date with my Flickr library, even though it's far more complete as I only upload a subset of my photos to Flickr.  I specifically want to extract Flickr tags back into the files themselves, and ideally rip the Geotagging information I added within Flickr.
While iPhoto is drastically improved by Keyword Assistant, it doesn't store the keywords (read: tags) in EXIF form, but in its own database.  During this investigation I discovered that iPhoto does import keywords from EXIF, and also Geotagging info.  The fact that it doesn't manage EXIF is a fairly annoying flaw, and one that I hope they'll be fixing.  I've heard that Microsoft Vista now does sensible things with EXIF.  iPhoto is, quite frankly, falling far behind other solutions at this point, and I hope next month will bring a new iLife with an improved iPhoto.
So, I had a good look around the 'net for some utilities to try to clear up this mess.  I've had a play with things like Cal Henderson's Flickr::API and Dmytro Kovalov's Mac::iPhoto before, and they're not particularly mature.  Incidentally, Mac::iPhoto also seems currently broken.
Others have attempted using Applescripts.  The ones I found around the 'net are far too slow to cope with the ~8000 photo collection I have.  This is probably due to the sucky design and/or implementation of Apple Events in MacOS.
Instead, I've had a play with PerlObjCBridge, or whatever Apple's calling it.  In Perl, it's "use Foundation;".  This gives access to the Cocoa API within OS X, which I figure is probably the fastest way to manipulate Property Lists.  Since iPhoto stores at least a backup of the database in XML form (specifically Property List form) as "AlbumData.xml", we can use this to cross-reference the data.
The most critical link between my Flickr and iPhoto collection is missing.  This would be a link between each individual photo and its alter ego in the two different collections.  Since filenames aren't necessarily complete or preserved by either iPhoto or Flickr, this is relatively difficult to establish.
I've found that a reasonably good connection is between image creation time/dates.  By matching the EXIF timestamp data within the file stored by iPhoto with the EXIF data extracted from Flickr, you can get a reasonably good correlation.  At this point, it would be a nice idea to shove the Flickr URL for the image into the local EXIF data and get iPhoto to read it.  From then on, there would be an established link.
Well, I got about as far as adding the URL, tags and geocoding to the image, but I gave up when it came to getting iPhoto to read it.  There is a relatively obscure "rebuild" function in iPhoto, triggered by holding down Cmd and Opt while starting iPhoto.  This allows rebuilding of thumbnails and the binary databases (presumably) from the XML.  Unfortunately, it doesn't seem to reread the images for new metadata.  I think this would require actual modification of the AlbumData.xml file to work, which sounds like a far bigger job.
In the meantime, this proves that such a script is feasible, albeit painful.  At the moment, this is a run-once script, so it's not much use for regular usage.
SOURCE CODE:  I am supplying this code freely with the understanding that there is no warranty or guarantee.  Also, I'll go as far as to say that incorrect usage could quite easily delete your photos, destroy your Flickr account, upset Flickr, and kill your pets.  DO NOT USE THIS CODE UNLESS YOU UNDERSTAND IT COMPLETELY AND ARE WILLING TO TAKE RESPONSIBILITY FOR ANYTHING GOING WRONG.  For more details, read the README file.
The most recent version can be obtained from my Subversion repository: iphoto_flickr_exif_munge/.
I also apologise for the quality of some of the code.  It's far more experimental than I'd usually want to release, but I think it might be of use to someone like me in a similar situation.  Rather than just throwing it into the depths of my hard drive and forgetting it, I figure it's probably worth blogging.
My conclusion to all of this is that I really need to get my iBook replaced with something good enough to run Aperture or Lightroom, and then reimport the whole bloody lot.  Painful, to say the least.  I'm also hoping that Google get around to writing Picasa for the Mac.  I think I'd prefer it in the long term.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/feed/</wfw:commentRss>
		<slash:comments>-760</slash:comments>
		</item>
	</channel>
</rss>
