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!
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 pmOff
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 presentation 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 presentation. 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 (see other differences here). 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 presentation, 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?) The same applies to width, which should be specified in CSS, not in the XHTML code.
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.
6:20 pm0
Web 2.0
The basis of Web 2.0 is not that now "web sites offer services".
The basis of Web 2.0 is that instead of being a one-way communication tool, it now involves the users—it turns them into content providers and allows them to collaborate with each other, which gives birth to communities expanding on viral scales with bandwagon and/or network effect.
Also, there are no "PHP databases" and "SSQL transaction sites"—that's a mix-up of web development technologies terminology.
PHP is an interpreted scripting language more often used to develop dynamic web sites—with or without any database involved. SQL is a database query and management language, while MySQL, MS SQL and others are relational database management software—with or without any web transactions, with or without PHP involved. SSL (not "SSQL") is a cryptographic protocol often used on the web to provide secure transactions.
Close, but not quite right.
8:30 am0
Image sensors don’t have pixels
What they have are photodiodes.
Image sensors are therefore not digital devices, as the photodiodes they are made of are simple analog devices that convert light into an electric current. It is only later that those currents are converted into numerical values via an analog-to-digital converter.
But these numeric values are still not pixels, because each photodiode is only able to capture luminance, not color. One of the tricks to capture color is to place color filters in front of the photodiodes. The most common arrangement of such filters is called the Bayer Filter Array, which uses red, green and blue filters in a mosaic pattern.
Once the sensor has captured the luminance for each of the three primary colors in such a pattern of adjacent samples, the color of each pixel can finally be interpolated through a process called demosaicing.