Gif disposal for source sprites with translucent pixels

behreandtjeremy · April 23, 2025, 9:41am

When an RGB color mode sprite contains translucent pixels, the gif generated on export does not properly dispose of frames.

builtIn

Test animation sourced from Makoto/Sprites | Street Fighter Wiki | Fandom .

prepped

For expected result, a script can be used to prepare the sprite. (Convert to indexed with a dither and a palette that has only one transparent color swatch and all others opaque.) For an animation, Bayer ordered dithering would be preferred over FS error diffusion, but I didn’t see any way to get Bayer to support alpha.

github.com/aseprite/aseprite

src/app/file/gif_format.cpp

main


      
                           disposal,
                           // Only the last frame in the animation needs the fix
                           (fix_last_frame_duration && gifFrame == nframes - 1));
          
                m_fop->setProgress(double(gifFrame + 1) / double(nframes));
              }
              return true;
            }
          
          private:
            void calculateDeltaImageFrameBoundsDisposal(gifframe_t gifFrame,
                                                        gfx::Rect& frameBounds,
                                                        DisposalMethod& disposal)
            {
              if (gifFrame == 0) {
                m_deltaImage.reset(Image::createCopy(m_currentImage));
                frameBounds = m_spriteBounds;
          
                // The first frame (frame 0) is good to force to disposal = DO_NOT_DISPOSE,
                // but when the next frame (frame 1) has a "pixel clearing",
                // we must change disposal to RESTORE_BGCOLOR.

My initial guess would be that there are several places in this method where alphas are being compared without a threshold filter applied, i.e., a’ = a >= 128 ? 255 : 0 . Unless, that is, the alpha has been filtered in a prior step.

(Secondarily, the disposal method is from the gif 89 spec. Aseprite writes an 87 header. I don’t know that it’d matter to most modern importers, though.)

Gasparoken · April 24, 2025, 2:57pm

Thanks @behreandtjeremy. This is a known issue: GIFs currently don’t support transparency at intermediate levels. Currently, Aseprite uses a simple (perhaps overly simple) criterion to determine whether a pixel should be rendered as transparent or opaque:
If alpha < 128 then the pixel color is assumed transparent;
else the pixel is opaque.
Therefore, if the artist wants to simulate transparency, they will need to perform dithering before exporting. Perhaps it would be helpful to add an option to include dithering in the GIF export process.
This report reminded me of the issue: Issue with Transparency on Gifs · Issue #1438 · aseprite/aseprite · GitHub

On the other hand, as you showed in the first gif, there is a bug. I created an issue for this GIF export broken when there are pixels with alpha <128 · Issue #5142 · aseprite/aseprite · GitHub.

Finally the Gif87/Gif89 spec, there is an open issue about this Aseprite always stamps GIF87a version in the file header when saving in GIF format · Issue #4746 · aseprite/aseprite · GitHub