[9fans] PNG and APE (cntd)

[9fans] PNG and APE (cntd)

[lucio]

I have uploaded fresh versions of npng.c and npng.1 to
/n/sources/contrib/lucio/pub/ for further testing.

The fix recommended by Russ is in there (α premultiplication) as well
as some (re-)implementation of options.  Other than -v (RGBV or CMAP8)
output, which looks pretty awful on small icons, it all seems to work
at least as well as png(1).  The -e option has me bothered, still.
8.npng is for those who seriously need the executable for the 386.

What I have not yet fixed is the use of sysfatal() for error
reporting, I need to change its name as well as its behaviour.  The
README file has not been updated either.

I have a slightly OT question: is it reasonable that PNG versions of
an image may be bigger than their GIF equivalent and (less
sursprisingly) much bigger than their JPEG versions?  I have not
tested this theory, but I have had this reported to me.

++L

Re: [9fans] PNG and APE (cntd)

[Lluís Batlle i Rossell]

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

lucio@proxima.alt.za wrote:
> I have a slightly OT question: is it reasonable that PNG versions of
> an image may be bigger than their GIF equivalent and (less
> sursprisingly) much bigger than their JPEG versions?  I have not
> tested this theory, but I have had this reported to me.
I don't know if I understood correctly your question, but although GIF
uses LZW instead of zlib (LZ77 iirc), it can stand only for 256
different colors - hence it my be smaller than PNG, as PNG allows 32bit
colors fine (being 8 for alpha). JPEG is dependant on lossy compression
(at least the actual implementations; I think a lossless was proposed,
but I've never seen it), then sure it can be much smaller than PNG.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3311 bytes --]

Re: [9fans] PNG and APE (cntd)

[lucio]

> I don't know if I understood correctly your question, but although GIF
> uses LZW instead of zlib (LZ77 iirc), it can stand only for 256
> different colors - hence it my be smaller than PNG, as PNG allows 32bit
> colors fine (being 8 for alpha).

The question was poorly phrased.  But yes, the comparison is between
PNG and GIF, specifically, because if baffled me when somebody showed
me figures that suggested the same image in PNG was larger than in
GIF.

I can only presume that PNG encoders increase the pixel depth, for
whatever reason.

And, BTW, PNG allows 16-bit per colour, a 48-bit depth per pixel.
Thanks to libpng, my "npng" can render these as 24-bit images.

++L

Re: [9fans] PNG and APE (cntd)

[Lluís Batlle i Rossell]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

lucio@proxima.alt.za wrote:
> I can only presume that PNG encoders increase the pixel depth, for
> whatever reason.
It offers also at least 8-bit for alpha. In GIF, simply one of the 256
colors is (absolutely) "transparent".
>
> And, BTW, PNG allows 16-bit per colour, a 48-bit depth per pixel.
> Thanks to libpng, my "npng" can render these as 24-bit images.
Oh, I didn't know. Nice feature, according to the usual 48-bit scanners.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3311 bytes --]

Re: [9fans] PNG and APE (cntd)

[Charles Forsyth]

> And, BTW, PNG allows 16-bit per colour, a 48-bit depth per pixel.
> Thanks to libpng, my "npng" can render these as 24-bit images.

``the human ear can't hear as high as that / still, it ought to please any passing bat''

Re: [9fans] PNG and APE (cntd)

[Jack Johnson]

On 4/27/06, Charles Forsyth <forsyth@terzarima.net> wrote:
> > And, BTW, PNG allows 16-bit per colour, a 48-bit depth per pixel.
> > Thanks to libpng, my "npng" can render these as 24-bit images.
>
> ``the human ear can't hear as high as that / still, it ought to please any passing bat''

I used to do some image fiddling a long time ago (image prep -> TGA
for television), and came across some info regarding medical x-ray
photographs being stored in a 12-bit grayscale format.  It's likely
that so fine a variation is either above or right on the edge of human
perception (given current working environments), but one
counterargument is that maybe it's not a human looking at the data.

Plus, I think 12 bits per color would be right around the limit of
film, something like a 4000:1 contrast ratio, so depending on the
scanner you'd likely be pushing the limits of the original medium
anyway, "lossless" transfer from analog to digital, whether or not
you're in a good position to make use of the data.

Archaeologists have the same problem all the time, looking at data
gathered by previous scientists and realizing the original gatherers
didn't save enough information for the current questions, so now they
tend to swing the opposite direction and record all the minutiae so
that years later someone can glean new information from an old dig.

One day, you may be a bat.

-Jack

Re: [9fans] PNG and APE (cntd)

[Steve Simon]

Re: 12 bit images

The problem is that Real Life™ has a contrast ratio well in excess of
12bits (72dBs) and if you add any exposure error (human error or fooled
software) then you may find quite a bit of your exposure is crushed
or burnt out.

This is why people use 14bit scanners running at 4096dpi and the like,
only to downsample to 640x480x8bit. You will always get better results if
you throw away resolution cleanly using well designed digital filter
than to use a low-res scanner directly.

I have seen several comparisons of SD vs HD TV down-converted, and the latter
wins every time.

my 2¢

-Steve

Re: [9fans] PNG and APE (cntd)

[Lluís Batlle i Rossell]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

Steve Simon wrote:
> This is why people use 14bit scanners running at 4096dpi and the like,
> only to downsample to 640x480x8bit. You will always get better results if
> you throw away resolution cleanly using well designed digital filter
> than to use a low-res scanner directly.
It's even more used in digital cameras, which most of them store to JPEG
directly. Therefore, the image file has a downsampled color space,
blocking effects, etc. The result is much better if you photo double the
resolution wanted, and then scale by software (even with a simple
scaling algorithm).

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3311 bytes --]

Re: [9fans] PNG and APE (cntd)

[Charles Forsyth]

sorry, my ill-advised quip meant that i thought it was just displaying the
family snaps in a window; i hadn't realised the software was processing medical data!

Re: [9fans] PNG and APE (cntd)

[lucio]

> sorry, my ill-advised quip meant that i thought it was just displaying the
> family snaps in a window; i hadn't realised the software was processing medical data!

Your quip brought a smile to _my_ lips; this is 9fans, after all.

++L

Re: [9fans] PNG and APE (cntd)

[jmk]

On Fri Apr 28 13:34:03 EDT 2006, lucio@proxima.alt.za wrote:
> > sorry, my ill-advised quip meant that i thought it was just displaying the
> > family snaps in a window; i hadn't realised the software was processing medical data!
>
> Your quip brought a smile to _my_ lips; this is 9fans, after all.
>
> ++L

your quip caused us to play the song in the unix room, to much
polite chuckling.

Re: [9fans] PNG and APE (cntd)

[Bruce Ellis]

Yes, 12 bit was added to postscript for x-rays.

brucee

On 4/28/06, Jack Johnson <knapjack@gmail.com> wrote:
> On 4/27/06, Charles Forsyth <forsyth@terzarima.net> wrote:
> > > And, BTW, PNG allows 16-bit per colour, a 48-bit depth per pixel.
> > > Thanks to libpng, my "npng" can render these as 24-bit images.
> >
> > ``the human ear can't hear as high as that / still, it ought to please any passing bat''
>
> I used to do some image fiddling a long time ago (image prep -> TGA
> for television), and came across some info regarding medical x-ray
> photographs being stored in a 12-bit grayscale format.  It's likely
> that so fine a variation is either above or right on the edge of human
> perception (given current working environments), but one
> counterargument is that maybe it's not a human looking at the data.
>
> Plus, I think 12 bits per color would be right around the limit of
> film, something like a 4000:1 contrast ratio, so depending on the
> scanner you'd likely be pushing the limits of the original medium
> anyway, "lossless" transfer from analog to digital, whether or not
> you're in a good position to make use of the data.
>
> Archaeologists have the same problem all the time, looking at data
> gathered by previous scientists and realizing the original gatherers
> didn't save enough information for the current questions, so now they
> tend to swing the opposite direction and record all the minutiae so
> that years later someone can glean new information from an old dig.
>
> One day, you may be a bat.
>
> -Jack
>

Re: [9fans] PNG and APE (cntd)

[lucio]

>> And, BTW, PNG allows 16-bit per colour, a 48-bit depth per pixel.
>> Thanks to libpng, my "npng" can render these as 24-bit images.
>
> ``the human ear can't hear as high as that / still, it ought to please any passing bat''

Just because there's no value in the higher resolution does not mean
that some fool isn't going to send you a picture you can't render.
And, honestly, it's very little effort to implement in the renderer.
I have no idea how much effort the developers of libpng had to expend
to get it right.

++L

Re: [9fans] PNG and APE (cntd)

[andrey mirtchovski]

> I have a slightly OT question: is it reasonable that PNG versions of
> an image may be bigger than their GIF equivalent and (less
> sursprisingly) much bigger than their JPEG versions?  I have not
> tested this theory, but I have had this reported to me.

png is libz compression, so even at its best you can still have an
image that compresses very badly. in fact i think i have an example,
let me find it... here:

http://pages.cpsc.ucalgary.ca/~mirtchov/screenshots/scr-porcini.png

basically that image (an album cover i used as as a desktop
background) even though small in acreage is large in size as a png
(1.1 megs) at compression of 9 and there's nothing we can do about it.

i don't care much about gif, but JPG achieves the small file size by
being lossy. for a test open up a JPG image in gimp or whatever editor
and save it again, but increase the level to 100% (instead of the
usual 85 or 90):

-rw-r--r--   1 andrey  andrey  1125261 Apr 27 00:28 IMG_3735-1.jpg
-rw-r--r--   1 andrey  andrey   446941 Apr 26 17:18 IMG_3735.JPG

(the images are otherwise unaltered)

Re: [9fans] PNG and APE (cntd)

[andrey mirtchovski]

forgot to add an example of a png that compresses much better, even
though it's bigger in size:

http://pages.cpsc.ucalgary.ca/~mirtchov/screenshots/plan9-normal.png

you can see that the difference is a lot of flat colour and much less
detail in the second image...

Re: [9fans] PNG and APE (cntd)

[Lluís Batlle]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

2006/4/27, andrey mirtchovski <mirtchovski@gmail.com>:
>
> i don't care much about gif, but JPG achieves the small file size by
> being lossy. for a test open up a JPG image in gimp or whatever editor
> and save it again, but increase the level to 100% (instead of the
> usual 85 or 90):
>
> -rw-r--r--   1 andrey  andrey  1125261 Apr 27 00:28 IMG_3735-1.jpg
> -rw-r--r--   1 andrey  andrey   446941 Apr 26 17:18 IMG_3735.JPG
>
> (the images are otherwise unaltered)


Keep on mind that jpeg with 100% quality is also lossy.

[-- Attachment #2: Type: text/html, Size: 860 bytes --]

Re: [9fans] PNG and APE (cntd)

[Harri Haataja]

On Thu, Apr 27, 2006 at 01:43:05PM +0200, Lluís Batlle wrote:
> 2006/4/27, andrey mirtchovski <mirtchovski@gmail.com>:
> > i don't care much about gif, but JPG achieves the small file size by
> > being lossy. for a test open up a JPG image in gimp or whatever
> > editor and save it again, but increase the level to 100% (instead of
> > the usual 85 or 90):
> >
> > -rw-r--r--   1 andrey  andrey  1125261 Apr 27 00:28 IMG_3735-1.jpg
> > -rw-r--r--   1 andrey  andrey   446941 Apr 26 17:18 IMG_3735.JPG
> >
> > (the images are otherwise unaltered)
> 
> Keep on mind that jpeg with 100% quality is also lossy.

There's also lossless but informed formats. Less so for images because
the often builtin major formats won't leave room for competition.

Fair bit of info on JPEG (and more) can be found at
http://www.faqs.org/faqs/jpeg-faq/

-- 
Energizer Bunny arrested - charged with battery.

Re: [9fans] PNG and APE (cntd)

[Russ Cox]

I remain unconvinced that all this effort on porting libpng
isn't wasted time.  If the current png reading code doesn't
work, I'd rather see that improved.  Andrey and I went through
it a year ago and made it pass all the tests in the PNG suite.

Russ

Re: [9fans] PNG and APE (cntd)

[lucio]

> I remain unconvinced that all this effort on porting libpng
> isn't wasted time.  If the current png reading code doesn't
> work, I'd rather see that improved.  Andrey and I went through
> it a year ago and made it pass all the tests in the PNG suite.

Oh, the primary target is GeoTiff and the secondary one is Graphviz.
I'm trying to produce a marked-up map of the area I live in and the
format of the maps and aerial photographs I have sourced from the
South African Surveyor General's office are in GeoTiff format.

Since I needed zlib and libjpeg and GD wants libpng, it has been
instructive to cut my teeth on npng.  I had a recollection that png(1)
did not do 24-bit images, but no proof, so I went ahead and started
from a different end.

I did discover that PNG isn't widely used, that the patent on LZW has
expired and that I have plenty left to learn about graphics (thanks to
all contributors, not least forsyth for the Microsoft papers - td's
contribution does not need mention on this forum).

As for Breadpng(), there's no ways I'm going to study the actual
on-disk representation of PNG or any of the other formats without very
sound reason.  Life is way too short :-)

That does not mean that I do not appreciate the value of doing it, or
that I am not grateful to those who took it upon themselves to do it,
of course.  Philosophically, I'm at odds with the Plan 9 approach, but
it's a pragmatic decision.

++L

Re: [9fans] PNG and APE (cntd)

[andrey mirtchovski]

the links web browser also required a port of libpng in a
subdirectory of its source tree. that's where the test images and
clients we used against p9's png came from. not sure how useful that
is, but i thought it worth mentioning.

Re: [9fans] PNG and APE (cntd)

[lucio]

> the links web browser also required a port of libpng in a
> subdirectory of its source tree. that's where the test images and
> clients we used against p9's png came from. not sure how useful that
> is, but i thought it worth mentioning.

Yes, I did remember.  Like GS, "links" also uses libjpeg, which has
value in itself.  GD, libTIFF and GeoTiff all also contribute to a
graphics workbench and all are actually quite open to being converted
to native Plan 9.

That is where I'm hoping to go, but I have some immediate objectives
that have slightly higher priority, as mentioned.  In the process,
I've had to make adjustments to the APE headers and to my view of the
Plan 9 directory hierarchy that I hope will benefit others as well.

In the medium term, I think there'd be advantages to extracting zlib,
libpng and libjpeg (at least) from GS, "links" and possibly other
places and accept them as first class citizens in the Plan 9 system.

++L

Re: [9fans] PNG and APE (cntd)

[Russ Cox]

I remain unconvinced that all this effort on porting libpng
isn't wasted time.  If the current png reading code doesn't
work, I'd rather see that improved.  Andrey and I went through
it a year ago and made it pass all the tests in the PNG suite.

Russ