Closed Bug 95106 Opened 23 years ago Closed 22 years ago

All colors (chrome and pages) reduced to 16 colors - or worse.

Categories

(Core :: Graphics: ImageLib, defect)

x86
Windows NT
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla0.9.6

People

(Reporter: mozilla, Assigned: pavlov)

References

()

Details

(Keywords: regression)

Attachments

(7 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.3+) Gecko/20010813
BuildID:    2001081303

Color images badly distored - apparently reduced to 16 colors. This is on NT 4.0
sp6 with 256 color display. Previously had some image quality and display
performance problems as reported in bug 88560, but this is much worse, and first
appeared for me in this build. This is first build that I've run since 0.9.3.

Reproducible: Always
Steps to Reproduce:
1. View a web page with color images. Even black-and-white with drop shadows are
a problem. See http://platformglobal.com and compare the image text to how it
appears in IE.

Actual Results:  Image colors are badly distorted.

Expected Results:  Normal image display.

This is running on NT 4 sp6 with 256 color display.
Wouldn't the problem be that Mozilla itself (the chrome) is using up lots of colors?

Have you tried the Classic theme?  Does that help?
I am using the Classic theme, as I was when running prior builds which displayed
colors *much* more effectively. As stated in the original bug description, I
last used 0.9.3 and it had image display problems but nothing nearly this bad.

The statement about the Mozilla chrome 'using up lots of colors' doesn't make
sense to me. It's not as if running a 256 color display provides a fuel tank of
colors, and if too many get 'used' in one part of the screen then other parts
show up in black and white. 256 colors is enough to provide quite good image
quality across the entire screen, as IE does on my machine.

Someone else running NT 4 needs to test this. If it doesn't show up at higher
color depth, they should set their display to 256 colors and test it that way.
Additional checking has shown that this problem affects all colors displayed by
Mozilla, in chrome and pages. The toolbar icons are badly dithered and washed
out, and the folder icons in the Bookmarks menu are gray with aqua outlines
instead of being lavender as they appeared in 0.9.3. Note that my system
underwent no changes between running 0.9.3 and installing build 2001081303.

HTML colors are also butchered. See the background for http://bigcharts.com
which normally is light green but is gray in this build on NT at 256 colors.
Summary: Color images appear to be reduced to 16 colors. → All colors (chrome and pages) reduced to 16 colors - or worse.
This problem persists in build 2001082703..

Will someone else at least confirm the issue (use NT with display set to 256
colors).

This problem makes the browser basically unusable, and its MUCH worse than the
color display problem that  persisted until 0.9.3. Something went wrong between
0.9.3 and August 13, but this bug has not even been confirmed.
This problem showed up first in build 2001080904.

I've done more testing and found that this problem appeared with the changes
incorporated on 8/08/01. Build 2001080804 displays colors like release 0.9.3,
build 2001080904 is the first build that shows these major color display
problems in the images, chrome, everywhere.

I'm upgrading this to Blocker status b/c the color display is so bad that it
makes the browser unusable for regular testing purposes.
Severity: major → blocker
Confirmed with Windows NT, build 2001082703.

Changing to 256 colours produces horrendous results in terms of colour display.
 Not only the references Web site, but anything at all - including the Mozilla
splash screen.  Any site with a graphic image (such as my own:
http://www.dante.com/) is even more noticeably worse.

Under 256 colours, IE 5.0 performs very adequately.  Mozilla display is
*noticeably* worse than IE so this can't be a Windows issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
One reason that IE performs adaquately under low color depths is that it
actually dithers the colors, instead of just finding the "closest match" color
from the currently available pallete.

To see for yourself, just set your desktop to 256 colors and then load "some
page" with photos (such as CNN.com) in both IE and Mozilla.

So, it may not be so much a "Mozilla bug", but rather extra functionality
(dithering) that could be needed.
Alex,

That might be the case for the problem reported in bug 8850, which is itself a
serious image quality problem for jpegs displayed at 256 colors. But this bug,
which is much more general and much more severe, appeared from nowhere on August 9.

This bug is related to changes made to the mozilla code between the August 8
build and the August 9 build - as noted in the commments added on 8/27.

Please try these two builds to check if you have any doubt about this.

Best,

Dave De Graff
Oops - above comment should refer to bug 88560.
Ahh.. Yes.  I've looked at this bugger, and can see that _something_ needs
fixing here.  I've done some investigation, and found some interesting
information, and made some screenshots.  Mozilla needs either (1) fixed, or (2)
added dithering capabilities

My testing environment
 Windows 2000, Windows Millennium, and Windows 98  (I tested on all 3)

Here's what I did:
(1) I set my screen resolution down to 256 colors (I normally have it set at
32-bit color)

(2) I loaded a copy of Internet Explorer 5.5, and Mozilla  Build 20010828

(3) In each browser, I loaded this "color spectrum" page, which displays most
(if not all) of the colors. URL: 
http://www-stat.ucdavis.edu/~xidanren/colorspectrum.html

(4) I gagged at the color differences   ;)  (not a required step)

(5) I took a screenshot, and safely saved them into an Image Editor for
analysis.  The shots were not altered in any way, except to crop only the color
spectrum area. (I will add a 'picture' of the chrome later)

(6)I did a color count (built into the image editor).. here are the results from
each image (note: the image includes only what you can see. All extra chrome or
window parts were cropped in this test).  Note, that the section I have saved
does not include the full spectrum, but it is enough to show the contrast
between the two.
   The results from the test:
      Color spectrum as displayed by IE 5.5 = 184 Unique colors!
      Color spectrum as displayed by Mozilla= 20  Unique colors!

(refer to the screenshots I have provided.  I will add 4 separate images.. One
with IE 5.5, one with Mozilla, and a combined picture to compare the two side by
side.  Then, the last image will be of the different chrome looks in mozilla)


Notes:
  (1) A related bug (possibly):  Although I revert the colors back to 32-bit
after my experiment, Mozilla refused to pop out of its low color look (meaning,
Mozilla was still in 256 color mode, while the rest of the computer was in
32-bit color).  However, to note: Internet Explorer had the same problem.

  (2) Would dithering really make THAT much of a difference between the two?  If
so, then Mozilla needs to add that feature.

  (3) there is no number 3

  (4) This color problem was evident throughout all sites I visited while in
that low color mode.  I have a few other screenshots of the sites I visited, but
I will not post them unless someone specifically asks (or needs them).

Someone with some expert knowledge can solve this!  Unfortunately, I lack that
specific superpower. :(
Ok.. sorry for the spamming.. but one more note:
  You should look at these images with a monitor setting above 256 colors (to
show the contrast between the images)..

  Or, view the images in an alternate browser (like Internet explorer, which
I've tested on)
wee!
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.5
  Here is a screenshot from the 2001-08-08-11 trunk  (August 8th 2001).  I have
included both the "Modern" Theme and the "Color Spectrum" page that I used in
previous screenshots.

  This shot indeed shows that the build PRIOR to August 9th does NOT seem to
have the color spectrum problem.  The screenshot I took with the August 9th
build looks identical (I think) to the ones that I produced with yesterday's
build (meaning.. the problem seemes to have existed since the 9th).  

(I am sorry I don't have the image editing program that I used for the other
screenshots where I currently type this..  This screenshot image does not
include the 'classic' chrome. :(  The image tool I used is at home, but I am at
work now, where I must resort to more basic image editing.)  However, just take
my word for it that the "classic" chrome seems to look just about flawless
_before_ that August 9th build.

  Extra notes: If anyone wants to submit their own screenshots, here's A note on
how to do it (if you don't know how):
[1a] Capture the entire screen by pressing the "Prnt Scrn" key on your keyboard.
or
[1b] Capture only an active window (the window that has focus) by pressing "ALT
+ Prnt Scrn"

[2] Open up (almost) any image editor (such as Paint(yuck!) or Microsoft Photo
Editor, or better yet, a professional graphics program)

[3] Choose the "paste" option from the graphics program, and the screenshot
should now be editable.

[4] Edit the image as necessary, and Save as an image file  

(note, the standard "Paint" program with Windows makes some pictures look ugly,
because it reduces the quality of the image. Be cautious if you're using a
screenshot with great detail)
this is very easy. When Pavlov removed the old image lib, he disabled palette 
management support.

Before, Mozilla would load it's own color palette when activated, now it 
doesn't.

The first step in getting this fixed is this bug:

http://bugzilla.mozilla.org/show_bug.cgi?id=96770

Which will allow gfx to give the palette to widget so it can render it.

If this bug ever makes it in, I can look at putting back 256 color support in 
Moz (I am working on the OS/2 version)

would adding "Bug 95106 depends on: 96770" be appropriate in this case?  I
hesitate to do it myself, because I am not sure if that dependency is truly the
case.
Depends on: 96770
.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
OK, this bug was reported soon after the release of 0.9.3. It was originally
targeted for 0.9.4, then 0.9.5 and now 0.9.6.

We know exactly when this bug appeared: between the builds of August 8 and
August 9 of this year.

Can the developer who incorporated those changes go back and fix the issue? This
bug makes the browser unusable on a 256 color display. Pushing the fix target
release back isn't helping...
according to the reporter this is a direct result of imagelib2's landing, pavlov
is the person who wrote it and landed it, he's also the current bug owner. 

let's be realistic, spamming this bug doesn't help your cause. 

From the record ( http://bugzilla.mozilla.org/show_activity.cgi?id=95106 ) this
bug was *NEVER* targetted at 094, it was originally targetted at 095 and later
096.  

http://bugzilla.mozilla.org/bug_status.html#severity
Severity
This field describes the impact of a bug.

Blocker Blocks development and/or testing work
> No
Critical crashes, loss of data, severe memory leak
> No
Major major loss of function
> Not really
Minor minor loss of function, or other problem where easy workaround is present
> Yes
Trivial cosmetic problem like misspelled words or misaligned text
> Perhaps
Enhancement Request for enhancement
> Yes except that conflicts with the regression keyword.

I'm undoing a severity change which was clearly incorrect w/o picking the best
severity (normal, enhancement and trivial all seem like better candidates).
Severity: blocker → major
Keywords: regression
I've attached the fix.

Right now I have the palette hardcoded.

There should probably be a way to query imagelib for the 216 color cube, because 
both OS/2 and Windows will need it.
No longer depends on: 96770
*** Bug 96770 has been marked as a duplicate of this bug. ***
Incidentally, modern doesn't look so good at 256 colors.

We are only using 236 out of 256 color entries, so theoretically, if we could 
find out what colors are used for modern, we could add them to the default 
Mozilla palette so modern would look better.
Keywords: patch
Comment on attachment 54726 [details] [diff] [review]
Add palette code back into windows - fixes this problem

r=pavlov

this is great for now. possible changes to palette stuff at a later date
Attachment #54726 - Flags: review+
Comment on attachment 54726 [details] [diff] [review]
Add palette code back into windows - fixes this problem

sr=waterson
Attachment #54726 - Flags: superreview+
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
I opened:

http://bugzilla.mozilla.org/show_bug.cgi?id=108800

to address the need for a programmatic color cube.

I'm marking this bug fixed
You need to log in before you can comment on or make changes to this bug.