8:11 am0
On White Balance
So you want to get accurate white balance. There are many ways to get there, if you know why you are doing it and what you want to achieve.
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.
5:30 am1
Another Bunch of Web Concepts
Following a previous post, I kept hearing a discouraging amount of misinformation regarding some web concepts, so I thought I'd do as I did before and add my two cents.
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.
7:04 pm0
Notes on TTL Flash
Since there seems to be a lot of misunderstanding concerning the use of Speedlites (portable electronic flashes), I feel the need to bring some precisions. (Note that although a lot of functionalities, parameters and behaviors are similar from one brand to another, since I am more familiar with Canon equipment, there are times when it will be preferable that you look for additional information.)
What is TTL flash metering?
At first there was manual flash exposure, which meant that the photographer had to know the guide number of his unit and calculate effective distances against apertures and ISO numbers using the inverse-square law bla bla bla... For example, a flash unit with an (imperial) guide number of 100 would correctly expose a subject 25 feet away with an aperture of f/4 (because 100 = 25 x 4). And, oh, that's for ISO 100, and no, you can't see if what you just did was correct, because you're shooting film. Now calculate equivalences along the way, as you're shooting your event. Lots of maths, trial and error (but mostly error). Thank goodness, this era is long gone.
Then there was automatic flash exposure, which was calculated by the flash unit itself using a little photo cell. The flash would emit light and judge if enough had been emitted by the general amount of light reflected back. Needless to say, this was not very precise and could only hope to work when the flash was used on the camera's hot shoe. (Later versions offered a way to separate the photo cell from the flash unit so the flash could indeed be used off-camera, but this only solved part of the problem.)
Then, at last, came TTL flash metering. (TTL metering had appeared long before for ambient light metering, but was now also available for flash exposure.) Instead of letting the flash unit calculate if the proper amount of light had been emitted, it left that job to the camera, using exactly what it had seen "Through The Lens". The thing to remember, though, is that the core addition to TTL flash is not so much the fact that the camera and flash unit now talk to each other using more pins on the shoe (which it obviously has to, to achieve the result), but the fact that the metering is done by the camera, through its lens! The more the camera and flash can talk the better to automate the process and achieve more accurate results, but that doesn't change the core fact of who's doing the metering.
What's the focal length got to do with the flash?
The flash doesn't have to know what focal length is used to work properly, but by concentrating its beam on an area that is not wider than the area covered by the focal length, it can preserve its power that would otherwise be wasted to light areas not even seen by the camera. By doing so, it can actually improve its effective reach and illuminate more distanced subjects. This used to be performed manually with Fresnel adapters installed on the end of flash units, but is now fully automated — insofar as the unit is able to. (As a matter of fact, if you're using very long lenses (in wildlife photography, for example), you might be interested by accessories such as the Better Beamer.)
The image area, when using a longer focal length, is increasingly smaller than the area covered by a flash that doesn't concentrate its beam
The flash's zoom allows it to concentrate its beam to the meaningful area, improving its reach/conserving its power
That's all there is to it! The fact that each flash unit can cover different "zoom" ranges doesn't mean it stops working properly if the lens is set to a longer focal length, it only means it won't be able to concentrate further its beam, therefore not improving its effective range further. There is nothing you can do about it (apart from hooking an accessory to the end of the flash).
Why does the flash ignore the lens' focal length when aiming its beam anywhere but forward?
Well, this should be rather obvious: if you're not beaming in front of you with the flash, then whatever focal length you are using is meaningless for the flash, since its beam is no longer aimed in the same direction.
When you aim the beam to the ceiling, for example, what you're hoping to do is to bounce the light so that the (main) source of light now becomes the ceiling — at this point, changing the flash's zoom would mean beaming a wider or narrower spot on the ceiling, which has absolutely nothing to do with the lens' focal length. Setting the orientation angle of the flash head likely has a much more significant impact on the reach/effect of the bounced light than how wide the beam is on the ceiling, depending on how far it is, etc. Since the camera has no way of knowing how far the ceiling is (or if it is flat, etc.), there is no way it can decide how wide the beam should be. Therefore, it defaults to an average value — not the longest, because a small beam on the ceiling would mean harsher light, which is exactly what we are usually trying to avoid.
You can always change the flash's zoom value manually, if you so wish, but there is no question that linking the focal length to the flash's zoom when beaming anywhere but in front doesn't make any sense.
Additionally, with Canon Speedlites (I cannot comment on other brands, which I don't know as well), when using the included diffuser (the one that retracts inside the flash head), the flash's zoom automatically goes to its widest value — because the point of this diffuser is to achieve an extra-wide angle of 14mm (14mm being the widest lens available in the Canon lineup). This also means that the flash won't be as powerful, since it is spreading its beam much more.
Is the flash metering related to the focus point?
Since I am more familiar with Canon equipment, I cannot confirm for every other brand (check your equipment's documentation), but I would think that the behavior is very similar. With Canon cameras, ever since E-TTL II came along (that's a long time ago, circa 2004), flash metering is no longer linked to the autofocus point selected. This means that you can use the "focus-recompose-shoot" technique freely without worrying that the flash metering will be thrown off.
The metering will also use information from the focus distance (when available — this is a per-lens capability) to calculate its power. This means that if the focus distance is on a subject, it will likely expose the subject properly and pretty much ignore the background (which means potentially leaving it dark). If the focus distance is on a background, it will likely expose the background properly and pretty much ignore the subject (which means potentially overexposing it). Exactly what we would expect, considering that the in-focus area is likely the most important part to light properly.
What is the FEL button doing?
First, we have to understand that regardless of our usage of the Flash Exposure Lock (FEL) function, there is always a pre-flash when using TTL metering. Since the pre-flash occurs right before the actual exposure begins, it is hardly noticeable. (When using rear-curtain synchronization, the two separate flashes will be very obvious, because they will occur before the exposure and right before the end of the exposure, respectively, giving you plenty of time to see the two bursts.)
So the goal of the FEL is not to generate a pre-flash (that, we always get). The point is to lock the flash metering — exactly the way the auto-exposure lock (AEL) works with ambient light, but with flash. Why would you do that? Well, if you don't want the flash to be metered based on the final scene (because there might be something you anticipate will throw off the metering, such as a bright white background or, conversely, lots of black tuxedos in the frame), you can trigger the calculation on a different scene or on a specific area of the scene (by zooming in on a subject's face, or by using a different metering zone pattern, for example) and then recomposing-shooting, which will use the flash metering that was calculated before.
If you're systematically using the FEL before each time you shoot, ad nauseum, without significantly changing the frame, you are wasting your time (and battery power). I hardly ever use that function, but it can be useful in difficult situations — just as much as AEL is with ambient light (which I never use). Instead, I tend to prefer using exposure compensation, which I find more predictable.
Note that here, Canons and Nikons work rather differently. Canon's FEL locks the flash metering only as long as you hold the shutter release half-way (otherwise it forgets the flash metering after about 16 seconds, or very quickly after a shot). A little star (*) appears in the viewfinder as long as the FEL is active, and a new FEL will have to be be performed each following time you need it. Nikon's FEL (at least, the way I was told it worked) locks the flash metering for as long as you don't press the FEL button again — the flash exposure will be the same for all the following frames until you unlock it.
What about exposure compensation?
Like I was saying, I tend to prefer exposure compensation over FEL, because I can better judge how to tweak the exposure than by trying to aim at something that I think would be closer to what I want (good luck!)
There are two ways you can apply flash exposure compensation (FEC). You can either apply FEC on the camera, or on the flash unit itself. With Canon (again, I cannot confirm for other brands), if you apply a FEC on the flash unit, it overrides whatever setting was in the camera. I personally prefer applying FEC with the camera, because I can reach the button right next to the shutter release without even having to move my eye away from the viewfinder, and I see what I'm doing from the display at the bottom of the viewfinder.
To wrap up...
One thing is for sure, working with flash requires practice, because it is much less predictable (especially when bouncing off various surfaces). It gets particularly tricky when mixing flash with ambient light, because now you have two independent exposures to oversee, plus color balancing with gels, etc.
Get to work!
2:52 pm0
Camera Raw Workflow Options
You know that "link" at the bottom of Camera Raw?
Camera Raw Workflow Options "link"
It allows you to change a couple of important Camera Raw options. These settings are not image-specific, meaning that they are not saved in the metadata of a file (be it in the XMP or embedded in a DNG) and therefore cannot be synchronized between images. These settings are global and if you never change them, they will never change from image to image.
With that said, let's look at these options in more detail:
Camera Raw Workflow Options Window
First of all, we have to understand that a raw file is not yet processed, it is not yet a matrix of "pixels", therefore it doesn't yet have a color depth or color space — it is only the end result of the processing that is made to fit inside those constraints.
In order for Camera Raw to present to you a preview of the file as it will look like once processed and to present to you an histogram that is representative of that preview, it has to know to which color space and bit depth you will export the file. (If you've been working with Adobe Lightroom, you know that there is no such option window — that is because Lightroom works natively in ProPhoto RGB at 16 bits/channel and only (optionally) converts to more restrictive constraints when images are exported or sent to an external editor.)
In Camera Raw, you will notice right away that if you choose a smaller color space in the workflow options (say, sRGB), the image preview and histogram will automatically reflect that change: highlights and shadows will be clipped far sooner, as a result of values being constrained to a narrower gamut. Therefore, you should set these options before you start processing your raw file, otherwise you will be mistaken in setting your white point, saturation and other significant values.
Speaking of color spaces...
Different people have different opinions on the matter of color space, but I prefer to work just like Lightroom, in ProPhoto RGB at 16 bits/channel, and only squish image data at the very end of the workflow (usually when exporting images for the web). If you've been reading reviews of the latest inkjet printers, you will know that Adobe RGB is not big enough any longer. Here is an excerpt from a review of the Epson Stylus Pro 7900/9900 printers:
This new ink set is called Ultrachrome HDR and for the first time in an Epson Pro series printer Green and Orange inks are utilized. This actually allows these printers to exceed Adobe RGB in certain parts of the spectrum, by a not inconsiderable margin.
What this tells us is that we don't know what new technology will pop up around the next corner, therefore we should keep as much information in our original files as possible — it doesn't hurt since we're keeping the files in 16 bits/channel.
Speaking of bit depth...
Indeed, there is no question that you should work in 16 bits/channel. 8 bits/channel is generally okay for a final image, but not for one that is still subject to manipulation (since, as we know, manipulation implies loss of information). If you start with 8 bits/channel and manipulate, you will end up with less than 8 bits/channel, and this will likely show up as posterization (especially in smooth gradients) — you know you're in this situation when your histogram has gaps.
That being said, Color Space and Bit Depth are really the only two workflow options you should consider while working in Camera Raw, as they are the only ones that will have an immediate effect — all the others will only have meaning once you export the image out of Camera Raw.
The only time you would play with the other settings (Size, Resolution and Sharpening) is if you were going to use Camera Raw itself to export finished products. I personally prefer to let Photoshop handle that, so I actually never touch these settings (except the first time I open up Camera Raw after installing the Adobe Suite, of course), leaving them as they appear in the screenshot above, for optimal quality.
The problem is that if you change these settings, the next time you open up Camera Raw, you will have to reset them back to the original values — something you are likely to forget, which would mess up your files (more on that later). This constant hassle to reset the settings back and forth depending on the usage of the file (immediate export vs. further work in Photoshop) is enough to make me want to batch process my exports through Photoshop and always leave these options alone to the optimal quality.
To complete our exploration of the options...
As I was saying, unless you're going to, say, export JPEGs for the web directly from Camera Raw, you should leave the Size option to the 1:1 value (no upresing nor downresing). Resizing is better left to the specialists — the algorithm applied here is not as optimal, nor as parametrable as the one you can use in Photoshop. Every resizing calls for interpolation, which means loss of detail, so you should only go through one resizing procedure, if needed, at the very end of the workflow, before you export.
Resolution, as it's been said before, doesn't mean anything until you start talking about printing. Whatever value you put here is meaningless as long as the file in not actualized. Stick to 72 if the file is going on the web (merely because that is the established standard), but otherwise, this number has no effect on the image whatsoever.
Output Sharpening, too, should definitely only be used if you're going to export files directly from Camera Raw. This, too, is a step that should be done at the very end, and is specific to where the file will be going. You don't apply the same sharpening on files viewed on screen vs. files printed on glossy paper vs. files printed on matte paper vs. etc., so you shouldn't apply it at this point if the file will be going to Photoshop for further processing.
To wrap up
Frankly, unless you're going to use Camera Raw to export images directly, to get optimal results, save time and avoid mistakes, I strongly recommend you use the settings shown in the screenshot above and never bother touching them again.
But it gets better...
Wouldn't it be nice if you could just change your mind later, once you're in Photoshop and it's too late because you've left Camera Raw? Wouldn't it be great if every setting in Camera Raw could still be changed later, once you're in Photoshop (and I really mean every setting, not just the workflow options)?
Well, they can, and it's amazingly simple to do! Instead of using the "Open Image" button (which rasterizes the raw file for good), simply hold the "shift" key to turn the button in an "Open Object" button. Ta-dah! You're now working with a "Smart Object": the raw file is now embedded inside your Photoshop layer and can always be edited back in Camera Raw when needed.
Raw file appears as a Smart Object
To bring the raw file back in Camera Raw, simply double-click on its thumbnail, and voila!
Note that this embedded raw file is not linked in any way to the original raw file that was opened as a Smart Object — you could always move the initial raw file or delete it altogether and it would not affect your image in Photoshop. Note as well that any Camera Raw parameters you change when editing your Smart Object will not be applied to the original raw file neither. It really is a copy of the raw file that was embedded inside the Smart Object, not just a link that was established.
7:18 pm0
Expose to the Right (and then some)
Following up on the previous post, where I was making the point that fully embracing the new photographic technologies meant more than shooting raw, I would like to point out to a recent post by Michael Reichmann. His text, from just a couple of weeks ago, was an open letter to Leica, explaining his ideas on how to improve their cameras.
The most interesting part of the letter, for me, wasn't so much Leica-related, but the part where he clearly stated how camera makers (and camera users, by extension) should fully come to terms with the actual behavior of the current technology:
All major digital camera makers seem to be stuck in the film era when it comes to exposure metering and setting. Part of the problem is that consumers want the image on the rear LCD or in the viewfinder to "look right", but looking right and being optimum from a raw image quality perspective are not the same thing. [...] In other words – let's leave the film exposure paradigm behind. Digital exposure is different than film exposure, and basing 21st Century cameras on 19th Century exposure rules has to end.
Well that's all good — we're all familiar with the "expose to the right" approach to optimizing exposure, and that understanding leads us to deliberately use generous exposures in the field, when gathering ambient light.
But what about when we're working in a controlled environment, when using strobes in a studio for example? There, it's as if we suddenly forget the "expose to the right" mantra and rather rely on our flash meters to calculate the exposure. If we want to push the reasoning all the way, shouldn't we reconsider our approach?
Let's consider this very simple experiment. Single Speedlight in a Lastolite EzyBox to camera left, ISO100 at f/5.6. This is what we get (as expected): a "correct" exposure.
Flash Meter at f/5.6, ISO100
I took an item on my desk that contained bright white, so that we can really see what's going on:
Tissue Box at f/5.6, ISO100
Whites are white — no doubt about it. Now let's double the flash power (f/8), but leave the aperture at f/5.6. This is what we get, straight out of the camera:
Tissue Box, 1-Stop Over-Exposure
Overexposed! But of course, this is exactly what we would expect — exposing to the right is supposed to optimize the file, not get the best result straight out of the camera (or on the LCD display, or on the histogram). As a matter of fact, this is what the two histograms look like, without any adjustment:
Histogram Comparison
According to this histogram, we were too enthusiastic and went too far to the right — we know that we shouldn't clip the highlights, because then we can't bring them back at all. To adjust the exposure so that we get (visually) the same result as the first file, I simply pull back the "Exposure" slider in Camera Raw — I'm not even messing around with the "Recovery" hack, there is no need, there is plenty of information in the highlights. Ta-dah! This is the result I get:
Tissue Box, Exposure Adjusted in Camera Raw
Well well. Nothing is clipped now, I get information everywhere from that same file, which was over-exposed by a full stop.
The question is, did this really have any effect on the quality of the image? Well yes it did indeed. Remember that this image was shot at ISO100, so the noise was already pretty low. But by taking a region from the blurred background and bringing up the exposure to get a middle gray (which, obviously, enhances the noise further) and removing any kind of noise reduction there was, we get this result:
Noise Comparison (200%)
I will grant you that, in practice, this would not be much to write home about. But certainly, even in an ideal situation, there is a difference — deeper shadows, in particular, would benefit even more from this 1-stop gain.
Now this is where it gets interesting. Because we know that the "expose to the right" approach has a more obvious impact on the quality of a file in the shadows, and especially when we're dealing with high ISOs, there is another situation where we should definitely apply it.
When we're working in a mixed "flash+ambient light" exposure! In these situations, we normally have large parts of the image in darker tones, and we're usually working with rather high ISOs to get acceptable shutter speeds. The typical exposure is usually somewhere around the -2 stops for the ambient, over which we add the flash. Well, I'll let you work out how you incorporate the lesson from situation to situation, but in the end it should probably look more like -1 stop for the ambient, +1 stop for the flash!
1:24 am1
Camera Raw is not Just an Import Plug-in (Anymore)
Back in 2002, when Adobe Photoshop 7 came out, it featured a new plug-in called Camera Raw 1.0, to provide support for reading raw files. At the time, the functionalities offered by Camera Raw were very limited, and it was used basically as a mere import plug-in for raw files. Camera Raw started to be a more serious tool at around version 3 (with CS2), and by version 4 (with CS3) it had matured into a pretty powerful raw processor.
If you've been shooting for a long time and actually went through the transition from film to digital (I have not), you've had to relearn your post-processing workflow many times over to adapt to the rapidly changing technology. You've likely started to work with digital long before digital cameras (and raw files) even existed, and your basic workflow meant scanning negatives/slides into high resolution TIFF files and going straight to Photoshop to do all the processing. When serious digital cameras came out and you started using them, you've been told that raw files contained much more information than JPEGs (or even TIFFs, for some cameras used to optionally shoot straight to TIFF), so you've gladly begun shooting raw.
Now even you are advocating shooting raw to preserve all the information the camera can capture — which is good — but you may still see the raw processing step as a mere intermediary to Photoshop, where all the serious stuff goes down. You'll say things like "Well, you see, here you have all these sliders that you can play around with to change your exposure, white balance, curves and all — kind of a simplified version of the basic functionalities you get in Photoshop... But, you know, we are all eager to bring that file into Photoshop, a much more powerful tool anyway, so we'll go right ahead and press 'Open'." You'll then lecture on using the Threshold adjustment layer to find your black and white points, using Color Samplers to locate them, and use a Levels or Curves adjustment layer to set the clipping with the black and white eyedroppers — you won't fail to mention that one should probably aim for 10 black and 245 white at most, because printers cannot manage further extremes; you'll add a Color Correction adjustment layer to fix the color cast; etc.
Now that's what is known as old think.
Don't get me wrong; I'm not saying this won't allow you to achieve satisfactory results — go right ahead and use whatever you are more comfortable with. Daniel Malka said it best when he said: "If it looks good, it's good, right?" If you've been looking at Joey L's early work, for example, and have been blown away by the results he achieved, you wouldn't really care to know that his Photoshop techniques were, at the time, profoundly lacking (as even he acknowledges).
But still, if that is the way you see your typical workflow, you are missing out on what raw files have to offer; you haven't fully embraced the digital workflow to the fullest; you have kind of a half-assed approach to image processing that is tainted by your past experience; you aren't extracting all the detail you can out of your files. Even a 16-bit, ProPhoto RGB TIFF file only has a fraction of what the raw file has to offer, for the simple reason that as soon as you leave the raw file, you are working with a baked file: everything you'll do to the image from this point will be destructive, and you'll never be able to extract all the detail that was available in the source file. That's because a raw file has not been demosaiced, it's still in a linear gamma, and all the settings you play with are only parametric: they are not affecting "pixels" yet.
For optimal results, ideally, you should be doing as much of the work as possible on the raw file (be it using Camera Raw, Lightroom or any other raw processor) and only open the image in Photoshop once you've exhausted all the possibilities, for more complex local/pixel-level editing (when needed). Camera Raw and other raw processors now even provide some level of parametric local adjustments (especially since Camera Raw 5, Lightroom 2, etc.), so there is no excuse. The white and black points (referred to as "Exposure" and "Blacks" in Camera Raw/Lightroom) are particularly important, because you cannot recover blown highlights once the image has been baked, no matter the bit depth and color space...
But don't take my word for it. For an excellent primer on the raw processing workflow, you should definitely read the first three chapters of the Real World Camera Raw books by Bruce Fraser and Jeff Schewe — even if you're not working specifically with Camera Raw. (Note that Lighroom uses exactly the same processing engine as Camera Raw.) Or you can always watch one of the comprehensive video tutorials with Jeff Schewe and Michael Reichmann back at the Luminous Landscape.
3:24 pm0
Notes on a Bunch of Web Concepts
I recently heard a distressing amount of inaccurate/flat-out-wrong little pieces of advice related to web development that I would like to comment on. (There were many, so I may have forgotten a couple of them...)
Meta Keywords
I'm sorry guys, but meta keywords are dead. They've been dead for so long that their rotting corpses are past the point of identification. They've been dead ever since Google came along and shook the search engine business by bringing about the idea that relevancy shouldn't be entrusted to the web page developers who define the keywords.
No, they are not entirely ignored, but you should pretty much act as though they were. The title and file name of your web pages are far more important than the contents of the meta keywords, for example.
XHTML Syntax
If you're using Dreamweaver CS4, by default, you're not actually building HTML files, but rather XHTML files — even if you haven't noticed (the file extension is the same).
It used to be that structure and formatting were both defined by HTML code, but for a long time now (say, a friggin' decade), for many good reasons, they have been separated: HTML is strictly used for structure, while CSS is used for aesthetics. This is one of the core ideas behind XHTML, which uses a more strict/restrictive syntax.
That being said, XHTML uses strictly lower cased tags, with a self-closing terminator when the tag is not a container. This means that <META> and <P></P> are flat out illegal — the proper syntax is <meta /> and <p></p>. If you're using some kind of deprecated meta tag builder off a page from the last century that generates pre-XHTML code, you'll have to clean it up before you can use it (which defies the purpose of the whole thing, methinks).
Also, <td align="left"> is another leftover from HTML and is illegal in proper XHTML (the "align" attribute defines the formatting, not the structure!) Let CSS handle that part with an appropriate syntax — something like <td style="text-align: left;">. You got that right: this means that Dreamweaver itself sometimes generates bad code when you use its formatting toolbar. (Are you beginning to see why many web developers prefer working directly in the code rather than letting WYSIWYG software f**k everything up?)
CSS Class Naming
Classes should have meaningful names based on what they mean for the places where they will be used, not based on what they will look like nor on which tag they will be used. For example, you shouldn't have classes that are named .thinborder, .largefont or .redtext, but rather something descriptive of the meaning of the class, such as .menu, .header or .important.
Also, keep in mind that classes can be applied to many different tags, so a class named .paragraphbig wouldn't make sense since you could just as well use that class on a <span> or a <td> tag, for example.
CSS Size Units
So far, you've likely been using the "px" unit when defining font sizes, line heights or margins, for example. "px" stands for "pixels", so whatever value you define using pixels is absolute. This means that if you changed the scale of a web page, items that were sized/positioned using pixels wouldn't move one bit and you'd have to recalculate everything to make them fit. This might be just what you want, if you're using a very precise design of a strictly defined size that you don't want wiggling in any way.
This is often what happens when you're a graphic designer asked to build a web page — you create a template in Photoshop, separate your elements using slices and produce a direct translation from those raster graphic elements to the web without asking competent web developers how they'd do it. Needless to say, there are different schools of thought regarding these practices, but I would tend to think that absolute sizing/positioning in pixels is very often not the best way to look at web design — it goes contrary to the whole open-based/flexible/accessible mission of the web.
Granted, some elements just have to be sized using pixels (raster graphics are not scalable, by definition), but many others should be allowed some leeway! You cannot entirely predict/control what size/behavior everybody else's web browser will adopt, so you should allow your design to be (at least partly) flexible. Also, for accessibility reasons, you should make it possible for other people to enlarge the font sizes of your web site without it crumbling to an unusable/unreadable piece of crap. Go take a look on W3C or Wikipedia, for example, and you'll see what I'm talking about — entirely flexible designs that keep working fine whatever happens to the scaling/font size/window size...
This is where relative size units come in. Say hello to "ex" and "em". I won't bother you with a lecture in typography, but let's just think of 1 "ex" to be the height of the small-cased "x" and 1 "em" the height of the capital "M" of the current font (also, 2 ex = 1 em). Want to have more readable line spacing? Just define the line-height as "1.5em" rather than bother on calculating what pixel size should do it — that'll give you the result you want, whatever the size of the font you defined.
Anyway, look into relative sizes — especially for everything type-related.
Size and Resolution of a Gradient to Use as a Background
Whether you define your gradient image as 1x700 or 20x700 (unless you're using an utterly inappropriate file format — more on that below), it will not have a significant impact on the file size. Let me say this again: whether you define your image as 1x700 or 100000000x700 doesn't really matter, because each row in the image will use the same color, which means that the lossless compression will pretty much do away with it. Here, a gradient 2 pixels high and, horrors!, one 10 times larger, with a whopping 20 pixels high, saved as PNGs:
(3053 bytes)
(3139 bytes)
Like I said, insignificant. Let me also add, by the by, that 3 KB files are not a source for worry, in 2010. Seriously. Bandwidth is so much higher now that unsolicited videos frequently start playing inadvertently in advertisement boxes a the right of pages nowadays — do you have any idea how unbelievably larger a video is, compared to a 3 KB gradient?
And that "resolution" field in Photoshop? Meaningless. Resolution doesn't mean anything until you start talking about printing. Screen resolution is not up to you, because you cannot know what display will be used to view your web page. Just put 72 because that's the standard value we've come to use for screen graphics, but changing that to 300 or 5453982 wouldn't change *anything* to either the quality of the image or its file size: when it comes to displaying graphics on a computer monitor, the only thing that matters is the size in pixels!
Web Safe Colors
News flash: this isn't 1996 anymore!
It used to be the case that computer memory available for the display was so scarce that no more than 8 bits per pixel (not per channel, as you are familiar when working in Photoshop) was available. 8 bits per pixel (256 values total) is so little that you can't really describe much with it, so instead of using the 8 bits to define the colors themselves, they were only used to refer to a table containing 256 colors — that is what is known as using a palette, or a "color lookup table" (or the "Indexed color..." mode in Photoshop).
Color #1 might be a red, Color #2 might be a blue, etc. (the numbers themselves do not describe the color, just the position of the color in the palette). This means that not all colors were available, only a little subset of 256 preset colors in the palette. To be able to display a given color, it had to be available in the palette. But it gets worse, because even if a given color is available in the palette you are using, the next person might not be able to use that color because it is not available in her palette. And indeed that was the case: Windows didn't use the same palette as Mac OS, so you couldn't be sure that a given color would be available.
Long story short: "web safe" colors are a subset of 216 colors that were available both in Window's system palette and in Mac OS's system palette, so you could be sure that it could be displayed (fairly) correctly.
That was a long, long time ago. We're talking about more than a decade here — that's a ginormous number in computer speak. So what should you do? Well in 2010, that's fairly simple: ignore the whole web safe color business altogether! Seriously. I can hardly believe this needs to be said, so grotesquely obvious this should be to anyone even remotely familiar with these concepts.
This is especially ridiculous when it comes to creating a gradient. Think about this for just a second: even if you did use a web safe color for the "end color" of your gradient, realize that every single other color in the gradient would not be web safe! What an utterly pointless exercise! Using web safe colors with the intent of creating a gradient is a completely nonsensical enterprise from the get go.
Using the "Save for Web" Feature
There was a time, a couple of generations of the Adobe Creative Suite ago, when it shipped with a product called "Image Ready". This whole application was discontinued and integrated in Photoshop through primarily its "Save for Web" feature.
What this tool does is it allows you to preview what an image will look like using different web image formats and compare results in terms of fidelity and file size. Instead of guessing what JPEG compression 8 looks like versus JPEG compression 6, and how significant the compromise will be in terms of image size, with the "Save for Web" feature you can find out right away. That's a very practical tool in that sense, because you can "optimize" your choice once you have the means to take an informed decision.
But one thing you have to understand is that whether you end up saving the file through "Save for Web" or through a simple "Save" command, the file size will be exactly the same, for the same given parameters. It just isn't true that "Save for Web" produces smaller files: it just allows you to determine what will be the optimal file format and parameters.
Web Image File Formats
There are three formats universally acceptable for raster (bitmap) images on the web: JPEG, GIF and PNG. Anything else is not guaranteed to be readable — that includes PICT, BMP, TIFF, etc. (There are also vector image file formats, such as SVG, but that's another discussion.) These three formats have very distinct capabilities/properties and should not be chosen randomly: there are situations for which each is more appropriate.
If you're exporting pictures, there's no question that the appropriate format is JPEG. JPEG is to images what MP3 is to music: it's a lossy algorithm that is based on human perception. It retains more information where it is more significant for our human eyes rather than trying to retain 100% technically accurate values, which is not the point when displaying small images on the web. You want to be able to cut on the file size in a way that is optimal for preserving what will allow other people to look at your images, even if it means you'll lose some fine detail (where it is less obvious to the eye).
If you're exporting graphics — geometric shapes and design elements such as logos that use simple shapes and/or few colors — you're likely better off with GIF or PNG. The main difference between the two is that GIF is limited to 256 distinct colors because it uses a color lookup table. If the image you export contains 256 colors or less, you can use GIF losslessly. If the image you export contains more than 256 colors, then use the PNG format which is also very efficient with these kinds of images. (I won't dwell on the topic of dithering...)
GIF also allows to produce animations (you should see the "kitsch" neon flashing in your head by now), but more importantly it allows to use a single "transparent" color — a device that is often useful in a design to make the graphics merge flawlessly with a background. PNG, in fact, is much more powerful in that sense because it allows using a full-fledged alpha channel — kind of like a mask in Photoshop, with variable levels of opacity — so you could do away with GIFs altogether in favor of PNG. The problem is that the alpha channel feature is improperly managed by significant web browsers (god forsaken Microsoft Internet Explorer 6), so you should avoid using the transparency feature of PNG files for web use (unless you want to get into annoying hackery to go around this limitation).
JPEG is absolutely not appropriate for simple graphical design elements, because of the presumption it works under and the compression artifacts it is likely to introduce. The little 2 pixels high gradient I showed you before? If saved in JPEG, it is not only less accurate than the PNG (which is lossless), but the file is actually also many times bigger!
PNG is absolutely not appropriate for pictures, not because it wouldn't retain the quality, but because losslessly compressing a picture is very inefficient. Lossless compression is more efficient with repeating patterns, which a picture is anything but, at pixel level.
GIF is even worse for pictures, because you'd have to use dithering to render a picture, which would be awful and bring back memories of the '90s. Wouldn't want that.
1:28 am0
Exporting JPEGs for the Web from Lightroom
There seems to be quite a bit of confusion regarding the exportation of JPEG files from Lightroom. The "Export" window itself is rather straightforward, but you still have to know which setting is more appropriate for your needs. In particular, three settings may need further explanation.
Screen Sharpening
In a complete image processing workflow, there are commonly three different kinds of sharpening applied at different stages and for very different purposes.
It is important to understand that most of the sharpening is necessary even if one does not want to apply it "for effect", because of various limitations along the workflow. It should be noted that a basic sharpening workflow is not aimed at correcting soft images (caused by focusing error or motion blur), but at maintaining optimal detail in files that already contain as much as they can.
- Capture Sharpening (or Input Sharpening) is applied first and is necessary to restore loss of detail inherent in digital capture. That is particularly obvious when anti-aliasing filters are placed in front of image sensors to reduce moiré, as is very often the case (except on most digital backs, the Leica M9, and others). That is why the default behavior in Lightroom/Camera Raw and other raw processors is to systematically apply at least a basic amount of capture sharpening, which must then be refined manually (depending on various factors such as frequency). Note that this is true only when shooting raw files—shooting JPEGs means that the camera has already applied sharpening, so additional work on the file must be done carefully.
- Creative Sharpening is usually applied locally on specific regions of an image that require it most (such as the eyes and mouth when working on a portrait). This is the only kind of sharpening that is applied "for effect", where the photographer decides whether he wants his image to look natural or more crunchy.
- Output Sharpening is applied at the very end and is totally dependent upon the destination of the image. Luckily for us (and thanks to the work of Bruce Fraser and the guys at PixelGenius), Lightroom makes it incredibly easy to properly perform this task, which used to require a lot of trial and error. The thing is that if the image is going to an inkjet printer on glossy paper, the sharpening applied is not the same as the one applied for matte paper, and is not the same depending on the resolution of the print, and is very different from the one applied for viewing an image on screen. On one hand, inkjet printers inherently introduce a certain loss of detail because of the nature of the technology itself, so some additional sharpening must be applied—sharpening that would definitely look ugly if the image were to be viewed on screen. On the other hand, images need to be resized to be of an appropriate size for viewing on screen, and resizing an image calls for interpolation algorithms, which also means a loss of per pixel detail. This is why Screen Sharpening is required, not "for effect", but to maintain optimal detail when the image is to be viewed on screen.
Applying a "Standard" amount of screen sharpening to JPEG files exported for viewing on a web page is a very good idea—not to make the images look crunchy, but to retain an optimal level of perceptible detail.
Note that whether you intend to export images for the web or to print them, output sharpening is not something Photoshop will do automatically or even offer. When you want to do it yourself in Photoshop, the burden is on you to apply the optimal sharpening for a given destination—good luck! Do yourself a favor and just don't do it that way... Either print/export from Lightroom, or use PixelGenius' PhotoKit Sharpener and skip output sharpening altogether in Lightroom.
Resolution
When exporting images for viewing on screen, the resolution of the file has absolutely no meaning, so whatever value you put in that field has no importance and, contrary to what you might have been told, will have no effect on the exported file—files won't have more or less detail, and file size will not be affected at all. The important factor when exporting files for the web is the size (in pixels), not the "resolution".
Traditionally, images consumed on a computer screen have been set at 72 ppi (so you might as well put that), but that really depends on the resolution of each monitor—something you have no control over when you publish images on the web.
Color Space
If a file is going on a web page, because we cannot know if the browser used to view the image will support color management, we should aim for the common denominator (it won't support it) and choose the sRGB color space (the default presumption when color management is not supported).
The gamut of the sRGB color space is smaller than the gamut of the AdobeRGB (1998) color space, which itself is smaller than the gamut of the ProPhoto RGB color space—that much is true. But "color spaces" must not be confused with "color models".
The fact that most commercial printers offer very limited gamuts has nothing to do with the fact that they work in CMYK (a color model, not a color space). One simply has to have a look at Bill Atkinson's book to realize that commercial printers are technically able to achieve excellent gamuts and color fidelity when they put in the required effort.
In other words, the CMYK color model itself does not define the gamut, so it would simply make no sense to state that "CMYK has a smaller gamut than color space X".
4:56 pm2
Tethered Power Consumption
Does using your camera tethered use more battery power?
Well, in a way, I would be forced to answer: yes, it does—at least, that's what I have observed with my Canon cameras (I can't comment for other brands). It's not so much that the cameras consume more battery power, it's that once the camera is plugged in and recognized by the EOS Utility (in the case of my Canon cameras), it will never go to sleep!
You know how after a while (say, a minute), the cameras will go in "stand by" mode (you can tell, because its top display turns off), consuming very, very little power? (So little, in fact, that I sometimes don't even bother turning them off.) Well, they never do that when they are hooked to the computer, to maintain the communication alive.
You'll notice that if you hook your camera to your computer and never fire a single frame, a couple of hours later the battery will be dead anyway! If you're going to shoot for a full day tethered, I recommend you bring a second battery with you—or, at least, recharge your battery during lunch time...
4:34 pm0
Index Files
It's been said that you should only have one "index" file per website—in the root folder. Well, you should definitely have at least one index file (in the root folder), but that would mean that you would have a structure such as this,
which would have the unfortunate side effect of creating rather redundant links, such as "/portfolio/portfolio.html". Well, yes, thank you, but I expected the portfolio folder to contain a web page for the portfolio!
Quite frankly, for such a simple website, the designer could just as well have opted for placing all the (html) files in the root folder, like this,
with all the relevant assets (such as images) placed in subfolders, of course. It could be argued that, for the sake of being super tidy, well structured, in case the website becomes bigger and assets get harder to manage, that it would be simpler for everything to be clearly separated in subfolders. True. But then for a bigger website, I would argue that assets would probably be managed by a database, not by a folder structure (which is kind of "old think"), so this would not be so important.
Now, if we want a compromise between the two situations, we will come back to the root of this post—index files. It just ain't true that you can't use multiple index files! It's only one index file per folder, not per website. You would get the following, very simple and straightforward structure:
By doing this, you would keep the super tidy structure, and as a bonus, you would also get simple links such as "/portfolio/". Also, if at some point you decide to add features to your site by switching from static html pages to say, PHP files, you wouldn't even have to update links...