Transparent background color is lost with saving a file as a gif

[FrancisCoulombe]

This seems to be new with the current beta on Steam.

Steps to reproduce:
-Make an ase file with a single normal layer, indexed colors, with the first color set as the transparency color. Fill the field with that transparent color.
-Draw something on the canvas with some other color.
-Save As > save this as a GIF file. The resulting GIF file will have lost its transparency.

If you open the new file, you will find its palette has been changed, with black colors added until index 63, and the new background color added as 64th color in the palette.
If you select that color and delete it from the palette, then save the file again, transparency is restored.

Expected behavior: The saved gif should keep its transparency.

[Salvo]

I don’t know much, hope i can help you!

Basically the gif format to save files has a limited set of colours (256) that can be saved in the gif.
Since you can use only a small range of colours, you can’t have a detailed animation if you use a wide range of colours in your drawing that aren’t in the limited set of colours of the gif.
But that’s another thing, i believe your problem is that since gif doesn’t support alpha channels, you can’t save that transparency when you save your file.

If you want to know exactly why you have that problem you should ask to @eishiya or @BraidAcer since they know more about this topic.

(in case you don’t know what an alpha channel is here’s the definition)

[eishiya]

I don’t think this is an alpha channel issue. GIF allows having one transparent colour, it has to be fully transparent. The first colour as transparency usually works. It’s only if OP’s transparency colour isn’t fully transparent that there would be an issue.

---

What version of Aseprite are you using? Do you perhaps have a background in your Aseprite file? Backgrounds, even if they’re hidden, have been known to mess up GIF exports in Aseprite. Try deleting the background before you export, if you’ve got one.

[FrancisCoulombe]

I am using a single normal layer, there are no background layers here. My aseprite version is 1.3 beta 5, x64

This is not an issue of me using the wrong colors, either. I have been using aseprite for years, this is a recent change in how the program behaves.

[FrancisCoulombe]

I recorded a short little stream to illustrate the problem better, hope this clarifies the problem:

[Scarodactyl]

I just spent a bit of time reproducing this issue. It’s a bit hard to activate but 100% real and weirdly inconsistent in its application.
Note that you have to save the file as a .aseprite file first. If you save directly as a .gif it renders fine. It has to first be a .aseprite file and then saved as a .gif.
I made a new blank file. It preloaded my default palette, which has three transparent colors, one is slot 31, one in slot 32 and one in slot 33. I drew a box and filled it with 31, a circle with 32 and the rest with 33.
And this is how it looks in aseprite:

I saved the file as a .aseprite, and then saved it as a .gif. It looks the same of course, but when you reopen the file it looks like this:

31 remained transparent, but areas indexed 32 and 33 were rendered black.
Not only are areas indexed 32 and 33 now black, 31, 32 and 33, plus several more rows, are now filled with black.

I have no idea what’s up with this but it’s a real issue.

[BraidAcer]

Hi, GIF format is generally not suitable for saving your original artwork, because it may modify your palette to keep up with GIF format internal requirements. For example, it only support one fully transparent index color and does not support partial alpha transparency at all. Please, keep your artwork as .ase/.aseprite and only export as GIFs.

[LuxTK]

31 remained transparent, but areas indexed 32 and 33 were rendered black.

I don’t know if it’s related but I’ve always had troubles when my palette’s transparent color is not the first color in the table and the file was indexed.

You could try editing the palette and moving one of those transparent colors to the first index. Then try again (btw there’s a remap button in case your animation starts to look weird after switching colors in the palette).

[Olga_Galvanova]

you can set which colour is going to be transparent in indexed mode by clicking middle mouse button. it will place tiny white dot at the center of colour swatch in palette.
scarodactyl has one in index 0, so the transparent area 31 is - after export - actually index 0, while the others are still index 32 and 33. and those can’t be transparent due to gif restrictions.
i would still expect aseprite to replace all transparent pixels with this index when exporting to gif though.
however, to be fair, when exporting gif in cases like this, aseprite does warn the user that gif doesn’t support palette with alpha channels.

[FrancisCoulombe]

Setting the transparent color to be index 0 does not prevent this bug - like I say in the first post, it adds a bunch of colors until it has 64, and it replaces all instances of the previously transparent color in the image with a new color it sets to be index 63. If you want to restore transparency, you need to open the GIF file, delete that final color from the palette and save it again.

To be clear, to make this bug happen, you need to save the file first as an ASE file, then open it and THEN save it as a gif. If you initially save it as a gif, it doesnt happen.

The issue is not that I keep my main files as a gif, I keep them all as ASE files - but I export my assets as GIF files for my project. This bug means there is an extra annoying step for exporting my files - every time I export a file as a GIF, I need to save it, close it, re-open it, fix the transparency and save again.

[behreandtjeremy]

Hi @FrancisCoulombe,

I saw you brought this issue up on your stream the other day, and I thought I’d poke around some. In Aseprite v1.3-beta7-x64 on Windows 10 I created an .aseprite file that looked like this:

My transparent color index is set to index 0. My layer is not a Background layer (it’s not underlined in the timeline).

Even though it looks like there is a uniform transparent background behind the dots, there are four different transparent backgrounds in each quadrant of the sprite. Here’s a screencap of a Replace Color dialog that tries to show the hidden difference.

I used this palette…

GIMP Palette
Name: Problem Palette
Columns: 4
Channels: RGBA
# Profile: sRGB
# Colors: 14
255   0 255   0 0x00ff00ff
255   0   0   0 0x000000ff
  0 255   0   0 0x0000ff00
  0   0 255   0 0x00ff0000
255   0   0 255 0xff0000ff
  0 255   0 255 0xff00ff00
  0   0 255 255 0xffff0000
255   0   0 170 0xaa0000ff
  0 255   0 170 0xaa00ff00
  0   0 255 170 0xaaff0000
255   0   0  85 0x550000ff
  0 255   0  85 0x5500ff00
  0   0 255  85 0x55ff0000
255   0 255 255 0xffff00ff

…knowing that multiple transparent colors in indexed color mode was asking for trouble. I also included translucent colors with alpha less than 128 and greater than 128 knowing they’d wouldn’t be left intact.

When I first exported, I got this result:

Reopened in Aseprite, it looked like this:

I’m guessing that, for a palette with 14 colors, the nearest power of 2 is 16. (I still don’t get the additional mystery last color.)

I changed my first palette color to opaque magenta (0xffff00ff). It turned out like this:

I reopened my original .aseprite file. I went to Edit > Preferences > Alerts and checked Show options when saving files for .gif.

Then, when I tried to save as a .gif again, this prompt came up

I unchecked preserve palette order. This .gif turned out like this:

Reopened in Aseprite, it looked like this:

I also experimented with converting from indexed color mode to RGB color mode.

The conversion removed the distinction between the different quadrants of transparent color. I’ll try to illustrate this with a screen cap of the magic wand tool:

In RGB mode, whether to preserve order is grayed out. It’s not an option when saving a .gif:

I opened Aseprite v1.2.30. (I changed my theme to make it easier for me to tell the difference.)

There is no option to preserve palette order. The exported .gif looked the same as the 1.3 beta export when preserve palette order was turned off.

For anyone who knows more about C++ than I do, my guess would be to switch to the beta branch of the repository and start with gif_options.h and gif_format.cpp to excavate. (Whether or not a sprite is considered to have a background seems to also play a role in how it is saved.)

You could also write a Lua script to alter your .aseprite files in bulk… But first it’d depend on why you have multiple transparent colors in your palette. (Well, it appears that you do in the stream, though as seen above it’s hard to judge by eye.)

Hope that moves the ball forward some,
Jeremy

[FrancisCoulombe]

Thank you! Yes, selecting the GIF options and unchecking “preserve palette order” has fixed the problem for me. It seems like preserving palette order doesnt handle certain kinds of GIF palette setups correctly. I dont use different kinds of transparency in my sprites, though I do have multiple fully transparent colors in my palette that are unused, you think those being there could be messing it up?