Here are the basics. I have an image (CS2 8 bit RGB tiff 72 dpi) that has been created with blocks of web-safe colors (where possible). When I save it for the web as a sliced JPEG the blocks of web-safe colors shift. I’m not as concerned with the appearance as the actual RGB values. For example, a block of color as 102,51,0 is being saved for the web as 103,51,1. I have tried this with color management on and off, saving as JPEG very high, high, etc. No difference.
Why won’t it save as "safe" colors? I have tried bringing this same image into the "save for web" as a JPEG with the same results. Again, I am basing this on the actual shift in RGB values – not how it looks on screen.
I have done this hundreds of times but never encountered this problem. What is going on?
Learn how to optimize Photoshop for maximum speed, troubleshoot common issues, and keep your projects organized so that you can work faster than ever before!
So called "Web-safe" color is pretty much an anachronism these days, left over from the days when the majority of web browsing systems didn’t have the computational horsepower to display more than 256 colors.
The GIF format was the first image file type that was transmissible over the web, and it only allowed for 256 (or 216, if you account for Mac/Windows parity across browsers).
Now that most of the installed user base can view millions of colors of the systems, adhering to web safe color is more of a design decision than it is a design constraint.
If you’re saying that you have what you call an even shift, then I suggest that you may need to recalibrate your monitor, and get to understand color management a little better.
For that, go spend some time at the following site, and look for articles on color management that are relvant to your system and version of Photoshop: <http://www.computer-darkroom.com/home.htm>
The "appearance" of color shift is not the problem. I understand color management. It is the "actual" shift of color. It moves a solid RGB 102,51,0 to 103,51,1. Why? I check the color values while in the "save for web" space and they are correct. After the save they have shifted values.
I have done a Save As . . ..tiff – no change ..eps – no change ..jpeg (with and without compression) – color shift every time ..jpeg through Save for Web – color shift
Again, these changes are the actual color values not appearance. I have presented this experience to our support guy here in the shop and he is getting the same results on his computers without explanation.
I took a cutting of the brown edge in the linked TIFF file that has an RGB value of 102/51/0 and opened it in a new file in case the JPEG compression was making its calculations based on surrounding colours.
I opened it in Save for Web and went to 4-up optimisation. I set all 3 for output to JPEG format, and set their values to Max, Medium and Low. Doing this, the JPEG compression does change the colour value a little – you can read this at the bottom of the screen.
However – and this is the weird thing – using maximum compression, the colour values at the bottom are correct: 102/51/0 or Hex 663300, so I thought Photoshop would output the JPEG at those colours. When I clicked save however, then went and retrieved the compressed file from disk, the colour values for the brown had shifted from 102/51/0 to 102/50/0 even though the Save for Web dialog had indicated otherwise.
Using ACE engine, PS CS2. It looks like the colours are shifiting a tiny amount during the saving of the file as JPEG on my machine too. No idea why though 😉
The reason I was wondering is that I saved your TIFF file to my desktop, tried Save for Web, and Photoshop WILL NOT let me save the file as a JPEG, no matter what I do. The only option in the Save For Web > Print dialog box is GIF. Period. Nothing else.
I cannot presume to explain this. I practically never do anything for the web, and I have never had a file containing slices.
So I am left with the memory of an astronomy professor at the university some fifty years ago who kept telling us "I cannot explain the universe to you, I can only describe it for you." :/
Ramón, Open the file then open it in Save for Web… Take the Slice tool (knife top left) and draw a marquee round the entire image so that every slice is selected. Then choose JPEG as your preset option on the right. This becomes the output type for every slice of the file. You can then select a slice and export it as an JPEG image. Why? Best ask your professor – I haven’t a baldy!
Hehehe he was already a senior citizen then. I doubt he’s alive some 50 years later. 🙂
I’m more than happy to take your word for the veracity of your above instructions, and I’m even happier that I don’t deal with web stuff. Thanks for the enlightenment.
Interesting. But pretty academic? Why would anyone use jpg to Save For Web solid-colored graphics like you post? Use GIF; cleaner image and no RGB number shift.
well I must say the amount of variation is so insignificant its really not worth worrying about. Especially when most of the folk surfing the web have uncalibrated monitors.
That and they don’t have the original file to compare it to.
OK, this is pure, unfounded speculation: I seem to remember either Chris Cox or Bruce Fraser saying that all color conversions go through L*a*b. If we could consider your "web safe" colors to be an index colored space that is being converted to sRGB, there could be rounding off errors involved.
"Why would anyone use jpg to Save For Web solid-colored graphics like you post?"
Because I can’t get by with a GIF.
The actual image has many continuous color tones. It is the background image for an HTML table. The color surrounding the image is a solid Hex build. The problem? The solid hex build and the solid color of the JPEG line up and don’t match, thus eliminating the illusion of a continual field of solid color.
Don’t take this the wrong way, but I didn’t come to the forum looking for opinions of how I should accomplish a given task, but why a particular task wouldn’t give me the expected results. The answer may not be as evident as I hoping but let’s not belittle the questioner.
Didnt mean to be little. Just a suggestion based on your posted example which has no continuous tones. Does your actual image lend itself to slicing? Saving solid color areas as GIF and continuous tone sections as JPEGS? (or would that just be another unwanted opinion of how you might a accomplish a given task. If so, I apologize in advance.)
The continuous tone areas lap into the solid areas. The image is being sliced but I’m unable to separate them adequately to do as you suggested.
I appreciate the suggestions but don’t want the original thread to get off track – Why does saving an already color compressed file as a JPEG cause a color shift in the actual numeric color values?
"What if you change the background color to match the picture? "
I have done this by encorporating a background image JPEG to create a seamless design.
I have solved the "web design issue" – that was what brought this all about. I still haven’t been able to understand the reasoning for the color change via JPEG.
I am leaning to believe that it is something incorporated in all JPEG saves but only shows in specific situations or colors.
Just based on this short description of how JPEG deals with color/luminance (even prior to compressing), it does not surprise me that there is a shift in RGB numbers:
First, the JPEG algorithms first cuts up an image in separate blocks of 8×8 pixels. Since the format is based on luminance/chrominance perception, it does not analyse RGB or CMYK colour values but instead converts image data to a luminance/chrominance colour space, such as YUV. This allows for separate compression of these two factors. Since luminance is more important than chrominance for our visual system, the algorithm retains more of the luminance in the compressed file. The next step in the compression process is to apply a Discrete Cosine Transform (DCT) for the entire block. DCT is a complex process that is let loose on each individual pixel. It replaces actual colour data for each pixel for values that are relative to the average of the entire matrix that is being analysed. This operation does not compress the file, it simply replaces 8×8 pixel values by an 8×8 matrix of DCT coefficients. Once this is done, the actual compression can start. First the compression software looks at the JPEG image quality the user requested (remember PhotoShop ‘low quality’, ‘medium quality’,…) and calculates two tables of quantization constants, one for luminance and one for chrominance. Once these tables have been constructed, the constants from the two tables are used to quantize the DCT coefficients. Each DCT coefficient is divided by its corresponding constant in the quantization table and rounded off to the nearest integer. The result of quantizing the DCT coefficients is that smaller, unimportant coefficients will be replaced by zeros and larger coefficients will lose precision. It is this rounding-off that causes a loss in image quality.
I think because of JPEGs objective, which is to compress an image while keeping continuous photographic tones looking as good as possible. Retaining specific RGB numbers of solid colors is not a priority.
I have the same issue, but it produces different results on 2 different computers and I’m not sure why. I have a block of color that is web safe (#99cc33), I save for web to jpg and it shifts to #9acd34.
On the other computer I open the same file and save for web to jpg and it stays #99cc33. Both photoshop versions (CS2) are set to the exact same color settings as well as the file being exactly the same. Is there a setting somewhere else I’m missing?
Further researching and I figured it out… an accidental press of cntrl-Y (probably while meaning to press cntrl-T) somewhere messed everything up.. switched workspace to proofing mode. Once I press cntrl-Y again it’s back to normal and saves for web with the correct same web safe colors it started with.
Learn how to optimize Photoshop for maximum speed, troubleshoot common issues, and keep your projects organized so that you can work faster than ever before!
Related Discussion Topics
Nice and short text about related topics in discussion sections
