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!
I haven’t written much about photo gear so far. My main working cameras are Canon 1DIIs. I love working with the 1DII but it’s not the best choice when the main focus of the day isn’t photography. Especially when you’ve got a bag of L lenses to go with it.
I’ve spent a lot of time playing with small point-and-shoot cameras for general goofing around and travel use. Unfortunately, pretty much everything I’ve tried so far has had at least one problem that made me hate using it. Either the camera was too slow (in terms of shutter lag), wouldn’t shoot raw or had generally horrible image quality. I’d been so disappointed with images from point-and-shoots that I started lugging around my 20D and a bunch of lenses. However, with a 1.6x crop, I’d often carry my 16-35/2.8L just to get wide angles and my 24-70/2.8L. Oh, and the 50/1.4. And other lenses. The end result was that I ended up juggling with lenses much more than I wanted to and carrying a lot more than I really needed to.
Recently, I’ve compromised and bought a Canon EF-S 17-85mm f4-5.6 IS USM lens for my 20D. The combination of the two is now my default “point-and-shoot”.
The size of the 20D and the 17-85mm isn’t truly ideal but it’s a lot smaller than my usual travel bag (1DII, 24-70/2.8L, 50/1.4, 135/2L). I’ve found it’ll fit into one of my existing small Kinesis bags, which is very handy. And, of course, the real bonus is that it takes relatively high-quality images that fit into my existing image workflow. And I can always smuggle my 50/1.4 along with me for shallow DoF and low-light work.
Downsides? Well, the 17-85mm isn’t without it’s niggles. I owned a Canon 28-135mm f4-5.6 IS lens for a while with my D60 and the 17-85mm shares some of the same issues. For starters, it’s not as sharp as any of the L zooms, especially at the wide end. It also suffers from fairly strong CA at the wide end. Shoot something like tree branches against a bright sky and the corners of the image have quite noticeable CA problems. Thankfully, this can be removed in Camera Raw but it’s definitely something to watch for. If you’re used to an L zoom, the 17-85mm has one other gotcha. Just like the 28-135mm, the zoom and manual focus rings are reversed from an L zoom. The end result is that I’m often zooming when I want to manually focus and vice-versa. None of these are show-stoppers tho’.
Used sensibly, it’s a fine walk-around lens. I’ve been surprised at the quality of the results, especially in the middle of it’s range. The IS is very handy and seems to work better than the version of IS on the 28-135mm. In fact, I’ve been very happy with IS on the 17-85mm and I’ve been able to hand-hold reasonably well down to about a 1/4 second.
The end result is that I’ve been able to take some camera gear along on trips that would have been awkward with a 1DII and lens bag and managed to make some images that would have otherwise passed me by…
I just updated a description of my current raw workflow on the Workflow 2.0 page. It’s got a few changes to the workflow described in Workflow 1.0, primarily driven by moving to DNG files and trying to pre-adjust as much as I can in Bridge before conversion to DNG.
Cheers!
I had planned to go out to Leighton Moss yesterday afternoon to do a bit of bird photography. However, after getting myself cosy and all set-up in a hide, I realized that the direction of the setting sun was going to make things really awkward. Which was a shame, as the quality of the light was beautiful. After a quick change of mind, I packed everything up, hiked back to the car and headed to nearby Arnside to see if I could catch the sunset.
The tide was just coming back in, which meant there was enough water in the channel to catch reflections and show the sky color. With a clear sky to the west, the sunset was one of those gorgeous, golden affairs that you sometimes get when it’s cold and still.
After some dithering on my part, I’ve enabled comments (with some protection) for your feedback pleasure. It’s an experiment to see if the current set of WordPress tools can deal with comment spam or not. The last time I did this, I spent ages managing comment spam so I’m hopeful that it won’t be as bad this time round…
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
The summer months are usually pretty tame for landscape photography. With the longer hours you get the choice of either getting up earlier (as early as 4am here in the Lake District) or heading out much later. And the light isn’t usually that interesting outside of a few key hours during mid-summer.
However, even by the usual summer standards, I’ve been lax in updating my online Portfolio. Never mind autumn, it’s now edging into winter here. Trying to make amends for this, I’ve added a few assorted updates (with more to come soon):
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!