Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0007210 [Squeak] Graphics minor always 10-10-08 03:12 11-15-08 02:20
Reporter wiz View Status public  
Assigned To andreas
Priority normal Resolution open  
Status assigned   Product Version 3.10.2
Summary 0007210: [Bug] Gif anim reader has problem reading certain animes.
Description for this one

download one of the animated polygons and mathconsult.

The one I am using as an example is from: [^]

In a fresh sq7179 basic image (i.e. 3.10.2)
get a file list.
select the downloaded file.
open it using the leftmost open button (this creates the animated morph as opposed to the static one.

for this particular morph you will see 3 glitches in the 24 frames.
Additional Information There are eighty animaged gifs in the unipoly directory.
All are 128 by 128 depth 8.
For each poly reading it in will have certain frames that do not read correctly. (Some polys read in completely ok, but that seems to be the exception,

Exploring the morph and diving down to the list of forms used for frames shows which frames are glitched.

The problem is solid in that the same frames will glitch for the same gif file each time.

As far as I can tell the glitches all seem to be similar. The first third of the form data is missing. The lines of info are slightly skewed. The bottom of the glitched forms are left all 0's which is not part of the file data.

Some analysis.
The color map seems to be ok.
The bitmap for the pixels should start out with transparent pixels which are coded as hex 40 . So the starting words of the file would usually be 16r40404040 .

In the messed up frames this is not so at the beginning.

The downloaded gifs play perfectly well in quicktime and in
my browser (IE 5.0) so the files are correct and were not corrupted in the down load.

The problem is in earlier squeaks as well. I have the same problem in
sq7053 (there is an additional problem due to an earlier transparency bug too.)
The problem still exists in the squeakland etoys branch of squeak.
At least as of etoys 3.0 (fresh dev addition).

For each of the glitched frames the first word is always the same.
That's probably a clue.

The same condition is probalby screwing up in the same way.
For this file the frames 3,7, and 11 are glitched. In other polyhedra the number of glitched frames is different. and the index of those glitched frames also vary from file to file.

I rate this as a highly annoying bug.

Attached Files  perlredblink.gif [^] (995 bytes) 11-14-08 03:09 [^] (3,350 bytes) 11-14-08 03:09 [^] (3,286 bytes) 11-14-08 16:41

- Relationships

SYSTEM WARNING: Creating default object from empty value

child of 0007209assigned andreas A Mother for animation bugs 
child of 0007223assigned andreas [RFE] GIFReadWriter and Animated Gifs can be done better. 

- Notes
(0012756 - 695 - 779 - 779 - 779 - 779 - 779)
10-29-08 05:53

more analysis,

Their are 3 types of bugs I get.

1) On some animated gifs, some of the images are munged.
2) On other animated gifs, errors corp up while reading.
Two symtoms are
a) getting a GIFReadWriter does not understand #colors:
This comes from readBody returning its reciever and not a form when the logic slips by all the if statements.
b) getting a illegal store into array. in readbody.
The immediate cause of this is when retrieving a nil from suffix table and trying to store it into a byte array.

a) and b) both seem to be caused by the bit reading getting out of sync and trying to read the count byte that preceeds the next subblock as if it were data.

a suivre
(0012762 - 633 - 729 - 729 - 729 - 729 - 729)
11-08-08 05:20

I believe I am closing in on the problem.

In GIFReadWriter>>readBitData
some assumptions are made that do not match the spec.
The spec says that a clear code may appear at any time.

This means you could get two in a row.
Or more probably you could get a clear code just before an eoicode.

readBitData assumes that the code after a clear code will be a pixel code
and forces it (by masking to be in pixel code range)..

The cure would be to hold off on assumptions and check each code for all of its possible meanings.

I need to do more work to find out if I am on the right track. But this looks hopeful.
(0012765 - 1112 - 1250 - 1250 - 1250 - 1250 - 1250)
11-14-08 03:26

Ha. Found it.

My last note was off the track .

The problem turned out to be a mistaken assumption about bits per pixel.

The header (more correctly the virtual screen) contains bits per pixel information for reading the color table.
This was being used in the image blocks (i.e. the raster data part.)
to set a bitMask .
The bitMask was used to decide whether the code was a pixel code or a compression code.
The bitMask should have been set from the imageBlocks initialBitSize.

Generally for one image gifs there will be agreement.
But animated gifs could and would have images of different bit depths.

So the bitMask was being set too high (usually) and the image would decompress wrong.
Or more rarely there would be problems where the animate gif could not be read at all. This was probably due to the other case. (I have not checked yet.)

The uploaded patch:
does the minimum to fix the problem.

You can see this by trying the small perlredblink.gif before and after the patch.

You can also try the anim24 gif from mathconsult (see above).
(0012766 - 138 - 150 - 334 - 334 - 334 - 334)
11-14-08 10:05

It fixes the issue for anim24.gif, but not for other examples like: [^]
(0012767 - 167 - 209 - 209 - 209 - 209 - 209)
11-14-08 16:44

Thanx Torsten ,

I filed out the wrong method at first.

The change you seek is in

Yours in curiosity and service, -Jerome Peace
(0012768 - 158 - 206 - 206 - 206 - 206 - 206)
11-14-08 16:46
edited on: 11-14-08 16:48

Hi Torsten,

I'll look into your other example later.
I'm aware this is not a complete fix.
It just felt important eoungh to push out.

Cheers, -Jer

(0012769 - 1054 - 1210 - 1210 - 1210 - 1210 - 1210)
11-15-08 02:20

Ah, disco_anim_bf16.gif uses features of graphic control that are not implemented in the reader of anim morph.
An easy way to see this is
using file list read in a downloaded copy of the gif (as a gif file)
using the red menu>extras>mouse up action

self stopStepping; step.

That will cause the anim to single step thru the images.

The second two images are meant to be displayed over the first image.
Instead we are erasing the first image before displaying the next.

To fix this the graphic controls disposition index would have to be respected. Presently it is not even noticed.

There is also a problem with anims that are displaced from the origin of the virtual screen.

Anyway the jist is that those repairs are beyond the scope of this report.
I would like to see gifs working in squeak as well as they do on the web.

Thank you for the pointer to the gifs.
Good SMALL gifs that demonstrate problems are invaluable in finding and proving fixes.

Yours in curiosity and service, --Jerome Peace

- Issue History
Date Modified Username Field Change
10-10-08 03:12 wiz New Issue
10-10-08 03:12 wiz Status new => assigned
10-10-08 03:12 wiz Assigned To  => andreas
10-10-08 03:13 wiz Relationship added child of 0007209
10-29-08 05:53 wiz Note Added: 0012756
11-08-08 05:20 wiz Note Added: 0012762
11-14-08 03:09 wiz File Added: perlredblink.gif
11-14-08 03:09 wiz File Added:
11-14-08 03:26 wiz Note Added: 0012765
11-14-08 03:39 wiz Relationship added child of 0007223
11-14-08 10:05 tbn Note Added: 0012766
11-14-08 10:15 tbn Issue Monitored: tbn
11-14-08 12:39 lewis Issue Monitored: lewis
11-14-08 16:41 wiz File Added:
11-14-08 16:44 wiz Note Added: 0012767
11-14-08 16:46 wiz Note Added: 0012768
11-14-08 16:48 wiz Note Edited: 0012768
11-15-08 02:20 wiz Note Added: 0012769

Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
83 total queries executed.
48 unique queries executed.
Powered by Mantis Bugtracker