"visually lossless"

anynymous said on 10/06/2017

Hi. I've read your article https://css-ig.net/png-tools-overview and I want to argue about the usage of the "visually lossless" term.

I am working in image/movie industry for years and we often use terms such as visually or virtually lossless and it appears to me that you are using it in a slightly incorrect and confusing way.

When we say virtually/visually lossless, we mean that DECODED image is not easily distinguishable from the original by simply looking at it with human eyes (without magnification etc.). Mathematically decompressed image IS different and with special methods these differences can be show. Multiple applications of the same compression may eventually degrade quality to the point when it is easily noticeable.

When DECODED image is always binary-same to the original, regardless of the number of consecutive recompressions, we call it "Mathematical Lossless". To me it looks like this is the term you want to use.

In both of the cases above, we assume that COMPRESSED image bitstream is different. If it wouldn't be, then the image would be simply unchanged so this information is pretty irrelevant.

Your usage of "visually lossless" implies that with the same settings you provide some or all of the output files will not match to the input when decoded, which is definitely not true for some of the tools you list, like optipng.

My suggestion is to use Mathematically Lossless term where applicable or simply dropping the "Visually" part and call it just "Lossless" if you want to keep things more casual.

cédric (dev) said on 10/09/2017

my definitions are more Web (alpha) related

  • lossless: all RGB values are identical, even if alpha == 0
  • visually lossless (or web lossless): RGB values with alpha == 0 could be modified
  • lossy: any RGB value where alpha is != 0 has been modified

however, it is an endless debate of interpretations and usage context. you could add many other factors here, like PNG chunks which affect display (gAMA, iCCP, etc.)

When we say virtually/visually lossless, we mean that DECODED image is not easily distinguishable from the original by simply looking at it with human eyes

you may be right (prof.jargon) but i consider this to be lossy. i do not even understand the meaning of the word lossless here since RGB data are altered in a lossy way and can not be restored

My suggestion is to use Mathematically Lossless term where applicable or simply dropping the "Visually" part and call it just "Lossless" if you want to keep things more casual.

no because there is a clear difference between my visually lossless and lossless definition

displayed data
original lossless visually lossless
76 954 bytes 74 330 bytes 71 341 bytes

when these images are decoded in a modern web browser, they should actually provide the exact same result: each pixel should be displayed just like the original

RGB data
original lossless visually lossless

however, there is a huge difference in RGB data: the visually lossless changes values in a way that could not be restored. according to the usage context, it changes the nature of this process

  • you could consider it as lossless for Web usage, because the image is decoded just like the original...
  • ...but if you use PNG as heightmap, this could become lossy: you irreversibly lose required/used data

fair comparison

it is about how you want to do comparisons and/or warn your user about what your tool is really doing. comparing lossless and visually lossless or lossy to (visually) lossless could be irrelevant and unfair

visually lossless / lossy - the unfair comparison
visually lossless lossy
71 341 bytes 63 699 bytes

if you ask me to compare these files with my eyes, i am just not able to see any differences without further inspection. however, i could use butteraugli or dssim to compare them: if the result is != 0, then i will probably consider this as lossy

same guy said on 11/16/2017

visually lossless comes from the fact that movies are huge and storing them as a true lossless is not really viable especially if you go above 8bit plus they often have a lot of noise and whatnot. So a high-bitrate fast compression is used.

I see what do you mean by showing these images with alpha that look the same in browser. Personally I come from a standpoint that there is only a one and only "standard" way to decode something. In case of PNG whatever can be hidden behind the alpha can be safely discarded. And if I would need to keep and access that data, I would make 2 files, one being rgb data without alpha and one separate mask file (or simply use a different format)

anyway, looks like this png lossless stuff on the web is more complicated than I though. Since I'm not a web designer, I'm gonna mind my own business. Back in the day I was just looking for new png encoding solutions to compress some image sequencess and found "visually lossless" to be confusing since at 1st i was sure I'm going to lose some useful data (which I don't).

megapro17 said on 08/28/2018

So, if I compress png without transparency, I can use web lossless and not lose not a single bit of information?

cédric (dev) said on 08/28/2018

no. -notrans is always lossy

Terpavor said on 09/28/2018

My thoughts before reading this thread were like... This tool is suspicious. They say it's visually lossless, that is, obviously, lossy. So why this tool is treated in benchmarks as lossless? And why only -s2...-s4? Looks like I should avoid pingo, its manual is too ambiguous.

I think you should avoid visually lossless term to not spook your users. Because it's generally accepted that visually lossless always is a subset of lossy. And avoid web lossless too, it's bad idea to invent new term for that.

You can use non-alpha lossless or something like that. And use this term with a link to the detailed description which explains that...

  • non-alpha lossless is completely lossless for pictures without alpha-channel (including -s9).
  • non-alpha lossless is lossless for areas where Alpha is non-zero.
  • non-alpha lossless mode changes only such RGB-values where Alpha is zero.
  • alpha-blended image will be lossless in web applications and many desktop applications
  • you shoudn't use non-alpha lossless mode if you afraid of alpha bleeding in your game (e.g. after bilinear filtration). Flood-filling will not help (don't know about premultiplied alpha). http://www.adriancourreges.com/blog/2017/05/09/beware-of-transparent-pixels/

Also documentation is really too ambiguous.

  • there's no -nojpgscale flag on that page https://css-ig.net/pingo
  • -s0...-s9 unwraps to?..
  • avoid sRGB conversion for PNG - when? In which case?
  • do not remove PNG chunks - is it necessary to remove some (?) chunks by default?
  • -lossless compresses image like -s0. Why? What will I get if I write -lossless -s9?
  • -pngfilter - dangeours name, because standard PNG filter are lossless

always do backup before using pingo. try on test files/folders especially made for this.

cédric (dev) said on 09/29/2018

why only -s2...-s4?
https://css-ig.net/png-tools-overview

if you reach pingo's description, you could see a link to those results. they are both outdated atm however

about the test

https://habr.com/post/326122/

i consider this benchmark to be invalid because it does not compare tools fairly. it makes sense to target the same scope...

PNG

pingo 0.98.25
100 PNG files — FX-4100 @ 3.6 Ghz - 8 Go RAM - Windows 7 64-bit
tool version binary options time in out
PngOptimizer 2.5.1 (f2701cb) 64-bit - 344.363s 180914 KB 172111,35 KB
ECT 25ef2cd 64-bit -1 -s 250.422s 180914 KB 171506,97 KB
pingo 0.98.25 64-bit -s0 91.047s 180914 KB 166956,22 KB

... then the conclusion could be different. pingo -s0 could be 3,78x time faster while saving 5155,13 KB more than PngOptimizer on this specific set. the JPG stuff is also wrong — it compares baseline/aggressive progressive encoding or image which are rotated (or not). my tests:

JPG

pingo 0.98.25
100 JPG files — FX-4100 @ 3.6 Ghz - 8 Go RAM - Windows 7 64-bit
tool version binary options time in out
ECT 25ef2cd 64-bit -1 -s 8.157s 119175,72 KB 114064,84 KB
Leanify 95ab165 64-bit -f 10.63s 119175,72 KB 114064,84 KB
pingo 0.98.25 64-bit -s0 -strip=3 -norotation 4.541s 119175,72 KB 114044,77 KB
pingo 0.98.25
100 JPG files — FX-4100 @ 3.6 Ghz - 8 Go RAM - Windows 7 64-bit
tool version binary options time in out
ECT 25ef2cd 64-bit -progressive -s 81.77s 119175,72 KB 107253,73 KB
Leanify 95ab165 64-bit - 89.72s 119175,72 KB 107254,28 KB
pingo 0.98.25 64-bit -s9 -strip=3 -norotation 34.49s 119175,72 KB 107252,50 KB

the rest

avoid web lossless too, it's bad idea to invent new term for that. (...) You can use non-alpha lossless

is non-alpha lossless official or you just ... invented it? :)

non-alpha lossless is completely lossless for pictures without alpha-channel (including -s9).

no. a paletted PNG does not have an alpha channel, as well as a grayscale+tRNS/truecolor+tRNS. pingo could change their alpha value(s) if == 0

alpha-blended image will be lossless in web applications and many desktop applications

i did not test any possible PNG case (as gray+alpha, gray/truecolor+tRNS) on any possible plateform, viewers, browsers etc. to do such affirmation. the only thing i could say is if well processed and if your decoder is 100% PNG specs compliant, the PNG *should* be rendered like expected

http://www.adriancourreges.com/blog/2017/05/09/beware-of-transparent-pixels/

that is not just this. if you actually use the PNG as heightmap, the process becomes lossy. you actually lose critical data

documentation is really too ambiguous

you already said that. perhaps you could write something more clear?

there's no -nojpgscale flag on that page https://css-ig.net/pingo

that is probably because this option does not exist anymore *

-s0...-s9 unwraps to?..
avoid sRGB conversion for PNG - when? In which case?

i did not get your questions here. what do you want to know exactly? *

do not remove PNG chunks - is it necessary to remove some (?) chunks by default?

like other optimizer, pingo removes some chunks by default — example, text related: tEXt, iTXt or zTXt which could weight several times bigger than the image data itself

-lossless compresses image like -s0. Why?

no *. -lossless is far more strict than -s0 alone; it should always keep RGB values, all chunks, the modification date, etc.

What will I get if I write -lossless -s9

-sN is considered as compression level if combined. so what you get in this case is the -lossless with more compression *

can you guarantee (...)

i do not guarantee anything — use it at your own risk

test it

if you want to know something about pingo, i suggest you do some test first: check data, do useful comparisons if necessary, etc. — you can probably answer your own questions from those results

Terpavor said on 09/30/2018

Sorry, I was a little emotional.

About terminology:

  • Google returns something about WebP and OpenEXR on non-alpha lossless query. But I was wrong, results are irrelevant to this case.
  • WebP doesn't have a special term for similar optimization. Invisible pixels are not preserved in lossless mode by default. They can be preserved by -exact flag.
  • ZopfliPNG uses --lossy_transparent flag for similar optimization (from help: remove colors behind alpha channel 0. No visual difference, removes hidden information)
  • I found the same terminology (lossy transparent) in some post here: https://encode.ru/threads/2523-compressing-animation-frames?p=48407&viewfull=1#post48407

IMHO, lossy transparent is better than non-alpha lossless or visually lossless. It has some unwanted connotations with lossy audio, but still looks appropriate in ZopfliPNG interface. https://en.wikipedia.org/wiki/Transparency_(data_compression)

that is probably because this option does not exist anymore

Oops. I mentioned it only because I found it in lossless (pure) example. https://css-ig.net/support/messages/pingo-examples#lossless

i did not get your questions here. what do you want to know exactly?

Never mind, I wanted to treat -s0...-s9 like combination of -pngstrip=N, something like -alpha and so on.

When I talked about ambiguity, I meant that it would be great to see detailed explanation of -s9 -lossless, of visually lossless meaning and other pitfalls somewhere else besides this thread. In documentation or help or verbose mode.

Thanks for the answer and clarifications.

cédric (dev) said on 10/01/2018

I mentioned it only because I found it in lossless (pure) example

a few months ago, i changed visually lossless to web lossless at least on the pingo and the benchmark pages. i did lot of changes in pingo since this, so examples are not really up to date — i am aware of this and started a rewrite, but it is low priority right now

https://encode.ru/threads/2523-compressing-animation-frames?p=48407&viewfull=1#post48407

as i said, it is an endless debate since it is based on subjective appreciation. some people call a process lossless just because they can not see any differences

comment this