Nabble - PNG MNG - General

libpng-1.2.41 is available

2009-12-03T03:58:56Z

libpng-1.2.41 (and 1.0.51 for legacy applications) is available at
ftp://ftp.simplesystems.org/pub/png/src
and at
http://libpng.sf.net/index.html

Please direct any replies to png-mng-implement@...

The changes since 1.2.40:

Moved redundant IHDR checking into new png_check_IHDR() in png.c
and report all errors found in the IHDR data.
Eliminated useless call to png_check_cHRM() from pngset.c
Expanded TAB characters in pngrtran.c
Added "xcode" project similar one already in libpng-1.4.0beta (Alam Arias).
Eliminated a shadowed declaration of "pp" in png_handle_sPLT().
Revised pngconf.h to make it easier to enable iTXt support. From libpng
version 1.2.9 through 1.2.40, defining PNG_iTXt_SUPPORTED did not work
as expected.
Converted all PNG_NO_* tests to PNG_*_SUPPORTED everywhere except pngconf.h
Changed many "#if defined(x)" to "#ifdef x" and fixed some indentation.
Added png_calloc() as a non-exported function.
Relocated png_do_chop() ahead of building gamma tables in pngrtran.c
This avoids building 16-bit gamma tables unnecessarily.
Removed a harmless extra png_set_invert_alpha() from pngwrite.c
Bugfixes and improvements to CMakeLists.txt (Philip Lowman)
Moved CMakeLists.txt from scripts into the main libpng directory.
Patched ltmain.sh for wince support.
Added PNG_CONVERT_tIME_SUPPORTED macro.
Make inclusion of time.h in pngconf.h depend on PNG_CONVERT_tIME_SUPPORTED
Updated scripts/pngw32.def and projects/wince/png32ce.def
Copied projects/wince/png32ce.def to the scripts directory.
Added scripts/makefile.cegcc
Added PNG_DEPSTRUCT, PNG_DEPRECATED, PNG_USE_RESULT, PNG_NORETURN, and
PNG_ALLOCATED macros to detect deprecated direct access to the
png_struct or info_struct members and other deprecated usage in
applications (John Bowler).
Removed three direct references to read_info_ptr members in pngtest.c
that were detected by the new PNG_DEPSTRUCT macro.
Marked deprecated function prototypes with PNG_DEPRECATED.
Marked memory allocation function prototypes with PNG_ALLOCATED.
Changed png_check_sig() to !png_sig_cmp() in contrib programs.
Corrected the png_get_IHDR() call in contrib/gregbook/readpng2.c
Marked nonexported functions with PNG_PRIVATE macro.
Revised scripts/*.def to reflect functions actually exported by libpng.
Updated the copyright year in scripts/pngw32.rc from 2004 to 2009.
Moved descriptions of makefiles and other scripts out of INSTALL into
scripts/README.txt
Rebuilt the configure scripts with autoconf-2.65
Disabled the new pedantic warnings about deprecated function use and
deprecated structure access unless the user defines PNG_PEDANTIC_WARNINGS.
Added "#define PNG_NO_PEDANTIC_WARNINGS" in the libpng source files.
Updated the list of files and made some cosmetic changes in README.

Glenn

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Burn All GIFs Day

2009-11-05T15:51:05Z

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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

FW: pnggccrd.c and pngvcrd.c

2009-11-05T15:14:53Z

These two files appear in 1.2.40beta92 but are zero length.

Shouldn't they just be removed?

John Bowler <jbowler@...>

------------------------------------------------------------------------------
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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: PNG and XMP already a way to consider storing metadata?

2009-11-02T11:24:46Z

glennrp@... schrieb:
> I understand why it has to be iTXt and not tEXt or zTXt, but why must it be
> uncompressed?

I'd say, the reason is just to avoid duplication of code and kind of
hidden backwards compatibility to tXMP.

The specification said back in 2001:

>An XML packet can be embedded in a PNG graphic file by adding a chunk
>of type “tXMP”.
>The data of the chunk should be a UTF-8 serialized XML packet.
>There should be no more than one ‘tXMP’ chunk present in each PNG file.
[http://xml.coverpages.org/XMP-Embedding.pdf (Sep 14 2001)]

So if you replace tXMP by iTXt and add XML:com.adobe.xmp (plus a few
bytes) in front, it does not really change anything major in your
parsing code.

That's more or less what's done in a later version of the spec:
[talking about UTF-8 and uncompressed iTXTt]
http://www.adobe.com/devnet/xmp/pdfs/xmp_specification.pdf (Sep 2005)

In SView5 I'm still supporting both ways for reading and the latter for
writing. Prepared it for compressed chunks, but decided against that for
now, due to the requirements of the spec.

------------------------------------------------------------------------------
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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: PNG and XMP already a way to consider storing metadata?

2009-11-02T11:10:16Z

Kopp, Thomas schrieb:
> In particular, I fully agree with Glenn that a hosted client like XMP cannot impose its own rules to the container, i.e. PNG. The other way around would be the only reasonable approach.

Agreed. EXIF, anyone? ;-)

------------------------------------------------------------------------------
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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: MNG and Synchronisation

2009-10-13T16:21:14Z

From: Martin Plassen [mailto:Martin.Plassen@...]
> The problem is if I put two similar GIFs next to each other,
>after some time, they are not any longer synchronised.

Because the GIF file format specifies a delay between frames, and,
typically, a free running animation engine handles errors in the delay by
ignoring them (rather than shortening the delay in the following frame to
catch up.)

There was an extension to IE that allowed the web page to explicitly specify
the frame to move to. This allowed a script in the page to take over
control of the animation. That would probably work for you if the animation
engine you have supports a 'go to frame' feature.

Even easier is to get the animation engine changed to use absolute time for
each frame - it's a small, easy, internal change and can easily be added as
an option.

That may still fail if you don't control the GIFs because the GIF
inter-frame delay is specified in centiseconds, so there is an average
round-off error of 0.25cs per frame. That can easily accumulate over
sufficient frames to give the 0.1s error between two animations that is
noticeable.

>So my question is, will animated MNG files behave better in this respect ?

I think so. Certainly these issues were part of the design of MNG, whereas
GIF was not even designed as an animation format. MNG files have more
accurate frame timing and the "FRAM" chunk specifies the handling of
inter-frame delay more precisely. The "external-signal" option was intended
to allow the container to force synchronization of a MNG. My interpretation
of the "deterministic" option is that it means that frames are replaced at a
time equal to the sum of the inter-frame delays of the frame and its
predecessors - i.e. the absolute time option.

If the same option is used on all the frames in the MNG then the net effect
is, as I interpret the options (Glenn or Willem are both much more expert):

1) deterministic: frames will be displayed at absolute times calculated by
summing the delays.
2) decoder-discretion: like GIF, except that the decoder is only permitted
to extend the delay by the timeout on the frame.
3) user-discretion: the GIF user input option, where frame advance only
happens when the user requests it.
4) external-signal: to synchronize a MNG to some external time source, or
event source, like the IE 'goto frame' extension to GIF handling but more
general.

Of course how well these options work depend on the decoder, and decoders
have no absolute requirement to even implement 'external-signal' because
implementation depends on decoder specific capabilities.

John Bowler <jbowler@...>

------------------------------------------------------------------------------
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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: MNG and Synchronisation

2009-10-13T13:45:58Z

But why don't you make the two animated GIFs or MNGs into one large
one with a transparent piece in the middle. Using the current CSS
absolute positioning techniques you could still have text or other
images being on top (or under) that transparent part.

Just my $0.02,
Willem

On 13-Oct-09, at 12:57 AM, Martin Plassen wrote:

> 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
> _______________________________________________
> png-mng-misc mailing list
> png-mng-misc@...
> https://lists.sourceforge.net/lists/listinfo/png-mng-misc

--

Willem van Schaik
willem@...

------------------------------------------------------------------------------
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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: MNG and Synchronisation

2009-10-13T13:41:34Z

On Tue, Oct 13, 2009 at 2:57 AM, Martin Plassen
<Martin.Plassen@...> wrote:
> 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
>

That would depend on the player software. If the GIFs
get out of sync, then MNGs probably will as well.

[I tried to answer you directly last time you asked me
but your mail (at users.sourceforge.net) bounced]

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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

MNG and Synchronisation

2009-10-12T23:57:20Z

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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Proposed "XML:com.adobe.xmp" PNG keyword

2009-10-09T04:32:57Z

On Thu, Oct 8, 2009 at 11:54 PM, Cosmin Truta <cosmin@...> wrote:

> Re: [png-mng-misc] PNG and XMP already a way to consider storing metadata?
> It is proposed to register the following new text keyword for
> use in PNG files:
>
> XML:com.adobe.xmp
> Extensible Metadata Platform (XMP) information, formatted
> as required by the XMP specification [XMP]. The use of iTXt,
> with Compression Flag set to 0, and both Language Tag and
> Translated Keyword set to the null string, are recommended
> for XMP compliance.
>
> References
> [XMP]
> Adobe Systems Inc., "XMP Specification", September 2005.
> http://www.adobe.com/devnet/xmp/

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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: PNG and XMP already a way to consider storing metadata?

2009-10-08T20:54:49Z

On Thu, Oct 8, 2009 at 2:44 PM, Glenn Randers-Pehrson <glennrp@...> wrote:

> On Thu, Oct 8, 2009 at 12:43 PM, Cosmin Truta <cosmin@...> wrote:
>
>> The chunk must be iTXt, and the keyword must be "XML:com.adobe.xmp".
>> iTXt (uncompressed) is required because XMP must be UTF8-encoded XML.
>> (XMP can also be UTF-16 and UTF-32, but PNG only allows UTF-8, which
>> is sufficient.) A typical PNG-only application should not normally
>> care if it's tEXt, zTXt or iTXt, compressed or uncompressed. However,
>> XMP is meant to be format-agnostic, so that you can easily transfer it
>> across image formats without doing any heavy lifting.
>
> I understand why it has to be iTXt and not tEXt or zTXt, but why must it be
> uncompressed? That seems to be an unreasonable and inconsistent
> requirement. Even if an application with knowledge of the particular
> keyword's non-compression rule writes the chunk properly, nothing prevents
> an editor that is unaware of the rule from rewriting it compressed, and
> we can't impose such a rule now.

I agree we cannot impose it, but we can still encourage applications
to use it uncompressed, for maximum interoperability.
If it makes sense to require iTXt instead of tEXt, to impose UTF-8
encoding over ISO8859-1 encoding (even when ISO8859 *can* do the job),
well, it also makes sense to impose uncompressed iTXt over compressed
iTXt, don't you think? On one hand you have the task of converting
plain ISO8859-1 to plain UTF-8, on the other hand you have the task of
converting a deflate-compressed UTF-8 to plain UTF-8. Either job
require intimate knowledge of the container format (PNG, in this
case), although this was not the intention of XMP. In my opinion,
ISO8859 to plain UTF-8 is much easier than deflated UTF-8 to plain
UTF-8.

Ergo, if you insist on allowing compressed iTXt, why not insist on
allowing tEXt, given that conversion to the desired plain UTF-8 is
even easier?
In contraposition: if it makes sense to stick to iTXt and not use
tEXt, it also makes sense to stick to uncompressed iTXt and not
compress it.

Say I write a simple XMP processor that handles as many formats as
possible: TIFF, JPEG, JPEG-2000, GIF, PNG, PDF, SVG, DNG, etc. The XMP
specification has given clear and detailed information on how to
*easily* embed XMP in each of these formats. They could have of course
recommended the implementors to use libtiff, jpeglib, jasper, libgif,
libpng, pdflib, etc. etc. etc. But that should not be the *required*
way to go for a simple XMP processor!
Perhaps the way to go is the freely-available XMP Toolkit; and does
anybody know, is that toolkit able to handle deflate-compressed UTF-8
text?

**

So it is entirely valid to embed "XML:com.adobe.xmp" in any text
chunk: tEXt, zTXt, uncompressed iTXt, or compressed iTXt. Our
registration process won't really change anything but acknowledge its
use. Now, the PNG specification allows them all, the XMP specification
allows only one of these. That one (the 3rd one) is PNG- and
XMP-compliant, the other three (1st, 2nd and 4th) are PNG-compliant
only.
What we can do is recommend (not require) using uncompressed iTXt for
compliance with the XMP specification.

It is proposed to register the following new text keyword for
use in PNG files:

XML:com.adobe.xmp
Extensible Metadata Platform (XMP) information, formatted
as required by the XMP specification [XMP]. The use of iTXt,
with Compression Flag set to 0, and both Language Tag and
Translated Keyword set to the null string, are recommended
for XMP compliance.

References
[XMP]
Adobe Systems Inc., "XMP Specification", September 2005.
http://www.adobe.com/devnet/xmp/

Best regards,
Cosmin

------------------------------------------------------------------------------
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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: PNG and XMP already a way to consider storing metadata?

2009-10-08T20:46:11Z

On Thu, Oct 8, 2009 at 10:30 PM, Glenn Randers-Pehrson
<glennrp@...> wrote:

> Also it seems I've got to fix the "pngcrush -n -v" because it doesn't
> display the iTXt contents. You only see them if you actually write
> a crushed output (which is what pngcrush is actually for)!

This is fixed in pngcrush-1.7.3. I'm not sure what would happen if
the XMP data contained non-Latin1 characters.

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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: PNG and XMP already a way to consider storing metadata?

2009-10-08T19:30:25Z

On Thu, Oct 8, 2009 at 6:41 PM, John Bowler <jbowler@...> wrote:

> TweakPNG can already do this on Windows - it can read/write arbitrary iTXt
> chunks. I've attached a PNG with what I believe to be otherwise valid, but
> compressed, XMP data (copied from the spec.)

Well, yeah. So can pngcrush, if it's built with libpng-1.4.0betaNN:

Begin interlace pass 0
Reading and writing end_info data
Handling 1 tEXt/zTXt chunks
0 XML:com.adobe.xmp (: ):
<x:xmpmeta xmlns:x='adobe:ns:meta/'>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about="" xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:format>application/pdf</dc:format>
</rdf:Description>
<rdf:Description rdf:about="" xmlns:xmp="http://ns.adobe.com/xap/1.0/">
<xmp:CreateDate>2002-08-15T17:10:04Z</xmp:CreateDate>
</rdf:Description>
</rdf:RDF>
</x:xmpmeta>
Destroying data structs

But that's way too much to ask (getting the commandline prompt
and typing (pngcrush -v Comp*.png comp_pc.png") from a user who
wants to hit "open with <something>" and see that listing, without
having to figure out any pngcrush or tweakpng options.

Also it seems I've got to fix the "pngcrush -n -v" because it doesn't
display the iTXt contents. You only see them if you actually write
a crushed output (which is what pngcrush is actually for)!

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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: PNG and XMP already a way to consider storing metadata?

2009-10-08T15:41:21Z

From: Glenn Randers-Pehrson [mailto:glennrp@...]
>I am willing to write a png_xms application that expands, extracts,
>pads, or inserts an xms:adobe iTXt chunk and allows the user to deal
>with multiple such chunks. I'm sure that others here could do it too in
>a day's work. I might need a little help GUI'ing it though, but I know
>that there exists one for pngcrush that could be trivially modified to
>work with png_xms.

TweakPNG can already do this on Windows - it can read/write arbitrary iTXt
chunks. I've attached a PNG with what I believe to be otherwise valid, but
compressed, XMP data (copied from the spec.)

Of course hand editing any XML, including XMP, without validating the result
against all the schemas is likely to result in errors, and the attached file
may well contain such errors!

John Bowler <jbowler@...>

------------------------------------------------------------------------------
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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

CompressesXMP.png (600 bytes) Download Attachment

Re: PNG and XMP already a way to consider storing metadata?

2009-10-08T13:40:36Z

On Thu, Oct 8, 2009 at 3:32 PM, John Bowler <jbowler@...> wrote:
> From: Glenn Randers-Pehrson [mailto:glennrp@...]
>>I understand why it has to be iTXt and not tEXt or zTXt, but why must it be
>>uncompressed?
>
> Doesn't 1.4.0 automagically decompress the chunk if it is compressed?
> Png_text_struct seems to always have uncompressed data - png_handle_iTXt
> always decompresses it if it is compressed. So far as I can see an app
> would have to do extra work to *disallow* compression, so it probably won't
> do it.

1.4.0 handles them fine. But what Adobe desires is to be able to dump
the file into a stupid text editor and read or manipulate the XMS data.

Glenn

> Similarly the XMP spec doesn't say what to do with multiple chunks, so the
> behavior will be application defined - almost certainly the apps will read
> just one (probably the first).

Right. But we could define the behaviour (note that the first XMP chunk
might not be the first one after editing with a PNG-compliant editor,
though).

>
>>That seems to be an unreasonable and inconsistent
>>requirement.
>
> Right, and it will get ignored. I bet it's there because it was easy for
> Adobe to add iTXt handling outside libpng (it can be done just by scanning
> the file) but they couldn't be bothered with adding the decompression
> support.
>
> Well, so what; as Glenn says:
>
>> We can't impose such a rule now.
>
> But we can register the keyword, without commenting on the unimplementable
> rules.

I was thinking more of commenting on the fact that the chunk might be
compressed, so a third-party application might be required to expand it
before it becomes readable with a text editor, and that a third-party
application would also be required, obviously, to repair the CRC.

I am willing to write a png_xms application that expands, extracts,
pads, or inserts an xms:adobe iTXt chunk and allows the user to deal
with multiple such chunks. I'm sure that others here could do it too in
a day's work. I might need a little help GUI'ing it though, but I know
that there exists one for pngcrush that could be trivially modified to
work with png_xms.

Bear in mind that a file with an uncompressed iTXt is still a PNG. A file
with a botched CRC is not.

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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: PNG and XMP already a way to consider storing metadata?

2009-10-08T13:10:36Z

For me it seems natural and consistent that any structure being embedded in a dedicated document type needs to respect the syntax and rules of the format it is embedded in. Otherwise the embedding document type would have to be adapted for each individual client it is embedding.

As a consequence, when embedding something into a document type, a kind of filter accompanying that something would have to be supplied for packing and unpacking it with respect to its container format.

In particular, I fully agree with Glenn that a hosted client like XMP cannot impose its own rules to the container, i.e. PNG. The other way around would be the only reasonable approach.

Regards,
Thomas.

-----Ursprüngliche Nachricht-----
Von: glennrp@... [mailto:glennrp@...]
Gesendet: Donnerstag, 8. Oktober 2009 21:35
An: PNG/MNG discussion list
Betreff: Re: [png-mng-misc] PNG and XMP already a way to consider storing metadata?

----- Original Message -----
From: "Glenn Randers-Pehrson" <glennrp@...>
To: "PNG/MNG discussion list" <png-mng-misc@...>

I understand why it has to be iTXt and not tEXt or zTXt, but why must it be
uncompressed? That seems to be an unreasonable and inconsistent
requirement. Even if an application with knowledge of the particular
keyword's non-compression rule writes the chunk properly, nothing prevents
an editor that is unaware of the rule from rewriting it compressed, and
we can't impose such a rule now.

OK, reading the Adobe spec I see why. They want to be able
to scan the file with a simple editor and extract or edit the
XMP stuff and write it back in place. There is even a recommendation
for a page or two of blank lines so an editor has a place to put
new stuff without changing the length. I suppose they don't worry
much about ruining the CRC. Who checks those anyhow?

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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

------------------------------------------------------------------------------
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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: PNG and XMP already a way to consider storing metadata?

2009-10-08T12:35:23Z

----- Original Message -----
From: "Glenn Randers-Pehrson" <glennrp@...>
To: "PNG/MNG discussion list" <png-mng-misc@...>

I understand why it has to be iTXt and not tEXt or zTXt, but why must it be
uncompressed? That seems to be an unreasonable and inconsistent
requirement. Even if an application with knowledge of the particular
keyword's non-compression rule writes the chunk properly, nothing prevents
an editor that is unaware of the rule from rewriting it compressed, and
we can't impose such a rule now.

OK, reading the Adobe spec I see why. They want to be able
to scan the file with a simple editor and extract or edit the
XMP stuff and write it back in place. There is even a recommendation
for a page or two of blank lines so an editor has a place to put
new stuff without changing the length. I suppose they don't worry
much about ruining the CRC. Who checks those anyhow?

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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: PNG and XMP already a way to consider storing metadata?

2009-10-08T12:32:06Z

From: Glenn Randers-Pehrson [mailto:glennrp@...]
>I understand why it has to be iTXt and not tEXt or zTXt, but why must it be
>uncompressed?

Doesn't 1.4.0 automagically decompress the chunk if it is compressed?
Png_text_struct seems to always have uncompressed data - png_handle_iTXt
always decompresses it if it is compressed. So far as I can see an app
would have to do extra work to *disallow* compression, so it probably won't
do it.

Similarly the XMP spec doesn't say what to do with multiple chunks, so the
behavior will be application defined - almost certainly the apps will read
just one (probably the first).

>That seems to be an unreasonable and inconsistent
>requirement.

Right, and it will get ignored. I bet it's there because it was easy for
Adobe to add iTXt handling outside libpng (it can be done just by scanning
the file) but they couldn't be bothered with adding the decompression
support.

Well, so what; as Glenn says:

> We can't impose such a rule now.

But we can register the keyword, without commenting on the unimplementable
rules.

John Bowler <jbowler@...>

------------------------------------------------------------------------------
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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: PNG and XMP already a way to consider storing metadata?

2009-10-08T11:44:30Z

On Thu, Oct 8, 2009 at 12:43 PM, Cosmin Truta <cosmin@...> wrote:

> The chunk must be iTXt, and the keyword must be "XML:com.adobe.xmp".
> iTXt (uncompressed) is required because XMP must be UTF8-encoded XML.
> (XMP can also be UTF-16 and UTF-32, but PNG only allows UTF-8, which
> is sufficient.) A typical PNG-only application should not normally
> care if it's tEXt, zTXt or iTXt, compressed or uncompressed. However,
> XMP is meant to be format-agnostic, so that you can easily transfer it
> across image formats without doing any heavy lifting.

I understand why it has to be iTXt and not tEXt or zTXt, but why must it be
uncompressed? That seems to be an unreasonable and inconsistent
requirement. Even if an application with knowledge of the particular
keyword's non-compression rule writes the chunk properly, nothing prevents
an editor that is unaware of the rule from rewriting it compressed, and
we can't impose such a rule now.

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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: PNG and XMP already a way to consider storing metadata?

2009-10-08T09:43:15Z

On Thu, Oct 8, 2009 at 10:57 AM, glennrp wrote:

>
> ----- Original Message -----
> From: "Cosmin Truta" <cosmin@...>
>
>
> I'm happy to tell you that there is a standard way to embed XMP inside
> PNG, mentioned in the XMP specification, and used by big vendors
> (Adobe) as well as open-source developers (exiftool and others). That
> is done via the iTXT chunk, with the text keyword "XML:com.adobe.xmp".
>
> www.adobe.com/devnet/xmp/pdfs/xmp_specification.pdf
>
> It appears to me that it would be appropriate for us
> to register that keyword. It was put into practice
> five years ago according to the XMP spec, and as
> Cosmin says, it's in use by multiple vendors and apps.

I fully agree. This could be the death blow to our simple but
unpopular text keyword system, and yet I still see it as a sound way
of moving forward.
Big players have identified areas of common interests concerning
metadata, and the difference between them and us is that they have
real experience, and they put that metadata to real use.

http://www.metadataworkinggroup.com/
http://www.metadataworkinggroup.com/pdf/mwg_guidance.pdf

Just to be clear on how XMP is embedded in PNG:

The chunk must be iTXt, and the keyword must be "XML:com.adobe.xmp".
iTXt (uncompressed) is required because XMP must be UTF8-encoded XML.
(XMP can also be UTF-16 and UTF-32, but PNG only allows UTF-8, which
is sufficient.) A typical PNG-only application should not normally
care if it's tEXt, zTXt or iTXt, compressed or uncompressed. However,
XMP is meant to be format-agnostic, so that you can easily transfer it
across image formats without doing any heavy lifting.

Best regards,
Cosmin

------------------------------------------------------------------------------
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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: PNG and XMP already a way to consider storing metadata?

2009-10-08T07:57:00Z

----- Original Message -----
From: "Cosmin Truta" <cosmin@...>

I'm happy to tell you that there is a standard way to embed XMP inside
PNG, mentioned in the XMP specification, and used by big vendors
(Adobe) as well as open-source developers (exiftool and others). That
is done via the iTXT chunk, with the text keyword "XML:com.adobe.xmp".

www.adobe.com/devnet/xmp/pdfs/xmp_specification.pdf

It appears to me that it would be appropriate for us
to register that keyword. It was put into practice
five years ago according to the XMP spec, and as
Cosmin says, it's in use by multiple vendors and apps.

This is also good motivation for us to get libpng-1.4.0
out the door, to provide iTXt support by default. I was
hoping to do that before we get to beta99....

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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: PNG and XMP already a way to consider storing metadata?

2009-10-08T07:27:32Z

On Thu, Oct 8, 2009 at 8:00 AM, Stefan Weisse <stefan.weisse@...> wrote:

> As weeks go by I slipped across XMP (Extensible Metadata Platform) [1],
> in short words a method of storing metadata in image files, used in
> imaging business, photography, ... more and more. Also when working with
> semi- or professional digital cameras, XMP is a way that might in future
> will be used more and more for storing metadata. The question I cannot
> answer myself whether it is already time to jump on that train.
>
> Do you have any insight whether there is already some specification on
> how to 'wed' (like wedding) XMP and PNG? Can XMP considered now as a
> method to store metadata or should one wait few years?

I have not looked at the XMP spec so I cannot answer in detail. However,
if an XMP datastream consists only of printable text, then it could be
contained in a PNG text chunk with an "XMP" keyword or similar.

e.g.,

zTXt XMP 0 data

If it contains binary data then a new chunk could be designed such as

xmPd keyword null_terminator compression_flag data

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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: PNG and XMP already a way to consider storing metadata?

2009-10-08T07:23:59Z

On Thu, Oct 8, 2009 at 8:00 AM, Stefan Weisse wrote:

> Do you have any insight whether there is already some specification on
> how to 'wed' (like wedding) XMP and PNG? Can XMP considered now as a
> method to store metadata or should one wait few years?

Stefan,

I'm happy to tell you that there is a standard way to embed XMP inside
PNG, mentioned in the XMP specification, and used by big vendors
(Adobe) as well as open-source developers (exiftool and others). That
is done via the iTXT chunk, with the text keyword "XML:com.adobe.xmp".

www.adobe.com/devnet/xmp/pdfs/xmp_specification.pdf

I personally have no hands-on experience with it, but I was planning
to enhance OptiPNG with XMP import (e.g. during TIFF-to-PNG
conversion). In my opinion, XMP is one of the most viable method to
store metadata, because it is gaining more and more popularity, and is
interchangeable across different image formats. The regular PNG text
chunks, on the other hand, are restricted to PNG/JNG/MNG only, and I
haven't seen any big-shot software programs taking full advantage of
their design, or using them in any sophisticated way. Heck, I didn't
even see much support for PNG text keywords as elementary as "Title",
"Author" or "Copyright".

> My vision would be to use XMP in a way that metadata (text, numbers,
> binary) can be properly seen in image editing applications while also
> being possible to nicely read and write the sets by my on-top-API,
> keeping valuable metadata glued together with image bits.

I warmly encourage you to pursue your vision :-)

If you need to see examples, it's easy: just take any image that you
know it has metadata, and export it to PNG from either Adobe Photoshop
or Adobe Lightroom. Other Adobe products, as well as other
XMP-supporting tools like ACDSee, should probably do this as well,
although I haven't tried them. Or if you want to stick with free
command line tools, I can recommend you my favorite: exiftool.

Best regards,
Cosmin

------------------------------------------------------------------------------
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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

PNG and XMP already a way to consider storing metadata?

2009-10-08T05:00:47Z

Hello,

I cite out of my older mail (April 28, 2009) that I sent to this list.

> Currently I am creating API for physicists and engineers on top of
> libpng to read/write more than just a plain PNG file. To put a long
> story short: It would be helpful for the physicist to easily be able to
> find out more on extra contents of the PNG file. Some already defined
> text chunks like "Description" I favour to use. Built-in operating
> system support to show such extra description (like list text chunks) is
> necessary in order for it to work.

Thanks to all who've answered. In principle I would have loved to write
back and discuss more, but usually I have much more things on my list to
do than I can do so I did not do it.

In principle I am ready with my on-top-API specification and reference
implementation for C++ (using libpng) and Java. Metadata is saved as
proprietary, but documented optional text chunks. This is not how I
would like to do it, but this was the only way that I could think of at
that time.

As weeks go by I slipped across XMP (Extensible Metadata Platform) [1],
in short words a method of storing metadata in image files, used in
imaging business, photography, ... more and more. Also when working with
semi- or professional digital cameras, XMP is a way that might in future
will be used more and more for storing metadata. The question I cannot
answer myself whether it is already time to jump on that train.

Do you have any insight whether there is already some specification on
how to 'wed' (like wedding) XMP and PNG? Can XMP considered now as a
method to store metadata or should one wait few years?

I'd be really interested in your opinion and also in experiences you
might have regarding XMP and image formats.

My vision would be to use XMP in a way that metadata (text, numbers,
binary) can be properly seen in image editing applications while also
being possible to nicely read and write the sets by my on-top-API,
keeping valuable metadata glued together with image bits.

regards,
Stefan

[1] http://en.wikipedia.org/wiki/Extensible_Metadata_Platform

------------------------------------------------------------------------------
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
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: relative ordering of iCCP, gAMA and cHRM chunks

2009-09-17T10:16:23Z

On Thu, Sep 17, 2009 at 12:09 PM, Manlio Perillo
<manlio.perillo@...> wrote:

>
>> Couldn't your application scan the file for chunks before processing
>> them? See pngcrush.c for an example of that.
>>
>
> No, I can not scan ahead the chunks, since it may result in big memory
> usage.

I meant simply scanning the file without storing anything, then "rewind"
and read it again, storing the iCCP data only if necessary.

Another possiblity is to store the iCCP chunk as an "unknown" chunk
and only decode it later if you decide you need it. That would of
course require memory to store the raw chunk though.

Glenn

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: relative ordering of iCCP, gAMA and cHRM chunks

2009-09-17T09:09:05Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Glenn Randers-Pehrson ha scritto:

> On Wed, Sep 16, 2009 at 7:28 AM, Manlio Perillo
> <manlio.perillo@...> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi.
>>
>> The PNG specification does not mandate any relative ordering for the
>> iCCP gAMA and cHRM chunks.
>>
>> It only says:
>> """A PNG encoder that writes the iCCP chunk is encouraged to also write
>> gAMA and cHRM chunks that approximate the ICC profile, to provide
>> compatibility with applications that do not use the iCCP chunk"""
>>
>>
>> I think that the spec should require that iCCP shall follow the gAMA and
>> cHRM, if these chunks are present.
>
> The PNG specification does not allow such a rule to be applied.
> The chunk copying mechanism depends on the existing rules.
>

Ok, thanks.

> Couldn't your application scan the file for chunks before processing
> them? See pngcrush.c for an example of that.
>

No, I can not scan ahead the chunks, since it may result in big memory
usage.

However, as I have written, an efficient solution is still possible with
PDF so its not really a problem, just a matter of curiosity.

Regards Manlio Perillo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqyXyEACgkQscQJ24LbaUTCgwCcCYLGUDTdjgIDhYW9JgXZVmb2
znkAnjapZUAFEKoRMaQy93e/TBuh7f5Y
=4rqM
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: relative ordering of iCCP, gAMA and cHRM chunks

2009-09-16T07:58:46Z

On Wed, Sep 16, 2009 at 7:28 AM, Manlio Perillo
<manlio.perillo@...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi.
>
> The PNG specification does not mandate any relative ordering for the
> iCCP gAMA and cHRM chunks.
>
> It only says:
> """A PNG encoder that writes the iCCP chunk is encouraged to also write
> gAMA and cHRM chunks that approximate the ICC profile, to provide
> compatibility with applications that do not use the iCCP chunk"""
>
>
> I think that the spec should require that iCCP shall follow the gAMA and
> cHRM, if these chunks are present.

The PNG specification does not allow such a rule to be applied.
The chunk copying mechanism depends on the existing rules.

Couldn't your application scan the file for chunks before processing
them? See pngcrush.c for an example of that.

Glenn

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

relative ordering of iCCP, gAMA and cHRM chunks

2009-09-16T04:28:47Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.

The PNG specification does not mandate any relative ordering for the
iCCP gAMA and cHRM chunks.

It only says:
"""A PNG encoder that writes the iCCP chunk is encouraged to also write
gAMA and cHRM chunks that approximate the ICC profile, to provide
compatibility with applications that do not use the iCCP chunk"""

I think that the spec should require that iCCP shall follow the gAMA and
cHRM, if these chunks are present.

Rationale:
I'm the author of a Python package that converts PNG and JPEG images to PDF:
http://hg.mperillo.ath.cx/pdfimg

In previous versions I read the entire iCCP chunk in memory, but now I'm
going to change this by reading the iCCP profile lazily, since it can be
big.

When creating the PDF color space object for ICC profile, PDF spec
requires an "alternate color" space to use, in case the PDF viewer does
not support ICC.

The problem, now, is that I need to know if there is a cHRM chunk to
properly set the alternate color space.

This is not a problem in current version, since all chunks data up to
the first IDAT are in memory.

NOTE: with current PNG spec I can still implement the code as I want,
since I can use a PDF object reference.

Thanks Manlio Perillo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqwy+8ACgkQscQJ24LbaURzAACcDBOfEE/+VBpzlcGuR0Y06sPt
SmcAn0am/sjcmw6AoueOpdjTp/koPJXg
=XfYD
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Come build with us! The BlackBerry® 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/devconf
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: FW: [png-mng-implement] zlib/libpng license name

2009-07-01T08:50:29Z

----- Original Message -----
From: "Cosmin Truta" <cosmin@...>

The confusion factor should be considered. I don't think the merits of
libpng and its developers have anything to suffer if we call zlib's
license "the zlib license" and we call libpng's license "the libpng
license".

There are a number of other authors who have applied the
OSI-approved license called "zlib/libpng license" to their
projects. I think if zlib/libpng license were to suddenly
disappear, that would cause confusion.

The zlib people are of course perfectly free to call
theirs the "zlib license" or the "zlib/libpng license".

We are not free to call ours the "zlib/libpng" license
because that's not what we use. So we have to call
ours something else, e.g., the "libpng license", or
we could continue to use an unnamed license. If
you look at the first message in this thread you
will find that I was confused by our using a license
with no name.

Glenn

------------------------------------------------------------------------------
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: FW: [png-mng-implement] zlib/libpng license name

2009-07-01T07:04:01Z

On Tue, Jun 30, 2009 at 5:49 PM, Glenn Randers-Pehrson wrote:

> I prefer "zlib/libpng license" over "zlib license". The original motivation
> was, I believe, that the zlib license and the libpng license were
> functionally equivalent in the opinion of OSI. They are different
> now, but that is because of the addition of the language
> mandated by UCITA.

I used to call it myself the zlib/libpng license, and I thought that
both zlib and libpng use it -- until I actually took the time to read
both license texts and realize they aren't the same.

The confusion factor should be considered. I don't think the merits of
libpng and its developers have anything to suffer if we call zlib's
license "the zlib license" and we call libpng's license "the libpng
license".

And I gave this example before: there is no such thing as a "BSD/MIT license".

Best regards,
Cosmin

------------------------------------------------------------------------------
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: FW: [png-mng-implement] zlib/libpng license name

2009-06-30T19:55:57Z

From: Glenn Randers-Pehrson [mailto:glennrp@...]
>From: George Cook [mailto:COOK@...]
>>At
>> this point I believe it would be incorrect to change the wiki page to
>> "zlib license", unless OSI also makes the change. The "zlib/libpng
>> license" link does, however, point to the wikipedia "zlib license" page.
>
>"zlib/libpng license" means the zlib license itself and the
>original libpng license which was functionally equivalent.

Right, I agree (with both points.) OSI has clearly endorsed something and
it is not, I believe, the libpng license with the UCITA clause. That thing
may as well be called by the name they currently give it - the "zlib/libpng
license".

>I guess actually it means the template for the zlib license
>that OSI publishes, not the actual zlib license with Jean-loup
>and Mark's names, nor the actual libpng license with other
>names.

That makes sense.

>"libpng license" means the license that libpng is presently
>using and could also mean a template for it

That also seems reasonable.

John Bowler <jbowler@...>

------------------------------------------------------------------------------
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: FW: [png-mng-implement] zlib/libpng license name

2009-06-30T14:49:38Z

On Tue, Jun 30, 2009 at 4:55 PM, George Cook<cook@...> wrote:

>>From: George Cook [mailto:COOK@...]
>>>The Wikipedia Open Source License page lists it as "zlib-libpng license".
>>>What should it list it as? "zlib/libpng license" or "Zlib license"?
>>>I will edit the Wikipedia page as needed.
>
>>In http://en.wikipedia.org/wiki/Open_Source_License the bullet point:
>
>>* [[zlib/libpng license]]
>
>>Should be changed to just say:
>
>>* [[zlib license]]
>
>>The status of the libpng license seems to be somewhat uncertain at this
>>point because of the UCITA clause - I've entered a discussion point on the
>>talk page.
>
>>John Bowler <jbowler@...>
>
> After posting that (on 6/25), I realized that the license list on that
> page is basically just a duplicate of
> "http://www.opensource.org/licenses/category". All the OSI web site
> pages have it as "zlib/libpng license", so I changed the wiki page from
> "zlib-libpng license" to "zlib/libpng license" several days ago. At
> this point I believe it would be incorrect to change the wiki page to
> "zlib license", unless OSI also makes the change. The "zlib/libpng
> license" link does, however, point to the wikipedia "zlib license" page.
>
>
> George Cook
> WVNET
>
> ------------------------------------------------------------------------------

I prefer "zlib/libpng license" over "zlib license". The original motivation
was, I believe, that the zlib license and the libpng license were
functionally equivalent in the opinion of OSI. They are different
now, but that is because of the addition of the language
mandated by UCITA.

"zlib/libpng license" means the zlib license itself and the
original libpng license which was functionally equivalent.

I guess actually it means the template for the zlib license
that OSI publishes, not the actual zlib license with Jean-loup
and Mark's names, nor the actual libpng license with other
names.

"libpng license" means the license that libpng is presently
using and could also mean a template for it, looking
something like this:

%<=============cut===============================
COPYRIGHT NOTICE, DISCLAIMER, and LICENSE:

If you modify <software> you may insert additional notices immediately
following this sentence.

COPYRIGHT:

<software> [version <x.y.z>] is Copyright (c) <date> <copyright holder>

For the purposes of this copyright and license, "[Contributing] Author[s]"
is defined as the following [set of] individual[s]:

<Name> [of <name of employer>]
[...]

DISCLAIMERS:

The [library|software] is supplied "AS IS". The [Contributing] Author[s]
[and their employers] disclaim[s] all warranties, expressed or implied,
including, without limitation, the warranties of merchantability and of
fitness for any purpose. The Contributing Author[s] [and their employers]
assume[s] no liability for direct, indirect, incidental, special, exemplary,
or consequential damages, which may result from the use of the <software>
even if advised of the possibility of such damage.

There is no warranty against interference with your enjoyment of the
[library|software] or against infringement. There is no warranty that our
efforts or the [library|software] will fulfill any of your particular purposes
or needs. This [library|software] is provided with all faults, and the entire
risk of satisfactory quality, performance, accuracy, and effort is with
the user.

LICENSE:

Permission is hereby granted to use, copy, modify, and distribute this
source code, or portions hereof, for any purpose, without fee, subject
to the following restrictions:

1. The origin of this source code must not be misrepresented.

2. Altered versions must be plainly marked as such and must not
be misrepresented as being the original source.

3. This Copyright notice, disclaimers, and license may not be removed
or altered from any source or altered source distribution[, except
by inserting additional notices where indicated above].

The [Contributing] Author[s] [and their employers] specifically permit[s],
without fee, and encourage[s] the use of this source code [as a component to
supporting the PNG file format] in commercial products. If you use this
source code in a product, acknowledgment is not required but would be
appreciated.
%<===================cut=====================

A template for the "original libpng license" would be the same except
for omitting the second paragraph of the disclaimers, and omitting the
sentence about inserting additional notices (without that sentence,
no one could distribute a modified version and comply with both
clauses 2 and 3, which are mutually exclusive. After much thought
back in 1998 I concluded that the provision was implied by clause 2,
and that "inserting" more clauses is not "altering" the license.).

Glenn

------------------------------------------------------------------------------
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: FW: [png-mng-implement] zlib/libpng license name

2009-06-30T13:55:28Z

>From: George Cook [mailto:COOK@...]
>>The Wikipedia Open Source License page lists it as "zlib-libpng license".
>>What should it list it as? "zlib/libpng license" or "Zlib license"?
>>I will edit the Wikipedia page as needed.

>In http://en.wikipedia.org/wiki/Open_Source_License the bullet point:

>* [[zlib/libpng license]]

>Should be changed to just say:

>* [[zlib license]]

>The status of the libpng license seems to be somewhat uncertain at this
>point because of the UCITA clause - I've entered a discussion point on the
>talk page.

>John Bowler <jbowler@...>

After posting that (on 6/25), I realized that the license list on that
page is basically just a duplicate of
"http://www.opensource.org/licenses/category". All the OSI web site
pages have it as "zlib/libpng license", so I changed the wiki page from
"zlib-libpng license" to "zlib/libpng license" several days ago. At
this point I believe it would be incorrect to change the wiki page to
"zlib license", unless OSI also makes the change. The "zlib/libpng
license" link does, however, point to the wikipedia "zlib license" page.

George Cook
WVNET

------------------------------------------------------------------------------
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

Re: Errata for PNG spec (tRNS chunk)

2009-06-30T11:04:34Z

> has enough process been completed on the W3C side for me
> to effectively say to Dick that W3C has approved this erratum
> through its processes and hence we now invite ISO/IEC to do
> likewise?

I've looked back through some old files. This error must have creapt in
very early on. Certainly the PNG 1.1 and 1.2 drafts I have use the RGB
order.

I believe the PNG-1.2 draft establishes our position, so I don't
think a formal vote is necessary. Our voting process takes a
minimum of 28 days. I recall that in the past we have used
a Call for Unanimous Consent or Call for Objection, which took
14 days. But in this instance I don't think even that is required.

Glenn

------------------------------------------------------------------------------
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

FW: [png-mng-implement] zlib/libpng license name

2009-06-30T09:29:29Z

From: George Cook [mailto:COOK@...]
>The Wikipedia Open Source License page lists it as "zlib-libpng license".
>What should it list it as? "zlib/libpng license" or "Zlib license"?
>I will edit the Wikipedia page as needed.

In http://en.wikipedia.org/wiki/Open_Source_License the bullet point:

* [[zlib/libpng license]]

Should be changed to just say:

* [[zlib license]]

The status of the libpng license seems to be somewhat uncertain at this
point because of the UCITA clause - I've entered a discussion point on the
talk page.

John Bowler <jbowler@...>

------------------------------------------------------------------------------
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc