90347 - JPEG displayed with noise (unlike IE)

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Alexandru Savulov]

Here is a JPEG that's displayed whith noise (tiny paralel horizontal lines that 
appear brighter that the rest). The JPEG is created from a bitmap that displays 
alternating lines (1px) in the colors 0x0080FF and 0x004080 + a 50% opaque layer 
that gradients from 0x000000 to transparent (Adobe Photoshop 6.0). IE and ACDSee 
display this without noise.
(attachment to follow)

Comment 1

[Alexandru Savulov]

Attachment: the noisy JPEG

Comment 2

[Matthias Versen [:Matti]]

looks idetical for me with win2k build 20010711 and NS4.75 and IE5.0
(32Bit, 1024x768, Geforce MX)

Comment 3

[Thomas Guyot]

Identical for me too, win2k, build 20010628, voodoo3

Comment 4

[Aaron Kaluszka]

That is weird.  I see it too, but if I do a [Print Screen] from IE and Moz and
paste them into PSP and compare them, they are exactly the same. 
Win2K/2001070904/TNT2

Comment 5

[Alexandru Savulov]

Ok, I forgot to mention:

home: Geforce2 MX,  ViewSonic PF790, 1200x1024, 32 bit
work1: ELSA Synergy Force, ViewSonic P810 1200x1024, 32 bit
work2: ELSA Gloria Synergy, ViewSonic P180, 1024x768, 32 bit

can see this on all 3.

Comment 6

[Francisco León]

This is addressed in lots of other bugs, so try to find for a dupe
Anyway, your attachment looks flawless for me, so i attached my own, and it's
100% reproducible
Just go to www.kernel.org and look at the bottom right image
Attaching screenshot
I have traced the bug to scrolling. If you scroll very fast way up and down past
the image, no horizontal lines are shown, but if you do it very slowly, for each
"scroll line" you do, mozilla inserts an horizontal line
Very annoying, catfood-worthy

Comment 7

[Francisco León]

Attachment: Horizontal lines in images

Comment 8

[Francisco León]

BTW i am using linux, perhaps you are making mention to something else

Comment 9

[Marc Attinasi]

Looking at attachment 41955 [details] on my Mac Ti Powerbook the noise is very obvious.
Mac IE on the same screen looks much smoother, showing not noisy horizontal
artifacts. What I see are regularly spaced bright horizontal lines, about 10
pixels apart.

On the Laptop's LCD screen it is very obvious, but on the attached Viewsonic
P810 monitor it is there but less obvious.

Comment 10

[Alexandru Savulov]

Ok, if I can, I will try to create a JPEG that displays what I mean in a more 
obvious way. The second attachment is not the same problem since is displayed in 
the same way by IE. (Also Nav 4.77 has the same problem.)

Comment 11

[Marc Attinasi]

... even Opera 5.0 displays the image smoothly (like IE) ;)

Comment 12

[Francisco León]

No way, my attachment shows perfectly in IE and ns 4.7x
Well, not the attachment, i scanned the BAD image, so it will look the same in
every browser!
If you want to see the image just go to www.kernel.org

Comment 13

[Alexandru Savulov]

Attachment: the side by side comparsion file as bitmap (read following comment)

Comment 14

[Alexandru Savulov]

i added a comparsion file (windows 24 bit bitmap *.BMP --- LINUX users: sorry
for the inconvenience!).

Note the darker JPEG region of the NS6.1 snapshot. If your hardware does not
allow you to see it with your naked eye, try to use a graphics processor to
"pick" the values from the bitmap. You'll also note that among the brighter blue
lines there are always 3 consecutive that have B=245, the 4th is always B=251
and thats every 8th line of the bitmap. This is what is making me think about
some troubles with the DCT alg. (disclaimer: I did not draw this bitmap by hand! :-)

Comment 15

[Alex Stewart]

Francisco's problem (ie horizontal lines) is bug 83289.  I'm not sure what
others are seeing is the same bug, so I'm not marking as a dup.

Comment 16

[Lasse Marøen]

I was about to file a new bug, but I think this is the same thing. It's a JPEG
similar to the first attachment in this bug but mine is more visible (on my
machine at least, which btw runs 20010830 on WinMe). The jpeg was made in
Photoshop 6 using the save for web function with quality set to 98%.

I made a screenshot of the jpg rendered in Mozilla and IE6 side by side. Will
attach that to. 

Comment 17

[Lasse Marøen]

Attachment: Another noisy JPEG

Comment 18

[Lasse Marøen]

Attachment: screenshot of previous jpeg in Mozilla and IE6

Comment 19

[Alexandru Savulov]

Good shot Lasse! That's exactly what I see on the first attachment!

Comment 20

[Stuart Parmenter]

I see this too.  Not sure what the cause is..  I expect something in libjpeg,
which I'm not too familiar with.

Comment 21

[tenthumbs]

Mozilla is getting exactly what it's asking for.

I can reproduce the observed behavior with the IJG djpeg utility. See 
the attachment for the difference between
  djpeg 47711.jpg
and
  djpeg -dct fast -dither ordered -nosmooth 47711.jpg.

This last is what mozilla uses. All mozilla has to do is change a few 
settings.

Comment 22

[tenthumbs]

Attachment: djpeg demo

Comment 23

[Lean Fuglsang]

*** Bug 115432 has been marked as a duplicate of this bug. ***

Comment 24

[Stuart Parmenter]

Changing from using JDCT_FASTEST (JDCT_FAST) to JDCT_ISLOW or JDCT_FLOAT solves
the problem.  I am concerned that this will result in a possibly noticable
slowdown.  The "Another noisy JPEG" attachment takes about 8ms longer if you use
ISLOW or IFLOAT on my Sun Ultra60 (Dual 450Mhz UltraSparcII).  The difference
between slow and float might be noticable on some other machines.

I suppose we could add yet another pref (joy) for image quality... something
that I could pass in to each decoder giving it a hint on what to do.

Comment 25

[tenthumbs]

I tried to measure the difference between JDCT_ISLOW and JDCT_IFAST on 
Linux but the difference is lost in the multitasking noise. It's 
certainly no more than 5% and I suspect it's actually less than 1%. I 
would think appearance is more important than speed here.

I think you should avoid floating point for the moment. There are all 
sorts of ways that the fpu and the compiler can conspire to create 
"errors." People will start complaining again. :-)

Comment 26

[Stuart Parmenter]

over to nivedita

Comment 27

[Nivedita (gone)]

Attachment: patch file fixing the noise in the JPEG

changed the DCT method to JDCT_ISLOW and DITHER mode to JDITHER_FS

Comment 28

[Stuart Parmenter]

Comment on attachment 65190 [details] [diff] [review]
patch file fixing the noise in the JPEG 

r=pavlov

Comment 29

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 65190 [details] [diff] [review]
patch file fixing the noise in the JPEG 

sr=[e-mail]

Comment 30

[Stuart Parmenter]

checked in for nivedita.

Comment 31

[Stuart Parmenter]

*** Bug 90916 has been marked as a duplicate of this bug. ***

Comment 32

[Terri Preston]

Hey Alex, I've never been able to reproduce this bug, so is it fixed for you?

Comment 33

[Simon Kirby]

I've noticed in the latest nightly builds that the problem has been reduced, but
there are still artifacts present that aren't visible in other programs and
browsers.  You'll need a sharp monitor or LCD (I'm viewing it on a ViewSonic
VG150) to see this, but take a look here:

    http://blue.netnation.com/mozilla_jpeg/

It appears the ringing around the sides of the test objects is now reduced, but
the objects themselves still have blocky chroma.  See the example links on that
page for pictures which show this problem.

It's probably another quality/speed tradeoff setting affecting the rendering
again...