A Smugmug world with color-managed browsers [Sitemap]

jfriend

Nov-25-2007, 08:57 PM

As I've finally begun to understand how color management really works on a Windows computer and I'm seeing some current trends with Safari and Firefox on Windows, I'm thinking that Smugmug may need to start planning ahead a bit for more thorough color management.

Today, we have a situation where all uploaded images are converted to sRGB (if they have a color profile tag other than sRGB) and only the original is left with a color profile as part of the image. All the generated sizes are stripped and are untagged.

When nearly all browsers are dumb and wouldn't know what to do with the color profile tag anyway, that makes some sense. Might as well save some storage space and download time and a little bandwidth.

But, the future is just around the corner. Safari for the Mac already reads color profiles. The latest Safari for Windows beta now reads color profiles. The next version of Firefox (3.0 in developer beta now) already has color management in it. With all this competitive pressure, it seems safe to assume that even IE will add it.

So, you ask, if all Smumug images are sRGB, then why does it matter whether the image has a profile in it or not and why does it matter if the browser is color managed or not?

That's what I used to think until I understood what happens a little better. To understand this, let's look at what happens in Safari when it displays a properly tagged image. First, it reads the profile of the image. Then, it maps those colors in the image profile to the profile of the monitor. This transformation does two things. First, it accounts for the source profile colorspace of the image. So, if it's ProPhotoRGB or AdobeRGB (wider gamut images), the color numbers in the image are interpreted properly for that color space. Second, it reads the monitor profile and understands it's display bias so that the properly interpreted source RGB numbers can be transformed into something that will display properly on the particular monitor with it's profile.

Now, what happens when this same Safari browser encounters an untagged image. It basically decides that it really knows nothing about the color space of this image so rather than doing any converting of it, it just sends the RAW RGB values from the image right to the screen. If the image is indeed sRGB (even though it isn't tagged as sRGB which is the case in Smugmug's generated image sizes), then the image won't be way off because most displays are relatively close to sRGB. But, Safari will also skip converting the image to the monitor profile, so unless your monitor is perfect sRGB, you will not get an ideal display of that image. The image in Safari will not look like it's original did in Photoshop or Safari. This will be a bummer. Depending upon how far your monitor is from sRGB, you will see shifts in the image colors. If the image was properly tagged as sRGB, then Safari would understand it as sRGB and properly take into account your monitor profile and then Smugmug down-sized version would display exactly the same as the original.

But, you ask, how does display calibration fit into this? If you calibrate your display to sRGB, won't that fix all this and the image will display perfectly? The answer is no. As I discovered recently, calibrating your display is more about creating a monitor profile that accurately describes what colors your monitor produces than it is about actually adjusting the colors of your monitor to some standard. So, a fully calibrated monitor will not necessarily be a perfect sRGB monitor. But, if color-managed software that reads it's monitor profile is used, that software can take any image in a known standard color profile and (within the limits of the gamut of the display), use that monitor profile to understand the display bias of the monitor and adjust what it sends to the monitor to get near perfect rendering of something like an sRGB source image. If the monitor profile is not used, then the image is not adjusted to take into account the biases of the display and you do not get proper colors. On a quality display, these biases won't be huge, but they will still be noticable.

So ... the consquences of display an untagged sRGB image in a color-aware browser like Safari or Firefox 3 is that the monitor profile is not used and the display of the image is NOT adjusted for the biases of the monitor. The image colors are degraded, even when the source image was sRGB. Add the tag in for sRGB and Safari now uses the monitor profile.

You might ask, why does Safari not use the monitor profile when the image is not tagged. I don't know why they did it this way, but it is the way it is and it's been that way on the Mac for a long time so it's unlikely to change so we just have to deal with it that way. I can understand some logic that says if we don't know what colorspace it's in, then we really shouldn't muss with the colors at all and that's what it is doing. The unfortunate side affect of this is that the image appears to be treated as if it's tagged with the monitor profile, not sRGB. I say this only because an image that actually was tagged with the monitor profile would need no adjustment to be sent to the monitor which is what Safari does when there'sno profile. If those two (sRGB and the monitor profile) are not exactly the same which they almost never are, the image renders wrong.

You might wonder about monitor profiles. Do you only have a monitor profile is you have profiled your monitor with a hardware profiler like Eye-One Display? No, nearly all display manufacturers offer a "stock" monitor profile that describes their typical monitor performance. If you buy a whole system from someone like HP or Dell, your system should come already installed with that OEM monitor profile. It's probably not that far off, particularly when the display is new and your lighting conditions are not unusual. If you buy a separate monitor, it will either come with a CD or you can go to the manufacturer's web-site to get their monitor profile and install it into Windows as the monitor profile. So, many systems these days do have workable monitor profiles, even when they have been custom profiled/calibrated. So, what I'm talking about here affects even non-calibrated displays.

Is this as clear as mud now?

So ... this is a very long winded technical explanation because I'm recommending that Smugmug look ahead to the days when many browsers in use are color managed and asking them to start including sRGB color profiles on the generated image sizes, particularly the larger sizes. I know the arguments about keeping it off thumbs in order to save download speed, but it seems like it needs to be on the main images. Heck, this is a site for displaying photos and Smugmug should be displaying the larger versions of the photos with as much color accuracy as possible. When a viewer has a color-managed browser, that accuracy requires that the image have a color profile attached.

Smugmug could wait until most browsers are color-managed before adding this, but that would be lagging the marketplace rather than leading it and by then, tens of millions more images would have been uploaded and generated at Smugmug without color profiles attached. I think they should lead in this regard and get it right early on.

Thoughts?

onethumb

Nov-25-2007, 09:04 PM

Baldy

Nov-25-2007, 10:01 PM

jfriend

Nov-25-2007, 11:12 PM

Good post, John. We've been talking about this internally with Safari's move to Windows and FF3.

A year ago I had some correspondence with the Safari team that led me to believe they were going to assume sRGB if the image is untagged, which is so utterly logical. I have to believe 99.99% of all images on the web are sRGB and you're never gonna see CNN and eBay attaching profiles to their images.

There's even an easier fix: ship the Mac with a 2.2 gamma. As configured by the factory, Macs don't render photos without ICC profiles accurately, nor do they render Flash, CSS, or HTML in the colors the artists intended. Apple tells you in their help sections to set your gamma at 2.2 so that the Internets won't be busted.

I feel like Bill Atkinson and I could drive to Apple, meet with Steve for 30 minutes, make our case for why 1.8 gamma is a mistake, and he'd make the Mac and Safari compatible with the Internet (and compatible with iPhone and Apple TV).

Bill worked for Apple when they chose 1.8 gamma to make things look right on some grayscale printer everyone has forgotten now. And I worked at NeXT when we chose 1.8 because Apple did.

I was at a party last night showing photos on my iPhone over AT&Ts slow network (I noticed you spoke broadly about Safari--do we know how iPhone Safari does color management?), and I was thinking, "Great. We're gonna add ICC profiles to make this even slower. And we're doing this why? Because some Apple products have an archaic gamma?"

John, what about Andrew Rodney's contention that this is the year for Adobe RGB so converting to sRGB is the wrong thing to do in the first place?

My post didn't really have anything to do with Apple's 1.8 gamma. I followed that issue when you guys raised it awhile ago and it does seem like Apple is just wrong there. But, what I was writing about had everything to do with all the Windows computers that will get better color display when images have profiles and the viewer has a color managed browser. Even on my brand new 30" HP monitor that is fully profiled with Eye-One Display2 on my new Windows Vista computer, a Smugmug JPEG in Safari has it's color shifted versus Photoshop looking at the full original with ICC profile. That's because my monitor isn't perfect sRGB. Photoshop uses the monitor profile to make minor corrections before display. Safari does not use the monitor profile because it doesn't see any ICC profile in the Smugmug JPEG. So, even without the gamma problem, there's still a color shift that occurs because of the missing ICC sRGB profile.

I don't know what Safari on iPhone does for color management. It is supposedly largely the same code base as on the Mac so they would have the option of implementing color management if they chose to.

If the world could get Safari and Firefox 3 to both treat an untagged image as if it really was tagged with full-on standard sRGB (so that it still uses the monitor profile), then you wouldn't have to add the inefficiency of adding sRGB profiles to all images and all existing images that are already untagged could immediately get better in a new browser. That would be best. I did not assume that it was possible to effect that kind of change so that wasn't in the gamut of the options I considered. If you think that is possible, then that's definitely the best option. I wonder what Firefox 3 has currently implemented (or plans to implement) in this regard.

I do think that once we have more color-managed options in use on the web, we will start to see more use of AdobeRGB on the web in some settings It won't be broad at first because adoption of color-managed browsers won't happen overnight, but I'd expect that it would start to pop up more than it is today. I could see a transition state where EZPrints starts accepting AdobeRGB images and you start keeping originals as AdobeRGB and just converting to sRGB for web display sizes, preserving the extra colors for printing which are thrown away today, but also preserving sRGB interoperability for the masses.

It was only a few months ago that I broke my own full sRGB workflow and started to use ProPhotoRGB or AdobeRGB when I'm working on an image for my own printer (I just recently upgraded my own home printing capabilities) because it can definitely handle colors that exist in some of my images, but are outside of sRGB. I would think some Smugmug pros would want to start doing that too at some point in the near future without having to give up on using Smugmug for print fullfillment. Today, they can't do that. It's Smugmug with sRGB or AdobeRGB and no Smugmug.

Until there's a reasonable penetration of color-managed browsers out there for Windows and until your printing services accept AdobeRGB images, I think you're doing the right thing by continuing to convert uploads to sRGB. The Windows world is not yet ready for AdobeRGB on the web. But, when those two things do happen (and I now believe they are going to happen), I think you will have a meaningful percentage of your higher-end users that will be looking to take advantage of AdobeRGB in Smugmug and you will want to be able to offer that rather than have them look elsewhere. Even then, it's probably an opt-in kind of feature where a user has to "turn it on" before you stop converting because you will need the user to tell you that they understand what they are doing.

Can you get Apple to change Safari's behavior to truly assume sRGB when there's no profile? That would be great! It could probably lead to a Domino effect with Firefox and eventually with IE too.

I would guess that Firefox 3 is early enough in the game that if we found the right folks who are championing color management in Firefox, they would listen to a good argument, particularly since it's not a lot of code to write, just a small logic step.

jfriend

Nov-25-2007, 11:19 PM

I'm afraid I just did something I *never* do: I skipped reading a jfriend post entirely.

Why? Because I'll bet that huge post was asking us to add sRGB ICC profiles on our images.

If I'm right, we've been looking very closely at this for quite some time (http://blogs.smugmug.com/don/2007/02/14/this-is-your-mac-on-drugs/). The only logical conclusion, given the mess the browser and OS manufacturers have left us with, is to embed the profiles and say "screw bandwidth and speed, they keep getting faster and cheaper anyway". We're a very logical company, so I'll let you draw your own logical conclusions. ;)

If I'm wrong, I apologize. Tell me so and I'll go back and read the post. :)

What I wrote about is related to the Mac gamma issue, but there is still a problem even when the display is set to the right gamma and this problem occurs even on Windows computers that don't have an incorrect gamma alignment. It's related to the fact that when Safari (even Safari on Windows) encounters an untagged image, it does not use the monitor profile when displaying that image. If the monitor profile is not a perfect sRGB (which most are not), then you get a color shift when looking at an untagged sRGB image versus a tagged sRGB image because the untagged image is not color corrected for the monitor profile. This is what I discovered in Safari for Windows. This is a bummer for displaying accurate color.

There are two ways to fix this. 1) Get all color-managed browsers to treat untagged images as full sRGB and properly use the monitor profile when displaying them or 2) Make all the images have proper sRGB profiles so the browsers will do the right thing with them. Either can work. I know Smugmug can do #2 itself on it's own images. #1 requires getting Apple, Mozilla and ultimately Microsoft to do the right thing in their browsers. That, I have no sense for whether it's possible.

Baldy

Nov-25-2007, 11:43 PM

We might have better luck getting to the Firefox team than to Apple. Maybe if they do the right thing, it will put pressure on the Safari team.

Interfacing to printers is growing more challenging because there are more of them (like Blurb and Fotoflot) and because they're offering more products via inkjet (canvas prints, photobooks...).

If wishes were horses...we'd be able to attach profiles on the fly depending on the user agent.

jfriend

Nov-26-2007, 10:37 AM

do we know how iPhone Safari does color management?)

If someone with an iPhone wants to visit this page http://www.color.org/version4html.xalter and report the results, that would give us the first info on whether iPhone/Safari is color-managed.

You should also remember that an Edge iPhone doesn't need to be the mobile design target for the next few years. I've got to believe we'll see HSDPA iPhones in 2008 sometime and that's a more meaningful mobile download speed design target for the next few years.

Since you're using Flash now for slideshows, does anyone know what Adobe's plans are for color management in Flash?

Sheaf

Nov-26-2007, 11:11 AM

If someone with an iPhone wants to visit this page http://www.color.org/version4html.xalter and report the results, that would give us the first info on whether iPhone/Safari is color-managed.

"The system does not support these ICC profiles."

arodney

Nov-26-2007, 05:30 PM

But, the future is just around the corner.

The future is wide gamut displays that don't resemble sRGB behavior. Now all the browsers that don't understand color management will really be messy.

Now, what happens when this same Safari browser encounters an untagged image. It basically decides that it really knows nothing about the color space of this image so rather than doing any converting of it, it just sends the RAW RGB values from the image right to the screen. If the image is indeed sRGB (even though it isn't tagged as sRGB which is the case in Smugmug's generated image sizes), then the image won't be way off because most displays are relatively close to sRGB.

I don't know about the Windows version, but on the Mac, Safari (all Apple software) assume untagged documents are in the display profile color space. I'm not super happy about this because in previous versions of OS X, we could actually tell ColorSync want to assume. We can't do that any longer so it seems like a feature lost. I'd prefer, for the time being that untagged documents be considered sRGB.

Note, in Photoshop, the selection of a working space in the color settings is our mechanism for telling Photoshop what to assume for untagged documents. So if you set say, Adobe RGB (1998) as your RGB working space, all untagged RGB documents are assumed to be in that color space for previewing and conversions. It would be useful if, at the operating system level, we could do this with all or other applications.

But, Safari will also skip converting the image to the monitor profile, so unless your monitor is perfect sRGB, you will not get an ideal display of that image.

There's no conversion going on here. A conversion is taking one set of RGB values in one color space and converting it into another. What we want to do is leave the RGB numbers alone and alter the assigned profile.

Also, you're going to be very hard pressed to ever find a true sRGB behaving LCD display. The sRGB color space is one based on a theoretical display, one using P22 CRT phosphors. They have very complex tone response curves, not simple gamma behavior. So, its not a good idea to assume you have a true sRGB display. You probably do not. It may have the gamut boundaries of sRGB but that's about it.

Depending upon how far your monitor is from sRGB, you will see shifts in the image colors. If the image was properly tagged as sRGB, then Safari would understand it as sRGB and properly take into account your monitor profile and then Smugmug down-sized version would display exactly the same as the original.

Safari is just operating like Photoshop and all other ICC aware applications. For this to happen, the application needs to understand what the RGB color space is and what the display profile is. That's done with two ICC profiles (or, if no profile, then there is that assumption about what the RGB numbers represent).

But, you ask, how does display calibration fit into this? If you calibrate your display to sRGB, won't that fix all this and the image will display perfectly?

Not really. And its not necessary (or really possible) to calibrate the display to this very exacting definition. Its actually easier. All you need to do is have an application that looks at the display profile and provides a unique compensation for that exact display. Think of it like having a set of CC filters you place over YOUR unique emulsion of film such that when its processed, it provides the correct color appearance. This is called Display Using Monitor Compensation. Every users display undergoes a unique compensation based on the display profile. So you don't have to try to force a display into a fixed behavior that's probably not possible. You have an application that "knows" the document is in sRGB (or any color space) and a display profile. It can then filter the signal if you will, such that the RGB numbers preview correctly. And better, the SAME RGB numbers on your display and my display, which are both different, preview the same way.

As I discovered recently, calibrating your display is more about creating a monitor profile that accurately describes what colors your monitor produces than it is about actually adjusting the colors of your monitor to some standard.

Exactly, this is what Display Using Monitor Compensation does. The profile is far more important than the actual state of the display. The profile needs to correctly "fingerprint" the behavior.

So ... the consquences of display an untagged sRGB image in a color-aware browser like Safari or Firefox 3 is that the monitor profile is not used and the display of the image is NOT adjusted for the biases of the monitor.

Its RGB mystery meat. Not only isn't the display profile being used, the RGB numbers are undefined. This browser sees say R23/B128/G98 the same if the document is in sRGB, Adobe RGB or ProPhoto RGB. It has a set of numbers, but not the SCALE of the numbers (the color space).

The image colors are degraded, even when the source image was sRGB.

I don't love the word degraded. Undefined is better. Its like someone speaking a language you don't understand.

You might ask, why does Safari not use the monitor profile when the image is not tagged. I don't know why they did it this way, but it is the way it is and it's been that way on the Mac for a long time so it's unlikely to change so we just have to deal with it that way

Safari does use the display profile, it just doesn't really know what to assume for the untagged document. As I said, in Photoshop (and older versions of OS X) you the user could tell the application this. "IF you get an untagged document, assume its sRGB or My display profile or ProPhoto RGB." if the assumption is correct, the preview is correct. Again, you need two ICC profiles to produce any kind of conversion (even for the display which is a soft proof): the source (this document is in this or that color space) and the destination (now show me the numbers as they should appear on this device. Assume sRGB as the source, use the display profile as the destination. You always have to have two profiles.

I can understand some logic that says if we don't know what colorspace it's in, then we really shouldn't muss with the colors at all and that's what it is doing.

If you don't know the color space, you have to guess, the guess is either correct (color appearance is correct) or its not (color appearance is incorrect).

The unfortunate side affect of this is that the image appears to be treated as if it's tagged with the monitor profile, not sRGB.

Yes, I can say on the Mac, with Safari, untagged documents are assumed to be in the display profile color space. Kind of dumb.

You might wonder about monitor profiles. Do you only have a monitor profile is you have profiled your monitor with a hardware profiler like Eye-One Display? No, nearly all display manufacturers offer a "stock" monitor profile that describes their typical monitor performance. If you buy a whole system from someone like HP or Dell, your system should come already installed with that OEM monitor profile. It's probably not that far off, particularly when the display is new and your lighting conditions are not unusual.

Here I disagree. Of all the canned profiles, those that are often totally useless are display profiles. Displays are very unstable devices. They alter their behavior over time. They get weaker (in terms of luminance) as they age. If you alter any control on the display, the profile you thought described this display is now useless. Canned display profiles are useless.

jfriend

Nov-26-2007, 10:09 PM

The future is wide gamut displays that don't resemble sRGB behavior. Now all the browsers that don't understand color management will really be messy.

It sounds like we all agree that it's dumb for Safari on both Mac and Windows (I can confirm it works this way on Windows too) to assume the monitor profile for an untagged image. While anything is a guess, the monitor profile is almost never a correct guess and sRGB would be a correct guess quite often on the web. Andrew, do you have any idea why Apple insists on doing it this way? Or how to influence them to change it?

The point of my original posting was to make a case for Smugmug including ICC profiles in the generated image sizes (except maybe the thumbs) so that color managed browsers can do the right thing. What do you think of that direction Andrew? It has the cost of more storage space for Smugmug, increased bandwidth usage and a little slower image download.

Also, is it possible to include an sRGB tag in an image that identifies it as being in the standard sRGB profile without including the actual profile and its multiple kbytes? That is Smugmug's conundrum. They don't want to slow down the web experience by having large ICC profiles in every image if they don't have to. I know it would be technically possible because the sRGB ICC profile is a standard and is known, but I don't know if the standard file format allows for that or if the software that reads it (like Safari) would understand just a single tag without the whole profile. If something like this is possible, that would be the best of both worlds. The image would be tagged sRGB, but wouldn't grow a lot in size. Any idea if this can be done? Or does the entire ICC profile have to be embedded even though it's the same in every sRGB image?

It's an interesting coincidence that you should drop into this thread Andrew because I just read through your color management book on a 6-1/2 hour flight. I recognize the phrases in your response from the book: "mystery meat", "Monitor compensation", etc... I actually bought the book some time ago, but it sat unopened for a little while. My recent foray into trying to solve some of my color management issues and set up a new monitor, computer and printer got me to crack it open.

The first half of the book is a good read. I haven't advanced to making custom profiles for my printer or camera or scanner so I wasn't ready for some of the later chapters.

I already had accumulated a decent basic understanding of how all this works and I used the book to fill in the gaps and I enjoyed hearing a little bit about how Photoshop evolved over the years. The best part for me was the discussion of rendering intents because I didn't really understand the differences between them. I would have enjoyed some sample images that illustrate what kinds of images match up well with the different rendering intents. You described it in words, but a few pictures could have been powerful.

I'm amazed at how messy it is to get all this right as a user. Though color management has been around for a few years now, it still seems like the software is in it's early childhood. I understand how it all conceptually works so I can now do it, but this is not something that most our our population can easily master. Our software is still really in the dark ages. It sounds like the Mac is a little better than Windows, but both still require you to know a lot in order to not make mistakes and to get things configured properly. I was really surprised at how much manual setup you have to do just to get a home print made that has Photoshop managing the colors, has the right paper/printer profile, has color management off in the print driver, has the right media type selected in the print driver for the right ink strategy, has the right options selected in the driver for the highest quality photographic print, etc....

It seems like I should be able to pick my paper by manufacturer and paper type, have it automatically fetch the ICC profile from a web service if it's not already local, tell it I want the highest quality photographic print for that printer/paper combination and say go. The combination of Photoshop, print driver and OS should do all the rest of the coordination. No such luck.

jfriend

Nov-26-2007, 10:45 PM

"The system does not support these ICC profiles."

Hmmm. No color management on the iPhone I guess. Perhaps not surprising, but too bad.

arodney

Nov-27-2007, 06:54 AM

Andrew, do you have any idea why Apple insists on doing it this way? Or how to influence them to change it?

I don't know why, its a silly concept that nearly every color geek I know dismisses. It will hurt a lot more when we all move away from sRGB. That's going to be a few years. And no, you don't influence Apple! That's why Aperture is kind of a mess and Lightroom, built by a company that does ask users their opinions is doing so well. That's another story.

Also, is it possible to include an sRGB tag in an image that identifies it as being in the standard sRGB profile without including the actual profile and its multiple kbytes? That is Smugmug's conundrum.

There's probably some EXIF tag that is could be used but would Safari use it? And we're only talking about 4K of data (the sRGB profile). Yes, I know when you're talking about millions of images, it adds up. Still...

They don't want to slow down the web experience by having large ICC profiles in every image if they don't have to.

4K isn't going to. Jeeze, lower the size limit of images by 5K and compensate. This is a non issue IMHO.

Andy

Nov-27-2007, 07:17 AM

4K isn't going to. Jeeze, lower the size limit of images by 5K and compensate. This is a non issue IMHO.

It had been a huge issue in the past. People want speed, fast pages. But now, connections are faster and it's less of an issue. But still, you could be talking about a hundred thumbs on a page and a huge main image, if your display is big enough, and that's now 400Kb :)

But we still hope to do it.

arodney

Nov-27-2007, 07:27 AM

It had been a huge issue in the past. People want speed, fast pages. But now, connections are faster and it's less of an issue. But still, you could be talking about a hundred thumbs on a page and a huge main image, if your display is big enough, and that's now 400Kb :)

But we still hope to do it.

What you do is leave the profiles off the thumbs (which I assume you build from the original higher rez images) and embed the 4K in the larger images where proper color appearance is key.

And even 400K, short of someone on dial-up (why are they looking at images?) isn't a huge, big deal.

This reminds me a bit about what I saw on the news the other day regarding digital TV signals starting in 2009. Those old Rabbit hears will not fly. What busts my gut is the US Government is going to pay for decoder boxes and adds to let people know about them. As if watching TV is as necessary as electricity and water. Anyway, progress moves us forward. I don't know that we can account for every person who insists on using really really old technology (like dial up). And I live in the boonies, I only got high speed 3-4 years ago.

jfriend

Nov-27-2007, 11:19 AM

There's probably some EXIF tag that is could be used but would Safari use it? And we're only talking about 4K of data (the sRGB profile). Yes, I know when you're talking about millions of images, it adds up.

I agree. If it's only 4k, then just add it to the main images M, L, XL, XL2, XL3 as we know that would work for all future color-managed browsers and will work in Safari today and Firefox 3 tomorrow without having to influence anyone to change. When the world starts moving past sRGB, the full profile will need to be there anyway.

It might be worth an experiment to see if the EXIF tag for sRGB could work. Support for that might be less sound so perhaps Smugmug only uses this tag on thumbs so if the browser understands the tag, then even the thumbs get color-managed to sRGB so they get monitor compensation.

For all the existing Smugmug images that don't have this tagging, it's probably worth a foray to find out what the Firefox 3 implementation is doing and try to influence it to assume sRGB if no tag. Heck, we could probably even find someone to contribute the few lines of code that are probably involved to do this right.

jfriend

Nov-27-2007, 09:53 PM

Here's some relevant info I found by doing a little experimentation and poking around with Google:

In a test of one image I had lying around that does not have an embedded ICC profile, but does have the EXIF tag set to sRGB, it does not look like the Safari for Windows beta does monitor compensation in this situation. If I load this image into both Safari and Photoshop, they do not look identical. If I then save the sRGB profile into the image in Photoshop and then look at it in Safari and Photoshop, they are identical. So Safari is not looking at the EXIF tag for sRGB. Darn, that would have been nice since that tag is only a few bytes long.

Here's the Firefox page that discusses color profile support in Firefox 3: http://www.mozilla.org/projects/colorsync/.

There are some interesting things in the Firefox page. For one, they are supporting the specification of a color profile in both the <*body*> tag (affects the whole page) and in an <*img*> tag (affects just that image). This means that the icc profile can be downloaded once when first specified and then cached for all subsequent uses. This could solve the storage and bandwidth issues and even make it practical to specify it for thumbs - if other browsers are going to support this too.

Further, this posting (http://lists.apple.com/archives/colorsync-users/2007/Feb/msg00188.html) from the Apple colorsync mailing list seems to say that Safari already supports the iccprofile attribute on the <body> tag. I haven't tried it to verify. That might be a promising way to go since Firefox 3 is also going to support it and this would cause thumbs to render properly without having to include the iccprofile in each image.

And, there's a proposal to add ICC profile support (http://www.w3.org/TR/css3-iccprof#icc-color) to CSS too.

arodney

Nov-28-2007, 06:42 AM

For one, they are supporting the specification of a color profile in both the <body> tag (affects the whole page) and in an <img> tag (affects just that image).

This is really the way to be working, describe the entire page, not the individual images.

jfriend

Nov-28-2007, 09:16 AM

More info on the Firefox 3 implementation.

According to the bug (https://bugzilla.mozilla.org/show_bug.cgi?id=16769) that is the tracking/discussion vehicle for the new feature in Firefox 3, all untagged images will be assumed to be sRGB and will get monitor profile compensation.

This is a quote from the bug: "The current implementation assumes sRGB on everything (excluding plugins -- which we don't touch) that isn't tagged and transforms those colors to the monitor profile."

There's also some discussion in that bug about why Safari doesn't assume sRGB and do monitor compensation for untagged images. It had to do with matching colors with Flash.

There's also a curious comment that suggests that Safari is going to start assuming untagged content is sRGB and applying monitor compensation to it, but not until Flash gets color management. I have no idea when that is.

It is unclear whether Firefox 3 will ship with color management enabled by default or not.

jfriend

Nov-28-2007, 09:38 AM

jfriend

Nov-29-2007, 08:37 AM

Hmmm. Appple says here (http://www.apple.com/macosx/features/300.html#imaging)that with Safari in Leopard, Safari now does recognize the sRGB EXIF tag used by most popular digital cameras. This implies that it apply color management when just the EXIF tag is present on Mac. Since these Mac features seem to be coming to Windows, perhaps a future beta release on Windows will have this too. I don't have a Mac with Leopard to try it on.

As I was thinking about this further, if Safari in Leopard really does recognize the sRGB EXIF tag and do monitor compensation when it sees that tag, it seems like this IS the solution to the Mac 1.8 gamma issue for Safari. Just put that single, tiny EXIF tag into all images and Safari should do proper monitor compensation. That isn't the solution to the larger issue I posted about here (I want a solution for that on Windows), but it might solve the particular Mac gamma issue for Safari. Further, it's probably not hard to influence Firefox 3 to do the same since they are already discussing it and probably just need some more nudging and seem interesting in learning from what Safari does.

jfriend

Nov-30-2007, 08:23 PM

Woah. I have full color management in Safari on one of my Smugmug galleries. The gallery images seem to now have sRGB ICC profiles on them. Is this an experiment? A change taking place?

This XL2-sized image (http://jfriend.smugmug.com/photos/184782829-XL-2.jpg) has what appears to be full EXIF data on it (which is very cool). It is showing a wide range of fields including description, keywords, most of the regular shooting data, etc... I think it's everything that was on the original. I checked a couple other images in that gallery and they appear to have EXIF on them too. I checked a different gallery in a different account and no data there.

Even more amazing, that same image as an sRGB color profile on it and is now properly color managed with monitor compensation in Safari for Windows. Safari for Windows now looks exactly the same as Photoshop. Very Cool!

Is something being changed here that will apply broadly (this would be a cool change)?

Sheaf

Dec-28-2007, 01:50 PM

...We've been looking very closely at this for quite some time (http://blogs.smugmug.com/don/2007/02/14/this-is-your-mac-on-drugs/). The only logical conclusion, given the mess the browser and OS manufacturers have left us with, is to embed the profiles and say "screw bandwidth and speed, they keep getting faster and cheaper anyway". We're a very logical company, so I'll let you draw your own logical conclusions. ;)

Logic has won out. We now embed the profiles in all images larger than "thumb" size.

As with SmugMungous, we only do this on images that get processed from here on out.

jfriend

Dec-28-2007, 02:36 PM

Logic has won out. We now embed the profiles in all images larger than "thumb" size.

As with SmugMungous, we only do this on images that get processed from here on out.

Totally awesome! Thanks. Now, I'm going to have to switch to either Safari or the color managed Firefox beta.

What's the best way to trigger profiles being added on important galleries? Double rotate?

timnosenzo

Dec-28-2007, 05:19 PM

Logic has won out. We now embed the profiles in all images larger than "thumb" size.

As with SmugMungous, we only do this on images that get processed from here on out.

WooHoo!!! :clap

Baldy

Dec-29-2007, 12:11 PM

Totally awesome! Thanks. Now, I'm going to have to switch to either Safari or the color managed Firefox beta.Hmmm.... We didn't expect the shift from thumbs to display images to be so dramatic on some Macs. Customers automatically assume we just broke the site. For an example, look at the comments on the release notes blog this a.m.:

http://blogs.smugmug.com/release-notes/2007/12/28/hide-photo-feature-unveiled/#comments

Here's a screen shot of my random Mac lappy, which has never been modified from the factory:

http://cmac.smugmug.com/photos/237182610-O.png

This could be a big problem for us. If we add ICC profiles to the thumbs, it will add a lot of weight to them and a lot of people are gonna start complaining about speed. If we have to wade in the Apple display swamp, which is too much for even very savvy color people to understand, there will be much angst. And 9 of 10 people who see this will just assume SmugMug is broken and won't see anything we post about it.

georges

Dec-29-2007, 01:16 PM

jfriend

Dec-29-2007, 03:23 PM

Hmmm.... We didn't expect the shift from thumbs to display images to be so dramatic on some Macs. Customers automatically assume we just broke the site. For an example, look at the comments on the release notes blog this a.m.:

http://blogs.smugmug.com/release-notes/2007/12/28/hide-photo-feature-unveiled/#comments

Here's a screen shot of my random Mac lappy, which has never been modified from the factory:

This could be a big problem for us. If we add ICC profiles to the thumbs, it will add a lot of weight to them and a lot of people are gonna start complaining about speed. If we have to wade in the Apple display swamp, which is too much for even very savvy color people to understand, there will be much angst. And 9 of 10 people who see this will just assume SmugMug is broken and won't see anything we post about it.

Did you see if Safari responds to the experimental attributes on the IMG tag that can specify the ICC profile as a URL without actually including it in every thumb? Since it's the same ICC profile for everything, it's also cached effectively by the browser. I don't have the ability to test whether it works or not, but you guys could try it out. I mentioned it in the earlier thread where I was offering ideas on this.

There are also proposed CSS attributes for color space. It seems like the big win would be if Safari responds to either of these choices, then you could apply an ICC profile to the thumbs without actually including it in them.

arodney

Dec-29-2007, 03:46 PM

Hmmm.... We didn't expect the shift from thumbs to display images to be so dramatic on some Macs.

This could be a big problem for us. If we add ICC profiles to the thumbs, it will add a lot of weight to them and a lot of people are gonna start complaining about speed. If we have to wade in the Apple display swamp, which is too much for even very savvy color people to understand, there will be much angst. And 9 of 10 people who see this will just assume SmugMug is broken and won't see anything we post about it.

Just inform the user that these are non color managed thumbnails just below them, (they will either understand or ignore that bit), then say something like "Click on the thumbnail to see the true color" or something to that effect. As long as you tell the user what he's seeing, you're in much better shape.

Sheaf

Dec-29-2007, 03:49 PM

Just inform the user that these are non color managed thumbnails just below them, (they will either understand or ignore that bit), then say something like "Click on the thumbnail to see the true color" or something to that effect. As long as you tell the user what he's seeing, you're in much better shape.

That's quite a bit of text to put on every single gallery page. Especially since it only affects a small number of people and even fewer of those would understand it.

arodney

Dec-29-2007, 03:53 PM

That's quite a bit of text to put on every single gallery page. Especially since it only affects a small number of people and even fewer of those would understand it.

You can tell them nothing and just wait until they ask you why the two don't match and then answer them. Your call.

Andy

Dec-29-2007, 04:14 PM

Just inform the user that these are non color managed thumbnails
But 99.99 percent of the people looking have 100 percent of "no clue" what this would ever mean :evil

No, this would not be good IMO....

arodney

Dec-29-2007, 04:19 PM

But 99.99 percent of the people looking have 100 percent of "no clue" what this would ever mean :evil
.

They don't have to understand. Its supposed to tell them they don't match by design and if they want to see the images correctly, to click and build a larger image (or whatever you do to get the color managed preview).

Or color manage both, got no problem with that at all. They should match after all....

Door number three is color manage neither and you've seen where that got you.

Andy

Dec-29-2007, 04:47 PM

They don't have to understand. Its supposed to tell them they don't match by design and if they want to see the images correctly, to click and build a larger image (or whatever you do to get the color managed preview).
They don't have to do anything for that :) The main images are profiled now.

Or color manage both, got no problem with that at all. They should match after all....
I had hoped for that but well, the profile can double the weight of the thumbs. Costly in terms of speed, potentially.

We'll see!

timnosenzo

Dec-29-2007, 05:16 PM

Baldy

Dec-29-2007, 08:53 PM

Out of curiosity... how do other sites handle this issue? I'm pretty sure Flickr embeds the ICC profile, and it looks like they do it for every size. Can they get away with it because they limit the number of thumbs on a page?Last time I checked, maybe 6 months ago, they were leaving the ICC profile if you included one, leaving it off if not.

Their thumbs are so small it's harder to notice, but still they've had many complaints about this.

Baldy

Dec-29-2007, 09:18 PM

Did you see if Safari responds to the experimental attributes on the IMG tag that can specify the ICC profile as a URL without actually including it in every thumb? Since it's the same ICC profile for everything, it's also cached effectively by the browser. I don't have the ability to test whether it works or not, but you guys could try it out. I mentioned it in the earlier thread where I was offering ideas on this.

There are also proposed CSS attributes for color space. It seems like the big win would be if Safari responds to either of these choices, then you could apply an ICC profile to the thumbs without actually including it in them.I tried it a year ago and couldn't get it to work or find anyone who had. It makes so much sense. I'd love an update on this from anyone who knows, but it sounds like backwards compatibility will not be there.

jfriend

Dec-29-2007, 10:13 PM

I tried it a year ago and couldn't get it to work or find anyone who had. It makes so much sense. I'd love an update on this from anyone who knows, but it sounds like backwards compatibility will not be there.

Last I checked, there were several possibilities to be investigated:

1) An attribute on the body tag that could designate the colorspace of all images in the page.
2) An attribute on each IMG tag that could point to an URL with a color space.
3) A CSS style parameter that could specify a standard colorspace by name.
4) A CSS style parameter that could specify a colorspace URL.

The big advantage of all of these is that you could leave the images alone, apply these globally and for browsers that don't understand them, nothing would change (thus no problem with backward compatibility). For browsers that do understand them you suddenly get color management and your monitor profile is respected.

I am traveling now and unable to run a bunch of tests to see if any of these options are supported in Safari, but it sure seems like it would be great to know if any of these are better options that having to include ICC profiles with everything. It makes so much sense for small images that you should be able to specify sRGB without having to include the sRGB ICC profile in every single small image. It seems like somebody in browser development at Apple must be thinking about this problem.

I don't have any inside info, but if I come across anything else in this regard, I'll certainly share it. Don't you guys at Smugmug have some contacts at Apple?

jfriend

Dec-29-2007, 10:22 PM

Baldy -

You know, it's hard to go wrong by shooting for the lowest common denominator.

I know this rubs some of the more advanced folks the wrong way, but I'd much rather continue along the non-color managed path.

When it comes to color managment, the grand majority of web users have no clue. Take a look at monitor settings when you visit your non-photographer friends. Most will likely be set to max brightness and max contrast. (and probably came from set that way from the factory.)

Maybe my friends are unusually unaware, but I doubt it.

As bad as it sounds, the lowest common denominator is probably the best answer in this case.

GS

IMO, the goal is NEVER to shoot for the lowest common denominator. The goal is that the lowest common denominator gets a decent experience and computers with better configurations get a much better result. I, for one, am not looking for Smugmug to aim for the lowest common denominator. One can go to Microsoft or Yahoo for that.

In fact, the Smugmug guys are trying to get a better display for Mac's that display non-profiled images at a significantly wrong brightness (because of a differing gamma setting and a silly Safari browser development decision to not assume sRGB when no profile is present). So, the Smugmug guys are just trying to improve things. The current attempt has some problems, but I wouldn't throw the baby out just because it's not quite as good as it should be yet. This should continue to go forward, not backwards. The future is for more color management and more properly profiled displays, not less.

We need a solution that can do both - let non-profiled displays continue to get consistent, but inaccurate results and let profiled displays get accurate results.

Andy

Dec-30-2007, 05:01 AM

3) A CSS style parameter that could specify a standard colorspace by name.

Hm...
http://www.w3.org/TR/SVG/color.html#ColorProfileAtRule

4) A CSS style parameter that could specify a colorspace URL.

Still looking for this one...

jfriend

Dec-30-2007, 07:23 AM

Hm...
http://www.w3.org/TR/SVG/color.html#ColorProfileAtRule

Quote:
<table border="0" cellpadding="4" cellspacing="0" width="100%"> <tbody><tr> <td class="alt2" style="border: 1px inset ;"> 4) A CSS style parameter that could specify a colorspace URL.
</td> </tr> </tbody></table>
Still looking for this one...

In that same CSS style parameter that you already link to above, you can put either sRGB or a URI to a profile.

Baldy

Dec-30-2007, 05:42 PM

I don't have any inside info, but if I come across anything else in this regard, I'll certainly share it. Don't you guys at Smugmug have some contacts at Apple?Yeah, we do have some contacts at Apple and the more we work on this the more insane attaching profiles seems. Unfortunately, the options you list sound great but none of them work yet, far as I can tell.

I keep shaking my head... :scratch We're doing this because the Mac isn't Internet compatible as it ships. I would have thought attaching profiles and slowing down the wireless experience for handheld devices would be a pain point for you, Mr. Wide Area Network Portable Device Man Extraordinnaire, since those devices are Internet compatible, gain nothing from adding profiles, but lose speed.

jfriend

Dec-30-2007, 08:36 PM

Yeah, we do have some contacts at Apple and the more we work on this the more insane attaching profiles seems. Unfortunately, the options you list sound great but none of them work yet, far as I can tell.

I keep shaking my head... :scratch We're doing this because the Mac isn't Internet compatible as it ships. I would have thought attaching profiles and slowing down the wireless experience for handheld devices would be a pain point for you, Mr. Wide Area Network Portable Device Man Extraordinnaire, since those devices are Internet compatible, gain nothing from adding profiles, but lose speed.

I've not found it a productive experience yet to web-browse to Smugmug on cellular devices. It will come in the next few years, but we need some interface enhancements, some speed enhancements and a lot more devices where it's practical to make it a pleasurable thing that would lead to it being an important design target for you to optimize for. Because of that, I'm more interested in seeing accurate color on the broadband, wired web for now.

That said, adding profiles to everything just to tell a browser that everything on the page is sRGB does seem a bit brute force when there are such better technologies that could be deployed to solve that problem. The CSS route would have been absolutely gorgeous since a couple simple changes to a style sheet could have assigned sRGB to all relevant images and fixed everything (if only Safari chose to support that).

I'm racking my brain for any other ideas.

arodney

Dec-31-2007, 06:29 AM

I keep shaking my head... :scratch We're doing this because the Mac isn't Internet compatible as it ships.

Excuse me? I think you have that a bit backwards.

Safari is at last ICC aware. All the other browsers on windows simply send the RGB values to the display, that's simply the wrong way to preview color numbers. That's not how Photoshop or Lightroom or any other imaging product with it's salt handles color previews.

There's nothing non internet compatible here, there's two methods of previewing RGB numbers, one insures all users see the same numbers the same way (the correct way using Safari or PS), the other simply ignores the color space of the document and the display, sends the RGB numbers directly to the display, pretty much ensuring that no two users will see the same numbers identically.

jfriend

Dec-31-2007, 08:06 AM

Excuse me? I think you have that a bit backwards.

Safari is at last ICC aware. All the other browsers on windows simply send the RGB values to the display, that's simply the wrong way to preview color numbers. That's not how Photoshop or Lightroom or any other imaging product with it's salt handles color previews.

There's nothing non internet compatible here, there's two methods of previewing RGB numbers, one insures all users see the same numbers the same way (the correct way using Safari or PS), the other simply ignores the color space of the document and the display, sends the RGB numbers directly to the display, pretty much ensuring that no two users will see the same numbers identically.

He's talking about the default gamma setting on Macs and the trouble it causes with untagged images on the internet described here (http://blogs.smugmug.com/don/2007/02/14/this-is-your-mac-on-drugs/) and here (http://arstechnica.com/journals/apple.ars/2007/2/15/7073).

jfriend

Dec-31-2007, 10:21 AM

arodney

Dec-31-2007, 03:43 PM

He's talking about the default gamma setting on Macs and the trouble it causes with untagged images on the internet described here (http://blogs.smugmug.com/don/2007/02/14/this-is-your-mac-on-drugs/) and here (http://arstechnica.com/journals/apple.ars/2007/2/15/7073).

This is basically silly IMHO:

Most people don’t have light-controlled rooms with color-calibrated monitors. I don’t, and you probably don’t, either. Almost everyone will see your photos slightly differently than the next person. We’re not talking about perfect color precision here, because on the net, that’s an impossibility.

It doesn’t matter what "most people" mean here since its so undefined.

You either care about the color of images consistently in all applications or you don’t. If you care, you’re probably using Photoshop or a host of other color managed applications that all show the same RGB numbers the same way. Safari can play by those rules:

http://www.color.org/version4html.xalter

What *is* important, though, is for your photo to match the rest of the page. If you’ve selected a background on a PC to match the blue in your subject’s eyes, you don’t want background and eyes to be mismatched on a Mac.

Wait, you just said color isn’t all that important, you don’t have a color calibrated display (and software). Which is it?

Or you'd rather have all the photos look different in some web browsers than it does in Photoshop?

No it doesn’t on my three Macs. They look identical. The web galleries I make in Lightroom match what I see there and on the web on any of those machines. All the applications I use honor the image color appearance which as a photographer is most important.

#1: Macs ship with a display gamma of 1.8.

ICC aware applications don’t care. I don’t calibrate my display to 1.8 (nor 2.2) because it doesn’t matter. I profile to as close to the native gamma (which in actually in NOT gamma but TRC) to native of the unit unless I’m working with a high bit internal unit like my NEC 2690.

ICC aware applications all play the same in the sandbox. Safari is an ICC aware browser. It can and will behave like Photoshop and other ICC aware applications when you setup and handle color management correctly.

There's absolutely no reason a Mac user can't and in fact may prefer to calibrate to a 2.2 "gamma" (which only helps in color managed applications and rarely matters outside). The TRC of nearly all such devices fall into the 2.0-2.2 camp any way.

onethumb

Dec-31-2007, 03:56 PM

It doesn’t matter what "most people" mean here since its so undefined.

That's just a silly statement. Most of the technologies the web is built on are de facto standards (at best), and yet things still work, because "most people" is a pretty dang good way of settling on a standard.

In this cast "most people" consider a JPEG without a profile to be sRGB. This sounds sane, and it's easy to understand and implement, and it's backwards compatible.

Thus, it's become the de facto internet standard for web images. Why on earth Safari wouldn't just assume this and still do the right thing for images with profiles is beyond me - it's the perfect solution.

There's no getting around the billions and billions of images online which have no profiles without making some assumption. And the assumption to just ignore them and do nothing is a bad one.

Now I'm faced with taking a 3KB thumbnail and adding 4KB of profile to it to more than double the time it takes to download, and since browsers only fetch two images at a time, this means that pages instantly become 2X slower, even on really really (1Gbps) fast connections. That's just ludicrous.

onethumb

Dec-31-2007, 04:02 PM

One possibility. Create two sets of thumbs (Th_icc, Ti_icc), one with profiles, one without. Serve the ones with profiles to color managed browsers, the ones without profiles to all the rest. You only take the extra download size hit if your browser would actually use it to render better color. Would work with all recent versions of Safari.

Actually, the solution I have working is to add ICC profiles on-the-fly on serving them, based on the User-Agent.

This works great, and it slows down the sending of the image (server-side) by only 0.08s on average, not really noticeable to humans.

However, because HTTP is still locked at 2 transfers in flight at once, doubling the bytes still has the effect of massively slowing down the transfer speed of the whole page when your 3-5KB thumbs become 7-9KB instead and there are a reasonable number of them.

So I chose not to ship it, preferring speed.

jfriend

Dec-31-2007, 04:05 PM

This is basically silly IMHO

I don't want to get in the middle of this, but I wasn't sure whether you saw the problem that Smugmug faces here, because the problem is not silly. Also, if you know the Smugmug guys, they are all Mac fans and do all their development on Macs. This is not an example of some PC-heads bashing Macs.

Safari, for all it's wonderful color-management graces, chooses to assume that untagged images are in your monitor profile (instead of assuming sRGB) and thus it just passes them right through to the video system without any monitor compensation. If your Mac display is set to a 1.8 gamma, then EVERYTHING that is actually sRGB, but has no profile attached will look a lot brighter than everything that is tagged with sRGB (presumably that's because sRGB is a 2.2 gamma color space). Thus your gamma setting influences the display brightness of untagged images.

Since the entire PC world is basically set for 2.2 gamma that makes untagged images display differently on the Mac vs. the PC. We could argue all day long whether the Mac camp or the PC camp is "more" correct, but the challenge for Smugmug is that they are different and that sucks.

If Safari had merrely assumed that all untagged images on the web are sRGB (which they are 98% of the time on photo sites), none of this would be a problem. Smugmug wouldn't care what a user's gamma was set to because Safari would be compensating for it on all image display. But, they didn't do that.

So, Smugmug is left with a bunch of choices, none of which seem great to try to deal with the Mac vs. PC difference in default gamma setting.

1) Add profiles to every single image including all thumbs. Can add as much as 500k to the download size for an image page if there are a lot of thumbs on the page. Takes more bandwidth (a Smugmug expense) and slows down the load time for a page (a user disadvantage and a comptitive disadvantage). AIt aplies a performance penalty to every user in order to fix a problem that only about 10% see.

2) Leave profiles off of all images. At least all images within a page will be consistent, but Mac users with a 1.8 gamma will show much brighter than Mac users with 2.2 or PC users (who generally are 2.2). This is how things were for 4 years and people are complaining so Smugmug is trying to do something better than this.

3) Add profiles only to the larger image sizes. This is the current situation and leads to the undesirable case of mixed color and brightness on the same page. While the main image is now more technically correct, the thumbs look more obviously wrong even though they haven't changed.

I have no intention of debating a Mac vs. PC thing here with you Andrew. All Smugmug is looking for is a 4th suggestion that works better than the ones above.

arodney

Dec-31-2007, 04:09 PM

In this cast "most people" consider a JPEG without a profile to be sRGB.

It doesn't matter what they consider, the fact is, all the RGB numbers, be they in sRGB or something else are not going to preview the same way for all users. There's only one bloody way to do that and it means you need to calibrate and profile your output device (display). If you don't, all bets are off, period. If something is or isn't in sRGB is immaterial if the application doesn't understand what the display is doing with the RGB numbers its getting.

Safari does this. So do a lot of other applications and people who apparently care about the color appearance of the images they are handling look the same.

There's no getting around the billions and billions of images online which have no profiles without making some assumption. And the assumption to just ignore them and do nothing is a bad one.

The simple fact of the matter is, everyone viewing those billions of images are very likely seeing them differently. That's not what people who create images and hope to show them off want. What they see is what they want everyone else to see. And without color management, that's not possible.

The images all in sRGB may or may not look that close. You've got people using 9 year old CRT's at 75cd/m2 and people with new LCD's viewing at 250 cd/m2. Sorry bud, they don't look the same.

Now I'm faced with taking a 3KB thumbnail and adding 4KB of profile to it to more than double the time it takes to download, and since browsers only fetch two images at a time, this means that pages instantly become 2X slower, even on really really (1Gbps) fast connections. That's just ludicrous.

Its only ludicrous if you're main goal is worrying about bandwidth and not the best and most faithful rendition of an image. I don't run a web site, I don't have any bandwidth issues so when I tell you I feel for you, understand that in my world, the image quality is more important. I'd be willing to pay MORE to have the images look better IF that's what it takes. But as an image creator, the idea that I'm using a service that attempts to have others view said images, I want those images color managed and 4k be dammed. So no, its not ludicrous for me, based on the goals of publishing images on the web.

Sheaf

Dec-31-2007, 04:24 PM

Its only ludicrous if you're main goal is worrying about bandwidth and not the best and most faithful rendition of an image. I don't run a web site, I don't have any bandwidth issues so when I tell you I feel for you, understand that in my world, the image quality is more important. I'd be willing to pay MORE to have the images look better IF that's what it takes. But as an image creator, the idea that I'm using a service that attempts to have others view said images, I want those images color managed and 4k be dammed. So no, its not ludicrous for me, based on the goals of publishing images on the web.

Speed, not bandwidth.

DavidTO

Dec-31-2007, 04:32 PM

Speed, not bandwidth.

:thumb

Nothing more embarrassing than showing off your work, only to hear "Why's it so slow?"

It's a tough balancing act. Most people I show my site to just want to see pictures. I want them accurate. But they don't care.

onethumb

Dec-31-2007, 04:39 PM

It doesn't matter what they consider, the fact is, all the RGB numbers, be they in sRGB or something else are not going to preview the same way for all users. There's only one bloody way to do that and it means you need to calibrate and profile your output device (display). If you don't, all bets are off, period. If something is or isn't in sRGB is immaterial if the application doesn't understand what the display is doing with the RGB numbers its getting.

Safari does this. So do a lot of other applications and people who apparently care about the color appearance of the images they are handling look the same.

The simple fact of the matter is, everyone viewing those billions of images are very likely seeing them differently. That's not what people who create images and hope to show them off want. What they see is what they want everyone else to see. And without color management, that's not possible.

The images all in sRGB may or may not look that close. You've got people using 9 year old CRT's at 75cd/m2 and people with new LCD's viewing at 250 cd/m2. Sorry bud, they don't look the same.

I'm sorry, but now you're just talking crazy talk. Greater than 99% of monitors are uncalibrated, and 10 years from now, greater than 99% of monitors will be uncalibrated.

End users aren't going to spending countless amounts of time and money learning how to calibrate their monitors (and then actually calibrate them).

Not to mention that This Is Not My Problem(tm). I can't help what display someone is using to browse SmugMug with. All I can assist with is giving the browser enough information so that, if it's smart enough, it can make a best guess as to what to do. That's my goal - but that goal is secondary to speed, particularly when 95% of the world's browsers ignore ICC profiles entirely.

I'm willing and able to provide a 90% solution - everything but thumbnails are now properly associated with an sRGB profile at a relatively minor speed expense.

But I'm not willing to degrade the performance (to the tune of 2X) of my customers' sites simply to provide a 100% solution that 95% of the world doesn't care about. Sorry, but it's just not gonna happen - customers will leave and our Pros' businesses will be damaged. SmugMug, with a single change, becomes uncompetitive.

Its only ludicrous if you're main goal is worrying about bandwidth and not the best and most faithful rendition of an image. I don't run a web site, I don't have any bandwidth issues so when I tell you I feel for you, understand that in my world, the image quality is more important. I'd be willing to pay MORE to have the images look better IF that's what it takes. But as an image creator, the idea that I'm using a service that attempts to have others view said images, I want those images color managed and 4k be dammed. So no, its not ludicrous for me, based on the goals of publishing images on the web.

Bandwidth has nothing to do with it. I have bandwidth to spare, and I'd gladly spend it if it did the right thing.

But since browsers can't parallelize more than 2 requests at the same time, they get "choked up" on tiny transfers (like thumbnails) even when they have really fast pipes (cable, DSL, or even fiber). The short version of the story is that you can only get really fat bandwidth on large transfers (megabytes) or on lots of simultaneous transfers occuring at the same time. HTTP prevents more than 2 transfers at once, which is a stupid limitation of the old HTTP spec, and one that's long overdue for fixing, but it hasn't happened yet.

When/if that day happens, I'm all for spending the extra 4KB per transfer - but until then, there's no way I'm going to double the speed it takes to draw SmugMug pages just so a tiny fraction of the world sees their colors correctly because Apple's not willing to fix their bug in Safari.

Baldy

Dec-31-2007, 08:23 PM

So, Smugmug is left with a bunch of choices, none of which seem great to try to deal with the Mac vs. PC difference in default gamma setting.Great summary, John. Onethumb and i just talked and decided now's the time to take this to Apple, as you also suggested. I worked through several issues like this with Steve and with the guy who is now in charge of the Safari team, and I'm pretty sure they'll hear us.

Andrew, we all have the deepest respect for your passion for color accuracy. I love that you are taking such a powerful stand to get the color right. We just have to get the speed right too or our customers will abandon us. The other apps you reference like Photoshop don't have to deal with the way http requests work across the web like we do.

Onethumb and I can't go in front of Steve unless (a) we're air tight in our knowledge of how Safari works; (b) we have an elegant solution to propose; and (c) we have backup artillery that Steve trusts like my good friend Bill Atkinson willing to say without hesitation, "absolutely, Steve, this is the right thing to do".

We'll get Bill if we get (a) and (b).

We can also test for air leaks by going to the Firefox team first. And, if they commit to an elegant solution, it will triple Apple's interest in hearing us.

Starting with point (a): John and Andrew, how confident are you that you know exactly how Safari is rendering untagged jpg images? For example, if I set my monitor profile to the sRGB IEC61966-2.1 profile that Adobe bundles with Photoshop, does an untagged jpeg image look the same as one where we attach an IEC61966-2.1 profile to the same jpeg?

jfriend

Dec-31-2007, 11:51 PM

Starting with point (a): John and Andrew, how confident are you that you know exactly how Safari is rendering untagged jpg images? For example, if I set my monitor profile to the sRGB IEC61966-2.1 profile that Adobe bundles with Photoshop, does an untagged jpeg image look the same as one where we attach an IEC61966-2.1 profile to the same jpeg?

I don't think I know anything that you don't already know. I don't know what Safari is doing internally, just what we observe. And, my experience is with the latest Safari beta on Windows so this should probably be confirmed on the Mac, though what I've read suggests that Mac Safari behaves similarly.

What we do know is if you take an sRGB image and strip it's profile, it renders in Safari exactly the same as it renders in Firefox 2.0.0.11 (an app with no color management at all). I don't know of any way that could happen other than Safari deciding that no ICC profile present means it should skip color management or assume the monitor profile (same result either way - no monitor compensation is done). It's easy to set up this experiment both on a monitor that is very close to native sRGB and one that's not and just capture the results.

I don't know if I'll have internet connectivity for the next few days, so it may be a few days before I can participate further in this conversation.

Baldy

Jan-01-2008, 01:03 AM

I am the only person as hopelessly geeky as Baldy, so much so I posted my response at Dec-31-2007, 11:51 PM. Baldy and I sure know how to P A R T A Y ! ! :barb :barb :barb No worries, John, I'm gonna set up a couple of test pages.

One is I'll put together a SmugMug gallery page whose thumbnails have sRGB profiles attached and an identical one whose thumbs have no profiles so we can put a number on exactly what the performance hit is, depending on the user's connectivity, etc.

Here's a really good summary of what we're battling:

http://www.die.net/musings/page_load_time/

Andrew, notice how a typical user on a cable modem with less upload bandwidth than download bandwidth takes it in the shorts. They really get it as they get further from our servers.

Andrew, why does setting your display on a Mac to Apple sRGB render colors so differently than using Adobe's sRGB profile?

arodney

Jan-01-2008, 06:39 AM

:thumb

Nothing more embarrassing than showing off your work, only to hear "Why's it so slow?"

I'd gladly wait a bit longer for a quality image. I'd gladly allow you to lower the file size to the same amount the profile takes up (or more) to ensure the image previews properly. We're talking images here!

Greater than 99% of monitors are uncalibrated, and 10 years from now, greater than 99% of monitors will be uncalibrated.

First of all, if you're going to make up stat's like this, please provide where they came from.

2nd, it doesn't even matter if 99% of the displays are calibrated or not for all users, we're talking those who rely on having their images appear correct. With the cost of Colorimeters now well below $80 (not to mention the cost of getting a print the wrong color), nearly anyone who cares about color appearance can and will calibrate their displays.

But there's a bigger issue of denial here, all focused on YOUR speed and bandwidth issues, not that of the end user who should be able to decide what quality they expect from a host providing their images.

Of those so called 99% you speak of, how many use Photoshop? Get us those stat's too please.

You pretty much summed up your expectation of your users "Its not my problem" when in fact it is.

I'm willing and able to provide a 90% solution - everything but thumbnails are now properly associated with an sRGB profile at a relatively minor speed expense.

Then do it. 90% solution is better than total failure!

When/if that day happens, I'm all for spending the extra 4KB per transfer - but until then, there's no way I'm going to double the speed it takes to draw SmugMug pages just so a tiny fraction of the world sees their colors correctly because Apple's not willing to fix their bug in Safari.

There's no bug that will bail you out here. You have to have a calibrated display and some idea of the scale of the RGB numbers to preview the numbers correctly for all users. And as more and more wide gamut displays come onto market (now at prices just over $1000 for "93%" of Adobe RGB (1998)), you're sRGB world is going to crumble. Its only a matter of time.

Andrew, we all have the deepest respect for your passion for color accuracy. I love that you are taking such a powerful stand to get the color right. We just have to get the speed right too or our customers will abandon us. The other apps you reference like Photoshop don't have to deal with the way http requests work across the web like we do.

First of all, most users want correct consistent color. When they see their images on someone else's browser, its often a shock. We're not communicating type here guys, we're talking about communicating color and tone and light; its called photography.

Yes, a lot of people don't care. Is this the main customer base and focus?

2nd, Photoshop absolutely does have this issue as you'll soon see (more I can't say due to NDAs). But if you think Photoshop and image correction on the non color managed web is an impossibility that big companies like Adobe are giving up on like some others, you're way, way off base.

arodney

Jan-01-2008, 06:42 AM

I don't know of any way that could happen other than Safari deciding that no ICC profile present means it should skip color management or assume the monitor profile.

It assumes the display profile. And while one could ask it to assume sRGB (that be nice), its not a long term fix as there will be days a coming where people will get awful color appearance looking at untagged sRGB images. Untagged images equal RGB or CMYK mystery meat.

Baldy

Jan-01-2008, 08:44 AM

Hey Rodney,

I get the feeling we missed each other a few posts back. Sorry if I wasn't clear about the problem we're trying to solve. Just to sync up:

I'd gladly allow you to lower the file size to the same amount the profile takes up (or more) to ensure the image previews properly.The problem is our thumbnail (100-pixel) images. They are about 4K in size and so is the profile.

Then do it. 90% solution is better than total failure!We did, which is what's causing the consternation. We added profiles to images that are larger than thumbnails and left them off the thumbs. People who were happy before are now unhappy because they don't like the thumbs looking different from the bigger images.

I'd gladly wait a bit longer for a quality image.You and our users agree. For the larger images, a bit longer is all you wait. But with thumbnails, your wait time doubles. When you put many thumbnails on a page, which is the modern way, our users are saying they won't wait. Sites like Picasaweb and .Mac's new Web Gallery put a lot of thumbs on the page, just as we do.

...all focused on YOUR speed and bandwidth issues, not that of the end userThis is the crux of the matter. We don't care if we add profiles to thumbs because it's basically free to us--not enough bytes to register on our bandwidth bill. And it wouldn't slow down our servers at all.

The rub is some of our end users would take it in the shorts, speed-wise because of the way browsers handle http requests. Same holds true for Adobe's users, Apple's, Google's, etc., unless one of them reinvents the networking protocol. Google and Apple haven't been able to, so I'm feeling like our chances aren't good.

Here's a great article that explains the problem:

http://www.die.net/musings/page_load_time/

I hope this helps.

Thanks,
Baldy

arodney

Jan-01-2008, 09:37 AM

We did, which is what's causing the consternation. We added profiles to images that are larger than thumbnails and left them off the thumbs. People who were happy before are now unhappy because they don't like the thumbs looking different from the bigger images.

Understood. That's why I suggested telling the user why they don't match.

Here's how I see it as a potential user (fill in the level of that user):

I have the option whereby both thumb's and larger images match but the color appearance is incorrect.

I have the option whereby the thumbs and larger image don't match but the bigger preview is correct (match Photoshop). I'd like to know why they don't match (or I just don't care). If I need to know, I think you can say this once and easily somewhere on the page of thumbs no?

I Don't understand or care about any of this stuff (hence, we have no problem with this user).

Last and best: I have the option whereby thumbs and larger images match as color managed in Photoshop and other ICC aware applications.

So the question is, what's best for the user? Both matching as color managed with the speed necessary is of course the goal. If you can get speed and larger images only, can you deal with that so people get the proper color appearance and understand the thumbnail is just that, much like a contact sheet versus the finished print don't match. If you tell them nothing, some ask "why don't they match?". If you tell them, that number of users who will call support will diminish. There will always be users who don't read what you tell them but at last you try to tell them what's up.

Andy made the point that X number of users wouldn't get it. And maybe that's fine (you actually could explain all this to those who are willing to read an FAQ and the net result would be more people not less using best practices, calibrating their displays).

Thumbs that don't match the correct larger image is still better than thumbs and larger images not properly color managed. If not today, more so in the next 3-5 years. Display technology (compared to say digital capture) is incredibly slow but that's finally changing. A Fluorescent backlit sRGB device, let alone a 1994 CRT with P22 phosphors isn't something we'll be using in the foreseeable future.

Hopefully web color management (Flash) will improve. If you listen to the Lightroom Podcast with Hamburg, Fraser and Zalman, they slam the lack of color management there pretty hard.

http://photoshopnews.com/2006/07/07/lightroom-podcast-episode-8-posted/

Perhaps Adobe just makes something that fixes all this and then you make the web site work with it, don't know.

You and our users agree. For the larger images, a bit longer is all you wait. But with thumbnails, your wait time doubles.

Can you let users have one or the other via a preference or its all or nothing?

georges

Jan-01-2008, 09:44 AM

I feel like the inexperienced interloper among experts, but I'm finding this conversation very interesting.

In a perfect world I'd love everyone to see accurate color.

However, the world I see is not perfect, so here are my preferences filtered through the way I see the world.

Speed is desireable, bandwidth is expensive. So I'd rather have things go a bit faster at the expense of absolute color accuracy.

I'd rather have the thumbnails match the displayed photo at the expense of absolute accuracy.

I say this because most of my viewers won't notice that the colors are not exact, they will notice the speed and they will notice that things don't match. They also are (mostly) unaware of color managment.

I can safely say that 99% of my viewers will not benefit from doubling the size of the thumbs. It would only add to the cost of the service.

I applaud the Smugmug folks for trying to address this problem and encourage them to keep looking for answers. However, the hours devoted to this are hours taken away from other efforts on the long list of customer wants and needs. I defer to their prioritization skills, they've made good decisions in the past.

I hope this has been useful and hasn't just added noise to the conversation.

Andy

Jan-01-2008, 09:46 AM

I hope this has been useful and hasn't just added noise to the conversation.

VERY useful, keep it coming, folks :clap

muddyknees

Jan-01-2008, 09:46 PM

Hm...
http://www.w3.org/TR/SVG/color.html#ColorProfileAtRule

Still looking for this one...

How about:
http://www.w3.org/TR/css3-color/#icc-color
note also...
http://www.w3.org/TR/css3-color/#profiles

maybe 5 years from now...

Gary

muddyknees

Jan-01-2008, 10:21 PM

The problem is our thumbnail (100-pixel) images. They are about 4K in size and so is the profile.

We did, which is what's causing the consternation. We added profiles to images that are larger than thumbnails and left them off the thumbs. People who were happy before are now unhappy because they don't like the thumbs looking different from the bigger images.

You and our users agree. For the larger images, a bit longer is all you wait. But with thumbnails, your wait time doubles. When you put many thumbnails on a page, which is the modern way, our users are saying they won't wait. Sites like Picasaweb and .Mac's new Web Gallery put a lot of thumbs on the page, just as we do.

This is the crux of the matter. We don't care if we add profiles to thumbs because it's basically free to us--not enough bytes to register on our bandwidth bill. And it wouldn't slow down our servers at all.

The rub is some of our end users would take it in the shorts, speed-wise because of the way browsers handle http requests. Same holds true for Adobe's users, Apple's, Google's, etc., unless one of them reinvents the networking protocol. Google and Apple haven't been able to, so I'm feeling like our chances aren't good.

Here's a great article that explains the problem:

http://www.die.net/musings/page_load_time/

PMFJI, but that article seems to say that with lots of small files, the speed is limited more by all the http "handshaking" than by the file size - which means that doubling or halving the size of small files would have little impact on the percieved page load speed, since it's the number of files that's rate-limiting for small files. The article also suggests one possible approach to reduce this issue - using "CSS-sprites" which involves combining all the thumbnails into a single file and using CSS to "expose" the proper frame in each position (block element) on the page. This seems to be a pretty standard technique for menu button mouse-over's etc.

Gary

Baldy

Jan-02-2008, 05:25 AM

PMFJI, but that article seems to say that with lots of small files, the speed is limited more by all the http "handshaking" than by the file size - which means that doubling or halving the size of small files would have little impact on the percieved page load speed, since it's the number of files that's rate-limiting for small files. The article also suggests one possible approach to reduce this issue - using "CSS-sprites" which involves combining all the thumbnails into a single file and using CSS to "expose" the proper frame in each position (block element) on the page. This seems to be a pretty standard technique for menu button mouse-over's etc.

GaryWe haven't had luck with combining thumbs into a single file because the user perceives the system as running slowly unless they see progressive progress. Even if the page loads twice as fast, if the user has to wait for all thumbs to download before any can be seen, their perception is it's slower.

Your other observation is interesting and I'm putting together some test pages so we can quantify what the performance penalties are for different users. Film at 11.

muddyknees

Jan-02-2008, 09:20 AM

We haven't had luck with combining thumbs into a single file because the user perceives the system as running slowly unless they see progressive progress. Even if the page loads twice as fast, if the user has to wait for all thumbs to download before any can be seen, their perception is it's slower.

I suppose it may be useful to distinguish different "types" of percieved slowness when analyzing these user studies - initial "lack of feedback" before seeing anything being rendered on the one hand, and slowness in the "progressive progress" on the other. On an inherently slow connection, of course you'll have both, but the "workarounds" available seem to focus on one or the other more, and would have different percieved effects on a fast connection where, for example, stochastic behavior of the WAN may be more significant, than on a slow connection, where the local bottleneck masks any network effects. I'ts perhaps ironic that techniques such as AXAX that seek to reduce the amount of data being downloladed at the expense of increased "handshaking" is becoming prevalent at the same time that end-user bandwidth is increasing, which makes the need for these kinds of workarounds less compelling. (That is, for an end-user on a fast connection but distant on the network from the server, it may be quicker to do a complete page reload than to do a bunch of "a la carte" http-requests to load just the specific pieces that have changed.)

Gary

Matthew Saville

Jan-05-2008, 02:29 AM

I just wanted to drop in and say that I'm totally loving Firefox 3 beta. Flipped on the color management, and images are looking completely identical to Bridge / Lightroom / Photoshop. I've uploaded Adobe RGB, Prophoto RGB, sRGB, and un-profiled images to test and they all look perfect. Anybody know how Firefox 3 is treating un-profiled images? sRGB, instead of assuming the monitor profile like Safari? I hope so...

I definitely don't want my tiny little thumbs to all have color profiles attached, I think at 150 pixels I can manage to forefit the very slight brightness / saturation difference that probably won't be noticed in the midst of all the un-calibrated, wacko monitors that are out there. I think the current smugmug solution, plus Firefox 3, is the way to go.

=Matt=

Baldy

Jan-25-2008, 03:27 PM

I think the current smugmug solution, plus Firefox 3, is the way to go.Just to brace you, we're converting our slideshow to Flash, so you'll be seeing your images in all their color-managed glory until you hit the slideshow button and then back to ignoring profiles you go.

I don't see that we have a choice about going to Flash slideshows so I don't see that there is anything we can do about this except (a) take heat for color-shifting people's photos, or (b) reverse our decision to attach profiles.

bigwebguy

Jan-26-2008, 05:30 PM

Anybody know how Firefox 3 is treating un-profiled images? sRGB, instead of assuming the monitor profile like Safari? I hope so...

gfx.color_management.display_profile is a config variable in about:config which sets the default color profile to use.

http://kb.mozillazine.org/Gfx.color_management.display_profile

Background Color management allows images and colors to be displayed consistently across a variety of devices. Mozilla recognizes embedded ICC profiles in image files and uses a local color profile to perform the color adjustments. This preference determines the output color profile that Mozilla uses in these adjustments.

Possible values and their effects A string containing the full path to an ICM profile for output. Default is an empty string in which case the systems global profile is used. If no global profile can be found a default sRGB profile is used.

Caveats

gfx.color_management.enabled (http://kb.mozillazine.org/Gfx.color_management.enabled) must be true for this preference to have an effect.
If the monitor is not calibrated correctly for use with the color profile, displayed colors may look worse with color management on.

jfriend

Jan-26-2008, 05:45 PM

gfx.color_management.display_profile is a config variable in about:config which sets the default color profile to use.

http://kb.mozillazine.org/Gfx.color_management.display_profile

Background Color management allows images and colors to be displayed consistently across a variety of devices. Mozilla recognizes embedded ICC profiles in image files and uses a local color profile to perform the color adjustments. This preference determines the output color profile that Mozilla uses in these adjustments.

Possible values and their effects A string containing the full path to an ICM profile for output. Default is an empty string in which case the systems global profile is used. If no global profile can be found a default sRGB profile is used.

Caveats
gfx.color_management.enabled (http://kb.mozillazine.org/Gfx.color_management.enabled) must be true for this preference to have an effect.
If the monitor is not calibrated correctly for use with the color profile, displayed colors may look worse with color management on.

Are you sure this is the preference for what profile to assume when an image is untagged? This sounds more like it's an override for the monitor profile. I think the question being asked is what does FF3 do when it encounters an image without an ICC profile embedded? We want all images to get monitor compensation using the monitor profile. We want images that don't have an embedded profile to be assumed to be sRGB. This last part is where Safari falls on it's face and I'm wondering if FF3 is better.

bigwebguy

Jan-26-2008, 06:07 PM

Are you sure this is the preference for what profile to assume when an image is untagged? This sounds more like it's an override for the monitor profile. I think the question being asked is what does FF3 when it encounters an image without an ICC profile embedded? We want all images to get monitor compensation using the monitor profile. We want images that don't have an embedded profile to be assumed to be sRGB. This last part is where Safari falls on it's face and I'm wondering if FF3 is better.You got me again. I read the article too quickly ;-)

Hard to glean anything about how it handles untagged images from that article.

jfriend

Jan-26-2008, 08:03 PM

You got me again. I read the article too quickly ;-)

Hard to glean anything about how it handles untagged images from that article.

That's a worthwhile thing to figure out (even if we have to look at the code to see) because FF3 is still early enough that we could probably influence this important aspect to be right (or at least have a preference to be right). I'll poke around myself on this one.

jfriend

Jan-26-2008, 09:37 PM

You got me again. I read the article too quickly ;-)

Hard to glean anything about how it handles untagged images from that article.

Here's the main page about color management in FF3: http://www.mozilla.org/projects/colorsync/.

Of particular interest is this: "The benefits of profile association vs. embedding is that the profile can be downloaded once and used for multiple images on a page, or in a session."

This may be how Smugmug solves the thumbnail problem. Rather than relying on the browser to treat unprofiled images a particular way, you embed a reference to the ICC profile and the same reference can be efficiently used for all images. Sounds good in theory.

The master bug for this feature (which was filed in 1999 and contains some of the development discussion) is here (https://bugzilla.mozilla.org/show_bug.cgi?id=16769).

In that long bug discussion, I found a reference to this sRGB spec document: http://www.w3.org/Graphics/Color/sRGB. In this document is a section on how to treat images on the web that don't have any profile. ALL of those references say the images should be assumed to be sRGB. Here's one quote from the "Browsing Scenarios" section of the document: "Since the image has no ICC profile, it is assumed to be in the sRGB color space. In this scenario, the resulting image will be consistent across devices."

Also in the bug is a whole bunch of discussion about what to do with untagged images. The people who understand this color stuff are correctly arguing that they should be assumed to be sRGB, but there is no clear decision in the bug for what to actually do.

There's also a lot of discussion about whether FF3 ships with color management on or off by default. I presume that the smart minds will win this one and it will ship with it on by default, but having different colors than Adobe Flash (because it's not color managed yet) is definitely a problem for them.

Good news. They also support attributes on img and body tags to specify a profile so they don't even have to be in the image and they can be referenced and cached so they are just downloaded once:

<img… iccprofile=…>
<body… iccprofile=…>And, btw, it's Apple people doing a bunch of this work. One would assume that Safari will get some of these features too that it doesn't already have.

bigwebguy

Jan-27-2008, 06:44 AM

Here's the main page about color management in FF3: http://www.mozilla.org/projects/colorsync/.

Of particular interest is this: "The benefits of profile association vs. embedding is that the profile can be downloaded once and used for multiple images on a page, or in a session."

This may be how Smugmug solves the thumbnail problem. Rather than relying on the browser to treat unprofiled images a particular way, you embed a reference to the ICC profile and the same reference can be efficiently used for all images. Sounds good in theory.

The master bug for this feature (which was filed in 1999 and contains some of the development discussion) is here (https://bugzilla.mozilla.org/show_bug.cgi?id=16769).

In that long bug discussion, I found a reference to this sRGB spec document: http://www.w3.org/Graphics/Color/sRGB. In this document is a section on how to treat images on the web that don't have any profile. ALL of those references say the images should be assumed to be sRGB. Here's one quote from the "Browsing Scenarios" section of the document: "Since the image has no ICC profile, it is assumed to be in the sRGB color space. In this scenario, the resulting image will be consistent across devices."

Also in the bug is a whole bunch of discussion about what to do with untagged images. The people who understand this color stuff are correctly arguing that they should be assumed to be sRGB, but there is no clear decision in the bug for what to actually do.

There's also a lot of discussion about whether FF3 ships with color management on or off by default. I presume that the smart minds will win this one and it will ship with it on by default, but having different colors than Adobe Flash (because it's not color managed yet) is definitely a problem for them.

Good news. They also support attributes on img and body tags to specify a profile so they don't even have to be in the image and they can be referenced and cached so they are just downloaded once:
<img… iccprofile="…"></img…>
<body… iccprofile="…"></body…>And, btw, it's Apple people doing a bunch of this work. One would assume that Safari will get some of these features too that it doesn't already have.I read that bug thread as well, and while it certainly sounds like they will treat untagged images and CSS colors as sRGB with monitor compensation. Unfortunately there is no definitive yes or no in that thread or anywhere else I can find. It does sound promising though.

Hopefully this will put the pressure on Adobe to get color management in Flash.

Thanks for your insight and legwork on all these color management issues John. Even I am starting to wrap my head around it...kinda...a little.