229836 - Black being rendered as Green (poor smilies are ill)

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[alanjstr]

Some of the smileys at http://www.nbproducties.nl/ss/main.php?id=vrolijk are
green edged instead of black.  This happens on Windows and Linux.  They appear
correctly in Internet Explorer and Konquerer.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031226
Firebird/0.7+

And in Opera some are black, some green and some red...?

Comment 1

[alanjstr]

smiles are yellow with green black and blue borders in BeZilla 1.4

Comment 2

[Jo Hermans]

In Safari 1.0, they're a mixture of black, blue and green borders :-)

Comment 3

[Olivier Cahagne]

this smiley renders with green borders Linux 20031231:
http://www.nbproducties.nl/smilies/klappen.gif
Opera 7.50P1 on Linux doesn't even render it (at all).
Gimp 1.2.3 loads it with black borders and a grey background.

Once I remove the background from this image and save it, Mozilla and Opera load
it fine with black borders.

Comment 4

[Jo Hermans]

I looked at 1 image in particular,
<http://www.nbproducties.nl/smilies/blijeknipoog.gif> (it's the left-most on the
line with the 'moose-smiley', with 1 large eye).

The border shows green in Mozilla 2003123105, even when showed on a single page
(so no background is involved). But it shows black in Safari 1.0, in Preview and
in GraphicConverter. GraphicConverter showed me that the green color (index 1)
was used for transparency, and the border was really black (index 12, but
somehow Mozilla decided to use green for the border too).

Comment 5

[Hermann Schwab]

http://www.nbproducties.nl/smilies/klappen.gif

Mozilla/Win98 shows it green, Opera and Irfanview golden/brown as it should be.

Image properties from IrfanView: 31x23x4 BPP
Compression: GIF - 6 images
Size: 31 x 23 pixel
Color: 16 (4 BitsPerPixel)

I downloaded with Opera, Mozilla shows it green.

Comment 6

[Daniel de Wildt]

ACD See shows the images also with a green border.
Maybe an error in the images?

Comment 7

[Hermann Schwab]

Regression
Big regression from Mozilla 1.3 to Netscape 7.1, (assumed to be like Mozilla 1.4)
small regression from Netscape 7.1 to Mozilla 1.4.1

I could attach 31 kb sized screenshots of each of them, but don´t think, it´s
needed.
So I guess this regressed sometime between Mozilla 1.3 and Mozilla 1.4,
and then some more from Mozilla 1.4 to Mozilla 1.4.1.
Can somebody test with 1.4a, 1.4b ?

Comment 8

[Hermann Schwab]

Attachment: 13kb screenshot Mozilla 1.4a, one smiley green.

this smiley regressed from 1.3 to 1.4a:
http://www.nbproducties.nl/smilies/hoedje5.gif
was brown in 1.3, now green in 1.4a

installed 1.4a from zip, crashed in imglib2.dll when loading the smiley page,
Talkback TB28317957E sent to talkback5.netscape.com

Comment 9

[Hermann Schwab]

Attachment: 12 kb Screenshor Mozilla 1.4b, many smileys green

screenshot as seen with Mozilla BuildID 2003042604,
made with Mozilla 1.4b Build ID 2003050714.

This regressed between 1.4a BuildID 2003040105 and 2003042604.

Comment 10

[Daniel de Wildt]

The fix for bug 199701 is checked in in that period. It checks the colorindex
for valid upper boundary and set it to 0 if it exceeds.
I tried convert.exe from an older ImageMagick (Win version 5.4.7) on the some
GIFs (blijeknipoog.gif, datwasikkeniet.gif, wink.gif) and got an error about an
invalid colormap index.

Comment 11

[Daniel de Wildt]

I forgot to say that the patch for bug 208622 has moved this boundary check.

Comment 12

[alanjstr]

Why is it being set to zero instead of the max, if it exceeds the max?  Or is
that just because its invalid.

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

ok, that was tor's patch, assigning the bug to him.

Comment 14

[tor]

Attachment: map illegal index values to black

Comment 15

[Daniel de Wildt]

alanjstr: I manipulated the palette of an image
(http://www.nbproducties.nl/smilies/thanx.gif) by setting all colors to white.
IE still shows the black text in black, so I assume that IE also set the colors
of pixels with and invalid color index to zero (black).

Comment 16

[ArronM (:paper)]

Comment on attachment 138427 [details] [diff] [review]
map illegal index values to black

technically, the red green blue comments when setting rgbRowIndex to 0 might be
incorrect, but I'll pretend I'm on unix and give it a r+. ;)

Comment 17

[tor]

Checked in.

Comment 18

[Jo Hermans]

Seems fixed in build 20040121 on Mac OS X 10.2.8