GIF options when loading

[GoogleCodeExporter]

What do you need to do?
Configure type of conversion when we are loading a .gif file. Conversion to 
RGBA by default could not be desirable or could be automatically avoided (e.g. 
with .gif files creates by ASEPRITE, with index 0 as transparent in every 
frame).

How would you like to do it?
When we load a .gif that cannot be converted to indexed format automatically, a 
dialog could appear showing the following options:
1) Convert to RGBA.
2) Assign a palette entry as transparent color automatically (if it is 
possible).
3) Pick a explicit color as transparent (ASEPRITE 0.9 will support non-zero 
palette entries as transparent color).

Original issue reported on code.google.com by davidcapello on 1 Mar 2011 at 10:30

[GoogleCodeExporter]

Original comment by davidcapello on 3 Mar 2011 at 2:36

• Added labels: Milestone-0.9

[GoogleCodeExporter]

I always work with indexed color, and I never want it to automatically convert 
to RGBA. What would that mean if I had multiple indexes set to the same color? 
Aseprite would not be able to tell the difference between these indexes, if I 
understand correctly.

Other programs such as Grafx2 are able to read and save which color index 
number is transparent. Will aseprite be able to read this as well?

Original comment by erdav...@gmail.com on 3 Apr 2011 at 5:13

[GoogleCodeExporter]

Yes, the GIF format use indexed color so any user would like to edit GIF files 
in that way. With the RGBA conversion you loss some information, so the 
automatic RGBA conversion is a bad thing to do (right now, the development 
version of ASEPRITE 0.9dev is working in this way).

I don't know exactly but I think Grafx2 cannot handle GIF animations, and that 
is where GIF loading process is a problem. With GIF files, each frame can have 
a different "transparent index", that is "the color that must not be merged 
with the previous frame", so it isn't a global transparent index. For example, 
in the 1st frame the transparent index could be 0, but then in 2nd frame the 
transparent index could be 1 (and the 0 color could be used to paint black or 
the color in the first palette entry whatever it is). The final composed 
animation can use the 256 colors in the screen (something impossible to be done 
with a global transparent index).

I think Grafx2 is simulating a global transparent index, it's useful to 
read/write GIF files created with Grafx2, but you cannot load any kind of GIF 
file that you can found on Internet. The general idea is to be able to read any 
animation as you see in the browsers (which is how ASEPRITE 0.9dev is working 
right now converting GIF files to RGBA).

The general idea of this issue is to add some special behaviour in the loading 
process of GIF files. In the final version of ASEPRITE 0.9, you should be able 
to load GIF files as indexed images only when: 1) no transparent index is used, 
2) a GIF with one frame is loaded, 3) a constant transparent index is used in 
all frames. In any other cases (e.g. two or mores frames have different 
transparent index), a warning message with some options should be shown (E.g. 
Would you like to convert this GIF animation to RGBA?)

Also you will be able to change the global transparent index to something 
different to 0 index.
Any idea is accepted because I've not started with this issue yet. Thanks for 
the comments!

Original comment by davidcapello on 3 Apr 2011 at 6:00

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Ah thanks for clearing that up. I never use more than one transparent color for 
sprites, so I will probably never see that warning message. But if the .gif 
format can store different transparent indexes per frame, why not support that 
in aseprite instead of converting to RGBA?

Original comment by erdav...@gmail.com on 3 Apr 2011 at 7:46

[GoogleCodeExporter]

Well, supporting different transparent indexes per frame is just one part of 
the problem. With GIF files you can (should be able to) select different types 
of compositions between frames. For example, each frame can be configured to a) 
replace the previous frames completely, b) merge with the previous frame, c) 
replace a portion of the previous frame, etc.

The (b) case is where the transparent index variations make sense. But anyway 
ASEPRITE is not prepared to work in that way. GIF files is like a composition 
between frames (instead of layers). ASEPRITE composites layers, but each frame 
is unique (the frame is rendered with the content of all layers in the current 
frame). In GIF files a frame could depend on the content of the previous one 
and so on. E.g. The last frame could show you parts of the first frame.

Supporting both compositions (layers+frames) can be a mess (right now onion 
skinning is a problem with multiple-layers). I think that the GIF trick to 
composite frames should be automatically done in the saving process only to 
reduce the final file's size, and not something delegated to the user.

PS: Something similar is the way as FLI/FLC files work, each frames is a chunk 
of image-differences that is be merged with the previous frame.

Original comment by davidcapello on 3 Apr 2011 at 9:14

[GoogleCodeExporter]

Fixed with commit c32551db64a2dc3cf76ba9bd1731a00c81b72006:
https://github.com/dacap/aseprite/commit/c32551db64a2dc3cf76ba9bd1731a00c81b7200
6

Original comment by davidcapello on 25 Jun 2011 at 8:13

• Changed state: Fixed