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•23 years ago
|
Component: ImageLib → Image: Layout
Updated•18 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
•