
You can see how much space there is around the crab!
Animated Crab uploaded by oleksiis on IMGUR. My guess is that this is a game asset sprite. It's unclear whether the uploader is the original artist; let me know if you know the original source!
There is an animated pixel crab that I'm quite fond of, but it doesn't fill its 256x256 grid space. Today's Sharepiece Challenge is my experience trying to use GIMP to edit it into a larger Discord emoji. You can download the GIMP XCF file at the bottom of this post.
Here is a list of all related September 2025 "Sharepiece Challenges"
Announcing "Lightweight Daily Sharing"
Practice: "Eleventy CLI Proof-of-Concept"
MON: "Trying to Draw Cats"
TUE: "Resizing an Animated GIF of a Crab"
WED: "Making a Clonk Sound with Unfamiliar Music Tools"
THU: "Refresh of Emergent Task Timer for Lawyers"
FRI: "Refresh of Powerpoint Resume Template"
The Goal
Embiggen the crab! We need to adjust all the frames at once, which look like this in the LAYERS panel:


You can see there are 4 different layers. By editing the layers, you can change the animation. I'm not doing that, but I do want to crop it down so the crab will appear much bigger in the 32x32 space that is allocated for it as an Discord Reaction. It will render at 128x128 if the emoji is entered by itself on a chat line.
Step 1: Crop the Crab to Content Size
Since each animation frame is slightly different, you can use the CROP TO CONTENT command to make a minimum-sized canvas. This is helpful for doing the kind of processing we need to do.


After the crop, there are no transparent "border pixels". You'll also notice that all the frames of the animation are drawn on top of each other. This isn't a problem; each frame will be exported as a separate frame.
Step 2: Determine the Pixel Scaling Factor
Because this is pixel art that has been scaled-up, we want to know what the original art size was. We want to maintain a power-of-two size for clean scaling of pixel art; this is a general principle for designing pixel assets for a video game. It might not actually be necessary for Discord, but old habits die hard.


Anyway, you can see that the dimensions of the box is 8x8, so the original asset was scaled by 8 times. Since the content width of the crab is 144 pixels, we can divide that by 8 to see that the original size was 18 pixels. It was likely a 32x32 sprite originally, if it's from an old games. Or, it could have been drawn larger because pixel art for modern games aren't constrained by low resolutions like we were back in the early 1990s. Now, it's just an art style!
Step 3: Squaring Things Up
Emoji-type graphics in general are square aspect, meaning their width matches the height. So, it's a good idea to make sure the asset is the same.


First I checked that 144 was evenly-divisible by 8 (our measured pixel scaling factor from before), which should ensure that scaling down will be even.
Next, I used the Set Image Canvas Size command works here, because we're not scaling the actual pixels up. The cropped content box is 144x112, so we want to resize the canvas so the width is the same as the height.
Step 4: Re-exporting the Animated GIF
When there is more than one image layer, GIMP will export each layer as an animation frame.


I set these options:
- loop forever option makes the animation loop. Not all display programs actually support this, but we can set this as our preference.
- frame disposal when unspecified option probably tells the GIF renderer in Discord to erase each frame before drawing the next. Turning it off is an optimization technique when you've designed a GIF to have unchanging areas in frame 1, and frames 2 and onward just change tiny parts that "self erase". If I don't turn on frame disposal, then the crab will just be a shimmering blob rather than a clean animation.
Aside: As an animated GIF editor, GIMP isn't really designed like a "real" bitmap animation program like the venerable DeluxePaint, Director, or Debabelizer software I used to use in the 1990sWhy not just use Photoshop? I canceled my Creative Cloude subscription quite a while ago, and am transitioning to other tools.. I miss those tools.
First Result
Not as clean as I would have liked. Here's what the new one looks like compared to the old one.


There is white fringing around my version, whereas the original smaller version seems to be properly anti-aliasing to the background color.
Usually white fringing is causes by assuming the wrong blending algorithm (e.g. straight versus premultiplied rgba) or some inconsistency with how the GIF exporter generates transparency. It seems more likely, as GIF is an indexed color format, that I messed up the palette table or there is some assumption about what pixel color is considered "transparent". GIMP doesn't seem to provide this level of insight in the UI, so I probably need to look at using some other program if I can't find a solution.
On a closer look, I think this isn't fringing. Because the asset is larger, more of the lighter pink is showing and so it looks relatively more white. The original asset is so small that the pink edge hilights disappear. By comparison, the new asset makes much better use of its space so the edges are noticeably thicker, which allows the lighterer color to show more prominently.
Finding Workarounds
- I could try a more modern format like animated PNG if Discord supports it. It looks like the PNG exported for GIMP doesn't generated animated PNG. A quick Google search revealed no quick or obvious solutions.
- It's possible that there is a pixel offset rendering caused by a subpixel offset. I'm rendering to 144x144, which is a bit bigger than 128x128 as Discord allegedly supports. This is evenly divisible 4 to 32x32.
As I mentioned in Step 2 above, the pixel scaling factor is 8. I can use this scale factor to resize the original art back down to individual pixels, then scale it up by a factor of 7 again to get very close to the target size of 128x128.
Step 5: Rescale to pixel-perfect 128x128
I first rescaled the original content-cropped image (144x112 pixels) down by a factor of eight, creating a "pixel perfect" original one-to-one pixel of 18x14. Then, I set canvas size to 18x18 to make the aspect square.
Then, I was ready to scale back up! This is the final scale-up from 18x18 to 126x126.


The important option is to make sure you're using no interpolation (see underlined option)! Otherwise, you'll lose the crisp pixel edges. Essentially, we are converting one pixel into a 7x7 pixel block.
Next, to get our desired 128x128 pixel, we go back to SET CANVAS SIZE and set it to 128. Here's what the dialog box looks like.


I also dropped the the crab to the very bottom of the image, to again avoid subpixel aliasing which might be contributing to the weird fringing effect. We probably can't entirely avoid it because our pixel block size is 7, and 7 doesn't divide evenly by a power of two as 8 does, but I thought I'd try it anyway. With modern computer screens people are less likely to notice a bit of pixel misalignment due to the very high resolutions of modern LED/LCD panels.


Original (144x144) versus resized crab (128x128), showing the improved space-filling despite the smaller canvas size.
» Download the GIMP file crab-128x128.xcf
Here is a list of all related September 2025 "Sharepiece Challenges"
Announcing "Lightweight Daily Sharing"
Practice: "Eleventy CLI Proof-of-Concept"
MON: "Trying to Draw Cats"
TUE: "Resizing an Animated GIF of a Crab"
WED: "Making a Clonk Sound with Unfamiliar Music Tools"
THU: "Refresh of Emergent Task Timer for Lawyers"
FRI: "Refresh of Powerpoint Resume Template"
Sharepiece Evaluation!
The idea behing this Sharepiece Challenge is to pick something that helps get unstuck with one's creativity/productivity. It's an experiment to uncover what works for people and what does not. That said, there are just a few criteria: small scope, can see, can share.
Conformance to Sharepiece Spec
Is lightly scoped?
PASS (more or less)
Can be seen or held?
PASS (it dances!)
Easily shared?
PASS (downloadable!)
Elapsed Time:
4.5 hours + 2.0 hours
This took much longer than I thought it would, largely due to the documentation that went into making this blog post and enhancing the blog's RSS feed "excerpt" system for "hidden" excerpts that show up only in the RSS feed. The actual time goofing around with GIMP was maybe an hourAddendum: I also spent some time adding Step 5 in the evening..
Reflection
I might have to consider whether blog posts themselves are their own deliverable. They are NOT lightweight tasks when documentation of steps is involved. Hmm. Something to think about.
I yammer about daily productivity challenges on the DSRI Discord Community Server every day. If you are a human-centered architect-builder that likes to chat, you might like the vibe.