AuthorTopic: Question About Animation Format (Read 584 times)

Hi Everyone,I made an animation in Graphics Gale. It is 16bit (64000 colors). When I try to save it as a GIF file, GraphicsGale shows an error that says:GIF format does not support high-color and full-color. Should the image be changed to 8bpp (256 colors) format?

When I choose YES, it saves it in a very low quality. When I choose NO, it doesn't save it at all... What should I do?! Help me please! I really need it in high quality

GIF only supports 8bit colour, you cannot have an animation with more than 256 colours per frame. You could optimize each frame by hand to use ~256 colours so that it looks better than the automatic conversion.

Alternatively, create a video instead of a GIF. You can save your frames as still images, then import them into a video editor to make a video out of them.

If you manually convert to 8bpp you are given options you aren't when converting on save.All Frames menu, Color Depth... item.Experiment with different combinations of (all unhelpfully named) algorithms and dithering.One of them might give better results.Failing that you can try exporting in a less lossy format (avi or image per frame) and doing the conversion in another program.

if you absolutely have to show us the movement GGale can actually make .avi files.file/save as/.AVIdont know about their quality though, video isnt really a good format for pixelart, pixelart is supposed to be 8bit. anything more than 8bit means you're using more than 256 colors and really, from what little you've shown I doubt you're doing some complex alpha blending thing that requires itWhen you've got your video just upload it to youtube or somewhere, paste the url. the quality wont be great but we'll see the movement

To see the detail we'd probably have to look at each individual frame, that way we would know why you would use more than 256 colors. go toexport/mutiple filesorexport/combined image that way we can actually see the frames.Pixelart animations that use more than 256 colors are not really common at all, so you should avoid them unless it's absolutely necesary. I've only heard of a format called APNG to handle stuff like this, but it isnt very well suported in the web or in pixelart programs, because animation with the level of pixe levell detail that pixelart implies is just not common.

Thanks for all the suggestions guys. Only reason I chose 16 bit was because I really want to make something great. But since I'm a beginner in pixel art, I did't know it will be a problem to make it a gif.

Colors in a GIF still have 24 bit depth (8 bits per RGB channel = 8 * 3 = 24), even though pixels use only 8 bits and therefore can only have one of 256 different colors. But these 256 colors are any of the 16 million available. Your GIF has 24 bit colors and an 8 bits per pixel format.

There are three concepts at play here. One is color depth, which is how many bits are used to represent each color shade. In a vast majority of instances these days we work with 24 bit colors, 8 bit per color channel. GIF also uses 24 bit colors.

Second concept is indexed colors. In a GIF, the colors are put into a color table, essentially the palette your GIF will use. Each color in the table has its index, so that the GIF can easily refer to it by a single number, from 0 to 255. Ergo, indexed colors.

Now, each pixel needs to be able to say which of these 256 colors it uses, so to represent a number from 0 to 255 you need 8 bits (2^8 = 256). So the GIF needs to spend 8 bits per pixel to tell which color each pixel has. This is the third concept, bits per pixel. GIF uses 8 bits per pixel.

If an image is not indexed, it will store the color directly for each pixel instead of using a separate table. It will say exactly which 24 bit shade to use for every pixel. So it will use 24 bits per pixel and represent 24 bit colors. In this case bits per pixel corresponds to color depth. But you can't say the same for indexed images, because they chose to make a tradeoff. In the GIF example, they spend only 8 bits per pixel (1/3 the size) to choose a color, but can only have max of 256 colors. And they have to separately store data for the palette, 256 colors * 24 bits, so the total space gained is a bit less than 2/3. It's more nuanced in practice because most image formats also use compression on top of that, but let's not get into that.

Hopefully not too giberish to understand.

Also, you can make something great no matter the color depth or bits per pixel used. There are plenty awesome black and white games that only use 1 bit colors/1bpp.