GIMP script for making animated previews
Tuesday, December 15, 2020 - 23:26
Created a script for rapidly producing animated GIFs for your spritesheet art submissions. You don't have to use it, but now that I have it, I know I'll be using it all the time! :)
Setup is just 6 easy steps: (No need to repeat steps #1 through #6 after the first time. Just do steps #7 & #8 for all subsequent animations)
- Download the latest version of GIMP. it's free! (If you already have GIMP installed, skip to step #4)
- Wait for GIMP to finish downloading. Wait for it... waaait! Ok, Install it! Quick!
- Start GIMP and let it run through its first-time initialization.
- Download the .zip file attached to this forum post. "spritesheet-to-animated-gif-preview.zip" below.
- Extract the .scm file to GIMP's scripts folder. See these instructions for how to find the scripts folder... Or easier still check out the embedded instructional video below. (For the default windows location, slap this path in your file explorer: %appdata%\..\Roaming\GIMP\2.10\scripts\
- Now open GIMP and load your spritesheet image. IMPORTANT: You'll want to refresh the scripts so it finds the new one you just added: "Filters" menu > "Script-Fu" > "Refresh Scripts"
- Now that the spritesheet is open, go to the "File" menu > "Create" > "Spritesheet to Animated Gif Preview"
- Adjust the settings: frame width and height, number of frames in your spritesheet (blank/empty frames don't count!), the background color you want for the preview.gif, etc.) then mash "OK" and watch the magic!
Now you have an animated gif to use as a preview for your OGA submissions! Let me know how it goes if you end up trying it out. Yes, yes, I know there's other ways to do this. All of them are better, too. But I either didn't know about them or couldn't afford them. So here's my free and open source solution! :P
Attachments:
spritesheet-to-animated-gif-preview.zip 3.4 Kb [39 download(s)]
Looks like a great tool.
I can't name a tool better than this, for the purpose of creating previews quickly, since it doesn't require specific experience, decisions based on it or manual procedures. It can be used by anyone even if they isn't familiar with GIF's architecture, and i'll recommend it to whoever wishes to create animated samples of 32 bits PNG but has trouble with manual conversion.
There is no victory. There is no defeat. There is just work to do.
Also: For now i must go to work, but this evening i'll try it myself, it looks very useful, the file below is a manual conversion, when i'll come back i'll download GIMP, install the script and recreate the animation with your script. I don't see reasons for the experiment to go wrong, and if it doesn't i'll use it myself, since manual conversion is indeed time consuming.
There is no victory. There is no defeat. There is just work to do.
Definitely going to try this out. Thanks!
@Puffolotti: Oh, wow! Why didn't I think to stress test this script with one of your famous 5000+ cell spritesheet monsters?
Yeah, it took a while but it worked great for me... though I naively assumed no one would ever have more than 1024 frames in a sheet. :/ I had to update the script with a new maximum of 16384 frames, so be sure to redo steps #4, #5, and #6 to get the latest version. I didn't do the same spritesheet as the one you've indicated above, so by all means, still give that a test. Let me know how it goes for you.
--Medicine StormHere we go.
The results are excellent. Thank you again, MedicineStorm, you had a great idea.
Now, down to business:
First image is a direct confrontation of first frame (Any frame could have been used.)
The other 3 files are
A gif created with ASEprite by manual procedure. (and, sorry if i sound presumptuous, but i think i have great familiarity with the task.)
A gif created with Medicinestorm's script with an arbitrary background.
A gif created with Medicinestorm's script with black background.
Short answer: Perfect for the task.
Long answer:
I applied a coloured background, and it applied a form of optimization that resulted in dithering and consequent "green dots", wich was to be expected, the tool isn't designed to print production ready stuff. The overall effect is apparent on real objects, probably ignored by most human minds on abstract object such as sparks or smoke.
The complexity of the optimization on the GIF compression is seen in the filesize.
Since the effect is interesting and can be used in production, i launched the script another time with a black background, and i got surprised by noticing that the dithering was much less noticeable. I removed the darkest colors in the palette untill they were in the sprite, and i can say that as long as the sprite itself doesn't contain colors darker than 64/255 it can be used to convert PNGs into 8bits sprites, if required.
In general i'd advise to use a black background for solid objects, coloured background for etheric objects or abstract effects, for best result, but the optimization isn't really spoiling the preview, the result is rather good.
Perhaps it could be expanded, but the selling point is the simplicity and the fact it is nearly impossible to do mistakes.
I'll do some more experiments.
I'm ashamed to admit currently i can't put more than 5400 cels in a spritesheet and therefore i'm not allowed to laugh like a pirate and shout: "16384? HA! that's not even warm up!" ;)
There is no victory. There is no defeat. There is just work to do.
That's not presumptuous, you're the perfect person for this test. :)
It looks like the last .gif (black background) has some frame position decay. Toward the end of the animation the frames are vertically shifting out of position. I am hoping that is just the result of entering a slightly inaccurate frame height value (one pixel too many?).
Hahaha! Thank goodness! I was worried you'd still be able to overwhelm the script. :D These are great results. Better than I expected, to be honest. I know it isn't going to be as high quality as the hardcore processing you can do, but like you said, the selling point is the simplicity and the fact it is nearly impossible to make mistakes.
--Medicine StormThere is objectively no position decay at all. It is possible that black background affects the outline differently than any other color, for reasons connected to the fact any factor multiplied by 0 gives 0 and this is why i ran different tests expecting different results.
Actually, if there is an apparent shift in the image, it would happen on not-black background, because, judging by the time the computer chews the procedures, it is when background isn't black that dithering becomes esoteric.
However: A slip of the finger (I.E. an height of 155 instead of 156) is always a possibility, but it would have produced a shift of 43-1 (First row won't get shifted) pixels in the end, in this particular spritesheet.
The Gif below has been obtained by typing 155 on purpose, and as expected, every 30 frames, the image shift down by 1 pixel. (Every self-respecting scientist/researcher deep down loves explosions and breaking stuff on purpose. )
There is no victory. There is no defeat. There is just work to do.
About the RAM or virtual RAM limit, it is pretty simple: Beside the limitation of 16384 frames, even if we talk about bigger frames, it looks like i can't put together on a PC a spritesheet so big that your script can't trim on the very same PC, but if i can put a sheet together on Aseprite, then your script can create a GIF.
There is no victory. There is no defeat. There is just work to do.
Wow, this is great. Totally missed this as I thought there would be some indication somewhere that there was a message posted to one of my original posted items. I was unaware there was a continuation.
Did it not alert you when I posted this comment? https://opengameart.org/comment/88683#comment-88683
Oh, well. Glad you've found it! :) I hope you'll give it a go. I'm glad you've been adding the animated preview to all your spritesheets, but I have to be honest, the gifs generated by the Chasys Draw IES Artist program don't fully do them justice.
--Medicine Storm