Google Fail: The Google Video download options

Google is terminating old content on mine on two services.

They're terminating pre-Google Blogger accounts that haven't migrated and they're terminating Google Video data. For various reasons I've data in both places.

Must be time from spring cleaning.

Personally, I don't mind losing the data. I'll say good-bye to the Google Video data; for one thing I don't think YouTube has the privacy controls GV had. I'm disappointed, however, with the way Google is doing this ...

... On April 29, 2011, videos that have been uploaded to Google Video will no longer be available for playback. We’ve added a Download button to the video status page, so you can download any video content you want to save. If you don’t want to download your content, you don’t need to do anything. (The Download feature will be disabled after May 13, 2011.)

We encourage you to move to your content to YouTube if you haven’t done so already...

.. Once a video has been downloaded, “Already Downloaded” will appear next to the Download Video link.

If you have many videos on Google Video, you may need to use the paging controls located on the bottom right of the page to access them all.

The classy approach would have been to provide a one click transfer from GV to YouTube.

Remember this as you migrate to the cloud.

Adding events to Google Calendar: generating quick add statements

Some parts of Google Calendar are pretty cool. Event import ain't one of 'em. I've gotten CSV import to work, but it's more than ugly. It's dumb [4]. Worst of all, if you make a mistake you can hose your calendar. There's event undo, but not import undo [1].

So when I had to enter 15 games from my son's calendar, I tried typing them in. That got tedious fast. I'm no good at data entry; I get bored. I make too many mistakes.

Instead I tried a middle-ground that worked pretty well. I dumped the event list into Numbers.app [2], then I wrote a simple Concatenate function [3] to construct Quick Add friendly statements like:

Baseball: LINWOOD MONROE - HIGHLAND PARK at HIGHLAND PARK on May 17, 2011 at 4:15 PM for 2 hours

I then pasted the statements into Quick Add one after the other [4]. Unfortunately Quick Add doesn't allow one to specify a target calendar, so they all went into my personal calendar. I had to do a search on "Baseball: " to find them all, then edit each one to move it to the shared family calendar. Even with that quirk it was relatively painless to enter data this way.

Which says something about how bad CSV import is!

[1] I though I'd read that Google was introducing a rollback option for calendars, but I can't find it. Must have been my imagination. 
[2] I bought it on the app store for a pittance, and I'm getting quite fond of it.  The font display is surprisingly bad, but that's not unusual in OS X (Mac Classic fonts were better, and Win 7 is best). Where it bests Excel is layout -- you can put as many table/spreadsheets on the work surface as you want.
[3] This doesn't work very well in Excel. In Excel a reference to date produces a date serial number in Concatenate. I believe this is a defect, and it's probably as old as time. I'm glad Numbers.app goes its own way. The function looked like this: =CONCATENATE("Baseball: ",E3," at ",F3," on ", C3 ," at ",D3," for 2 hours")
[4] A smart import function would use quick add style NLP to process any number of lines into events, then it would allow a user to correct the list, then it would import. With an undo option of course.

Picasa web albums and color management

[See the updates at end. My initial impression was based on dated material.]

I finally consolidated my images with Google's Picasa web albums: Migrating images from SmugMug to Google's Picasa image store - Lessons in data lock and business models.

It was a painful process.

After i was done I reviewed my newer images. They don't look nearly as good as they should. In particular they looked better on SmugMug.

Turns out Picasa web albums don't support color management (ICC, colorsync, etc). (See also - all these discussions get "closed to new replies" pretty quickly.)

Please cover your ears while I scream.

Ok, you can uncover now.

I used to use sRGB profiles, so the lack of color management was less apparent -- even with Mac/PC gamma issues (newer Macs quietly converted to PC Gamma). Now I use Adobe RGB color profiles, and I get to see how badly Picasa's color management sucks.

Sometimes you just can't win. I've started a newer thread on the online help forum, but I doubt there's any good news. I wonder if I'm going to have do my own image sharing and give up on the online services.

Update: A google support tech tells us that Picasa Web Albums will use the colorsync profiles of images uploaded with Picasa 3.8. I've a question pending on whether this is also true for Google's

Update 4/5/11: More from Google ...

Uploading via the Picasa Web Uploader should also preserve your color profile, and I tested this with Firefox 4 and Safari 5 on Snow Leopard and it's looking good on my end. Photos 1600 pixels or smaller are still color managed, but their thumbnails currently aren't (to help decrease load times)

Update 4/9/11:

your color profile is also preserved on photos 1600 pixels or smaller, but the thumbnails for these smaller photos (when you're on your album page, not a photo page) don't preserve your color profile. This only affects thumbnail previews, not the actual photos themselves.

If I understand this correctly, Picasa now preserves color profiles. Thumbnails for images smaller than 1600 pixels displayed on an album page are not color managed (how would the browser manage conflicting directions from hundreds of images?). A photo page should always use the preserved color profile.

See also:

• Mac OS X v10.6: About gamma 2.2: "Some images that do not contain color profiles might appear darker in Mac OS X v10.6 than they did in earlier versions of Mac OS X.  Adding the sRGB IEC61966-2.1 profile or Adobe RGB (1998) profile to these images lets them display correctly."
• Gordon's Tech: Smugmug: just use sRGB and be happy
• John's Digital Photography Page - color profiles (old)

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:

• Gordon's Notes: smugmug review: full res image sharing and photo printing (4/2004 - when I first became a customer. Back then my tech posts were in Gordon's Notes.)
• Gordon's Tech: Smugmug: just use sRGB and be happy (1/2006). Today we're still struggling with color profiles, but I with Windows 7, IE 9, Chrome, Safari and 10.6 maybe we're slowly getting to what we expected around 1998.)
• Gordon's Tech: SmugMug + PictureSync vs. Google Picasa Web Albums (9/2006). I thought SmugMug's future was limited. Wrong -- they seem healthy still! They found a paying market in professional photographers, and they took full advantage of high switching costs.
• Gordon's Notes: The rise of software rental (aka software as service) (2/2010). Another perspective on switching costs.
• Gordon's Notes: Cloud data: Should I trust (Simplenote) Simperium? (8/2010). Low switching costs make Simperium trustworthy if you assume all the data is public. Low switching costs make for honest and relatively ethical companies. This is, incidentally, why geeks love Dropbox.
• Gordon's Notes: Google has a Data Liberation team (3/2009). More than anything Google says, and more than anything else they have ever done, this has been their most important non-evil act.
• Gordon's Tech: Evernote's import/export test (updated) (7/2008). Evernote is better now, but I have not returned to study them. For them the data lock temptation must be irresistible.
• Gordon's Tech: data lock: All of my Gordon's Tech 'data lock' tagged posts.
• Gordon's Notes: data lock: All of my Gordon's Notes 'data lock' tagged posts. (Yes, I think data lock is interesting!)

Why cropping an 18 megapixel image isn't as good as an adequate telephoto

An 18 megapixel image has twice the data as an 9 megapixel image.

So does that mean a 135 mm telephoto and an 18 megapixel sensor can do as well as a 270mm telephoto and a 9 megapixel image?

No.

Why not?

Because when you crop the 18 megapixel image, and double the apparent size, you also double the image noise.

Blogger's text editor: I make another plea for a rational approach to paragraph formatting

It took considerable restraint for me to write this so politely.

Please stop using div tags to define paragraphs - Blogger Help

My blogs start around 2002, when Blogger used carriage returns to delimit paragraphs. They extend through the time that Blogger used <br> tags with or without hidden carriage returns.

These days, with either the "new" or legacy editor, it's unclear to me what Blogger does. I only know that when I use MarsEdit, Ecto or the native editor I see pairs of div tags. This causes a mess. Depending on which editor I use paragraphs vanish or spacing doubles. If I open older posts with the editors I get no paragraph spacing.

If I go into preferences I see:

"If Yes is selected, single hard-returns entered in the Post Editor will be replaced with single <br /> tags in your blog, and two hard-returns will be replaced with two tags (<br /><br />))."

Of course br tags are no longer used, so this language is simply wrong. If set it to "No" my old posts format incorrectly. To put it mildly, this is a mess.

I would like Blogger to use tags to, you know, delimit paragraphs. I would like Blogger to convert older posts to use <p> tags. Please Blogger, stop using <div> and <br> to define paragraphs, it's not what they're made for.

It's hopeless (yes, I've tried changing templates). Alas, I don't think there's really any way to move my blogs and keep any sort of reasonable formatting across 5,300 or so posts.

See also:

• Blogger's 3 year paragraph debacle - the case of universal line break conversion (10/2010). There have been years of complaints, until most everyone who cares has moved to WordPress. (Spammers don't care.)
• Gordon's Tech: Migrating from Blogger to WordPress - a guide

How I made Gmail and OS X 10.6 Mail.app into a grumpily married couple

There's no way to make Gmail and OS X Mail.app [1] into a happily married couple.

The Google Label (very shallow acyclic graph) vs. IMAP Folders (tree, single inheritance) models cannot be reconciled. If you use Gmail as an OS X Mail.app IMAP server, messages with multiple labels (Inbox, All Mail, Baseball, Work, etc) will be replicated in OS X. A single Gmail message may produce several OS X messages; Label-crazed geeks may find dozens of duplicates. Searches are a mess.

I'm happy to say, however, that I have found a way to make this dysfunctional couple settle down. I used How to make Gmail work well with Mail | Macworld as a guide. It claims too much, but the advice is still useful.

If you follow the articles advice, however, you will lose all your email archives from Mail.app; they will be only on Gmail. I inverted the advice. Using the advanced IMAP controls I turned off IMAP sync for all labels except for these four:

• Inbox
• Drafts
• All Mail
• Trash

This means that my tagging/organization pseudo-folders exist only on Google. None of that is exposed to OS X, the Google "labels" are gone [1]. On the other hand, I still have Spotlight Search and Smart Mailboxes, and my only duplicates are with All Mail and Inbox/Priority Inbox:

These duplicates go away when I move mail from Inbox to All Mail (archive).

Note I don't see the Sent folder (that would create All Mail/Sent folder dupes), but I have no use for the separate Sent folder (I can recreate an equivalent with Smart Search). I prefer the All Mail folder.  I don't bother exposing my Gmail Spam label/folder -- it's immense.

I followed most of the rest of the articles advice. Turns out I wasn't saving OS X Mail.app Sent messages on the server -- I thought I was.

With this configuration Mail.app looks like this:

It ain't a match made in heaven, but it's no longer Hell. Purgatory maybe. Maybe Apple will fix this in Lion?  [1]

[1] The fix is to stop treating Gmail tags as folders, and treat them as, you know, tags. Then support tags in Mail.app and use smart search to create additional derived folders. Who files email any more anyway? I stopped doing that years ago, and it's added years to my life. (By the way, I give a great lecture on email management.)

Update 3/17/2011: Alas, I can’t seem to eliminate the Sent folder. Even though I have the Label turned off on Gmail’s advanced IMAP control, it still produces dupes with the All mail folder. This is a more annoying problem than the small number of dupes in the All Mail folder. Maybe I need to move all my email from Gmail’s “Sent” folder to a new label.