A Windows XP help forum. PCbanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » PCbanter forum » Microsoft Windows XP » General XP issues or comments
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

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



 
 
Thread Tools Display Modes
  #91  
Old Yesterday, 06:58 PM posted to alt.windows7.general,alt.comp.os.windows-10,microsoft.public.windowsxp.general
Paul[_32_]
external usenet poster
 
Posts: 10,377
Default Image formats

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
Ads
  #92  
Old Yesterday, 07:39 PM posted to alt.windows7.general,alt.comp.os.windows-10,microsoft.public.windowsxp.general
Brian Gregory[_2_]
external usenet poster
 
Posts: 134
Default Image formats

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).
  #93  
Old Yesterday, 07:50 PM posted to alt.windows7.general,alt.comp.os.windows-10,microsoft.public.windowsxp.general
Andy Burns[_6_]
external usenet poster
 
Posts: 1,098
Default Image formats

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
  #94  
Old Yesterday, 08:10 PM posted to alt.windows7.general,alt.comp.os.windows-10,microsoft.public.windowsxp.general
Brian Gregory[_2_]
external usenet poster
 
Posts: 134
Default Image formats

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).
  #95  
Old Yesterday, 11:56 PM posted to alt.windows7.general,alt.comp.os.windows-10,microsoft.public.windowsxp.general
Paul[_32_]
external usenet poster
 
Posts: 10,377
Default Image formats

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
  #96  
Old Today, 12:08 AM posted to alt.windows7.general,alt.comp.os.windows-10,microsoft.public.windowsxp.general
Paul[_32_]
external usenet poster
 
Posts: 10,377
Default Image formats

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
  #97  
Old Today, 12:27 AM posted to alt.windows7.general,alt.comp.os.windows-10,microsoft.public.windowsxp.general
Brian Gregory[_2_]
external usenet poster
 
Posts: 134
Default Image formats

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).
  #98  
Old Today, 12:33 AM posted to alt.windows7.general,alt.comp.os.windows-10,microsoft.public.windowsxp.general
Brian Gregory[_2_]
external usenet poster
 
Posts: 134
Default Image formats

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).
  #99  
Old Today, 12:35 AM posted to alt.windows7.general,alt.comp.os.windows-10,microsoft.public.windowsxp.general
Brian Gregory[_2_]
external usenet poster
 
Posts: 134
Default Image formats

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).
  #100  
Old Today, 01:05 AM posted to alt.windows7.general,alt.comp.os.windows-10,microsoft.public.windowsxp.general
Paul[_32_]
external usenet poster
 
Posts: 10,377
Default Image formats

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
  #101  
Old Today, 05:13 AM posted to alt.windows7.general,alt.comp.os.windows-10,microsoft.public.windowsxp.general
Big Al[_5_]
external usenet poster
 
Posts: 1,431
Default Image formats

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
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off






All times are GMT +1. The time now is 10:37 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright ©2004-2020 PCbanter.
The comments are property of their posters.