Brian Gregory wrote:
On 18/02/2020 17:58, Paul wrote:
Brian Gregory wrote:
On 18/02/2020 16:21, Paul wrote:
...
There are three levers.
1) DEFLATE compression. Lossless.
2) Pre-filter to (1) to improve compression performance.
Still lossless.
3) Palette reduction. Potentially lossy in the color domain.
If you start with a JPG with 100,000 false colors because
of math roundoff, then pass it through palette reduction,
the colors might get scrubbed down to 256 colors and
usage of the 8 bit palette. The difference between the
original set of colors and the new "256 approximate colors"
is a loss of some sort.
If you use pngcrush, it might be testing stuff like that
for you, and making a decision based on byte count.
Paul
Nobody's even mentioned anything called pngcrush.
The program we're discussing is called optipng and it clearly says in
the first paragraph of it's website that no information is lost.
https://i.postimg.cc/ZYXHvtkb/portio...anual-page.gif
Ask yourself why those options are there. What passes for
a manual, doesn't say what it's doing.
Then, we have this.
https://manpages.debian.org/stretch/...ipng.1.en.html
"BUGS
Lossless image reductions are not completely implemented.
(This does not affect the integrity of the output files.)
Here are the missing pieces:
- The color palette reductions are implemented only partially.
- The bit depth reductions below 8, for grayscale images, are not
implemented yet.
"
I set up a test case for it, and it didn't go for it.
The output was still identical (converted to PNM and diff.exe
them).
Maybe what it does is "count colors" and do trivial
palette reduction. (If it analyzes the whole image and only
sees 256 colors total, it could switch to a 256 color palette.)
If you use the -np option, then it would avoid doing even
the trivial reductions in the palette. Now, if the eventual
intention of the program is to do aggressive palette
reduction, then the purpose of having a -np option would
make more sense. Turning off trivial reduction is pretty
pointless, if the name of the program is "opti...".
If you do a non-trivial palette reduction, there could be
banding in the output image. It's hard to tell from that
"feature enhancement" description above, whether the program
would head in that direction some day or not.
If PNG only offered 24 bit color, then there would be
no question about the potential for loss in the color space.
But it does have other options, which means using the
full range of controls, you could "encourage a lossy transform"
by some program. In the case of this program, you might
have to descend into source, because of the nature of the
documentation.
Paul
Go to http://optipng.sourceforge.net/
follow link to http://optipng.sourceforge.net/pngtech/optipng.html (A
guide to PNG optimization)
Read it.
I already read it and I don't think it addresses what
can be done with the palette. If no one addresses the issue,
or documents it properly, who can say what the specific or
the average program is doing.
-np Do not apply palette reduction.
What *kind* of palette reduction, FFS ? There are two kinds.
If I was writing a utility, I could offer both.
*******
https://en.wikipedia.org/wiki/Color_quantization
"PNG images support 24-bit color, but can often be made much
smaller in filesize without much visual degradation by application
of color quantization, since PNG files use fewer bits per pixel
for palettized images."
A trivial such color quantization can be achieved by "counting colors"
and selecting a smaller palette if the color count will fit within
that palette size. It appears (by me running one test case), that
this might be what optipng is doing.
True quantization can improve on that (but, it's not lossless as such).
In the case of JPG damage to line art or cartoons, true quantization
can achieve the original palette, with a small (sum of squares) error
(likely not perceptible to humans). It's a special case, where an image has been
damaged by using JPG compression when another method would have worked
better.
Paul