ExpressionMedia can do it, via scripting
Bridge cannot as it doesn't import anything - it's just a browser
Portfolio, Cumulus - yes and yes, via scripting and other means
iPhoto - yes, via scripting
Aperture - yes, via scripting

Other apps?

-Roger

Yes, of course - I use Exiftool... the field is called "RawImageDigest" so if that field exists and is populated then the hash is there. I've got a few AppleScripts (which in turn automate Exiftool) for scanning a collection to report on whether each file has this hash - if you're on a Mac and interested I'd be happy to share.

-Roger

Has anyone implemented RawImageDigest support (for DNG)? The spec is fairly straightforward, saying just the following:

"This tag is an MD5 digest of the raw image data. All pixels in the image are processed in row- scan order. Each pixel is zero padded to 16 or 32 bits deep (16-bit for data less than or equal to 16 bits deep, 32-bit otherwise). The data for each pixel is processed in little-endian byte order."

On reading this I was a little surprised that there is any processing needed on the raw pixel data - I supposed RawImageDigest was an md5 digest of unpadded, truly "raw" image data as it is stored in the DNG wrapper. Does anyone here have any insight into this? Are you aware of any free code libraries or command line tools which implement RawImageDigest calculations?

Thanks for any leads,

Roger Howard

Ahhh shoot, yeah that's it - sRAW isn't supported in any of the Apple apps which depend on their system-wide camera support (Finder, Preview, Aperture, etc).

- Roger

I have both CR2 and DNG files from a 5d Mark II here on OSX Snow Leopard and the thumbnails show in Finder, the previews in Quicklook, and I can open them in Preview. Are you up to date with Software Update?

-Roger

XP and Vista have the same effective memory limits - if you want more than 4GB of memory you'll want to use a 64-bit OS (XP, Vista and Win 7 all come in 64 bit flavors). And note, even with 4GB, you'll largely be limited (out of the box) to 2GB per application.

Seriously, though, if you're going to upgrade from XP go to Windows 7, not Vista. And Win 7 64bit is perfectly fine - unless you're running legacy peripherals that have no 64 bit drivers you'll be much better off on Windows 7 in 64bit mode.

Also, note that these are simplifications - 32bit Windows (Whether XP, Vista or 7) has so many different ways of tweaking memory config that it is possible to use more than 4GB, or more than 2GB per app, using various tweaks like PAE; but it is *far* easier to just run the 64 bit flavor and not have to think about this, assuming you don't have problems that prevent you from running a 64 bit OS.

 -Roger Howard

AHhh... well I'm not terribly familiar with C1 these days, and not at all with regards to its DNG support. If it can generate DNGs, then those DNGs can contain previews showing the file as it should look.

Or generate JPEGs for each asset using C1, and then use that JPEG as the preview in your DAM - or insert it directly back into the DNG as its preview using exiftool.

 -Roger

Just a guess, but Snow Leopard introduced Quicktime X and deprecated the legacy Quicktime APIs (though they are still available). EM2 has long used Quicktime APIs for generating thumbnails/previews of many file types, and EM hasn't been significantly overhauled since long before Snow Leopard. It sounds at least probable that the issue relates to the use of the legacy Quicktime APIs - it'd be a big surprise to me if such a big performance hit resulted from drawing a simple status bar update.

Just a guess of course, and there's nothing you can do to test this I suppose

-Roger

Assuming you mean either 2 or 4 quad-core CPUs, I'd go with a single quad-core at the higher clock speed. The vast majority of the time it'll be faster.

In limited cases, having twice as many cores at a somewhat lower clock speed will be faster, but in most workloads relevant to people here I'd say that's the exception.

- Roger Howard

If the price differential isn't a problem, go with the 6 core machine. While Photoshop, Lightroom and many other apps can indeed use more than 1 core at a time, most won't make use of all cores effectively (and it varies widely by what you're doing - some operations won't use more than a single core ever, some scale across multiple cores almost perfectly) - there are diminishing returns with multiple cores in most workloads. The faster clock speed, bus and memory, plus a better video card (which can help Photoshop in many ops now) in the newer 6 core model will likely make the most difference in regular use. Don't forget, RAM is one of the cheapest and most effective upgrades - don't skimp there. If I was building a Mac Pro workstation today, I wouldn't go with less than 12GB, and would go as high as I could afford. Of course, buy your memory from somewhere else - just like your hard disks - to get the best options and far better pricing.

- Roger Howard

A few reasons people use tracklogs:

1. They don't have a camera that automatically records GPS metadata at each shutter click, and manually creating a waypoint each time they capture a shot isn't ideal.
2. They want to capture GPS data at all times, NOT just when clicking the shutter. This might be for non-photo reasons - recording trails they hiked, or even recording GPS data while shooting video.
3. They want the precision of GPS location data, so remembering where they were within +/- quarter of a mile is not what they want.

While most of my photography doesn't require extremely accurate location data, tracklogs are easy to capture and require basically no effort - just turn on the GPS when you set out in the morning, and remember to charge it at night. Oh, and make sure to keep the clocks in sync.

Merging tracklogs with the photos, so the GPS data gets embedded in the images, is a trivial, automated process these days. Not an inconvenience at all, and basically the only (or at least easiest) option for anyone who doesn't have a camera that captures GPS data at each shutter click.

I don't see how you reached your conclusion that it's far better not to tracklog, but that's an individual opinion I suppose. I'd rather have the tracklog for the majority of the cases where it's useful, and fill in the manual data for the rare cases it's not. When my GPS fails (lack of signal) it's usually because I entered a building, in which case the last recorded (and next recorded) GPS data once I'm out of the building is likely to be useful enough for my purposes. Since most software which geotags images using tracklogs will pick averaged points during periods where there's no GPS data, this almost always works exactly as expected.

So if you're saying that GPS isn't useful if it's not captured in the camera, embedded into the image, at the time of the capture I would disagree. And, of the methods available to capture GPS data if you shoot with a camera with no GPS, I'd say tracklogs are by far the easiest.

Besides, as I said, when I travel I record tracklogs regardless of whether I'm shooting or not. Geotagging my photos is just one use of the tracklogs.

-Roger Howard

A tracklog is simply the record of all the GPS location data captured during a session - a timeline, where every point on the timeline represents a location determined by the GPS receiver. This happens unattended, unlike manually recording waypoints with your GPS when you remember.

Most GPS's support tracklogging - you simply turn logging on, and when you're done you have a text file with GPS coordinates and timestamps. These coordinates will typically be recorded at some regular interval - such as every 5 seconds. This tracklog can be used to load into Google Earth to show your journey graphically; or, more relevant to this site, you can load a tracklog into a geotagging app, point it at a bunch of photos, and based on correspnding timestamps in the tracklog and the images themselves, the geotagging software can automatically add GPS data to the images.

Since the tracklog's timestamps may not correspond to exact moment an image was captured, many geotagging apps can interpolate positions.

I'm not an expert in disk controllers, but my understanding is the verification happens at the controller level - the OS hands data off to the drive controller to be written, and there's essentially a contract with the controller requiring perfect reads and writes. I'd say it'd be highly unusual for local copies to fail with silent corruption; I'd love to see a test demonstrating this happening. If such corruption is possible at this level, it's enormously unlikely given the massive amount of data reads/writes our machines perform every day without issue.

The only kind of copy I can imagine where the writes are significantly at risk of in-transit corruption is over certain network protocols, where the in-transit data may get corrupted without detection; the OS on the receiving end has no way of knowing this, and so it writes the data as-received from the network stack. FTP, for instance, is a historically common source of this kind of corruption, but with most network protocols its far less likely these days.

I'm skeptical that disk-to-disk copies are a significant source of data corruption but would love to see better data either way. As I said, I think the dormant corruption issues are far more prevalent. - files getting corrupted on disk due to uncorrected degrading of the disk/medium. These would be difficult to detect without either batch-based file comparisons (either to other copies, or to fingerprints like md5 digests) or filesystems which monitor and automatically correct on-disk corruption (ZFS, for instance).

- Roger Howard

Jake - absolutely, a simple (and nicely redundant) method for defragging data files is to copy to an empty disk and back. Defragging happens at the OS level today, within limits - usually only files up to a certain size, but this effectively keeps the OS itself defragged (and with optimum placement of files on disk - not the same). Frankly, I don't think defragging today is worth the trouble in the vast majority of cases - it's long been mainly a placebo, except in edge cases where you need to wring every bit of I/O performance out of a disk, such as with huge streaming writes like uncompressed audio/video capture.

As for the reliability of the defrag, there is verification during writes, so I don't think defragging (by most modern tools) is particularly risky in that regard; most file corruption happens silently during file dormancy (where it's sitting quietly by itself, and bits are randomly flipped because of a bad sector), not during activity such as copies where there is verification done at the controller/driver level to insure bit-accurate copies (if there weren't, we'd be in deep trouble every day).

Like so many other bits of old conventional wisdom, I think the need to defrag (or frequently repair) filesystems is largely gone today; as often as not, these tasks cause as many problems as they may fix. I do regularly filesystem integrity checks, and keep good backups, but I don't proactively defrag or repair disks that don't need it.

- Roger Howard

Peter - there are great GPS apps (I use MotionX) for the iPhone and other smart phones for generating tracklogs without having to take a shot periodically... the problem with smartphone GPS for this is the same as your Garmin, but worse - the phones will drain much faster with their GPS running all the time (and the phone prevented from sleeping), so I rarely ever use this except in the car or on my boat where I have DC power to the phone - my iPhone 3GS drains in maybe 2 hours (or less?), if I recall correctly, when using the GPS this way. In the field - hiking, camping, touring, etc - I just use a nice little GPS logger that I clip on my bag, which gets me a full day or so on 3 AAA's... I keep several sets of AAAs charged in my bag, so even if I forget to charge (or just can't) I'm good for 3-4 days; and, worst case, you can usually find a set of AAA's just about anywhere there's a shop.