I was importing an animated .gif to Scratch just to look at the process and to maybe update this wiki article, but I got a shock from Scratch. When it opened, the individual frames came out all weird, and many had large spots of color missing. I tried uploading to tinypic to show it here, except that failed there as well, even though it's not failing in any of the image viewers I have, my web browser, or the java code I wrote in Processing (created by MIT). If interested, here are a few snapshots:

Animation on Tinypic
Scratch

And that brings up another interesting issue. The image pre-view seemed to be glitching, but the image itself isn't failing in Tinypic. Hmmm…

Anyway, here's a clearer example of what's happening. This time around, I decided to test on a floating hamburger .gif.

In reality:



In Scratch:



Oh and finally, to add on, I had also tried importing a third star animation (actually the second I tried). That came through to Scratch without an hitches.

So, does anyone know why this is happening?

With regards,

ErnieParke

Try importing the .gif into 1.4, then upload the project to 2.0. Make a new sprite, then in the costumes tab, select the “import costume” button and import the .gif. That should bring the full .gif into Scratch.

ProdigyZeta7 wrote:

Try importing the .gif into 1.4, then upload the project to 2.0. Make a new sprite, then in the costumes tab, select the “import costume” button and import the .gif. That should bring the full .gif into Scratch.

Thanks for pointing that out, but I really don't need these .gif's, and this topic is more or less for reporting the bug and trying to figure out why this is happening. Bugs often reveal more about their code/counterpart then one actually notices.

With regards,

ErnieParke

ErnieParke wrote:

ProdigyZeta7 wrote:

Try importing the .gif into 1.4, then upload the project to 2.0. Make a new sprite, then in the costumes tab, select the “import costume” button and import the .gif. That should bring the full .gif into Scratch.

Thanks for pointing that out, but I really don't need these .gif's, and this topic is more or less for reporting the bug and trying to figure out why this is happening. Bugs often reveal more about their code/counterpart then one actually notices.

With regards,

ErnieParke

I know what's going on. Animated GIF files are really bunches of frames put together. However, using whole frames can make a GIF file really, really huge and slow to load. What some programs do is optimize the GIF file while it's being rendered - basically, the next frame only displays the pixels that have changed from the previous frame before it; what happens is that the resulting GIF file has frames that are spotty in some areas (the blank spots being the places where the pixel colors have not changed).

Scratch 1.4 basically takes this into account when a GIF is imported, but Scratch 2.0 does not. If a GIF is imported without hitches into Scratch 2.0, then you likely were importing a GIF that wasn't optimized (and therefore has full frames intact).

If you're having trouble understanding what I mean, open that hamburger GIF file in a animated-GIF-capable editor (such as GIMP) and look at the frames, and then do the same with that star animation you mentioned.

cheddargirl wrote:

ErnieParke wrote:

ProdigyZeta7 wrote:

Try importing the .gif into 1.4, then upload the project to 2.0. Make a new sprite, then in the costumes tab, select the “import costume” button and import the .gif. That should bring the full .gif into Scratch.

Thanks for pointing that out, but I really don't need these .gif's, and this topic is more or less for reporting the bug and trying to figure out why this is happening. Bugs often reveal more about their code/counterpart then one actually notices.

With regards,

ErnieParke

I know what's going on. Animated GIF files are really bunches of frames put together. However, using whole frames can make a GIF file really, really huge and slow to load. What some programs do is optimize the GIF file while it's being rendered - basically, the next frame only displays the pixels that have changed from the previous frame before it; what happens is that the resulting GIF file has frames that are spotty in some areas (the blank spots being the places where the pixel colors have not changed).

Scratch 1.4 basically takes this into account when a GIF is imported, but Scratch 2.0 does not. If a GIF is imported without hitches into Scratch 2.0, then you likely were importing a GIF that wasn't optimized (and therefore has full frames intact).

If you're having trouble understanding what I mean, open that hamburger GIF file in a animated-GIF-capable editor (such as GIMP) and look at the frames, and then do the same with that star animation you mentioned.

Ahh… So that's why the GIF images come out so spotty. I've never really even known that GIF images sometimes were being optimized that way, and it's an igneous trick to come to think of it. I think that might also be a nice piece of information to put on the wiki once I get around to updating the GIF article, after my Pre-Calc test. Well then, thank you cheddargirl for telling me!

With thanks,

ErnieParke

ErnieParke wrote:

cheddargirl wrote:

ErnieParke wrote:

ProdigyZeta7 wrote:

Try importing the .gif into 1.4, then upload the project to 2.0. Make a new sprite, then in the costumes tab, select the “import costume” button and import the .gif. That should bring the full .gif into Scratch.

Thanks for pointing that out, but I really don't need these .gif's, and this topic is more or less for reporting the bug and trying to figure out why this is happening. Bugs often reveal more about their code/counterpart then one actually notices.

With regards,

ErnieParke

I know what's going on. Animated GIF files are really bunches of frames put together. However, using whole frames can make a GIF file really, really huge and slow to load. What some programs do is optimize the GIF file while it's being rendered - basically, the next frame only displays the pixels that have changed from the previous frame before it; what happens is that the resulting GIF file has frames that are spotty in some areas (the blank spots being the places where the pixel colors have not changed).

Scratch 1.4 basically takes this into account when a GIF is imported, but Scratch 2.0 does not. If a GIF is imported without hitches into Scratch 2.0, then you likely were importing a GIF that wasn't optimized (and therefore has full frames intact).

If you're having trouble understanding what I mean, open that hamburger GIF file in a animated-GIF-capable editor (such as GIMP) and look at the frames, and then do the same with that star animation you mentioned.

Ahh… So that's why the GIF images come out so spotty. I've never really even known that GIF images sometimes were being optimized that way, and it's an igneous trick to come to think of it. I think that might also be a nice piece of information to put on the wiki once I get around to updating the GIF article, after my Pre-Calc test. Well then, thank you cheddargirl for telling me!

With thanks,

ErnieParke

No problem.

Closed by request.