Posts Tagged ‘photos’
Selecting nonRAW photos in iPhoto via AppleScript
July 7th, 2009 at 4:14 pm
I’ve started using the RAW format on my Canon G10 and have run into a small annoyance when importing into iPhoto. Both the RAW image and an accompanying JPEG of the same photo are imported, giving me two images for every photo.
The JPEGs seem unnecessary; they contain less information than the RAWs and new JPEGs can always be generated from the RAWs. Selecting the JPEGs and deleting them is easy when I’m importing only a few images, but it’s tedious when importing dozens. Here’s a semi-automated to do it.
- Have the Event you’ve just imported showing in iPhoto, as in the screenshot.
- Run the “Select non-RAWs” script described below (I use FastScripts, but there are other ways).
- Deselect any JPEGs that don’t have an associated RAW, because we don’t want to delete those.
- Delete the selection.
Here’s the AppleScript that does the selecting:
1: tell application "iPhoto"
2: set rawKW to item 1 of (every keyword whose name is "Raw")
3:
4: select (every photo in current album whose keywords does not contain rawKW)
5:
6: end tell
The script takes advantage of the fact that iPhoto automatically gives every RAW image the “Raw” tag. As usual, a seemingly simple AppleScript actually involved much trial and error to make sure the distinctions between strings, lists, and the ever-mysterious “references” are honored. Also note the “English-like” construction in Line 4:
whose keywords does not contain
Lovely.
The script would be much better if I had been able to write it like this:
tell application "iPhoto"
set rawKW to item 1 of (every keyword whose name is "Raw")
set rawNames to name of every photo in current album whose keywords contains rawKW
select (every photo in current album whose keywords does not contain rawKW and name is in rawNames)
end tell
This would select only those JPEGs that have a corresponding RAW, and Step 3 of the procedure wouldn’t be needed. Unfortunately, trying to run this script leads to an error:
iPhoto got an error: Can’t make {"IMG_1050", …} into type reference.
This is, apparently, a known problem for which I couldn’t find a straightforward workaround. If you know of one, email or Twitter me.
Update (7/10/09) After reading this post at maccreate.com, I went looking for a setting to prevent my camera from automatically creating a JPEG along with the RAW. This morning I finally found it. Not making or importing the JPEG in the first place is a much better solution than what I’ve described in this post.
Poor man’s cable release
July 6th, 2009 at 4:30 pm
I was going to take fireworks photos on Saturday with my Canon G10, which has a fireworks mode (focus at infinity, 2-second exposure, f8.0, ISO 80), but decided that I was already carrying more to the park—chairs, blanket, bug spray, etc.—than I wanted to. Maybe I’ll take photos next year, when my boys are older and can share more of the burden. In preparation for the photos I never took, I “made” a cable release for the camera, the highly intricate plans for which are detailed below.
A cable release is way of remotely operating the shutter of your camera. Its used mainly to take long-exposure photos without touching— and thereby shaking—the camera. Canon makes a cable release for the G10, but it’s only two feet long and pretty expensive for an item that I don’t expect to use very often.
You can also use the G10’s self-timer as a sort of cable release. Set up the camera to use the timer, press the shutter button, and pull your hands back so the camera’s vibration damps out before the timer opens the shutter. I’ve used this method many times with several camera models; it works fine, but it is a bit slow and awkward compared to a real cable release.
The key to making your own cable release lies in recognizing that the official Canon product has a 2.5 mm (or 3/32″) TRS connector—i.e., mini stereo plug—that fits into a jack on the side of the G10’s body. This is just a smaller version of the standard 3.5 mm (1/8″) stereo plug you’ll find at the end of your iPod earbuds.
(Image taken from the G10 manual.)
Cables with 2.5 mm jacks are relatively rare, but cables with 3.5 mm jacks are as common as dirt. I had a couple of them in my electronic junk box, including a 10-footer that had the TRS jack at one end and a 9-pin serial connector at the other1. This cable, combined with a 3.5-to-2.5 mm adapter—which are fairly cheap—were all I needed.
Cutting off the serial connector and stripping back the insulation, I exposed the three wires inside the cable. One wire is connected to the sleeve (1) of the jack, one is connected to the ring (2), and one is connected to the tip (3). The TRS connector gets its name from these three parts: Tip, Ring, Sleeve.
The image above shows the stripped wires in the cable, the 3.5 mm jack at the other end of the cable, and a Radio Shack adapter. The numbering of the tip, ring, and sleeve were taken from an image on the TRS Wikipedia page.
After plugging the cable’s jack into the adapter and the adapter into the port on the camera, it took less than a minute of experimenting to learn that touching the ring wire to the sleeve wire caused the camera to focus (like pushing the shutter button halfway down) and touching the tip wire to the sleeve wire caused the shutter to trip (like pushing the shutter button all the way down). There’s no need for power or any other wiring; just touch the wires to operate your camera remotely. Now you see why I said in the first paragraph that I “made” this release—there’s really nothing to it.
Eventually I’ll buy a cheap momentary switch and connect the raw end to it to give me something a little easier to use and less likely to unravel. But even without that, I have a working 10-foot cable release.
-
I don’t know what it was for, but I do know that none of my computers have serial ports anymore. I’ll never need that connector again. ↩
FMiL
June 16th, 2009 at 7:52 pm
Today I got my copy of iLife ’09 and installed it. I’ll start playing around with iMovie and iDVD eventually, I’m sure my older son will get interested in those programs and in GarageBand and iWeb, but my immediate interest was in iPhoto. So far it’s been a series of disappointments.
I’ve never been a big fan of iPhoto and still won’t use it with the photos I take for work—they need a specific type of project-based organization and separation that iPhoto will never provide—but I have started using it for my personal photos. I’ve been using whatever version came with my Intel iMac a couple of years ago, and wanted to upgrade to iPhoto ’09 for four reasons:
- Geotagging my photos with Places. I don’t have a GPS-equipped camera, but I like the idea of having the location of the photo attached to it, even if I have to do it “by hand.”
- Handling RAW images. My camera does have the ability to shoot RAW, and there are times when I’d like to make use of that.
- Uploading directly from iPhoto to Flickr. The uploader program from Flickr is kind of clunky.
- Straightening photos without using an external editor. I have a tendency to tilt the camera a bit when composing a shot, and I’d like to correct for that within iPhoto itself. My older version couldn’t do that.
I haven’t tried anything with RAW images yet. The straightening function seems to work very smoothly. As for geotagging and Flickr uploading, they’ve been a real disappointment. Geotagging by hand simply doesn’t work, and Flickr support is sort of half-assed by design.
Let’s start with Flickr, because it’s easier to explain. When you choose some photos and click on the Flickr button, this sheet pops out of the titlebar:
The first problem is that the name of the photo I’m uploading isn’t “Dec 23, 2008”—that’s the date on which it was taken. So the heading at the top of the sheet is misleading. More important, though, is that iPhoto is going to create a new Flickr set to put the uploaded photo into. There’s no opportunity for me to select an existing set. If I want the picture in an existing set—or a new set with a name other than “Dec 23, 2008”—I’ll have to go to my Flickr Organizr and do all that manually. Same for adding photos to groups. This is really annoying, as it makes it seem like you’re doing everything twice.
iPhoto does upload its metadata—title, keywords (tags), description—to Flickr, but there are some downsides to that. You can’t, for example, use different tags for iPhoto than you use for Flickr, because iPhoto establishes a permanent two-way connection between the two. This automatic syncing may be just what you want, but there are situations where you’d probably want different tags. Pictures of your kids, for example, would probably be tagged with their names in your personal iPhoto library, but you may prefer a more generic “kids” tag on a public site.
Frazier Spears discussed these shortcomings and others in a blog post written shortly after iPhoto ’09 came out. I saw links to the post back then but didn’t think to check it out when I was making the decision to buy iLife ’09. Spears is the developer of FlickrExport, an iPhoto plugin that does exactly what you’d think. It’s true that he’s hardly a disinterested party, but it’s also true that he’s spent a lot of time thinking about how Flickr exporting should be done. His appraisal of iPhoto’s Flickr uploader seems pretty fair to me.
The problem with geotagging is worse, but it seems to be due to a bug, not a design decision. When you try to set the location of an image through the Add New Place map, you cannot scroll the map to the right spot by dragging it around.
Instead of scrolling, the tiles of the map turn to ghost images as you click and drag them. It’s reminiscent of the way images on a web page become ghost-like as you drag them out of Safari and onto the Desktop.
Apparently that resemblance is not a coincidence. In this thread on Apple’s discussion site, several people have mentioned this problem and said it only arose after they upgraded to Safari 4—before that, the maps could be dragged just they can in Google Maps. At first, you may think that a web browser upgrade would have nothing to do with iPhoto, but I think the connection is reasonable. Much of the Safari upgrade consists of changes to the underlying WebKit infrastructure, an infrastructure that many applications use. OmniFocus had some problems during the Safari 4 beta phase. It only makes sense that iPhoto would be using WebKit to access and display data from Google Maps.
The most important thing I got from the Apple discussion thread is that I wasn’t nuts. The map is supposed to be draggable and in fact was draggable until recently for all those people.
Almost everyone on the thread has filed a bug report. I filed one myself this evening. It would be nice if Apple came out and told us if this really is related to Safari and when we can expect—ah hahahahahahahahahaha heeheeeheeheeee hohohohohoho haaaaa hahahahahahaha, oh man, I kill me sometimes. Anyway, maybe we’ll get one of those “assorted bug fixes and feature enhancements” updates and the problem will go away.
Update 6/17/09
Apparently I have more influence at Apple than I thought. Just one day later, Apple has issued Safari update 4.0.1, which “addresses incompatibilities between Safari 4.0 and certain features in iPhoto ’09, including Places and Facebook publishing.”1 I don’t know anything about the Facebook publishing part, but the Places problem is gone. The map can now be scrolled by clicking and dragging and you can set a photo’s location to wherever you want.
I must learn to harness this newfound power and ensure that it is used for good rather than evil.
-
I even shamed them into giving a proper description of the fix instead of the usual mumblemumble. ↩
Snappy
June 9th, 2009 at 11:30 am
On my way into work yesterday, I pedaled past this guy resting alongside the Waubonsie Creek Trail.
The path runs between a creek and a pond, and I’m not sure if he was going from one to the other or was just out to stretch his legs. I stopped and pulled out my camera for a few pictures, which I put up on Flickr.
The nice thing about shooting a turtle instead of a bird is that you don’t have be stealthy or quick about it. I did make sure to take one photo from a distance so I could capture him before he pulled his head in, but otherwise it was like shooting an interesting rock.
He was pretty big: his shell was about 10 inches across from side to side, and 12 inches long from front to back. I don’t carry a tape measure with me on my bike, but I can use my hand to give a sense of scale.
I wanted a clear view of his eyes for this portrait, and briefly considered clearing away some of the grass in front of him. But I decided my fingers were more important than an unobstructed photo.
Derotating JPEGs with exiftool
April 20th, 2009 at 4:30 pm
After importing photos from my digital camera, I often find that pictures I took in landscape mode are rotated to portrait mode. Rotating photos is no big deal—I can’t imagine any image editor that won’t let you do it—but I want the rotation to be done losslessly and I want to know it’s being done losslessly. Enter exiftool, an extremely full-featured program and Perl library for editing the EXIF metadata in image files. With exiftool, I can remove the spurious rotation that sometimes appears, and I know that it’s a lossless operation because exiftool doesn’t touch the image itself, only the metadata.
For a few years now, digital cameras have included a device that tracks the orientation of the camera and puts that information into the image file’s metadata. Applications that display images read that information and present the image rotated accordingly. The orientation information is expressed as an integer and written to a specific field in the EXIF metadata for the image.
If the camera is in landscape orientation with the bottom of the camera down, the orientation value is 1:
We can use exiftool to tell us this by executing
exiftool -Orientation -n <imagename>
and out will pop
Orientation : 1
If we leave out the -n option, exiftool will tell us the orientation in English:
exiftool -Orientation <imagename>
gives
Orientation : Horizontal (normal)
If the camera is rotated so the top is pointing to the photographer’s left, the image will look like this on our computer
and exiftool will tell us the orientation as
Orientation : 8
or
Orientation : Rotate 270 CW
which tells the software on the computer to rotate the image data 270° clockwise before displaying it.
Finally, if the camera is rotated so its top is pointed to the photographer’s right, the image will look like this on our computer
and exiftool will tell us the orientation as
Orientation : 6
or
Orientation : Rotate 90 CW
So far, so good. The photos of Dr. Doom appeared on my computer with the correct orientation because my computer looked at the Orientation field of the EXIF data and rotated the image accordingly.
Unfortunately, I happen to take a lot of photographs looking down, with the camera’s image sensor in a nearly horizontal plane. In this position, the orientation device—which presumably uses gravity to figure out which way is up—doesn’t have much to go on, and the value of the Orientation field is kind of a crapshoot. I think it reports the orientation the camera was in just before I pointed it down to take the picture. And that could be any orientation, because I never think about how I’m holding the camera before I’m ready to shoot.
When this inadvertent rotation occurs, I typically want to get rid of the rotation and put the photo in landscape orientation. Exiftool has a way of doing that. Instead of having it report the value of the Orientation field, I can have it write the value1:
exiftool -Orientation=1 -n <imagename>
will get stick the value of 1 into the Orientation field, and my computer will now display the images as if the camera had been held in the normal orientation. Doing this to the two portrait images of Dr. Doom yields
and
respectively.
I found myself doing this enough that I wrote a one-line shell script to save myself from typing “Orientation” over and over. I call it derotate:
#!/bin/bash
exiftool -Orientation=1 -n "$@"
One nice thing about derotate (which it inherits from exiftool) is that I can invoke it with as many arguments as I want:
derotate <imagename1> <imagename2> <imagename3> ...
and all of the images will be derotated.
There’s more to the Orientation field than 1, 6, and 8. A value of 3 represents an image rotated upside down (which my current camera, a Canon G10, doesn’t seem to generate), and values of 2, 4, 5, and 7 represent combinations of rotation and mirroring. You can see a full discussion here.
There’s more to exiftool, too. Read the fine manual.
-
By default, exiftool keeps a copy of the unaltered file in
<imagename_original>, so goof-ups can be recovered from. ↩
Fixing photo dates
February 4th, 2009 at 1:39 pm
Let’s say, just for argument’s sake, that when you got that new camera shortly after the first of the year, you mistakenly set its clock to the year 2008 instead of 2009. So now you have a bunch of photos with screwed-up metadata. What to do?
The first thing to do is download and install Phil Harvey’s extensive ExifTool system. ExifTool is a Perl library with a command-line application that can do all kinds of reporting and surgery on the metadata in your image files. Mac users can install ExifTool using either the Mac instructions (which install from a package) or the Unix instructions (which install through a Makefile). I chose1 the Unix installation so I’d have standard access to the libraries if I wanted to write my own programs. One thing I didn’t like about the installation was that it put the exiftool command-line program in /usr/bin, which I think should be reserved for Apple-supplied programs. After following Harvey’s instructions, I also did
sudo mv /usr/bin/exiftool /usr/local/bin/
which moved exiftool to a more suitable directory. There’s probably nothing wrong with the standard installation; this is just my preference.
With exiftool installed, navigate to the directory where your mistakenly-dated photos are and execute
exiftool '-AllDates+=1:0:0 0:0:0' *.JPG
This adds (+=) one year to all the date values (-AllDates) in the metadata for every .JPG file in the directory. The time shift is in the format
years:months:days hours:minutes:seconds
There are some shortcuts you can use if you just need to adjust the hour value—after a vacation in a different time zone, for example, or a shift to/from Daylight Saving Time.
Considering how little it seems to be doing, ExifTool runs rather slowly. That’s because it makes a backup copy of every file before changing the metadata. You’ll find the backups in the same directory as the originals, with an _original extension. If the metadata editing goes wrong, you can restore from these backups. This is a nice feature, but I still prefer to make backups before editing my photos.
ExifTool changes the metadata in the JPEG file itself. I’m not a big user of iPhoto, but it’s my understanding that it reads file’s metadata when the photo is imported, then uses its own copy of that data when displaying dates. So if you’ve already put the mistakenly-dated photos into iPhoto, you may need to move them out of iPhoto, change their dates, and then reimport them. Whatever you do, make sure you have backups before doing anything that might affect your precious photographs.
-
Oh, wait! This was supposed to be a hypothetical discussion, wasn’t it? ↩