plasmic, thanks for offering a very good explanation of our testing methodology. it was apparently not clear, and that has led to quite a bit of confusion about what we were actually claiming.
to clarify something else: we were not in any way asserting that the "reallysafe palette" was absolute. we were simply saying that those were the colors that we found to work. notice all the qualifiers in the paragraph in which we introduce the reallysafe palette. also, we felt that the tone of the article was such that it was inviting people to do their own research and validate, qualify, or debunk our findings. sorry for the confusion on that. (in fact, please see a post i just put up elsewhere in this thread that elaborates on the reallysafe palette).
finally, i don't appreciate the unfounded comments about razorfish. neither hadley nor i worked on the project for which we are being sued; moreover, i am quite sure that you have no idea of the facts behind the situation. perhaps you might instead appreciate a company that employs designers who take things seriously enough to devote an enormous amount of time and energy to researching such an important issue and then offering up what they found to the web community at large.
--dave
that's correct. those 22 colors are just the ones that didn't HAPPEN to look messed up under the conditions in which we looked. actually, i think i can now offer a better explanation of those 22 colors. first, a minor flaw in my reasoning. i said that white and black are the only colors shared. but i failed to apply these across all three roots channels. so really there are 8 colors that will be displayed with certainty:
000
00F
0F0
F00
0FF
FF0
F0F
FFF
then there are 2 more colors shared on the green channel of 16-bit with 24-bit:
55
AA
so then you can add:
050
05F
F50
F5F
0A0
0AF
FA0
FAF
so this would mean that there are (let's say at least) 16 colors that work properly at 16-bit. but at 8-bit and 15-bit, it's only those first 8 colors.
now, the "really safe palette" includes those 8 colors. the other 14 are, i suspect, not actually safe at all. what i believe happened is that, as we pointed out in the article, they are primarily green. and the green channel at 16-bit has an extra bit of colors (5x6x5). this led to a situation where those greens were shifted more subtly. so subtly, in fact, that we couldn't see the discontinuity under our conditions (brightness and contrast, lighting, etc). but the discontinuity's there, and lots of people have since pointed it out to us.
--dave
hi there. i've managed to stay off the boards for a long time, but i finally decided i needed to offer a response to this post.
first, we did look close at our tests. we looked for a long, long, long time, over and over, with differing contrast and brightness settings, in natural and artificial light, again and again. sometimes, some of the gifs appeared as if they were dithering (very slightly), and sometimes not. in the end we came down on the side of not dithering. from what i understood about internet explorer, it performs getNearestColor on both the image and the code, but for the image it adds in another function first, which actually results in 2 changes in color to the image, as opposed to 1 to the code, and thus the different results. this implies, however that the image is not dithering.
either way--whether it's a dither or not--the fundamental problem still stands: high color display is seriously troubled, and the websafe palette is not websafe at that bit depth. this is something many people clearly did not know (as evidenced by the hundreds of email we've received in response to the article).
second, you seem to misunderstand our point about inconsistency and why that makes the colors not websafe. gamma and other problems have long existed that mean that a single color looks different from one machine to another. we don't suggest at all that that makes those colors websafe. the idea behind the websafe palette--it seems to me--is that as long as you stick to those colors, your images and code-generated color will look the same, and will not be dithered. at high color, as we found, this is no longer true: a single color value on a single machine will not be rendered the same across image and code. i believe that to be a significant fact to web designers. dither or not, i believe that that makes any color that encounters such a problem not websafe at high color. that was the point we were trying to make about "unwebsafe."
third, we never claimed to have all the answers. the motivation for writing the article was really to put out a call to the real experts to help us fill in the gaps. several errors have been pointed out already. that's fine with me. i should mention, though, that many of the "mistakes" people have pointed out have been contradicted by the input from many others. what's interesting to me now is that after 300 hundred emails to me and over 300 posts on this board, the "experts" still don't agree about what the real problem is. i feel that the article has succeeded in that it has sparked a much-needed debate--one that in the end will surely get to the answer, and lead to better software development (i hope).
in the meantime, you might give a little more respect to people who devoted tons of their own time to investigating an important issue and then shared that information in an earnest attempt to find the solution, rather than making snide, bitter, unhelpful remarks.
--dave
Slashdot Mirror
to clarify something else: we were not in any way asserting that the "reallysafe palette" was absolute. we were simply saying that those were the colors that we found to work. notice all the qualifiers in the paragraph in which we introduce the reallysafe palette. also, we felt that the tone of the article was such that it was inviting people to do their own research and validate, qualify, or debunk our findings. sorry for the confusion on that. (in fact, please see a post i just put up elsewhere in this thread that elaborates on the reallysafe palette).
finally, i don't appreciate the unfounded comments about razorfish. neither hadley nor i worked on the project for which we are being sued; moreover, i am quite sure that you have no idea of the facts behind the situation. perhaps you might instead appreciate a company that employs designers who take things seriously enough to devote an enormous amount of time and energy to researching such an important issue and then offering up what they found to the web community at large. --dave
that's correct. those 22 colors are just the ones that didn't HAPPEN to look messed up under the conditions in which we looked. actually, i think i can now offer a better explanation of those 22 colors. first, a minor flaw in my reasoning. i said that white and black are the only colors shared. but i failed to apply these across all three roots channels. so really there are 8 colors that will be displayed with certainty: 000 00F 0F0 F00 0FF FF0 F0F FFF then there are 2 more colors shared on the green channel of 16-bit with 24-bit: 55 AA so then you can add: 050 05F F50 F5F 0A0 0AF FA0 FAF so this would mean that there are (let's say at least) 16 colors that work properly at 16-bit. but at 8-bit and 15-bit, it's only those first 8 colors. now, the "really safe palette" includes those 8 colors. the other 14 are, i suspect, not actually safe at all. what i believe happened is that, as we pointed out in the article, they are primarily green. and the green channel at 16-bit has an extra bit of colors (5x6x5). this led to a situation where those greens were shifted more subtly. so subtly, in fact, that we couldn't see the discontinuity under our conditions (brightness and contrast, lighting, etc). but the discontinuity's there, and lots of people have since pointed it out to us. --dave
hi there. i've managed to stay off the boards for a long time, but i finally decided i needed to offer a response to this post. first, we did look close at our tests. we looked for a long, long, long time, over and over, with differing contrast and brightness settings, in natural and artificial light, again and again. sometimes, some of the gifs appeared as if they were dithering (very slightly), and sometimes not. in the end we came down on the side of not dithering. from what i understood about internet explorer, it performs getNearestColor on both the image and the code, but for the image it adds in another function first, which actually results in 2 changes in color to the image, as opposed to 1 to the code, and thus the different results. this implies, however that the image is not dithering. either way--whether it's a dither or not--the fundamental problem still stands: high color display is seriously troubled, and the websafe palette is not websafe at that bit depth. this is something many people clearly did not know (as evidenced by the hundreds of email we've received in response to the article). second, you seem to misunderstand our point about inconsistency and why that makes the colors not websafe. gamma and other problems have long existed that mean that a single color looks different from one machine to another. we don't suggest at all that that makes those colors websafe. the idea behind the websafe palette--it seems to me--is that as long as you stick to those colors, your images and code-generated color will look the same, and will not be dithered. at high color, as we found, this is no longer true: a single color value on a single machine will not be rendered the same across image and code. i believe that to be a significant fact to web designers. dither or not, i believe that that makes any color that encounters such a problem not websafe at high color. that was the point we were trying to make about "unwebsafe." third, we never claimed to have all the answers. the motivation for writing the article was really to put out a call to the real experts to help us fill in the gaps. several errors have been pointed out already. that's fine with me. i should mention, though, that many of the "mistakes" people have pointed out have been contradicted by the input from many others. what's interesting to me now is that after 300 hundred emails to me and over 300 posts on this board, the "experts" still don't agree about what the real problem is. i feel that the article has succeeded in that it has sparked a much-needed debate--one that in the end will surely get to the answer, and lead to better software development (i hope). in the meantime, you might give a little more respect to people who devoted tons of their own time to investigating an important issue and then shared that information in an earnest attempt to find the solution, rather than making snide, bitter, unhelpful remarks. --dave