Open
Bug 86925
Opened 23 years ago
Updated 2 years ago
HTML and Images with the same colour are rendered differently
Categories
(Core :: Layout: Images, Video, and HTML Frames, defect)
Core
Layout: Images, Video, and HTML Frames
Tracking
()
NEW
Future
People
(Reporter: wildfire, Unassigned)
References
()
Details
Attachments
(2 files)
I have an 8 bit colour display and am using X 4.02; when I go to the Debian site (www.debian.org) the rounded corners on the rectangle appear in a different colour even though they are the same. Edited IRC log: wildfire == me; Joy == webmaster@debian.org * wildfire notes the rounded corners on the debian site are a different shade of red to the red rectangle <Joy> wildfire: they can't be, your display is wrong <Joy> wildfire: we used the same hex code to generate the HTML and the PNGs <wildfire> no, my display is right <wildfire> they come up a different color <wildfire> err, colour * wildfire spits .. damn americans <wildfire> do you want a screen cap.? <Joy> wildfire: it's #DF0451 in the HTML... lemme check the Gimp <wildfire> oh, same with the blue corners btw <Joy> gimp says it's #df0451 <Joy> wildfire: how many colors does your display have? <Joy> wildfire: 16, 256, 65K, 16M? <wildfire> 8 bit <wildfire> 256 <Joy> wildfire: that's probably the reason. arguably we should have used a different color from the start, but your software should be using the same color, too.
Reporter | ||
Comment 1•23 years ago
|
||
Comment 2•23 years ago
|
||
Could be a gamma-correction issue. PNGs are gamma-corrected, while text is not...
Comment 3•23 years ago
|
||
wfm may be color set
Comment 4•23 years ago
|
||
everything looks correct here, even in 8 bit mode. must have been fixed at some point, marking WFM
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 5•23 years ago
|
||
No, this still fails for me with build 2001080104. It isn't a colour set issue because the boxes come up the right colour and portions of the image also come up correctly. It may be a gamma related issue but I don't believe that mozilla does that for PNGs. I've used xmag to zoom in on the problem area and the PNG attached is from electric eyes (and annoyingly the colours differ between all three: mozilla, xmag and eeyes. sigh.) Anand
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Reporter | ||
Comment 6•23 years ago
|
||
Comment 9•23 years ago
|
||
btw, i see it happening in millions of colors.
Comment 10•23 years ago
|
||
Marking NEW based on the dupe.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 11•23 years ago
|
||
I read thru these ramblings and don't still don't know why, in theory, the color space should be rendered with any modification at all. Rendering of html and css colors, yes that requires gamma consider, etc. However, the answer is simple [unfortunately] just replicate IE. 90% of the browsers are IE, so designers pick colors that look good with IE; period. As I understand it, PNG is a compression algorithm. Therefore, the decompression algorithm should repoduce the orginal, without any modification. Al.............
Updated•23 years ago
|
Target Milestone: --- → Future
In response to comment 11: Doing gamma correction according to the spec does replecate IE for Windows, since Windows is already sRGB so no correction needs to be done. It just makes Mozilla on other platforms look more like IE for Windows. (I don't like that attitude in general, but it's true in this case.)
Updated•22 years ago
|
Component: ImageLib → Image: Layout
Updated•17 years ago
|
Assignee: pavlov → nobody
QA Contact: tpreston → layout.images
Updated•6 years ago
|
Product: Core → Core Graveyard
Updated•6 years ago
|
Product: Core Graveyard → Core
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•