Does the .png image format have a text metadata field?

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

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.

--
Brian Gregory (in England).

Brian Gregory wrote:

TIFF seems like a nightmare

Not wrong.

I managed to build Sam Leffler's (sp?) TIFF library under VMS, but it
was still "fun" getting it to read all types of files required

On 17/02/2020 21:23, Big Al wrote:
optipng doesn't change the image quality any?Â*Â* I've never used it, just
installed it on my system.Â* I ran a test and some images were cut in
half.Â* My eye doesn't see any quality diff.

Further to my first reply. "Cut in half" is rare and suggests that the
original program that created them didn't choose the compression
parameters at all well, or maybe chose them aiming for highest possible
execution speed, or tested only on a photo where the more intensive
compression often makes only a little difference.

--
Brian Gregory (in England).

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

Brian Gregory wrote:
On 17/02/2020 21:23, Big Al wrote:
optipng doesn't change the image quality any? I've never used it,
just installed it on my system. I ran a test and some images were cut
in half. My eye doesn't see any quality diff.

Further to my first reply. "Cut in half" is rare and suggests that the
original program that created them didn't choose the compression
parameters at all well, or maybe chose them aiming for highest possible
execution speed, or tested only on a photo where the more intensive
compression often makes only a little difference.

Cutting a file size in half, is a typical number for a
lossless compression method. There's really nothing out
of the ordinary about it.

And it's not really a surprise, when the same method is
not able to improve on that number.

Switching the compressor on (compression setting 0 versus 1),
gives you the 2:1 improvement. The values 2 through 9 take
a lot more time, and don't seem to measurably improve things.
The 70MB PNG file created with compression=0, became 35MB
when the compression was set to 1 instead (you can do that in
GIMP).

One thing I can't figure out, is why a compression setting of
0, takes so long to write the file. That's a puzzle.

Something like LZ77 might do a bit better than that, and the
same 0..9 control values might make a bit of difference.

Whereas JPG or MPG2 might achieve 100:1 lossy compression and
then you're impressed.

At a compression setting of 0, DEFLATE should be turned off
entirely. A compression setting of 1, turns on DEFLATE.
I don't really see what DEFLATE can do, when the control
is set at 2 through 9. If the DEFLATE method had a "better
dictionary" it planned to use, it would probably be using
it in every case, instead of waiting until the control is
set to 2 or 9.

Paul

On 18/02/2020 22:56, Paul wrote:
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

Sigh.

In section 2.1 look at "The possible image reductions a"

That lists everything that optipng does to the image including the
pallette and none of them represent a lossy conversion.

--
Brian Gregory (in England).

On 18/02/2020 23:08, Paul wrote:
Brian Gregory wrote:
On 17/02/2020 21:23, Big Al wrote:
optipng doesn't change the image quality any?Â*Â* I've never used it,
just installed it on my system.Â* I ran a test and some images were
cut in half.Â* My eye doesn't see any quality diff.

Further to my first reply. "Cut in half" is rare and suggests that the
original program that created them didn't choose the compression
parameters at all well, or maybe chose them aiming for highest
possible execution speed, or tested only on a photo where the more
intensive compression often makes only a little difference.

Cutting a file size in half, is a typical number for a
lossless compression method. There's really nothing out
of the ordinary about it.

And it's not really a surprise, when the same method is
not able to improve on that number.

Switching the compressor on (compression setting 0 versus 1),
gives you the 2:1 improvement. The values 2 through 9 take
a lot more time, and don't seem to measurably improve things.
The 70MB PNG file created with compression=0, became 35MB
when the compression was set to 1 instead (you can do that in
GIMP).

One thing I can't figure out, is why a compression setting of
0, takes so long to write the file. That's a puzzle.

Something like LZ77 might do a bit better than that, and the
same 0..9 control values might make a bit of difference.

Whereas JPG or MPG2 might achieve 100:1 lossy compression and
then you're impressed.

At a compression setting of 0, DEFLATE should be turned off
entirely. A compression setting of 1, turns on DEFLATE.
I don't really see what DEFLATE can do, when the control
is set at 2 through 9. If the DEFLATE method had a "better
dictionary" it planned to use, it would probably be using
it in every case, instead of waiting until the control is
set to 2 or 9.

Â*Â* Paul

Look for gods sake just TRY IT and stop endlessly speculating on what
you kind of feel is probably the case.

Get a selection of PNG files, some photos and some graphics and you'll
see how much of an improvement optipng can make. Usually not much, maybe
2% if you're lucky but when a PNG is going on a website why not do it?
If you see more than that it probably means the original PNG wasn't
compressed properly.

--
Brian Gregory (in England).

On 18/02/2020 23:33, Brian Gregory wrote:
Get a selection of PNG files, some photos and some graphics and you'll
see how much of an improvement optipng can make. Usually not much, maybe
2% if you're lucky but when a PNG is going on a website why not do it?
If you see more than that it probably means the original PNG wasn't
compressed properly.

Which, can we agree, is fairly unusual?


--
Brian Gregory (in England).

Brian Gregory wrote:
On 18/02/2020 23:33, Brian Gregory wrote:
Get a selection of PNG files, some photos and some graphics and you'll
see how much of an improvement optipng can make. Usually not much,
maybe 2% if you're lucky but when a PNG is going on a website why not
do it? If you see more than that it probably means the original PNG
wasn't compressed properly.

Which, can we agree, is fairly unusual?

On a day to day basic, I don't have much reason to
examine the topic. When I download images, I have enough disk space
I don't really care about potential savings. If something is
too big, I'd just throw it away.

It was only the one large graphic, where I was trying to find
some way to make the file manageable. And PNG, with the selection
of palettes it offered, was the solution. I might have used
netpbm or something, to get the degree of control needed.
I don't think I could set GIMP to a four color palette.
I must have used some other method. I'm not sure I could
open it in GIMP (not enough memory on this machine).

I don't think I tried any optimizer on that particular file,
as a brute force run on something that size would likely
never finish. But the palette change, did make it possible
to store the file without it being inconveniently big.

My problem now, is I can't find the file, to refresh my
memory on what it was for. It's gone off to some backup
drive I would guess.

And the only conventional images that large, would be
the ones I made with Microsoft ICE (panorama stitching software).
The .psb format worked for that, and that was good enough.

https://en.wikipedia.org/wiki/Adobe_Photoshop

"Photoshop files sometimes have the file extension .PSB,
which stands for "Photoshop Big" (also known as "large
document format"). A PSB file extends the PSD file format,
increasing the maximum height and width to 300,000 pixels
and the length limit to around 4 Exabytes."

The output quality of ICE wasn't that good, so as tests go it
was kind of a flop. I understand the fill capabilities
of the current Adobe Photoshop are pretty amazing. If a
panorama has holes in it or missing photos in the sequence,
some softwares will offer to fill the holes with a matching
pattern. ICE left a few spots with all-black.

Paul

On 2/18/20 2:10 PM, this is what Brian Gregory wrote:
On 17/02/2020 21:23, Big Al wrote:
optipng doesn't change the image quality any?Â*Â* I've never used it,
just installed it on my system.Â* I ran a test and some images were cut
in half.Â* My eye doesn't see any quality diff.

Further to my first reply. "Cut in half" is rare and suggests that the
original program that created them didn't choose the compression
parameters at all well, or maybe chose them aiming for highest possible
execution speed, or tested only on a photo where the more intensive
compression often makes only a little difference.

I have to agree with the poor choice on the first file creation. The
whole folder of 184 images that one must have been the best fix, but the
others were like .3% and some as high as 4%. Overall not worth the
work. I think Paul eluded to that too.

Thanks. Fun exercise though.
Al

On Mon, 17 Feb 2020 03:16:38 +0000, Brian Gregory
wrote:

On 15/02/2020 04:27, Mayayana wrote:
I use BMP or TIF for that. I could use PNG but it's
relatively bloated and it's also complex. Try saving
a big image as TIF and then PNG. PNG is a lot of
work to pack and unpack. It's slow. And as I wrote
to Java Jive, I did a test yesterday and found that
PNGs are much bigger than TIFs.

You might use BMP? Yet you go on to moan about large size of PNG?
I don't notice any difference in speed between PNG and TIFF.
You running an 8086?
Also I just tested with a photo and the PNG was actually a little
smaller than the TIFF suggesting that whenever you use to export to PNG
isn't correctly optimising the compression.

My Nikon D70s DSLR can store images as .nef raw format.

"Lucifer" wrote

| You might use BMP? Yet you go on to moan about large size of PNG?
| I don't notice any difference in speed between PNG and TIFF.
| You running an 8086?
| Also I just tested with a photo and the PNG was actually a little
| smaller than the TIFF suggesting that whenever you use to export to PNG
| isn't correctly optimising the compression.
|
| My Nikon D70s DSLR can store images as .nef raw format.

I like to shoot in RAW, too, and get RW2 files. Though I'm
not a great photographer, it seems worthwhile to use
RAW format. But I don't usually leave them that way. Once
I feel they're optimized for my purposes I save as TIF/BMP
and delete the RAW. At that point I don't really need it,
and I only have PSP/AftershotPro that can read it.

Mayayana wrote:
"Lucifer" wrote

| You might use BMP? Yet you go on to moan about large size of PNG?
| I don't notice any difference in speed between PNG and TIFF.
| You running an 8086?
| Also I just tested with a photo and the PNG was actually a little
| smaller than the TIFF suggesting that whenever you use to export to PNG
| isn't correctly optimising the compression.
|
| My Nikon D70s DSLR can store images as .nef raw format.

I like to shoot in RAW, too, and get RW2 files. Though I'm
not a great photographer, it seems worthwhile to use
RAW format. But I don't usually leave them that way. Once
I feel they're optimized for my purposes I save as TIF/BMP
and delete the RAW. At that point I don't really need it,
and I only have PSP/AftershotPro that can read it.

If by "can read it" you mean "can read RW2 format files": IrfanView's
'FORMATS' PlugIn can read RW2 (and many other RAW formats and other
formats). I sometimes use it to read files in Nikon's NEF (RAW) format.
(N.B. I had problems using IrfanView to *convert* NEF files (to JPEG) -
Date Taken proprtiy lost - but that was in 2012, so perhaps this has
been fixed.)

"Frank Slootweg" wrote

|
| If by "can read it" you mean "can read RW2 format files": IrfanView's
| 'FORMATS' PlugIn can read RW2 (and many other RAW formats and other
| formats).

That's interesting. You're right. I never thought
to try it. Still, though, I don't see any reason to
leave it in RAW format once I've coaxed what I
can out of the image. I'd rather have it in a more
common format. One never knows what will be able
to read it in the future.

Apropos of that, I just received a docx file of something
one of my brothers wrote. I immediately save it as TXT
and delete the docx. Docx is bloated, not widely supported,
and requires that I open the gigantic Libre Office just to
read the plain text. I don't see any point in such unnecessary
complexity.