But 99.99 percent of the people looking have 100 percent of "no clue" what this would ever mean
.
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.
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.
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?
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.
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.
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?
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.
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.
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... 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.
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... 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 keep shaking my head... 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.
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 and here.
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... 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.
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.
He's talking about the default gamma setting on Macs and the trouble it causes with untagged images on the internet described here and here.
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:
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.
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.
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.
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.
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.
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.
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.
0
Options
BaldyRegistered Users, Super ModeratorsPosts: 2,853moderator
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?
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.
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 ! !
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:
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?
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.
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.
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.
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 user
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.
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.
To all
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.
Comments
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.
Author "Color Management for Photographers"
http://www.digitaldog.net/
We'll see!
Portfolio • Workshops • Facebook • Twitter
Their thumbs are so small it's harder to notice, but still they've had many complaints about this.
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?
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
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.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
http://www.w3.org/TR/SVG/color.html#ColorProfileAtRule
Still looking for this one...
Portfolio • Workshops • Facebook • Twitter
In that same CSS style parameter that you already link to above, you can put either sRGB or a URI to a profile.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
I keep shaking my head...
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.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
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.
Author "Color Management for Photographers"
http://www.digitaldog.net/
He's talking about the default gamma setting on Macs and the trouble it causes with untagged images on the internet described here and here.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
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.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
This is basically silly IMHO:
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
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.
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.
Author "Color Management for Photographers"
http://www.digitaldog.net/
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.
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.
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.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
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.
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.
Author "Color Management for Photographers"
http://www.digitaldog.net/
Speed, not bandwidth.
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.
Dgrin FAQ | Me | Workshops
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.
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.
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?
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.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
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?
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!
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.
Then do it. 90% solution is better than total failure!
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.
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.
Author "Color Management for Photographers"
http://www.digitaldog.net/
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.
Author "Color Management for Photographers"
http://www.digitaldog.net/
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:
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/
I hope this helps.
Thanks,
Baldy
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.
Can you let users have one or the other via a preference or its all or nothing?
Author "Color Management for Photographers"
http://www.digitaldog.net/
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.
http://georgesphotos.net