You may have been explained how to do it by following the procedure when using Dreamweaver, and later been surprised when it didn't work for you. I was surprised too, considering that this is the official way of going about it, but it just didn't seem to work.

The obvious observation is that everything works fine when the slideshow is first exported, but when you try to embed it in your design, it fails. So I've kind of reverse-engineered the auto-generated code to try and figure out what was going on. Not being a SlideShow Pro developer, I cannot say with certainty why it doesn't work by following the original procedure (they must have tested this!), but there really seems to be variables missing in the declaration...

But first, let's just take a moment to look at some of the parameters you set when creating the slideshow. Personally, I don't want all the bells and whistles that the software offers me:

• Unless I've added specific captions/comments for all the images, I don't want to display captions when the user hovers his cursor over an image.
• Unless I want to merge many albums inside the same slideshow, I don't want to display the gallery.
• Unless I will use this slideshow in a standalone page, I don't want to display the header.
• I certainly don't want to use popups for displaying a larger image in a new window when the user clicks on an image.

So with all that said, I have to (or can) disable many important features of the slideshow that will simplify its interface (there may even be some I missed—you'll have to carefully review all the innumerable and incoherently organized options to be sure):

Extraneous features

Unfortunately, the software is not very brilliant and will export images even for disabled features. That is, it'll export large-size images to display full screen, in popups and in thumbnails even if the features were explicitely turned off.

Moreover, even if you've set the slideshow to be of a given size, it won't export images that are of the exact size required to fit in the frame automatically—it'll export images the size you specify manually, even if that means the images will be larger than the room available (rendering all the images ugly because Flash's resizing interpolation sucks, thus also turning into a farce the output sharpening you've expected), and even if that means you'll have to fuss with the pixels until it seems to match perfectly, considering the variable height of the navigation bar, strokes you might have added, etc. This is ridiculous:

Output Settings

In this example, I had to set a slideshow dimension of 900x634 (yes, 634 exactly) to match my 900x600 images, considering the navigation bar I had configured, with no stroke.

(Note that all the settings can be modified manually by editing the exported XML files directly, but I don't presume you'll want to do that. It'll be easier to configure it right from the start...)

Once you've exported this thing, you'll want to go in the "album1" folder and delete all the useless images it exported for you that will simply take up space for nothing. In my case, I delete the two folders "fs" (for full screen images) and "popup" (for popup images). By now you've cut the whole thing's size by a not inconsiderable margin (enormous if you had left the "Full Screen" and "Popup" dimensions to large sizes). If you've both turned off the previews and are using a navigation bar that only displays numbers, you can delete the "thumb" folder as well.

Alright. So now you've got a folder containing all the stuff that SlideShow Pro exported for you and you want to embed the slideshow inside your design.

If you follow the official instructions, you'll use Dreamweaver's embed feature and add the "base" variable, which will prompt you to add a "Scripts" folder containing two files in the root of your website. If you have more than one album, yet have them separated (because you want the user to access them using links/buttons in your design, not by using the slideshow's "Gallery" feature), this means you'll have more than one of those SlideShow Pro exported folders containing duplicates of certain files.

We don't want all that—let's optimize! Forget about the official procedure. Here's how you do it (strap your seatbelt, because this requires editing some code). I will presume here that all your albums will be accessible from a single location—that is, you'll have some kind of "portfolio" section (thus, a "portfolio" folder) that contains links to the various albums. Something quite like this:

Portfolio pages

In this case, I have two albums in my portfolio (the main album and another about "nature") and I want each one to display a slideshow.

First step, export all your slideshows separately.

You will end up with a bunch of different folders, all containing a standalone slideshow page and its associated files/folders. We don't want to merge them in a single slideshow (as you might have done in a previous assignment to have all of them showing in the gallery), but we do want to merge them in a single folder that we will add inside our portfolio section, to save space and keep things clean. (I presume here that you will have already deleted the useless images folder for unused features, as explained earlier, to save space.)

Select one of the slideshows as the base where all the others will be added. (It doesn't matter which one.)

In that folder, you can delete the "index.html" file exported by SlideShow Pro, as we will not be using a standalone page to view the slideshow. You can also go ahead and delete the "pop.html" and "pop.swf" files, as we will not be using the "popup" feature (well, not here, in any case).

Rename some files and folders.

Because we will be merging many albums in the same folder, we need to select unique names for the album-specific files. For example, if your album is about portraiture, rename these files in this fashion:

• Rename the "param.xml" file into "param_portraiture.xml".
• Rename the "images.xml" file into "images_portraiture.xml".
• Rename the "album1" folder into "album_portraiture".

Now, because we have messed with the file names, the slideshow is broken. We must change the values in the files that depend on these specific names.

Open the (former) "param.xml" file (Dreamweaver, for example, allows you to edit the code directly), and locate the "xmlFilePath" attribute near the end of the file. You should change the value that is set to "images.xml" into the new images file, "images_portraiture.xml". The parameter file is good to go!

Open the (former) "images.xml" file, and rename all the occurences of the "album1" value to the new name of the images folder ("album_portraiture"). There should be 5 of those, all in the <album> tag. The image file is good to go!

Good work. Now, do that procedure with each of your albums. When you're done, you will move the parameter file, the images file and the album folder of each album into the base gallery's folder. The remaining files (expressInstall.swf, loader.swf, slideshowpro.swf and the "js" folder) will be shared by all slideshows, so you don't need to bring them over.

Move the slideshows in your site's folder structure

When you're done, you should put the base slideshow folder inside your portfolio folder and rename it "slideshows". As an example, for my portfolio, I had two albums, so here's the folder structure of the portfolio folder as seen in Dreamweaver, once I have moved over the base "slideshows" folder:

Portfolio folder structure

Notice that some files are shared by all albums, and some files are specific to each album. If you have more slideshows, you'll have more album-specific files, but the basic structure should remain the same.

Embed the slideshows in each portfolio page

We're almost done. At this point, we have optimally merged all the slideshows in a single folder that we have incorporated into our site's structure, but we still need to make them appear on the appropriate pages.

Go into Dreamweaver, in your main portfolio page. Add a <div> tag at the location where you would like to place the slideshow (it is presumed that the space available in your design matches with the size of the slideshow, of course). Give that <div> tag the id "flashcontent" (it could have been anything, but we'll stick to the official name...) There is no need to create a CSS rule for that id. Remove the useless text Dreamweaver inserts inside the div. You'll end up with a bare, skinny div that doesn't do anything yet (this is normal):

<div id="flashcontent"></div>

Now go in the code for your page, and inside the <head> section of the page, add the following chunk of code:

<script type="text/javascript" src="slideshows/js/swfobject.js"></script>
<script type="text/javascript">
   var flashvars = {
      paramXMLPath: "param_city.xml"
   }
   var params = {
      base: "slideshows",
      bgcolor: "#ffffff",
      allowfullscreen: "false"
   }
   var attributes = {}
   swfobject.embedSWF("slideshows/loader.swf", "flashcontent",
      "900", "658", "9.0.0", "slideshows/expressInstall.swf",
      flashvars, params, attributes);
</script>

You'll have to simply replace the "param_city.xml" to whatever the name of the parameters file for the slideshow you want there (say, for example, "param_portraiture.xml"). Also, you'll have to change the size for the slideshow (where it says 900 and 658) to the size appropriate for your slideshow. Notice that the height is larger than the value entered when configuring the slideshow—this is because I am using the "wet floor" feature that shows a nice little reflection at the base of the slideshow, which this height has to account for. You may have to change the background color value as well (bgcolor) if it isn't white...

Do this in all your portfolio pages, simply changing the name of the parameter file, and you're done! (You'll obvisouly only see the result once you preview the page inside a real browser...)

Why all the complication?

When you're done, you'll have all your slideshows in a single folder, you'll have deleted all the extraneous/duplicate files and folders to save space, and you won't need to add a "Scripts" folder in the root of your website. You have included a bunch of variables in the code that were missing by following the official procedure (remember that the only variable it required you to add was "base").

It required some more work in the code, but is a cleaner, more size-efficient solution in the end.

Since we don't walk around with colorimeters or computers to analyze our images (and because we just don't have the time to fool around anyway), there is an easy trick to reliably figure out which color the ambient light actually is. Your camera has an RGB histogram — all you need to do is to fill the frame with a neutral reference and you'll know!

Remember that since you only want to read the ambient light for this test, you need to turn off your flash. Also,  it is important to use the "daylight" (neutral) white balance to do this test, otherwise you will not get a true assessment of the color (you will get something that was corrected in one way or another). The neutral reference could be a grey card (ideally), but it could also just be a white wall or piece of paper — as long as it fills the frame and is "close enough" to neutral you'll be alright, since you won't be able to surgically match your flash to that color anyway (there's only so much you can do with a couple of gels!)

I tested this in my living room, where the lamps use "compact fluorescent" bulbs — those are hard to guess. When the image appears on your LCD, display the RGB histogram, and you will see the color dominance right there:

In this case, we can see that there is far more red and green than blue. We can also see that although this is fluorescent, this is definitely not just green. Remember that with light, red+green=yellow! So in this case we have some kind of orange, because the red component is a bit stronger than the green.

Now all you have to do is pick gels that will add the same cast to your flash. If I had to act quickly, I would pick a strong orange and I know that I would get a pretty decent result. With just this one quick test, I am certain not to make a huge mistake and use a color that is way off.

To illustrate the effect the different gels produce on your flash, you can do a similar test: shoot a neutral reference, in "daylight" white balance, but this time with only the flash exposure (use a fast shutter speed and low ISO to remove any ambient light).

Using a strong green gel, we get this result:

Definitely not! Notice how the histogram doesn't look at all like the one I had with the ambient light only. Let's try a strong orange gel:

Well, this is much better. I could certainly shoot knowing that the color of the ambient light and the color of my flash are "close enough". If you want to match the ambient light even more closely, it's possible — at some point you'll get something like this:

A-ha! Well this is very, very close. But I had to use three different gels (from what I had in my kit), so this is getting a bit crazy. Also remember that each gel you add in front of your flash cuts some light — the more gels you use, the less powerful your flash becomes.

In practice, you might only have 2 or 3 degrees of orange and green in a basic kit. That's fine — most discrepancies can be removed with just these, even if they are not "perfect". The more you do this, the more you will be able to pick the appropriate gel (or combination of gels), since you will know what histogram they produce.

Screen Sharpening

In a complete image processing workflow, there are commonly three different kinds of sharpening applied at different stages and for very different purposes.

It is important to understand that most of the sharpening is necessary even if one does not want to apply it "for effect", because of various limitations along the workflow. It should be noted that a basic sharpening workflow is not aimed at correcting soft images (caused by focusing error or motion blur), but at maintaining optimal detail in files that already contain as much as they can.

• Capture Sharpening (or Input Sharpening) is applied first and is necessary to restore loss of detail inherent in digital capture. That is particularly obvious when anti-aliasing filters are placed in front of image sensors to reduce moiré, as is very often the case (except on most digital backs, the Leica M9, and others). That is why the default behavior in Lightroom/Camera Raw and other raw processors is to systematically apply at least a basic amount of capture sharpening, which must then be refined manually (depending on various factors such as frequency). Note that this is true only when shooting raw files—shooting JPEGs means that the camera has already applied sharpening, so additional work on the file must be done carefully.
• Creative Sharpening is usually applied locally on specific regions of an image that require it most (such as the eyes and mouth when working on a portrait). This is the only kind of sharpening that is applied "for effect", where the photographer decides whether he wants his image to look natural or more crunchy.
• Output Sharpening is applied at the very end and is totally dependent upon the destination of the image. Luckily for us (and thanks to the work of Bruce Fraser and the guys at PixelGenius), Lightroom makes it incredibly easy to properly perform this task, which used to require a lot of trial and error. The thing is that if the image is going to an inkjet printer on glossy paper, the sharpening applied is not the same as the one applied for matte paper, and is not the same depending on the resolution of the print, and is very different from the one applied for viewing an image on screen. On one hand, inkjet printers inherently introduce a certain loss of detail because of the nature of the technology itself, so some additional sharpening must be applied—sharpening that would definitely look ugly if the image were to be viewed on screen. On the other hand, images need to be resized to be of an appropriate size for viewing on screen, and resizing an image calls for interpolation algorithms, which also means a loss of per pixel detail. This is why Screen Sharpening is required, not "for effect", but to maintain optimal detail when the image is to be viewed on screen.

Applying a "Standard" amount of screen sharpening to JPEG files exported for viewing on a web page is a very good idea—not to make the images look crunchy, but to retain an optimal level of perceptible detail.

Note that whether you intend to export images for the web or to print them, output sharpening is not something Photoshop will do automatically or even offer. When you want to do it yourself in Photoshop, the burden is on you to apply the optimal sharpening for a given destination—good luck! Do yourself a favor and just don't do it that way... Either print/export from Lightroom, or use PixelGenius' PhotoKit Sharpener and skip output sharpening altogether in Lightroom.

Resolution

When exporting images for viewing on screen, the resolution of the file has absolutely no meaning, so whatever value you put in that field has no importance and, contrary to what you might have been told, will have no effect on the exported file—files won't have more or less detail, and file size will not be affected at all. The important factor when exporting files for the web is the size (in pixels), not the "resolution".

Traditionally, images consumed on a computer screen have been set at 72 ppi (so you might as well put that), but that really depends on the resolution of each monitor—something you have no control over when you publish images on the web.

Color Space

If a file is going on a web page, because we cannot know if the browser used to view the image will support color management, we should aim for the common denominator (it won't support it) and choose the sRGB color space (the default presumption when color management is not supported).

The gamut of the sRGB color space is smaller than the gamut of the AdobeRGB (1998) color space, which itself is smaller than the gamut of the ProPhoto RGB color space—that much is true. But "color spaces" must not be confused with "color models".

The fact that most commercial printers offer very limited gamuts has nothing to do with the fact that they work in CMYK (a color model, not a color space). One simply has to have a look at Bill Atkinson's book to realize that commercial printers are technically able to achieve excellent gamuts and color fidelity when they put in the required effort.

In other words, the CMYK color model itself does not define the gamut, so it would simply make no sense to state that "CMYK has a smaller gamut than color space X".

Yes, you may resize and drag around the preview image in the "Print" dialog box from Photoshop, but it's really approximate—chances are you won't fully exploit the real estate. Yes, you may use the "Print" module from Lightroom, with a certain cell configuration, and fill in the blanks with a bunch of dummy blank images until your test image falls in the right spot, but it's kind of a hack—why won't the software allow to leave spots blank and drag a picture around on the layout is a mystery.

Here's a different approach. What I do is I create a new document in Photoshop, the size of the printable area of the test paper, at a good resolution (say, 300 ppi), and I split the page using guides according to how big I want the tests. I only need to do this once, because I save the file each time I'm done with a test. The advantage is that I know exactly where the next available slot for a test print is on the test paper, and because I have precise guides to help me, I can fully exploit the available space in each cell.

Test print layout.

Before printing, all I need to do is hide the layers of the previous test images, so that only the last one is printed. When the document is full, I delete the layers and change my test page.

Don't forget to write a little marker on the back of the test page, so you always feed it in the printer the same way!