Simply put? Nothing.
Well, if that were all I had to say on the subject, this would have to be my shortest blogpost ever… Okay, a bit more info then:
A lot of first time DSLR users are concerned that their shiny new camera delivers files that are “only” 72dpi, while their old point and shoot delivered 300dpi files. Why is this concern unwarranted? Surely 300 is more then 72, and more is better, right?

Wrong

The old wisdom saying is that “300dpi is for printing and 72dpi is for screen”.
There are a few things wrong with that.
First and foremost, the term “dpi” stands for dots per inch. In a digital file there are no dots, only pixels. So the correct term is pixels per inch (ppi).
Also, 72ppi originated as it was the resolution of an ancient Mac monitor. Current monitors have a much higher pixel density: My old 12″ PowerbookG4 for instance has a screen resolution of about 100ppi. Most current screens are somewhere between 80 and 120ppi.

Do the math…

for your screen: Simply measure width and height and divide the number of pixels by the measured values… Tip: Once you found the figure for your screen, be sure to enter it in the PSCS4 preferences under “Units and Rulers, Screen resolution”: That way, the “Zoom, Print size” will show an accurate sized preview.
So, is a 300ppi file better then a 72ppi file?

No difference

If you hadn’t gathered as much from the above, for display on screen, only the display you’re using will determine the “resolution”.
So, a file that contains for instance 500×750 pixels will be displayed at a different size (in inches, centimeters, or whatever you prefer), depending on the screen you’re using to view it. The arbitrary ppi figure set in the file has no relevance whatsoever.

To illustrate that, here is an example: Each file is 500×750 pixels. One is 72ppi, the other 300ppi.

Notice the difference? No? That’s because there isn’t any.

Why use it then?

Because you have to put something in the box: There is no way that Photoshop will allow you to not fill in a value. However, what you put in there is pretty arbitrary. Use whatever you like basically for display on screen.
I prefer to use 300ppi for general use, since then the “image size” dialog box will quickly tell me about how large I can print an image at decent quality. For web, I mostly use 72ppi (unless I forget) since, well, that’s what some people expect…

Some more reading: here

In my previous post, I wrote about Firefox 3.5 “better wait for version 3.5.1″
That version was released today, and I’m sorry to say, It still has its problems:
For one thing, it still doesn’t support ICC V4 profiles.
For another, by default it color manages like Safari does: Wonky: Only images with embedded profile are managed. So you could get problems as described on this page: The image looks different from the background.
On my Mac, it didn’t. What the heck? I hadn’t changed it from the default setting…
No matter what I set in the “gfx.color_management.mode”, it looked like the thing kept managing everything (except when setting “0″ off course). No way to get the images on that page to look different from the background. “Here be dragons” indeed.

But wait, there’s more

The background looked different from the background of the same page opened in (fully colormanaged) Flock 2.5. In fact, the background looks like the page opened in Safari. Yet there was no change on the images with and without profile. Another “what the heck”? I’d already checked that images with embedded profile were color managed…
At first I thought that FF 3.5.1 might be doing a perceptual rendering for screen. That would explain why for instance on my laptop the image I used in the previous post doesn’t clip in FF3.5.1, but clips like mad in Flock 2.5. It should clip; it’s way out of the laptops gamut. However, a perceptual rendering should not be possible from an sRGB V2 profile, and even if it were, it would probably be visible on series of the same image with different color spaces: the Perceptual rendering would be different for each color space… Yet the tagged images here all looked the same. (And all undersaturated)

What’s going on then?

Then I found out (using the OSX DigitalColor Meter) that the image in FF3 measured the exact value of the sRGB original in Photoshops info palette. So here’s what I think was happening:
FF 3.5.1 converts tagged images (so that part is color managed), then doesn’t use the monitor profile (byebye color management). Manually setting the correct display profile didn’t help either.

Cause of the problem

Since it looked like the problem was related to my Monitor Profile, I tried calibrating anew. Bingo! FF 3.5.1 does work as expected as long as I create a “standard” (Matrix based) monitor profile: My previous profile was created using the setting “Create Table-Based (3D) Profile” of my Monaco Optix XR-Pro software, since that gave more accurate results… No idea why FF 3.5.1 won’t use it. This is a V2 profile as far as I know.
Needless to say, there’s a bug report on the way…

A lot of people are confused the first time they save an image for web display: The image looks different in a non color managed browser then it did in Lightroom or Photoshop. One “solution” was to view the image in Photoshop like it would appear in a non color managed application, by going View > Proof setup > Monitor RGB. This would show you how the image would look in a non color managed application on your screen. Still a guess what anybody else would see though, since you’re seeing the difference between the monitor profile and sRGB…

Better

A much better option would be for everybody to browse color managed.
Up until recently, most browsers were not color managed. Safari changed that, and was the first color managed browser for PC. Internet Explorer had provided a color managed browser for Mac OSX before that, but it is discontinued now.

A few new options arrived lately

FireFox 3 is color managed, though the feature is disabled by default. If you enable it, it’s a heck of a lot better then Safari in my opinion, since it fully color manages: It rightly assumes sRGB on untagged images (Safari stupidly assumes Monitor RGB, except on Vista), and it does so for backgrounds as well. So no more Safari Wonkiness…

Firefox gets even better tomorrow, when version 3.5 is introduced. It has color management enabled by default.. There is a bug however when using wide gamut monitors. So those of you on a wide gamut screen, better wait for version 3.5.1…

Easiest way to enable color management in FF3.0, is to use the Add-On. Nice to note that this Add-On also works for Flock, the browser I’m currently using.

OmniWeb 5.1.3 is color managed when set to be in the prefs.

Another color managed browser will be the upcoming version of Google Chrome. Yay!

Join the majority

Looking at the statistics of this blog, about 53% of the visitors use Firefox, 21% use Safari, 19% use IE and 3% use Chrome. So chances are that a whopping three quarters of you could be browsing color managed! That’s a big majority.

Since more and more people will be browsing color managed, the last part of the advise many times given in the past; “web images should be sRGB, without embedded profile“, is no longer valid in my opinion. Also, a lot more people use wide gamut screens, on which non color managed browsing is a horridly over-saturated experience.

Where does Photoshops “Save for web” fit in?

The save for web dialog box changed a bit after CS2, and now also gives you the option to convert to sRGB. In PSCS2, you had to do that manually. It still gives you four different ways to preview your image: The same options you get when you go View > Proof Setup.
What a lot of people don’t realize is that these viewing options can be set for each window separately.

First, let’s see what each option does:

“Monitor Color“: As a non color managed application would show it on your screen.
“Macintosh (No color management)” As a non color managed application would show it on a monitor with gamma 1.8 (ancient): The image appears lighter.
“Windows (No color management)“: As a non color managed application would show it on an sRGB monitor. An sRGB image will look the same here as in the last option. An AdobeRGB or ProPhotoRGB image will appear less saturated.
“Use document profile“: As a color managed application would display it.

What does it look like

For demo purposes, I used an image in ProPhotoRGB that shows a massive amount of clipping in sRGB. I also used my laptop, which has a rather crappy screen, so the differences between the monitor profile and sRGB are obvious.

The window showing the “Original” is set to “Document profile” in all screenshots. Again: You can set the view for all windows separately. So when using “4-Up”, you can compare the original to an approximation a wild guess of what non-colormanaged browsers might show other users.

First screenshot: ProPhotoRGB, without converting to sRGB, Preview set to “Monitor Color”. Horrid, and the reason for many posts on photography forums.

Second screenshot: converted to sRGB, Preview set to “Monitor Color”. Quite a bit off, but does show why you should use sRGB for the web.

Third screenshot: converted to sRGB, Preview set to “Document Profile”. Nice Match.

Note that the image is way out of the Powerbooks gamut. So it appears a lot less saturated in that color space, because it’s clipping like crazy. (Naturally, the screenshots were converted from the powerbook profile to sRGB before posting) Compare the sRGB version below with the one restricted to the Powerbooks displays gamut in the above screenshots.

Additionally, the clipping that’s occurring while converting to sRGB doesn’t show on the Powerbook, since the monitor gamut is smaller then sRGB. On my desktop with LaCie CRT, I can clearly see the clipping when toggling the “convert to sRGB” tickbox. If I were to post this image, I’d correct for that clipping before converting…

So, all in all “Save for web” is a very useful tool that provides not only “WYSIWYG” , but also provides a guess to what others might see.

Lastly, for those interested: Here’s a screenshot of the difference between Gamma 1.8 and 2.2. A good reason to use Gamma 2.2 and I’m glad to say the next version OSX will finally ship with Gamma 2.2 set as default, instead of the legacy Gamma 1.8.