Although Sunday’s annual Borrowdale Shepherd’s Meet had been cancelled, I knew the fell run was still happening. A book I’d been given last Christmas contained Patrick Ward‘s great wide-angle photo of the nearby Wasdale fell run, and I wanted to exploit the combination of the D700 and my 17-35mm f2.8 lens in a similar way. Wide angle shooting is the D700′s biggest plus for me so far (funny how easily you can forget what wide really means).

These blokes, some young and others in their 70s, race up to the top of Borrowdale‘s 750m / 2500ft Dale Head fell and the fastest ones are back in Rosthwaite village in just about 45 minutes. A “fell”, if you’re wondering is the Lake District word for the hills, and is of Norwegian Viking origin. So, like the word “dale” for a valley or “thwaite” for a clearing, the names reveal the region’s settlement history – nearby Keswick’s kaese is from the Norse for cheese and the wick indicating a farm.

I already knew the route and chose a spot just above a gate where I knew the runners would have to pass – it took us 45 minutes to get up there – and where I would be able to scoop up the runners and the valley.

The previous day, at a Sealed Knot battle, I had played with the D700′s focus tracking, leaving the focus mode on Continuous and the focus area on Auto – “the camera automatically detects the subject”, says the manual. The D200 had a similar feature which I never found very effective, but during the battle I let the D700 identify a fast-moving subject and track it across the frame. It was one of those bloody hell, it’s really doing it, road-to-Damascus moments. So I decided to try it for real with the fell run, and it worked like a dream, snapping focus onto the runner and tracking him perfectly. Previously I would have worked in 3 phases – focus, recompose, shoot – but now the camera was allowing me to compose and shoot when the subject had reached where I wanted him to be in the frame. As a result, I got loads of these shots of the runners on the way up and then leaping over a gully on the way down.

Another D700 aspect is that I think the camera has an Auto ISO mode somewhere. If so, I didn’t use it, and these pictures were mostly taken at ISO 800, with some at 400, and others at 500 or 640. In other words I was always thinking about the ISO as well as the aperture/shutter speed combination for enough depth of field to show where they were running while also freezing the action (in this case generally f7.1 and speeds over 1/500). Just as the D700 handled the focussing and let me concentrate on composition and timing my shot, the quality of the D700′s higher ISO captures make me wonder if I should have chosen Auto ISO and eliminated one leg of the ISO/aperture/speed triangle. Scary perhaps, but certainly not absurd.

As an experiment, I’m displaying the pictures here using SlideShowPro. As usual, they were processed in Lightroom and I then used File > Export and the Lightroom to SlideShowPro Director plug-in to upload them directly to a new SSP Director album. The beauty of this solution is that it’s quick, a few clicks, and I can use the images for multiple purposes – SSP Director holds the images at full size and generates the output size on demand. Here I display the pictures in this post, inserting an IFRAME with a web page which calls up that album in a Flash movie (that page is PHP and accepts the album code as a variable). Alternatively, SSP Director could supply different-sized images for my existing web galleries and also for my Flash site. If my Flash site scaled images to fit the user’s screen size, SSP Director would automatically handle that for me, caching the pictures on the server via ImageMagick or GD. Hopefully that’s an interesting detail – at least for some of this blog’s readers! In short, it’s a very efficient Lightroom-web workflow and not as complex as it might sound.

One reason why I still use iView rather than switching completely to Lightroom is because I prefer its HTML web gallery templates. iView takes about a third of Lightroom's time to output a big contact sheet style web gallery of say 100-300 pictures because it uses my DNG files' embedded previews, while Lightroom seems to insist on re-rendering the raw files when you're previewing the gallery in Web, again each time you change an output setting, and then again when it actually starts generating them.

A second reason is because I can edit iView's HTML-based templates much more easily. Going back to Lightroom 1.0, the original XML and XSLT templates appealed to the geek in me, but I always felt they were misguided, a developer's solution which demanded a far higher level of skill than even the IT-minded photographer was likely to possess. While you can inch up the HTML learning curve, tweaking templates in small yet rewarding steps, XML and XSLT customization require much more experience. That aspect didn't worry me too much because I used to implement XML and XSLT solutions professionally, but iView works perfectly for my contact sheet galleries and my main site is powered by an online database and some iView scripts. So I never felt customizing the Lightroom XML and XSLT templates was worth the effort. I was rather surprised, impressed, that anyone else bothered.

That thunderous lack of interest cascaded over to the Lua-based templates or “engines” which arrived with Lightroom 1.3. And at the time I was much more enthusiastic about learning Flash and ActionScript. In fact I still am - once I actually launch the Flash site, I'll update it via SlideShowPro's excellent Lightroom-SSP Director export plug-in. That's one click to run the Lightroom export, one click to activate the new web gallery. Beat that, Lua.

Still, I'm really glad to see Sean McCormack is doing a bite-sized series on writing Lightroom web engines, starting with Anatomy of a Lightroom HTML Gallery:

Lightroom HTML galleries used to be written in a mix of XSLT and XML. The simpler coding in Lua makes it a pleasure to create HTML galleries with. You can write Flash galleries in Lua, but because IE doesn't allow plugin loading on PC Lightroom, you can't see them in the preview window. Hence 3rd party Flash galleries use the old method for cross platform compatibility.

Lua galleries were introduced in Version 1.3 and have matured somewhat with V2.0. The new syntax is much tidier and more compact. In fact Matthew Campagna shaved 500 lines off one of his galleries for version 2, and my new website in a gallery LRB Portfolio managed close to that also.

So what comprises a Lua Gallery? Well the absolute minimum a gallery can contain is 3 files: galleryInfo.lrweb, manifest.lrweb and a HTML file. Let's look at them in a little more detail….

And part 2 is over here. You never know, now I've cracked Flash and ActionScript, this might even encourage me to learn Lua at long last.

Other resources for Lightroom Web:

• Lightroom 2 SDK now includes the web engine, as well as export and the beginnings of custom metadata
• SlideShowPro Director is an online management system for web photo galleries and powers my new site
• SSP-Director plug-in for Lightroom makes updating it a dream
• SSP for Lightroom is their standalone web gallery engine
• GalleryMerger is a tool for hassle-free maintenance of standalone SSP multi-album galleries
• The Turning Gate
• Lightroom galleries (with added exclamation marks)

OK, I tried it out. After my little joke about Ahmedinejad and his centrifuges, I should say that this little toy didn't work 100% properly first time…. The Lightroom side of it worked perfectly, and the plug-in also created a new album (a grouping of pictures) on my server, but it didn't send the payload - no pictures were uploaded. OK, so I hadn't bothered updating Director 1.20 beforehand, but it should still have worked.

Once I'd updated Director to the latest 1.22, the process was as slick as can be. You select your images, begin an Export using the SSP export plug-in, and press Export. A few minutes later and it uploads your files to the server and takes you to Director's control panel in your default browser. You're ready to go. Very neat.

The one thing I don't like is not having control over the sizes of file that are uploaded. I would prefer to upload at the size at which I anticipate and set the sharpening option accordingly. Instead it uploads full size files, making the upload slower, taking up more disc space, and invalidating your sharpening choices.

UPDATE - It's easy to edit the plug-in and gain access to the file sizes and quality settings.
UPDATE 2 - Now you don't have to do so because a bug fix for the plug-in also restores your control over file sizes and quality settings.

While the existing SlideShowPro for Lightroom generates individual web galleries, when your site consists of multiple galleries you have to do some manual editing of xml files which (a) not everyone can do (b) is still manual work for those who can do it. It's much more efficient to power a site with an online database.

That's where SlideShowPro Director comes in - it's a database which supplies the data to SlideShowPro. Previously Director let you import Lightroom's SlideShowPro web galleries, which worked but was still a bit of an effort, but now SlideShowPro has released a Lightroom export plug-in for SlideShowPro Director. This is an export plugin that allows you to upload pictures directly from your Lightroom library to an existing or new album inside SlideShowPro Director. It works with both the self-install version of Director 1.2, as well as their hosted subscription accounts (more here).

Just like President Ahmedinejad unwrapping a shiny new delivery of centrifuges, I can't wait to try it on my still-hidden Flash-based site.

Just refreshed the site with a few new pictures - the new gallery is again all new stuff, as it should be, while the wedding gallery includes newer work as well as some old favourites.

Both galleries are Flash-based and use the excellent SlideShowPro. I'm using the SSP for Lightroom web engine purely to generate the content, the jpegs and the xml file with all the filenames and captions. But they're displayed via my own Flash movie which is based on an SSP for Flash component. This approach means I can quickly create new galleries to add to existing pages, while the power of ActionScript lets me show extra information like the gallery's name and description. As my long-threatened Flash-based site uses the same SSP galleries, the transition - if it ever happens - should be painless….

I recently added some Flash-based galleries which are powered by the SlideShowPro for Lightroom engine, but I found that they had truncated my site's DHTML menus when the galleries were viewed in Firefox (my preferred browser on PC and Mac). These menus were “Spry” objects added in Dreamweaver CS3, though I suspect other similar menu systems would also be affected, but I already knew you had to take care with Flash and DHTML layers, so it only took a little Googling before I had a solution. This was to edit the swfobject.js script, which adds the SlideShowPro Flash object to the page. After the embed tag, add wmode=”transparent”. I am not 100% certain that this is the right solution - but seems to work.

So I spotted the same problem straight away when I read Michael Clark's post on SSP and followed a link to his web site. But something else came from our email exchange - Michael mentioned he was about to regenerate all his SSP galleries so they would start automatically.

The thing is, it's not always necessary to regenerate the SSP galleries if you only want to change some of the SlideShowPro movie's options. When you first generate an SlideShowPro for Lightroom gallery, it outputs a file called param.xml which contains many of the options that you set in Web's right panel. Hacking this file is a lot quicker than regenerating the galleries. In this case, I happened to know that automatic starting was a simple matter of changing displayMode=”Manual” to displayMode=”Auto”. You can generally guess the parameter options by looking at Web's right panel, but hopefully they'' soon by documented in the manual (as they are in the SSP for Flash manual). This just gives me another reason to like SSP.

Getting my Flash-based site up and running is taking me more time than I'd hoped. Now there's a surprise. Actually, that's not quite fair - within about 3 or 4 days I had written something decent, but I am being a bit ambitious and would like to integrate this site's text-based content into the new Flash site. While Flash will read and display external HTML files, format them with CSS, and read the database powering this blog, its text rendering could be a lot better and scrolling text could also be more elegant. So I've been proceeding at a slower pace, and picking up more Flash skills on the way. There's no rush, and there have been other things to do.

The new site will display images via a SlideShowPro component and in the last month SSP for Lightroom has been launched and is a real snip at $25, or just $10 for those of us who already have the Flash component. It is rather slow on a Windows box, but the developer is investigating the issue and I'm sure it'll be fixed before too long.

To test SSP for Lightroom, I've used it to add a new gallery to the site. Putney Debates is a set of pictures I took back in October when a Sealed Knot regiment helped open a permanent exhibition at the SW London church where the debates took place back in 1647 (read more). I wanted to display the movie within my current site's HTML and, since the SSP documentation was as clear as I'd expected, it was a trivial task, just minutes, to adjust the HTML. So SSP for Lightroom walks away with a golden “Beardy”.

News that the excellent SlideShowPro Flash gallery is coming to Lightroom:

With that, there will be two versions of the plugin - a “complete” version that ships with everything a new customer (without Flash or SlideShowPro) needs, and an “incomplete” version designed for existing users of SlideShowPro. For the “incomplete” version, you simply publish a SWF containing the component and add it to the SlideShowPro for Lightroom's plugin folder. Your “incomplete” version will then be “complete,” and ready to go.

Both versions will be purchasable, with “incomplete” obviously costing less than “complete,” but we haven't figured out exact pricing yet. Expect more information on that, including screenshots, in the near future!

It'll be interesting to see how well it's done and how much the “incomplete” version costs. Such a gallery engine can already be written by any SSP owner who has the right knowledge. As I've adapted SSP for iView, I'm rather surprised some third party hasn't released one already.

I've recently been designing a Flash-based site. It's the biggest Flash project I've ever undertaken and I'm writing it from the ground up, apart from using an off the shelf component to display the pictures. I've settled on the SlideShowPro photo gallery which I can readily populate from iView with XML or from an SQL database. The site is also going to include large amounts of text, even the blog, and I have been really surprised at how little Flash CS3's text handling has progressed since version 5 when I last worked much with it. I want the visitor to be able to scroll text, or implement fading in, but you still have to remember the subtle and needless differences between static text, dynamic text and input text boxes, or between symbols that are movie clips and those that are graphics. It might be easier to do it all with code, or maybe I should have tried doing it in Silverlight?

Some resources:

• SlideShowPro - web gallery
• Soundslides - alternative to SlideShowPro, used by Magnum here
• Simpleviewer - v popular web gallery
• kirupa.com - resources
• Flashloaded - components
• actionscript.org
• Deep linking - technique
• Adobe Developer Center