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.
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.
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
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.
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.
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.)
Matthew SavilleRegistered Users, Retired ModPosts: 3,352Major grins
edited January 5, 2008
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Even I am starting to wrap my head around it...kinda...a little.
I'm not kidding, I woke up this morning at 445am after having nightmares about color - got up, made coffee and have been poring through all this stuff for the againth time, and I still feel the same way.
BaldyRegistered Users, Super ModeratorsPosts: 2,853moderator
edited February 19, 2008
Ugh, we're still getting bruised for attaching ICC profiles. I was trying to handle a customer who said:
"The reason I didn´t fall for SmugMug are the colors. It seems as SmugMug applies extra contrast and saturation - this creates a challenge for me, to re-adjust all photos before uploading."
When I get back to them and say, "We attach ICC profiles to the images so Firefox 3 and Safari can view the photos correctly" they respond, "No. You are the only ones who have this problem. My photos look right on every other photo sharing site." That's because he doesn't attach ICC profiles and neither do the other photo sharing sites.
Of course, 9 of 10 customers don't write us about this, they just decide on another site because they don't want us screwing up their colors.
Ugh, we're still getting bruised for attaching ICC profiles. I was trying to handle a customer who said:
"The reason I didn´t fall for SmugMug are the colors. It seems as SmugMug applies extra contrast and saturation - this creates a challenge for me, to re-adjust all photos before uploading."
I don't understand this. IF he's using an ICC aware application and browser, they two match. If not, the profile isn't doing anything.
I don't understand this. IF he's using an ICC aware application and browser, they two match. If not, the profile isn't doing anything.
What they're saying is if they upload their photos to photo sharing sites from Apple, Google, Flickr, etc., his photos look one way in Safari. If he uploads them to SmugMug, they look another (because we attach ICC profiles).
Since profiles are so non-standard on the web, we're the odd man out and they assume we're the ones who have it wrong.
What they're saying is if they upload their photos to photo sharing sites from Apple, Google, Flickr, etc., his photos look one way in Safari. If he uploads them to SmugMug, they look another (because we attach ICC profiles).
Since profiles are so non-standard on the web, we're the odd man out and they assume we're the ones who have it wrong.
Sorry, I still don't get it. So when he's uploading his images to these other sites, he's doing so without a profile but he is when uploading to yours?
I also don't understand the bit about "because we attach ICC profiles". Seems you need to honor the images (tagged or untagged). And of course, untagged images would not show any effect outside of Safari.
Comments
VERY useful, keep it coming, folks
Portfolio • Workshops • Facebook • Twitter
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
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
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.
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
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=
My SmugMug Portfolio • My Astro-Landscape Photo Blog • Dgrin Weddings Forum
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.
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
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.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
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.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
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.
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.Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
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.
I'm not kidding, I woke up this morning at 445am after having nightmares about color - got up, made coffee and have been poring through all this stuff for the againth time, and I still feel the same way.
Portfolio • Workshops • Facebook • Twitter
"The reason I didn´t fall for SmugMug are the colors. It seems as SmugMug applies extra contrast and saturation - this creates a challenge for me, to re-adjust all photos before uploading."
When I get back to them and say, "We attach ICC profiles to the images so Firefox 3 and Safari can view the photos correctly" they respond, "No. You are the only ones who have this problem. My photos look right on every other photo sharing site." That's because he doesn't attach ICC profiles and neither do the other photo sharing sites.
Of course, 9 of 10 customers don't write us about this, they just decide on another site because they don't want us screwing up their colors.
I don't understand this. IF he's using an ICC aware application and browser, they two match. If not, the profile isn't doing anything.
Author "Color Management for Photographers"
http://www.digitaldog.net/
Since profiles are so non-standard on the web, we're the odd man out and they assume we're the ones who have it wrong.
Sorry, I still don't get it. So when he's uploading his images to these other sites, he's doing so without a profile but he is when uploading to yours?
I also don't understand the bit about "because we attach ICC profiles". Seems you need to honor the images (tagged or untagged). And of course, untagged images would not show any effect outside of Safari.
Author "Color Management for Photographers"
http://www.digitaldog.net/