Closed Bug 88560 Opened 23 years ago Closed 16 years ago

Major jpeg display/dithering problem on NT w/ 256 colors.


(Core Graveyard :: Image: Painting, defect)

Windows NT
Not set


(Not tracked)



(Reporter: mozilla, Unassigned)




(Whiteboard: CLOSEME 2008-08-30)


(5 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010628
BuildID:    2001062815

Many jpeg images look like **** on NT with 256 colors.

See above url and compare to IE. Also visible with many other jpegs; gifs seem
to display OK.

For example, see also:

...among many others. Some jpegs do seem to appear correctly, others not.

Reproducible: Always
Steps to Reproduce:
1. View one of the image URLs provided above, or another URL that contains jpegs
which appear poorly on NT running at 256 colors.

Actual Results:  Badly displayed image.

Expected Results:  Proplerly displayed image.

I've expected that this is a well-known problem that is being addressed, but I
did not find duplicate reports when searching for them.

Seems possibly related to the following bugs:

a. 50464 (Opened August 27, 2000, last activity reassigned to on March 19 2001 - and this is still listed at 'NEW'?)

b. 73624 (Performance issue at 256 colors on NT, not image quality).

I'm reporting this as major b/c I think that there are a lot of people still
running 256 colors, and when you see images like this it's a big turnoff to
using the browser for most people.
we don't currently do any dithering on windows at 256 colors.  i suppose we 
Ever confirmed: true
Target Milestone: --- → mozilla1.0
Bug 95106 seems like a severe regression that may be related to this bug. 95106
was reported on 8/13, but no one has apparently tried to confirm it so far.

Please check it out running NT with display set to 256 colors. This more severe
color display problem shows up first in the 8/09 build, and makes the browser
basically unusable at 256 color display setting.
I experience this too while using NT over a Citrix client. There is not
dithering in Mozilla of any image. Event the Themes don't get ditherd.

As side NOTE: Netscape 6.1 does a better job of color handling but it still
isn't as good as Netscape 4.7x on the WinNT with 256 color.
I am having the same problem.  Machine is an HP VE with ATI 3D Rage IIC video
card.  It appears that images (gif and jpg verified) are being rendered in 16
colors.  I have never seen this problem from other apps.  Tested at both
1024x768 and my usual 1024x1620 setting.
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
Target Milestone: mozilla1.0 → mozilla1.0.1
CC'ing Asa. Methinks this should not be past 1.0. Besides the people who use 256
color normally, I and many of my colleagues use Windows 2000 Terminal Services
which also shows this problem. And especially the Modern theme looks horrible.
Moving bugs to new Image: GFX component
Component: ImageLib → Image: GFX
Possibly because of fixes of bug 135226, this looks pretty good now. Running
trunk build 20020511 on Windows 2000 Server under Terminal Services. Used to be
pretty bad, but now the dithering does a fairly good job.
Just got the latest build (build id:2002051208, Win NT, display 256) hoping it 
would solve the dither problem. As I got the last persons e-mail about it 
working better. I looked at several pages and the gif's still seem to have a 
problem especially with color. At the Lizard logo at that top left 
looks orange instead of red. Jpeg's look better but they are also faded in 
comparison to Netscape 4.78 or IE 5.5 sp2. Gifs are bad at handling gradients 
naturally but they shouldn't be as bad as they seem in Mozilla. Both Netscape 
and IE do a better handling of gif's. 

My questions is why can't the original Netscape's 7.7x dither engine be used as 
it works fine?

I have 98SE and I see same bug in 256C for both Mozilla 1.0 build 2002053012 AND
Netscape 6.2, looks exactly the same.  Yay microsoft. You know how to DITHER.
don, can you take a look at this at some point?
Assignee: pavlov → dcone
I believe the fixes in bug 135226 may have addressed some Windows-specific
issues, but there is still a problem when rendering to a 8-bit / 256 color
display, as I'm seeing similar results in the solid colors and theme banners
when using 8-bit color mode X displays on Unix as well.  I've attached a
screen-grab of Mozilla 1.0 rendering the gradiated graymodern theme buttons
against a steel-blue background, with the browser itself using the normal
(bluish) modern theme, all while running in the 8-bit color space (gtk is using
a 6x6x6 color cube).  Note that the images inside the browser window are a bit
pale, but dithered reasonably, as are the buttons on the masthead, but the
solid colors chosen for the menu bar and masthead background (which is a
1-bit-wide pixmap streched across the top) are a very rough approximations of
the desired colors.
A few observations...
The steel-bluish background on the test page is specified as RGB #778899, and
the solid color of the top menu bar background in the modern theme is #dde3eb,
which is how they show-up on 24-bit color.

When these solid colors (or horizontal stripes of solid colors in the case of
the masthead background) are displayed on an 8-bit display they get mapped into
a 6x6x6 color cube, and displayed as:
     #778899 -> #669999
     #dde3eb -> #ccffff
Which I suppose is a reasonable bit of rounding, though not optimal.  The real
question is then whether better choices for colors could/should be made for
these, or whether to just dither all the solid colors to make a better
approximation of the desired color.  Note that with the 24-bit jpeg displayed as
an image on the 8-bit display, the dithering gives a good approximation of the
requested colors, but that same color does not appear in the theme.

In reasearching known bugs in this area, I also came across several general
complaints about color usage on 256-color displays which are likely related:
  bug 140683 : no 256-color support
  bug 100398 : color palette selections wrong 
  bug 104712 : wrong background color in 256 color mode
and others.  Comments by those bugs' owners include "We have very few users
using 256 colors." and "Who cares about 256 color mode!  I *really* want to mark
this as "wontfix" since we never will"  Not sure what needs to be done to prove
the worth of this class of problems, but clearly these are at least being
reported, so *someone* cares about 256 color mode.
Created some test cases: Three sides of a 32x32x32 color cube, created as
background colors in a blank-element table and as jpeg images:

The jpegs images are how these tables are rendered on a 24-bit display, and show
the 32 different bands of color in each direction.  Rendering these tables on an
8-bit display shows the banded sides of the color cube, usually 6x6x6, undithered.

This shows: (1)The color choices made by mozilla when not rendering an image are
approximated to their nearest renderable single color without dithering; (2)I
know very little about coding efficient HTML (better examples welcome)
*** Bug 156014 has been marked as a duplicate of this bug. ***
Possible related bug? In Remote Desktop (XP) 256 color mode in 0.61 (and TB 0.1)
the toolbars and other UI components look blacked out. If i run my mouse over
them they will sometimes appear. In 15bit mode or higher things look fine.
Attaching a jpeg to demonstrate.
Hard to tell if this is lack of dithering, wrong colormap entirely, or a
combination of the two.  What do you get with the tables vs images test I
posted?  Note that the URL I posted in Comment #17 is no longer valid, due to an
ISP switch.  The current test is at...
Target Milestone: mozilla1.0.1 → Future
Vedran Miletic, the target milestone field belongs to the bug assignee. Please
stop changing fields in Bugzilla. Thank you.
Target Milestone: Future → ---
QA Contact: tpreston → image.gfx
is this problem gone?
bug 140683 was fixed 2003-01-15
Assignee: dcone → nobody
Does the problem still occur in Firefox 3 ?
Severity: major → minor
Whiteboard: CLOSEME 2008-08-30
Please reopen if it still occurs in Firefox 3.

Closed: 16 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.