Closed GoogleCodeExporter closed 8 years ago
Original comment by davidcapello
on 3 Mar 2011 at 2:36
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
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
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
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
Fixed with commit c32551db64a2dc3cf76ba9bd1731a00c81b72006:
https://github.com/dacap/aseprite/commit/c32551db64a2dc3cf76ba9bd1731a00c81b7200
6
Original comment by davidcapello
on 25 Jun 2011 at 8:13
Original issue reported on code.google.com by
davidcapello
on 1 Mar 2011 at 10:30