Color change when saving as GIF

[tomrakers]

Been using PI for close to 10 years now (since V3)

Have observed this problem since about version 6. I just D/L the latest version and it still has this problem. This problem occurs 90-95% of the time, but not every time.

You create a graphic that you want to save as a GIF and you want it to match exactly an existing web page background so you make the surrounding color the exact same as what you will be matching. When you go to save as a non-dithered GIF, PI insists on changing one or more of the colors. (For instance the color you built the background of the GIF with might have been 255,255,255 and PI tries to save it as 254,254,254

As an example, create a rectangle and color it with a solid background.

Place some different color text or additional graphics in the box then go to save it as a non-dithered GIF

Place you hand tool over both of the background areas in the original and the one to be saved in the preview area. See how the color has changed by 1 or 2 on one or more of the RGB channels?

If the object is saved as is it will not perfectly match the page background you will be placing it on.

You can manually fix the problem by changing it yourself, but is there some other answer. It is a PITA to do this virtually every time you want to save a GIF.

I do not want to and should not have to save it as "transparent" GIF.

[heinz-oz]

If you don't want it to be transparent, why do you insist on gif? Gif files have a limited color depth and the problem you are experiencing may be due to your saved custom pallette. Try saving as jpeg and use that on your web page.

[tomrakers]

Thanks for the reply. I should have prefaced my question with the info that I have been a Web Designer since 1994 so my understanding of images as related to the web is solid. We chose PI over PS back then because we are more interested in getting the job done rather than displaying boxes of over-priced software out in our lobby.

Couple reasons we must use the GIF format.

The primary reason is that a JPEG even at 100% quality and no sub-sampling does not guarantee a pixel to pixel color match to the original image as a GIF can (or should anyhow, provided it was designed properly to begin with). Any image that is primarily flat colors should be compressed as a GIF to avoid compression artifacts.

Secondly, a lot of times we use multiple versions of the image for animation, thereby requiring the background color be identical in each frame. We use a custom palette when needed, but even then PI sometimes changes the background color in unpredictable ways when saving as a GIF.

The only workaround I have found is to manually lock the color. My question is, I suppose, why does Ulead not care about this bug? Perhaps they don’t know? If so, now they do I guess.

[heinz-oz]

Hope they do now. As to why PI sometimes seems to change the RGB definition, don't know and never noticed it.

Do you notice the variation right away or only once you have placed the image on your site? Maybe a browser problem also, depending on where it shows up. That is exactly the reason why I use the transparency feature of gif files.

Why don't you want to use the transparent gif option? It works very well and doesn't add a lot to the task when saving the gif in the first place.

I always have used it and, hence, did not appreciate the problems you are having.

[tomrakers]

If you go to the GIF Optimizer previewer and select the Palette tab, you see the error in the index values when you place the "hand" over the appropriate portion of the original GIF, then move to the right preview pane over the same area.

For instance the one I have open now has a background index of 200,100,50

In the right pane it shows a value of 201, 103, 54

Those values seem to change based on what other colors are present in the image. If I change the other colors in the GIF slightly then go to optimize it, I get 202, 102, 51

Some browers will render that tiny discrepancy quite differently, turning a nice, fluid page into a total mess.