Posts tagged with SlideShowPro
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.
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 . . .
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 . . .
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 . . .
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 . . .
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.
I don't want . . .
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 . . .
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 . . .
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.
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:
The Lightroom-Director export plug-in makes it easy to upload 2000-pixel JPEGs directly from Lightroom
I've a smart album in Director which automatically displays new pictures in the New Photos page's Flash movie
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
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 . . .
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 . . .
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 . . .
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 . . .
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 . . .
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 . . .