> in alt.html, dorayme wrote:
>>> "Michael Satterwhite" <satterwh.X$NO$S$> wrote in message
>>> news:fgFTd.49240$...
>>>> I have a .jpg image with a known background color (#F6F6FF). Using a style
>>>> sheet, I specify background-color: #F6F6FF;. The problem is that when the
>>>> page renders, the background color is *CLOSE* to the background-color of
>>>> the image, but it doesn't match. As a result, the boundary of the .jpg is
>>>> visible.
>
> Problems:
> 1. JPG is not necessarily sving the color exactly
> 2. 16bit colors may cause problems on 24bit images
>
> Solutions:
> 1. Use png or other lossless format
> 2. Uee png or other image with transparency
>
>>> I got around this problem by using a colour picker ( I use Eclipse Palette
>>> it's free at this address
>>> http://www.greeneclipsesoftware.com/eclipsepalette.html ) on the background
>>> colour of the image then using that colour in my css) It hasn't failed me
>>> yet.
>
> That would work, assuming the problem is #1. In case of #2, it just looks
> to solve problem, and might even cause another.
If it was #2, what might the problem be? Interesting that you raise this
issue of different bit colour. Perhaps this is getting a bit ot, but would
appreciate any link to a good discussion of the issue.
>> Yes, I have found that this problem comes up more when the colour concerned
>> is not a websafe colour (websafe colours are from a special palette that
>> most web browsers support, a small subset of all colours).
>
> Websafe colors are not websafe. As user of any 16bit color can see.
>
> Web safe colors are relic from age when 8 bit display drivers and thus
> 256 colors were usual. 256 colors are very unusual today. 2 colors are
> much more used. As is 16bit (65 thousand color). So called websafe colors
> aren't on either, so there is no sence to limit yourself to them.
OK... um... well...I'm a relic myself actually... but I want to be more
modern. I have been thinking lately to move from the use of websafe palettes
for general website construction as I do notice that many nice sites use the
full range of #RRBBGG; I find that it is easier to become familiar with the
vastly smaller subset colours and their notation and had been thinking that
doing a lot with a little is a good thing... but I digress.
>
>> If it is "a known colour" as the OP says, how can a colour picker solve the
>> problem?
>
> To tell if the color really is what it is supposed to be. Jpg is lossy
> format, and it might have changed while saving.
Yes, I see your point about colour changing from original to jpg compressed.
I was thinking the OP knew the resulting pic's colour. On the issue of
changing the jpg itself, my impression has been that there are no surprises
in colour if one does not redo the compression.
>> I have done this to get around the issue: change the jpg bg colour to a
>> websafe one.
>
> I have tried it many times, but it usually don't work...
>> This may or may not be your cup of tea. Mostly not so hard. In
>> Photoshop, for example, you can select (via paths or magic wands or
>> menus...) the colour concerned, or - importantly - enough of it on the edges
>> and substitute a close looking websafe one.
>
> If you only get area near edge, there still will be difference at some
> point. And changing background of jpg might be almost impossible. But if
> OP is maker of this jpg, he should have orginal somewhere.
Well, yes, it needs sensitive handling and depends on the pic and what is
desired for integration on the page, one would not simply select a band
around the edges... If the OP had original pic, there would still be the
problem of compression change...
>
>> In other words, prepare the pic
>> to suit the popular browsers rather than find a way to get them to suit the
>> pic.
>
> Yes.
Well, maybe you are just being nice here! If one is free to use millions of
colours in website construction, maybe one can design to suit the pics more!
dorayme
Similar Threads
