These are all photographs I’ve taken in my beloved Lake District over the last few years and reworked with a new effect which I found pretty addictive but can’t disclose, not yet anyway. You may of course say it should remain that way, but I rather liked the results and it is my party….

As usual they are being served from my SlideShowPro Director content management system, but I recently heard that they have discontinued the Slidepress plug-in (why is explained here). So instead I am using their Publish mechanism, copying code from Director and pasting it in WordPress. I’m not sure it’s totally reliable and WordPress has a habit of correcting – or rather deleting – the code.

Royalist chaplain at the English Civil War re-enactment by Sealed Knot at Shaw House, Newbury (site of the 2nd battle of Newbury 1644)

SlideShowPro’s newly-released Director WordPress plugin is a handy way to call individual images like this from Director and display them on a WordPress page.

In case you haven’t been following our news lately, this plugin allows you to insert images and videos from SlideShowPro Director (self-install or through SlideShowPro.com) into WordPress blog posts/pages. You may browse all your uploaded content while editing a post within the WordPress control panel and choose how you’d like your images to be sized, cropped, and aligned. For video, the plugin embeds H.264 videos using the HTML5 video element and falls back to the (Flash based) SlideShowPro Player if the video is a different codec or the browser can’t display the video on its own. When used with H.264 videos, the latter gives you a hassle free method for deploying videos that will display across all desktops and mobile devices.

Very slick for a free add-on !

What you’re seeing here is SlideShowPro’s SlidePress, a WordPress plug-in that uses SlideShowPro to display images drawn from content management systems such as – in this case – SlideShowPro’s Director.

As noted above, it is a WordPress plug-in. Set-up was almost entirely through WordPress’s Plugins section and it went right first time – always a good start. The only thing I had to upload was an up-to-date copy of the SlideShowPro swf file.

To add a slideshow to a post such as this is a quick job. You just click the plug-in’s button in WordPress’s Edit Post toolbar, and then tell SlidePress which set of images to load. Here I pointed it to Director, but you can also draw images from Flickr or other data feeds. Publish the post and you’re done.

Each slideshow or “gallery” can have its own styling. Always in WordPress – you never have to mess around with Flash – you click an “Edit Style Settings” button and then gain access to all SlideShowPro’s parameters. So you can choose effects such as the Ken Burns panning here, or configure the navigation buttons to prevent full screen use. You can even set image sharpening through WordPress.

To gain an idea of the workflow from Lightroom, you’d use SlideShowPro’s export plug-in to send pictures to Director, and then compose your post. That easy.

And apart from SlideShowPro being pretty slick, it’s also free if you’ve got already got SlideShowPro Player. Flash has taken a bit of a knocking over the last year (I’d be interested to know what iphone/pad users see here), but I’m very impressed.

I don’t believe for a second that Apple’s failure to support Flash on the iPad is for anything other than their own commercial self-interest. It was in their power to be so pigheaded, their apologists will always back their decisions and puff out a smokescreen of technical justifications, while all the workload and changeover costs fall on others’ shoulders. Whether that’s another greedy corporate that has to re-engineer  its video streaming technology or a photographer forced to ditch an expensively-designed Flash-based web site, it’s someone other than Apple who picks up the tab for their failings. The good thing though was that Jobs’ mendacious thoughts on Flash were delivered with such “sod you” finality that you were left in no doubt about Apple’s decision. As a belated and not-total convert to working with Flash, I shrugged and put on ice any effort to learn any more ActionScript, but I did feel sorry for the victims of Apple’s actions – not least the industry of Flash coders whose business models it imperilled.

It’s been fascinating to see the response of Flash developer SlideShowPro. For my needs the jewel in their crown hadn’t been the Flash component for which they are best-known but the Director content management system which could supply pictures and video to the Flash front end. Director meant you could readily have a site based on Flash or on HTML – or both if you’re as daft as me – and implement a very efficient workflow from Lightroom. So SlideShowPro’s Flash new alternative SSP Mobile is built on Director and is going to make it easy for those with SlideShowPro Flash-based sites to publish to iPads. As it says here:

Director 1.5 (which will be a free upgrade for all Director users) will now allow you to embed a slideshow / photo gallery of any album or gallery without requiring any other products. You simply kick-up the “Embed slideshow” window from inside an album or gallery, choose a style, enter a size, and modify some of the player’s main options. Click “Copy embed code”, paste your clipboard into an HTML document, and you’re done! Desktop users will see the Flash version, while mobile clients (including iPad, iPhone and iPod Touch) will see a clickable poster that leads them to the mobile player.

And yes, if you’re already using Director, it’s a free upgrade. Nice work.

Here’s an example of why I like SlideShowPro and particularly its Director image management database.

Just a week ago in this post a user asks SlideShowPro about using GPS data in images he’s uploaded to Director, and within 5 days they’ve updated Director and added GPS Support.

This is partly based on code by Dave Finlayson, another fan of Director’s API, who posted his code while I was enthusiastically breaking my Director installation (by using Lua’s “–” rather than PHP’s “//” to comment out some code….)

When you click the pins, you’re seeing the same image as on this page. Just as it does with that page’s thumbnail and larger images, Director takes the high resolution image on the server and resizes it on the fly (workflow diagram here).

SlideShowPro Director Connector is a WordPress plug-in written by Swiss-based photographer Ruggero de Pellegrini. It’s a nice piece of work that lets you access Director images directly from the WordPress editing window – just compose a blog post or page, click a button, and choose your picture from Director – and you’re done. It adds code like this:

Here the number 2389 refers to an image that I’ve uploaded to Director, and there are alternative codes to display images as a grid, but you don’t need to know much more than how to install the WordPress plug-in.

Documentation could be better. There are some screenshot JPEGs in the plug-in zip file, and there are some details of the shortcodes you need for inserting image grids or displaying single pictures. That’s fine for those of us who think they know what they’re looking for, but others will need step by step instructions. For instance, the WordPress page template needs links to Lightbox, since they aren’t added by the plug-in. That took me a minute or two to figure out, but should be made obvious in the step by step installation instructions. Page formatting is also a little awkward and I suspect Ruggero would acknowledge that this aspect is unfinished. I might understand how to modify the CSS stylesheet so the thumbnails have nice big borders, and I might also know where to look so the thumbnails don’t crop – but would those without the same sort of experience? So I do see some rough edges, but I also see something that’s got a lot of potential and is very close to being a great solution.

So, I’m having another go at WordPress. The idea is to manage all the site’s text content with a single tool, replacing the blog’s current reliance on the rather-aged pMachine and my use of Dreamweaver for other text pages. I also want to make changes of emphasis, for example integrating in my Twitter posts which would once have become shorter blog items (even if that does mean bringing in the tweets that are more like IM or social networking). Some longer blog posts would work better as articles – for example my ever popular post on the perils of multiple Lightroom catalogues, or those where I’ve used the blog for plug-ins. WordPress is obviously suited to blog postings, and its Pages feature will accommodate my need for longer articles. So far, so good – I’m pretty impressed with WordPress’s flexibility.

A few things about what I’m doing. I decided I wanted something that looked lighter and more open – not my Joy Division default with everything “contained” within a centred, rectangular layout. I liked how the Arjuna theme from SRS uses rounded rectangles around sidebars and titles, so in the last day or two I’ve customised the theme extensively.

So my (Connemara) theme varies the header background for different site areas, and my tweets are shown in the blog sidebar. The photo galleries are done using WordPress pages which get images directly from SlideShowPro Director. These pages have a custom field called “album”, and are displayed using a custom WordPress page template which retrieves the album code (using the get_post_custom_values function) and uses Director’s API to add images to the page, resized and sharpened by the server. PHP then writes the thumbnail grid and CSS on the fly, and the Lightbox JavaScript is also integrated. I do love my PHP.

What do you think?

SlideShowpro Director 1.4.1 has been released and has watermarking:

Director 1.4.1 includes new support for built-in watermarking, allowing you to upload an image (transparent PNGs work best) to use as a watermark, then Director composites that image on your original content when it creates the optimized copy for your slideshows. You can define as many different watermarks as you like, and change what watermark is applied on a per-album basis. You can also control the positioning of the watermark and its opacity when composited with the image.

Now all I want is that it doesn't strip metadata (there's a hack).

Following up a comment about the new Flash alter-ego, I noticed that I wasn't as protected from hotlinking as I had thought. Rather complacently, I had noticed my SlideShowPro Director (the content management system for all the site's pictures) had got both an htaccess file and a crossdomain.xml file which limits which allows you to stop other domains accessing the pictures, and I'd assumed that would be enough. Hm.

The brain hadn't clunked on to thinking to check what was in Director's htaccess file - such as a “RewriteEngine Off” line which overrode the site's overall htaccess file and its “RewriteEngine On” anti-hotlinking instruction. And I hadn't looked into what crossdomain.xml file would do, or rather not do. It'll stop other Flash movies serving pictures from my server, but wouldn't stop hotlinking in HTML. So, with Director unprotected by its htaccess file, anyone who could find a picture's URL could hotlink to it.

It's not too difficult to fix, though I've little doubt something else will break. See this thread and also stopping Director from stripping metadata.

Anti-hotlinking images

I don't want to start a war with whoever hotlinks an image, so this is the image I usually serve via the htaccess file.

When I have been a bit more irritated, I use an alternative image. While one could serve up something nasty, I prefer a 1 pixel high 1800cm wide transparent gif. It should blow the offending site's layout but will be almost invisible and force the other person to put time into tracking down why his site suddenly looks crap. And as they'll never be quite sure you really meant it at them….

I noticed the other day that in the darkest corners of my hard drive are some Flash files dating back to 1999. That I've been dabbling with Flash for ten years was a surprise, but these were Precambrian era fumblings and very primitive life forms indeed. As the second Christian Millennium stumbled onwards, every so often I'd come down from my tree and have another go - I remember being quite interested by generating content on the fly from PHP - but working with Flash never ignited my interest, and I fully shared the distaste that many people have for it.

Certainly one thing I always had against it, apart from its use for ads and crappy music, was that I do have this innate bolshiness about photographers having to use Macs, switch to Canon, or have Flash sites. You can have great-looking sites, and have protection against image misuse, without ever going Flash. Was true, is true.

A more substantial objection was to using Flash for a photographic site with lots of text. You see so many Flash sites that remain slick and impressive, but which are clearly out of date and display exactly the same pictures as the day the site's designer had billed his work. No real thought ever seemed to go into the day - a lot sooner than you'd think - when the photographer would have new work to go online or wanted to update the text. Even once it became possible for Flash to load images on the fly, Ben the “I'm a Mac” designer (or the long-gone assistant) would be really into graphics and animation, but have little clue about databases and coding. There always seemed to be built in contradictions between a site's appearance and its need to evolve. Eventually the photographer would need to find a new de$igner and start the time-consuming and costly site building process all over again. Karl Marx, and the Marx Brothers, would be laughing in their graves.

I'm not sure when my attitude to Flash changed. And it still hasn't changed 100% - part of the reason why I've been in no hurry to reveal or work on my Flash site. It's been a steady tipping of the balance. While Flash never lit any lasting flames of imagination, I kept rubbing those sticks together, playing with ActionScript 2, linking movies to databases and XML. Eventually I wasn't learning from scratch each time, so I decided I'd learn ActionScript 3. And once that made sense, I decided to learn Lua for Lightroom. Clearly some people are happier always pushing rocks up mountains.

One motive for my changing was my slowly-growing reliance on Lightroom for DAM rather than Expression Media. For a few years, I'd powered my web site from a self-written database which I updated from Expression Media using some VB and SQL scripts. Adapting that process for Lightroom wouldn't have been hard - in fact it seemed too boring.

Also in Flash's favour was my lack of enthusiasm for the fancy things you can now do with HTML and CSS. I've always liked CSS, but tricks with list items and floating div tags… been there, done that, and they just leave me cold. What's more, I am an optimist but am also certain that sooner or later such things will fail, somewhere. Unless you're lucky, your fancy HTML + CSS + JS will look ever-so-slightly wrong in Internet Explorer 8, or it'll crash Firefox 3 on the Mac. Give me PHP or Flash which if it fails, does so everywhere.

Each time I thought about it, the idea of making a Flash movie for just the pictures wasn't exciting enough. I wanted to be more ambitious and include all the site's content, which meant figuring out how to make Flash load external HTML and XML files, and style the text with external CSS files. As time wore on, I also wanted a wet floor effect too, drag and drop palettes…. And all without being too flashy.

These were my objectives (or post facto rationalisations):

• Must not look like Lightroom - a cliche nowadays - but it must integrate well with it
• It can't be white - too Mac - but I also wanted a change from my grey Peter Saville c1980 default
• Images would be displayed by SlideShowPro with ThumbGrid
• Colour managed Flash in any browser with Flash Player 10
• All ActionScript 3 - though 3's awkward in many ways, I couldn't see the point writing something new in 2 (applies to Lightroom galleries too)
• Use Flash to do fancy stuff that's hard or impossible in HTML - drag and drop, transparency, cross fades, wet floor effects
• Managed images and galleries/albums via an online database - SlideShowPro Director - which could power both Flash and HTML sites
• Generate menus dynamically - uses PHP to write XML and get galleries/albums from SSP Director
• Allow “deep-linking” directly to content - this is done using SWFAddress and ActionScript
• I wanted a gradient-filled background but which would fill the whole browser window, whatever its size, which meant it needed more ActionScript
• External Flash movies - even video - loaded when required
• Text content to be supplied by external HTML (supported tags) and styled with CSS, also stored outside Flash
• Existing blog to be displayed in Flash….

OK, now the Twitter-style punchline. As if the excitement of Windows 7 and Lightroom 3 Beta wasn't enough, today I release my Flash site, beta.

Like many of the features in LR3-beta, Publish Services seems a small step forward. Its obvious use is for those who use services like Flickr, Smugmug etc, and before long I hope SlideShowPro's Director can also be included. But it isn't just about the web - there's also the Hard Drive option.

This lets you maintain folders of images on your own computer, and opens up a number of interesting workflows.

I found it came in very handily for a Blurb book I was preparing in InDesign. The images were all raw files, which InDesign itself cannot use, so ordinarily I would have needed to output a large number of TIFs of certain dimensions. If I then saw that an image on the page needed further adjustment, I'd need to go back to the raw file in Lightroom and generate the TIF again. Equally, if the caption needed changing, it would be inefficient to edit it in InDesign and copy the text to the original in Lightroom.

The solution was to publish folders of TIFs - one folder for each of the sizes needed for the book layout. Now, whenever I wanted it was little effort to adjust images that were already in the layout and change their captions “upstream”. Periodically I'd tell Lightroom to publish the updated TIFs of the correct sizes and to the folders InDesign was expecting. Slick.

For anyone with Flash on their website, or those of us endlessly putting off the day of launching our Flash sites, last week there was an interesting post on Google's webmaster blog. The title Flash indexing with external resource loading may not be too catchy, but the post quickly gets to the point :

We just added external resource loading to our Flash indexing capabilities. This means that when a SWF file loads content from some other file - whether it's text, HTML, XML, another SWF, etc. - we can index this external content too, and associate it with the parent SWF file and any documents that embed it.

On the horizon for a while,this is enabled by default, but if you don't want it you can block it with robots.txt. What's more Google don't mention any caveats such as the version of Flash - on the contrary, they say it'll work regardless of Actionscript version.

Via SlideShowPro.

SlideShowPro's latest update is a bit more significant than most - it introduces a “Ken Burns” pan and zoom effect - so I'm downloading it right now. A Lightroom version of this is here now.

… now includes the latest images that I've uploaded to the site.

While one thinks of SlideShowPro as a Flash component, their SlideShowPro Director manages your web site's content and serves up different sizes of images to both Flash and regular HTML pages. Here I'm using a few features in conjunction:

1. The Lightroom-Director export plug-in makes it easy to upload 2000-pixel JPEGs directly from Lightroom
2. I've a smart album in Director which automatically displays new pictures in the New Photos page's Flash movie
3. My Flash site also shows the pictures at the size it needs, so it'll be easy to maintain both Flash and more Google-friendly HTML content
4. Here on the blog page I'm using the Director API to show images at 150 pixels wide (follow the more link for my commented code) - Director generates all these different sizes as required

While the long-fabled Flash site is moving forward again, its continually being almost-ready has had a pretty-constipating effect on the old-style photo galleries. So I've now begun replacing them with Director-driven galleries which means a load of newer images are now in the American Civil War, the Napoleonic era, the 20^th century, and some such as this one of Hastings 1066 in the Medieval gallery. Time travel beckons….

This is PHP5:

     include('../flash/flash_ssp_director_api/classes/DirectorPHP.php');
     $director = new Director('key', 'director url');
	 $format = array(
       'name' => 'thumb',
       'width' => '150',
       'height' => '150',
       'crop' => 0,
       'quality' => 75,
       'sharpening' => 1
    );
	$director->format->add($format);
	$album = $director->album->get(29);
	$contents = $album->contents[0];
	$i = 0;

//create an array to hold the latest images
	$ssp_latest_imgs = array();

	foreach($contents as $content) {
		if ($i <=  			{
			$caption = "Recently uploaded : " . str_replace ("+", " ", $content->iptc->caption);
			$caption = str_replace ("%2C", ",", $caption);
			$imgcode = '';
//add the current image and HTML to the array
			$ssp_latest_imgs[$i] = $imgcode ;
			}
		$i = $i + 1 ;
	}
//now display an image - in this case the first one
echo $ssp_latest_imgs[0];

//now display an image - in this case the sixth one
echo $ssp_latest_imgs[5];

I'd been holding off upgrading SlideShowPro Director until I had enough time to do so properly, but I was itching to try the smart albums included in version 1.3.

Here I've set my new photos section so it's now calculated automatically. I always find that any “latest photos” section soon becomes static, or involves some duplication of effort. So this section now shows photos since a certain date, but excluding those in a couple of albums which are reserved for this blog. As I already use Director's Lightroom export plug-in, which makes adding new pictures a moment's work, and smart albums mean I could update a number of albums in a single export. They're not terribly sophisticated yet, and target far fewer fields than in Lightroom, but are a great start.

If you own SlideShowPro, you get access to lots of examples including the wet floor effect. While I'm sure some will dismiss the look as frivolous or simply too popular to be original, it's so ubiquitous nowadays because (1) we or rather computers can create it on the fly and (2) it does add interesting depth to what would otherwise be a flat, two-dimensional screen. What's wrong with a bit of trompe l'oeil?

Unfortunately for those who've decided to move wholly to ActionScript 3, the SlideShowPro guys haven't yet had time to post an updated version of their AS2 example. No worries - they're working on other good stuff such as smart albums (can't wait).

Adobe have however posted a generic solution for creating movie clips with reflections in ActionScript 3.0 which includes a class file. As this sneak preview of the fabled colour-managed, xml- and database-powered, AS3-coded, modular-build and still-to-be-unleashd Flash site shows, the reflect.as class can be adapted relatively easily to specific requirements such as SlideShowPro. If you want to read how….. 3 elements are needed - calling up the reflect.as class, using onImageFormatEvent to trigger repositioning of the reflection, adding a repositioning function to reflect.as.

OK, my ssp component is in a movie clip called sspGalleries, so….

Calling up that Relect.as class in my movie:

import com.pixelfumes.reflect.*;
var r1:Reflect=new Reflect({mc:this.sspGalleries,alpha:60,ratio:30,distance:0,updateTime:0,reflectionDropoff:1});

Next I use the ssp as3 onImageFormat event to reposition the reflection - important because the vanilla reflect.as class will create a reflection beginning at my ssp movie clip's bottom edge. That's no good - it leaves a gap - if my image isn't as tall as the ssp component. So I use onImageFormatEvent to get the dimensions and position of the currently-displayed image within the ssp component.

function onImageFormatEvent(event:SSPImageFormatEvent) {
	if (event.type=="imageFormat") {
		//trace( event.h + " " + event.y + " " + this.sspGalleries.y);
		var reflectionTop =  event.h + event.y + + my_ssp.y ;
		r1.reposition(reflectionTop, my_ssp.height) ;
	}
}
my_ssp.addEventListener(SSPImageFormatEvent.IMAGE_FORMAT, onImageFormatEvent);

What this does is run a function called reposition which I added to the reflect.as class and which takes two variables. One is needed for images which are not as tall as the ssp component and calculates the bottom of the image by grabbing its height, its vertical position within the ssp component (this deals with centred content), and the vertical position of the ssp component within the movie. The other is the height of the ssp component - this is like a backstop and will set the maximum vertical position of the reflection.

Now the third thing you need to do - add a function to the reflect.as class:

		public function reposition(position:Number, objHeight:Number ):void {
			// moves the bitmap reflection - John [2009]
			//trace(gradientMask_mc.y + " " + reflectionBMP.y);
			if (position
The two important entities in the class are the reflection bitmap, or reflectionBMP, and the gradient mask that makes it fade away - this is gradientMask_mc. This function checks if the reflection's calculated y position is greater than the ssp component's height - ie if the image fills the component. In that case, the reflection is positioned at the bottom of the ssp component. If not - eg the image is landscape and centred - the reflection's positioned at the bottom of the image within.
		

Just as a lot of photographers think they have to go Mac, a lot think their web site has to be Flash-based because it stops people stealing their pictures. “Stops”, of course, has always been an exaggeration - someone could always do a screenshot or scavenge through the browser's cache folder. Flash only makes saving pictures less obvious and perhaps more time-consuming than it's worth.

But here's a handy Mac tip for you - try Apple's Safari browser, go to any photographer's Flash-based web site, and choose Safari's Window > Activity menu item. You get a nice little list of all the files which make up the current web page, including JPEGs called up by the Flash movie. Double click one and it opens in a separate browser window, ready to save to your hard drive. It's not much harder than saving pictures off an HTML gallery, is it? I've yet to find a photographer's Flash-based web site which has resisted this simple method - my own Flash-based pages included.

Fortunately Mac users are generally more honest than PC users, aren't they? Rafa Benitez fact or what? Safari is available for PC and is pushed suppository-style with iTunes and QuickTime updates.

It certainly makes me feel I've been rather complacent so far, but more generally it emphasizes that a photographer with a Flash-based web site really can't be any more lazy with deterrents than one with an HTML-based site.

As a bare minimum, it means embedding your copyright metadata in your pictures - which the thief would have to spend time removing, or leaves evidence of abuse. Better still, you want copyright information displayed on the picture itself, which helps deter theft via screen shot, Activity window, or browser cache. Lightroom's Web can add visual copyright marking, yet the feature is laughably-weak so the copyright cannot be positioned anywhere other than the image's bottom corner from where it can be easily cropped. Until noticing this Activity window, I thought my solution - putting the copyright into my Flash movie - was a much better defence, but now I'm nowhere near as confident.

As I stole a few of my own pictures using the Activity window, one thing I noticed was the lack of any embedded copyright metadata. This had all been present in the files I was uploading with the SlideShowPro Director plugin for Lightroom, but SSP Director was then generating a variety of sizes, as it should, and sending them to various Flash movies - stripped of their metadata. Yuck - if you were so concerned about file size, would you honestly use Flash in the first place? Secondly, I knew that my visual copyright marking was only in the Flash movie, fine for the main risk from screen shot theft, but no use against browser cache trawling, and now no defence against Safari's Activity window.

While I can implement this hack to preserve embedded metadata, the visual copyright issue is a tougher nut to crack. One could upload already-watermarked images to Director, but it's an extra step in what was an elegant process, and Director would then serve the pictures at various sizes and potentially introduce artefacts around the copyright pixels. Ideally SSP Director needs to do it on the fly.

The lack of copyright metadata makes me very nervous of recommending SSP Director until the default is changed or can be overridden in the SSP Director control panel. But one thing I like about SSP is that the guys both listen and respond….

Launching a Flash site has always been a background project - it's not as if I'm unhappy with the current site - and it's pretty easy to find a reason to keep it in the garage and keep tinkering away. Learning ActionScript3 was the latest reason for such delay, but I've convinced myself it was probably the right move. Just like that Iraqi reporter didn't target Dumbo Bush with old sandals but chose his latest genuine Timberlands, it would feel a shame to launch an ActionScript 2 version. Even now, when I feel I've cracked ActionScript 3, I'm sure I'll find other reasons for delay - that light at the end of the tunnel could always be a fast-approaching train.

Still, intense beavering-away does sometimes deliver fruits ready for public display. I already had some Flash-based galleries on this site, all based on SlideShowPro and ActionScript 2. They were all powered by Director, SlideShowPro's online content management system, and adding new images was a simple matter of running a Lightroom export and choosing which album to target.

I had a couple of less-edifying but more-visual reasons for switching these to ActionScript 3. A big one was that with a single line of ActionScript 3 you can make a Flash movie colour managed - see John Nack's post (for this to be visible, the visitor has to be using a colour-managed browser and the Flash Player 10).

Secondly, I liked the look of SlideShowPro's new ThumbGrid component. It's a $24 add-on to the SlideShowPro Flash component, replacing the built-in navigation, and it is only for ActionScript 3. See how it works here.

The only regret about not launching the fabled Flash site has been its stubbornly-constipating effect on putting new pictures online. So for an example of ActionScript 3 + colour management + ThumbGrid, see the mostly-new American Civil War gallery.

How bloody annoying. Yesterday, rather than renew my annual hosting agreement, I was switching to another package. While staying with the same host, their more modern platform costs less, and has better email handling and PHP5, which I “need” to play with SlideShowPro's API. The cunningly-devised plan was to get all the html, images, email settings, and databases working on the new platform before switching off the old one.

Unfortunately someone misunderstood the words “IMPORTANT - REFER TO XYZ (the guy at the host who handles the account) DO NOT SWITCH THE DNS SETTINGS UNTIL CUSTOMER REQUESTS”. OK, I was as long-winded and ambiguous as ever, and most of all I was foolish enough to enter those words in a box called “Special instructions”. Naturally enough, they were completely and enthusiastically ignored, and just an hour after signing up I had lost access to my old web space and had a 24-48 hour wait before the new web space would go live.

Not by luck, I had absolutely everything, including the mySQL databases, backed up to my PC. It will take a while to upload everything, but I've already hooked up the database-driven stuff like the blog and most of the pictures. I am lucky that I can handle it all myself. Yet thinking back to the recent Digital Railroad fiasco, can say the same about your online property?

Normal service will be resumed….

I was asked recently for a few reasons why I still use Expression Media (I still call it iView) rather than depending entirely on Lightroom, so in descending order, here goes:

• By far the biggest reason is to manage in a single place all files related to photographic projects. For me, like very many photographers, that isn't just photos, but might easily include sound clips from wedding shoots, PDF contact sheets, the odd ProShow presentation, as well as any correspondence. Ideally Lightroom should control all these file types, but it doesn't, yet.
• iView's very much faster generating large numbers of JPEGs for emailing or for making a web gallery of a whole shoot. This is because it uses the Lightroom-adjusted preview in the DNG, while Lightroom needlessly reprocesses the raw data.
• I depend on custom fields for recording who's featured in my re-enactment pictures and finding them quickly, and for grouping frames shot for stitching or HDR. While the LR2 SDK does now let you add custom fields, it's too new and undeveloped, and you can't read/write the metadata to/from images. iView does this, so any TIF made from a DNG automatically inherits the original's custom metadata, making it easy to marry up a stitched panorama to the component frames, for example.
• I greatly prefer the flexibility of iView's low tech HTML templates to Lightroom's Lua-based ones.
• iView has scripting using widely-known languages which I can quickly use to copy IPTC location information over to keywords, for example, or to search and replace within captions (eg for typos). It gives me the flexibility to write a simple script in a text editor, or in a well-established development and debugging tool such as Microsoft's VB editors or Apple's Script Editor. Lightroom's comparatively-obscure Lua is an inhuman programmer's language wrapped in layers of nested functions, has little documentation written for non-programmers, gives indecipherable error messages, has no development tool more helpful than a text editor - and in any case has restricted access to metadata. For me, end user access to scripting is one badge which makes a program a professional tool, and it should be present from day 1.
• Using beta versions of Lightroom, and testing them more brutally than may be wise, I want a rock solid DAM base.

There is a huge value in one application combining file management, adjustment, and output. I'm a big user of LR2's smart collections which can automatically group new pictures meeting a wide range of criteria. Migrating to a wholly Flash-based web site, I'm using Lightroom's SlideShowPro export. And maybe the SDK may offer a way forward for my custom metadata. Even though I'm unsure what I want to do about types of files which Lightroom can't import, the balance is certainly shifting and I'm relying more on LR as months go by.