Closed Bug 114701 Opened 24 years ago Closed 14 years ago

Pictures seem brighter than background

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Type:
defect
Priority:
Not set
Severity:
trivial

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: hetesitamas, Unassigned)

References

(
URL
)

Details

Attachments

(1 file)

smaller testcase with white on black text
38.02 KB, text/html
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5) Gecko/20011011 BuildID: 2001101117 If you visit a page with a background color and an image is on it with the same background color (chechked the source and the image in IrfanView and ACDSee), it is really visible that the image seems lighter in Moz than the background color. Reproducible: Always Steps to Reproduce: 1. Create an image with a background color. (try #386080) 2. Make the page's body the same color. 3. Visit the page. If you don't see the difference, take a screenshot and zoom in. Actual Results: Background areas of the picture is lighter. During the writing of this bug report, I realized that this is a JPEG-specific error. Only complex JPEG pictures produce this error. IMHO this is a really big problem that I first found in this precompiled Windows. It really degrades the pleasure of viewing pages.
imagelib. works fine here, linux build 2001-12-10-08 Reporter, what's your bit depth?
Assignee: mjudge → pavlov
Component: Image Conversion Library → ImageLib
Reporter: Which image on the specified page seems weird to you? Everything seems ok for me. Build ID: 2001 12 10 03. Windows 2000.
using 16-bit color right ? this is a known problem with 16-bit palette ... test page: http://hotwired.lycos.com/webmonkey/00/37/stuff2a/complete_websafe_216/test.html Description: http://hotwired.lycos.com/webmonkey/00/37/index2a_page5.html?tw=design
any current input on this ? ive lately fooled around with such stuff, especially mac/win differeces and i didnt recognize any such problem with mozilla 0.9.8 on win2k
On win98 with my display set to 16bit color I can see this problem on the test URL as well as with the articles pointed to by Chu Alan in comment #3. It seems to be a bug. Chu Alan, when you say known problem, so you mean there is already a bugzilla bug about this? If so, can you dupe this one, or else report back with the bug # so somebody else can dupe it?
Status: UNCONFIRMED → NEW
Ever confirmed: true
sorry ... may be i have confused you, known problem here means this problem is a common problem on many browsers when trying to use 16-bit color ... including some IE and Netscape versions. here is an excerpt from the article :- When we viewed the old 216 websafe color palette at 16-bit depth, we were shocked. All over the place there were little squares amid our blocks of color. Sometimes they were blaringly obvious; other times, nothing more than timid ghosts of color. But either way, we could definitely see the GIF inside the table cell. This didn't happen in all browsers. Internet Explorer 5 on both Windows and Macintosh handled the colors properly, as did Netscape 4.6 (tested only on Macintosh) and 3.04 (tested only on Windows). But all the other browsers we tested ran into problems ... lots of problems. To make matters worse, the problem colors weren't the same for each of these browsers. For instance, #336633 failed in Internet Explorer 4 on Windows and 4.5 on Macintosh, while it was fine on Netscape 4.07 and 4.74 on Windows. Then a color like #FF99CC worked fine in all the Internet Explorers but failed in Netscape 4.07 and 4.74 on Windows.
This should be retested in a current trunk (not 1.0 or 1.0rc) build, since gamma correction has landed on the trunk.
anyone can test on win98 machine? Since I don't have any win98 here ... P.S. the URL of reporter and the testcase works fine here with 2002043007/Linux on 24 bit colors ...
Blocks: 141776
WFM Win2k 2002050204 in both 16- and 24-bit color.
tor or saari? any comments here?
WFM 2202071104 trunk win2k, 16,24 and 32 bit
There can be a few things that make a difference here. A 16 bit display means you are gonna use 5 bits per color for each color.. and have on bit left over. Depending on the graphics card that one bit will be used for one of the colors.. so graphics card to graphics card those colors can change. Now.. and application can choose to use only 5 bits per color on a display.. that makes it more consistent. Explorer could be doing this. I also think but have not found a way to detect how a color card uses these bits and can make an adjustment. As far as Mozilla is concerned.. unless there is something I am missing.. we don't adjust these colors, we just pass them off to the card.. telling it to draw using these colors. I will double check this.. but I am almost positive. The color differences you see..may be some gamma correction, card correction, etc. Explorer may deal with things by an internal adjustment.
*** Bug 159829 has been marked as a duplicate of this bug. ***
As additional food for bug-hunting thought, making a transparent PNG gives the same effect- the background of the image is lighter than the rest of the page. For example, http://ninechoir.com/~fgasper/index.html.
I see most of the gif images on http://hotwired.lycos.com/webmonkey/00/37/stuff2a/complete_websafe_216/test.html Trunk 2002072718, Windows Me, 16-bits color, nVidia GeForce2MX 32MB.
Also, when I switch to 32-bits color (without restarting), things get better but still not all gifs are undetectable. IE5.5 does better.
In fact, reading comments on bug 159829, this bug also affects Linux and MacOS in different ways. The above bug (marked as a dupe of this one) mentions problems in these other OS'es with 16-bit color pallettes. Is this a "fixable" bug? I don't imagine that I'm the only one out there viewing transparent PNG's at 16bpp... Please consider changing this bug's platform and OS to "All", and possibly upgrading severity to "minor"?
*** Bug 142755 has been marked as a duplicate of this bug. ***
OS/Hardware => All from dupes
OS: Windows 98 → All
Hardware: PC → All
*** Bug 310566 has been marked as a duplicate of this bug. ***
Assignee: pavlov → nobody
QA Contact: tpreston → imagelib
None of the above testcases is still available. Is this 9 years old bug still valid?
If this is still the case, please reopen this bug.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: