<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.graphics.png.general">
    <title>gmane.comp.graphics.png.general</title>
    <link>http://blog.gmane.org/gmane.comp.graphics.png.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2484"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2482"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2481"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2472"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2468"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2466"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2465"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2456"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2419"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2415"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2412"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2407"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2406"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2395"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2391"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2389"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2381"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2379"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2378"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.graphics.png.general/2372"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2484">
    <title>How to build the png source for Windows</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2484</link>
    <description>&lt;pre&gt;Hello,
I am trying to to build the latest source code (ver 1.5.6) of libpng from
here &amp;lt;http://www.libpng.org/pub/png/libpng.html&amp;gt;,(*.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 &amp;gt;&amp;gt; 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= &amp;gt;&amp;gt; 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 $&amp;lt; at &amp;gt;

    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&amp;lt; at &amp;gt;public.gmane.org
https://lists.sourceforge.net/lists/listinfo/png-mng-misc
&lt;/pre&gt;</description>
    <dc:creator>ASUDE ASUDE</dc:creator>
    <dc:date>2011-12-14T14:05:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2482">
    <title>Hang When Running the reading code.</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2482</link>
    <description>&lt;pre&gt;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&amp;lt; at &amp;gt;public.gmane.org
https://lists.sourceforge.net/lists/listinfo/png-mng-misc
&lt;/pre&gt;</description>
    <dc:creator>Steven Farris</dc:creator>
    <dc:date>2011-11-26T15:11:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2481">
    <title>sRGB in PNG, v2 vs v4</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2481</link>
    <description>&lt;pre&gt;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
&lt;/pre&gt;</description>
    <dc:creator>Glenn Randers-Pehrson</dc:creator>
    <dc:date>2011-09-29T23:54:48</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2472">
    <title>ISO PNG - 2003 or 2004?</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2472</link>
    <description>&lt;pre&gt;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.






&lt;/pre&gt;</description>
    <dc:creator>Chris Lilley</dc:creator>
    <dc:date>2011-09-28T16:19:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2468">
    <title>If you had to do it again... 16 years later.</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2468</link>
    <description>&lt;pre&gt;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
&lt;/pre&gt;</description>
    <dc:creator>Frédéric Kayser - CryoPNG</dc:creator>
    <dc:date>2011-06-13T12:57:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2466">
    <title>Reading palette images with transforms</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2466</link>
    <description>&lt;pre&gt;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 &amp;lt;jbowler-HInyCGIudOg&amp;lt; at &amp;gt;public.gmane.org&amp;gt;


------------------------------------------------------------------------------
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
&lt;/pre&gt;</description>
    <dc:creator>jbowler-HInyCGIudOg&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2011-05-18T14:12:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2465">
    <title>update of PngSuite</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2465</link>
    <description>&lt;pre&gt;
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 .



&lt;/pre&gt;</description>
    <dc:creator>Willem van Schaik</dc:creator>
    <dc:date>2011-04-17T05:59:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2456">
    <title>Error message: Image width is zero in IHDR</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2456</link>
    <description>&lt;pre&gt;Hello list,

Is there anything wrong with this PNG?
http://granjow.net/uploads/temp/s1.png

I get error messages:
when loading it with TV-L1[1]. No matter whether I export the PNG with GIMP 
or create it wit imagemagick.

thanks
Simon

[1] http://www.inf.ethz.ch/personal/chzach/opensource.html

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
&lt;/pre&gt;</description>
    <dc:creator>Simon A. Eugster</dc:creator>
    <dc:date>2011-03-29T08:04:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2419">
    <title>PNG is 16</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2419</link>
    <description>&lt;pre&gt;Happy birthday, etc.!

(When PNG was born, the idea of an image format having been around for 16
years, virtually unchanged, was close to inconceivable.  That's probably
still true today of things that are higher up the stack...)

Greg

------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
&lt;/pre&gt;</description>
    <dc:creator>Greg Roelofs</dc:creator>
    <dc:date>2011-03-07T17:34:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2415">
    <title>PNG chunk copy-safety when IHDR changes</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2415</link>
    <description>&lt;pre&gt;I've always considered all unknown chunks to be not-copy-safe,
in ImageMagick/GraphicsMagick, regardless of the chunk-type bits,
if IHDR changes (actually I always I consider them not-copy-safe,
because the PNG encoder has no way of knowing what IM/GM has
done to the image, or if it even started out being a PNG). The PNG
spec doesn't say that changing IHDR makes all unknown chunks
not-copy-safe, but consider what happens to the validity of oFFs
and pHYs if you crop or scale the image.

I got a complaint today about ImageMagick losing the grAb chunk
which I never heard of until know, when "mogrify -trim file.png" is used.
As described to me, it's the same as oFFs without the units field,
and does actually need to have its contents modified to account
for the trim operation.

Should the next edition of the PNG spec, if there ever is one,
say something about that, or should it be obvious without any
note in the spec?

Glenn

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
&lt;/pre&gt;</description>
    <dc:creator>Glenn Randers-Pehrson</dc:creator>
    <dc:date>2011-01-29T15:56:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2412">
    <title>longjmp version</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2412</link>
    <description>&lt;pre&gt;
I'm half-trying to get rrdtool working under the POSIX subsystem in
Windows Server, aka Interix. I am having some trouble with programs that
use libpng failing on longjump version. Is there a way to prevent this
problem from happening


[ administrator$ ] make test
make  pngtest
gcc -DHAVE_CONFIG_H -I.    -D_ALL_SOURCE -I/usr/local/include
-I/usr/local/ssl/include -I/usr/local/ssl/include  -D_ALL_SOURCE -MT
pngtest.o -MD -MP -MF .deps/pngtest.Tpo -c -o pngtest.o pngtest.c
mv -f .deps/pngtest.Tpo .deps/pngtest.Po
/bin/sh ./libtool --tag=CC    --mode=link gcc  -D_ALL_SOURCE
-L/usr/local/ssl/lib -L/usr/local/ssl/lib -lbind -lbind -o pngtest
pngtest.o libpng12.la -lz -lm
libtool: link: gcc -D_ALL_SOURCE -o .libs/pngtest pngtest.o
-L/usr/local/ssl/lib ./.libs/libpng12.so -lbind -lz -lm
-Wl,-rpath,/usr/local/lib
/opt/gcc.3.3/lib/gcc-lib/i586-pc-interix3/3.3/../../../../i586-pc-interix3/bin/ld:
./.libs/libpng12.so: _longjmp: invalid needed version 2
./.libs/libpng12.so: could not read symbols: Bad value
collect2: ld returned 1 exit status
*** Error code 1

Stop.
*** Error code 1

Stop.



&lt;/pre&gt;</description>
    <dc:creator>Eric A. Hall</dc:creator>
    <dc:date>2010-12-29T04:43:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2407">
    <title>PNG file issue</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2407</link>
    <description>&lt;pre&gt;Hi,

I am a Web Developer, and working in Linux environment. 

Recently I have created a PNG image using php5 with jpgraph tool. 
The PNG image file size is 45 KB.

After created the image I have placed/written the image into PDF file. 
For display the image in the PDF file I have used PostScript and HARU PDF functions with two different examples. 
The PDF file size is 6.5 MP.

The above examples If I used with JPEG image 
The JPG image file size is 250 KB.
The PDF file size is 500 KB.

Why the file size is too much, when using PNG file ?

Please let me know if you find any issues.

Regards,
P.karikalan.


      

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
&lt;/pre&gt;</description>
    <dc:creator>Kari kalan</dc:creator>
    <dc:date>2010-12-08T08:20:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2406">
    <title>libpng-1.4.5 is available</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2406</link>
    <description>&lt;pre&gt;libpng-1.4.5 is available from the usual sources:
ftp://ftp.simplesystems.org/pub/png/src
and from
http://libpng.sf.net

Changes since the last public release (1.4.4):

  Fixed possible configure.ac bug introduced in version 1.4.4.
  Wrapped long lines in CMakeLists.txt and introduced ${libpng_public_hdrs}
  Check for out-of-range text compression mode in png_set_text().
  Removed some extraneous parentheses that appeared in pngrutil.c of
    libpng-1.4.3
  Revised png_get_uint_32, png_get_int_32, png_get_uint_16 (Cosmin)
  Moved reading of file signature into png_read_sig (Cosmin)
  Fixed atomicity of chunk header serialization (Cosmin)
  Added test for io_state in pngtest.c (Cosmin)
  Added "#!/bin/sh" at the top of contrib/pngminim/*/gather.sh scripts.
  Changes to remove gcc warnings (John Bowler)
    Certain optional gcc warning flags resulted in warnings in libpng code.
    With these changes only -Wconversion and -Wcast-qual cannot be turned on.
    Changes are trivial rearrangements of code.  -Wconversion is not possible
    for pngrutil.c (because of the widespread use of += et al on variables
    smaller than (int) or (unsigned int)) and -Wcast-qual is not possible
    with pngwio.c and pngwutil.c because the 'write' callback and zlib
    compression both fail to declare their input buffers with 'const'.
  Added comment about the potential API incompatibility of the
    png_get_uint_16() macro with libpng-1.4.0 through 1.4.4.
  Removed PNG_NO_WRITE_GAMMA from pngminim/encoder/pngusr.h

Glenn

------------------------------------------------------------------------------
This SF Dev2Dev email is sponsored by:

WikiLeaks The End of the Free Internet
http://p.sf.net/sfu/therealnews-com
&lt;/pre&gt;</description>
    <dc:creator>Glenn Randers-Pehrson</dc:creator>
    <dc:date>2010-12-09T13:59:43</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2395">
    <title>weppy (WebP)</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2395</link>
    <description>&lt;pre&gt;New image format:

http://code.google.com/speed/webp/

Glenn

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
&lt;/pre&gt;</description>
    <dc:creator>Glenn Randers-Pehrson</dc:creator>
    <dc:date>2010-10-01T14:31:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2391">
    <title>PNG12_0, libpng12.so.0 on Sol10</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2391</link>
    <description>&lt;pre&gt;------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev _______________________________________________
png-mng-misc mailing list
png-mng-misc-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f&amp;lt; at &amp;gt;public.gmane.org
https://lists.sourceforge.net/lists/listinfo/png-mng-misc
&lt;/pre&gt;</description>
    <dc:creator>Burke Sean</dc:creator>
    <dc:date>2010-08-09T06:19:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2389">
    <title>libpng-1.4.2 is available</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2389</link>
    <description>&lt;pre&gt;libpng-1.4.2 is available from
ftp://ftp.simplesystems.org/pub/png/src
and from
http://libpng.sf.net/index.html

This is a minor cleanup version.  A new "vstudio" project
is supplied, to replace the "visualc6" and "visualc71"
projects, which will be removed from libpng-1.5.0.

The "png_check_sig()" macro is restored, as an
aid to migration from version 1.2.X.

The png_set_dither() function is restored, but renamed
"png_set_quantize()" to reflect more accurately what it
actually does.

For the remainder of 2010, version 1.2.43 will receive only
security updates.  Version 1.0.53 will not receive any
updates from now on.

Glenn

------------------------------------------------------------------------------
&lt;/pre&gt;</description>
    <dc:creator>Glenn Randers-Pehrson</dc:creator>
    <dc:date>2010-05-06T11:14:51</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2381">
    <title>handling of too-fast requested framing rates inanimations</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2381</link>
    <description>&lt;pre&gt;Neither the APNG or MNG spec has much to say about how to
handle a situation where the requested framing delay is too
short because either the decoder can't decode the complete
frame in time or because the hardware has a maximum
framing interval that is less than the requested one.

There is a bug report about Firefox not handling requested
framing delays of 1, 2, ..., 10 ms properly.  They seem
slower than a requested 11ms framing delay.

I wondered how the reporter could tell exactly what
is happening if a typical 75Hz monitor was being used
to display the result.

Firefox/Mozilla resets the delay to 100ms if the decoder
isn't finished in time, so I suspect that for the particular
file it takes about 10 ms to decode each frame, so the
framing interval becomes 110ms which would be observably
slower.

I'm recommending that Firefox/Mozilla extend the
delay by 13ms instead of 100ms, which corresponds
to one refresh cycle on a 75Hz monitor.

Glenn

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
&lt;/pre&gt;</description>
    <dc:creator>Glenn Randers-Pehrson</dc:creator>
    <dc:date>2009-12-30T18:17:44</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2379">
    <title>Burn All GIFs Day</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2379</link>
    <description>&lt;pre&gt;Today is the 10th anniversary of Burn All GIFs Day.

Glenn

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
&lt;/pre&gt;</description>
    <dc:creator>Glenn Randers-Pehrson</dc:creator>
    <dc:date>2009-11-05T23:51:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2378">
    <title>FW: pnggccrd.c and pngvcrd.c</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2378</link>
    <description>&lt;pre&gt;These two files appear in 1.2.40beta92 but are zero length.

Shouldn't they just be removed?

John Bowler &amp;lt;jbowler-HInyCGIudOg&amp;lt; at &amp;gt;public.gmane.org&amp;gt;





------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
&lt;/pre&gt;</description>
    <dc:creator>John Bowler</dc:creator>
    <dc:date>2009-11-05T23:14:53</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2372">
    <title>MNG and Synchronisation</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2372</link>
    <description>&lt;pre&gt;I have tried to use animated GIFs to solve a specific
programming task in my user interface. However, I am not able to achieve what
at I want with GIFs. The problem is if I put two similar GIFs next to each other,
after some time, they are not any longer synchronised. I need them to be. So my 
question is, will animated MNG files behave better in this respect ?
I am working in Win32 environments.
Please reply directly to me also, since I am not receiving this list.
Martin


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
&lt;/pre&gt;</description>
    <dc:creator>Martin Plassen</dc:creator>
    <dc:date>2009-10-13T06:57:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.graphics.png.general/2371">
    <title>Proposed "XML:com.adobe.xmp" PNG keyword</title>
    <link>http://comments.gmane.org/gmane.comp.graphics.png.general/2371</link>
    <description>&lt;pre&gt;

Looks good to me.  Let's get libpng-1.4.0 out before voting on
this, though, because the current libpng does not support
iTXt by default, and you cannot even enable it without
manually editing pngconf.h.

I'll publish libpng-1.4.0rc01 very shortly, maybe later on
this week.

Glenn

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
&lt;/pre&gt;</description>
    <dc:creator>Glenn Randers-Pehrson</dc:creator>
    <dc:date>2009-10-09T11:32:57</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.graphics.png.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.graphics.png.general</link>
  </textinput>
</rdf:RDF>

