150041 - Jpegs do not render correctly

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Alex Hosking]

Well I cant describe it, Please look at the Attachment

Comment 1

[Matthias Versen [:Matti]]

Build ID ?
Hmm, no attachent here :-)

Comment 2

[Alex Hosking]

Attachment: Look here and see.

I have Used IE as the other example But I could of used Opera.

Comment 3

[Alex Hosking]

This has been the same in all the builds i've used.

Comment 4

[Matthias Versen [:Matti]]

hmm, where is the difference ?

Comment 5

[Dash]

Look at the edges of an object in the image.  It's aliasing, kinda.  More like a
half downloaded image that hasn't completed it's rendering.

Example: Netscape Communicator load a large graphic and it will get better
quality in passes.

Comment 6

[Tuukka Tolvanen (sp3000)]

Yeah the left image appears half res. Reporter, where's the original jpeg?

Comment 7

[Tuukka Tolvanen (sp3000)]

Original jpeg appears to be here: http://ajuk.150m.com/images/ajuk.jpg
Gqview shows it smooth to the pixel, in Mozilla it's about half resolution
(looks like 2*1 px blocks).
Linux trunk cvs 20020607.

Comment 8

[Alex Hosking]

So are we all agreed that s a bug and it needs fixing?
Or is this worksforme? I will have a look on anther comp as soon as I get a chance.

Comment 9

[Bruce Brackbill]

Good eye Alex.

I also see "the jaggies" with Mozilla Build 2002061308 ( and NS 4.7 )
Win 95 16bit colors.

IE 5.5 does NOT display any jaggies. ( the image is smooth ) 

Comment 10

[Shark Daddy (Jonathan L.)]

This has been visited before; it's not that JPEGs don't render correctly, they
do, but rather that they don't look as nice close up as in IE, because IE uses
some anti-aliasing technique to make images look better.

Comment 11

[Alex Hosking]

No I made that image IE has it right
I should know I made it

Comment 12

[darinf]

FWIW, I downloaded the image from the location in comment #7 and opened it in
Mozilla 1.0 and IE 5.5 SP2, both under win2k. I can see the difference. Then,
seperately, I downloaded the image to two different files and opened up them
both up in my image viewer, Firehand Ember which I trust very much. The two
files are identical to each other in Ember, and identical to how it appears in
IE, but Mozilla clearly is different and has that "one more pass needed" look to
it, especially around the right side/bottom bend of the U and J. Conclusion:
Mozilla is not rendering this image correctly.

Addendum: Netscape Communicator 4.7 displays it the same as Mozilla. Opera
displays it as it appears in Ember and IE.

Comment 13

[tor]

Taking bug.

Comment 14

[tor]

Attachment: patch to use more accurate upsampling - now matches MSIE output

Comment 15

[Shark Daddy (Jonathan L.)]

Yes, I performed a similar task to what Darin did with PSP and see a similar
result now.

tor, does this actually match the output, or simulate it?

Comment 16

[tor]

It looks the same as the attachment and do_fancy_upsampling is actually the
default setting for libjpeg, so I assume that's the same settin that MSIE/Opera
are using.

Comment 17

[Alex Hosking]

Attachment: Original Image

This is the Original JPeg
-------------------------------
Insert Clever Comment Here

Comment 18

[Stuart Parmenter]

what is the performance cost (decoding time) by of changing this option?

Comment 19

[tor]

For a 2726x1729 single pass jpeg (hst_crab_nebula.jpg, if you happen to have
a redhat system with the desktop-backgrounds package installed), user time for
djpeg increases from 0.55 to 0.83 seconds on a p3-500.  The amount of time spent
data copying and display inside mozilla is probably much more.  Anyway, we
shouldn't be cutting corners in quality for performance.

If anyone mentions prefing this I'm going to sic mpt on them...

Comment 20

[Stuart Parmenter]

Comment on attachment 88805 [details] [diff] [review]
patch to use more accurate upsampling - now matches MSIE output

r=pavlov

Comment 21

[Christopher Blizzard (:blizzard)]

Comment on attachment 88805 [details] [diff] [review]
patch to use more accurate upsampling - now matches MSIE output

sr=blizzard

Comment 22

[tor]

Checked in.

Comment 23

[Alex Hosking]

Is a bug fixed llwhen there a working patch to fix it or is it fixed when
Mozilla includes the patch in one of the nightly builds?

Comment 24

[tor]

Neither - it's fixed when a patch to fix the problem has been applied to
main source repository.

Comment 25

[Adam D. Moss]

Attachment: red/green test image.

This image should make the before/after difference quite
clear for verification.  Pre-patch should be chunky, post-patch
should simply be blurry.  The white sworls should be unaffected.

Comment 26

[Adam D. Moss]

Attachment: red/green test image at 1:1:1 sampling

This image has its chroma channels sampled at
full-resolution and should hence be identical (and sharp)
before and after the patch, or regression has occurred.

Comment 27

[Alex Hosking]

I may sound dumb but how do I use the Patch?

Comment 28

[Daniel Mario Vega (Restore MNG Support --> #18574)]

Alex,

Normally you don't need to use a patch. Unless you are testing the patch and
building yourself mozilla from sources.

Once the patch is "checked in" ( see Comment #22 )you wait for the next nightly
build or stable release. New "nightly builds" appears every few hours and can be
donloaded from: http://ftp.mozilla.org/pub/mozilla/nightly/latest/

But these build are for testing purposes. They could be "unstable". However most
of the time they are good enough for daily use.

Comment 29

[Alex Hosking]

Will this be im Mozilla 1.01?

Comment 30

[Alex Hosking]

Yes I see It fixed and I also see it fixed in NN7! Whey.

Comment 31

[Alex Hosking]

I should note that this bug only shows up allot worse on flat screens

But im still seeing it.