4:41 pmOff
Pushing Exposures
It's been suggested that raising the exposure in the raw processor would generate a cleaner file than raising the ISO by the same amount, since the camera doesn't have internal software as sophisticated as the raw processors you run on your computer.
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.
3:09 amOff
Resolution Shmesolution
As I've said before (here, here and here), setting the resolution doesn't mean anything until actualization—that is, until we're talking about printing the image, having it become a measurable object you can hold in your hands. In other words, both detail (quality) and file size are unaffected by the value you set for the resolution until actualization.
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".
7:56 amOff
X Sync Limit
When photographing on location, you might want to use flash to complement the available light, allowing you to have greater control over the exposure of the subject and its environment.
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/250th 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/8000th 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:
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 [...]
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.
12:48 pmOff
Color Models vs Color Spaces
There is a widespread—though understandable, to a point—confusion between color models and color spaces. For example, we'll hear someone saying something like "CMYK is much smaller than ProPhoto RGB", which unfortunately doesn't make sense because it compares apples with oranges, even if there's a certain truth somewhere in there. First, let's look at the concepts.
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:
- The capture device (the digital camera—or scanner, if we're feeling nostalgic)
- The display device we're working on (such as an LCD monitor)
- 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.
2:29 pmOff
Embedding a SlideShow Pro presentation
So you've created a SlideShow Pro presentation to feature some of the images in your portfolio, and now you want to embed it in your website—that is, you want to insert the slideshow in your design, not just point to the standalone web page that the software generated.
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.