Tuesday, May 09, 2006

LaunchBar 4.1 is out

TidBITS has a nice summary. I've been using 4.1beta for ages, I guess I'll get around to updating. Every so often I adopt a new Launchbar feature, but the core functionality is hardwired to my fingers. A terrific product, I've never really been tempted to try anything else. Why mess with perfection?

Monday, May 08, 2006

How to crater XP: print a google map from IE

Here's how I cratered XP. It didn't just lock up, it died. Nothing worked, no keyboard entry, nada. I had to power cycle.
1. Enable the obscure print background setting for IE (advanced options).
2. View a Google Map in Hybrid view (sat and map).
3. Print to Adobe Acrobat (probably works for regular printer as well but I don't have time to power cycle my desktop.)
When you do the same thing in Firefox you get a smear of blurred color, but neither FF nor XP craters. Interesting lesson about the stability of IE.

The best printing browser, hands down, is Safari. IE and Firefox used to be tied, but I'd say FF is ahead now. I'll have to try this experiment with FF and Safarin on my Mac and see what happens there.

I think Google Calendar might generate PDFs to print via a PDF viewer. Given the state of the browser, Google Map probably needs to do same thing.

StickyBrain and Yojimbo: CoreData is the key difference

StickyBrain 4.1 beta brings serious features to the table - The Unofficial Apple Weblog (TUAW)

My main question when comparing the two will be which uses a more accessible data store. Yojimbo uses OS X CoreData, StickyBrain uses its own database store. Point and game to Yojimbo.

No more single vendor data stores. CoreData is something we can get at.

Thursday, May 04, 2006

Aperture: good news

Two pieces of good Aperture nows.

First, Version 1.11 is out. I hadn't expected it for a month yet. Given the history of this product a 1.11 release weeks after the 1.1 release is a sign that Apple is serious about squashing the quality issues.

Second, Gruber has a believable story on why the 1.0 release was so awful and why it's likely Apple will get on top of the problem.

Wednesday, May 03, 2006

Automator does something useful? iPhoto browser

macosxhints - 10.4: System-wide iPhoto browser

Mail.app imap disaster - retracted?

This was transiently scary.

My wife's email is setup on two computers. Both use IMAP.

On the iBook, running OS X 10.3.9, her Mac OS X - Mail (Mail.app) IMAP account is set to view messages and delete permanently when deleted on the iBook. Since 'store sent on server' and 'store draft on server' don't work with our ISP's IMAP implementation, every message she sends defaults cc to herself. BTW, if you drag a message from a local store to the inbox it vanishes forever. God knows where it goes.

On the iMac, running 10.4.6, her Mail.app IMAP account is similary configured. The idea is she drags messages from her inbox when she's done with them to a local folder on the iMac. The messages are thus removed from the IMAP server.

She can thus work her email from two machines, but archives it at one machine.

Except today, after doing some IMAP work, every archival message on the iMac displayed the same error message -- basically saying that only the header was stored locally, the message itself was on the IMAP server and I needed to reconnect. Except, of course, it wasn't.

I quit Mail.app and went for a walk. When I returned I tried again. All of the messages were back again.

Weird.

PS. I've never done much with Mail.app. Today, when configuring my wife's email, I started using Smart Folders. The ability to create and chain these Boolean queries (iTunes can chain queries, Mail.app can chain queries, iPhoto cannot) is very impressive. Thanks to Spotlight they update instantly. I'm setting up her email to work rather like Gmail, but Mail.app is missing Gmail's ability to attach tags to messages. On the other hand Mail.app has a far superior query language and powerful rules, which can include AppleScript extensions. Mail. app may not be rock solid, but it is certainly very powerful.

Tuesday, May 02, 2006

My RAW image workflow

Once I decided to keep wait for Aperture 1.11 or later, I decided to see what I could do with iPhoto's 6.02's RAW capability (OS 10.4.6).

Actually, pretty well. I'm pleased. Not only that, but my new workflow is more efficient than my old one. Background details are in this post. Here's what I do:

1. All images are shot RAW. I set white balance to auto and ignore it. With those CR2 RAW files (12 bits of color) I can fix the color balance later.

2. I import all images into my 'intake' iPhoto Library. (I use iPhoto Library Manager to switch libraries, but if you option-click launch iPhoto it will ask for the Library location.)

3. Edit in iPhoto, cropping, adjust color balance, sharpness, etc. (I plan to buy Noise Ninja, that will change my workflow, more later).

4. Export as JPG (this drops color bits to 8, so it's important that the white balance has been fixed.

5. Rename using a A Better Finder Rename (this is not necessary for most.)

6. Import into my main Library, add comments, etc.

7. Put Intake Library images in the trash. Next time I use it I'll empty the trash.
I get significantly better results than I've been getting with in-camera JPG, and this workflow is really quick.

Update 5/3/06: Alas, I've come across a very annoying bug. I set iPhoto to save edited raw as TIFF 16bit/channel. When I did this and exported JPG the metadata was missing. GRRRRRRRRRR. I've turned off the 'save edited RAW as TIFF' option.