For most screenshots, just save it as RGB.
One way to save space on these screenshots is to throw away the Alpha (transparency) layer. This will chop it from a 32-bit image down to 24-bit (~25% filesize savings).
Let's take this as one example:
cover.png
RGBA (261 KB) vs. RGB (205 KB) = ~78% of the size
The alpha was useless, so in this case the RGB image is EXACTLY the same.
- - -
Again, PNG is great because it's LOSSLESS.
When you then take something with millions/thousands of colors (RGB) though, and try to squash it into a <256 color box (Indexed), you'll be destroying lots of information.
(See more detail below.)
Quote:
Originally Posted by KevinH
If you feel that some specific images in the user guide had gone too far in that tradeoff, please let us know.
|
Nearly all of them, which is why I questioned it.
- insert-file-main.png
- tutorial-load-html.png
- tutorial-saved-epub.png
- [...]
See the difference between:
I super zoomed into a section, and you can see how:
In the original PNG, the icons/text are still perfectly crisp/clean.
In the Indexed PNG, it looks like they were saved as a JPG 50.
Quote:
Originally Posted by KevinH
As for colour depth, does setting max number of colours to anything other than a power of 2 make sense?
|
Depends on what type of images you're running it on.
Although setting "Maximum number of colors" at 256 won't stop GIMP from using less if possible.
Keep that setting on 256 or 128 and you'll probably be fine.
The fewer colors, the more repetition the image has = higher compression.
BUT, the fewer the colors, the more loss/distortion occurs.
Images That Already Have <=256 Colors
Indexing this type is a purely lossless conversion.
Take icons as an example.
Let's say your simple icon has 32 different colors in it:
You may have saved it as:
- RGBA (RGB + Alpha).
- 32-bit image (8-bit R, 8-bit G, 8-bit B, 8-bit Alpha)
- RGB
- 24-bit image (8-bit R, 8-bit G, 8-bit B)
- Indexed
- 8-bit image (<256 colors, so every pixel can be stored within a single byte)
RGBA (411 bytes) vs. RGB (360 bytes) vs. Indexed (271 bytes)
Choosing
Image > Mode > Indexed and setting "Maximum Number of colors".
GIMP will test the image, and see "Oh, this icon only had 34 colors", so it will create a palette that's exactly 34 colors large.
How do you see how many colors there are in your Indexed image?
You can see this in GIMP by going to:
Windows > Dockable Dialogs > Colormap
Images That Already Have >256 Colors
Indexing this type is LOSSY.
There are many different algorithms/dithering methods to try to do this (posterization)... some tools are good, most are awful.
The lower # of colors you allow, the more distortion occurs.
See the above zoomed in images.
And again, when you have simple images, like a menu item. Okay, great, you can REALLY chop down on the colors.
But when you have large, complicated, colorful screenshots like the entire Sigil window (icons and all)... trying to cut that down to 256 colors is going to be AWFUL.
Quote:
Originally Posted by KevinH
Ie. why 17 colours for your equations? I could see space savings from using 16 colours each represented as 4 bit wide fields with two fields packed into a single byte, but non-powers of 2 would seem to drop colour range with no associated space saving. Or am I missing something?
|
Biggest being the "4-bit PNG rendering bug", and bad support for 2-bit + 4-bit PNGs in some programs:
See the 2013 thread,
"Sony Reader for PC -- not rendering 16-color png".
(You can see the "zebra striping" that occurred in my+GrannyGrump's old pictures.)
17 colors still kept it as a (barely) 8-bit image, so you have no bugs AND you still get large filesize savings compared to a full 256 colors.
(Of course, that low # of colors only worked because it was simple shades of black/gray. Colorful/complicated pictures, you probably wouldn't want to go that low.

)
Quote:
Originally Posted by KevinH
BTW, I found a program on github called pngquant2 that seems to be using k-means cluster analysis on colours to determine true number of degrees of freedom represented by the colours actually used to determine the "best" set of palette colours to choose.
|
I'm really disappointed the guy who wrote pingo/ScriptPNG took down so many of his great image compression articles, but they can still be found via Archive.org:
https://web.archive.org/web/20161208...g-optimization
https://web.archive.org/web/20161003...ticles/truepng
https://web.archive.org/web/20161003...g-optimization
(There were many more, especially comparisons between all the different tools.)
I was able to recover this by visiting his website ~2016:
https://web.archive.org/web/20160601...ww.css-ig.net/
I think it was around 2018 that he "updated" his site to promote pingo, but he took down his entire article archive in the process.