Closed Bug 88560 Opened 23 years ago Closed 16 years ago

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

Categories

(Core Graveyard :: Image: Painting, defect)

x86
Windows NT
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: mozilla, Unassigned)

References

()

Details

(Whiteboard: CLOSEME 2008-08-30)

Attachments

(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: http://static.userland.com/weblogsCom/images/scripting2weblogscom/Header.jpg http://www.cnn.com/2001/ALLPOLITICS/06/30/cheney.health/story.dr.device.jpg ...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 pavlov@netscape.com 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 should.
Status: UNCONFIRMED → NEW
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 moved)
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 mozilla.org 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: http://users.ntr.net/~dickermn/colors.html 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... http://pages.sbcglobal.net/dickermn/Colors/
retargeting
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 ? http://www.mozilla.com/firefox/
Severity: major → minor
Whiteboard: CLOSEME 2008-08-30
Please reopen if it still occurs in Firefox 3. http://www.mozilla.com/firefox/ -> WORKSFORME
Status: NEW → RESOLVED
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.

Attachment

General

Creator:
Created:
Updated:
Size: