I’ve started work on the 2.0 release of MetaSync. It’s a ground-up rewrite of the existing code to make it a bit more flexible and allow a few more features down the road. The basic list of new features for 2.0 are -

• Document-based application. You’ll be able to load and save common configurations, which should help keep things sane as the feature set expands.
• Broader filename matches. I’m beefing up the filename matching to allow matches other than simple stem matches to happen.
• Match pre-flighting. I’ve rejigged the matching to allow you to see what files are matched up before starting the sync. This should mean it’s easier to check that you’ve got the right parameters before pressing the “OK” button.
• Interface tweaks. I’m trying to clean the basic interface up and make it all a bit easier; especially the extension matching.
• Synchronization of sets. This could take a bit of work to make it really feasible but I’m going to have a crack at copying set info across.
• Metadata comparisons. This is something I’ve wanted for a while - the ability to compare the metadata for a match and show what’s different. Hopefully, in this’ll allow folks to catch situations where they might lose some metadata changes that they’ve forgotten about.
• Uh. That’s it.

So, just a few changes then.

For the real geeks out there, I’m also rejigging the code to use more Cocoa objects. This should give me a bit more flexibility when it comes to driving the fancier bits of the UI as I’ll be able to use Cocoa bindings to really drive things along.

Hopefully, I’ll have a beta available in a week or two’s time.

Cheers!

Scott…

One of the projects I’m working on this year is a long-term time-lapse photography movie for a straw-bale building project in Cumbria. The basic plan is to shoot time-lapse footage continuously over a period of 5 or 6 months and then cut it together to produce a short film of the building construction. The problem is that there just isn’t any software out there for the Mac that’ll handle long-term time-lapse.

In short, what I really need is software that’ll:

• Shoot between fixed hours every day (i.e. 8am until 6pm). Even better, it can shoot between a calculated sunrise and sunset time
• Shoot and organize basic images. If you’re running for 5 months you don’t need it to build a QuickTime movie on the fly.
• Allow movies to be built from subsets of the captures. I won’t use every frame captured every day but I might use all the frames for some days to slow down the action at busy times.
• Not leak memory. If this program is running for weeks at a time (realistically), then it has to be really well behaved.

Sadly, there really isn’t anything out there that does all this. The solution, as always, is to roll my own. I’ve been working for a while on an application called Epoch that I hope will help me run the long-term time-lapse. I cribbed the basic camera code from the TimeLapse example application in the Image Capture SDK (which needed serious cleaning up for actual use). It’s also my first Core Data application, which has thrown up some unexpected issues.

Anyway, if you’re interested in long-term time-lapse and might be interested in using Epoch then drop me a line and I’ll let you know when it’s available to play with.

Cheers!

A few weeks ago, I finally took the plunge and converted my entire raw image archive to DNG. This wasn’t a trivial decision to take given the sheer volume of images that are in the archive now but with iView MediaPro 3 supporting XMP information in DNG files, it seemed like the time had come.

Why convert to DNG?

• The obvious reason is to allow metadata for the images to be stored in the files without having to resort to using things like Apple resource forks or sidecar files. I’ve always been careful about not synchronizing metadata back to my raw images (treating them as read-only) which makes me more dependent on iView MediaPro than I’d prefer. As DNG files are really just slightly fancy TIFF images, the mechanism for writing back the XMP-encoded metadata is pretty well understood and robust.
• I have a plethora of raw image types. I’ve got CRW/THM from a Canon D60, raw “TIF” files from a Canon 1D and CR2 files from Canon 1DII and 20D cameras. It’d be helpful to have a common format for all my raw images in order to simplify how to export metadata to them.
• Better previews. This is a huge plus if your workflow includes Adobe Bridge, Photoshop CS2 and iView MediaPro 3. The Adobe Raw Convertor will regenerate previews for a DNG file if parameters, such as the white balance or exposure, are changed. It also generates previews based on crop or rotation parameters. This means that the iView MediaPro shows previews that reflect the current conversion and not just the parameters that were recorded when the raw image was taken. The result is a raw image catalog that looks a lot closer to the finished product.
• There’s definitely some future-proofing value in using DNG to store a vanilla, slightly-less proprietary version of my image data. I’m still archiving the basic raw images but it’s out of sheer paranoia rather than some lack of belief in DNG’s future.

The conversion into DNG was really very straightforward. A definite tip of the hat to the folks at Adobe who worked on the DNG Convertor application that’s provided as part of the ACR support. It’s not the fastest convertor I’ve ever used but it did one thing that completely won me over. It’s smart enough to traverse a directory hierarchy and build a mirror of that heirarchy using DNG files. Yeah! I feared I’d have to spend a day writing scripts to move the shiny new DNG files back into the right place. As it was, I just had to spend a day waiting for the DNG conversions to finish.

As for conversion parameters, I’ve gone with

• Medium sized JPEG previews
• Lossless compression
• Preserve Raw Image (i.e. no de-mosaicing)
• Embedded originals

The last option is one that I wrestled with but I finally decided to just bundle the raw images into the DNG files too. Why? Well, it keeps everything in one place and disk space is cheap these days. Out of paranoia, I also archive my raw files separately. Can’t be too careful…

I haven’t found any real downsides so far using my current workflow. My DNG images contain the correct and current metadata for them and I can see that information in Bridge and Photoshop CS2 without any problems. There’s really no difference to working with CR2 files except that I’m not generating XMP sidecar files for the raw conversion parameters now.

And that can only be a good thing.

Whilst using MetaSync last night, I realized I’d broken the exact match support (by adding some last minute debugging - that’ll teach me!). I fixed that and added a check to give a warning if it catches the problem described in “Can’t get every custom field of catalog ‘foo’”.

MetaSync 1.5.1 is available to download on the Software page.

Cheers

Ah. The joys and vagarities of Applescript implementations in vendor applications. There’s been a problem in the iView Applescript implementation for a while and, as someone has just run into it again, it’s probably worth writing it up.

If you view a subset of an iView catalog (for example, you click on a specific location in the “Organize” pane), you’ll spot that the title of the catalog changes from

to

So far, so good. Unfortunately, this seems to hobble iView’s ability to find the catalog from Applescript with the name “DNG”. In fact, it doesn’t even seem to work if you try the full name. And, to add insult to injury, if you ask for a list of all the open catalogs when they’re being displayed as subsets, you get the base name back.

So, what does this mean? Well, it means tools like MetaSync don’t work if a catalog you want to work with (either as a source or destination) is showing a subset. You’ll get the error shown in the title of the post if you try it. The fix is to always do a “show all” before attempting a sync between catalogs.

I’ve reported this to iView - hopefully it’ll be fixed in a release fairly soon.

I’ve just released Metasync 1.5 which allows metadata to be copied between media items in iView MediaPro catalogs. This version of MetaSync works with both iView MediaPro 2 and iView MediaPro 3. It also has a number of new features

• Updated user interface
• Support for new iView MediaPro 3 catalog fields
• Numerous bugfixes and extra sanity checking from the MetaSync 1.2 release
• There’s now a bit finer granularity on metadata annotations copied. I’ll be adding to this in the next release but this is an initial start.
• Logging support (both to a local application log and to a file)

I’ve also rewritten a lot of the core of the application to take advantage of Applescript Studio features that weren’t available when I first wrote the application. This has simplified the code a fair bit and allowed a few weird problems to be fixed as a result.

If you’re using iView MediaPro 3, you’ll need to upgrade to iView MediaPro 3.0.1 if you’re going to use MetaSync. Problems with the Applescript support in the original 3.0 release mean that it’s essentially unuseable for scripted applications (the litany of Applescript problems in 3.0 was actually fairly depressing).

The 3.0.1 release fixes many of the problems in 3.0 and seems to be far more stable.

Enjoy!

It appears that the 3.0 release of iView MediaPro didn’t get a particularly hard regression test on it’s Applescript interface. I’ve already found a couple of bugs that affect MetaSync and the Automator Actions. In particular, MetaSync is very unhappy with 3.0 because of a problem with copying annotations from one record to another. There’s also a problem with the “shutter speed” field in the Applescript dictionary for 3.0 which causes MetaSync to barf.

The end result is that I’m going to try to work around some of these problems and release a new copy of MetaSync for use with 3.0.

iView just announced iView MediaPro 3.0 at the PhotoPlus Expo in New York. I’ve downloaded a beta copy of 3.0 for testing and to see if there’s anything new in the 3.0 Applescript interface that’d be worth adding an action for.

I just posted the 1.1b release of the Automator Actions. There aren’t any functional changes to the software over 1.1 but this release does fix a few annoying bugs over 1.1. If you use the Import Files or New Catalog actions, I’d definitely upgrade to 1.1b.

Enjoy!

I just released the 1.1 version of the iView MediaPro Automator Actions. There are 8 new actions as part of the package -

• Get Specified iView MediaPro Catalog
• Rebuild iView MediaPro Items
• Save iView MediaPro Catalog
• Set Categories For iView MediaPro Items
• Set Event Date For iView MediaPro Items
• Set Keywords For iView MediaPro Items
• Set Orientation For iView MediaPro Items
• Set People For iView MediaPro Items

and 3 actions got new twiddly bits added to them

• Get Selected iView MediaPro Items
• Import Files To iView MediaPro Catalog
• Set Annotations For iView MediaPro Items

The actions are available for download now from the Software page. There’s a basic writeup on the new actions in the Articles section.

Enjoy!