gmane.comp.graphics.png.general

Re: [png-mng-implement] Error while building the pnglib from source for Windows

Glenn Randers-Pehrson — 2011-12-14T14:31:51

png-mng-implement is the appropriate one.


Try projects/vstudio or projects/visualc71

We will look into what's the matter with makefile.msc.  I don't know if
it has been tested recently.

Glenn

------------------------------------------------------------------------------
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits? 
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/

How to build the png source for Windows

ASUDE ASUDE — 2011-12-14T14:05:25

Hello,
I am trying to to build the latest source code (ver 1.5.6) of libpng from
here <http://www.libpng.org/pub/png/libpng.html>,(*.zip file)  I am trying
to build a libpng windows library(static or dll) on my Windows-7.

I copy the file scripts/makefile.msc to ../Makefile

then do make (CMD prompt).

I get errors. Below is the message printed on console on doing make:

cl -c -Oait -Gs -nologo -W3 -AL -Izlib .c >> pngerrs

And pngerrs(errorfile) contains error message as:

    .c
    c1 : fatal error C1083: Cannot open source file: '.c': No such file or
directory
    .c
    c1 : fatal error C1083: Cannot open source file: '.c': No such file or
directory




This is the Makefile:

    # makefile for libpng
    # Copyright (C) 1995 Guy Eric Schalnat, Group 42, Inc.
    # Copyright (C) 2006, 2009 Glenn Randers-Pehrson
    #
    # This code is released under the libpng license.
    # For conditions of distribution and use, see the disclaimer
    # and license in png.h
    #
    # Assumes that zlib.lib, zconf.h, and zlib.h have been copied to ..\zlib

    # -------- Microsoft C 5.1 and later, does not use assembler code
--------
    MODEL=L
    CFLAGS=-Oait -Gs -nologo -W3 -A$(MODEL) -Izlib
    #-Ox generates bad code with MSC 5.1
    CC=cl
    LD=link
    LDFLAGS=/e/st:0x1500/noe
    O=.obj

    #uncomment next to put error messages in a file
    ERRFILE= >> pngerrs

    # variables
    OBJS1 = png$(O) pngset$(O) pngget$(O) pngrutil$(O) pngtrans$(O)
pngwutil$(O)
    OBJS2 = pngmem$(O) pngpread$(O) pngread$(O) pngerror$(O) pngwrite$(O)
    OBJS3 = pngrtran$(O) pngwtran$(O) pngrio$(O) pngwio$(O)

    all: libpng.lib

    # see scripts/pnglibconf.mak for more options
    pnglibconf.h: scripts/pnglibconf.h.prebuilt
        cp scripts/pnglibconf.h.prebuilt $< at >

    png$(O): png.h pngconf.h pnglibconf.h pngpriv.h pngstruct.h pnginfo.h
pngdebug.h
              $(CC) -c $(CFLAGS) $*.c $(ERRFILE)

    pngset$(O): png.h pngconf.h pnglibconf.h pngpriv.h pngstruct.h
pnginfo.h pngdebug.h
        $(CC) -c $(CFLAGS) $*.c $(ERRFILE)

    pngget$(O): png.h pngconf.h pnglibconf.h pngpriv.h pngstruct.h
pnginfo.h pngdebug.h
        $(CC) -c $(CFLAGS) $*.c $(ERRFILE)

    pngread$(O): png.h pngconf.h pnglibconf.h pngpriv.h pngstruct.h
pnginfo.h pngdebug.h
        $(CC) -c $(CFLAGS) $*.c $(ERRFILE)

    pngpread$(O): png.h pngconf.h pnglibconf.h pngpriv.h pngstruct.h
pnginfo.h pngdebug.h
              $(CC) -c $(CFLAGS) $*.c $(ERRFILE)

    pngrtran$(O): png.h pngconf.h pnglibconf.h pngpriv.h pngstruct.h
pnginfo.h pngdebug.h
        $(CC) -c $(CFLAGS) $*.c $(ERRFILE)

    pngrutil$(O): png.h pngconf.h pnglibconf.h pngpriv.h pngstruct.h
pnginfo.h pngdebug.h
        $(CC) -c $(CFLAGS) $*.c $(ERRFILE)

    pngerror$(O): png.h pngconf.h pnglibconf.h pngpriv.h pngstruct.h
pnginfo.h pngdebug.h
        $(CC) -c $(CFLAGS) $*.c $(ERRFILE)

    pngmem$(O): png.h pngconf.h pnglibconf.h pngpriv.h pngstruct.h
pnginfo.h pngdebug.h
        $(CC) -c $(CFLAGS) $*.c $(ERRFILE)

    pngrio$(O): png.h pngconf.h pnglibconf.h pngpriv.h pngstruct.h
pnginfo.h pngdebug.h
        $(CC) -c $(CFLAGS) $*.c $(ERRFILE)

    pngwio$(O): png.h pngconf.h pnglibconf.h pngpriv.h pngstruct.h
pnginfo.h pngdebug.h
        $(CC) -c $(CFLAGS) $*.c $(ERRFILE)

    pngtrans$(O): png.h pngconf.h pnglibconf.h pngpriv.h pngstruct.h
pnginfo.h pngdebug.h
        $(CC) -c $(CFLAGS) $*.c $(ERRFILE)

    pngwrite$(O): png.h pngconf.h pnglibconf.h pngpriv.h pngstruct.h
pnginfo.h pngdebug.h
        $(CC) -c $(CFLAGS) $*.c $(ERRFILE)

    pngwtran$(O): png.h pngconf.h pnglibconf.h pngpriv.h pngstruct.h
pnginfo.h pngdebug.h
        $(CC) -c $(CFLAGS) $*.c $(ERRFILE)

    pngwutil$(O): png.h pngconf.h pnglibconf.h pngpriv.h pngstruct.h
pnginfo.h pngdebug.h
        $(CC) -c $(CFLAGS) $*.c $(ERRFILE)

    libpng.lib: $(OBJS1) $(OBJS2) $(OBJS3)
        del libpng.lib
        lib libpng $(OBJS1);
        lib libpng $(OBJS2);
        lib libpng $(OBJS3);

    pngtest$(O): png.h pngconf.h pnglibconf.h
        $(CC) -c $(CFLAGS) $*.c $(ERRFILE)

    pngtest.exe: pngtest.obj libpng.lib
        $(LD) $(LDFLAGS) pngtest.obj,,,libpng.lib ..\zlib\zlib.lib ;

    test: pngtest.exe
        pngtest

    # End of makefile for libpng


What is going wrong here?

I would like to know steps to build a libpng windows library? Any pointers
useful.
------------------------------------------------------------------------------
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits? 
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/_______________________________________________
png-mng-misc mailing list
png-mng-misc-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: Hang When Running the reading code.

2011-11-26T18:05:49

From: Steven Farris [mailto:sfarris.math-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org] 

The most likely explanation is that you are using a Cygwin DLL and you have a conflicting one on your system.  If that is the case ldd will tell you what is wrong.

Where did you obtain the build of libpng?  If you built it yourself, how did you build it (what options, if any, to configure) and how, where and what did you install?

When you build your app what do you link against, and what does ldd say your app requires?

John Bowler <jbowler-HInyCGIudOg< at >public.gmane.org>



------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d

Hang When Running the reading code.

Steven Farris — 2011-11-26T15:11:42

Folks of png-mng-misc,

I am experiencing a hang in my code at the png_create_struct when I run the
png read code.  I am using the form with three NULLs in the last three
parameters.  Any suggestions as to why?  I am running png 1.5.6.  I am
compiling successfully with g++ 3.4.4 in cygwin on top of Windows XP.
Also, when the code is present, but not called the application cannot be
killed?

Regards-

-Steve Farris
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d_______________________________________________
png-mng-misc mailing list
png-mng-misc-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

sRGB in PNG, v2 vs v4

Glenn Randers-Pehrson — 2011-09-29T23:54:48

I'm working on some applications that read various image formats
that might have embedded iCC sRGB color profiles, and convert
to and from png.

In theory, it's supposed to be OK to recognize the sRGB
profile and just write the sRGB profile in the PNG.

Now comes the rub: when we read a PNG with an sRGB
chunk and write to a format that doesn't have the equivalent
of the sRGB  chunk but does allow embedded color
profiles, which sRGB profile should the application write?
There are two version-2 profiles (with and without blackpoint
compensation) and one version-4 profile which is much
larger and claimed by ICC to produce better-looking results.

I am leaning toward providing an option for the user to
select version 2 or version 4.  What should be the default?
v4 has been out for 10 years, and ICC seems to recommend
using v4 (see http://www.color.org/v4spec.xalter).

What to do about the black-point compensated one?

Currently I am recognizing these profiles by their length
and by the presence of "sRGB" at a certain offset.
I think there are other sRGB profiles floating around
that won't be recognized this way.

Glenn

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1

Re: ISO PNG - 2003 or 2004?

Chris Lilley — 2011-09-29T20:24:01

GRP> The proposal, as I understand it, is to update the document
GRP> http://www.w3.org/2003/11/REC-PNG-20031110-errata

yes

GRP> change
GRP>     15948-2003
GRP> to
GRP>     15948-2004

exactly. (And also in the title as mentioned later in the thread).

Re: ISO PNG - 2003 or 2004?

Glenn Randers-Pehrson — 2011-09-29T19:20:31

Oh, right, the instance in the title needs to be changed as well.
I don't suggest removing it.

Glenn

On Thu, Sep 29, 2011 at 2:35 PM, John Bowler
<john.cunningham.bowler-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1

Re: ISO PNG - 2003 or 2004?

John Bowler — 2011-09-29T18:35:18

...


Ok, I misunderstood both Chris's original proposal (*just* to change that
instanced of the string "ISO/IEC 15948:2003") and your reference to the
erratum document (I didn't know it was there!)

I had not realized that the document was not an ISO document.  After all the
title is:

"Information technology — Computer graphics and image processing — Portable
Network Graphics (PNG): Functional specification. ISO/IEC 15948:2003 (E)"

Perhaps that instance of the string should simply be removed?  After all; it
has no meaning (there is no such thing) and it is misleading (it suggests
that it is an ISO document.)

John Bowler jbowler-HInyCGIudOg< at >public.gmane.org

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1_______________________________________________
png-mng-misc mailing list
png-mng-misc-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: ISO PNG - 2003 or 2004?

Glenn Randers-Pehrson — 2011-09-29T15:51:58

The proposal, as I understand it, is to update the document
http://www.w3.org/2003/11/REC-PNG-20031110-errata

by adding

================cut=======================

Typographical error in "Status of this document"

Category:
    2. Corrections that do not affect conformance
Date:
    2011 September 29
Reported by:
    Chris Lilley
Status:
    Proposed

Description

    The second paragraph of the "Status of this document" section says:

         This document ... is also International Standard,
         ISO/IEC 15948:2003....

    The ISO document was not published until 2004, and the number
    of the ISO document is ISO/IEC 15948:2004.

Change


In section "Status of this document", second paragraph

change

    15948-2003

to

    15948-2004

===============cut=========================

I don't object to that.

Glenn

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1

Re: ISO PNG - 2003 or 2004?

Chris Lilley — 2011-09-29T14:09:35

JB> If some company can post an electronic version of the real ISO spec that can be:
JB>  
JB> 1) Viewed without cost.
JB> 2) Mirrored
JB>  
JB> Then I think everyone would support updating the links to point
JB> to that or to mrror it as appropriate.

But that isn't the proposal.
 
JB> However the alternative of pointing PNG newbies to the ISO web
JB> site is counterproductive and I, for one, will continue too
JB> implement against the 20031110 draft because I don't have a copy
JB> of the final version and can't justify spending $180 for one.

The point is that the 20031110 is identical to the ISO one; we just need to correctly identify the ISO spec.

There is no 2003 ISO spec; they didn't get it published until 2004.

As you know, W3C produces freely available and royalty-free specifications. The aim of this erratum isn't to shunt peopleoff to ISO; its to let them know that the W3C one and the ISO one are identical (and thus, that they don't need to fork out umpteen Swiss Francs for the ISO version).

Re: ISO PNG - 2003 or 2004?

John Bowler — 2011-09-29T09:42:09

If some company can post an electronic version of the real ISO spec that can
be:

1) Viewed without cost.
2) Mirrored

Then I think everyone would support updating the links to point to that or
to mrror it as appropriate.

However the alternative of pointing PNG newbies to the ISO web site is
counterproductive and I, for one, will continue too implement against the
20031110 draft because I don't have a copy of the final version and can't
justify spending $180 for one.

Given this situation it seems much more productive overall to ignore the ISO
version and use the 20031110 version; if necessary someone who cares can do
a byte-by-byte comparison on two versions to verify the original observation
that they are identical.

John Bowler jbowler-HInyCGIudOg< at >public.gmane.org
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1_______________________________________________
png-mng-misc mailing list
png-mng-misc-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: ISO PNG - 2003 or 2004?

Chris Lilley — 2011-09-28T17:33:43

gcn> ----- Chris Lilley <chris-Pl0VvzL1eo4< at >public.gmane.org> wrote:


gcn> Not sure how we were supposed to know that in 2003.
gcn> It would be an "update" not an "erratum".

I agree we could not have known that at the time of publication.

gcn> I'm not paying 180,00
gcn> Swiss Francs  to find out if the only difference between
gcn> the real spec and these is the year.

Of course :) but following the link at ISO is free, and confirms that the actual publication date was 2004.

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=29581

Re: ISO PNG - 2003 or 2004?

2011-09-28T17:29:51

----- Chris Lilley <chris-Pl0VvzL1eo4< at >public.gmane.org> wrote:

Not sure how we were supposed to know that in 2003.
It would be an "update" not an "erratum".

In fact my printed copy of the "second edition" is dated
20 May 2003 and refers to ISO/IEC 15948:2002(E).

Similarly, any copies of the Second Edition that I can
find at W3C and elsewhere are 2003.  I'm not paying 180,00
Swiss Francs  to find out if the only difference between
the real spec and these is the year.

Glenn



------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1

ISO PNG - 2003 or 2004?

Chris Lilley — 2011-09-28T16:19:39

Hello,

This was just brought to my attention. Seems like a clear errata item;
the ISO page is clear that the correct date is 2004.

While this might seem like an 'obvious' correction that people could
do in their head,it can cause confusion as some people might think
these are two different versions of the spec.

Re: If you had to do it again... 16 years later.

Frédéric Kayser - CryoPNG — 2011-06-17T21:08:59

Le 16/06/2011 06:12, Greg Roelofs a écrit :

I roughly know about that (and all the mess around patents on things 
like arithmetic coding, which could be used in JPEG but nobody dares, 
and all those so called "range coders" are arithmetic coding in disguise).
But I would say patents are only the second major threat against real 
world innovation the first one being marriage.

Anyway Deflate itself could be tweaked in two ways:
- in the case of RGB images instead of compressing bytes it could handle 
RGB triplets (a full pixel) this would multiply by 3 (or 6) both the 
size of the search window and the maximum match length (this will not 
work if this damn filter byte is still in front of each row), emitting a 
literal would mean two others will follow (a reduced - without the 
length part - Huffman tree could be used for these two).
- it could be range extended by trading match length against range (not 
the way Deflate64 does), for instance once we have more than 32768 bytes 
of past history length from 227 to 258 (those from code 284) could 
signify a length from 3 to 34 but 32768 bytes a head of the distance 
actually encoded, again once we have more than 65536 bytes of past 
history lenght from 195 to 226 (those from code 283) could signify a 
length from 3 to 34 but 65536 but a head of the distance actually 
encoded... and so on down to code 281.

I will probably experiment these two ideas (at my pace it will take way 
more than weeks and I have just started two and a half other projects 
-PNG related-).

Safari natively supports JPEG2000 (on the Mac at least).
It's not a well-known fact but Apple embeds JPEG2000 images inside its 
.icns files (these are the applications icons, equivalent to .ico files 
in Windows) since Mac OS X inception.
http://en.wikipedia.org/wiki/Apple_Icon_Image


------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev

Re: If you had to do it again... 16 years later.

Greg Roelofs — 2011-06-16T04:12:06


But most images change much more rapidly anyway, and those that don't
tend to have plenty of "the same stuff" in the last 32 KB at any instant.
That's not a strong defense, but deflate isn't _that_ bad a choice for
lossless image compression.


It's also _much_ slower than zlib.  So it may make sense as an option (or
not; see below), but it's a bad choice as a default.

The other big question mark is its patent status.  Deflate was thoroughly
vetted--the zlib version was designed, in fact, around patents.  I'm certain
LZMA can't say the same thing, and the fact that no one seems to have made
a fuss about it yet doesn't necessarily mean anything.  (It took years for
the Forgent JPEG claims to surface, and I don't know that anybody seriously
believed their patent applied to anything but MPEG.  There may have been
other, more serious JPEG threats after that, but I no longer recall the
details.)  At any rate, the biggest PNG users--web browsers--are very big
targets these days.  Mozilla, Safari, Chrome, MSIE...they're all potential
cash cows, even for bogus litigants, so you tend to face an uphill battle
on such things unless you bring a lot more to the table than "30% better".


Nobody cared about 35 vs. 67 bytes even in the 9600 days. ;-)


You don't have to verify them; and again, the size impact is irrelevant for
the cases that matter.


Similar comments, though you could argue that 4 is too small for some
images.  Not that anyone would seriously want to put a gigapixel image
into PNG format (especially not a single IDAT), but that's a potentially
valid case.


You're still talking about the extreme low end--and don't forget that PLTE
_is_ compressed via truncation.  But I still see this as pretty much
irrelevant these days.  What's the actual use case where saving perhaps a
couple hundred bytes (at most) on colormapped images makes a big performance
difference somewhere?


Agreed.


Half agreed, but SVG is probably far better for logos.


Agreed.  Whatever the discussion points about global filter methods way
back when (I'm guessing it devolved to somebody's actual tests, though
probably very limited), this seems like a potentially nice win.


That also completely borks streamability.  This was a design choice; we
chose the latter.


Not buying it.  zlib/deflate is smack in the middle of the lossless spectrum:
moderately fast, moderately good compression (and low resource usage).  At
one end you've got FastLZ/QuickLZ/LZF/LZO/Snappy, and at the other LZMA and
some slightly better-compressing but mind-bogglingly slower algorithms.  You
can make a good case for adding compression methods--maybe Snappy and LZMA?--
but not for replacing deflate.  And there's always the patent question.


MNG is already "son of PNG"; some claim APNG is, too.  Some of the subsets
of MNG are easily implemented and still offer compelling improvements
(especially JNG == JPEG + alpha, and the RGB-differencing thing Glenn
mentioned), but they've gone nowhere.  There's a reason for that...


Yup, and how many of those have gone anywhere?  At all?  I don't believe
any browser supports JPEG 2000, and that's probably the best known case
with the biggest backers.  Maybe the reference implementations were just
utter crap, but it didn't come close to matching even regular JPEG in my
own experiments; where's the value?  Ditto wavelet methods, fractal
methods, etc., etc.


You're getting warm now.  As frustrating as it is to guys like you--and even
me still--the fact of the matter is that an image format's _biggest_ feature,
by far, is its stability.  People _hate_ incompatible images and the whole
upgrade cycle that goes with them; it takes a huge improvement in features
to overcome that.  LZMA's compression improvements over deflate are nice,
but they're not close to the same league as SVG's, and even that's not yet
widely used.  Heck, why are static GIFs still around when PNG is better--
frequently _much_ better--99% of the time?  And Flash blows animated GIFs
out of the water.  Yet people cling to them.


Various sets at various times.  It's a whole research project in itself to
come up with a good corpus.


If we rolled back to 1995 browser tech with 2011 compression tech, I'd
definitely push for at least consideration of LZMA, despite its less-certain
patent status.  MNG's intrapixel differencing, definitely; global filter
values, probably (despite the starting-from-scratch complexity hump that
every "little" option increases, which would still be the same problem in
this hypothetical world); palette + alpha, definitely; maybe some extra
filter methods (there was some interesting work published here recently;
sorry, I've forgotten who did it).

But multiple compression methods are a tough call even if there are robust,
open-source, third-party libraries doing the heavy lifting--which is not
completely clear for LZMA and definitely not the case for many of the
fast options.  If you require all of them to be supported always, you've
just added serious code weight to your apps; but if any are optional,
you may as well not have them at all, because there's almost guaranteed
to be a sufficient number of apps omitting them that nobody's willing to
use them.

Anyway, these are just my off-the-cuff thoughts; I'm sure I've missed
some things, but I won't have time to add to this even if I remember them,
so don't be surprised if you don't hear from me again for a while. :-)

Greg

------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev

Re: If you had to do it again... 16 years later.

Glenn Randers-Pehrson — 2011-06-13T18:02:28

2011/6/13 Frédéric Kayser - CryoPNG <cryopng-GANU6spQydw< at >public.gmane.org>


I would add pixels/inch as a pHYs unit and some kind
of English unit to the oFFs chunk.

Intrapixel differencing as in MNG

I believe we discussed the possibility of a global
filter-type byte (instead of per row) but rejected it
as not worth while, both in the original PNG discussions
and again in MNG discussions.

Glenn
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev_______________________________________________
png-mng-misc mailing list
png-mng-misc-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

If you had to do it again... 16 years later.

Frédéric Kayser - CryoPNG — 2011-06-13T12:57:06

Hello,
I have been playing around with PNGs for a while, looking for the best 
tools to reduce their size (the primary goal was to reduce the size of 
the themes on my Sony Ericsson K810 and Web Performance Optimization).

This led me to hack libpng to implement some kind of advanced dirty 
transparency cleaning:
http://www.libpng.org/pub/png/book/chapter09.html#INDEX-747
   "If a region is completely transparent, don't zero out the underlying 
color pixels in order to improve compression unless you've notified the 
user in some way."

Well, I did worse since cryopng actually zeroes out the output of the 
filters, that means completely transparent pixel can end up with non 
zero RGB components (the value of the reverse transformation of the 
filter indeed) those will be zeroed once filtered, thus the deflate 
engine receives more zeros, this can slightly improve compression of 
RGBA images.

Of course this is not enough to contend against pngslim like scripts, so 
I ended up writing some awful scripts that run pngrewrite, 
optipng/cryopng, pngout, pngwolf, pngout again, deflopt and defluff in a 
row (with dozens of parallel random pngout runs)... and after a few 
minutes (or hours!) on a quad-core CPU I can except to get a nearly 
optimal PNG file... and I have at least two new tools on the 
drawing-board that could further reduce the size of many PNG files.

Since I thought that I had finally mastered the subject, I have decided 
to give a course to a local group of webmasters on "How to optimize PNG 
files to reduce your bandwidth costs and speed-up page download on 3G 
handhelds/tablets".
So I've started to draw some educational material. I took a screen 
capture of an old game called Ceasar III (in this building game graphics 
were still near-isometric sprites) and I picked a nice 384 by 384 pixels 
sample region. I thought that it would be really cool the show the PNG 
decompression in slow-motion (highlighting the regions that were 
replicated) so I dumped the entire deflate decompression process to look 
at the literals and length/distance references to discover that the 
32768 bytes sliding window was in fact way to small...
If you do the maths in this case each line takes 1+384x3 bytes (1 byte 
filter type, 3 bytes RGB) that's 1153 bytes, this means that a match 
search will occur only within the 28.4 previous lines (out of 384 that's 
not a lot).
And I am talking about a 384 pixels wide image, when you know that 
nowadays monitors tend to display 1080p HDTV signals in the case of a 
dumb screen shot do not except to be able to search in more than the 6 
previous lines.

Deflate is now 18 years old, LZMA is only 10 and is gaining broader 
acceptance year after year, so I tried to compress my sample (once saved 
as raw RGB component) with xz, I tried various settings and here we are:
163860 bytes Caesar384.raw3e.xz
232692 bytes Caesar384.png
That's nearly 30% smaller and LZMA as not even been tuned for this type 
of data and could not benefit from filtering.
I know that there are some concerns about the fact that LZMA can gobble 
hundreds of MB for compression and decompression but it can easily be 
tamed to use much less (something like 10 or 12 MB for decompression).

When I was reading the PNG specs I have found a few annoying points:
- the smallest PNG file is 67 bytes this is bigger than the smallest GIF 
(35 bytes)
- CRCs are mandatory
- the size of the chunk is always written as 4 bytes
- the PLTE chunk is never compressed (not easy but could be done)
- a 256 colors indexed mode plus a whole alpha channel type would be 
welcome (the tRNS chunk is nice but limited)
- there is not 4096 colors mode (4 bits per component) this would be 
nice for previews or logos (and the same plus alpha)
- the fact that the filter type is repeated in front of each line (even 
if it's 0 from the first to the last row), this hinders compression
- the fact that a whole alpha channel only appears after RGB (or grey) 
components this hinders compression, it could be in a different chunk.
- deflate is outdated (its search window is too small compared to 
nowadays screen definitions)

So I've started to write an early draft of a new image file format (.nx) 
something that could be called "Son of PNG" or "PNG reborn" since it 
keeps the chunk principle of PNG (but reduced in size), all PNG chunks 
can be converted, but it also opens the door for new compression methods 
(LZMA, LZ4, range extended Deflate...) and new filters.

Thus I have a few questions :
- has this already be done? (I know that JPEG XR and JPEG2000 have 
lossless modes, and WebP will get an alpha channel)
- to you agree with the fact that since PNG is now pretty good 
established it is now impossible to introduce major enhancement (like a 
new compression engine) to it
- did you use a set of files to compare compression results (against 
.gif .tif .tga)?
- and what would you change to PNG if you had to do it again... 16 years 
later?

Best regards

Re: update of PngSuite

Frédéric Kayser - CryoPNG — 2011-06-10T13:26:50

Willem van Schaik wrote :

Hello,
it looks like your suite lacks images with more than one tRNS entry.

Here is a basic sample file: a blue square each quarter has a different 
transparency level.
http://frdx.free.fr/3trans.png

pngcheck -p 3trans.png

File: 3trans.png (116 bytes)
   PLTE chunk: 4 palette entries
     0:  (  0,  0,255) = (0x00,0x00,0xff)
     1:  (  0,  0,255) = (0x00,0x00,0xff)
     2:  (  0,  0,255) = (0x00,0x00,0xff)
     3:  (  0,  0,255) = (0x00,0x00,0xff)
   tRNS chunk: 3 transparency entries
     0:    0 = 0x00
     1:   85 = 0x55
     2:  170 = 0xaa
OK: 3trans.png (32x32, 2-bit palette+trns, non-interlaced, 54.7%).

Best regards

PS to Willem I did send this to you by email a week ago.

Reading palette images with transforms

2011-05-18T14:12:34

How do I display a palette based (indexed) PNG with gamma correction?

I'm trying to read a PNG indexed (color type 3) image to which I've added a gamma transform (i.e. I've specified gamma values to png_set_gamma that will cause the RGB values in the palette to change.)

In my code I use the sequential reader and I call png_read_update_info.  The documentation (libpng-manual.txt - this is 1.5) says that the update call will update the palette according to the transformations (as well as updating other chunks that, as previously reported on the implementation list, don't actually get updated.)

When I look at the palette (png_get_PLTE) it is unchanged (I think).  When I look at png_read_update_info it doesn't change the palette - instead this happens later in png_init_read_transformations.  However, even if I wait until after I've read all the rows of the image I still get the old palette back because I simply can't find a way to read the transformed one (in png_struct).

I've checked back to 1.0.53 and the libpng code all looks the same.  In particular there is only one call to png_set_PLTE in there and it happens when reading the PNG file.

I think I must be doing something stupid; after all it must be possible to display palette based PNGs with gamma correction (without expanding to 24 bits), but how?

John Bowler <jbowler-HInyCGIudOg< at >public.gmane.org>


------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay

update of PngSuite

Willem van Schaik — 2011-04-17T05:59:50

Triggered by a couple of requests for updates during the last year, I've 
finally picked up (after 12 years :-) an upgrade of PngSuite.

You can find the new version at http://www.schaik.com/pngsuite2011/ but 
I expect this soon to replace the existing version at 
http://www.schaik.com/pngsuite/ .

Here are the topics that got corrected / extended, please let me know if 
you observe any errors:

= spAL chunks got replaced with sPLT chunks
= a few filenames are changed, nobody noticed the bug for more than a 
decade :-), thanks Hadrien !!!
= I added some iTXt chunks with UTF-8 text to the "ancillary chucks" 
category; I used iGoogle for the translation and although I speak four 
languages, I don't know Finnish, Greek, Hindi or Japanese, so the texts 
can be a bit crappy :-), but this is all about the correct UTF-8 
encoding; still, looking forward to improvements from our linguistic 
audience (see attached)
= the transparency images showing a NeXT logo got replaced with 
politically correct (and more boring) images to accommodate some "GPL 
zealots" in the Debian community :-(
= the "corrupted PNGs" category got finally completed and extended with 
a number of additional tests, like color type, checksums, etc.

Some more test images incorporating sRGB and iCCP chunks are still on 
the drawing board.

Enjoy,
Willem


PS. I needed and wrote a small utility that can correct chunk CRC32 
checksums. Useful after manually correcting / hacking data in a PNG 
file. Check out http://www.schaik.com/png/pngcsum.html .