GIMP Version: 2.8.14
Operating System: Mac OS
GIMP Experience: Intermediate Level

List any ERROR messages you received:
GIF (or PNG) image Message

Couldn't simply reduce colors further. saving as opaque.

Message repeated once.

---

hello all, first question:

For starters, I'm wondering why does gimp 2.8.10 default to 255 colors when choosing indexed mode? I always type 256 -- i just feel entitled to that one extra color. But then I often run into a problem, for which I have yet to identify the cause. The problem happens only occasionally when i'm exporting my work as 256 color indexed png(or gif). I get an error message to the effect of ~failed to save transparency, saving opacity instead~. Sorry I don't have the exact words, although i had the same problem today while trying to export a gif. I first optimized for gif, then indexed, and exported, and i still got the error:

GIF (or PNG) image Message

Couldn't simply reduce colors further. saving as opaque.

Message repeated once.

here's a screenshot:


...my background was changed to black, and so was another layer, not sure why this is, or what causes this? i've had the problem before when trying to save a png as 256-color indexed, however, oddly, i don't get the problem if i choose fewer colors. here is my gif saved as 128 colors(i like powers of 2), it seems unaffected:


and here is my messed up gif; it I can't get rid of the black background no matter what i do:


I also did a quick test with GIMP 2.10, and it gives me the same error, although the server won't let me upload more than three images apparently...

Can anyone tell me what is the cause of my problem? I like to save things in indexed form to keep file-size small(and also for stylistic reason), but I don't necessarily want to sacrifice too much definition, and want to choose the max(256). is it possible to make this work?

in GIF, the transparency is really one of the colors (to be more accurate, one of the color indices is designated as being the one for transparent pixels). So if you use 256 colors, you can't have transparency. I think you now understand why Gimp uses 255 colors by default. On the whole, Gimp defaults are sound, if you don't think they are, you overlooked something

Ah, actually that makes a lot of sense!
So i guess from now on, if I want the maximal file-size efficiency in my indexing then i should choose 3, 7, 15, 31, 63, 127, or 255 colors if my image contains transparency(basically any gif), and 2, 4, 8, 16, 32, 64, 128, or 256 if there is no transparency(and png)...?

Thanks, that really opened my eyes!

...looks like gimpchat has lost my two sample images. i wish i knew the proper way to upload...?

let me reattach here below:

128 colors(with transparency)


256 colors(black background)


i also attempted to fix the problem using GIMP_2.10(and before I had the issue properly explained to me), and got this bizarre result:

What makes you think that at 128 colors everything will be coded on 7 bits and that your image will be 12.5% smaller? AFAIK the only thing that happens when you have fewer colors is that you have a bit more chances to have contiguous pixels of the same color and so they can be RLE-encoded. But with RLE-encoding, an image which is all white with 255 color pixels is smaller than an image with random pixels with any of 256 colors.

If you are file-size conscious for your animations, you should investigate using the WebP format. Supported by all major browsers, no colormap restrictions, supports partial opacity...

Interesting, so it says .webp is both lossy and lossless... ...that might get confusing...
https://en.wikipedia.org/wiki/WebP

I'm curious about the implications to pixel-art, and confusions like this threads:
https://pixelation.org/index.php?topic=48665.0 ...smaller files seems cool though!

and about indexing, you're not suggesting fewer bits doesn't play a role in the final size of the file?!
...but thanks for the info; i wasn't aware that .gif used RLE. What about .png?
https://en.wikipedia.org/wiki/Run-length_encoding

thanks!

ps: what is up with links on this site?(fixed now!)

.

Yes, WebP supports both types of compression.

The size of the color map or the color index of the pixels is not reduced because values fit in 7 or 6 or 4 bits. It's all stored as a full byte. Of course, the result is then subject to LZW compression, and if there are fewer values they will compress better (but you won't see a sudden drop when going from 129 to 128, for instance).

You may need have to have enough posts under your belt to be able to post links around here.

There is a restriction on new users not being able to add links. Once you have made 5 posts you should be automatically permitted to add links.

Kevin

looks like i passed the threashold can post links now!

Interesting! [url=https://en.wikipedia.org/wiki/Lempel–Ziv–Welch]LZW[/url], i really should read up on file formats some time...

...looking at png, it apparently uses a totally different compression method(DEFLATE) ...sounds pretty sophisticated...

...hey there is an APNG! why didn't i know about this already? why don't i see more of this around?

...I've found some conflicting info regarding advantages of apng vs webp:
http://littlesvr.ca/apng/gif_apng_webp.html
https://corydowdy.com/blog/apng-vs-webp-vs-gif
https://www.keycdn.com/support/png-to-webp
https://insanelab.com/blog/web-developm ... g-gif-png/

I also found an old thread from 2013:
viewtopic.php?f=22&t=6889

...idk which is preferable...?

I prefer the 'webm' format when publishing short animations.
This is what they look like online.

With webm the technology exits on the server carrying the animations. They are not 'stand alone' like gifs.

cool! so i guess there are a few options out there currently...