Nonsense.

For one thing, when shooting raw files, the software in the camera has absolutely nothing to do with the resulting image. That's what shooting raw means: the raw data from the sensor, once digitized by the A/D converter, is not processed further and is dumped as is on the memory card. Understand that when the ISO is changed, it doesn't simply mean that the camera will "push process" the file with its internal software—that would be a completely pointless enterprise which would render even the concept of selecting an ISO meaningless. Why would you bother changing the ISO at capture time if you could simply push a slider farther right in your raw processing software in post?

Raising the ISO is not a matter of software, just as raising the gain on any signal processor isn't:

In digital camera systems, an arbitrary relationship between exposure and sensor data values can be achieved by setting the signal gain of the sensor.

This cannot be relegated to post production, as by then it is too late. If you have underexposed an image, no amount of pushing will recover lost information—just like it was with negative film. Having raised the signal gain prior to digitization (by setting a higher ISO) gives you additional information (especially noticeably in the shadow area), albeit at a cost of higher noise.

Back in the film days, it was a well known fact that a "push" processing was detrimental to the quality of the image (unless, of course, that particular "look" was what you wanted, for aesthetic reasons):

Push processing allows relatively insensitive films to be used under lighting conditions that would ordinarily be too low for adequate exposure at the required shutter speed and aperture combination. This technique alters the visual characteristics of the film, such as higher contrast, increased grain and lower resolution. Saturated and distorted colours are often visible on film that has been push processed.

If you were shooting slides (positive film, which is closer to the behavior of digital exposure), you could push an exposure by a larger margin than if you were shooting negative film, and the opposite was true of "pulling" (which is the opposite of pushing).

This was, of course, the film days, and there might be various reasons for doing so (such as the sudden need for a different ISO when the film had already been loaded). I am not a avid film shooter, so I cannot discuss in detail about the many motivations behind the practice, but the fact remains that pushing definitely didn't have the same effect as using a higher ISO (i.e.: not just an equivalent increase in grain).

In digital photography, pushing a file not only increases the noise (which is okay—raising the ISO does so as well), but more importantly, it also compresses the dynamic range of the file in a way that raising the ISO doesn't. That, you want to avoid.

Same aperture and shutter speed, ISO 800, 400 and 200.

Here is the boring picture of a camera shot with various ISO speeds. As you can see, the histogram reveals that tonalities are not just generally farther to the left, they are also more compressed to the left—bringing the exposures on a par in post will unavoidably be harder on the underexposed frames.

But those are raw files, and we're working with very powerful, sophisticated raw processors, aren't we? Let's see what happens when we bring the three exposures even (moving the white point and black point):

Pushing the exposures

Well, well! It seems the file with a higher ISO turned out cleaner than the files pushed in post! The more you push, not only do you get more noise everywhere (especially in the shadows), but the files get muddier, and tonal gradations are less smooth. Why is that? Because there is more information in the highlights than in the shadows (hence "expose to the right").

The morale of the story is that you are better off raising the ISO to get a proper exposure than compensating for underexposure in post.

Of course, here I am not talking about resolution in the sense of number of pixels, as we often hear people say when talking, for example, about the resolving power of digital camera sensors ("My camera has a resolution of 12 megapixels!") This unfortunate choice of words perpetuates an age old confusion about what we mean by "resolution", "size", "dimensions", "number of pixels", etc. Here, I am referring to the proper sense of the word, which means pixel density, not number of pixels.

Resolution = Number of pixels / Physical space they occupy

Note that even the "Guideline for Noting Digital Camera Specifications in Catalogs" of the Camera & Imaging Products Association (CIPA) explicitely advises that "The term 'Resolution' shall not be used for the number of recorded pixels", but I am not merely arguing that we should stick to using the word "resolution" when we mean "pixel density". That is a valuable point to defend, but is not so problematic as the fact that people actually confuse "ppi" (by sheer definition a measure of density) and "number of pixels" or "file size". (There is also a related confusion between ppi [pixels per inch] and dpi [dots per inch], the latter being a matter of print heads, but that is an issue I won't be discussing here.)

So, in keeping with that definition of the word, for resolution to mean anything, we must know both the number of pixels and the number of inches we're dealing with. Until the image is printed, pixel density is either immaterial or is a value that fluctuates depending on the context. My main display, for example, projects 1920 × 1200 pixels on a 24" panel (~94 ppi). My laptop, on the other hand, projects 1680 × 1050 pixels on a 15" panel (~129 ppi). Using a projector? You could make 1024 × 768 pixels occupy 6 feet wide (~14 ppi)! Thus, if you look at, say, the same 900 × 600 pixels image in any of these contexts, the actual resolution of the image has changed considerably—and you didn't have any say in the matter. So the only time you actually have the control over the resolution is when you send an image for print, because then you know the ultimate size of the image, and you can finally lock down the "number of inches" part of the equation.

In their confusion, people will say something like: "I don't need a large image, just give it to me in, say, 100 ppi", as if that meant anything. Even more egregious, they'll say something like: "Send it to me in 72 ppi so that it can be attached in an email", or "For images displayed on the web, set the resolution to 72 otherwise they'll take longer to download" as if resolution had any relation to file size. Conversely, they'll make the opposite mistake when confronted with such file properties:

File properties in Bridge

"Well, gee, 72 ppi means I am obviously dealing with a small, low quality file here!" No you aren't—notice the dimensions! This is a rather huge image, of potentially pretty great quality, I would think.

Look at it this way: 5000 wide pixels at 72 ppi, or 5000 wide pixels at 600 ppi is the same file, the same data, it doesn't mean anything until we decide to print. In the same manner, an image of 100 measly pixels wide set at 8000 ppi is a ridiculously little file compared to a 5000 pixels wide image set at 8 ppi.

What matters for the quality and size of a file is the number of pixels. What matters for the quality of a print is the resolution—but you need the pixels to be able to afford it, so it still breaks down to the number of pixels.

So, okay, you could maintain that what they are actually trying to say, albeit technically improperly, is that if you take your original picture and you resample it down to, say, 72 ppi, then you would end up with a much smaller image. Apart from the fact that resampling and setting the resolution are two thoroughly different things (it just happens that you do both of these things in the same location in Adobe Photoshop), maybe. But the inescapable problem which then arises is that we'd have to know the initial resolution in order to reduce it down to 72. What is it? Let's see... The sensor in my camera is 36mm (~1.42") wide and produces images 5616 pixels wide. Does it mean that the original image has a ... 3962 ppi resolution? That can't be right!

Hey, no problem, let's just posit that the initial resolution is something like 240, or 300 ppi, for whatever reason. Well it's still a problem, because if you simply resample down from an arbitrary 300 ppi, everybody will end up with considerably different image sizes, since different cameras have different number of pixels (say, 21 MP versus 12 MP, a quite realistic difference these days).

Again, this all boils down to the fact that there is no such thing as "image resolution" until you actually decide how big you want it actualized. Let's go to the epicenter of confusion, the "Image Size" dialog box in Adobe Photoshop:

Changing image resolution in Photoshop's "Image Size" dialog box

As can be seen here, setting a different resolution has no effect whatsoever on the file size, and no effect whatsoever on the quality of the file either. (Of course, if you did print this, you'd go from a 18,72" wide high quality image to a 78" wide poor quality image—then, and only then, would it mean anything.)

The "Image Size" dialog box has all of the interrelated terms in the same place, and you can see that Adobe chose their vocabulary carefully:

• "Pixel Dimensions" is the relevant measure of image quality and file size in this dialog box. It is the number of pixels you're working with—the more pixels you have, the more [potential for] detail you have.
  • In this example, 5616 × 3744 are the pixel dimensions of images coming out of a Canon EOS 5D Mark II (a 21 megapixels camera). Indeed, if you multiply these two numbers to get the number of pixels, you get 21.026304 million pixels.
• File Size (the value in parentheses) is a factor of the number of pixels, number of channels, and bit depth, but those last two aren't configurable from this dialog box.
  • If you take the number of pixels, multiply this by 3 channels (red, green and blue in an RGB color image) and then by the bit depth (in this case 16 bits (2 bytes) per channel), you indeed end up with 120.31 MB. If you're working with an 8 bits per channel image, or if you're working with a grayscale image (only one channel), or if you're working with a CMYK image (four channels), etc., this value would change accordingly, so be careful when interpreting it. What's more, this value doesn't take anything else into consideration (such as layers/adjustment layers/layer styles, embedded Smart Objects, color profile, color lookup table, vectorial data/paths, text, masks, notes, file format, compression level, full size composite, preview, metadata, etc.), so it has little to say about the ultimate file size on disk.
  • While we're on the subject... "File size" is another misleading term trotted around instead of the meaningful "pixel dimensions" or "number of pixels". Instead of saying something tractable like "The Pentax 645D has a 39.5 megapixels sensor" (which indeed it has) you'll hear someone say "The Pentax 645D produces 225 MB files!" Well, what do you mean by that? The Pentax 645D's raw files are in fact closer to about 50 MB in size and vary according to image content/ISO/etc., so that number is unnecessarily confusing.
• "Document Size" means "if you actually spread all the pixels above at a density of [Resolution] you will get an image that measures [Width × Height ][Unit]". Again, until you print the image, this whole section is meaningless and you can just ignore it altogether.

The bottom line is this:

• Image file quality and size are more meaningful in terms of the number of pixels.
• Unless you're having a discussion about printing, don't even bring up "resolution", "ppi" or "inches".

When the ambient light is rather dim, you might need to "drag the shutter" (use a slow shutter speed to allow enough of the ambient light to register on the sensor), while freezing the subject with flash—the flash lasting only a very, very brief moment. In this situation, your only potential problem, in terms of exposure, is having a flash that is too powerful, forcing you to figure out a way to limit its output (by using neutral density gels, for example).

Conversely, when the ambient light is very bright, such as when shooting in broad daylight, you might encounter many challenges. First, you will need to use more powerful flashes, otherwise their light won't be bright enough to be noticeable, in comparison to the available light. Second, you will need to use very fast shutter speeds, otherwise the ambient light will be too powerful—the shutter speed, in this case, will allow you to control the ambient light without affecting the flash exposure, since the flash is so fast as to be unaffected by the shutter speed.

1/60 second X sync (denoted by lightning bolt) on the shutter speed dial of a Canon AE-1 Program camera using a curtain-type focal-plane shutter

But there lies the problem: when using flash, you won't be able to exceed the "X sync" of your camera's shutter—a speed that is very often much too slow to control bright sunlight when using larger apertures.

So where is that X sync limitation coming from? It comes from the simple fact that for flash to register on the sensor, its burst must occur at the same time as the sensor is fully exposed to it. And what controls the exposure of the sensor? The shutter. Whatever type of shutter your camera is using, there are unavoidable physical limits to the speed at which the mechanical parts of the shutter can move. Since the flash exposure is usually much briefer than the speed at which the shutter can move, the limit in the fastest usable speed is determined by the speed at which the shutter can fully expose the sensor.

Most cameras today employ a focal-plane shutter, a shutter that is located just in front of the sensor and can fully expose the shutter no faster than speeds around 1/250 second, often slower. You might wonder why the X sync is so slow while it is usually possible to use exposure times as fast as 1/8000 second...

Rather than explaining it myself, I will let Ansel Adams do it, with an excerpt from one of his famous books:

Current focal-plane shutters usually consist of two separate curtains. As the first one travels across the focal plane it uncovers the film to begin the exposure, and the second curtain follows after a controlled interval to terminate the exposure.

At longer exposures the first curtain will open completely, and, after the measured delay, the second curtain then closes. As the shutter speeds become faster, however, the second curtain begins closing before the first has fully uncovered the film, thus following the first curtain across the film. The exposure is made through the slit formed by the two curtains, and very fast shutter times are possible. [...]

With electronic flash the pulse of light is very brief, in the range of 1/500 to as little as 1/50,000 second, so the flash must be triggered at the moment the shutter is fully open. This requirement presents no problem with a leaf shutter, since there is always a moment when the shutter is fully open, even at the fastest speeds. With a focal-plane shutter, however, the maximum speed that can be synchronized with electronic flash is the fastest at which the entire film surface is exposed at the same moment, usually 1/60 to 1/90 second with the curtain-type shutter and 1/125 second with the metal blade-type. Using electronic flash with a higher speed means that part of the film will be covered by one or both curtains when the flash fires, and only a section of the film will be exposed.

Ansel Adams, "The Camera", pp. 84, 86, Little, Brown and Company.

There's a reason some photographers pay a hell of a lot more for camera systems that allow the use of central shutters. Apart from focal-plane shutters having achieved faster speeds than the ones Adams was referring to in 1980, this basic principle has remained true to this day, no matter what you might have understood from David Hobby or Joe McNally's insights. If all it took to circumvent the X sync was to use low-powered flashes, a whole sweep of the photographic educational material would become meaningless.

Take a look at this video of a Nikon D3 in slow motion, where you can clearly see the rear curtain following the first without ever fully exposing the sensor (which is to be expected, at 1/4000 second). This video is also interesting for it demonstrates the full process of the aperture blades stopping down and the mirror (and sub-mirror) raising, the shutter curtains moving down, followed by the cocking of the shutter while the mirrors and aperture blades go back to their original position.

No, what David Hobby and Joe McNally are referring to when they talk about a way to use flash at faster-than-X sync speeds is, for example, Nikon's "FP" or Canon's "High Speed Sync" modes. The basic idea is that instead of sending a single flash, these modes send a rapid succession of flashes during the whole exposure so as to allow the sensor to be exposed to the flash throughout, even if only a small portion of the sensor is exposed at any point due to the use of a faster shutter speed.

Of course, because the flashes have to send multiple bursts of light, they cannot be used at their full power—there must be enough juice to flash during the whole exposure. As a consequence, they can only be used at a lower power, hence the frequent use of a multitude of flashes at the same time to compensate for the loss of power.

The key issue here is the fact that multiple bursts of light are emitted because the sensor is not fully exposed at any point, not the fact that the flashes are used at lower power. To be very clear: the power of the flash has nothing to do with the ability to use fast shutter speeds, but is only a drawback to be able to use this trick. Moreover, these special modes can only be used with proprietary systems, when the flash can speak to the camera—it is definitely not a trick you can achieve with any combination of camera and flash, and definitely not when using studio strobes.

Here is Joe McNally on the subject:

On a bright, sunny day, your ISO becomes (roughly) your shutter speed at f/16. Thus, ISO 200 translates to a 1/250^th of a second shutter speed at f/16. Right there, if you notice, you are at the top end of your flash sync speed, with a small flash powered by four AA batteries. [...]

Auto FP high-speed sync is an interesting and valid alternative to having the flash launch a missile's worth of light in one pop. In this mode, you are asking it to make many, many small pops of light. It syncs up with the focal plane shutter (hence the FP) to burst tiny bits of light through the blades of the shutter as it exposes the scene. Effectively, the light stays on for the whole exposure, which is a very short amount of time. This bursting capacity enables the flash to stick with the shutter all the way to a speed of 1/8000^th of a second, depending on the camera.

Somethin's gotta give, right? You bet. The power of your flash falls victim to the speed and repetition of all those little pops. [...] A way around this is to use a bunch of Speedlights [...].

Joe McNally, "Hot Shoe Diaries", pp. 256-257, New Riders.

Here is Kirk Tuck on the subject:

You're probably aware that most digital camera shutters can only synchronize with flash at shutter speeds of up to 1/250 second. [...] If you are using one of the more sophisticated flash and camera systems, you should also know about a nifty feature that can be helpful for shooting in sunlight with your flash. It's called "FP" flash, and it works like this: With your camera and flash set to handle FP [...], choose a shutter speed and aperture combination that works with the ambient light and the flash will actually pulse consistently enough to light the camera sensor evenly as the shutter opening travels from side to side or from top to bottom. This technique is best used to supply a bit of fill flash when you are using a fast lens near its widest aperture to blur a background. Since the flash must pulse instead of unloading one big burst of light the output is much lower.

Kirk Tuck, "Minimalist Lighting", pp. 68-70, Amherst Media.

And here's a bunch of Wikipedia articles, all speaking with the same voice:

Flash synchronization:

Today, certain modern xenon flash units have the ability to produce a longer-duration flash to permit X-synchronization at shorter shutter speeds. Instead of delivering one burst of light, the units deliver several smaller bursts [...]. This allows light to be delivered to the entire area of the film or image sensor even though the shutter is never fully open at any moment. The downside is that the flash is of less effective intensity since the individual bursts are lower powered than the normal capability of the flash unit. Only certain camera and flash combinations support this feature, and the camera-flash pairings are almost exclusively from the same manufacturer [...]

Shutter (Photography):

When using a focal-plane shutter with a flash, a photographer will typically operate the shutter at its X-sync speed or slower; however, some electronic flashes can produce a steady pulse compatible with a focal-plane shutter operated at much faster shutter speeds.

Focal-plane shutter — Breaking the X-sync barrier:

Electronics are also responsible for pushing the focal-plane shutter's X-sync speed beyond its mechanical limits. [...] At higher speeds, a normal 1 millisecond electronic flash burst would only partially expose the film – the part open to the slit. [...] In 1986, the Olympus OM-4T introduced a system that could synchronize a specially dedicated accessory Olympus F280 Full Synchro electronic flash to pulse its light at a 20 kilohertz rate for up to 40 ms, to illuminate its horizontal FP shutter's slit as it crossed the entire film gate – in effect, simulating long-burn FP flashbulbs – allowing flash exposure at shutter speeds as fast as 1/2000 sec. This allowed daylight plus fill-flash use in almost any situation. However, there is a concomitant loss of flash range.

Color modes in Photoshop

There are a number of ways to express color. If we want to express "maximum red" (whatever that arbitrary color means), we might use the RGB model and say "255 Red, 0 Green, 0 Blue", but we could just as well use the HSB representation and say "0° Hue, 100% Saturation, 100% Brightness". Both would express the same abstract color ("the most red that can be expressed"), just as we could do using the CMYK model (0% Cyan, 100% Magenta, 100% Yellow, 0% Key).

In other words, there is nothing inherently limitative in expressing colors using different color models, it just speaks differently to different people or contexts. Photographers often find the HSB model more intuitive, while graphic designers (and people closer to the print industry in general) tend to be more comfortable thinking in CMYK.

Unfortunately, things are not that simple, because "maximum red" means a different thing to each device and medium. A typical digital camera can capture a much richer array of colors than a printer can typically render, so a color model alone is not sufficient to describe colors. If the computer were to simply ask the printer to render "50% Green", the printer would naturally wonder "Well, what do you mean by that?", because no two printer/ink/paper combinations produce the same color when they spurt 50% of their green.

Which brings us to color spaces. Of all the colors in the full spectrum (well, the portion meaningful to the human eye/brain at least—see Lab), a color space defines which portion of it it can describe and how colors are distributed. The subset of the full color spectrum that a space contains is referred to as its gamut. Therefore, the "maximum red" of a digital camera, LCD monitor and printer/ink/paper combination are all expressed the same way as (for example, in the RGB model) "255 Red, 0 Green, 0 Blue" in their respective space, but they don't mean the same color, because all of their spaces have different gamuts. "Maximum red" on a given monitor might only be, say, "73% Red" of a given camera (which has a much more vivid "maximum red"), so when we want to have consistent color across a workflow, we need to know the color space of each device we're working with so that they can all "speak the same language".

A color space that describes the characteristics of a given device is also called a color profile. In a complete digital photography workflow, we would therefore need a profile for:

1. The capture device (the digital camera—or scanner, if we're feeling nostalgic)
2. The display device we're working on (such as an LCD monitor)
3. The output device (such as an inkjet printer/ink/paper combination)

We will also need to decide the color space (and bit depth, which can be thought of as the precision level) in which we will be performing post-production (also called, for obvious reasons, "working" space).

Photographers typically work in the RGB model (unless they want to perform old-school transformations in Lab) and typically deal with a number of familiar working spaces—sRGB, Adobe RGB (1998) and ProPhoto RGB.

• sRGB is a relatively small space that is the common denominator/standard for web publishing, so it should only be used when an image is exported for the web (or to some commercial printer that asks for it).
• Adobe RGB (1998) has long been the de facto working space because it is significantly larger than sRGB. The truth of the matter is that Adobe RGB has been smaller than the color spaces of digital cameras for years (see this ooold article), so when exporting images from the raw processing software to the Adobe RGB space you are throwing away lots of information. Worse than that, even modern inkjet printers can render colors outside of the Adobe RGB gamut.
• ProPhoto RGB is huge. While one could make the case that ProPhoto RGB might be too large in certain situations, when working in 16-bits, these concerns are not warranted. (ProPhoto RGB also happens to be the working space used by Adobe Lightroom.)

So, to wrap up...

A color model is the way you express colors. It doesn't have a size, and it cannot describe "real world" colors. It simply says "I am expressing colors using Red/Green/Blue channels", or "using Cyan/Magenta/Yellow/Key (Black) channels".

A color space (or color profile, or working space—all the same thing really, used somewhat interchangeably or depending on the context) is an actual description of a specific subset of the visible colors that maps—gives meaning to—the values used in a given model. Color spaces/color profiles/working spaces are all (typically) saved to disk in the form of ".ICC" files.

That being said, let's set the record straight on a number of color space related issues.

Using the camera profile as the working space

The camera's profile is quite large, but it is not the largest color space—not by a long shot. To give you an idea, here is a representation of the gamut of a Canon EOS 1Ds Mark II camera versus the ProPhoto RGB color space:

Comparison between the profile of a Canon EOS 1Ds Mark II and the ProPhoto RGB space.

Notice how abundantly larger the red mesh (ProPhoto RGB) is to the camera's profile (solid shape in the middle). The camera's profile is device-dependent to that particular camera and constrains colors to only the ones that that particular camera can capture, which has no bearing on how the artist would like to transform the image to bring it where he wants. The very bizarre idea of actually working in the space of the capture device is akin to caring that the final processed image will be "capturable" by the source device—it doesn't make any sense.

When working on an image, one should make abstraction of the source device. Imagine if a given photographer uses different cameras and wants to composite shots taken with different cameras in a single image? <head explodes>

The thing about CMYK

Because commercial printing processes typically work using color halftoning with CMYK separations, and because the default CMYK color profile used in North America is often U.S. Web Coated (SWOP) v2 (having a notoriously small gamut), we can be tempted to think that "CMYK is much smaller than ProPhoto RGB", which doesn't make sense. CMYK is a model, while ProPhoto RGB is a color space, so nothing can be said of the size of CMYK.

CMYK is not inherantly "smaller" than any other model, it's just that in practice, it is pretty much always true that any CMYK space used will be smaller than your working RGB space; let's just not confuse models and spaces.

Capture One

I find suspect the claim that "Capture One manages color better because it works in Lab". Let's understand that image transformations are mathematical abstractions that are only bound to a given space at the end of the process. Nothing prevents the internal image processing pipeline of a given software to juggle with imaginary colors of much greater precision than what can actually be displayed/exported.

Whatever happens behind the curtains, the "Lab" data has to be converted to a profile either to be displayed or to be exported to a baked file (e.g. TIFF, PSD, JPEG). In any case, it might very well be that internal algorithms used by Capture One manage to perform a "better" job with colors (I don't even know what it means to handle colors "better"—sounds rather subjective), but it would be for another reason than the fact that it does its math with L*, a* and b* coordinates.

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.

What gives these lenses their potential is that they have a larger image circle than regular lenses. Instead of simply being large enough to cover the sensor, their image circle extends far beyond and can therefore be moved around without introducing vignetting (not to be confused with illumination fall-off).

Geometric Distortion

The first set of adjustments are made to control convergence.

For example, this is what happens when the top part of a building appears smaller than the bottom part, because of a viewpoint that forces the camera to be tilted back. You cannot adjust the perspective with lens movements (only physically moving to a different position can change the relative distance the camera stands from the bottom and the top part of the building), but you can do something about the converging lines.

The basic idea is to position the camera so that the sensor plane is parallel to the surface you want to keep straight and simply slide the lens in order to place the part of the image circle that contains the subject where you want it. The amount of correction is therefore limited by how large the image circle is.

The sliding of the lens can be made in any direction allowed by the lens, to correct for lines converging in various directions (convergence doesn't necessarily only happen when looking up!) You can also create high-quality panoramic images by sliding the lens between exposures (never actually panning the camera), to produce (almost) seamless stitches.

If the lens is slid upwards, the movement is called a "rise". A downwards slide is called a "fall". Sideways, it is called a "shift" (left or right).

Focus Plane

The second set of adjustments are made to control the focus plane.

With regular lenses, the sensor plane and the lens plane are parallel, resulting in a parallel focus plane (depth of field extends front to back, parallel to the sensor). By changing the angle of the lens, the Scheimpflug principle explains that the plane of focus will end up at an angle as well, with the depth of field extending like a cone around that plane (see article for a complete explanation).

You don't need to bother with all that math. In simple terms, what it means is that because you can change the angle of the plane of focus, you can exert more control over which part of the image will be sharp. You could, for example, achieve a sharp image from right in front of the lens to the infinity, without requiring an overly small aperture that would be at worse impossible with regular lenses, at best detrimental to image quality because of diffraction.

By exploiting this optical phenomenon in the "wrong" direction, you can create a very slim section of sharpness in the image (almost perpendicular to the sensor plane), with the rest falling sideways out of focus — the trick behind the "fake miniature" effect.

When the lens is angled up or down, the movement is called a "tilt". When the lens is angled left or right, the movement is called a "swing".

Because the lens can be rotated, a combination of rise/fall/shift/tilt/swing can be achieved (depending on the capabilities of the lens — recent designs allow the slide movements to be rotated independently from the tilt/swing movements).

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.

When using a Sekonic L-358 light meter to read a flash exposure (the same applies to other models, I am simply not familiar with them), one of the nice features it has is its ability to indicate which percentage of the total exposure came from the flash — the rest of the exposure being from the ambient light available in the location where the metering was done.

Here is a figure taken from the L-358's user manual:

Metering flash exposure

As you can see in this example, 70% — "Percentage of flash in total exposure" — means that the flash was responsible for 70% of the total light, while 30% came from the ambient light available. The total amount of light ended up requiring an aperture of f/5.6 and 3/10th (let's call this f/6.3).

If 30% of the total light gathered by the light meter during a reading comes from the ambient light, if you change the shutter speed (without changing the flash power), you should expect that percentage to change: the longer you expose, the more the ambient light will have an impact on the total light, since you will gather more of it (while still gathering the same amount of flash). On the other hand, if you expose for a very brief moment, you will gather very little of the ambient light (while still gathering the same amount of flash), so the ambient light won't have much of an impact in the total light.

You might very well end up in a situation where the flash is only responsible for a small fraction of the total light (say, 10%) or, at the other extreme, end up in a situation where the ambient light has no influence on the exposure (which would give a 100% flash exposure). For example, when working in a studio environment, we usually don't mind leaving the modeling lights on when shooting, because we know that the light they produce is insignificant in the total exposure compared to the flash power (we get a 100% flash exposure all the time regardless).

Now, coming back to a location shoot where we mix some ambient light with flash, we should often expect situations where the percentage of the flash in the total exposure will not be 100%. In the situation of the figure above, where 70% of the total light came from the flash, suppose we were to expose for 1/30 instead of 1/125 — that is two stops more ambient, giving us a brighter background. In this case, the flash would now only account for ~40% of the total exposure. What's more, since we're adding ambient light to the previous exposure (flash remained the same), we now have more light overall, so we must use a smaller aperture — we go from f/6.3 to ~f/9.

This makes the shutter speed a crucial parameter to provide to the light meter, otherwise the obtained value will be wrong.

The only situation in which we could ignore the shutter speed would be in a pitch-black room where the only light is the flash — in this case, the ambient light (or lack thereof) would have no impact in the reading whatsoever.

Changing our perception of flash color gels

If you're mixing flash with ambient light, you know that you can (must?) correct the color of the flash so that its light color is well harmonized with the ambient light color, lest you get a quirky result.

But you can also use color gels not necessarily because you want to make the two light sources the same, but because you want to add an effect, such as warming up the subject so that it contrasts more with a colder background, for example.

In the image below, both the foreground and the background lights are of the same neutral color:

Foreground and background light have same color

Using a CTO gel (orange) on the flash aimed at the subject, you can warm up the subject, which will further isolate it from the background (which will now be of a relatively colder color than subject, even if it is the same as in the first shot):

Foreground light is warmer than background light (note: a strong color was used to make the illustration obvious)

Indeed, while the background remained the same, it can be said that the subject is warmer.

You will notice that I also (conveniently) included a gray card in the frame. If we take the picture above (the same exact file), but that we color correct using the gray card, here's what we get:

Image above, but white balance corrected with the gray card

You will notice that the subject is now perfectly neutral — exactly back to what we had in the first frame — but that the background turned blue (colder)! In this case, can it be said that the subject is warmer than in the first shot? Absolutely not — in fact, they are exactly the same, after correction, even if a "warming" gel was used.

If you're going to include a gray card (or GretagMacbeth chart) in your frame, you might want to do it while you're not using a gel on the subject, otherwise, balancing the color with a neutral reference will remove any color you might have thrown on the subject and, rather, affect the background. If you're going to include a gray card in your frame while you are using a gel, the way you should look at it is that you are in fact changing the color of the background in the opposite direction than that of the color gel (e.g.: if you're using a warming color on the subject, you're actually not changing the subject, but rendering the background colder!)

The fact that we are using a "warming" gel has no bearing on the final look of the image, because it depends on the white balance selected. A "warming" gel might therefore be more meaningfully seen as a "gel that makes the background colder"! That is why, when you work indoors under tungsten lights, you use a warming gel: not to warm up the subject (you still want it neutral), but rather to make the background colder.

If you're shooting raw, you're probably aware that you don't technically need to worry about it at capture time, because it's not set in stone — whatever setting you use won't definitely affect your final image; you'll easily be able to change it in your raw processor. (Of course if you're shooting JPEG, then you'll definitely want to nail it as close as possible to your objective to minimize the amount of manipulation required. But you're not shooting JPEG anyway, are you?)

So you're shooting raw. Why even bother performing your white balance at capture time, then?

• One reason might be to get a better approximate histogram, so that you can better judge your exposure. Indeed, you might think that one of the channels is clipping when, in fact, it's the color cast that was throwing off the histogram. But then again, if you're evaluating the exposure another way (say, with a light meter), then this won't matter to you.
• Another reason might be to get a better approximate image preview, so that you can better judge the colors. Of course, you can't really rely on the image preview on that little LCD for accurate color evaluation, but surely, if the color balance is completely off, it might be quite misleading. But then again, you might only use the image on the LCD to judge the composition, pose and other aspects of the image, keeping in mind that color will be dealt with afterwards, so this, too, might not matter to you.
• Yet another reason might be so that when the unprocessed images pop up on your computer screen, the client watching you work will have a better idea of what the images will look like right away. Indeed, the client might not respond well if there is an annoying color cast in the images, even if you know you'll fix it later. But if you're not shooting tethered with a client watching over your shoulder, this might not matter to you either. (Note that some raw processors, such as Capture One, can be configured to automatically apply a certain white balance to all imported images, so that the images are immediately corrected, regardless of how they were shot, which is another reason why performing in-camera white balance might be irrelevant to you.)

Only you can know how important it is for images to be properly balanced at capture time, but if you want to do it, there are many ways to go about it.

• One way is to use the Auto White Balance feature of your camera. Sometimes, in rapidly/wildly changing light situations, this setting might be more efficient at getting a decent approximate white balance than having to fiddle repeatedly with your camera's parameters. If you're not working in such a difficult situation and the color of the light is not changing — say, you're working in a studio — then this setting might, on the contrary, produce unpredictable results.
• To get consistent results, another way is to use one of the white balance presets your camera offers — things like "sunny", "cloudy", "tungsten", "fluorescent", etc. This usually won't give you an exact result, but you'll likely get reasonably close to your target for your histogram and image preview to be very usable.
• If this is not good enough, a more sophisticated way to set the white balance would be to manually enter a kelvin temperature (which, unfortunately, only affects the blue-yellow axis, not the green-magenta color), or further tweak the result with the "white balance shift" tool. (Have fun. Who wants to spend time doing that?)
• Finally, the most accurate in-camera result you can achieve would be to use the "Custom White Balance" feature.

Bear in mind that whatever approach you choose, none — not even the custom one — will give you a surgically exact result. The only way to get a better result would be to include a neutral reference in a photo under each light situation, and later use that reference to synchronize the white balance for all the images shot under this type of lighting.

For the most accurate readings, you might include a tool like a WhiBal gray card, which is good to take care of the white balance, or go one step further with an X-Rite ColorChecker Passport, which includes a good ol' Gretag MacBeth color chart as well as the software required to generate camera calibration profiles for Lightroom — serious business!

If you don't want to spend the money (or carry these around, or shoot those test shots), for fairly good results, many common objects will be good enough to get you close to your target and allow you to work without having to worry too much about color. This might be a piece of white paper, tissue, gray hair, etc. It would be pretty hard to judge if these references are absolutely neutral (unlikely), so you understand that those are not perfect solutions. (For example, stuff usually increasingly turns yellow as it gets older.)

But keep in mind that few situations require critically accurate color — you be the judge. (Sometimes, even a perfect white balance won't be enough and colors will have to be manually tweaked in Photoshop with a virtual reference anyway (such as a Pantone swatch), and yet even then, color accuracy will likely take another hit when the image gets to the printer, so this discussion is at least partly moot.)

Now, in those situations where extreme color accuracy will not be an issue, you will have to determine if accurately reproducing the scene is what's important to you. Often, perfect color balance will not yield the image that will look better to your eye — you might very well decide that warming, cooling or otherwise coloring your image will produce something that is more pleasing, whatever light was there the moment you took the picture. You might even decide to convert your images to monochrome, and maybe even to tone them. Yet another reason why you might not need to worry too much about technical accuracy, but more about achieving an image that speaks to you.

For those reasons, on a more practical/pragmatic note, unless critical color accuracy is expected, I will usually save time and use one of the camera presets to get reasonably close results in-camera (so that I can still get useful information out of my histogram and image preview), include a WhiBal in the first shot if there are no other useful neutral references around, and tweak the results in post anyway. If I know in advance that I will deliberately change the look of an image, I might use a different preset (such as using a "cloudy" setting on a sunny day to make the image warmer); this will give me a better instant feedback, even if it won't have any definitive effect on the image until I make the final decision/adjustment in post.

If you still want to perform a custom white balance to get as close as you can in-camera, note that Canon and Nikon employ dramatically different procedures to achieve this (I am not familiar with the way other brands work):

• With a Canon camera, the procedure requires a ridiculous number of steps (which explains why I usually don't bother). You first have to shoot a picture of a neutral reference, filling the center part of the frame with it. You then have to go to the "Custom WB" menu option. You then have to point the camera to the picture of the neutral reference you want to use for the calibration (usually the one you just shot), and then confirm your choice. You then have, each time, to dismiss a non-removable reminder that tells you to change your white balance setting to "Custom". You then have to go ahead and change the white balance setting to "Custom". (Still there?) If this wasn't enough, you'll also be left with an otherwise useless frame, on your memory card, that was shot just for this, which you might want to delete. (Or you'll keep it and use it to perfect the correction in post...)
• With a Nikon camera, the procedure is decisively more efficient (take a hint, Canon). Set the camera to the "Pre" (preset) white balance setting. Hold the white balance button for two seconds until "PRE" starts blinking. Shoot your neutral reference.

If the procedure fails because the camera doesn't want to take the shot, this is because you're in a "one-shot/AF-A" autofocus mode that won't allow you to shoot until focus is obtained. Contrary to what you might have been told, performing a custom white balance does not require the camera to be set to manual focus, but since the neutral reference is usually a plain card, the AF system simply won't be able to achieve focus, which is the reason it will appear not to work. Just focus on something else or set the lens to manual focus — it doesn't really matter, as long as the center part of the frame contains the neutral reference. (If you're shooting in a continuous AF mode, this won't be an issue.)

If the procedure fails with the camera telling you it couldn't perform the calibration, that's because the exposure was completely off: the camera cannot read the color information out of a clipped highlight. Make the exposure average, or use a semi-automatic mode just for that shot (such as aperture-priority).

Make sure you actually do your reading based on the actual light conditions you'll be shooting in... This is especially relevant when you're working with flash — you don't want to perform your studio calibration based on the ambient light, or your location calibration on incorrectly gelled/randomly bounced mixed-light and get results that don't make sense.

Maximum Image Dimensions and Page Size

Alright, we all agree that we want our website to load rather quickly, because we know people aren't going to wait more than a couple of seconds. We also don't want mischievous people to be able to do much with our images. We have to consider the browser size of the bulk of our visitors when determining the size of our website, because we don't want to force them to scroll to see the whole thing.

These are all laudable objectives — I couldn't really disagree with them, in principle.

But 100-120 KB per page at most? 500-600 pixels wide images at most? That, I'm sorry, is based on egregiously outdated standards. Just so you don't have to take my word for it, I visited a bunch of photographers' web sites (they all happen to have blogs I follow) and looked at how large their images were — not the home page image, I mean the average image they present in their portfolio. You'll likely recognize these guys' name — I think they know what they are doing and/or have been professionally counselled.

The smallest images I found were those on Chris Orwig's site, and they were 693 pixels wide. Here's the rest of the random sample I visited:

• Joe McNally, 778 pixels wide
• Zack Arias, 804 pixels wide
• James Rubio, 819 pixels wide
• Drew Gardner, 826 pixels wide
• Chase Jarvis, 920 pixels wide
• Tim Tadder, 940 pixels wide
• Vincent Laforet, 1024 pixels wide
• Joey L, 1064 pixels wide
• Finn O'Hara, 1278 pixels wide

Wait, what? 1278 pixels wide? That's just the image, not even the website itself.

Do you have an idea what a single portfolio section of a site presenting such good quality imagery must weigh? A lot more than 120 KB. Did I have to wait an eternity to see the images, so much so that I thought I should give up and go to another site? Not at all. Do these guys really worry about their images getting stolen? Puh-lease.

I think I rest my case.

More on Image File Formats

Okay, so I'd already covered the key points in my previous post, but let's add some more information.

The idea that the PNG format came from PCs and never really caught on on Macs is simply baseless. The main reasons the PNG format was created were to improve upon the limited GIF format and to get rid of licencing issues (since GIF was patented by CompuServe). If anything, the Linux/free-software/open-source community (which was later, even before the OS X transition, largely embraced/encouraged/supported by Apple) did more for the format than the Microsoft-riddled make-everything-proprietary PCs. Indeed, Internet Explorer only recently got the memo that PNGs had an alpha channel, which is likely the main reason the format couldn't fully be exploited in the first place, hindering it's spread.

The idea that logos, which often use few basic colors, are prime candidates for the GIF format is only partially true. When you create shapes (be it in Photoshop or Illustrator) and convert them to raster images, new intermediate colors have to be interpolated to create seemingly smooth lines and curves — a process called anti-aliasing. The consequence is that even if you're only using few base colors when designing your logo, it might very well end up requiring more colors than can fit in an indexed color file format such as GIF. To be safe, go PNG, which is just as size-efficient, but not 8-bit palette limited.

The suggestion that you shouldn't embed color profiles in images to reduce file size is to be taken cautiously. If we all agree that images on the web should all be converted to the sRGB color space anyway (because we cannot presume color management will be available in the client's browser) and therefore don't decide to include the profile in our web images, well, it shouldn't really be a problem — if the profile is missing, every browser should presume sRGB, just as if color management was unavailable, so we're good. The risk, though, is that we some day forget that an image we export is for some other use (be it for a client, for a commercial printer that color manages, etc.) and then wonder why our images don't look as expected. Seriously guys, a color profile is about 2 KB — that's insignificant in comparison to the whole size of an image. Remove one step in your workflow and always embed color profiles, just in case; it's not going to hurt to do it, but it might if you don't.

The suggestion of creating a slideshow of photos using Photoshop's Animation functionality and exporting it as an animated GIF is preposterous even as a simple example. GIF is, as we know, a monstrously awful file format for photos, because it is 8-bit palette limited and will introduce screaming posterization or dithering. Furthermore, it will create huge file sizes because it is not designed to handle photos. Additionally, it won't allow (in any remotely economical fashion) transitions between images. Moreover, it won't allow any kind of control for the user (stop, pause, forward, back). Frankly, anything else would be a better idea — Javascript, Flash ... you name it.

Output Sharpening

I've already talked about the mistaken idea that the "Save for web" functionality would export smaller files. But what preparing images through Photoshop carelessly will also not do for you is screen output sharpening. Just save yourself the time and effort and error-prone procedure of doing that by hand the olde way and use something like Lightroom. (Or at least create yourself a batch action that also performs basic sharpening.)

Spacers

The dreaded "spacer.gif" (yes, this is the common name, not "single.gif") is a bronze-age-old hack. A trademark of poor code, of lazy development. There are other (better) ways to achieve what this shameless little bugger is doing.

If you don't mind the contempt you'll get for using it and still want to go ahead with the idea, keep in mind that images can be sized any way you want on a web page. This means that you should only create a single one of those darn things, one that is 1x1 pixel, and size it according to your needs on the page. For example, if you need a 600x400 empty placeholder, don't create a separate GIF file for the placeholder, just size your spacer pixel 600x400 at that location!

Alternate Text

You know the "alt" attribute of images? The idea behind that has absolutely nothing to do with search engines. Yes, of course, search engines will use whatever additional data at their disposal to enrich their databases and, hopefully, provide more accurate results. But that was not the motivation behind the "alt" attribute (which is required in strict versions of HTML).

The name says it: it is an alternative to the image, in case the image cannot be loaded or otherwise consumed. If the image is missing or there is any kind of problem, instead of showing the image, the browser will simply display the alternate text. If a blind person visits your website, not being able to see the images, their text-to-speech software will read the alternate text aloud. Therefore, the alternate text should be descriptive of what the viewer cannot see, not just a useless generic name like "image"!

Also, if you're using a spacer pixel (goodness forbid), you should include an empty alternate text (alt=""), otherwise if the text were to be called upon, it could break your design.

General notes on using CSS

CSS is fundamentally based on the idea of economy: the more global and the less specific the better.

What this means is that if you're going to be using, say, the "Verdana" font everywhere on your site,

• Proper CSS would call for defining "Verdana" only once as the font-family for everything in a single, global declaration. No need to mention it anywhere else, since this global declaration takes care of it all.
• Very bad CSS would call for redefining endless times "Verdana" as the font-family in each and every class you create. This not only means puke-inducingly redundant declarations, but also means that if you change your mind about the font used on your site, you'll have to go through every single darned class you've created and modify it. That's just about as far as you can get from the point of using CSS in the first place.

If you're going to use a property "everywhere, but", define a property in a global declaration (probably in the <body> tag or such an overarching location), then make amendments at very specific locations where the rules don't apply. This will dramatically reduce/simplify/tidy your CSS.

On the other hand, if you're going to use a property at a decidedly very specific location, don't define it at a global location, as it will affect every other use of the related tag/class. For example, I cannot see, for the life of me, any good reason to globally add a right padding to every friggin' link on the site if all you want to do is separate items in your footer. By doing this, you'll risk looking perplexed in front of 20 people when you won't understand why your thumbnails don't line up in their cells. Chances are that most links on your site are not going to benefit from a seemingly arbitrary padding on the right, even if some very specific ones might.

While I'm on the topic of padding a link... "Padding" is space inside an element, while "margin" is space outside an element. What this means, in the case of a link, is that even if the two properties would have the seemingly visually identical effect, the padding would make the link itself larger, while the margin would make the space next to the link larger. That is important, because if you're using padding on a link (goodness forbid), the "padded" section of the link would be active (clickable) as well:

Notice how empty space is active (bad!)

That's just wrong. The appropriate property to define, in that case, would rather be a margin.

Redefining Links with CSS

Alright, you want to redefine links (the <a> tag) so that they all look the same, except for the "hover" variant. So you're going to spend a couple of minutes duplicating your half-dozen properties four times in all of these variants so that they are all the same, except for the "hover" which will have a slight difference.

Since you've been reading what I said about global versus specific, you know that's no good. Instead of duplicating every-compound-thing from a:link to a:visited and to a:hover and to a:active (phew!), just redefine the <a> tag itself, once! Boom: all the links will share a set of properties defined globally. Then add only the differences you want to the "hover" variant. You're done. That takes less time and is more economic. Especially if you want to make a slight change afterwards — you won't have to make that change four times.

Lastly, be careful when removing the underline from links. You may want to do it for aesthetics reasons, but good design calls for good usability, not just cuteness. Make sure, if you remove the underline, that links are still obviously links. The underline is such an established standard that you should think twice before you do that — or just do it where it doesn't break usability, such as in a menu where items are obviously selectable, while leaving the underline for links elsewhere in the text. Also, don't use underline on text that is not a link (used purposely here) — that's very misleading.