From owner-png-list@dworkin.wustl.edu Mon Sep 2 06:52:58 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id GAA17572 for ; Mon, 2 Sep 1996 06:52:58 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id GAA24456 for png-list-outgoing; Mon, 2 Sep 1996 06:52:16 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id GAA24451 for ; Mon, 2 Sep 1996 06:52:12 -0500 Received: by grommit.inria.fr (8.7.5/8.6.12) id NAA15864 for png-list@dworkin.wustl.edu; Mon, 2 Sep 1996 13:51:50 +0200 (DST) Date: Mon, 2 Sep 1996 13:51:50 +0200 (DST) From: Chris Lilley Message-Id: <9609021351.ZM15862@grommit.inria.fr> In-Reply-To: Cave Newt "Re: PNG support via OBJECT vs. IMG" (Aug 30, 6:30pm) References: <199608302330.SAA21465@ellis.uchicago.edu> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: PNG support via OBJECT vs. IMG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Aug 30, 6:30pm, Cave Newt wrote: > Chris wrote: > > > Right. Note that the MIME type is extracted from the HTTP header, so > > it comes in before the image is even loaded. It is also available by > > doing a HEAD request instead of a GET. > > I included the first 32 bytes because someone said WIDTH and HEIGHT are > required for OBJECT. They ere optional, but recommended. They are required, I gather, for embed as implemented by Netscape. > Can't get that info from HEAD... No. Would it help if you could? -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 2 07:05:05 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id HAA17619 for ; Mon, 2 Sep 1996 07:05:04 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA24542 for png-list-outgoing; Mon, 2 Sep 1996 07:05:07 -0500 Received: from relay1.oleane.net (Relay1.OLEANE.NET [194.2.1.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA24537 for ; Mon, 2 Sep 1996 07:05:01 -0500 Received: from atlas.gemse.fr ([3.45.12.3]) by relay1.oleane.net (8.6.10/8.6.9) with SMTP id OAA15319 for ; Mon, 2 Sep 1996 14:04:32 +0200 Received: from bird.gemse.fr by atlas.gemse.fr (4.1/SMI-4.1) id AA27828; Mon, 2 Sep 96 13:38:32 +0200 Received: by bird.gemse.fr (5.0/SMI-SVR4) id AA13755; Mon, 2 Sep 1996 13:47:03 +0200 Date: Mon, 2 Sep 1996 13:47:03 +0200 Message-Id: <9609021147.AA13755@bird.gemse.fr> From: Jean-loup Gailly To: PNG List Subject: Re: Reentract libpng In-Reply-To: Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List John Bowler writes: > 0.88 libpng and zlib (0.95?) have static tables which are initialized at > run time, but no static data which is modified during compression or > decompression. I believe that the later zlib initialization is > write-once and so should be multi-thread safe (multiple threads can > initialize in parallel). zlib is not strictly write-once, but the initialization can be done by multiple threads in parallel, so it's thread safe. Lee Crocker writes: > I'm just curious, but why do programs that do CRCs still typically > have a pre-calculated table, when it has been faster to calculate > it at runtime rather than load it from disk on any machine made > since about 1982? Many embedded systems don't have any disk. And they often have severe limitations on RAM size, but more ROM space. The pre-calculated table can be put in ROM if necessary. This is why zlib supports both initialization methods (pre-calculated and at runtime). It's not just a question of speed. If your particular application doesn't have any limitation on the size of the writable data segment, just compile zlib with the appropriate flag to get dynamic initialization. Jean-loup ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 2 07:17:57 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id HAA17654 for ; Mon, 2 Sep 1996 07:17:56 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA24649 for png-list-outgoing; Mon, 2 Sep 1996 07:18:11 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA24644 for ; Mon, 2 Sep 1996 07:18:07 -0500 Received: by grommit.inria.fr (8.7.5/8.6.12) id OAA16019 for png-list@dworkin.wustl.edu; Mon, 2 Sep 1996 14:17:45 +0200 (DST) Date: Mon, 2 Sep 1996 14:17:45 +0200 (DST) From: Chris Lilley Message-Id: <9609021417.ZM16017@grommit.inria.fr> In-Reply-To: Jean-loup Gailly "Re: Reentract libpng" (Sep 2, 1:47pm) References: <9609021147.AA13755@bird.gemse.fr> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: Reentract libpng Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 2, 1:47pm, Jean-loup Gailly wrote: > Many embedded systems don't have any disk. And they often have severe > limitations on RAM size, but more ROM space. The pre-calculated table > can be put in ROM if necessary. This is why zlib supports both > initialization methods (pre-calculated and at runtime). It's not > just a question of speed. Right. I had a comment on PNG from some people who do PDAs and such. They said that the 32k buffer required for deflate made the format impractical on small machines. Does anyone have a feel for how PNG compares in memory- and cpu-scarce environments with GIF and JPEG JFIF? -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 2 07:43:01 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id HAA17773 for ; Mon, 2 Sep 1996 07:43:00 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA24848 for png-list-outgoing; Mon, 2 Sep 1996 07:43:06 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA24843 for ; Mon, 2 Sep 1996 07:43:01 -0500 Received: by grommit.inria.fr (8.7.5/8.6.12) id OAA16035 for png-list@dworkin.wustl.edu; Mon, 2 Sep 1996 14:42:34 +0200 (DST) Date: Mon, 2 Sep 1996 14:42:34 +0200 (DST) From: Chris Lilley Message-Id: <9609021442.ZM16033@grommit.inria.fr> In-Reply-To: Carl Morris "Re: IMG tag (was: Re: PNG plugin for Netscape/Mac (first-cut))" (Aug 23, 7:08pm) References: <199608240015.TAA11466@inet.htcnet.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: IMG tag (was: Re: PNG plugin for Netscape/Mac (first-cut)) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Aug 23, 7:08pm, Carl Morris wrote: > [someone wrote] > | But there are other places where an image can appear that are > | probably > | not usable with an object tag (e.g. the body background argument), I > | assume that this is supported by MSIE also, it is now also supported > | by Mosaic and oviously it is very popular. With content nogotiation, > | it should be possible to put PNG images in there, which would not > | work if we only have the object tag with PNG support. > > The background source is sort of obsolete... Sort of, but both Wilbur and Cougar DTDs have a background attribute for body. And style sheets allow setting background on not only body, but other elements. The problem is, if browsers totally rely on some plug-in architecture to implement support for a particular media type, there can be problems if that plug-in can only be used in particular ways( eg, restricted to Object or restricted to Embed) and not other ways (background images from stylesheets, for example). If the plug-in exports some API which allows display of that media type, things are better. There can also be integration problems if the plug-in does not affect the Accept headers sent, or if it does not use the browser's cache (leading to slow reloads), or if it is not re-entrant (so multiple images are fetched and decompressed serially), or if multiple copies are loaded into memory when there are multiple instances of that media on the page. So, browsers which only implement PNG support via a plug-in architecture can present the format at a disadvantage compared to natively-supported formats. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 2 09:55:51 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA18312 for ; Mon, 2 Sep 1996 09:55:49 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA26011 for png-list-outgoing; Mon, 2 Sep 1996 09:56:02 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA26006 for ; Mon, 2 Sep 1996 09:56:00 -0500 Date: Mon, 2 Sep 96 10:54:26 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: png-list@dworkin.wustl.edu Subject: Fourteenth MNG draft Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609021054.aa01736@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I have posted the Fourteenth MNG draft to swrinde and mailed the text version to mpng-list. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 2 18:53:24 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA21117 for ; Mon, 2 Sep 1996 18:53:24 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA01292 for png-list-outgoing; Mon, 2 Sep 1996 18:53:11 -0500 Received: from inet.htcnet.com (inet.htcnet.com [199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA01286 for ; Mon, 2 Sep 1996 18:53:08 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id TAA23685 for ; Mon, 2 Sep 1996 19:01:31 -0500 Message-Id: <199609030001.TAA23685@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: Re: Reentract libpng Date: Mon, 2 Sep 1996 18:52:42 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List | Right. I had a comment on PNG from some people who do PDAs and such. They said | that the 32k buffer required for deflate made the format impractical on small | machines. | | Does anyone have a feel for how PNG compares in memory- and cpu-scarce | environments with GIF and JPEG JFIF? No, but I have an opinion... If you plan to use PNG in a computer that doesn't have enough memory to display the file, how do they plan to use any compressed file format... I don't think the 32k dictionary is bad by no means... The only time the full 32k of memory is used is on files larger than 32k, which means to display such a file, more than 32k of video memory would also be a likely bet. I would rather see the dictionary size increased in some cases. A good example of what a 1 meg deflate dictionary can do is in RAR, the russian archiver... 1 meg however is probably more than an image ever needs, but RAR's smallest dictionary is 64k, and does do better on the raw true color data than PNG does (RAR itsself also contains filters for true color pictures and WAV files.) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 2 19:03:37 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA21176 for ; Mon, 2 Sep 1996 19:03:36 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA01361 for png-list-outgoing; Mon, 2 Sep 1996 19:03:45 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA01356 for ; Mon, 2 Sep 1996 19:03:41 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.5/8.7.3) with ESMTP id QAA21821 for ; Mon, 2 Sep 1996 16:56:44 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.5/8.7.3) id QAA25184 for png-list@dworkin.wustl.edu; Mon, 2 Sep 1996 16:56:44 -0700 (PDT) Message-Id: <199609022356.QAA25184@web1.calweb.com> Subject: Re: Reentract libpng To: png-list@dworkin.wustl.edu Date: Mon, 2 Sep 1996 16:56:44 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <9609021147.AA13755@bird.gemse.fr> from "Jean-loup Gailly" at Sep 2, 96 01:47:03 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > From owner-png-list@dworkin.wustl.edu Mon Sep 2 05:08:49 1996 > Return-Path: owner-png-list@dworkin.wustl.edu > Received: from primus.paranoia.com (primus.paranoia.com [204.145.225.20]) by mail.calweb.com (8.7.5/8.7.3) with SMTP id FAA01933 for ; Mon, 2 Sep 1996 05:08:36 -0700 (PDT) > Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by primus.paranoia.com (8.6.12/paranoia) with ESMTP id HAA03703 for ; Mon, 2 Sep 1996 07:15:06 -0500 > Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA24542 for png-list-outgoing; Mon, 2 Sep 1996 07:05:07 -0500 > Received: from relay1.oleane.net (Relay1.OLEANE.NET [194.2.1.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA24537 for ; Mon, 2 Sep 1996 07:05:01 -0500 > Received: from atlas.gemse.fr ([3.45.12.3]) by relay1.oleane.net (8.6.10/8.6.9) with SMTP id OAA15319 for ; Mon, 2 Sep 1996 14:04:32 +0200 > Received: from bird.gemse.fr by atlas.gemse.fr (4.1/SMI-4.1) > id AA27828; Mon, 2 Sep 96 13:38:32 +0200 > Received: by bird.gemse.fr (5.0/SMI-SVR4) > id AA13755; Mon, 2 Sep 1996 13:47:03 +0200 > Date: Mon, 2 Sep 1996 13:47:03 +0200 > Message-Id: <9609021147.AA13755@bird.gemse.fr> > From: Jean-loup Gailly > To: PNG List > Subject: Re: Reentract libpng > In-Reply-To: > Sender: owner-png-list@dworkin.wustl.edu > Precedence: bulk > Reply-To: PNG List > > > John Bowler writes: > > > 0.88 libpng and zlib (0.95?) have static tables which are initialized at > > run time, but no static data which is modified during compression or > > decompression. I believe that the later zlib initialization is > > write-once and so should be multi-thread safe (multiple threads can > > initialize in parallel). > > zlib is not strictly write-once, but the initialization can be done by multiple > threads in parallel, so it's thread safe. > > Lee Crocker writes: > > > I'm just curious, but why do programs that do CRCs still typically > > have a pre-calculated table, when it has been faster to calculate > > it at runtime rather than load it from disk on any machine made > > since about 1982? > > Many embedded systems don't have any disk. And they often have severe > limitations on RAM size, but more ROM space. The pre-calculated table > can be put in ROM if necessary. This is why zlib supports both > initialization methods (pre-calculated and at runtime). It's not > just a question of speed. > > If your particular application doesn't have any limitation on the size > of the writable data segment, just compile zlib with the appropriate > flag to get dynamic initialization. > > Jean-loup > > ------------------------------------------------------------ > To find out more about the mailing list server, send mail to > png-list-request@dworkin.wustl.edu > with the word "help" (and nothing else) in the message body. > ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 2 19:24:52 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA21309 for ; Mon, 2 Sep 1996 19:24:46 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA01525 for png-list-outgoing; Mon, 2 Sep 1996 19:25:03 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA01520 for ; Mon, 2 Sep 1996 19:25:00 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.5/8.7.3) with ESMTP id RAA24468 for ; Mon, 2 Sep 1996 17:18:03 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.5/8.7.3) id RAA04386 for png-list@dworkin.wustl.edu; Mon, 2 Sep 1996 17:18:03 -0700 (PDT) Message-Id: <199609030018.RAA04386@web1.calweb.com> Subject: Decompression memory requirements To: png-list@dworkin.wustl.edu Date: Mon, 2 Sep 1996 17:18:03 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <199609030001.TAA23685@inet.htcnet.com> from "Carl Morris" at Sep 2, 96 06:52:42 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >| Does anyone have a feel for how PNG compares in memory- and >| cpu-scarce environments with GIF and JPEG JFIF? > No, but I have an opinion... If you plan to use PNG in a computer that > doesn't have enough memory to display the file, how do they plan to use > any compressed file format... I don't think the 32k dictionary is bad > by no means... The only time the full 32k of memory is used is on > files larger than 32k, which means to display such a file, more than > 32k of video memory would also be a likely bet... That's not really true. A non-interlaced PNG can be decoded and displayed on a machine without sufficient memory to hold it, and even an interlaced on can be decoded if there is external storage (disk, for example) equivalent to /half/ of the uncompressed image size. As far as display goes, that will of course require either streaming to a device with its own frame buffer, or to a printer, or else downsampling on the fly. Having written a program that printed 500k interlaced GIFs in full color to an HP Paintjet on a machine with 256k, I can confirm that those are not just theoretical possibilities. (It's still on some FTP sites--I haven't played with it for years). Software decoding arbitrary PNG images must have the 32k buffer plus working RAM; I wouldn't use an embedded system with less than 48k. GIF was lighter, squeezable into 16k. This ignores the eventual destination of the image bits, which is a separate concern not related to compression format. ROM requirements are probably a bit larger than GIF's as well, but not much. JPEG is smaller than both (Tom?). If you're creating an imbedded system that only needs to deal with images created by that system or one which you control, you can produce PNG images that only use 8k or 16k buffers, and those images will be readable by normal decoders. Limiting a decoder to those, however, will of course cause it to fail on other PNGs. So if you were creating a system, say, that captured pictures, compressed them, and transmitted them to another box that displayeed them, you could get away with less memory if you didn't have to worry about other transmitters of arbitrary PNGs sending to your receiver. -- Lee Daniel Crocker ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 2 20:31:38 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA21620 for ; Mon, 2 Sep 1996 20:31:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA02101 for png-list-outgoing; Mon, 2 Sep 1996 20:31:46 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id UAA02096 for ; Mon, 2 Sep 1996 20:31:43 -0500 Date: Mon, 2 Sep 96 21:28:39 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Fourteenth MNG draft Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609022128.aa06661@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In the 14th MNG draft, in Section 4, Retaining image data, the first paragraph contains language that no longer applies, because the CHDR/CEND syntax has been eliminated: When dependent frames (frames containing PND streams) are present, the decoder must retain information about the previous frame for use in decoding the dependent frame. It is never necessary to retain information from frames earlier than the previous frame, except for the original background, which must be retained for the entire duration of the MNG stream if it is required. This paragraph should be replaced with: When ok_to_discard == 0 in the MHDR chunk, the decoder must retain information about each image for possible redisplay with the SHOW or LSHO chunks or use as the basis image for a subsequent PND stream. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 3 09:11:53 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA27987 for ; Tue, 3 Sep 1996 09:11:53 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA10305 for png-list-outgoing; Tue, 3 Sep 1996 09:09:36 -0500 Received: from qnx.com (qnx.com [198.53.31.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA10299 for ; Tue, 3 Sep 1996 09:09:31 -0500 Received: (from chrish@localhost) by qnx.com (8.6.12/8.6.12) id KAA27415 for png-list@dworkin.wustl.edu; Tue, 3 Sep 1996 10:09:05 -0400 Message-Id: <199609031409.KAA27415@qnx.com> Subject: Re: Reentract libpng To: png-list@dworkin.wustl.edu Date: Tue, 3 Sep 1996 10:08:58 -0400 (EDT) From: "Chris Herborth" In-Reply-To: <9609021147.AA13755@bird.gemse.fr> from "Jean-loup Gailly" at Sep 2, 96 01:47:03 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List What you wrote: > Many embedded systems don't have any disk. And they often have severe > limitations on RAM size, but more ROM space. The pre-calculated table > can be put in ROM if necessary. This is why zlib supports both > initialization methods (pre-calculated and at runtime). It's not > just a question of speed. A lot of embedded systems also have very limited CPU power; startup time can also be very important for fault-tolerant systems... in this case, having the CRC tables in ROM or FLASH is a big win. -- ----------================================================---------- _ Chris Herborth, R&D Technical Writer (chrish@qnx.com) | \ _ QNX Software Systems, Ltd. Arcane Dragon -==(UDIC)==- | < /_\ http://www.qnx.com/~chrish/ DNRC Holder of Past Knowledge |_/ \_ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 3 11:13:27 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id LAA29761 for ; Tue, 3 Sep 1996 11:13:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA12412 for png-list-outgoing; Tue, 3 Sep 1996 11:12:10 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA12407 for ; Tue, 3 Sep 1996 11:12:04 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id MAA15822 for ; Tue, 3 Sep 1996 12:11:36 -0400 (EDT) To: PNG List Subject: Re: Decompression memory requirements In-reply-to: Your message of Mon, 2 Sep 1996 17:18:03 -0700 (PDT) <199609030018.RAA04386@web1.calweb.com> Date: Tue, 03 Sep 1996 12:11:36 -0400 Message-ID: <15820.841767096@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Lee sez >> | Does anyone have a feel for how PNG compares in memory- and >> | cpu-scarce environments with GIF and JPEG JFIF? > Software decoding arbitrary PNG images must have the 32k buffer > plus working RAM; I wouldn't use an embedded system with less than > 48k. GIF was lighter, squeezable into 16k. GIF compression requires an absolute minimum of about 25Kb for the LZW hashtable (5 bytes/slot, about 5000 slots to hold density to something reasonable for a 4096-symbol table). That's in addition to any actual storage for image data, I/O buffers, etc. Deflate takes more (32Kb history buffer plus string-searching tables; not sure how big those tables are) but not an order of magnitude more. The decompression figures are at least 13K for GIF (4096 3-byte table entries, plus a stack of uncertain maximum size) vs 32K for PNG (all you need is the history buffer). > JPEG is smaller than both (Tom?). I'm not sure JPEG is really relevant to the comparison, but the IJG decoder uses about 20K of working space plus strip buffers proportional to the image width (typically about 40 bytes/pixel column for color data, last I counted). Possibly lots more, if you do anything that forces the whole image to be buffered --- progressive JPEG does, for example. The encoder is in the same ballpark. Of course the code size is substantially larger than what either PNG or GIF need. > If you're creating an imbedded system that only needs to deal with > images created by that system or one which you control, you can > produce PNG images that only use 8k or 16k buffers, and those images > will be readable by normal decoders. Restricting the decoder to handle only indexed-color images would be another way to simplify it and reduce its memory needs. However, we certainly don't want to encourage people to build subset PNG decoders. I find this whole argument highly unconvincing. PNG certainly requires somewhat more code and data than GIF, but it'd be pretty silly to design a new spec in 1995 that was *not* any more resource-hungry than GIF87. Technology marches on. In comparison to the resources available in a typical PC of the two eras, PNG is far cheaper to implement than GIF was when it first came out. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 3 11:40:40 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id LAA00437 for ; Tue, 3 Sep 1996 11:40:37 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA13097 for png-list-outgoing; Tue, 3 Sep 1996 11:40:51 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA13092 for ; Tue, 3 Sep 1996 11:40:47 -0500 Received: by grommit.inria.fr (8.7.5/8.6.12) id SAA01286 for png-list@dworkin.wustl.edu; Tue, 3 Sep 1996 18:40:20 +0200 (DST) Date: Tue, 3 Sep 1996 18:40:20 +0200 (DST) From: Chris Lilley Message-Id: <9609031840.ZM1284@grommit.inria.fr> In-Reply-To: Tom Lane "Re: Decompression memory requirements" (Sep 3, 12:11pm) References: <15820.841767096@sss.pgh.pa.us> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: Decompression memory requirements Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 3, 12:11pm, Tom Lane wrote: > The decompression figures are at least 13K for GIF (4096 3-byte table > entries, plus a stack of uncertain maximum size) vs 32K for PNG (all > you need is the history buffer). So, not that much in it. I imagine off-screen storage of the uncompressed image is the main hog, and that will be the same ofr equivalent GIF and PNG images (and for equivalent PNG, JPEG, TIFF etc truecolor images). > I'm not sure JPEG is really relevant to the comparison, but the IJG > decoder uses about 20K of working space plus strip buffers proportional > to the image width (typically about 40 bytes/pixel column for color > data, last I counted). Possibly lots more, if you do anything that > forces the whole image to be buffered --- progressive JPEG does, for > example. Ah, interesting. > Of course the code size > is substantially larger than what either PNG or GIF need. Right. > we certainly don't want to encourage people to build subset > PNG decoders. Which would not actually be PNG decoders acording to the spec, I believe. > I find this whole argument highly unconvincing. PNG certainly > requires somewhat more code and data than GIF, Somewhat more is fine. Lots more might have been a problem > Technology marches on. In comparison to the resources > available in a typical PC of the two eras, PNG is far cheaper to > implement than GIF was when it first came out. Yes, but another consequence of technology marching on is that a GSM portable phone can have a PDA and a Web browser inside it. PCs become more powerful, but also electronic organisers become powerful enough to think about displaying graphics. An example of this class of technology which I came across recently: http://www.geoworks.com/htmpages/9000.htm [I want one, can you tell?] -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 3 12:02:09 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA00834 for ; Tue, 3 Sep 1996 12:02:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA13385 for png-list-outgoing; Tue, 3 Sep 1996 12:02:08 -0500 Received: from llyene.jpl.nasa.gov (llyene.jpl.nasa.gov [128.149.75.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA13380 for ; Tue, 3 Sep 1996 12:02:05 -0500 Received: from quest.jpl.nasa.gov (quest.jpl.nasa.gov [128.149.75.43]) by llyene.jpl.nasa.gov (8.6.8/8.6.6) with SMTP id KAA12404 for ; Tue, 3 Sep 1996 10:01:57 -0700 Received: by quest.jpl.nasa.gov (NX5.67f2/NX3.0S) id AA15020; Tue, 3 Sep 96 10:00:43 -0700 Message-Id: <9609031700.AA15020@quest.jpl.nasa.gov> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) X-Image-Url: http://quest.jpl.nasa.gov/mark-face.gif In-Reply-To: <15820.841767096@sss.pgh.pa.us> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.118.2) From: Mark Adler Date: Tue, 3 Sep 96 10:00:41 -0700 To: PNG List Subject: Re: Decompression memory requirements References: <15820.841767096@sss.pgh.pa.us> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >> The decompression figures are at least 13K for GIF (4096 3-byte table >> entries, plus a stack of uncertain maximum size) vs 32K for PNG (all >> you need is the history buffer). PNG (i.e. zlib inflate) needs another few K (4 to 8 I think) for Huffman decoding tables. mark ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 3 15:24:21 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA03964 for ; Tue, 3 Sep 1996 15:24:20 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA16958 for png-list-outgoing; Tue, 3 Sep 1996 15:24:00 -0500 Received: from inet.htcnet.com (inet.htcnet.com [199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA16953 for ; Tue, 3 Sep 1996 15:23:53 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id PAA04098 for ; Tue, 3 Sep 1996 15:32:21 -0500 Message-Id: <199609032032.PAA04098@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: Re: Reentract libpng Date: Tue, 3 Sep 1996 15:23:22 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List | > Many embedded systems don't have any disk. And they often have severe | > limitations on RAM size, but more ROM space. The pre-calculated table | > can be put in ROM if necessary. This is why zlib supports both | > initialization methods (pre-calculated and at runtime). It's not | > just a question of speed. | | A lot of embedded systems also have very limited CPU power; startup time | can also be very important for fault-tolerant systems... in this case, | having the CRC tables in ROM or FLASH is a big win. Why would such a system be processing images... ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 3 15:51:48 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA04179 for ; Tue, 3 Sep 1996 15:51:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA17531 for png-list-outgoing; Tue, 3 Sep 1996 15:51:55 -0500 Received: from qnx.com (qnx.com [198.53.31.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA17525 for ; Tue, 3 Sep 1996 15:51:49 -0500 Received: (from chrish@localhost) by qnx.com (8.6.12/8.6.12) id QAA07015 for png-list@dworkin.wustl.edu; Tue, 3 Sep 1996 16:51:21 -0400 Message-Id: <199609032051.QAA07015@qnx.com> Subject: Re: Reentract libpng To: png-list@dworkin.wustl.edu Date: Tue, 3 Sep 1996 16:51:13 -0400 (EDT) From: "Chris Herborth" In-Reply-To: <199609032032.PAA04098@inet.htcnet.com> from "Carl Morris" at Sep 3, 96 03:23:22 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List What you wrote: > | > Many embedded systems don't have any disk. And they often have > severe > | > limitations on RAM size, but more ROM space. The pre-calculated > table > | > can be put in ROM if necessary. This is why zlib supports both > | > initialization methods (pre-calculated and at runtime). It's not > | > just a question of speed. > | > | A lot of embedded systems also have very limited CPU power; startup > time > | can also be very important for fault-tolerant systems... in this > case, > | having the CRC tables in ROM or FLASH is a big win. > > Why would such a system be processing images... I could envision a scanner grabbing small images, passing them over a narrow network (serial link or something) to a server of some sort for OCR... if network bandwidth was the major bottleneck, something like PNG could be a boon. Even at a low compression level, it would help. And maybe the server would occaisionally send back images for the operator (maybe FedEx or someone would like a hand-held package scanner that can display an image of the original shipping label in case the package is damaged?). Of course, this mythical system would probably use a hardware TIFF implementation... And then there's the Network Computer. I've seen specs for some of these things, and they're not much more powerful than a Newton to try to keep costs down. And one of the big targets for these are web surfers, who will have to deal with gif, jpeg, png, etc on wimpy systems with no backing store at all, and not much RAM. -- ----------================================================---------- _ Chris Herborth, R&D Technical Writer (chrish@qnx.com) | \ _ QNX Software Systems, Ltd. Arcane Dragon -==(UDIC)==- | < /_\ http://www.qnx.com/~chrish/ DNRC Holder of Past Knowledge |_/ \_ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 3 16:30:53 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA04663 for ; Tue, 3 Sep 1996 16:30:51 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA18067 for png-list-outgoing; Tue, 3 Sep 1996 16:30:50 -0500 Received: from inet.htcnet.com (inet.htcnet.com [199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA18062 for ; Tue, 3 Sep 1996 16:30:47 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id QAA04587 for ; Tue, 3 Sep 1996 16:39:15 -0500 Message-Id: <199609032139.QAA04587@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: Re: Reentract libpng Date: Tue, 3 Sep 1996 16:30:16 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List | I could envision a scanner grabbing small images, passing them over a | narrow network (serial link or something) to a server of some sort for | OCR... if network bandwidth was the major bottleneck, something like PNG I think if the PNG designers really had this in mind, ZLIB would not have been the compressor... also, there is no company that would even try this... The compressing of the image in such a system would be the system's downfall... | And then there's the Network Computer. I've seen specs for some of | these things, and they're not much more powerful than a Newton to try to | keep costs down. And one of the big targets for these are web surfers, | who will have to deal with gif, jpeg, png, etc on wimpy systems with no | backing store at all, and not much RAM. And that is one reason why this systems will never gain much popularity. Already the web has outgrown my full blown computer, there is no way a settop "network" computer is going to be better! (At least I can upgrade my PC when I get money! :) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 3 16:31:24 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA04678 for ; Tue, 3 Sep 1996 16:31:24 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA18098 for png-list-outgoing; Tue, 3 Sep 1996 16:31:45 -0500 Received: from jeeves.va.pubnix.com (jeeves.va.pubnix.com [199.170.214.66]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA18090 for ; Tue, 3 Sep 1996 16:31:41 -0500 Received: from garotte.va.pubnix.com by jeeves.va.pubnix.com with ESMTP id RAA19505; Tue, 3 Sep 1996 17:30:58 -0400 (EDT) Received: from garotte.va.pubnix.com by garotte.va.pubnix.com with ESMTP id RAA01643; Tue, 3 Sep 1996 17:30:57 -0400 (EDT) Message-Id: To: PNG List Subject: Re: Decompression memory requirements In-reply-to: Your message of "Tue, 03 Sep 1996 18:40:20 +0200." <9609031840.ZM1284@grommit.inria.fr> Date: Tue, 03 Sep 1996 17:30:57 -0400 From: "Josh M. Osborne" Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In message <9609031840.ZM1284@grommit.inria.fr>, Chris Lilley writes: [...PNG requires somewhat more resources then GIF, which is fine for PC's, but may not be so how for embeded systems...] >Yes, but another consequence of technology marching on is that a >GSM portable phone can have a PDA and a Web browser inside it. >PCs become more powerful, but also electronic organisers become >powerful enough to think about displaying graphics. > >An example of this class of technology which I came across recently: >http://www.geoworks.com/htmpages/9000.htm Mabie not such a hot example. It has 2M of "program execution" space, which I susspect is the data area for running programs, and mabie code living in the FLASH ROM gets copied in. It also has a "powerful" 24Mhz i386 in there. (it is a good example in that it is a resource constrained machine with a web browser, but the Sony MagicCap, or the AST "zoomer" would be better examples of "Resource constrained", but they still have at least 1M of RAM) I can't actually think of anything that would want to deal with largeish bitmap images where 32K vs. 16K would make a big diffrence. The last time I programmed coin-op video games was 4 years ago and even then we had several megs of RAM (mind you we were fairly short, but no we were actually shorter on ROM!). >[I want one, can you tell?] So do I. Unfortunitly the few parts of the USA that could use such a GSM phone run on a diffrent frequency, so I doubt Nokia will make a USA version. I do wonder how much they cost... ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 3 16:51:16 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA05130 for ; Tue, 3 Sep 1996 16:51:16 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA18386 for png-list-outgoing; Tue, 3 Sep 1996 16:50:54 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA18381 for ; Tue, 3 Sep 1996 16:50:40 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.5/8.7.3) with ESMTP id OAA05722 for ; Tue, 3 Sep 1996 14:43:30 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.5/8.7.3) id OAA15100 for png-list@dworkin.wustl.edu; Tue, 3 Sep 1996 14:43:29 -0700 (PDT) Message-Id: <199609032143.OAA15100@web1.calweb.com> Subject: Decompression memory requirements To: png-list@dworkin.wustl.edu Date: Tue, 3 Sep 1996 14:43:28 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <199609032139.QAA04587@inet.htcnet.com> from "Carl Morris" at Sep 3, 96 04:30:16 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > I think if the PNG designers really had this in mind, ZLIB would not > have been the compressor... also, there is no company that would even > try this... The compressing of the image in such a system would be the > system's downfall... "The PNG Designers" are right here; no need to speculate. Yes, embedded applications were a concern, so we chose an algorithm that was a reasonable compromise between memory usage and effectiveness. A 64k machine is quite capable of handling PNG. At current prices of RAM, that's about $1. Maybe $2-3 for statics. That's not going to influence the price of set-top boxes much at all. -- Lee Daniel Crocker ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 3 17:14:18 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id RAA05496 for ; Tue, 3 Sep 1996 17:14:17 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA18669 for png-list-outgoing; Tue, 3 Sep 1996 17:14:13 -0500 Received: from inet.htcnet.com (inet.htcnet.com [199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA18664 for ; Tue, 3 Sep 1996 17:14:08 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id RAA04901 for ; Tue, 3 Sep 1996 17:22:35 -0500 Message-Id: <199609032222.RAA04901@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: Re: Decompression memory requirements Date: Tue, 3 Sep 1996 17:13:35 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List | "The PNG Designers" are right here; no need to speculate. Yes, embedded | applications were a concern, so we chose an algorithm that was a | reasonable compromise between memory usage and effectiveness. A 64k | machine is quite capable of handling PNG. At current prices of RAM, | that's about $1. Maybe $2-3 for statics. That's not going to influence | the price of set-top boxes much at all. Face it, ZLIB is not fast on a 1mhz processor.... Such a system could send the data faster uncompressed that in it compressed ... THe only reason compression is used on big machines is because BIG machines can process faster than they can talk... the processors I program on can communicate as fast as they can process in many cases... as such, I wouldn't even consider compression... that was what I was getting at... ZLIB would have to be placed in hardware for such a device to use it... ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 3 18:50:13 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA06378 for ; Tue, 3 Sep 1996 18:50:13 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA20358 for png-list-outgoing; Tue, 3 Sep 1996 18:50:31 -0500 Received: from Starbase.NeoSoft.COM (starbase.neosoft.com [206.109.7.129]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA20350 for ; Tue, 3 Sep 1996 18:50:28 -0500 Received: (from peter@localhost) by Starbase.NeoSoft.COM (8.7.5/8.7.4) id SAA03203 for png-list@dworkin.wustl.edu; Tue, 3 Sep 1996 18:49:59 -0500 (CDT) From: Peter da Silva Message-Id: <199609032349.SAA03203@Starbase.NeoSoft.COM> Subject: Re: or tags for PNG To: png-list@dworkin.wustl.edu Date: Tue, 3 Sep 1996 18:49:59 -0500 (CDT) In-Reply-To: <199608301414.JAA06179@ellis.uchicago.edu> from "Cave Newt" at Aug 30, 96 09:14:35 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Amaya? ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 5 10:26:13 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA05830 for ; Thu, 5 Sep 1996 10:26:11 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA19261 for png-list-outgoing; Thu, 5 Sep 1996 10:25:48 -0500 Received: from sun31336a.cc.bellcore.com (sun31336a.cc.bellcore.com [128.96.71.114]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA19256 for ; Thu, 5 Sep 1996 10:25:44 -0500 From: neil@sun31336a Received: by sun31336a.cc.bellcore.com (SMI-8.6/SMI-SVR4) id LAA00755; Thu, 5 Sep 1996 11:23:35 -0400 Date: Thu, 5 Sep 1996 11:23:35 -0400 Message-Id: <199609051523.LAA00755@sun31336a.cc.bellcore.com> To: png-list@dworkin.wustl.edu Subject: How do I get off this list? X-Sun-Charset: US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I have sent numerous requests to png-list-request@dworkin.wustl.edu to either get help or get unsubscribed to the png-list, but to no avail. How do I get off this list? Neil. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 5 11:24:22 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id LAA06844 for ; Thu, 5 Sep 1996 11:24:21 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA20369 for png-list-outgoing; Thu, 5 Sep 1996 11:24:39 -0500 Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA20364 for ; Thu, 5 Sep 1996 11:24:36 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by wugate.wustl.edu (8.7.5/8.7.3) with SMTP id LAA26857 for ; Thu, 5 Sep 1996 11:24:40 -0500 Date: Thu, 5 Sep 96 12:22:45 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: How do I get off this list? Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609051222.aa19298@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }From: neil@sun31336a }Date: Thu, 5 Sep 1996 11:23:35 -0400 }Subject: How do I get off this list? } }I have sent numerous requests to png-list-request@dworkin.wustl.edu to either }get help or get unsubscribed to the png-list, but to no avail. } }How do I get off this list? } } Neil. Assuming that the png-list subscriber "neil@cc.bellcore.com" is you, send a message to majordomo@dworkin.wustl.edu. In the body, put the following lines (and nothing else): unsubscribe png-list neil@cc.bellcore.com end ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 5 17:44:40 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id RAA18631 for ; Thu, 5 Sep 1996 17:44:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA27423 for png-list-outgoing; Thu, 5 Sep 1996 17:44:57 -0500 Received: from inet.htcnet.com (inet.htcnet.com [199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA27417 for ; Thu, 5 Sep 1996 17:44:49 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id RAA27970 for ; Thu, 5 Sep 1996 17:53:28 -0500 Message-Id: <199609052253.RAA27970@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: DOS/Win 32 software Date: Thu, 5 Sep 1996 17:44:06 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Is there any good software for converting files between PNG and other formats available for DOS or Win32 that doesn't comprise of comercial or shareware or even full fledged applications... I have heard of the PNGTOPNM or what ever utilities, but do DOS or Win32 binaries exist? I currently use PSP 3.12/4.1 and CompuShow 2000 both unregistered, and I just find that they do not always give me the control I would like to have on a format such as PNG... Their compression also ranges from okay to poor... -|- Carl Morris (N0YUV) -|- 1:285/302 -|- msftrncs@htcnet.com -|- -|- Hooper Connections BBS -|- 1-(402)-654-2102 -|- 28.8kbps V.34 -|- -|- http://199.120.83.179/~moreese/ -|- ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 5 17:46:56 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id RAA18643 for ; Thu, 5 Sep 1996 17:46:50 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA27444 for png-list-outgoing; Thu, 5 Sep 1996 17:47:14 -0500 Received: from inet.htcnet.com (inet.htcnet.com [199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA27439 for ; Thu, 5 Sep 1996 17:47:11 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id RAA27976 for ; Thu, 5 Sep 1996 17:55:50 -0500 Message-Id: <199609052255.RAA27976@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: Paint Shop Pro 4.1's PNG support... Date: Thu, 5 Sep 1996 17:46:29 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I got to thank JASC, they added GIF style alpha support to their PNG support, but thats the end of the thanks... Their compression of the image data is worse now, often 2k or more larger for images that are fairly simple. Still no fine control over palettes (how many entries actually need to be in the file) or true color alpha masks... or other things which one might really wish graphic applications would take advantage of... -|- Carl Morris (N0YUV) -|- 1:285/302 -|- msftrncs@htcnet.com -|- -|- Hooper Connections BBS -|- 1-(402)-654-2102 -|- 28.8kbps V.34 -|- -|- http://199.120.83.179/~moreese/ -|- ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 00:02:38 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id AAA22839 for ; Fri, 6 Sep 1996 00:02:37 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA01879 for png-list-outgoing; Fri, 6 Sep 1996 00:03:01 -0500 Received: from gntcompaq.gintic.ntu.ac.sg ([155.69.29.28]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id AAA01873 for ; Fri, 6 Sep 1996 00:02:50 -0500 Received: by gntcompaq.gintic.ntu.ac.sg with Microsoft Exchange (IMC 4.0.837.3) id <01BB9BF3.C2B23E00@gntcompaq.gintic.ntu.ac.sg>; Fri, 6 Sep 1996 13:03:12 +0800 Message-ID: From: Willem van Schaik To: "'PNG List'" Subject: RE: DOS/Win 32 software Date: Fri, 6 Sep 1996 13:03:11 +0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Hi Carl, I put the MS-DOS binaries of pnmtopng on my ftp-server: see ftp://mht3.gintic.ntu.ac.sg:8021/pub/png/pnmtopng-msdos.zip Hope this helps you. But I agree that the focus of the png-group is very much on the Unix front and that we should pay more attention to DOS/Win users. Of course I must admit that I'm just as much to blame for that. There are ofcourse quite some Win application that support PNG, for example PaintShop Pro is doing a good job. Also SEA (not Windows-based, but very fast and good-looking) is doing it quite well. Willem W i l l e m v a n S c h a i k ------------------------------------------------------------------------- ------ Gintic - Singapore willem@gintic.ntu.edu.sg http://mht3.gintic.ntu.ac.sg:8000/WWWillem.html >---------- >From: Carl Morris[SMTP:msftrncs@htcnet.com] >Sent: Friday, 6 September 1996 06:44 >To: Willem van Schaik >Subject: DOS/Win 32 software > >Is there any good software for converting files between PNG and other >formats available for DOS or Win32 that doesn't comprise of comercial >or shareware or even full fledged applications... I have heard of the >PNGTOPNM or what ever utilities, but do DOS or Win32 binaries exist? > >I currently use PSP 3.12/4.1 and CompuShow 2000 both unregistered, and >I just find that they do not always give me the control I would like to >have on a format such as PNG... Their compression also ranges from >okay to poor... > >-|- Carl Morris (N0YUV) -|- 1:285/302 -|- msftrncs@htcnet.com -|- >-|- Hooper Connections BBS -|- 1-(402)-654-2102 -|- 28.8kbps V.34 -|- >-|- http://199.120.83.179/~moreese/ -|- > >------------------------------------------------------------ >To find out more about the mailing list server, send mail to >png-list-request@dworkin.wustl.edu >with the word "help" (and nothing else) in the message body. > ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 00:39:16 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id AAA22954 for ; Fri, 6 Sep 1996 00:39:14 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA02241 for png-list-outgoing; Fri, 6 Sep 1996 00:39:42 -0500 Received: from INET-03-IMC.itg.microsoft.com (mail3.microsoft.com [131.107.3.23]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id AAA02225 for ; Fri, 6 Sep 1996 00:39:37 -0500 Received: by INET-03-IMC.itg.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB9B73.D333C3F0@INET-03-IMC.itg.microsoft.com>; Thu, 5 Sep 1996 21:47:24 -0700 Message-ID: From: John Bowler To: "'PNG List'" Subject: RE: DOS/Win 32 software Date: Thu, 5 Sep 1996 17:20:02 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 34 TEXT Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >From: Carl Morris[SMTP:msftrncs@htcnet.com] > >Is there any good software for converting files between PNG and other >formats available for DOS or Win32 that doesn't comprise of comercial >or shareware or even full fledged applications... I have heard of the >PNGTOPNM or what ever utilities, but do DOS or Win32 binaries exist? NetPBM supports convertion of BMP (and non-Win32) formats to pnm. It is available pre-compiled for various X86 systems in the SimTel archives (at http://www.coast.net/SimTel/ - the NT version can be found in http://www.coast.net/SimTel/nt/graphics.html). This doesn't include png convertion, but that can be found in ftp://swrinde.nde.swri.edu/pub/png/applications/. >I currently use PSP 3.12/4.1 and CompuShow 2000 both unregistered, and >I just find that they do not always give me the control I would like to >have on a format such as PNG... Their compression also ranges from >okay to poor... It is also fairly trivial to take "example.c" from the libpng source and hack it to read a BMP file and output a PNG. The level of control here is enormous :-) The one issue you probably won't find addressed is that of converting the CIEXYZTRIPLE in a BITMAPV4 bitmap into the corresponding PNG cHRM chunk, however it is just a fairly easy scaling operation. Overall compression of palette based images tends to be very variable in my experience. Increasing the Zlib compression level frequently doesn't help - this is probably just the side effect of attempting to compress a dithered image. John Bowler > ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 00:44:19 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id AAA23032 for ; Fri, 6 Sep 1996 00:44:18 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA02302 for png-list-outgoing; Fri, 6 Sep 1996 00:44:55 -0500 Received: from mega.megamed.com (megamed.com [199.4.114.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id AAA02293 for ; Fri, 6 Sep 1996 00:44:51 -0500 Received: from coruisk (mega218.megamed.com [199.4.114.218]) by mega.megamed.com (8.7.5/8.7.3) with SMTP id WAA01224 for ; Thu, 5 Sep 1996 22:43:56 -0700 Date: Thu, 5 Sep 1996 22:43:56 -0700 Message-Id: <199609060543.WAA01224@mega.megamed.com> X-Sender: jbowler@megamed.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: John Bowler Subject: RE: DOS/Win 32 software Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List It looks like the message I sent from Microsoft got lost in the bowels of Microsoft Exchange, so, in the certainty of repeating myself... http://www.coast.net/simtel/ is a very good archive of DOS/Win16/Win32/OS/2 software, in particular http://www.coast.net/simtel/nt/graphics.html contains the NetPBM toolkit (netpbm-e.zip) compiled for Win. In combination with Willem van Schaik's pnmtopng this is sufficient to deal with Win bitmap formats up to BITMAPINFO. Alternatively, given a compiler, you can hack example.c from libpng to read BMP files fairly trivially. This option gives the greatest control over compression parameters and so on. The only unanswered issue (unless you really want a GUI :-) is how to handle the CIEXYZTRIPLE in a BITMAPV4 - this should be translated into a PNG cHRM chunk but it has a different format (it has X, Y and Z). The code to do this is, however, a relatively trivial scaling operation. John Bowler (jbowler@megamed.com) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 07:35:19 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id HAA26042 for ; Fri, 6 Sep 1996 07:35:17 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA06066 for png-list-outgoing; Fri, 6 Sep 1996 07:35:34 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA06061 for ; Fri, 6 Sep 1996 07:35:31 -0500 Received: by grommit.inria.fr (8.7.5/8.6.12) id OAA14903 for png-list@dworkin.wustl.edu; Fri, 6 Sep 1996 14:34:47 +0200 (DST) Date: Fri, 6 Sep 1996 14:34:47 +0200 (DST) From: Chris Lilley Message-Id: <9609061434.ZM14901@grommit.inria.fr> In-Reply-To: John Bowler "RE: DOS/Win 32 software" (Sep 5, 5:20pm) References: X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: DOS/Win 32 software Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 5, 5:20pm, John Bowler wrote: > The one issue you probably won't find addressed is that of converting > the CIEXYZTRIPLE in a BITMAPV4 bitmap into the corresponding PNG cHRM > chunk, however it is just a fairly easy scaling operation. Interesting, I didn't know bmp could have that information. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 09:55:44 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA27718 for ; Fri, 6 Sep 1996 09:55:43 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA07597 for png-list-outgoing; Fri, 6 Sep 1996 09:55:40 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA07583; Fri, 6 Sep 1996 09:55:28 -0500 Received: by grommit.inria.fr (8.7.5/8.6.12) id QAA15287; Fri, 6 Sep 1996 16:54:44 +0200 (DST) Date: Fri, 6 Sep 1996 16:54:44 +0200 (DST) From: Chris Lilley Message-Id: <9609061654.ZM15285@grommit.inria.fr> In-Reply-To: Glenn Randers-Pehrson ARL-WMRD-TED-TIB "Re: MNG subformats" (Sep 6, 9:05am) References: <9609060905.aa11287@THOR.ARL.MIL> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: mpng-list@dworkin.wustl.edu Subject: URL in PNG/ MPNG (was Re: MNG subformats) Cc: png-list@dworkin.wustl.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 6, 9:05am, Glenn Randers-Pehrson ARL-WMRD-TED-TIB wrote: > Chris wrote: > } > }Sort of, except that I expected the chunk to contain the URL so the > }composite image could in fact be displayed standalone by an http-aware > }viewer > > This looks very dangerous. I agree with Lee, that a MNG should always > be standalone, we are using different meanings for standalone. I am meaning that the file itself has the information required, without having to refer to the HTML in which the file is embeded. I am assuming that gettingsomething over HTTP is a fairly core thing that any OS can do nowadays. You and Lee seem to mean that the file has no external references, so it stands alone in that sense although the displayed result on taking a blank NONE as previously described and then replacing it's alpha channel would not be terribly useful, I feel. > even if it actually contains a PND preceded by a NONE chunk. > I think the viewer should just receive the two files from some other > http-aware application such as an HTML parser. Perhaps you could post an HTML fragment that might express this. I am not aware of a way to send two different URLs to one image (or media) viewer and would be interested to see your suggestions. Handing off the required functionality to an enclosing application is fine, as long as we have established that the enclosing application can actually do it. In the case of HTML and a browser being the enclosing application, I don't yet see how this is to be expressed. > I would not mind putting the URL of the basis image in a tEXt chunk, though, > to have a record of the image's origen, but I would not expect any viewer > to do anything but display the URL as text. > > tEXt:Basis Image URL\0ftp://swrinde.nde.swri.edu/mng/images/whatever.mng This is a related example to another text keyword I was planning to register once the dust has settled a little on the PNG spec. Original at URL\0fully qualified URL in accordance with RFC 1738 plus optional relative URL in accordance with RFC 1808 Perhaps the extensions chunk should contain a couple of paragraphs about URLs, like they now have about floating point, so all text keywords that expect a URL use the same format. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 10:01:27 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA28113 for ; Fri, 6 Sep 1996 10:01:24 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA07654 for png-list-outgoing; Fri, 6 Sep 1996 10:01:50 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id KAA07649 for ; Fri, 6 Sep 1996 10:01:47 -0500 Date: Fri, 6 Sep 96 10:58:13 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: png-list@dworkin.wustl.edu Subject: Anniversary of chunk proposals Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609061058.aa14047@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List It's a year and a day since Todd French proposed the fALS, pCAL, and dRNG chunks. sPLT has been around longer than that. We should take action to register them. I propose that sPLT be moved into the png extensions document, and that the following be added to the png extensions document, in the section "Chunks Not Described Here".

fALS False Color

The fALS chunk describes a palette to be used together with grayscale image data to produce a false-color image.

dRNG, DRNG Pixel Data Range

The dRNG or DRNG chunk gives the data range of pixel samples, when the values do not occupy the full range of possible values.

lOGE, LOGE Logarithmic Encoding

The lOGE or LOGE chunk provides parameters for decoding image data whose samples have been logarithmically encoded.

pCAL Scale of Pixel Values

The pCAL chunk records the relationship between pixel values and actual physical values, when the PNG file is being used to store physical data.

xSCL X Scale of Image Subject

The xSCL chunk records the relationship between the column position of a pixel and an actual physical value.

ySCL Y Scale of Image Subject

The ySCL chunk records the relationship between the row position of a pixel and an actual physical value. I propose that we take no action now on the proposed aLIG, fING, tSCL, and zSCL chunks. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 10:11:52 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA28192 for ; Fri, 6 Sep 1996 10:11:48 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA07752 for png-list-outgoing; Fri, 6 Sep 1996 10:11:53 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id KAA07746 for ; Fri, 6 Sep 1996 10:11:50 -0500 Date: Fri, 6 Sep 96 11:08:48 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Anniversary of chunk proposals Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609061108.aa15364@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I wrote: }The specifications }for the following chunks appear in the PNG Scientific Visualization Chunks }document, which is available at ftp://swrinde.nde.swri.edu/pub/png/documents/. } In case you are hunting for this document: The *proposed* sci-vis document is in pub/png-group/documents. Once the chunks are registered, I would put a copy in png/documents, with the unregistered ones not mentioned, and the chunk names modified to reflect their registered status. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 10:31:50 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA29011 for ; Fri, 6 Sep 1996 10:31:49 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA08123 for png-list-outgoing; Fri, 6 Sep 1996 10:31:58 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA08116 for ; Fri, 6 Sep 1996 10:31:52 -0500 Received: by grommit.inria.fr (8.7.5/8.6.12) id RAA15455 for png-list@dworkin.wustl.edu; Fri, 6 Sep 1996 17:31:02 +0200 (DST) Date: Fri, 6 Sep 1996 17:31:02 +0200 (DST) From: Chris Lilley Message-Id: <9609061731.ZM15453@grommit.inria.fr> In-Reply-To: Glenn Randers-Pehrson ARL-WMRD-TED-TIB "Anniversary of chunk proposals" (Sep 6, 10:58am) References: <9609061058.aa14047@THOR.ARL.MIL> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: Anniversary of chunk proposals Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 6, 10:58am, Glenn Randers-Pehrson ARL-WMRD-TED-TIB wrote: > It's a year and a day since Todd French proposed the fALS, pCAL, and dRNG > chunks. sPLT has been around longer than that. We should take action to > register them. And hopefully it should take less time in future to register chunks. But perhaps we should measure from when a proposal is stable and mature, rather than from the time the first hazy what-if hits the list. > I propose that sPLT be moved into the png extensions document, and that > the following be added to the png extensions document, > in the section "Chunks Not Described Here". I agree with this. > I propose that we take no action now on the proposed aLIG, > fING, tSCL, and zSCL chunks. Because they are immature, or not a good idea, or what? -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 10:51:17 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA29104 for ; Fri, 6 Sep 1996 10:51:16 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA08926 for png-list-outgoing; Fri, 6 Sep 1996 10:51:44 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id KAA08920 for ; Fri, 6 Sep 1996 10:51:38 -0500 Date: Fri, 6 Sep 96 11:49:24 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Anniversary of chunk proposals Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609061149.aa17355@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List } }> I propose that we take no action now on the proposed aLIG, }> fING, tSCL, and zSCL chunks. } }Because they are immature, or not a good idea, or what? aLIG is (I think) immature. fING is maybe not needed as a chunk, although the algorithm described is useful. The problem with putting fING in the PNG stream is that it is easy to forge, and people might wind up deleting images that they didn't intend to, if they depended on a fING chunk supplied by someone else. For example, the moderator of alt.unusual_activity.bin might use fING chunks to weed out duplicates. Someone who doesn't approve of that sort of stuff posts a lot of blank transparent images and forges the fING chunks corresponding to the images he'd like to get rid of. tSCL and zSCL are for use with MNG, so there's no need to register them now. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 12:21:33 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA00950 for ; Fri, 6 Sep 1996 12:21:30 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA10451 for png-list-outgoing; Fri, 6 Sep 1996 12:21:01 -0500 Received: from u11.CS.Berkeley.EDU (u11.CS.Berkeley.EDU [128.32.38.135]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA10443 for ; Fri, 6 Sep 1996 12:20:57 -0500 Received: (from amc@localhost) by u11.CS.Berkeley.EDU (8.6.11/8.6.9) id KAA29669 for png-list@dworkin.wustl.edu; Fri, 6 Sep 1996 10:20:09 -0700 Date: Fri, 6 Sep 1996 10:20:09 -0700 Message-Id: <199609061720.KAA29669@u11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: Anniversary of chunk proposals X-Advice: should read soon From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson ARL-WMRD-TED-TIB says: > I propose that sPLT be moved into the png extensions document, and > that the following be added to the png extensions document, in the > section "Chunks Not Described Here". Do there exist implementations supporting these chunks? Have these chunks been used? If not, there might be problems or shortcomings that we won't find out about until people do start using them. Someone recently proposed that perhaps sPLT should include a gamma value. That sounds like a potentially good idea, but once we move it to the PNG Extensions document, it's too late. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 12:32:25 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA01086 for ; Fri, 6 Sep 1996 12:32:24 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA10689 for png-list-outgoing; Fri, 6 Sep 1996 12:32:58 -0500 Received: from mega.megamed.com (megamed.com [199.4.114.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA10684 for ; Fri, 6 Sep 1996 12:32:53 -0500 Received: from coruisk (mega217.megamed.com [199.4.114.217]) by mega.megamed.com (8.7.5/8.7.3) with SMTP id KAA29276 for ; Fri, 6 Sep 1996 10:32:05 -0700 Date: Fri, 6 Sep 1996 10:32:05 -0700 Message-Id: <199609061732.KAA29276@mega.megamed.com> X-Sender: jbowler@megamed.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: John Bowler Subject: Re: DOS/Win 32 software Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 14:34 06/09/96 +0200, Chris Lilley wrote: > >Interesting, I didn't know bmp could have that information. It's not the best documented format in the world. It was defined for Win95 as part of the color matching (ICM) technology. The entire Win32 SDK description follows (byte sex is little endian). John Bowler (jbowler@acm.org) The BITMAPV4HEADER structure contains information about a Win32 version 4.0 bitmap. typedef struct { DWORD bV4Size; LONG bV4Width; LONG bV4Height; WORD bV4Planes; WORD bV4BitCount; DWORD bV4V4Compression; DWORD bV4SizeImage; LONG bV4XPelsPerMeter; LONG bV4YPelsPerMeter; DWORD bV4ClrUsed; DWORD bV4ClrImportant; DWORD bV4RedMask; DWORD bV4GreenMask; DWORD bV4BlueMask; DWORD bV4AlphaMask; DWORD bV4CSType; CIEXYZTRIPLE bV4Endpoints; DWORD bV4GammaRed; DWORD bV4GammaGreen; DWORD bV4GammaBlue; } BITMAPV4HEADER, FAR *LPBITMAPV4HEADER, *PBITMAPV4HEADER; And a CIEXYZTRIPLE is:- The CIEXYZTRIPLE structure contains the x, y, and z coordinates of the three colors that correspond to the red, green, and blue endpoints for a specified logical color space. typedef struct tagCIEXYZTRIPLE { CIEXYZ ciexyzRed; CIEXYZ ciexyzGreen; CIEXYZ ciexyzBlue; } CIEXYZTRIPLE; typedef CIEXYZTRIPLE FAR* LPCIEXYZTRIPLE; Members ciexyzRed; xyz coordinates of red endpoint. ciexyzGreen xyz coordinates of green endpoint. ciexyzBlue xyz coordinates of blue endpoint. The CIEXYZ structure contains the x, y, and z coordinates of a specific color in a specified color space. typedef struct tagCIEXYZ { FXPT2DOT30 ciexyzX; FXPT2DOT30 ciexyzY; FXPT2DOT30 ciexyzZ; } CIEXYZ; typedef CIEXYZ FAR* LPCIEXYZ; Members ciexyzX x coordinate in fix point (2.30). ciexyzY y coordinate in fix point (2.30). ciexyzZ z coordinate in fix point (2.30). ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 13:05:47 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA01335 for ; Fri, 6 Sep 1996 13:05:47 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA11154 for png-list-outgoing; Fri, 6 Sep 1996 13:06:10 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id NAA11149 for ; Fri, 6 Sep 1996 13:06:06 -0500 Date: Fri, 6 Sep 96 14:02:56 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Anniversary of chunk proposals Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609061402.aa02979@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Fri, 6 Sep 1996 10:20:09 -0700 }Subject: Re: Anniversary of chunk proposals }From: "Adam M. Costello" }Glenn Randers-Pehrson ARL-WMRD-TED-TIB says: } }> I propose that sPLT be moved into the png extensions document, and }> that the following be added to the png extensions document, in the }> section "Chunks Not Described Here". } }Do there exist implementations supporting these chunks? Have these }chunks been used? If not, there might be problems or shortcomings that }we won't find out about until people do start using them. This is a Catch-22. The only implementations would be among ourselves because the chunks haven't been made public, and anyone else who does stumble across them is going to be scared off by the warnings about the formats not being stable.. I haven't done anything with sPLT because I don't need it on my equipment. I assume Dave M. will eventually try out lOGE... it's his chunk. It's difficult to see how anything could be wrong with xSCL and ySCL. I'm working on implementing pCAL, particularly with the new hyperbolic sine function (equation type 3). There might need to be some sort of warning added about making sure to protect against overflow. EXP(100.) will overflow 32-bit IEEE floating point arithmetic, and some operating systems or compilers might return garbage. I've implemented drNG. If you have an SGI at hand, look at the lena_d14.mng, which is way too red. Then apply drNG (viewpng can insert a drNG chunk in the incoming stream) and judge for yourself whether drNG is useful (lena_d14.mng is, of course, a sci-vis image). Type viewpng -j scratch1 -x 100 lena_d14.mng viewpng -j scratch2 -x 700 -drng 0 315 0 255 0 255 lena_d14.mng I assume this color correction could also have been done with the cHRM chunk, but, I'm sorry, the spec doesn't spell out how to work with cHRM well enough for me to understand. Given R, G, B in the file, sample bit depth cHRM data in the file file_gamma viewing_gamma, display_gamma display buffer bit depth cHRM data for my monitor How do I compute the R, G, B values to write to the display buffer? I want a nice cookbook explanation like what Dave provided for gamma correction. } }Someone recently proposed that perhaps sPLT should include a gamma }value. That sounds like a potentially good idea, but once we move it to }the PNG Extensions document, it's too late. That was for the MNG situation where you might have several images on the screen at once, with different gammas, and in the gPLT chunk. But maybe it is also a good idea for sPLT in PNG. Should I go ahead and add an assumed_gamma field in sPLT and gPLT? ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 13:19:07 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA01486 for ; Fri, 6 Sep 1996 13:19:06 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA11641 for png-list-outgoing; Fri, 6 Sep 1996 13:19:19 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA11635 for ; Fri, 6 Sep 1996 13:19:11 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.5/8.7.3) with ESMTP id LAA06591 for ; Fri, 6 Sep 1996 11:11:48 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.5/8.7.3) id LAA22832 for png-list@dworkin.wustl.edu; Fri, 6 Sep 1996 11:11:48 -0700 (PDT) Message-Id: <199609061811.LAA22832@web1.calweb.com> Subject: New Chunks To: png-list@dworkin.wustl.edu Date: Fri, 6 Sep 1996 11:11:48 -0700 (PDT) From: "Lee Daniel Crocker" Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Re new and proposed PNG chunks: unless there are existing, running, useful applications that make use of the proposed chunks, I feel it is dangerous to standardize them. Register them as private, sure, but not public without /serious/ testing and experience, unless the need for them is obvious, immediate, and there is little argument. As I recall, many of these proposed chunks faced serious arguments. -- Lee Daniel Crocker ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 13:19:23 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA01503 for ; Fri, 6 Sep 1996 13:19:20 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA11659 for png-list-outgoing; Fri, 6 Sep 1996 13:19:48 -0500 Received: from u11.CS.Berkeley.EDU (u11.CS.Berkeley.EDU [128.32.38.135]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA11653 for ; Fri, 6 Sep 1996 13:19:45 -0500 Received: (from amc@localhost) by u11.CS.Berkeley.EDU (8.6.11/8.6.9) id LAA00246; Fri, 6 Sep 1996 11:19:00 -0700 Date: Fri, 6 Sep 1996 11:19:00 -0700 Message-Id: <199609061819.LAA00246@u11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: Anniversary of chunk proposals X-Advice: should read soon From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson ARL-WMRD-TED-TIB says: > But maybe it is also a good idea for sPLT in PNG. Should I go ahead > and add an assumed_gamma field in sPLT and gPLT? I think so. Can anyone think of any problems with that? But don't call it "assumed_gamma". It's not assuming anything; it's *telling* the decoder what the gamma value is for the palette entries, exactly as gAMA tells the decoder the gamma value for PLTE entries. I'd call the field simply "gamma". AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 13:38:40 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA01757 for ; Fri, 6 Sep 1996 13:38:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA12284 for png-list-outgoing; Fri, 6 Sep 1996 13:38:12 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA12273 for ; Fri, 6 Sep 1996 13:38:00 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.5/8.7.3) with ESMTP id LAA09766 for ; Fri, 6 Sep 1996 11:30:33 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.5/8.7.3) id LAA00450 for png-list@dworkin.wustl.edu; Fri, 6 Sep 1996 11:30:32 -0700 (PDT) Message-Id: <199609061830.LAA00450@web1.calweb.com> Subject: Re: Anniversary of chunk proposals To: png-list@dworkin.wustl.edu Date: Fri, 6 Sep 1996 11:30:32 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <9609061402.aa02979@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 6, 96 02:02:56 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > This is a Catch-22. The only implementations would be among ourselves > because the chunks haven't been made public, and anyone else who does > stumble across them is going to be scared off by the warnings about > the formats not being stable.. If no one needs it badly enough to implement it before the standard is stable, then it has no business being standardized. -- Lee Daniel Crocker ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 14:12:25 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA02035 for ; Fri, 6 Sep 1996 14:12:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA12922 for png-list-outgoing; Fri, 6 Sep 1996 14:12:32 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA12914 for ; Fri, 6 Sep 1996 14:12:26 -0500 Date: Fri, 6 Sep 96 15:08:09 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New Chunks Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609061508.aa05217@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Subject: New Chunks }Date: Fri, 6 Sep 1996 11:11:48 -0700 (PDT) }From: Lee Daniel Crocker }Re new and proposed PNG chunks: unless there are existing, running, }useful applications that make use of the proposed chunks, I feel it }is dangerous to standardize them. Register them as private, sure, What is the mechanism for "Registering as private?" }but not public without /serious/ testing and experience, unless the }need for them is obvious, immediate, and there is little argument. }As I recall, many of these proposed chunks faced serious arguments. There was a pretty thorough discussion of all of these chunks and we seemed to come up with satisfactory descriptions. I recall that they were denounced by the "no new chunks" contingent and I don't expect that to change. I don't think any new chunk could meet the criteria you list, because the testing just won't happen within this group, and no one else is going to work with them until they are finished. And they are all going to face serious arguments from some members of this group. Todd, did you ever implement fALS, pCAL, and dRNG? Dave, did you ever implement lOGE? Or are we all waiting for Guy to do it? As I said, I am working with pCAL. The only problem I had with it was that the log equations wouldn't work with negative numbers, hence the hyperbolic equation type 3. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 14:13:10 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA02043 for ; Fri, 6 Sep 1996 14:13:05 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA12939 for png-list-outgoing; Fri, 6 Sep 1996 14:13:45 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA12933 for ; Fri, 6 Sep 1996 14:13:39 -0500 Date: Fri, 6 Sep 96 15:11:52 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Anniversary of chunk proposals Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609061511.aa05765@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Fri, 6 Sep 1996 11:19:00 -0700 }Subject: Re: Anniversary of chunk proposals }From: "Adam M. Costello" }Glenn Randers-Pehrson ARL-WMRD-TED-TIB says: } }> But maybe it is also a good idea for sPLT in PNG. Should I go ahead }> and add an assumed_gamma field in sPLT and gPLT? } }I think so. Can anyone think of any problems with that? } }But don't call it "assumed_gamma". It's not assuming anything; it's }*telling* the decoder what the gamma value is for the palette entries, }exactly as gAMA tells the decoder the gamma value for PLTE entries. I'd }call the field simply "gamma". OK We need to have some words explaining what the decoder is supposed to do when the sPLT gamma and the image gamma are different. (One thing it can do is just look for another sPLT chunk that has a better gamma) ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 14:23:36 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA02235 for ; Fri, 6 Sep 1996 14:23:34 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA13110 for png-list-outgoing; Fri, 6 Sep 1996 14:24:06 -0500 Received: from u11.CS.Berkeley.EDU (u11.CS.Berkeley.EDU [128.32.38.135]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA13100 for ; Fri, 6 Sep 1996 14:23:59 -0500 Received: (from amc@localhost) by u11.CS.Berkeley.EDU (8.6.11/8.6.9) id MAA00555 for png-list@dworkin.wustl.edu; Fri, 6 Sep 1996 12:23:15 -0700 Date: Fri, 6 Sep 1996 12:23:15 -0700 Message-Id: <199609061923.MAA00555@u11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: Anniversary of chunk proposals X-Advice: perhaps read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson ARL-WMRD-TED-TIB says: > We need to have some words explaining what the decoder is supposed to > do when the sPLT gamma and the image gamma are different. (One thing > it can do is just look for another sPLT chunk that has a better gamma) It must simply remember that the gamma value that tells how to interpret sample values in PLTE or IDAT is not the same gamma value that tells how to interpret sample values in sPLT. If it's mapping pixel values to their nearest neighbors in the palette, it will probably want to convert the pixels or the palette entries (or both) to a common representation for doing the comparison. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 14:29:18 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA02311 for ; Fri, 6 Sep 1996 14:29:18 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA13168 for png-list-outgoing; Fri, 6 Sep 1996 14:29:44 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA13159 for ; Fri, 6 Sep 1996 14:29:39 -0500 Received: by grommit.inria.fr (8.7.5/8.6.12) id VAA16114 for png-list@dworkin.wustl.edu; Fri, 6 Sep 1996 21:28:54 +0200 (DST) Date: Fri, 6 Sep 1996 21:28:54 +0200 (DST) From: Chris Lilley Message-Id: <9609062128.ZM16112@grommit.inria.fr> In-Reply-To: John Bowler "Re: DOS/Win 32 software" (Sep 6, 10:32am) References: <199609061732.KAA29276@mega.megamed.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: DOS/Win 32 software Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 6, 10:32am, John Bowler wrote: > >Interesting, I didn't know bmp could have that information. > > It's not the best documented format in the world. [...] > description follows [...] Thanks for this info, much appreciated. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 14:56:56 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA02748 for ; Fri, 6 Sep 1996 14:56:48 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA13561 for png-list-outgoing; Fri, 6 Sep 1996 14:55:21 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA13553 for ; Fri, 6 Sep 1996 14:55:08 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.5/8.7.3) with ESMTP id MAA21232 for ; Fri, 6 Sep 1996 12:47:45 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.5/8.7.3) id MAA02218 for png-list@dworkin.wustl.edu; Fri, 6 Sep 1996 12:47:45 -0700 (PDT) Message-Id: <199609061947.MAA02218@web1.calweb.com> Subject: Re: New Chunks To: png-list@dworkin.wustl.edu Date: Fri, 6 Sep 1996 12:47:45 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <9609061508.aa05217@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 6, 96 03:08:09 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > I don't think any new chunk could meet the criteria you list, because > the testing just won't happen within this group, and no one else is > going to work with them until they are finished. And they are all > going to face serious arguments from some members of this group. Then they don't belong in a standard. If we need to create some mechanism of publishing "working drafts" and "proposed standards" like a real standards body, then let's do that. If we need a faster mechanism for registering private chunks, then let's do that. But let's not screw up a good standard just because we don't have the mechanisms in place to do it right. Let's fix the mechanisms. Most of the proposed chunks are pretty benign, (except for dRNG, which is completely antithetical to the very purpose of PNG and should have every piece of paper on which it appears ceremonially burned--but I digress :), but that doesn't mean we should clutter a good spec with benign fluff just because no one objects. To become standard, these chunks need to prove themselves in the real world. If no one is going to implement them, then publish them as proposals and be done with it. Some years from now, when someone desperately needs one of those functions, he'll see a way to do it, implement it, and start using it. If it works well, /then/ we make it a real standard. -- Lee Daniel Crocker ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 14:57:42 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA02822 for ; Fri, 6 Sep 1996 14:57:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA13620 for png-list-outgoing; Fri, 6 Sep 1996 14:56:59 -0500 Received: from natashya.eden.com (natashya.eden.com [199.171.21.14]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA13605 for ; Fri, 6 Sep 1996 14:56:54 -0500 Received: from cpic (net-4-129.austin.eden.com [206.81.226.129]) by natashya.eden.com (8.7.4.1/8.7.1.1) with SMTP id OAA17101 for ; Fri, 6 Sep 1996 14:56:02 -0500 (CDT) Date: Fri, 6 Sep 1996 14:56:02 -0500 (CDT) Message-Id: <199609061956.OAA17101@natashya.eden.com> X-Sender: pschmidt@mail.eden.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: pschmidt@photodex.com (Paul Schmidt) Subject: Re: DOS/Win 32 software Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >At 14:34 06/09/96 +0200, Chris Lilley wrote: >> >>Interesting, I didn't know bmp could have that information. > >It's not the best documented format in the world. It was defined for Win95 >as part of the color matching (ICM) technology. The entire Win32 SDK >description follows (byte sex is little endian). > >John Bowler (jbowler@acm.org) ... Does anyone have any of these CIE BMP files laying around for reference purposes? Best Regards, Paul Schmidt ---------------------------------------------------------- Photodex Corporation Service GO/Keyword E-Mail 1106 Clayton Lane #200W AOL: Photodex Photodex Austin, TX 78723 CIS: Photodex 74774,3635 (512)406-3020 Voice (512)452-6825 Fax i'net: pschmidt@photodex.com "I play with dots... WWW: http://www.photodex.com ...lots of dots." FTP: ftp.photodex.com ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 15:38:26 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA03514 for ; Fri, 6 Sep 1996 15:38:24 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA14500 for png-list-outgoing; Fri, 6 Sep 1996 15:37:30 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id PAA14495 for ; Fri, 6 Sep 1996 15:37:23 -0500 Date: Fri, 6 Sep 96 16:35:57 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New Chunks Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609061635.aa08224@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Subject: Re: New Chunks }Date: Fri, 6 Sep 1996 12:47:45 -0700 (PDT) }From: Lee Daniel Crocker }> I don't think any new chunk could meet the criteria you list, because }> the testing just won't happen within this group, and no one else is }> going to work with them until they are finished. And they are all }> going to face serious arguments from some members of this group. } }Then they don't belong in a standard. If we need to create some }mechanism of publishing "working drafts" and "proposed standards" }like a real standards body, then let's do that. If we need a }faster mechanism for registering private chunks, then let's do }that. I think the problem is that we don't have *any* mechanism for registering private chunks. What I have proposed is to not mention them at all in the core spec, and only to mention their names with the briefest of descriptions in the extensions document. Like the fRAc chunk. I can't think of any other way of registering private chunks. Except maybe to add to the "chunks not described here" section in the extensions document, a paragraph that says "other registered chunks that are neither described here nor named here are listed, but not described, in the document ftp://... and in that document just put the name of the chunk and an e-mail address where people can seek further information. That ought to bury them sufficiently deep. }But let's not screw up a good standard just because we don't }have the mechanisms in place to do it right. Let's fix the }mechanisms. I am not proposing to touch the standard. }Most of the proposed chunks are pretty benign, (except for dRNG, which }is completely antithetical to the very purpose of PNG and should have }every piece of paper on which it appears ceremonially burned--but I }digress :), }but that doesn't mean we should clutter a good spec with }benign fluff just because no one objects. To become standard, these }chunks need to prove themselves in the real world. If no one is }going to implement them, then publish them as proposals and be done }with it. Some years from now, when someone desperately needs one of }those functions, he'll see a way to do it, implement it, and start }using it. If it works well, /then/ we make it a real standard. } }-- }Lee Daniel Crocker Thanks... ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 16:06:29 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA03736 for ; Fri, 6 Sep 1996 16:06:28 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA15071 for png-list-outgoing; Fri, 6 Sep 1996 16:05:19 -0500 Received: from mercury.ukc.ac.uk (mercury.ukc.ac.uk [129.12.21.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id QAA15060 for ; Fri, 6 Sep 1996 16:05:14 -0500 Received: from mint.ukc.ac.uk by mercury.ukc.ac.uk with SMTP (PP); Fri, 6 Sep 1996 21:53:57 +0100 Received: from localhost (localhost.ukc.ac.uk) by mint.ukc.ac.uk (4.1/UKC-2.14) id AA23726; Fri, 6 Sep 96 21:53:55 BST To: PNG List Subject: Re: Anniversary of chunk proposals In-Reply-To: Your message of "Fri, 06 Sep 1996 10:58:13 EDT." <9609061058.aa14047@THOR.ARL.MIL> Date: Fri, 06 Sep 1996 21:53:54 +0100 Message-Id: <23725.842043234@mint.ukc.ac.uk> From: Dave Beckett Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I've had a student of mine evaluating some of the PNG chunk proposals and it seems appropriate to mention them now: - fING : Fingerprint - fALS : False colour palette I don't have his final report yet (due next week) but I can summarize from memory what he reports. fiNG ---- An spec with an ambiguous part. It is unclear how to expand the pixels to a common format. The PNG library doesn't support the appropriate Left-Bit Replication needed to 16bits and both pngfprint and my student both get wrong e.g. if original image is 5-bits deep: 43210 ----- 11011 then, according to the spec, it should be LBR'd to 16 bits: 76543210 76543210 -------- -------- 11011110 11110111 but libpng used with png_expand converts 11011 -> 11011110 and the second byte (the same value) is very wrong. Due to the confusion, his program and pngfprint don't agree on CRCs (but of course, there could be bugs in the way too). The Adler-32 CRC seems fine. But hey, why not have two bits of CRC code in the library? He also recommends that the fiNG chunk is placed before IDAT so that the main body of the png image file doesn't need to be read and skipped to get the fingerprint. Personally, I'm not convinced that fiNG is that useful except for a few specialised applications - image libraries who probably are doing their own thing. fALS ---- A success. It is easy to support, useful and orthogonal to the existing facilities. There don't seem to be any standard false colour palettes in use - too domain specific I guess. Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 16:24:22 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA03848 for ; Fri, 6 Sep 1996 16:24:17 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA15541 for png-list-outgoing; Fri, 6 Sep 1996 16:23:07 -0500 Received: from enel.ucalgary.ca ([136.159.99.2]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA15536 for ; Fri, 6 Sep 1996 16:23:02 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id PAA21037; Fri, 6 Sep 1996 15:22:03 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609062122.PAA21037@enel.ucalgary.ca> Subject: Re: New Chunks To: png-list@dworkin.wustl.edu Date: Fri, 6 Sep 1996 15:22:02 -0600 (MDT) In-Reply-To: <199609061947.MAA02218@web1.calweb.com> from "Lee Daniel Crocker" at Sep 6, 96 12:47:45 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Lee writes: > Most of the proposed chunks are pretty benign, (except for dRNG, which > is completely antithetical to the very purpose of PNG and should have > every piece of paper on which it appears ceremonially burned--but I > digress :) I've wanted to use dRNG, and pCAL for some time, but never have because they were only drafts. dRNG (or maybe DRNG) to be used by POV output to allow a user to record "whiter-than-white" and possibly negative output values, rather than clipping them to [0,255]. With a viewer that supported it, the user could then shift the clipping range and get the right light intensities, rather than re-rendering the whole image again. With ray tracing it's really a shot in the dark (pun intended) to get the lighting correct without a lot of (slow) iterations. I think Rayshade or Radiance even has a proprietary 32-bit FP format to do just this. As for pCAL, I want to use it when converting USGS DEM heightfields into 16-bit grayscale PNGs, for about a 90% space savings, but keep track of the physical representation. My point is that I haven't done this because the chunks were subject to change, and there's no hope of anything using them unless they become "standard". Cheers, Andreas. PS - I'm away for the next 2 weeks. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 16:47:12 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA04006 for ; Fri, 6 Sep 1996 16:47:11 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA15805 for png-list-outgoing; Fri, 6 Sep 1996 16:47:39 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id QAA15800 for ; Fri, 6 Sep 1996 16:47:36 -0500 Date: Fri, 6 Sep 96 17:43:41 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Anniversary of chunk proposals Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609061743.aa12221@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Subject: Re: Anniversary of chunk proposals }Date: Fri, 06 Sep 1996 21:53:54 +0100 }From: Dave Beckett } }I've had a student of mine evaluating some of the PNG chunk proposals }and it seems appropriate to mention them now: } }- fING : Fingerprint }- fALS : False colour palette } }I don't have his final report yet (due next week) but I can summarize }from memory what he reports. } }fiNG }---- }An spec with an ambiguous part. It is unclear how to expand }the pixels to a common format. The PNG library doesn't support the }appropriate Left-Bit Replication needed to 16bits and }both pngfprint and my student both get wrong }e.g. if original image is 5-bits deep: } } 43210 } ----- } 11011 } }then, according to the spec, it should be LBR'd to 16 bits: } } 76543210 76543210 } -------- -------- } 11011110 11110111 For display, yes, but that has nothing to do with fiNG. } }but libpng used with png_expand converts 11011 -> 11011110 and the }second byte (the same value) is very wrong. Due to the confusion, }his program and pngfprint don't agree on CRCs (but of course, there }could be bugs in the way too). The fiNG proposal says to do the LBR scaling without regard to sBIT, if present. So if your original image is 5-bits deep, and you have stored it in an 8-bit format, it should have been LBR-scaled to 11011110. Then when you do the fING calculation you LBR-scale the 8-bits to 16 and get 11011110 11011110. Where is the ambiguity? } }The Adler-32 CRC seems fine. But hey, why not have two bits of CRC }code in the library? } }He also recommends that the fiNG chunk is placed before IDAT so that }the main body of the png image file doesn't need to be read and }skipped to get the fingerprint. It says that in the proposed spec. } }Personally, I'm not convinced that fiNG is that useful except for a }few specialised applications - image libraries who probably are doing }their own thing. True, and as I have said, people can be dangerously misled. They read that the MD5 fingerprint is virtually unforgeable and forget that someone can just type in a phony one that doesn't match the image data. } }fALS }---- }A success. It is easy to support, useful and orthogonal to the }existing facilities. There don't seem to be any standard false }colour palettes in use - too domain specific I guess. } }Dave } }------------------------------------------------------------ }To find out more about the mailing list server, send mail to }png-list-request@dworkin.wustl.edu }with the word "help" (and nothing else) in the message body. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 16:49:20 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA04035 for ; Fri, 6 Sep 1996 16:49:18 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA15836 for png-list-outgoing; Fri, 6 Sep 1996 16:49:59 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA15830 for ; Fri, 6 Sep 1996 16:49:49 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.5/8.7.3) with ESMTP id OAA13121 for ; Fri, 6 Sep 1996 14:42:32 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.5/8.7.3) id OAA01226 for png-list@dworkin.wustl.edu; Fri, 6 Sep 1996 14:42:31 -0700 (PDT) Message-Id: <199609062142.OAA01226@web1.calweb.com> Subject: Re: New Chunks To: png-list@dworkin.wustl.edu Date: Fri, 6 Sep 1996 14:42:30 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <199609062122.PAA21037@enel.ucalgary.ca> from "Andreas Dilger" at Sep 6, 96 03:22:02 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > [Uses for proposed chunks] > > My point is that I haven't done this because the chunks were subject to > change, and there's no hope of anything using them unless they become > "standard". Implementing "officially proposed" standards is a noble effort, and the risk of doing that is, in part, a measure of the value of the proposal. If you'd rather live without it than risk making some minor change that the experience of implementing it may reveal to be necessary, then that fact alone says volumes about the value of the proposal. The alternative to implementing an official proposal is to implement needed functionality in a private unofficial way. But doesn't that also risk that the official standard may eventually do something incompatible with your private chunk? You either need the feature or you don't. If you really need it, you do it privately, or you do it in a way that supports the evolving standard. Either way, the risks to you are the same; but they are far less than the risks to every other user of the standard of freezing untested extensions. -- Lee Daniel Crocker ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 17:02:53 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id RAA04190 for ; Fri, 6 Sep 1996 17:02:53 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA15950 for png-list-outgoing; Fri, 6 Sep 1996 17:02:57 -0500 Received: from u11.CS.Berkeley.EDU (u11.CS.Berkeley.EDU [128.32.38.135]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA15945 for ; Fri, 6 Sep 1996 17:02:53 -0500 Received: (from amc@localhost) by u11.CS.Berkeley.EDU (8.6.11/8.6.9) id PAA01108 for png-list@dworkin.wustl.edu; Fri, 6 Sep 1996 15:02:08 -0700 Date: Fri, 6 Sep 1996 15:02:08 -0700 Message-Id: <199609062202.PAA01108@u11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: New Chunks X-Advice: perhaps read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List adilger@enel.ucalgary.ca (Andreas Dilger) says: > My point is that I haven't done this because the chunks were subject > to change, and there's no hope of anything using them unless they > become "standard". I sure wish the HTML community had attitudes a tad closer to this. :) AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 17:49:45 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id RAA04780 for ; Fri, 6 Sep 1996 17:49:44 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA16447 for png-list-outgoing; Fri, 6 Sep 1996 17:48:42 -0500 Received: from mathtype.com ([206.183.220.144]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA16442 for ; Fri, 6 Sep 1996 17:48:38 -0500 Received: from [206.183.220.130] by mathtype.com with ESMTP (Apple Internet Mail Server 1.1); Fri, 6 Sep 1996 15:45:30 -0800 X-Sender: jimk@pop.mathtype.com Message-Id: In-Reply-To: <199609061811.LAA22832@web1.calweb.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Sep 1996 15:41:51 -0800 To: PNG List From: Jim King Subject: Re: New Chunks Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 10:11 AM -0800 9/6/96, Lee Daniel Crocker wrote: >Re new and proposed PNG chunks: unless there are existing, running, >useful applications that make use of the proposed chunks, I feel it >is dangerous to standardize them. I have a real problem with this. While I understand the need to make sure solutions work before putting them in a standard, that's what design is for, and catching the flaws is what comittees like this are=EE for. What the above statement tells me as a commecial software devloper is: "Don't bother with standards. Just implement propriatary solutions and propose them later to standards groups." I guess that's one reason you see exactly this happening so much these days. I'm certainly not going to implement any standard that is subject to change. It would cost me too much money (and too many customers). So where are you going to get the testbeds for new chunks? I guess what I'm really saying is that if chunks won't be approved unless there are working applications that use them, and commercial application developers won't write apps to use chunks unless they are already approved, the whole idea of an extensible format has been a waste of time. What we've got here is a catch22 where nothing new will be added because nothing new has been added. I'm not an expert at photo-quality graphics (which is why I've silently read most of the proceedings here for the past year or so), but I do know how they end up used quite often, and it seems to me that many of these chunks are worth having. Let's hack out the design problems and get them in SOME standards document (probably other than the actual PNG spec itself) so that people will start using them. Jim King Product Manager jimk@mathtype.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Design Science, Inc. Sales: sales@mathtype.com 4028 Broadway Support: support@mathtype.com Long Beach, CA 90803 USA World Wide Web: voice: 310-433-0685 http://www.mathtype.com fax: 310-433-6969 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 17:57:52 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id RAA04831 for ; Fri, 6 Sep 1996 17:57:51 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA16518 for png-list-outgoing; Fri, 6 Sep 1996 17:57:11 -0500 Received: from mathtype.com ([206.183.220.144]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA16513 for ; Fri, 6 Sep 1996 17:57:07 -0500 Received: from [206.183.220.130] by mathtype.com with ESMTP (Apple Internet Mail Server 1.1); Fri, 6 Sep 1996 15:54:01 -0800 X-Sender: jimk@pop.mathtype.com Message-Id: In-Reply-To: <9609061149.aa17355@THOR.ARL.MIL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Sep 1996 15:53:51 -0800 To: PNG List From: Jim King Subject: Re: Anniversary of chunk proposals Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 7:49 AM -0800 9/6/96, Glenn Randers-Pehrson ARL-WMRD-TED-TIB wrote: >} >}> I propose that we take no action now on the proposed aLIG, >}> fING, tSCL, and zSCL chunks. >} >}Because they are immature, or not a good idea, or what? > >aLIG is (I think) immature. What about it is immature? If it needs more changes, let's make them and get it done. If you are referring to implimentation issues, you should be aware that Design Science has been using our original proposed version of this chunk (which this list improved quite a bit to make aLIG) for over seven years in Widnows Metafiles, PICT images and EPS files. The difference there is that we have to put the data chunk in comments with those formats because those image formats are not extendable as PNG is. On the display end, the data is read out and used by Microsoft Word, WordPerfect, NisusWriter, DeltaGraph, Ventura Publisher, ClarisWorks and many other existing commercial applications. All aLIG is proposing is that we use the obvious advantages of the extendable PNG design to add the same data to the image in a more 'correct' fashion. The only opposition I've seen to this chunk in the past year is from people saying "No one wants such data in an image". I think I've listed six companies above that wanted such data enough to accept some hack of existing data formats (i.e. sticking a data stucture into a picture comment) that we created and sent them. Jim King Product Manager jimk@mathtype.com ================================================================== Design Science, Inc. Sales: sales@mathtype.com 4028 Broadway Support: support@mathtype.com Long Beach, CA 90803 USA World Wide Web: voice: 310-433-0685 http://www.mathtype.com fax: 310-433-6969 ================================================================== ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 18:18:45 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA04947 for ; Fri, 6 Sep 1996 18:18:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA16785 for png-list-outgoing; Fri, 6 Sep 1996 18:17:51 -0500 Received: from u11.CS.Berkeley.EDU (u11.CS.Berkeley.EDU [128.32.38.135]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA16780 for ; Fri, 6 Sep 1996 18:17:47 -0500 Received: (from amc@localhost) by u11.CS.Berkeley.EDU (8.6.11/8.6.9) id QAA01436 for png-list@dworkin.wustl.edu; Fri, 6 Sep 1996 16:17:02 -0700 Date: Fri, 6 Sep 1996 16:17:02 -0700 Message-Id: <199609062317.QAA01436@u11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: Anniversary of chunk proposals X-Advice: perhaps read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Jim King says: > What about it is immature? If it needs more changes, let's make them > and get it done. Three of the default values aren't quite specified: center = width/2 middle = height/2 baseline = 3/4 * height The fields are integers. Does "/" mean integer division? Nope, because then baseline is zero. So it must mean floating-point division, in which case the "=" contains an implicit round() or trunc(), but which is it? I suggest we specify integer division, then say: center = width / 2 middle = height / 2 baseline = (3 * height + 1) / 4 AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 18:31:22 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA05008 for ; Fri, 6 Sep 1996 18:31:19 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA16951 for png-list-outgoing; Fri, 6 Sep 1996 18:30:38 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA16946 for ; Fri, 6 Sep 1996 18:30:33 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id TAA06877 for ; Fri, 6 Sep 1996 19:29:47 -0400 (EDT) To: PNG List Subject: Re: New Chunks In-reply-to: Your message of Fri, 6 Sep 1996 15:41:51 -0800 Date: Fri, 06 Sep 1996 19:29:47 -0400 Message-ID: <6875.842052587@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Jim King writes: > What the above statement tells me as a commecial software devloper is: > "Don't bother with standards. Just implement propriatary solutions and > propose them later to standards groups." I guess that's one reason you see > exactly this happening so much these days. I'm certainly not going to > implement any standard that is subject to change. I think both sides of this debate have a point. Jim's quite right that commercial developers can't ship products that depend on un-frozen chunks. And some of us who are (I think) just private individuals have also said that they wouldn't bother to use a chunk until it was frozen. It makes sense: if you test a chunk using a private chunk name for it, then your software and files *will* need to change when/if the chunk is approved and renamed to a public name. However, Lee is very right that a chunk that's strictly at the "thought experiment" stage is risky to put into the spec. It would be nice to see *some* proponent(s) of a new chunk willing to invest some extra effort in demonstrating that the chunk doesn't have any serious problems. > Let's hack out the design problems and get them in SOME standards document "Hack" was exactly the wrong word to use here ;-). It makes Lee's point for him, wouldn't you say? Ultimately I think we will have to take comfort in the fact that extension chunks don't have to be perfect. If (say) we define sPLT without a gamma field, and later someone comes along and convinces people that a gamma field would be helpful, we can always put in a new chunk type with a new name and recommend that encoders store both chunk types for backwards compatibility. Ugly, but I'm sure there will be cases like that eventually. I would say that if there's any serious doubt about a proposed chunk, we should expect the proponents to do a test implementation. If the consensus on the list is that the chunk won't cause any problems, and there's at least some evidence for its utility, then I wouldn't object to approving it without a test implementation. (Especially so for extension chunks. Putting something new into the main spec has a much higher bar to jump over, IMHO. If we ever do revise the main spec, I would argue that only stuff that has been on the extension list for a while should be considered for moving into the main spec.) The lack of action on the existing proposals has got more to do with inertia and burnout than with any actual anti-new-chunk bias, I think. We should get off our duffs and do something about the proposals. Glenn's got the right idea in trying to push things to closure. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 19:25:59 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA05222 for ; Fri, 6 Sep 1996 19:25:58 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA17484 for png-list-outgoing; Fri, 6 Sep 1996 19:26:31 -0500 Received: from mathtype.com ([206.183.220.144]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA17473 for ; Fri, 6 Sep 1996 19:26:26 -0500 Received: from [206.183.220.130] by mathtype.com with ESMTP (Apple Internet Mail Server 1.1); Fri, 6 Sep 1996 17:22:49 -0800 X-Sender: jimk@pop.mathtype.com Message-Id: In-Reply-To: <6875.842052587@sss.pgh.pa.us> References: Your message of Fri, 6 Sep 1996 15:41:51 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Sep 1996 17:22:39 -0800 To: PNG List From: Jim King Subject: Re: New Chunks Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 3:29 PM -0800 9/6/96, Tom Lane wrote: >However, Lee is very right that a chunk that's strictly at the "thought >experiment" stage is risky to put into the spec. It would be nice to see >*some* proponent(s) of a new chunk willing to invest some extra effort in >demonstrating that the chunk doesn't have any serious problems. I agree. If a chunk has opposition, the proponent should at least be willing to answer that opposition and show that the disputed things are not problems (or find better ways to do them) or they obviously didn't want it enough. >> Let's hack out the design problems and get them in SOME standards document >"Hack" was exactly the wrong word to use here ;-). It makes Lee's point >for him, wouldn't you say? :} Bad choice of words! >I would say that if there's any serious doubt about a proposed chunk, >we should expect the proponents to do a test implementation. If the >consensus on the list is that the chunk won't cause any problems, and >there's at least some evidence for its utility, then I wouldn't object >to approving it without a test implementation. (Especially so for >extension chunks. Putting something new into the main spec has a much >higher bar to jump over, IMHO. If we ever do revise the main spec, >I would argue that only stuff that has been on the extension list for a >while should be considered for moving into the main spec.) I agree completely with this. A three tiered system makes a lot of sense, and I think we already have this. The problem is defining how things move between the tiers. The PNG Spec should be the hardest to get into, requiring that a chunk have been used and implemented successfully for some time to be considered when (if) the spec is revised. The PNG Special-Purpose Public Chunks document should be easier to get something into, requiring only that the PNG list think the chunk is somewhat useful and that it won't cause any problems (as you say above). This gives new chunks the opportunity to be official before they get into software (thus giving them the chance to get into software!) The PNG Proposed Chunks document should be very easy to get things into, being that it is simply a base for discussion before moving the item to tier 2 when it seems OK. >The lack of action on the existing proposals has got more to do with >inertia and burnout than with any actual anti-new-chunk bias, I think. Certainly. I only wrote because I was hearing rumblings of people who wanted to apply the same standards I stated above for the PNG spec to the Public Chunks document. I hope that is not the case, as it would put a big roadblock in the way for taking advantage of PNG's inherant expandibility. Jim King Product Manager jimk@mathtype.com ================================================================== Design Science, Inc. Sales: sales@mathtype.com 4028 Broadway Support: support@mathtype.com Long Beach, CA 90803 USA World Wide Web: voice: 310-433-0685 http://www.mathtype.com fax: 310-433-6969 ================================================================== ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 19:26:02 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA05229 for ; Fri, 6 Sep 1996 19:26:01 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA17483 for png-list-outgoing; Fri, 6 Sep 1996 19:26:30 -0500 Received: from mathtype.com ([206.183.220.144]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA17472 for ; Fri, 6 Sep 1996 19:26:26 -0500 Received: from [206.183.220.130] by mathtype.com with ESMTP (Apple Internet Mail Server 1.1); Fri, 6 Sep 1996 17:22:46 -0800 X-Sender: jimk@pop.mathtype.com Message-Id: In-Reply-To: <199609062317.QAA01436@u11.CS.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Sep 1996 16:52:48 -0800 To: PNG List From: Jim King Subject: Re: Anniversary of chunk proposals Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 3:17 PM -0800 9/6/96, Adam M. Costello wrote: >Three of the default values aren't quite specified: > >center =3D width/2 >middle =3D height/2 >baseline =3D 3/4 * height > >The fields are integers. Does "/" mean integer division? Nope, because >then baseline is zero. So it must mean floating-point division, in >which case the "=3D" contains an implicit round() or trunc(), but which is >it? In a way it's probably unimportant since these are not part of the data but simply suggestions to the reader as to how to make up for the lack of data. One pixel different in either direction for an image that wasn't created with this data anyway won't matter that much. But for consistancy's sake, I guess we should define it. >I suggest we specify integer division, then say: > >center =3D width / 2 >middle =3D height / 2 >baseline =3D (3 * height + 1) / 4=EE Sounds good to me. Except, why do we want the baseline default to be 3/4 of the height? It seems to me that if someone doesn't specify a baseline, then that image has no concept of baseline. In that case the bottom of the image should usually line up with the baseline of text, so it would be baseline =3D height as the default. Is there a particular reason for the (3/4 of height)? Seems to me to be an attempt at a guess where you probably don't want a guess. Jim King Product Manager jimk@mathtype.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Design Science, Inc. Sales: sales@mathtype.com 4028 Broadway Support: support@mathtype.com Long Beach, CA 90803 USA World Wide Web: voice: 310-433-0685 http://www.mathtype.com fax: 310-433-6969 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 6 20:44:18 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA05446 for ; Fri, 6 Sep 1996 20:44:18 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA18126 for png-list-outgoing; Fri, 6 Sep 1996 20:44:35 -0500 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id UAA18120 for ; Fri, 6 Sep 1996 20:44:32 -0500 Received: by mail2.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24) id <01BB9C21.E7875340@mail2.microsoft.com>; Fri, 6 Sep 1996 18:33:31 -0700 Message-ID: From: John Bowler To: "'PNG List'" Subject: RE: DOS/Win 32 software Date: Fri, 6 Sep 1996 18:32:37 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Encoding: 39 TEXT, 74 UUENCODE X-MS-Attachment: basi2c16.bv4 0 00-00-1980 00:00 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >From: pschmidt@photodex.com[SMTP:pschmidt@photodex.com] > >Does anyone have any of these CIE BMP files laying around for reference >purposes? It seems very unlikely... The format is also documented in Graphics File Formats (second edition) by James D. Murray and William VanRyper (O'Reilly) but any app which is using the Win95 ICM is probably just generating the format internally (and passing it to the color match APIs) simply because there are very few if any apps which can read the format. The attached file is basi2c16.png converted to BMP by HiJaak 95 then hacked into the V4 format:- >bmpcheck basi2c16.bv4 FILE: basi2c16.bv4 3194 bytes file size: 3194 reserved1: 0 reserved2: 0 image offset: 122 BITMAPV4 (Win32 BMP) Image size: 32x32 1 planes, 24 bpp BI_RGB (no compression) 0 image size, 11806x11806 pixels per metre 0 colors used, 0 colors important Masks: red 0x00000000 green 0x00000000 blue 0x00000000 alpha 0x00000000 CSType: 0 Gamma: red 0x00007333 green 0x00007333 blue 0x00007333 CIE Red XYZ: 0.640000, 0.330000, 0.030000 CIE Green XYZ: 0.300000, 0.600000, 0.100000 CIE Blue XYZ: 0.150000, 0.060000, 0.790000 The CIE end points are the HDTV/Rec 709 ones (I hope). John Bowler begin 600 basi2c16.bv4 M0DUZ# ```````'H```!L````( ```" ````!`!@````````````>+@``'BX` M``````````````````````````````````````"/PO4H4;@>%1Z%ZP$S,S,3 M9F9F)F9F9@:9F9D)/0K7`RA`"'G`!CO`!#W``C_````"/\`"/<( M".\0".<8"-XA"-8I",XQ",8Y"+U""+5*"*U2"*5:")QC")1K"(QS"(1["'N$ M"'.,"&N4"&.<"%JE"%*M"$JU"$*]"#G&"#'.""G6""'>"!CG"!#O" CW" `` M$/\`$/<`$.\($.<0$-X8$-8A$,XI$,8Q$+TY$+5"$*U*$*52$)Q:$)1C$(QK M$(1S$'M[$'.$$&N,$&.4$%J<$%*E$$JM$$*U$#F]$#'&$"G.$"'6$!C>$!#G M$ CO$ ``&/\`&/<`&.\`&.<(&-X0&-88&,XA&,8I&+TQ&+4Y&*U"&*5*&)Q2 M&)1:&(QC&(1K&'MS&'-[&&N$&&.,&%J4&%*<&$JE&$*M&#FU&#&]&"G&&"'. M&!C6&!#>& CG& ``(?\`(?<`(>\`(><`(=X((=80((0``*?\`*?<`*>\`*><`*=X`*=8(*\`,><`,=X`,=8`,\`.><`.=X` M.=8`._\`>_<`>^\`>^<` M>]X`>]8`>\X`>\8`>[T`>[4`>ZT`>Z4`>YP`>Y0`>XP`>X0(>WL0>W,8>VLA M>V,I>UHQ>U(Y>TI">T)*>SE2>S%:>REC>R%K>QAS>Q![>PB$>P``A/\`A/<` MA.\`A.<`A-X`A-8`A,X`A,8`A+T`A+4`A*T`A*4`A)P`A)0`A(P`A(0`A'L( MA',0A&L8A&,AA%HIA%(QA$HYA$)"A#E*A#%2A"E:A"%CA!AKA!!SA A[A `` MC/\`C/<`C.\`C.<`C-X`C-8`C,X`C,8`C+T`C+4`C*T`C*4`C)P`C)0`C(P` MC(0`C'L`C',(C&L0C&,8C%HAC%(IC$HQC$(YC#E"C#%*C"E2C"%:C!ACC!!K MC ASC ``E/\`E/<`E.\`E.<`E-X`E-8`E,X`E,8`E+T`E+4`E*T`E*4`E)P` ME)0`E(P`E(0`E'L`E',`E&L(E&,0E%H8E%(AE$HIE$(QE#DYE#%"E"E*E"%2 ME!A:E!!CE AKE ``G/\`G/<`G.\`G.<`G-X`G-8`G,X`G,8`G+T`G+4`G*T` MG*4`G)P`G)0`G(P`G(0`G'L`G',`G&L`G&,(G%H0G%(8G$HAG$(IG#DQG#$Y MG"E"G"%*G!A2G!!:G ACG ``I?\`I?<`I>\`I><`I=X`I=8`I\`K><`K=X`K=8`K\`M><`M=X` MM=8`M\` MO><`O=X`O=8`O; Sat, 7 Sep 1996 05:47:40 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA22548 for png-list-outgoing; Sat, 7 Sep 1996 05:47:44 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id FAA22543 for ; Sat, 7 Sep 1996 05:47:41 -0500 Date: Sat, 7 Sep 96 6:44:43 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Anniversary of chunk proposals Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609070644.aa26036@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Fri, 6 Sep 1996 15:53:51 -0800 }From: Jim King }Subject: Re: Anniversary of chunk proposals }At 7:49 AM -0800 9/6/96, Glenn Randers-Pehrson ARL-WMRD-TED-TIB wrote: }>} }>}> I propose that we take no action now on the proposed aLIG, }>}> fING, tSCL, and zSCL chunks. }>} }>}Because they are immature, or not a good idea, or what? }> }>aLIG is (I think) immature. } }What about it is immature? If it needs more changes, let's make them and }get it done. Lee said it was, back in April when I last tried to get the proposed chunks moved into the extensions document. He said it needed more discussion. Since absolutely no more discussion has occurred, I assume it is still just as immature, but a little more gray and wrinkled. I have not implemented it myself, and assume no one else has either, unless you as the proponent have. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 7 05:54:38 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id FAA08357 for ; Sat, 7 Sep 1996 05:54:38 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA22611 for png-list-outgoing; Sat, 7 Sep 1996 05:55:21 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id FAA22599 for ; Sat, 7 Sep 1996 05:55:17 -0500 Date: Sat, 7 Sep 96 6:49:20 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New Chunks Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609070649.aa26188@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List }I would argue that only stuff that has been on the extension list for a }while should be considered for moving into the main spec.) Absolutely. I think that any new chunk should, once registered, live in the extensions document for at least a year or two before moving to the core spec. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 7 05:54:55 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id FAA08359 for ; Sat, 7 Sep 1996 05:54:38 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA22612 for png-list-outgoing; Sat, 7 Sep 1996 05:55:22 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id FAA22602 for ; Sat, 7 Sep 1996 05:55:18 -0500 Date: Sat, 7 Sep 96 6:52:10 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Anniversary of chunk proposals Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609070652.aa26311@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Adam writes, regarding the proposed aLIG chunk: } }I suggest we specify integer division, then say: } }center = width / 2 }middle = height / 2 }baseline = (3 * height + 1) / 4 } Thanks, this is better. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 7 06:01:22 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id GAA08422 for ; Sat, 7 Sep 1996 06:01:21 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id GAA22720 for png-list-outgoing; Sat, 7 Sep 1996 06:00:33 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id GAA22715 for ; Sat, 7 Sep 1996 06:00:30 -0500 Date: Sat, 7 Sep 96 6:57:05 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Anniversary of chunk proposals Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609070657.aa26479@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List } }Is there a particular reason for the (3/4 of height)? }Seems to me to be an attempt at a guess where you probably don't want a }guess. } It seems to be a reasonable guess *if* the image depicts a character from a font. The reason I put 3/4 was as a subliminal reminder to typographers that 3/4 is 3/4 of the way to the *bottom* of the image, where they may be thinking of a baseline that is 1/4 of the way to the top. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 7 08:35:48 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA09356 for ; Sat, 7 Sep 1996 08:35:47 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA23654 for png-list-outgoing; Sat, 7 Sep 1996 08:36:25 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA23644; Sat, 7 Sep 1996 08:36:22 -0500 Date: Sat, 7 Sep 96 9:32:45 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: mpng-list@dworkin.wustl.edu cc: png-list@dworkin.wustl.edu Subject: Fifteenth MNG draft Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609070932.aa03147@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I have posted the 15th MNG draft to swrinde's incoming directory, in txt.gz, ps.gz, and .html formats, along with a draft-15 version of SGI viewpng, pngballs_d15.mng, lena_d15.mng, and impact_d15.mng I'll send the ASCII text of the draft to mpng-list. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 7 13:04:15 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA10885 for ; Sat, 7 Sep 1996 13:04:14 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA26118 for png-list-outgoing; Sat, 7 Sep 1996 13:04:28 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA26108 for ; Sat, 7 Sep 1996 13:04:23 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id OAA08208 for ; Sat, 7 Sep 1996 14:03:32 -0400 (EDT) To: PNG List Subject: A proposal for new-chunk process Date: Sat, 07 Sep 1996 14:03:32 -0400 Message-ID: <8205.842119412@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I think a big reason why the currently proposed PNG chunks have been sitting in limbo for so long is that we don't have any agreed-on procedure for moving them along, nor any sense of when it's OK to decide that they're sufficiently "done". With that in mind, here is a modest proposal. I would *not* like to see the chunk review process degenerate into politics or petty bookkeeping, so I do not suggest a rigid carefully- specified process. But I do think we need more structure than what we have now (which is none). Since this is such an informal group, a major concern that I have with some new chunks is that I'm not sure how many people have actually taken the time to look closely at each proposal. (I know I haven't looked very closely at many of them ... maybe I'm just projecting my guilt feelings onto the rest of you ;-).) If we aren't going to demand a test implementation of each new chunk, it's all the more critical that a proposal be thought about carefully by a number of people; such a review is the only chance we have to catch problems. Therefore, I suggest a voting process that's designed to ensure that adequate review has taken place. Let us agree that a YES vote for a new chunk proposal signifies "I have read the proposal carefully, I do not see any technical objections to the new chunk or imprecision in its definition, and I think it is probably useful enough to go into the PNG extensions list". A NO vote means you think there's something wrong with it (and one hopes that people will provide reasons why, rather than just saying no). If you have not studied the proposal reasonably carefully, you don't vote. Picking some numbers out of the air, something like ten YES votes and no NO votes would seem like a reasonable threshold for deciding that a chunk has no problems and should pass the vote. (I'm guessing from recent list traffic that a dozen or two people might be sufficiently interested to put the effort into vetting any particular chunk. We might have to adjust the number after we get some experience.) If there are any NO votes at all, my instinct would be to raise the threshold of YES votes considerably --- maybe require fifteen YES votes? But we don't want to turn a single NO into a veto power. There should also be an agreed-on time limit to ensure that people have had time to think about a proposal. Maybe a minimum of two weeks preliminary discussion period, followed by issuance of a final proposed spec draft, followed by a two week voting period? We can't make the intervals too long, because proposals are likely to just get forgotten about, but I don't want to see things zip through overnight either. People might want to change their votes after further thought and discussion. A potentially touchy subject is who gets to vote. One extreme would be "just the original spec authors", but I don't like that at all --- it would get harder and harder to get a quorum as people drop out for one reason or another. It smacks of elitism anyway. The other extreme would be "anyone on png-list", but I don't like that either --- we could get votes from people who aren't really sufficiently familiar with PNG to recognize potential problems. What I suggest is that you need to have been a member of png-list for some given amount of time before you get to vote. The easiest way to measure this would be from the date of your first message contributed to the list --- that could be checked easily in the archives, whereas I dunno whether we have logs of actual list subscribe requests. (This rule would penalize folks who just lurk without saying anything, but they're unlikely to vote anyway...) A bit of quick research suggests that about two dozen of us would have the vote now if we set a one-year participation period, and two or three more if it was six months. I'd be inclined towards the one-year figure myself. (Note: this is just counting people who I recall seeing messages from recently; there are several more who are still on the mailing list but may have lost interest. This is out of about seventy names altogether on png-list.) Given a pool of about two dozen active contributors to the list, is ten YES votes a reasonable threshold? I think so, but if we find that none of the proposals currently on the table get through, we'd probably better lower the number ;-) Anyway, that's my two cents worth. Any comments, refinements, better ideas? regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 7 14:34:45 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA11509 for ; Sat, 7 Sep 1996 14:34:42 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA27114 for png-list-outgoing; Sat, 7 Sep 1996 14:35:18 -0500 Received: from mega.megamed.com (megamed.com [199.4.114.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA27109 for ; Sat, 7 Sep 1996 14:35:14 -0500 Received: from coruisk (mega227.megamed.com [199.4.114.227]) by mega.megamed.com (8.7.5/8.7.3) with SMTP id MAA29914 for ; Sat, 7 Sep 1996 12:34:05 -0700 Date: Sat, 7 Sep 1996 12:34:05 -0700 Message-Id: <199609071934.MAA29914@mega.megamed.com> X-Sender: jbowler@megamed.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: John Bowler Subject: Re: A proposal for new-chunk process Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 14:03 07/09/96 -0400, Tom Lane wrote: > >Therefore, I suggest a voting process... This sounds like it should work. Ten/fifteen votes sounds reasonable. > >A potentially touchy subject is who gets to vote. One extreme would be >"just the original spec authors", but I don't like that at all --- it >would get harder and harder to get a quorum as people drop out for one >reason or another. It smacks of elitism anyway. The other extreme >would be "anyone on png-list", but I don't like that either --- we could >get votes from people who aren't really sufficiently familiar with PNG >to recognize potential problems. > >What I suggest is that you need to have been a member of png-list for >some given amount of time before you get to vote. Reasonable. > The easiest way to >measure this would be from the date of your first message contributed to >the list Ok. (Arbitrary, but fair.) >I'd be inclined towards the one-year figure myself. (Note: this is just >counting people who I recall seeing messages from recently; there are >several more who are still on the mailing list but may have lost >interest. This is out of about seventy names altogether on png-list.) Ah, well, I have a slight bias here. I think people lurk on a list for a while before posting. I subscribed on 2 Dec 1995, but first sent a message (from this email address) on 3 Mar 1996. I favor 6 months :-) John Bowler (jbowler@acm.org) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 7 18:30:11 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA12535 for ; Sat, 7 Sep 1996 18:30:10 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA29108 for png-list-outgoing; Sat, 7 Sep 1996 18:30:54 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id SAA29103 for ; Sat, 7 Sep 1996 18:30:51 -0500 Date: Sat, 7 Sep 96 19:29:06 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: A proposal for new-chunk process Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609071929.aa28059@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List tom's proposal seems reasonable. I vote YES. As for the details: 6 months since first posting seems OK. (I expect a lot of first postings in the next day or so) Initial registration, or elevation from a special document to extensions document, or from the extensions document to the core spec requires 10 yes votes in excess of twice the no votes. e.g. 10-0, 12-1, 14-2, .. 20-5 Two weeks at a minimum, maybe 30 days would be better, to complete a vote. Persons would be allowed to change their vote during the voting period. I suggest that it should take the same number of votes to establish this procedure... What about people stuffing the ballot box (amc@berkeley, amc@wustl, glennrp@arl, gr0089@epfl....) and letting people with new addresses (newt@pobox, amc@berkeley) vote? It shouldn't be a problem; we all know each other. But what about when a critical vote comes up in a couple of years and we've established this procedure and all retired? Maybe the qualification should be: if your mug appears in the authors collage.... I had really hoped we could do the chunk registration by consensus, the way the spec was done... I wonder why we can't? ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 7 20:58:55 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA13014 for ; Sat, 7 Sep 1996 20:58:55 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA00588 for png-list-outgoing; Sat, 7 Sep 1996 20:59:17 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id UAA00583 for ; Sat, 7 Sep 1996 20:59:13 -0500 Date: Sat, 7 Sep 96 21:57:22 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: png-list@dworkin.wustl.edu Subject: In defense of dRNG Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609072157.aa06981@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Here is my major reason for needing DRNG. If you have been following mpng-list, you know that I have demonstrated 80:1 compression of a movie in SGI movie format. Not all SGI movies will be that compressible, but I think all that are of the "line art" type will be extremely compressed when expressed as MNG. I wish I could tell SGI that MNG could compress their movies *losslessly*, but truthfully I can't. I did compress my movie losslessly. The SGI Image format contains MINVAL and MAXVAL variables which are functionally equivalent to DRNG. That would be the place to park SGI's MINVAL and MAXVAL. A DRNG-aware viewer would then display the movie with the same appearance as an SGI viewer displaying the original movie. Another solution would be to define a MNMX chunk to contain them, but when I proposed that 1.5 years ago, it received the same reception as dRNG/DRNG. Another solution was to define a SGIV chunk but that met with objection, too. Also, it would cause the sgi-converted images to be unreadable by almost everyone. sGIV would be readable but the sGIV chunk would most likely be discarded by most editors, being unsafe-to-copy. So I need something that is exactly equivalent to DRNG, whatever its name. In opposition to DRNG: The danger is that people will put converted SGI movies on the web, taking advantage of the huge compression factor, and then browsers would take the heat if they didn't look right, resulting in people demanding that the browser writers implement dRNG. Thereby causing the demise of PNG as we know it. Of course the spec gives dire warnings about using DRNG with severely out-of-range pixels, but who's going to read the spec? Not Joe Movie-Maker who hears about a way to squash his movie file down to almost nothing without loss and just grabs a movie-mng converter. But if we call it SGIV or anything else that changes nothing. The browsers will probably still have to contend with it. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 7 21:31:05 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id VAA13127 for ; Sat, 7 Sep 1996 21:31:05 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA00896 for png-list-outgoing; Sat, 7 Sep 1996 21:31:51 -0500 Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id VAA00891 for ; Sat, 7 Sep 1996 21:31:48 -0500 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id VAA01547 for ; Sat, 7 Sep 1996 21:29:57 -0500 (CDT) Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.5/8.7.3) id VAA05236 for png-list@dworkin.wustl.edu; Sat, 7 Sep 1996 21:30:51 -0500 (CDT) Date: Sat, 7 Sep 1996 21:30:51 -0500 (CDT) Message-Id: <199609080230.VAA05236@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: Re: A proposal for new-chunk process From: Cave Newt Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Tom wrote: >What I suggest is that you need to have been a member of png-list for >some given amount of time before you get to vote. The easiest way to >measure this would be from the date of your first message contributed to >the list --- that could be checked easily in the archives, whereas I >dunno whether we have logs of actual list subscribe requests. I do (since the July Crisis). I also have scattered membership lists as of various dates, just in case there's ever another Crisis. On the other hand, digging out the info would not be a trivial exercise. There's also the resubscription problem. What about old-timers who have gone silent? Guy and Jeremy certainly fall into this category (or would if they were still subscribed, which I guess they aren't...). >interest. This is out of about seventy names altogether on png-list.) 71 as of yesterday, not counting the two obvious list/archive addresses. There are also some folks only on png-implement, I think. >Given a pool of about two dozen active contributors to the list, >is ten YES votes a reasonable threshold? I think so, but if we find >that none of the proposals currently on the table get through, we'd >probably better lower the number ;-) My guess is that it will need lowering, but 10 is a good target to begin with. Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 7 23:10:49 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id XAA13548 for ; Sat, 7 Sep 1996 23:10:47 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA01684 for png-list-outgoing; Sat, 7 Sep 1996 23:11:23 -0500 Received: from u11.CS.Berkeley.EDU (u11.CS.Berkeley.EDU [128.32.38.135]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id XAA01674 for ; Sat, 7 Sep 1996 23:11:11 -0500 Received: (from amc@localhost) by u11.CS.Berkeley.EDU (8.6.11/8.6.9) id VAA03616 for png-list@dworkin.wustl.edu; Sat, 7 Sep 1996 21:10:18 -0700 Date: Sat, 7 Sep 1996 21:10:18 -0700 Message-Id: <199609080410.VAA03616@u11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: A proposal for new-chunk process X-Advice: should read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson ARL-WMRD-TED-TIB says: > Initial registration, or elevation from a special document to > extensions document, or from the extensions document to the core > spec requires 10 yes votes in excess of twice the no votes. > > e.g. 10-0, 12-1, 14-2, .. 20-5 That sounds good. > Two weeks at a minimum, maybe 30 days would be better, to complete > a vote. Persons would be allowed to change their vote during the > voting period. The voting period begins when anyone eligible to vote posts a proposal to the list and calls for a vote. Each edit of the proposal would require a new call for votes, which would have its own voting period. Presumably, people will be consistent enough with their voting to prevent alternate proposals from both passing. I think I lean slightly toward 30 days rather than two weeks. > I suggest that it should take the same number of votes to establish > this procedure... Good idea. I suggest that the voting period for establishing the procedure and the voting periods for the first proposals be allowed to be concurrent. If the voting for the first proposals turns out to conform to the procedure that later gets established, it applies retroactively. Are there any other details, or should someone write up the formal meta-proposal for the procedure? > I had really hoped we could do the chunk registration by consensus, > the way the spec was done... I wonder why we can't? The spec had a benevolent dictator. That helped a lot. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 8 00:37:38 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id AAA14323 for ; Sun, 8 Sep 1996 00:37:36 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA02604 for png-list-outgoing; Sun, 8 Sep 1996 00:38:12 -0500 Received: from u11.CS.Berkeley.EDU (u11.CS.Berkeley.EDU [128.32.38.135]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id AAA02599 for ; Sun, 8 Sep 1996 00:38:08 -0500 Received: (from amc@localhost) by u11.CS.Berkeley.EDU (8.6.11/8.6.9) id WAA03843 for png-list@dworkin.wustl.edu; Sat, 7 Sep 1996 22:37:16 -0700 Date: Sat, 7 Sep 1996 22:37:16 -0700 Message-Id: <199609080537.WAA03843@u11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: In defense of dRNG X-Advice: perhaps read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson ARL-WMRD-TED-TIB says: > I wish I could tell SGI that MNG could compress their movies > *losslessly*, but truthfully I can't. It's quite a predicament. Here's the best I can come up with: wRIH ("Wide Range Image Header") ==== compression method: Same meaning as in IHDR, but applies to wRID, not IDAT. filter method: Ditto. The values for width, height, bit depth, and color type are inherited from IHDR. The interlace method is 0, because interlacing would be pointless. (It wouldn't be pointless if we could interleave wRID chunks and IDAT chunks, but alas.) The remainder of the chunk has roughly the same format as dRNG. The IDAT chunks (or PLTE) contain scaled samples, but wRIH enables the decoder to recover the unscaled sample values, except the ones that were outside the (min,max) range. We need to define the mapping carefully using integer math so it really is reversible. wRID ("Wide Range Image Data") ==== Same format as IDAT, except that the chunk begins with a 2-byte sequence number (outside the compressed data stream) used to detect & correct chunk reordering. The wRID chunks contain the original unscaled samples, except that only samples whose corresponding scaled samples are 0 or 2^bitdepth-1 are needed. The rest may be set to anything by the encoder, and ignored by the decoder. This should allow good compression if most samples are in range. Setting the unused samples to a constant value would be a simple heuristic, but there might be even better ones that take into account the filtering and compression algorithms. wRPL ("Wide Range PaLette") ==== Just like PLTE, but contains unscaled sample values. Used instead of wRID for indexed color images. This proposal has the advantage of being completely compatible with existing viewers. It has the disadvantages of being gross, and making alteration of minval and maxval an O(width * height) operation instead of an O(1) operation (except for indexed color images). AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 8 06:43:49 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id GAA16463 for ; Sun, 8 Sep 1996 06:43:46 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id GAA04870 for png-list-outgoing; Sun, 8 Sep 1996 06:44:22 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id GAA04865 for ; Sun, 8 Sep 1996 06:44:18 -0500 Date: Sun, 8 Sep 96 7:40:17 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: In defense of dRNG Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609080740.aa02189@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Sat, 7 Sep 1996 22:37:16 -0700 }Subject: Re: In defense of dRNG }From: "Adam M. Costello" }Glenn Randers-Pehrson ARL-WMRD-TED-TIB says: } }> I wish I could tell SGI that MNG could compress their movies }> *losslessly*, but truthfully I can't. } }It's quite a predicament. Here's the best I can come up with: } }wRIH ("Wide Range Image Header") }wRID ("Wide Range Image Data") Don't need all that for converting SGI images, because the SGI spec requires that the data lie between PIXMIN and PIXMAX, inclusive, so it's really "Small range image data". DRNG is perfect for that. There probably aren't that many images out there that don't just have PIXMIN=0, PIXMAX=255, and for those there's no need to keep PIXMIN and PIXMAX in the PNG file. Possibly there are some converted 5-bit images around that have PIXMAX=31, but I don't really know because I only deal with my own images. When I said SGI images would suffer lossy conversion I just meant that the PIXMIN and PIXMAX data (the two numbers) would be lost, not that anything would happen to the pixel data. A sgi-png conversion would give the appearance of loss; in the case of the 5-bit images I mentioned above they would be darkened. And then the png-sgi conversion would result in an SGI image that was also dark. Now, if someone were using the DRNG chunk to do something tricky like making sepia-tones, such images would not look the same when converted to SGI..... but that doesn't bother me particularly. What I am after is the ability to answer the question, "Can you convert SGI images losslessly to PNG and back to SGI format?" with an unqualified "YES!" Without DRNG or equivalent, the answer is "Well, yes, but if you're using PIXMAX you have to save it somewhere and restore it when you convert back..." by which time I've lost their attention. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 8 06:53:32 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id GAA16834 for ; Sun, 8 Sep 1996 06:53:32 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id GAA04926 for png-list-outgoing; Sun, 8 Sep 1996 06:54:22 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id GAA04920 for ; Sun, 8 Sep 1996 06:54:19 -0500 Date: Sun, 8 Sep 96 7:48:37 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: In defense of dRNG Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609080748.aa02809@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List } }wRIH ("Wide Range Image Header") }==== [etc] }This proposal has the advantage of being completely compatible with }existing viewers. It has the disadvantages of being gross, and making }alteration of minval and maxval an O(width * height) operation instead }of an O(1) operation (except for indexed color images). I can't see what this proposal accomplishes that DRNG can't. Perhaps it will be more palatable to DRNG's detractors because of its unpalatability. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 8 11:07:50 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id LAA17672 for ; Sun, 8 Sep 1996 11:07:48 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA06525 for png-list-outgoing; Sun, 8 Sep 1996 11:08:29 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA06520 for ; Sun, 8 Sep 1996 11:08:25 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id MAA10864 for ; Sun, 8 Sep 1996 12:07:30 -0400 (EDT) To: PNG List Subject: Re: A proposal for new-chunk process In-reply-to: Your message of Sat, 7 Sep 96 19:29:06 EDT <9609071929.aa28059@THOR.ARL.MIL> Date: Sun, 08 Sep 1996 12:07:29 -0400 Message-ID: <10862.842198849@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn says: > I had really hoped we could do the chunk registration by consensus, the > way the spec was done... I wonder why we can't? Well, actually I'd like to believe that it will be by consensus, that most votes will be 10-0 or 0-10. But I think we need some agreed way of deciding when we have closure of the discussion. The problem with the chunks that were proposed last September is that the discussion trailed off without any definite yea-or-nay resolution. The original spec development differed from the current situation in a couple of ways: 1. Everyone felt a very strong sense of time pressure; we didn't let discussions drop. That's why I suggested setting up a time period. 2. Not everything was done by consensus; we had a benevolent dictator to force closure on a particular point when the discussion reached a dead end. Thomas has retired from that job (heck, he's not even posted anything to this list in three months). Lacking a dictator, we need a democracy or we'll have anarchy... regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 8 13:20:49 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA18605 for ; Sun, 8 Sep 1996 13:20:48 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA08085 for png-list-outgoing; Sun, 8 Sep 1996 13:21:19 -0500 Received: from u11.CS.Berkeley.EDU (u11.CS.Berkeley.EDU [128.32.38.135]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA08075 for ; Sun, 8 Sep 1996 13:21:16 -0500 Received: (from amc@localhost) by u11.CS.Berkeley.EDU (8.6.11/8.6.9) id LAA04603; Sun, 8 Sep 1996 11:20:20 -0700 Date: Sun, 8 Sep 1996 11:20:20 -0700 Message-Id: <199609081820.LAA04603@u11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: In defense of dRNG X-Advice: should read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson ARL-WMRD-TED-TIB says: > Don't need all that for converting SGI images, because the SGI spec > requires that the data lie between PIXMIN and PIXMAX, inclusive, so > it's really "Small range image data". DRNG is perfect for that. Oh, the problem is not nearly as bad as I thought. In fact, DRNG is overkill for your purpose. All you really need is an ancillary chunk that stores the same numbers that DRNG does, but which would be like sBIT in that it provides historical information, but doesn't affect the interpretation of IDAT. IDAT would store the *scaled* samples, but the scaling must be done using an invertible function, so that the unscaled samples can be recovered using this new chunk. If that's agreeable, we can get on with carefully defining the function. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 8 13:23:17 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA18616 for ; Sun, 8 Sep 1996 13:23:16 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA08111 for png-list-outgoing; Sun, 8 Sep 1996 13:23:58 -0500 Received: from u11.CS.Berkeley.EDU (u11.CS.Berkeley.EDU [128.32.38.135]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA08106 for ; Sun, 8 Sep 1996 13:23:55 -0500 Received: (from amc@localhost) by u11.CS.Berkeley.EDU (8.6.11/8.6.9) id LAA04634 for png-list@dworkin.wustl.edu; Sun, 8 Sep 1996 11:23:00 -0700 Date: Sun, 8 Sep 1996 11:23:00 -0700 Message-Id: <199609081823.LAA04634@u11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: In defense of dRNG X-Advice: perhaps read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson ARL-WMRD-TED-TIB says: > I can't see what [wRIH/wRID/wRPL] accomplishes that DRNG can't. It allows whiter-than-white and blacker-than-black pixels in a way that doesn't confuse existing viewers. I thought that's what you needed, but you didn't. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 8 13:26:19 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA18630 for ; Sun, 8 Sep 1996 13:26:18 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA08136 for png-list-outgoing; Sun, 8 Sep 1996 13:26:55 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA08131 for ; Sun, 8 Sep 1996 13:26:51 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id OAA11627 for ; Sun, 8 Sep 1996 14:25:55 -0400 (EDT) To: PNG List Subject: Re: In defense of dRNG In-reply-to: Your message of Sun, 8 Sep 1996 11:20:20 -0700 <199609081820.LAA04603@u11.CS.Berkeley.EDU> Date: Sun, 08 Sep 1996 14:25:55 -0400 Message-ID: <11624.842207155@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > All you really need is an ancillary chunk that stores the same numbers > that DRNG does, but which would be like sBIT in that it provides > historical information, but doesn't affect the interpretation of > IDAT. IDAT would store the *scaled* samples, but the scaling must be > done using an invertible function, so that the unscaled samples can be > recovered using this new chunk. > If that's agreeable, we can get on with carefully defining the function. I like this approach a *whole* lot better than actually storing samples that are not full range. The only possible problem is that there's no way to represent an out-of-range sample, so it's still not "guaranteed 100% lossless". But I guess you can say that it would represent every spec-conformant SGI file losslessly. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 8 13:42:48 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA18790 for ; Sun, 8 Sep 1996 13:42:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA08249 for png-list-outgoing; Sun, 8 Sep 1996 13:43:10 -0500 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA08244 for ; Sun, 8 Sep 1996 13:43:06 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id LAA12112 for ; Sun, 8 Sep 1996 11:41:54 -0700 X-Sender: davem@mail.cs.ubc.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 8 Sep 1996 11:41:56 -0700 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: Re: In defense of dRNG Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I have a couple of concerns about the correspondence between dRNG and SGI PIXMIN/PIXMAX. Most of them are really about PIXMIN/PIXMAX itself (I think it's a botch), but that affects the "correct" conversion of SGI images into PNG images with dRNG (or equivalent). First, why I think PIXMIN/PIXMAX is a botch: The library that SGI provides for writing SGI files *automatically* determines PIXMIN and PIXMAX when any image file is written. Then, when the image files are read, some of the image tools *automatically* rescale the data values so that PIXMIN in the file becomes zero in the frame buffer, and PIXMAX in the file becomes 255 in the frame buffer. This means that my carefully-computed pixel values, which are as close as I can make them to being photometrically related to the original scene, are suddenly arbitrarily rescaled. Now, if my image has no pixel value larger than 240, it's because I don't *want* those pixels to reach the peak intensity that the monitor is capable of - I don't want it scaled to 255. But at least scaling at this end of the range is visually relatively benign. On the other hand, if no pixel has a value smaller than 30, it's because there is no part of the image darker than that. If 30 gets mapped to zero, that *drastically* darkens the shadow areas of the image, changing gamma and colour saturation. And, in fact, SGI display programs aren't consistent among themselves. The "ipaste" program does no rescaling, while "imgview" and "imgworks" do. As a result of this, all of my interactions with PIXMIN/PIXMIN in SGI files have been negative - they always do something I don't want, and never do something I consider useful. As a result, I have given up on using SGI's "fromppm" program and their supplied library for writing images, and instead use the PBMPLUS "pnmtosgi" program which always sets PIXMIN to 0 and PIXMAX to the PPM file's maxval. Now, I would have no problem with PIXMIN and PIXMAX if SGI decided either 1) They are statistical measures, automatically computed, but no programs make use of the information during display unless explicitly asked to rescale the data, so in practice PIXMIN and PIXMAX have no effect on display. or 2) They are user-provided advisory commands that tell the display program to rescale the data during display, but since they are present *only* when the originator of the image *wants* that rescaling, they form part of the original image and interpreting them is necessary to get correct display of the image. instead, we have 3) They are automatically-determined statistical measures that affect the display of the image, even if neither the person who originated the image or the person displaying it want that to happen. So, the question becomes: how do you map this feature into a PNG chunk, and how should PNG encoders and display programs handle that chunk? If SGI's use of PIXMIN/PIXMAX was as described in #1 above, then the mapping to PNG is easy: you just put the PIXMIN/PIXMAX values into a comment chunk of some sort - either using the existing text chunk mechanism, or a new chunk with a unique name to make it easier to find. But whatever the details, it should be clear that the chunk is just a comment, and no PNG decoder is expected to use the chunk to alter the display of the image. No problem. On the other hand, if SGI really meant PIXMIN/PIXMAX's meaning to be as in #2 above, then it maps fairly directly to dRNG as we have been discussing it. dRNG is a chunk which is inserted at the request of the user and which *does* affect the display of the image. Now, this goes against the original PNG design philosophy of always scaling sample values to the range 0... 2^nbits-1, and there will be some opposition to that. But if we were to agree to the change in philosophy, then SGI PIXMIN/PIXMAX could be mapped to dRNG and everyone would be happy. Unfortunately, current practice is #3. I would argue that we should *never* put a feature into PNG that automatically alters people's images for them. If others agree with me, then we will never have a feature that exactly mimics PIXMIN/PIXMAX. If I were writing an "absolutely lossless" SGI->PNG converter, I would do the following: I'd argue that since PIXMIN/PIXMAX are automatically determined, they *cannot* reasonably be viewed as instructions from the image author to the display program. Thus they are just advisory info, and can legitimately be turned into comments in the PNG header. Pick a pair of unique keywords (SGI_PIXMIN and SGI_PIXMAX?), store them as text chunks, and you're done. Any SGI display program that really *wants* to rescale the sample values based on PIXMIN/PIXMAX can do so; the info is in the image for them to look up. The complementary PNG->SGI converter program can find the values in the text chunk and convert them back to PIXMIN/PIXMAX in the SGI output file. So this is lossless storage. Yet, at the same time, any standard PNG viewer will display the images while ignoring the text comments - which is the correct thing to do if PIXMIN and PIXMAX are really just advisory info. So I think you neither want nor need dRNG for this application. The other reservation I have is that if you take interpretation #2 and really want the display of the image changed by PIXMIN and PIXMAX, then they are not quite equivalent to dRNG. PIXMIN/PIXMAX state that there are *no* pixels in the file with values outside this range, so you don't have to figure out what to do with them. You could legitimately build lookup tables that map all values less than PIXMIN or greater than PIXMAX to zero, since they don't exist in the data anyway. dRNG, on the other hand, specifies scaling for the entire input sample value range - so you may have to decide what to do with values that come out less than zero or greater than 1. Not a big deal, but enough for someone to complain that dRNG isn't equivalent to PIXMIN/PIXMAX. Glenn writes: >When I said SGI images would suffer lossy conversion I just meant >that the PIXMIN and PIXMAX data (the two numbers) would be lost, not >that anything would happen to the pixel data. A sgi-png conversion >would give the appearance of loss; in the case of the 5-bit images >I mentioned above they would be darkened. And then the png-sgi >conversion would result in an SGI image that was also dark. I think a text comment in the PNG header addresses this well enough. SGI->PNG->SGI conversion would be truly lossless. If the PNG image is displayed, it would look the same as "ipaste" displaying the SGI image (provided that gAMA was set correctly) but not necessarily the same as "imgview" or "imgworks" displaying the SGI image. Given that SGI software isn't consistent in its interpretation, how can the PNG interpretation be considered "wrong"? >Now, if someone were using the DRNG chunk to do something tricky like >making sepia-tones, such images would not look the same when converted >to SGI..... but that doesn't bother me particularly. What I am after >is the ability to answer the question, "Can you convert SGI images >losslessly to PNG and back to SGI format?" with an unqualified "YES!" >Without DRNG or equivalent, the answer is "Well, yes, but if you're >using PIXMAX you have to save it somewhere and restore it when you >convert back..." by which time I've lost their attention. So use a comment. Or invent a new private chunk. But this definitely does *not* need nor want the image-modifying powers of dRNG. Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 8 13:50:23 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA18829 for ; Sun, 8 Sep 1996 13:50:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA08294 for png-list-outgoing; Sun, 8 Sep 1996 13:51:04 -0500 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA08289 for ; Sun, 8 Sep 1996 13:51:01 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id LAA12535 for ; Sun, 8 Sep 1996 11:49:57 -0700 X-Sender: davem@mail.cs.ubc.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 8 Sep 1996 11:49:59 -0700 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: Re: In defense of dRNG Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Adam writes: >All you really need is an ancillary chunk that stores the same numbers >that DRNG does, but which would be like sBIT in that it provides >historical information, but doesn't affect the interpretation of >IDAT. IDAT would store the *scaled* samples, but the scaling must be >done using an invertible function, so that the unscaled samples can be >recovered using this new chunk. In fact, I'd argue that you usually don't even want to scale the samples. They're not scaled in the SGI image file, and the PIXMIN and PIXMAX values in the SGI file do not represent a request by the image originator to scale the values. They're just statistical data. The fact that some (not all) SGI image viewers want to rescale the sample values based on PIXMIN and PIXMAX can best be regarded as a bug or a feature of the viewers themselves, not a requirement for viewing the image. If the PIXMIN/PIXMAX data is in a comment in the PNG file header, such viewers can still do the scaling if they want. But standard PNG viewers won't rescale - an entirely legitimate thing to do if PIXMIN and PIXMAX are just statistical data. Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 8 14:51:00 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA19025 for ; Sun, 8 Sep 1996 14:50:59 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA08893 for png-list-outgoing; Sun, 8 Sep 1996 14:51:25 -0500 Received: from mega.megamed.com (megamed.com [199.4.114.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA08888 for ; Sun, 8 Sep 1996 14:51:21 -0500 Received: from coruisk (mega211.megamed.com [199.4.114.211]) by mega.megamed.com (8.7.5/8.7.3) with SMTP id MAA12711 for ; Sun, 8 Sep 1996 12:50:13 -0700 Date: Sun, 8 Sep 1996 12:50:13 -0700 Message-Id: <199609081950.MAA12711@mega.megamed.com> X-Sender: jbowler@megamed.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: John Bowler Subject: Re: A proposal for new-chunk process Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 12:07 08/09/96 -0400, Tom Lane wrote: > >Well, actually I'd like to believe that it will be by consensus, that >most votes will be 10-0 or 0-10. But I think we need some agreed way >of deciding when we have closure of the discussion. The problem with >the chunks that were proposed last September is that the discussion >trailed off without any definite yea-or-nay resolution. Indeed, so the compelling feature of the voting process is it establishes the state of a proposal. > Lacking a dictator, we need a democracy or we'll have anarchy... I think the choices are democracy or concensus. The two differ only in the interpretation of "yes" and "no":- democratic: yes means: "I think this is the best proposal and should be adopted" no means: "I think there is some better alternative which should be used" abstain means: "I don't give a damn", or "It really doesn't matter, adopt/don't this and stop arguing" A "majority" (defined, perhaps, in the ways people have suggested) finalizes the process. Absence of a majority invokes a default behavior ("don't adopt"). concensus: yes means: "This should be adopted" no means: "I have strong objections, this should not be adopted" abstain means: "I don't give a damn" (but *not* "adopt by default" *or* "reject be default") Only absence of "no" or "yes" in one vote finalizes the process. In the concensus approach the arguments continue until everyone agrees or abstains. If the voting process is issued by someone casting a vote then "everyone abstains" means that everyone loses interest (there is no further vote), in this case the proposal is not adopted but anyone can initiate a new vote at any time. A proposal can be adopted, or rejected, by one vote but it is almost inconceivable that *adoption* will happen by one vote because someone will "NO" on the basis that there is insufficient support or utility (this *is* a strong objection!) In the concensus approach everyone can vote - ballot box stuffing is impossible, the equivalent is just being bloody-minded and ignoring counter arguments. If that becomes a problem then maybe a process change is required :-) John Bowler (jbowler@acm.org) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 8 15:12:40 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA19122 for ; Sun, 8 Sep 1996 15:12:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA09104 for png-list-outgoing; Sun, 8 Sep 1996 15:13:10 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id PAA09099 for ; Sun, 8 Sep 1996 15:13:07 -0500 Date: Sun, 8 Sep 96 16:11:38 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: In defense of dRNG Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609081611.aa28336@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List } }In fact, I'd argue that you usually don't even want to scale the samples. }They're not scaled in the SGI image file, and the PIXMIN and PIXMAX values }in the SGI file do not represent a request by the image originator to scale }the values. They're just statistical data. } }The fact that some (not all) SGI image viewers want to rescale the sample }values based on PIXMIN and PIXMAX can best be regarded as a bug or a feature }of the viewers themselves, not a requirement for viewing the image. } Dave The SGI Image spec seems to say otherwise (versions 0.97 and 1.00 are identical with regard to PINMAX and PINMIN [sic]: For Version 1.00 of this spec see: http://reality.sgi.com/grafica/sgiimage.html Draft version 0.97 The SGI Image File Format [...] The Header The header consists of the following: Size | Type | Name | Description [...] 4 bytes | long | PIXMIN | Minimum pixel value 4 bytes | long | PIXMAX | Maximum pixel value [...] PINMIN - The minimum pixel value in the image. The value of 0 may be used if no pixel has a value that is smaller than 0. PINMAX - The maximum pixel value in the image. The value of 255 may be used if no pixel has a value that is greater than 255. This is the value that is considered to be full brightness in the image. [...]end of extracts from SGIIMAGESPEC.txt Disregarding the typos (PIN should be PIX), this description seems to correspond to DRNG. It certainly appears that if your data ranged from 30 to 240, PIXMAX could be 255, representing full brightness, and PIXMIN by implication could be 0, representing full darkness. The use of PIXMIN and PIXMAX as statistical measures that you described seems to be a result of another possible interpretation of this somewhat terse spec, that may not have been the intention of the author. The phrase "considered to be full brightness in the image" is an exact description of the max_sample value of DRNG. But if some SGI products interpret these header values differently, there really is no solution for us except to store the values and restore them on conversion back to SGI image format, and display them as we see fit. I would choose the method that adheres to the SGI spec, which is exactly DRNG (yes, DRNG is overkill because it provides 3 different channels and allows for pixels to be out of the min_pix to max_pix range. I forgot to restate my other reason for wanting dRNG and that is to facilitate better compresssion of sBIT=5 images, using zero-fill instead of LBR-fill, and using dRNG to make the final adjustments. I do intend to continue using drNG for my own purposes, whether dRNG or DRNG is approved or not, and just run the risk of encountering someone else's images that use a chunk named "drNG" to represent something entirely different. If that is something that will bring about the downfall of PNG, I'm sorry; that is not my intent. I have too much sweat invested in PNG to let that happen. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 8 15:53:51 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA19275 for ; Sun, 8 Sep 1996 15:53:50 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA09552 for png-list-outgoing; Sun, 8 Sep 1996 15:54:23 -0500 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA09547 for ; Sun, 8 Sep 1996 15:54:17 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id NAA19045 for ; Sun, 8 Sep 1996 13:53:17 -0700 X-Sender: davem@mail.cs.ubc.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 8 Sep 1996 13:53:19 -0700 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: Re: In defense of dRNG Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > The SGI Image File Format > [...] > The Header > > The header consists of the following: > > Size | Type | Name | Description > > [...] > 4 bytes | long | PIXMIN | Minimum pixel value > 4 bytes | long | PIXMAX | Maximum pixel value > > [...] > > PINMIN - The minimum pixel value in the image. The value of > 0 may be used if no pixel has a value that is smaller than 0. > > PINMAX - The maximum pixel value in the image. The value of > 255 may be used if no pixel has a value that is greater than 255. > This is the value that is considered to be full brightness in > the image. > > [...]end of extracts from SGIIMAGESPEC.txt I read this as saying that PIXMIN and PIXMAX are informational values. If you don't know the actual max and min (because you didn't look at every sample value while writing the image to calculate max and min), it is acceptable to write 0 for min and 255 for max. (Remember, this is a fixed-size binary header, so all fields are always present - you don't have the option of leaving out a chunk if you don't know reasonable data to put into it). And I think that's *all* it says. One might interpret the "considered to be full brightness in the image" as an indication that you should scale PIXMAX to 255 for display, but it doesn't explicitly say that. And it doesn't say anything at all suggesting that PIXMIN should be scaled to 0. >The use >of PIXMIN and PIXMAX as statistical measures that you described seems >to be a result of another possible interpretation of this somewhat terse spec, >that may not have been the intention of the author. My own suspicion is that the author didn't fully consider the issue of whether these fields should be descriptive or prescriptive, and thus didn't make it clear in the spec. Then someone (probably another person) wrote the image library that automatically calculated these values whenever an image is written - implicitly treating them as descriptive, but probably without thinking about it. Then the person who wrote "ipaste" just ignored the values, or figured they were only descriptive. Then someone else again wrote the ImageVision library (the thing that imgview and imgworks is based on), read the spec, and figured that the fields were prescriptive. If the company that originated the spec ships code to customers that interprets this data in two different inconsistent ways, what hope do others have of deciding what is "correct"? So I vote for doing the thing that makes the most sense, regardless of the actual wording in the spec, documenting why it is done that way, and let others argue about it if they want. Or get SGI to clarify its own spec, and fix its programs. >But if some SGI products interpret these header values differently, there >really is no solution for us except to store the values and restore them >on conversion back to SGI image format, and display them as we see fit. >I would choose the method that adheres to the SGI spec, which is exactly >DRNG (yes, DRNG is overkill because it provides 3 different channels and >allows for pixels to be out of the min_pix to max_pix range. Yes, that's one way. But it somewhat violates the "rescale on encoding if you want to change brightness" philosophy of PNG. And, as I described earlier, existing SGI files all have PIXMIN and PIXMAX values that are usually statistical measurements, so using them to rescale images does the wrong thing as often as it does something useful. Whereas the "stick them in a chunk that has no effect on display, but from which they can be recovered" does not have any of these problems. It doesn't give the automatic rescaling that some SGI *viewers* provide - but SGI viewers can easily provide this function directly when viewing PNG files if SGI adds PNG support to ImageVision. Since the SGI spec is so vague, and since they have different viewer implementations that do or don't scale, I think the most conservative thing when converting SGI to PNG is to do so in a way that doesn't cause scaling in PNG viewers by default. >I forgot to restate my other reason for wanting dRNG and that is to >facilitate better compresssion of sBIT=5 images, using zero-fill instead >of LBR-fill, and using dRNG to make the final adjustments. Well, "smart" PNG viewers already have sBIT available, so they already have all the information they need to know that (for example) the original image was 5 bits deep, and thus a pixel value of 248 or higher should be mapped to maximum video voltage. They can easily build a LUT that provides optimum display of sBIT=5 images with the information already availble. dRNG isn't needed for this. ============================================================================ Where dRNG *is* useful is in "scientific visualization" applications where you want to leave the data in the file unscaled, but display only a portion of the brightness range to enhance some features. This would be useful with many sorts of wide-dynamic-range data. (We can have another argument about whether this thresholding information belongs in the image file or not, but at least the idea is clearly useful). More generally, PNG does not currently provide a way to store image data when there is no one "correct" way to display the data. Another example is wide-brightness-range photographic data where the encoded brightness range exceeds the brightness range of a CRT. You can choose to display the shadows and midtones, and the midtones and highlights, but can't see both shadows and highlights at the same time unless you reduce the gamma to the point where the image is quite unrealistic. All of these are valid ways of displaying the data, but none is "correct" or even "best". PNG as it stands now assumes that there is one "correct" way for a given image to look, and does its best to provide identical results on all platforms. It seems to me that this is the essential conflict: If every image has one "right" way to see it, then PNG works pretty well (but why bother with 16-bit sample values when 8 is almost always adequate for fixed-presentation images?). But if we want to store wide-dynamic-range or non-photographic data that has no single "right" display representation, then either we need to extend PNG to handle multiple ways of looking at the same data, or admit that PNG isn't intended for this and shouldn't be used for this. Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 8 16:13:15 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA19383 for ; Sun, 8 Sep 1996 16:13:13 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA09770 for png-list-outgoing; Sun, 8 Sep 1996 16:14:02 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA09765 for ; Sun, 8 Sep 1996 16:13:58 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id RAA13415 for ; Sun, 8 Sep 1996 17:13:02 -0400 (EDT) To: PNG List Subject: Re: In defense of dRNG In-reply-to: Your message of Sun, 8 Sep 1996 13:53:19 -0700 Date: Sun, 08 Sep 1996 17:13:01 -0400 Message-ID: <13412.842217181@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List davem@cs.ubc.ca (Dave Martindale) writes: > But if we want to store wide-dynamic-range or non-photographic > data that has no single "right" display representation, then either we need > to extend PNG to handle multiple ways of looking at the same data, or admit > that PNG isn't intended for this and shouldn't be used for this. I don't think it's quite as bad as that. What I think PNG presumes is that there is a clearly specified *default* way to see an image, and that this is what you'll get if you have a plain vanilla PNG decoder. But that doesn't stop you from adding ancillary chunks that define other ways to look at the image, and from creating decoders that can select one of those other ways. sBIT is in effect such a chunk, and we can make more. The major problem with dRNG, in my eyes, is that dRNG makes it highly likely that the "default" view presented by a plain vanilla decoder will be unusable. If dRNG is defined as a way to descale scaled data back to some original representation, but the stored samples are full-range data, then this problem goes away. For images that include whiter-than-white and blacker-than-black data, the only way to store such data losslessly whilst retaining this PNG assumption is to scale so that the actual data range is 0 .. max (or less). Depending on how far outside the normal range your highlights are, that could result in a fairly low-contrast default display. I don't know if the resulting image would be considered "unusable"... if it likely would be, then we do have a problem with supporting such data. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 8 20:21:29 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA22138 for ; Sun, 8 Sep 1996 20:21:28 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA12375 for png-list-outgoing; Sun, 8 Sep 1996 20:21:38 -0500 Received: from gntcompaq.gintic.ntu.ac.sg ([155.69.29.28]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id UAA12369 for ; Sun, 8 Sep 1996 20:21:33 -0500 Received: by gntcompaq.gintic.ntu.ac.sg with Microsoft Exchange (IMC 4.0.837.3) id <01BB9E30.68DE7990@gntcompaq.gintic.ntu.ac.sg>; Mon, 9 Sep 1996 09:22:23 +0800 Message-ID: From: Willem van Schaik To: "'PNG List'" Subject: RE: A proposal for new-chunk process Date: Mon, 9 Sep 1996 09:22:22 +0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Tom wrote: >Given a pool of about two dozen active contributors to the list, >is ten YES votes a reasonable threshold? I think so, but if we find >that none of the proposals currently on the table get through, we'd >probably better lower the number ;-) > I think this overall a good idea to get some action in these chunks. A treshold of 10 sounds OK too. The only addition I would make is that there must be at least 2 times more YES votes then NO votes. Similar to the rules for Newsgroups voting. For the rest I'm not to bothered about the exact rules. Let's not make them too complicated. Or am I already doing that now ???? Willem > > > > ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 8 20:23:25 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA22145 for ; Sun, 8 Sep 1996 20:23:24 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA12423 for png-list-outgoing; Sun, 8 Sep 1996 20:24:17 -0500 Received: from gntcompaq.gintic.ntu.ac.sg ([155.69.29.28]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id UAA12418 for ; Sun, 8 Sep 1996 20:24:13 -0500 Received: by gntcompaq.gintic.ntu.ac.sg with Microsoft Exchange (IMC 4.0.837.3) id <01BB9E30.C9945160@gntcompaq.gintic.ntu.ac.sg>; Mon, 9 Sep 1996 09:25:06 +0800 Message-ID: From: Willem van Schaik To: "'PNG List'" Subject: RE: A proposal for new-chunk process Date: Mon, 9 Sep 1996 09:25:04 +0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List John wrote: > >>I'd be inclined towards the one-year figure myself. (Note: this is just >>counting people who I recall seeing messages from recently; there are >>several more who are still on the mailing list but may have lost >>interest. This is out of about seventy names altogether on png-list.) > >Ah, well, I have a slight bias here. I think people lurk on a list for >a while before posting. I subscribed on 2 Dec 1995, but first sent a >message (from this email address) on 3 Mar 1996. I favor 6 months :-) > I would say too that 6 months is OK. But who am I, yes one of the other late-joiners :-). But I'm not keeping track what are the exact dates. John, do you use a computer for that ?? ;-). Willem > ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 9 07:29:25 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id HAA26690 for ; Mon, 9 Sep 1996 07:29:24 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA17822 for png-list-outgoing; Mon, 9 Sep 1996 07:29:48 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id HAA17817 for ; Mon, 9 Sep 1996 07:29:45 -0500 Date: Mon, 9 Sep 96 8:27:29 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: In defense of dRNG Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609090827.aa06321@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List We seem to be heading for a 3-tiered registration system, 1. Core chunks PNG spec MNG spec PNP spec? 2. Public extension chunks PNG extensions document MNG extensions document? PNP extensions document? 3. Special purpose extension chunks Sci-vis chunks Color management chunks? Other categories? I suggest a fourth category (not a tier but a separate thing): 4. Deprecated chunks Chunks that are registered not with a blessing but with a curse. This would include those chunks that have been thoroughly examined, and have a stable format, which are rejected or despised by a sufficient number of us to prevent registration, but are still desired by a minority. This would be a document that would formally document the format, but would state in no uncertain terms that the chunk is *not* expected to be used in polite company. I suspect that the first two candidates for this document would be DRNG and fING. The extensions document would make reference to the deprecated chunks document but wouldn't even mention the names of the chunks defined in it. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 9 08:51:12 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA27892 for ; Mon, 9 Sep 1996 08:51:11 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA18441 for png-list-outgoing; Mon, 9 Sep 1996 08:51:45 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA18436 for ; Mon, 9 Sep 1996 08:51:42 -0500 Date: Mon, 9 Sep 96 9:48:03 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: sBIT [was Re: In defense of dRNG] Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609090948.aa12902@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List } }Well, "smart" PNG viewers already have sBIT available, so they already have }all the information they need to know that (for example) the original image }was 5 bits deep, and thus a pixel value of 248 or higher should be mapped }to maximum video voltage. They can easily build a LUT that provides }optimum display of sBIT=5 images with the information already availble. }dRNG isn't needed for this. } This is a very interesting point. During all the discussion of sBIT, I always looked at sBIT as just providing information for restoring the original image data during a PNG-to-original-format conversion, not as something relevant to the viewing software. The PNG spec only hints at your point. But I think you are right, a *smart* PNG viewer will first restore the original 5-bit (or whatever) data and then LBR-scale it up to the frame buffer depth. My viewpng for SGI has been ignoring sBIT. After today it will use sBIT in the manner just described (but defeatable with a command-line option). ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 9 09:03:25 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA28298 for ; Mon, 9 Sep 1996 09:03:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA18533 for png-list-outgoing; Mon, 9 Sep 1996 09:03:43 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA18526 for ; Mon, 9 Sep 1996 09:03:38 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id KAA16524 for ; Mon, 9 Sep 1996 10:02:38 -0400 (EDT) To: PNG List Subject: Re: In defense of dRNG In-reply-to: Your message of Mon, 9 Sep 96 8:27:29 EDT <9609090827.aa06321@THOR.ARL.MIL> Date: Mon, 09 Sep 1996 10:02:37 -0400 Message-ID: <16522.842277757@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > I suggest a fourth category (not a tier but a separate thing): > 4. Deprecated chunks I think that'd provide a good place for "historical cruft", that is, chunks that were once in good standing but have been superseded by a better idea. An example already staring us in the face is the use of PLTE rather than an ancillary chunk (sPLT) for suggested palettes for truecolor images. This would be a bit tricky to document, since the *chunk* won't go away but one use of it would. In any case, it won't happen until we are ready to produce a PNG 2.0 specification, which I hope won't be for a long while... > This would include those chunks that have been thoroughly examined, > and have a stable format, which are rejected or despised by a sufficient > number of us to prevent registration, but are still desired by a > minority. Unless the minority is significantly larger than one, I'd suggest using a private chunk instead. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 9 09:25:51 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA28808 for ; Mon, 9 Sep 1996 09:25:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA18784 for png-list-outgoing; Mon, 9 Sep 1996 09:26:35 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA18778 for ; Mon, 9 Sep 1996 09:26:32 -0500 Date: Mon, 9 Sep 96 10:25:19 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: In defense of dRNG Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609091025.aa15097@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List } }> This would include those chunks that have been thoroughly examined, }> and have a stable format, which are rejected or despised by a sufficient }> number of us to prevent registration, but are still desired by a }> minority. } }Unless the minority is significantly larger than one, I'd suggest using }a private chunk instead. } Yes, of course. It would take the same number of votes to get a chunk registered in the cursed chunks document as in one of the blessed chunks documents. This won't work if some people apply the same height of hurdle (presently about 2 meters) to this one as to all of the others, but I for one would be willing to vote YES here when I voted NO in other categories. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 9 09:50:08 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA29119 for ; Mon, 9 Sep 1996 09:50:06 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA19115 for png-list-outgoing; Mon, 9 Sep 1996 09:50:50 -0500 Received: from natashya.eden.com (natashya.eden.com [199.171.21.14]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA19110 for ; Mon, 9 Sep 1996 09:50:47 -0500 Received: from cpic (net-4-134.austin.eden.com [206.81.226.134]) by natashya.eden.com (8.7.4.1/8.7.1.1) with SMTP id JAA06550 for ; Mon, 9 Sep 1996 09:49:44 -0500 (CDT) Date: Mon, 9 Sep 1996 09:49:44 -0500 (CDT) Message-Id: <199609091449.JAA06550@natashya.eden.com> X-Sender: pschmidt@mail.eden.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: pschmidt@photodex.com (Paul Schmidt) Subject: RE: DOS/Win 32 software Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >The attached file is basi2c16.png converted to BMP by HiJaak 95 then >hacked into the V4 format:- ... >John Bowler John, Thanks for the CIE file. :-) Best Regards, Paul Schmidt ---------------------------------------------------------- Photodex Corporation Service GO/Keyword E-Mail 1106 Clayton Lane #200W AOL: Photodex Photodex Austin, TX 78723 CIS: Photodex 74774,3635 (512)406-3020 Voice (512)452-6825 Fax i'net: pschmidt@photodex.com "I play with dots... WWW: http://www.photodex.com ...lots of dots." FTP: ftp.photodex.com ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 9 11:22:13 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id LAA00571 for ; Mon, 9 Sep 1996 11:22:12 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA20686 for png-list-outgoing; Mon, 9 Sep 1996 11:23:03 -0500 Received: from mercury.ukc.ac.uk (mercury.ukc.ac.uk [129.12.21.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id LAA20681 for ; Mon, 9 Sep 1996 11:22:52 -0500 Received: from mint.ukc.ac.uk by mercury.ukc.ac.uk with SMTP (PP); Mon, 9 Sep 1996 17:21:33 +0100 Received: from localhost (localhost.ukc.ac.uk) by mint.ukc.ac.uk (4.1/UKC-2.14) id AA15702; Mon, 9 Sep 96 17:21:31 BST To: PNG List Subject: fING (was Re: Anniversary of chunk proposals) In-Reply-To: Your message of "Fri, 06 Sep 1996 17:43:41 EDT." <9609061743.aa12221@THOR.ARL.MIL> Date: Mon, 09 Sep 1996 17:21:30 +0100 Message-Id: <15701.842286090@mint.ukc.ac.uk> From: Dave Beckett Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >>>>> On Fri, 6 Sep 96 17:43:41 EDT, Glenn Randers-Pehrson ARL-WMRD-TED-TIB said: Glenn> [ripped apart my fING problems] My previous example was bogus, so please ignore it! I will try again to explain my problem with pngfprint's implementation of fING and why I say the bits are wrong, as far as I understand it. By default, for images <8 bits deep (i.e. non-paletted) libpng returns bytes with the pixels packed into each byte with no gaps i.e. as stored in the IDAT chunks: 1-bit deep (8 pixels/byte) 7 6 5 4 3 2 1 0 ================================= | Z | Y | X | W | V | U | T | S | where S..Z are the 8 pixels ================================= 2-bit deep (4 pixels/byte) 7 6 5 4 3 2 1 0 ================================= | Z z | Y y | X x | W w | where Ww, Xx, Yy and Zz are the 4 pixels ================================= 4-bits deep (2 pixels/byte) 7 6 5 4 3 2 1 0 ================================= | Z z z z | Y y y y | where Yyyy and Zzzz are the 2 pixels ================================= If you invoke png_set_packing() it changes the output format to be 1 pixel per byte with the values in the lower bits: For 1-bit deep: 8 bytes 0000000S 0000000T 0000000U 0000000V 0000000W 0000000X 0000000Y 0000000Z For 2-bit deep: 4 bytes 000000Ww 000000Xx 000000Yy 000000Zz For 4-bit deep: 2 bytes 0000Wwww 0000Xxxx Now this still isn't what you want. png_set_expand() must be called to do LBR for the <8-bit deep images giving: 1-bit deep: SSSSSSSS TTTTTTTT UUUUUUUU VVVVVVVV WWWWWWWW XXXXXXXX YYYYYYYY ZZZZZZZZ 2-bit deep: WwWwWwWw XxXxXxXx YyYyYyYy ZzZzZzZz 4-bit deep: WwwwWwww XxxxXxxx but unfortunately, this isn't called in the pngfprint program so the bytes that are being fingerprinted are incorrect. Phew, it took re-implementing the fingerprinting to find this out... --- Side issue: how do people feel about the libpng documentation? Is it OK and the recipes/test programs with it sufficient? I personally don't think so since it took digging around the source comments to find out exactly what the above functions do. Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 9 11:52:45 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id LAA00970 for ; Mon, 9 Sep 1996 11:52:44 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA21277 for png-list-outgoing; Mon, 9 Sep 1996 11:53:18 -0500 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA21271 for ; Mon, 9 Sep 1996 11:53:12 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id JAA26601 for ; Mon, 9 Sep 1996 09:51:00 -0700 X-Sender: davem@mail.cs.ubc.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Sep 1996 09:51:13 -0700 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: Re: sBIT [was Re: In defense of dRNG] Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >This is a very interesting point. During all the discussion of sBIT, I >always looked at sBIT as just providing information for restoring the >original image data during a PNG-to-original-format conversion, not as >something relevant to the viewing software. The PNG spec only hints at your >point. But I think you are right, a *smart* PNG viewer will first restore >the original 5-bit (or whatever) data and then LBR-scale it up to the frame >buffer depth. There are several things you can do to get more accurate display of images where sBIT is smaller than nbits. All are more or less equivalent, so it just depends on the architecture of the viewer which one is "better". As Glenn suggests, you can replace the lower padding bits (which might be zeros) with LBR fill, which is a more accurate rescaling than zero fill, and then treat the values as if they are full 8-bit (or 16-bit) for the purposes of gamma correction and display. Or you can permanently discard the lower insignificant bits, and just make the first transformation that the data undergoes (probably gamma correction) use a lookup table appropriate for the narrower data. For example, just use a 32-entry gamma correction table, where the input values are scaled by dividing by 31 and output is scaled by multiplying by 255. This is actually very useful with 16-bit sample values, as it means you don't need a full 65535-entry table. Or, if you don't want to do the right-shift to get rid of the insignificant bits, you can still get exactly the same results by ignoring the lower insignificant bits of the table index while building the table. For example, if a "standard" gamma-correction LUT gets built by: for (i = 0; i < 256; i++) { intens = (float) i / 255.0; ..... } then the second approach would produce the table for sBIT=5 using for (i = 0; i < 32; i++) { intens = (float) i / 31.0; ..... } and the third approach would use maxval = ((1<<5) - 1) << 3); /* or maxval = (255 >> 3) << 3) */ for (i = 0; i < 256; i++) { intens = (float) ((i>>3)<<3) / maxval; ..... } Or, instead of any of the above, you can do all of the calculations all the way through with 5-bit pixel values and then load a framebuffer LUT that causes the pixel value range 0..31 to cover the full voltage range of the DACs. This is slightly less accurate than carrying 8 bits through all of the calculations, but otherwise workable. By the way, if you ignore sBIT completely and just use the data as if it was 8 bits wide, then the only effect of getting zero-filled data is that the intensity of the image is slightly reduced. Since the brightness reduction is just a multiplicative factor that is the same everywhere in the image, the tonal scale and gamma of the image are not affected - it will "look" the same to the human viewer. It will just be slightly darker than optimum, that's all. So only perfectionist viewers really need worry about sBIT when decoding images for viewing when nbits is 8. (But for 16-bit images, the reduction in lookup table size afforded by sBIT might be well worthwhile). Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 9 12:11:33 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA01404 for ; Mon, 9 Sep 1996 12:11:29 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA21622 for png-list-outgoing; Mon, 9 Sep 1996 12:12:02 -0500 Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA21613 for ; Mon, 9 Sep 1996 12:11:33 -0500 Received: from fb0430.mathematik.th-darmstadt.de (daemon@fb0430.mathematik.th-darmstadt.de [130.83.2.30]) by rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id TAA04678 for ; Mon, 9 Sep 1996 19:09:45 +0200 Received: from fb0408.mathematik.th-darmstadt.de by fb0430.mathematik.th-darmstadt.de (1.37.109.16/Server-1.5/HRZ-THD) id AA050088986; Mon, 9 Sep 1996 19:09:47 +0200 Received: from localhost by fb0408.mathematik.th-darmstadt.de (1.37.109.16/Client-1.5/HRZ-THD) id AA122658982; Mon, 9 Sep 1996 19:09:42 +0200 Date: Mon, 9 Sep 1996 19:09:42 +0200 (MESZ) From: Alexander Lehmann To: PNG List Subject: Re: fING (was Re: Anniversary of chunk proposals) In-Reply-To: <15701.842286090@mint.ukc.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Hello all, On Mon, 9 Sep 1996, Dave Beckett wrote: > >>>>> On Fri, 6 Sep 96 17:43:41 EDT, Glenn Randers-Pehrson ARL-WMRD-TED-TIB said: > Glenn> [ripped apart my fING problems] > > My previous example was bogus, so please ignore it! > > I will try again to explain my problem with pngfprint's > implementation of fING and why I say the bits are wrong, as far as I > understand it. ... > png_set_expand() must be called to do LBR for the <8-bit deep images giving: I think I missed that in testing the program. This only happens in greyscale images with less than 8 bit, palette images should work, since the palette is scaled to 8 bit anyway. Considering Dave's example, I think we have a possibility for a problem with bit depths that are not 1,2,4. When scaling data to 8 bit and then to 16 bit, the result is different than when scaling to 16 bit in the first place. This would mean that images that are stored scaled to 16 bit produce a different print value than when storing them at 8 bit. This could be fixed by having a second print value that considers sbit or that is always based on 8 bit data, but I don't think it is a very likely situation that this actually happens. bye, Alexander -- Alexander Lehmann, | "On the Internet, alex@hal.rhein-main.de (plain, MIME, NeXT) | nobody knows lehmann@mathematik.th-darmstadt.de (plain) | you're a dog." ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 9 12:28:04 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA01583 for ; Mon, 9 Sep 1996 12:28:02 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA21857 for png-list-outgoing; Mon, 9 Sep 1996 12:28:09 -0500 Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA21852 for ; Mon, 9 Sep 1996 12:28:06 -0500 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id MAA10377 for ; Mon, 9 Sep 1996 12:26:09 -0500 (CDT) Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.5/8.7.3) id MAA15233 for png-list@dworkin.wustl.edu; Mon, 9 Sep 1996 12:27:03 -0500 (CDT) Date: Mon, 9 Sep 1996 12:27:03 -0500 (CDT) Message-Id: <199609091727.MAA15233@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: libpng docs (was Re: fING) From: Cave Newt Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Dave asks: >Side issue: how do people feel about the libpng documentation? Is it >OK and the recipes/test programs with it sufficient? I personally >don't think so since it took digging around the source comments to >find out exactly what the above functions do. It's tolerable but needs considerable work. (On the other hand, I don't have time to put into it, so I haven't said anything before now.) But I do recall that the png_set_expand() thing is extremely poorly docu- mented; it does about 8 different things under different conditions, and there's no indication what thing is going to happen when, or how many calls you have to make to get from one image type to another. At the very least it needs a table describing input type and output type for every possible image state. There have been other things where I've had to go read the code, but I forget what right now... Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 9 15:01:06 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA04572 for ; Mon, 9 Sep 1996 15:01:03 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA25421 for png-list-outgoing; Mon, 9 Sep 1996 14:59:50 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA25414 for ; Mon, 9 Sep 1996 14:59:45 -0500 Date: Mon, 9 Sep 96 15:58:27 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: sBIT [was Re: In defense of dRNG] Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609091558.aa03342@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List [Various ways to implement sBIT} Right. Obviously whatever a viewer does, it can combine it all in a LUT... I was just expressing what the effect ought to be. }By the way, if you ignore sBIT completely and just use the data as if it }was 8 bits wide, then the only effect of getting zero-filled data is that }the intensity of the image is slightly reduced. It could be reduced quite a lot if sBIT=1 in an image that is promoted to 8-bit truecolor. I was experimenting with that in a version of the impact_d15.mng file to see if I could get better compression. In this particular case, indexed color worked out better, but the sBIT=1 files filtered better with zero-fill than with LBR-fill, for the reasons we discussed last summer. (with LBR-fill, you get 00, FF, and 01 in the zlib input stream, while with zero-fill you only get 00 and 10.) [...] } Dave ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 9 16:35:28 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA06220 for ; Mon, 9 Sep 1996 16:35:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA28576 for png-list-outgoing; Mon, 9 Sep 1996 16:35:36 -0500 Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA28569 for ; Mon, 9 Sep 1996 16:35:30 -0500 Received: from fb0430.mathematik.th-darmstadt.de (daemon@fb0430.mathematik.th-darmstadt.de [130.83.2.30]) by rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id XAA20639 for ; Mon, 9 Sep 1996 23:34:24 +0200 Received: from fb0409.mathematik.th-darmstadt.de by fb0430.mathematik.th-darmstadt.de (1.37.109.16/Server-1.5/HRZ-THD) id AA058514865; Mon, 9 Sep 1996 23:34:26 +0200 Received: from localhost by fb0409.mathematik.th-darmstadt.de (1.37.109.16/Client-1.5/HRZ-THD) id AA217464862; Mon, 9 Sep 1996 23:34:22 +0200 Date: Mon, 9 Sep 1996 23:34:22 +0200 (MESZ) From: Alexander Lehmann To: PNG List Subject: Re: sBIT [was Re: In defense of dRNG] In-Reply-To: <9609091558.aa03342@THOR.ARL.MIL> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Mon, 9 Sep 1996, Glenn Randers-Pehrson ARL-WMRD-TED-TIB wrote: > [Various ways to implement sBIT} > > Right. Obviously whatever a viewer does, it can combine it all in > a LUT... I was just expressing what the effect ought to be. > > }By the way, if you ignore sBIT completely and just use the data as if it > }was 8 bits wide, then the only effect of getting zero-filled data is that > }the intensity of the image is slightly reduced. > > It could be reduced quite a lot if sBIT=1 in an image that is promoted to > 8-bit truecolor. I was experimenting with that in a version of the > impact_d15.mng file to see if I could get better compression. In this > particular case, indexed color worked out better, but the sBIT=1 files > filtered better with zero-fill than with LBR-fill, for the reasons we > discussed last summer. (with LBR-fill, you get 00, FF, and 01 in > the zlib input stream, while with zero-fill you only get 00 and 10.) Hm, I think this is not explicitly forbidden in the spec, but I think LBR-fill should be strongly discouraged at least with bit depth <= 4, it makes sense for bitdepths >8, most displays will waste the additional precision anyway, but with low bitdepths, the image will be distinctly darker. bye, Alexander -- Alexander Lehmann, | "On the Internet, alex@hal.rhein-main.de (MIME, NeXT) | nobody knows lehmann@mathematik.th-darmstadt.de (MIME) | you're a dog." ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 9 16:51:10 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA06381 for ; Mon, 9 Sep 1996 16:51:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA28844 for png-list-outgoing; Mon, 9 Sep 1996 16:50:27 -0500 Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA28836 for ; Mon, 9 Sep 1996 16:50:18 -0500 Received: from fb0430.mathematik.th-darmstadt.de (daemon@fb0430.mathematik.th-darmstadt.de [130.83.2.30]) by rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id XAA28530 for ; Mon, 9 Sep 1996 23:49:15 +0200 Received: from fb0409.mathematik.th-darmstadt.de by fb0430.mathematik.th-darmstadt.de (1.37.109.16/Server-1.5/HRZ-THD) id AA059115757; Mon, 9 Sep 1996 23:49:17 +0200 Received: from localhost by fb0409.mathematik.th-darmstadt.de (1.37.109.16/Client-1.5/HRZ-THD) id AA217845753; Mon, 9 Sep 1996 23:49:14 +0200 Date: Mon, 9 Sep 1996 23:49:13 +0200 (MESZ) From: Alexander Lehmann To: PNG List Subject: png_set_expand considered harmful (was: fING) In-Reply-To: <15701.842286090@mint.ukc.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Hello all, On Mon, 9 Sep 1996, Dave Beckett wrote: > png_set_expand() must be called to do LBR for the <8-bit deep images > giving: I have played around a bit with that and I now think that png_set_expand is not useful for this case, since it does too many things at once. To get the LBR necessary for the checksum, we can use png_set_expand, but only if the image doesn't contain a trans chunk. In this case, the image data is expanded to contain an alpha channel, which isn't useful in the case the fingerprint. The next thing I tried was to remove the tRNS bit from valid, which doesn't change anything, since there are some flags in png_struct set also, which is obviously not available for user programs (or if they are, they shouldn't be used). So I ended up scaling the data myself, but I think the steps that png_set_expand does should be split into functions that can be turned on separately. While I was at it, I also fixed the bug with calc0 and added IEND detection, otherwise I got a seg violation with PNG files with data after IEND. I have put the new version onto my WWW page and also into incoming at swrinde, where it should be substituted for the 0.1 version, as usual. bye, Alexander -- Alexander Lehmann, | "On the Internet, alex@hal.rhein-main.de (MIME, NeXT) | nobody knows lehmann@mathematik.th-darmstadt.de (MIME) | you're a dog." ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 9 19:38:32 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA07515 for ; Mon, 9 Sep 1996 19:38:32 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA01390 for png-list-outgoing; Mon, 9 Sep 1996 19:38:58 -0500 Received: from inet.htcnet.com (inet.htcnet.com [199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA01385 for ; Mon, 9 Sep 1996 19:38:52 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id TAA17344 for ; Mon, 9 Sep 1996 19:47:52 -0500 Message-Id: <199609100047.TAA17344@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Date: Mon, 9 Sep 1996 19:37:45 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01BB9E86.5FB93480" Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List This is a multi-part message in MIME format. ------=_NextPart_000_01BB9E86.5FB93480 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Can someone please tell me if this image is in a valid PNG format. I am having trouble with a PNG plug in (check page below). and so am wanting to check that the only 3 programs I have are working correctly, and if they are, maybe you could suggest the plug-in author as to what he's doing wrong... image is attached... via mime... -|- Carl Morris (N0YUV) -|- 1:285/302 -|- msftrncs@htcnet.com -|- -|- Hooper Connections BBS -|- 1-(402)-654-2102 -|- 28.8kbps V.34 -|- -|- http://199.120.83.179/~moreese/ -|- ------=_NextPart_000_01BB9E86.5FB93480 Content-Type: application/octet-stream; name="omnilogo.png" Content-Transfer-Encoding: base64 Content-Description: omnilogo (PNG Image) Content-Disposition: attachment; filename="omnilogo.png" iVBORw0KGgoAAAANSUhEUgAAAJ8AAABQBAMAAAD1i7qyAAAAMFBMVEUAAAC/AAAAvwC/vwAAAL+/ AL8Av7/AwMCAgID/AAAA/wD//wAAAP//AP8A//////+E4/ZsAAAG+UlEQVR42uWZv4+bSBTHXcxh qvNRWGeqa1xccX/EBI1YulWq+KqjQLp02ZUsGVcQaRLGFaJYrbfKn3T/ylqyMrji3nsDmF0bbEUp LjqCMDAzn/m+n7vejEbf9/j5O/MQWH3P4/mHA5Zpmqor1il7DJNt+zIQ/Tq5DExHY5p8HdC+Evh8 HTBFYKySarVKNJ30hI95pVUGs+K8UahVQtNWA0AFb+5AZpKO8js6Qcko0TAyhssoM7sahfB5N5qU R6POAu2KPAkzgQknPSFrjGjablQrhON5NL4EHMH1bmQ/Iw2YGbmBgCAIxMJTo/AOgXaJT0MKS5r2 PJqM8IzprIHwjA5sfEgnzBwCkhXmnJDCmIQQkDaYNEAzjYCTQWCtsETAmFSMCDiGbLFPFGraejix m61fAXMK1muF1SWgorwghaiWgLZtEzDFu1cK4SWk1gAwb7bWQEuNAyB7a4UTyONXClOYdQFoFGIY amBcm5zWqflC4d1lYOscDG8XeC7KlOdXKURgeYVCqsyLQGwRKS3AAjaVgsAxpU23UigzqmGgNl3R qMPsM9i8OlPL9jVAWoJND3VNaEVCQD2qnzvdhl72AqGzkTuoA2Kbo+dV3Q+rth+aB0gmRTy7F/gN h+mR54FaCR5kncn7Jnp1R26zI46xSa+yLEu0Up0lL4ClEJYlRHAcXjaE+p1sNlgKIeARrnn14ugC S8RxzxNtc6uk3QwlL54rOZ//Dti5xfqBWswFTyMprOOuPDKg5dy8kuLvVmGAj9L7pxe4lzyUgrG5 ZI3RpeA1iN/WwlgtdW5buA/rV6i5JwRTseA85LWrSk/c0CePzB5c1EYvA1LIo6gXuJfCtrDsfBGI 29owlkY0FrE5vfCZZYyWbG6jQs57gRIiQjJSj4dNUCNBJkkmjWjmc07xWUbBDSqU/QoFF9bE+FuK P+qY8DC6RW9ELCLRAbMCHtAWbDyssPR82+TGfs7m3LjVF4y/J4tDTpZyUBgxuF2GkfGh7AUKJub1 XRjUaNAjIKxgMfyjHZgEuMBX3g0prBP0FLi3gjpbSi7YnKYtZcpD8UEHIExgkWgYAnQaVDIUE/Lh vE/hkos6FBpsDxITShHBakgaBgmIfdK3EO6LbBkEpFDwPoVLWPK+UVinr+/xQICVwuJChDdGIVrP RMo5RTnsjfKSCTmuFbLAQ6AG8yCHfDD7s8VwOx14YhX6Abz0/QkpZL0Kw5Q3PgyYILdCRL6CukCk uQy4IPEpXDh4grFb8mFvlPfM90UdHhGS8dBLAghIADWZLFkE7gfxGOFoziIZ3lKUvT6Fpc+YZWIL Csh4Cd0WCghiMK72IYceBOJhjoY9OA9IYdTbD2GWb7LeC3yLysLzYNFXDvULKAH9BXfl5JQI0pF8 yMM+hVD3TAYmwxnlghZYyGizoPiKCMY8SmTJ+WyWDyusllhVGbbZSH42wZEhLrIwQbBFswTaWUrm OEXhuAkqhKDox7PAEqsK649TisEOFtXVnvvUcETAP2B9osLCdRZvnYdKBox/qHbngdhA0jCCPSX2 wALs8aEpV/HMKX6DiSGPbmLbcdyqOky3SqnY+SIZJvZhdh5YQsFCd5FvfskI6PlMrTdk3F8wGvzk wL3rvquqTaYyIG5+g4pmCEzOAqs737I94b3ZopfcLHAA5brOg4qVXhfwVLhT4MBXLPhBvBT5erZk 6Ob77XmFYB0oTMVHtEBPN2Cdu9guFFrnOq7z9hPeqgwSEU2QSfkAXgeFxaIPCDPjLKHx3XbjLhaG sKp08aDMQV/qNGVVcpiZ34MK1Qukw8Hx9SzB9YVZAr87wX22ejlxZ3wH3hkElgWO32+TGL5luo0z AOa2rte/0kexTSp4d5jlg0AzbvxymHbmOq0Qk3jaWVRr5wvuPQi832JrdpWBH+fqooUXhLgv1Nop HmHqMLBYoBkOGbvrbN5R65gpW1U8fnIOs64LzwAhJtrkL4hYdICtWo1h1ZCTxSNkt7PNB4EHd4PV MSU73E5CHF11gLDqolCbKSTZxyJOhoFAe8g2sywxK9vjCL+f5auiAIO38Kp4afEp8L6YQp06JHD3 kHU2au+f3LeFO1OZq6CO8TIILGZYG0+ZkXK0pgN33jpPMGk9RW/PXv3Z6AToLhSU2jRrA3608xiT DEsa82vtqHwYCJYBRNNq3Y3JUws/oE9W6NQEU6e6APwza1PkRUycduXOaNVFpqG15ReAO4eisTXX 4+wOvM4fEPqEeXMBeP+Qk8Nex6RTJ7VntetOY/Wad2oyQXbUGtZd4LGlNPnjFNkp7/TLI82hlgz3 nYF2rX6qgfG7EweeAVbZ8aq7NXCExzWmVFl1BdAcSdV/lM3g6tzoN3y91YOjP95fif8nwP/6/1b8 C3Lw9hj6GSP8AAAAAElFTkSuQmCC ------=_NextPart_000_01BB9E86.5FB93480-- ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 9 20:50:27 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA07947 for ; Mon, 9 Sep 1996 20:50:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA03013 for png-list-outgoing; Mon, 9 Sep 1996 20:49:48 -0500 Received: from mathtype.com ([206.183.220.144]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA03005 for ; Mon, 9 Sep 1996 20:49:37 -0500 Received: from [206.183.220.130] by mathtype.com with ESMTP (Apple Internet Mail Server 1.1); Mon, 9 Sep 1996 18:45:31 -0800 X-Sender: jimk@pop.mathtype.com Message-Id: In-Reply-To: <8205.842119412@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Sep 1996 18:45:15 -0800 To: PNG List From: Jim King Subject: Re: A proposal for new-chunk process Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 10:03 AM -0800 9/7/96, Tom Lane wrote: >I think a big reason why the currently proposed PNG chunks have been >sitting in limbo for so long is that we don't have any agreed-on >procedure for moving them along, nor any sense of when it's OK to decide >that they're sufficiently "done". With that in mind, here is a modest >proposal. Definitely! >Therefore, I suggest a voting process that's designed to ensure that >adequate review has taken place. Let us agree that a YES vote for a >new chunk proposal signifies "I have read the proposal carefully, >I do not see any technical objections to the new chunk or imprecision >in its definition, and I think it is probably useful enough to go into >the PNG extensions list". A NO vote means you think there's something >wrong with it (and one hopes that people will provide reasons why, >rather than just saying no). If you have not studied the proposal >reasonably carefully, you don't vote. This makes a lot of sense. The only thing I see as missing in your proposal is a way to officially decide that a chunk proposal is dead and should be buried. We could have recurring chunks floating around this list for years that no one really wants just because they haven't ever been removed. How about a similar process for killing a chunk. Once a killing is proposed, a vote should be held to remove it with the same voting criteria as we use for successfully approving the chunk. Jim King Product Manager jimk@mathtype.com ================================================================== Design Science, Inc. Sales: sales@mathtype.com 4028 Broadway Support: support@mathtype.com Long Beach, CA 90803 USA World Wide Web: voice: 310-433-0685 http://www.mathtype.com fax: 310-433-6969 ================================================================== ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 9 20:50:29 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA07948 for ; Mon, 9 Sep 1996 20:50:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA03022 for png-list-outgoing; Mon, 9 Sep 1996 20:50:02 -0500 Received: from mathtype.com ([206.183.220.144]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA03012 for ; Mon, 9 Sep 1996 20:49:47 -0500 Received: from [206.183.220.130] by mathtype.com with ESMTP (Apple Internet Mail Server 1.1); Mon, 9 Sep 1996 18:45:29 -0800 X-Sender: jimk@pop.mathtype.com Message-Id: In-Reply-To: <9609070644.aa26036@THOR.ARL.MIL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Sep 1996 18:37:24 -0800 To: PNG List From: Jim King Subject: Re: Anniversary of chunk proposals Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 2:44 AM -0800 9/7/96, Glenn Randers-Pehrson ARL-WMRD-TED-TIB wrote: >}>aLIG is (I think) immature. >} >}What about it is immature? If it needs more changes, let's make them and >}get it done. > >Lee said it was, back in April when I last tried to get the proposed >chunks moved into the extensions document. He said it needed more >discussion. Since absolutely no more discussion has occurred, I assume >it is still just as immature, but a little more gray and wrinkled. Fair enough. >I have not implemented it myself, and assume no one else has either, >unless you as the proponent have. Not until the thing is real. Lack of browser implimentation really puts a damper on whether or not this is worth it to us, but the chances of us doing it are zero unless it's in a real spec that we can point word processor writers and browser writers to, because there's no way most of the companies we work with will impliment anything unless the definition is frozen. (Thus my note of frustration earlier.) When definitions are frozen we have half a chance. Jim King Product Manager jimk@mathtype.com ================================================================== Design Science, Inc. Sales: sales@mathtype.com 4028 Broadway Support: support@mathtype.com Long Beach, CA 90803 USA World Wide Web: voice: 310-433-0685 http://www.mathtype.com fax: 310-433-6969 ================================================================== ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 9 20:50:47 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA07962 for ; Mon, 9 Sep 1996 20:50:36 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA03006 for png-list-outgoing; Mon, 9 Sep 1996 20:49:38 -0500 Received: from mathtype.com ([206.183.220.144]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA02999 for ; Mon, 9 Sep 1996 20:49:33 -0500 Received: from [206.183.220.130] by mathtype.com with ESMTP (Apple Internet Mail Server 1.1); Mon, 9 Sep 1996 18:45:26 -0800 X-Sender: jimk@pop.mathtype.com Message-Id: In-Reply-To: <9609070657.aa26479@THOR.ARL.MIL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Sep 1996 18:29:03 -0800 To: PNG List From: Jim King Subject: Re: Anniversary of chunk proposals Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 2:57 AM -0800 9/7/96, Glenn Randers-Pehrson ARL-WMRD-TED-TIB wrote: >} >}Is there a particular reason for the (3/4 of height)? >}Seems to me to be an attempt at a guess where you probably don't want a >}guess. >} > >It seems to be a reasonable guess *if* the image depicts a character >from a font. The reason I put 3/4 was as a subliminal reminder to >typographers that 3/4 is 3/4 of the way to the *bottom* of the image, >where they may be thinking of a baseline that is 1/4 of the way to >the top. But what if it isn't? A character from a font is exactly where the creator of the PNG would want to use the aLIG baseline. If the aLIG baseline is left out, I think it's safe to assume that the PNG is NOT a character, nor does it have any intent to align with character baselines. In this case, there should be no need to guess as to what a baseline would be. Instead it should be treated just as if it were any other picuture. IMHO, if the image is simply a picuture, I'd want the bottom of the picutre to line up with my text baseline, thus the default being height rather than (3/4 of height). Jim King Product Manager jimk@mathtype.com ================================================================== Design Science, Inc. Sales: sales@mathtype.com 4028 Broadway Support: support@mathtype.com Long Beach, CA 90803 USA World Wide Web: voice: 310-433-0685 http://www.mathtype.com fax: 310-433-6969 ================================================================== ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 07:40:27 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id HAA12017 for ; Tue, 10 Sep 1996 07:40:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA13276 for png-list-outgoing; Tue, 10 Sep 1996 07:41:08 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id HAA13269 for ; Tue, 10 Sep 1996 07:41:04 -0500 Date: Tue, 10 Sep 96 8:39:06 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Anniversary of chunk proposals Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609100839.aa18919@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List }IMHO, if the image is simply a picuture, I'd want the bottom of the picutre }to line up with my text baseline, thus the default being height rather than }(3/4 of height). So be it. That's how the next version of the proposal will read. It's your chunk... I'm not so happy about the situation where the design must be frozen before anyone will test it. We were pretty lucky with the core PNG spec in that respect, although if we had waited another month before freezing the core spec, some minor things might be different, based on the results with early implementations. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 08:52:46 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA12599 for ; Tue, 10 Sep 1996 08:52:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA14847 for png-list-outgoing; Tue, 10 Sep 1996 08:53:25 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA14842 for ; Tue, 10 Sep 1996 08:53:21 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id JAA21223 for ; Tue, 10 Sep 1996 09:52:15 -0400 (EDT) To: PNG List Subject: Adobe announces PNG support in Photoshop 4.0 Date: Tue, 10 Sep 1996 09:52:14 -0400 Message-ID: <21220.842363534@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Adobe has announced Photoshop 4.0 --- it's not gonna actually ship till November, though. There's fairly extensive material at http://www.adobe.com/prodindex/photoshop/main.html What got my attention was PNG and progressive JPEG support (yay!). So, that's one large company that's followed through on their promise of PNG support ... regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 09:40:29 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA14361 for ; Tue, 10 Sep 1996 09:40:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA16226 for png-list-outgoing; Tue, 10 Sep 1996 09:41:27 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA16219 for ; Tue, 10 Sep 1996 09:41:22 -0500 Date: Tue, 10 Sep 96 10:37:36 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: png-list@dworkin.wustl.edu Subject: More publicity Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609101037.aa22556@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Sun, 8 Sep 1996 12:09:07 +0100, Completely Disorganised From: Paul Oliver Newsgroups: alt.lang.basic,alt.lang.delphi,alt.msdos.programmer,comp.graphics.misc,comp.lang.basic.misc, comp.lang.basic.visual.misc,comp.lang.c,comp.lang.c++,comp.lang.pascal.borland,comp.lang.pascal.delphi.misc, comp.lang.pascal.misc,comp.os.msdos.programmer,comp.programming,demon.homepages.adverts Wotsit's Format http://www.wotsit.demon.co.uk ============================================== The programmer's File Format collection at Wotsit's Format has been updated and now contains details of 54 different file types. Newest additions are: ANI, HQX, PNG, SGI Please drop by and let me know if you find the site useful. I would also like to hear from anyone who has any common file format descriptions that could be added to the collection for others to share. Paul Oliver /---------------------------------------------------------------\ | Wotsit's Format http://www.wotsit.demon.co.uk | \---------------------------------------------------------------/ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 09:45:48 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA15436 for ; Tue, 10 Sep 1996 09:45:46 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA16343 for png-list-outgoing; Tue, 10 Sep 1996 09:46:48 -0500 Received: from inet.htcnet.com (inet.htcnet.com [199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA16336 for ; Tue, 10 Sep 1996 09:46:45 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id JAA21204 for ; Tue, 10 Sep 1996 09:55:47 -0500 Message-Id: <199609101455.JAA21204@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: hindsight... Date: Tue, 10 Sep 1996 09:45:32 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Again I am contributing my hindsight to this list... Yup, you know what that means... I found something in the PNG specification which I think was very badly thought out. Let this just be archived by the list, then if someone else works on this type of thing in the future they can think about it first... The "simple transparency" chuck is awkward for indexed files. Be exact, its just about useless and just a waste of space on images that are supposed to be small... First of all: 1. Palettized images have to provision for RGB bit depths other than 8 bits... 2. Palettized images were designed for display on 8bit palettized displays or similiar. 3. Why does the transparency chuck allow alpha values for palettized images but only on/off for True Color/Gray Scale images? This seems extremely twisted... First of all: 1. The transparency chunk should work the same in all modes in that it only effects one color at a time, for palettized images, either on or off, but for truecolor/grayscale a full alpha value could be specified. This would seem to be more consistent with current use and hardware requirements... Of course, its too late now... I am sure some will have a strong arguement for the palettized alpha transparency, but think about it, any time you need that much alpha control, you problably need more color control too, and should instead be using true color images with full alpha... -|- Carl Morris (N0YUV) -|- 1:285/302 -|- msftrncs@htcnet.com -|- -|- Hooper Connections BBS -|- 1-(402)-654-2102 -|- 28.8kbps V.34 -|- -|- http://199.120.83.179/~moreese/ -|- ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 10:19:51 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA16603 for ; Tue, 10 Sep 1996 10:19:51 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA17447 for png-list-outgoing; Tue, 10 Sep 1996 10:20:41 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id KAA17441 for ; Tue, 10 Sep 1996 10:20:38 -0500 Date: Tue, 10 Sep 96 11:17:56 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609101117.aa23571@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }From: Carl Morris }Date: Mon, 9 Sep 1996 19:37:45 -0500 }This is a multi-part message in MIME format. } }------=_NextPart_000_01BB9E86.5FB93480 }Content-Type: text/plain; charset=ISO-8859-1 }Content-Transfer-Encoding: 7bit } }Can someone please tell me if this image is in a valid PNG format. I }am having trouble with a PNG plug in (check page below). and so am }wanting to check that the only 3 programs I have are working correctly, }and if they are, maybe you could suggest the plug-in author as to what }he's doing wrong... Your image looks fine to me, with viewpng and other programs of mine. Mosaic (with libpng-89c) reads and displays it, too. It's a few bytes larger than it needs to be, having some unused PLTE entries. It lacks a gAMA chunk ;-( ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 11:24:14 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id LAA18328 for ; Tue, 10 Sep 1996 11:24:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA19390 for png-list-outgoing; Tue, 10 Sep 1996 11:23:49 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id LAA19384 for ; Tue, 10 Sep 1996 11:23:43 -0500 Date: Tue, 10 Sep 96 12:21:29 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: hindsight... Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609101221.aa25225@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Corl wrote: }The "simple transparency" chuck is awkward for indexed files. Be }exact, its just about useless and just a waste of space on images that }are supposed to be small... First of all: } }1. Palettized images have [no] provision for RGB bit depths other than 8 }bits... True } }2. Palettized images were designed for display on 8bit palettized }displays or similiar. They were designed for efficient storage of images with 256 or fewer colors } }3. Why does the transparency chuck allow alpha values for palettized }images but only on/off for True Color/Gray Scale images? Because truecolor and grayscale have a full alpha channel available, and the tRNS mechanism would be quite inefficient. For 16-bit grayscale you'd have up to 65k entries, and for 16-bit truecolor you'd have up to 2^48 entries. } }This seems extremely twisted... First of all: } }1. The transparency chunk should work the same in all modes in that it }only effects one color at a time, for palettized images, either on or }off, but for truecolor/grayscale a full alpha value could be specified. You can get that effect in indexed-color images by using color 0 for your transparent color and just having a trns chunk with one entry. For the grayscale and truecolor images, a full alpha channel is more efficient (see above). } }This would seem to be more consistent with current use and hardware }requirements... Of course, its too late now... } }I am sure some will have a strong arguement for the palettized alpha }transparency, but think about it, any time you need that much alpha }control, you problably need more color control too, and should instead }be using true color images with full alpha... } Possibly. But consider the MNG fADE chunk. You don't need much alpha control, but just want to be able to give all opaque pixels the same amount of alpha. Here you need alpha control but not necessarily fine color control... you might be fading a 3-color logo. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 11:33:36 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id LAA18529 for ; Tue, 10 Sep 1996 11:33:23 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA19617 for png-list-outgoing; Tue, 10 Sep 1996 11:33:54 -0500 Received: from u11.CS.Berkeley.EDU (u11.CS.Berkeley.EDU [128.32.38.135]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA19612 for ; Tue, 10 Sep 1996 11:33:48 -0500 Received: (from amc@localhost) by u11.CS.Berkeley.EDU (8.6.11/8.6.9) id JAA09607 for png-list@dworkin.wustl.edu; Tue, 10 Sep 1996 09:32:32 -0700 Date: Tue, 10 Sep 1996 09:32:32 -0700 Message-Id: <199609101632.JAA09607@u11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: hindsight... X-Advice: perhaps read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List "Carl Morris" says: > 1. Palettized images have to provision for RGB bit depths other than 8 > bits... I don't see why. Do you say this because multiplying an 8-bit R, G, or B value by an 8-bit A value produces a 16-bit result? Just chop it down to 8 bits. > 3. Why does the transparency chuck allow alpha values for palettized > images but only on/off for True Color/Gray Scale images? With true color and grayscale images, you already have the option of full alpha values with the color type field of IHDR. I agree that tRNS serves two entirely different purposes depending on whether the image is indexed color or not, and perhaps it should have been two separate chunks, but it doesn't really matter. > 1. The transparency chunk should work the same in all modes in that > it only effects one color at a time, for palettized images, either on > or off, Then there would be no way at all to get full alpha values for indexed color images. > but for truecolor/grayscale a full alpha value could be specified. That would be easy, but not very useful. How often is it true that a true color image's partially transparent pixels all have the exact same RGB values (or just a few different RGB values)? > I am sure some will have a strong arguement for the palettized alpha > transparency, but think about it, any time you need that much alpha > control, you problably need more color control too, and should instead > be using true color images with full alpha... There is a very specific but very useful situation in which tRNS is useful for indexed color images: anti-aliased characters or logos. Imagine an image with very few colors, round or diagonal edges, and a fully transparent background. Anti-aliasing at the edges (i.e. setting the color and alpha of pixels that straddle the outline to a weighted average of the values on either side) will introduce more RGBA values, but often less than 256 of them (or a useful set of 256 can be selected). This RGBA palette can be composed against any solid-color background, preserving the smoothed edges, without increasing the number of colors in the palette. Compare that to what you get with on/off transparency: either jagged edges, or halos. (Halos result when the image author performs anti-aliasing assuming a specific background color, which is not the background color chosen by the image viewer.) You see this all the time on the web. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 13:21:02 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA19998 for ; Tue, 10 Sep 1996 13:21:01 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA21960 for png-list-outgoing; Tue, 10 Sep 1996 13:21:31 -0500 Received: from mathtype.com ([206.183.220.144]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA21949 for ; Tue, 10 Sep 1996 13:21:21 -0500 Received: from [206.183.220.130] by mathtype.com with ESMTP (Apple Internet Mail Server 1.1); Tue, 10 Sep 1996 11:17:33 -0800 X-Sender: jimk@pop.mathtype.com Message-Id: In-Reply-To: <9609100839.aa18919@THOR.ARL.MIL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Sep 1996 10:23:48 -0800 To: PNG List From: Jim King Subject: Re: Anniversary of chunk proposals Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >I'm not so happy about the situation where the design must be frozen >before anyone will test it. We were pretty lucky with the core PNG >spec in that respect, although if we had waited another month before >freezing the core spec, some minor things might be different, based on >the results with early implementations. Point taken. How much did you pay Carl to write his 'hindsight...' message on the same day you said this? :'} On the other hand, it's a very real problem that it's tough to sell a dream. On the evangelism front, you'll convince hackers and shareware authors to impliment something that is still experimental, but not companies who are paying high priced programmers. Notice that Adobe is just now willing to put PNG into PhotoShop, when the spec has been frozen for months. They didn't put it into the last version of PhotoShop, even though the PNG spec was pretty much done when they were working on it. Jim King Product Manager jimk@mathtype.com ================================================================== Design Science, Inc. Sales: sales@mathtype.com 4028 Broadway Support: support@mathtype.com Long Beach, CA 90803 USA World Wide Web: voice: 310-433-0685 http://www.mathtype.com fax: 310-433-6969 ================================================================== ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 14:35:07 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA20885 for ; Tue, 10 Sep 1996 14:35:05 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA23341 for png-list-outgoing; Tue, 10 Sep 1996 14:35:08 -0500 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA23332 for ; Tue, 10 Sep 1996 14:35:02 -0500 Received: by mail2.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24) id <01BB9F13.457FF7B0@mail2.microsoft.com>; Tue, 10 Sep 1996 12:26:20 -0700 Message-ID: From: John Bowler To: "'PNG List'" Subject: RE: Anniversary of chunk proposals Date: Tue, 10 Sep 1996 12:26:39 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Encoding: 21 TEXT Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >From: Jim King[SMTP:jimk@mathtype.com] >On the evangelism front, you'll convince hackers and shareware >authors to impliment something that is still experimental, but not >companies who are paying high priced programmers. Notice that Adobe is >just now willing to put PNG into PhotoShop, when the spec has been frozen >for months. They didn't put it into the last version of PhotoShop, even >though the PNG spec was pretty much done when they were working on it. A cynic might observe that there are still bugs and problems in libpng, and that has a head start on any other development. You do Adobe a disservice - they show sufficient foresight to put in support for a file format which is not currently supported in any main stream commercial application but which they, presumably, think will become important. Adobe's product development cycle will not be greatly different from any company I have worked for. On that basis (I don't know anything else apart from public announcements) I would guess they started work on this before the PNG spec was finalized and certainly before it obtained standards body approval :-) John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 17:07:28 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id RAA23337 for ; Tue, 10 Sep 1996 17:07:25 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA25497 for png-list-outgoing; Tue, 10 Sep 1996 17:06:20 -0500 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA25486 for ; Tue, 10 Sep 1996 17:06:14 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id PAA20209 for ; Tue, 10 Sep 1996 15:05:04 -0700 X-Sender: davem@mail.cs.ubc.ca (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Sep 1996 15:05:07 -0700 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: Re: Anniversary of chunk proposals Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >I'm not so happy about the situation where the design must be frozen >before anyone will test it. We were pretty lucky with the core PNG >spec in that respect, although if we had waited another month before >freezing the core spec, some minor things might be different, based on >the results with early implementations. I'll echo that sentiment. It seems to me that where we (the committee) made good decisions, it was often because one or more people had previous experience implementing a particular feature, or lots of experience with a *bad* implementation of that feature in some other file format. And the places where we made (in hindsight) poor decisions were where nobody on the committee had much experience but we had to make a decision anyway. Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 17:07:33 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id RAA23343 for ; Tue, 10 Sep 1996 17:07:32 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA25498 for png-list-outgoing; Tue, 10 Sep 1996 17:06:22 -0500 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA25491 for ; Tue, 10 Sep 1996 17:06:17 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id PAA20197 for ; Tue, 10 Sep 1996 15:05:00 -0700 X-Sender: davem@mail.cs.ubc.ca (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Sep 1996 15:05:05 -0700 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: Re: Adobe announces PNG support in Photoshop 4.0 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >Adobe has announced Photoshop 4.0 --- it's not gonna actually ship >till November, though. There's fairly extensive material at > http://www.adobe.com/prodindex/photoshop/main.html >What got my attention was PNG and progressive JPEG support (yay!). Hmm. Any likelihood of someone getting a beta test copy so we can make sure that things like gAMA and alpha and cHRM work right? Or is there an extensive enough test suite somewhere that the Adobe people can do thorough testing on their own? Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 18:39:57 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA24755 for ; Tue, 10 Sep 1996 18:39:54 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA27022 for png-list-outgoing; Tue, 10 Sep 1996 18:39:49 -0500 Received: from llyene.jpl.nasa.gov (llyene.jpl.nasa.gov [128.149.75.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA27017 for ; Tue, 10 Sep 1996 18:39:43 -0500 Received: from quest.jpl.nasa.gov (quest.jpl.nasa.gov [128.149.75.43]) by llyene.jpl.nasa.gov (8.6.8/8.6.6) with SMTP id QAA11702; Tue, 10 Sep 1996 16:38:01 -0700 Received: by quest.jpl.nasa.gov (NX5.67f2/NX3.0S) id AA02832; Tue, 10 Sep 96 16:36:48 -0700 Message-Id: <9609102336.AA02832@quest.jpl.nasa.gov> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) X-Image-Url: http://quest.jpl.nasa.gov/mark-face.gif In-Reply-To: X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.118.2) From: Mark Adler Date: Tue, 10 Sep 96 16:36:45 -0700 To: Zip-Bugs@LISTS.WKU.EDU, png-list@dworkin.wustl.edu Subject: me References: Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Hey, I got my 10 minutes of fame! (Or is that 15 minutes?) Not related to compression though. I made the New York Times today in the science section on Mars missions. mark ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 18:55:14 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA24981 for ; Tue, 10 Sep 1996 18:55:12 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA27318 for png-list-outgoing; Tue, 10 Sep 1996 18:54:40 -0500 Received: from SantaClara01.pop.internex.net (SantaClara01.POP.InterNex.Net [205.158.3.18]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA27312 for ; Tue, 10 Sep 1996 18:54:31 -0500 Received: from utility.PUMATECH.COM ([205.158.186.131]) by SantaClara01.pop.internex.net (post.office MTA v1.9.3 ID# 0-11030) with SMTP id AAA4624 for ; Tue, 10 Sep 1996 16:52:55 -0700 Received: by utility.PUMATECH.COM with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB9F38.22617D60@utility.PUMATECH.COM>; Tue, 10 Sep 1996 16:50:12 +0100 Message-ID: From: Mike White To: "'png-list@dworkin.wustl.edu'" , "'Zip-Bugs@LISTS.WKU.EDU'" Subject: RE: me Date: Tue, 10 Sep 1996 16:50:07 +0100 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Congradulations... Now if you can figure out a way to compress the time for the missions to actually get to Mars, you'll be in line for a Nobel prize. /Mike >---------- >From: Mark Adler[SMTP:Mark.Adler@quest.jpl.nasa.gov] >Sent: Tuesday, September 10, 1996 4:36 PM >To: Zip-Bugs@LISTS.WKU.EDU; png-list@dworkin.wustl.edu >Subject: me > >Hey, I got my 10 minutes of fame! (Or is that 15 minutes?) Not related to >compression though. I made the New York Times today in the science section >on >Mars missions. > >mark > ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 19:06:00 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA25058 for ; Tue, 10 Sep 1996 19:05:59 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA27594 for png-list-outgoing; Tue, 10 Sep 1996 19:06:39 -0500 Received: from inet.htcnet.com (inet.htcnet.com [199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA27589 for ; Tue, 10 Sep 1996 19:06:29 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id TAA22147 for ; Tue, 10 Sep 1996 19:15:32 -0500 Message-Id: <199609110015.TAA22147@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: Re: Date: Tue, 10 Sep 1996 19:05:15 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List | Your image looks fine to me, with viewpng and other programs of mine. | Mosaic (with libpng-89c) reads and displays it, too. It's a few bytes | larger than it needs to be, having some unused PLTE entries. | It lacks a gAMA chunk ;-( Yea, but no program I have is smart enough to remove the extra entries, or I would! :) Its probably too simple of in image to desire gamma ... with only 16 colors in the palette, its idealized for display on 16 colors systems... also, no program I have will correctly add such a chunk :( ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 19:13:45 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA25099 for ; Tue, 10 Sep 1996 19:13:43 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA28059 for png-list-outgoing; Tue, 10 Sep 1996 19:14:13 -0500 Received: from inet.htcnet.com (inet.htcnet.com [199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA28054 for ; Tue, 10 Sep 1996 19:14:10 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id TAA22163 for ; Tue, 10 Sep 1996 19:23:14 -0500 Message-Id: <199609110023.TAA22163@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: Re: hindsight... Date: Tue, 10 Sep 1996 19:12:58 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List | I don't see why. Do you say this because multiplying an 8-bit R, G, or | B value by an 8-bit A value produces a 16-bit result? Just chop it down | to 8 bits. No, its just a point, since palettized PNG images are so simple to begin with, why add complicated alpha to something that can really have much alpha anyway... | > 1. The transparency chunk should work the same in all modes in that | > it only effects one color at a time, for palettized images, either on | > or off, | | Then there would be no way at all to get full alpha values for indexed | color images. On a palettized 8 bit display, the ones 8bit palettized images are designed for, there is no way for any alpha other than "lucky" matching and redithering... | That would be easy, but not very useful. How often is it true that a | true color image's partially transparent pixels all have the exact same | RGB values (or just a few different RGB values)? How likely is it that each palette entry needs a different alpha? | There is a very specific but very useful situation in which tRNS is | useful for indexed color images: anti-aliased characters or logos. | Imagine an image with very few colors, round or diagonal edges, and | a fully transparent background. Anti-aliasing at the edges (i.e. To me, anti aliasing is a joke... I have been using 16 color video for years, to me its just in the way, and so its the TRNS chunk when all I want is 1 entry to be alphaed and have no control over the software I use to create the images ... in this case, PSP stores the transparent entry at the end of the palette table by default so the whole chunck is required... | color, which is not the background color chosen by the image viewer.) | You see this all the time on the web. No, I don't, as 16 colors can't display half the stuff you guys send my way ... :( ... None the less, I think my biggest point would be that TRNS is too complicated for a 256/palettized image (smaller images with less than 256 colors)... ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 19:21:06 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA25130 for ; Tue, 10 Sep 1996 19:21:03 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA28205 for png-list-outgoing; Tue, 10 Sep 1996 19:21:42 -0500 Received: from inet.htcnet.com (inet.htcnet.com [199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA28200 for ; Tue, 10 Sep 1996 19:21:38 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id TAA22206 for ; Tue, 10 Sep 1996 19:30:44 -0500 Message-Id: <199609110030.TAA22206@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: Re: hindsight... Date: Tue, 10 Sep 1996 19:20:27 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List | }2. Palettized images were designed for display on 8bit palettized | }displays or similiar. | | They were designed for efficient storage of images with 256 or fewer colors I have found a few images better converted to true color and compressed with PNG's filters rather than being palettized... | Because truecolor and grayscale have a full alpha channel available, and | the tRNS mechanism would be quite inefficient. For 16-bit grayscale you'd | have up to 65k entries, and for 16-bit truecolor you'd have up to 2^48 | entries. Not always, its most inefficient right now for palettized images... Already, the little 32x32x16 icons I use are larger compressed in PNG than GIF, and the PNG files I was producing didn't have any transparency in them, the GIF's did... Now I have a program that can put TRNS chunks in the files, but the file size took another large jump, making it extremely not worth my time to use PNG for small images with simple transparency... | You can get that effect in indexed-color images by using color 0 for your | transparent color and just having a trns chunk with one entry. For | the grayscale and truecolor images, a full alpha channel is more efficient | (see above). I don't have any control over where the transparent color is ... sure, there are "shortcuts" but, as I can see it, the programs I use won't write a palette any smaller than 256 colors unless its 16 colors, so I don't see why those same programs would optimize the palette to cut the TRNS chunk down in size... Hopefully they will think about this, but I don't know if anyone from MS, PSP, even Adobe really monitor this groups discussions... ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 20:26:28 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA25355 for ; Tue, 10 Sep 1996 20:26:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA29427 for png-list-outgoing; Tue, 10 Sep 1996 20:26:49 -0500 Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA29422 for ; Tue, 10 Sep 1996 20:26:46 -0500 Received: from www47.inria.fr (www47.inria.fr [138.96.48.120]) by wugate.wustl.edu (8.7.5/8.7.3) with ESMTP id UAA22308 for ; Tue, 10 Sep 1996 20:26:19 -0500 Received: by www47.inria.fr (8.6.13/8.6.12) id DAA26076; Wed, 11 Sep 1996 03:20:46 +0200 Date: Wed, 11 Sep 1996 03:20:46 +0200 From: Chris Lilley Message-Id: <199609110120.DAA26076@www47.inria.fr> To: PNG List Subject: Re: Adobe announces PNG support in Photoshop 4.0 In-Reply-To: References: Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Dave beta testers are sworn to secrecy with a non disclosure agreement so I can't tell you my findings with my copy. Oops .. too late, no delete key ;-) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 20:34:47 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA25390 for ; Tue, 10 Sep 1996 20:34:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA29578 for png-list-outgoing; Tue, 10 Sep 1996 20:35:34 -0500 Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA29573 for ; Tue, 10 Sep 1996 20:35:30 -0500 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id UAA26837 for ; Tue, 10 Sep 1996 20:33:18 -0500 (CDT) Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.5/8.7.3) id UAA09536 for png-list@dworkin.wustl.edu; Tue, 10 Sep 1996 20:34:11 -0500 (CDT) Date: Tue, 10 Sep 1996 20:34:11 -0500 (CDT) Message-Id: <199609110134.UAA09536@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: mainstream apps (was RE: Anniversary of chunk proposals) From: Cave Newt Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List John Bowler wrote: >disservice - they show sufficient foresight to put in support for a file >format which is not currently supported in any main stream commercial >application but which they, presumably, think will become important. Presumably "main stream commercial application" refers to Windows apps in this context... Even within that limited arena, I find it hard to believe that you could dismiss *all* of the following as non-mainstream: 3D Studio MAX Freehand Graphics Studio HiJaak 95 Paint Shop Pro Ulead stuff (ImagePals, VideoStudio, etc.) WebImage ...not even counting your own company's repeated claims that PNG would be supported in Internet Explorer within the 3.0 timeframe. (And I just heard that the PNG-supporting WebFX plug-in technology is now owned by Netscape and transmogrified into Live3D, so maybe Navigator is a wee bit closer to real support. As far as I can tell, Live3D still exists only as a plug-in, though.) Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 21:35:15 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id VAA25672 for ; Tue, 10 Sep 1996 21:35:13 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA00620 for png-list-outgoing; Tue, 10 Sep 1996 21:35:30 -0500 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id VAA00614 for ; Tue, 10 Sep 1996 21:35:26 -0500 Received: by mail3.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB9F4F.1046AA80@mail3.microsoft.com>; Tue, 10 Sep 1996 19:34:20 -0700 Message-ID: From: John Bowler To: "'PNG List'" Subject: RE: (16 color image) Date: Tue, 10 Sep 1996 19:34:13 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 15 TEXT Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > >From: Carl Morris[SMTP:msftrncs@htcnet.com] > >Its probably too simple of in image to desire gamma ... with only 16 >colors in the palette, its idealized for display on 16 colors >systems... also, no program I have will correctly add such a chunk :( Even for such images adding gamma is probably a good idea if the image is in the native format of a platform with a known default gamma (e.g. Mac or, even, Windows where the appropriate gamma is almost always ~0.45). If this is not done information has been implicitly lost - PICT for example implies Mac gamma, BMP implies the image is appropriate for display on a PC. John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 10 22:06:09 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id WAA25851 for ; Tue, 10 Sep 1996 22:06:01 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id WAA00925 for png-list-outgoing; Tue, 10 Sep 1996 22:06:57 -0500 Received: from tide21.microsoft.com (tide21.microsoft.com [131.107.3.31]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id WAA00918 for ; Tue, 10 Sep 1996 22:06:53 -0500 Received: by tide21.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BB9F53.6FAC5ED0@tide21.microsoft.com>; Tue, 10 Sep 1996 20:05:38 -0700 Message-ID: From: John Bowler To: "'PNG List'" Subject: RE: mainstream apps (was RE: Anniversary of chunk proposals) Date: Tue, 10 Sep 1996 20:05:16 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 37 TEXT Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >From: Cave Newt[SMTP:newt@pobox.com] >Sent: Tuesday, September 10, 1996 6:34 PM > >Presumably "main stream commercial application" refers to Windows apps >in this context... Not particularly. Are you saying that the gloom previously expressed on this list is invalid? Personally I tend to agree - acceptance of PNG is increasing, gradually. >Even within that limited arena, I find it hard to >believe that you could dismiss *all* of the following as non-mainstream: > > 3D Studio MAX > Freehand Graphics Studio > HiJaak 95 > Paint Shop Pro > Ulead stuff (ImagePals, VideoStudio, etc.) > WebImage Like PhotoShop these are all image processing apps I think (not sure about 3D Studio Max and maybe the WebImage isn't really in this class). My statement was imprecise - there are producers but no consumers (a generalization). As a file interchange format PNG is important because of its ability to handle most other common formats in a consistent and simple way, that means both ends of the process are needed. Devil's advocate time... Where are the multi-media creation tools? What about the illustration packages (Freehand Graphics Studio maybe?)? What about the print service bureaus? Desktop publishing? In the absence of these clients, why should the image processing app. manufacturers care (of course they do, Adobe's support is evidence of that)? John Bowler > ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 11 05:39:46 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id FAA29030 for ; Wed, 11 Sep 1996 05:39:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA06713 for png-list-outgoing; Wed, 11 Sep 1996 05:40:35 -0500 Received: from epfl2 (epfl2.epflbalto.org [192.188.199.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id FAA06707 for ; Wed, 11 Sep 1996 05:40:30 -0500 Received: by epfl2 (5.0/SMI-SVR4) id AA07916; Wed, 11 Sep 1996 06:37:48 -0400 Date: Wed, 11 Sep 1996 06:37:47 -0400 (EDT) From: Glenn Randers-Pehrson To: PNG List Subject: Re: hindsight... In-Reply-To: <199609110030.TAA22206@inet.htcnet.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Tue, 10 Sep 1996, Carl Morris wrote: > Date: Tue, 10 Sep 1996 19:20:27 -0500 > From: Carl Morris > To: PNG List > Subject: Re: hindsight... > > I don't have any control over where the transparent color is ... sure, > there are "shortcuts" but, as I can see it, the programs I use won't > write a palette any smaller than 256 colors unless its 16 colors, so I > don't see why those same programs would optimize the palette to cut the > TRNS chunk down in size... Hopefully they will think about this, but I > don't know if anyone from MS, PSP, even Adobe really monitor this > groups discussions... You do have control over where the transparent color falls in the PLTE. If you are converting GIFs, they have one color index that is transparent. Construct a PNG PLTE that maps that color, whatever its GIF index might be, to zero, and maps the GIF color zero to some other color (the index just abandoned by the transparent color, for example). That's what I did, and I never needed a tRNS chunk with more than one entry when converting GIFs. If the programs you use aren't under your control, then get different programs... Or write a png-to-png that removes the wasted PLTE entries and moves the transparent color to index 0. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 11 09:51:51 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id JAA01826 for ; Wed, 11 Sep 1996 09:51:47 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA09307 for png-list-outgoing; Wed, 11 Sep 1996 09:52:23 -0500 Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA09288 for ; Wed, 11 Sep 1996 09:52:15 -0500 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id JAA13774 for ; Wed, 11 Sep 1996 09:50:07 -0500 (CDT) Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.5/8.7.3) id JAA13142 for png-list@dworkin.wustl.edu; Wed, 11 Sep 1996 09:51:02 -0500 (CDT) Date: Wed, 11 Sep 1996 09:51:02 -0500 (CDT) Message-Id: <199609111451.JAA13142@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: RE: mainstream apps From: Cave Newt Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List John Bowler wrote: >Not particularly. Are you saying that the gloom previously expressed on >this list is invalid? Personally I tend to agree - acceptance of PNG is >increasing, gradually. Yes, I said it then, and I'll repeat it now: acceptance of PNG has been slower than most of us expected and/or hoped, but it's definitely gaining momentum and big-name support. (Publicity and continued ports by the group are still important, of course, as noted previously, but I think PNG's acceptance would continue to grow even if we all disappeared tomorrow.) >> 3D Studio MAX >> Freehand Graphics Studio >> HiJaak 95 >> Paint Shop Pro >> Ulead stuff (ImagePals, VideoStudio, etc.) >> WebImage >Like PhotoShop these are all image processing apps I think (not sure >about 3D Studio Max and maybe the WebImage isn't really in this class). 3D Studio MAX is a 3D world-builder app; its support is via VRML 2.0 export capability. I included WebImage because it's recently gotten some pretty good press; it's hard to tell if that means it's popular or just a nicely done also-ran. >My statement was imprecise - there are producers but no consumers (a >generalization). As a file interchange format PNG is important because >of its ability to handle most other common formats in a consistent and >simple way, that means both ends of the process are needed. OK, but aside from browsers (an admitted weakness), how many big-name image viewers are there? Almost every one I've ever used or heard of, whether for Windows or Unix/X or Amiga or whatever, could probably be argued as "non-mainstream" on the basis of market share, and yet there are more viewers available than any other category (by roughly a factor of two). This includes commercial ones like Paul's CompuPic and Ulead's Viewer in addition to all of the popular freeware/shareware ones (ACDSee, XV, Display, Graphic Workshop, Image Alchemy, ImageMagick, PMView, Poly- View, etc.). Possibly it's precisely the fact that there are so many that prevents one or two of them from being anointed mainstream. Even so, Hi- Jaak has definitely made a name for itself over the last decade. >Where are the multi-media creation tools? Scala MM100? Ulead MediaStudio/VideoStudio? HoTMetaL Pro? >What about the illustration packages (Freehand Graphics Studio maybe?)? How does that differ from normal image-creation packages? That is, what are some examples? Freehand and Photoshop come to mind; PhotoStyler doesn't exist anymore but has "official" plug-in support (Ulead wrote all of their file converters); are there others? >What about the print service bureaus? I haven't been tracking this and wouldn't know where to start. Some of them may even support PNG already. >Desktop publishing? So FrameMaker and MSWord import capabilities? No support that I'm aware of, but I'd consider this a "later domino" than high-end image producers and web browsers. >why should the image processing app. manufacturers care (of course they >do, Adobe's support is evidence of that)? I'd argue that they should care regardless, simply because of the technical aspects--a single file format that can do pretty much everything TIFF can (deep images, alpha channel, better compression, lossless) as well as almost everything GIF can (i.e., indexed color, simple transparency), plus some nice extras (gamma, indexed alpha). It's just about ideal as a universal image-editing format, even if JPEG (for example) is your final target. I've kind of lost track of what we're arguing about (if anything :-) ), but even if Photoshop is the "biggest-name" app with PNG support so far, it seems to me that there are a *lot* of runners up. Netscape Navigator is the one other "really big-name" app that I'd like to see; much of the rest would follow if they'd take the lead. But Photoshop really helps. Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 11 15:18:56 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA06091 for ; Wed, 11 Sep 1996 15:18:56 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA15570 for png-list-outgoing; Wed, 11 Sep 1996 15:19:11 -0500 Received: from inet.htcnet.com ([199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA15559 for ; Wed, 11 Sep 1996 15:19:02 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id PAA27064 for ; Wed, 11 Sep 1996 15:18:25 -0500 Message-Id: <199609112018.PAA27064@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: Re: hindsight... Date: Wed, 11 Sep 1996 15:16:56 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List | You do have control over where the transparent color falls in the PLTE. If | you are converting GIFs, they have one color index that is transparent. | Construct a PNG PLTE that maps that color, whatever its GIF index might be, | to zero, and maps the GIF color zero to some other color (the index just | abandoned by the transparent color, for example). That's what I did, and I | never needed a tRNS chunk with more than one entry when converting GIFs. When will you learn I am a user of software, not an author! (Sure, I program, but not graphical apps)... | If the programs you use aren't under your control, then get different | programs... Or write a png-to-png that removes the wasted PLTE entries | and moves the transparent color to index 0. I might as well, I got "proof" that JASC, makers of PSP, reduced their compression engine to make it faster... I don't want faster compression.... I want BETTER compression... ARG! ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 11 15:46:54 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA06340 for ; Wed, 11 Sep 1996 15:46:52 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA15965 for png-list-outgoing; Wed, 11 Sep 1996 15:47:30 -0500 Received: from inet.htcnet.com ([199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA15958 for ; Wed, 11 Sep 1996 15:47:18 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id PAA27130 for ; Wed, 11 Sep 1996 15:46:48 -0500 Message-Id: <199609112046.PAA27130@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: PNG Advertising... Date: Wed, 11 Sep 1996 15:45:18 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Maybe a way to gain more support in PNG would be to get permission to post a small FAQ on PNG in the image news groups. This FAQ could contain user and programmer related questions/answers and guide people to the light, if you get what I mean... :) -|- Carl Morris (N0YUV) -|- 1:285/302 -|- msftrncs@htcnet.com -|- -|- Hooper Connections BBS -|- 1-(402)-654-2102 -|- 28.8kbps V.34 -|- -|- http://199.120.83.179/~moreese/ -|- ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 11 16:49:57 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id QAA06998 for ; Wed, 11 Sep 1996 16:49:56 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA17038 for png-list-outgoing; Wed, 11 Sep 1996 16:50:18 -0500 Received: from sass165.sandia.gov (sass165.sandia.gov [132.175.109.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA17032 for ; Wed, 11 Sep 1996 16:50:12 -0500 Received: from tfrench.csu890.sandia.gov (jecurti.csu890.sandia.gov [134.253.34.71]) by sass165.sandia.gov (8.6.12/8.6.12) with SMTP id PAA27011 for ; Wed, 11 Sep 1996 15:50:04 -0600 Message-Id: <199609112150.PAA27011@sass165.sandia.gov> Comments: Authenticated sender is From: "Todd French" To: png-list@dworkin.wustl.edu Date: Wed, 11 Sep 1996 15:50:07 -0700 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: New Chunks Priority: normal X-mailer: Pegasus Mail for Windows (v2.33) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Hi all, Below I describe my experience with implementing faLS, pcAL and drNG. Sorry about the length. I tried to keep it short but the words add up fast. >Todd, did you ever implement fALS, pCAL, and dRNG? Dave, did you ever >implement lOGE? Or are we all waiting for Guy to do it? I have implemented faLS, pcAL and drNG. My current programs use the draft 0.960406 PNG Scientific Visualization Chunks document in which pcAL was called zsCL and pcAL equation type 3 was not defined. I use these chunks to describe images from fluorescence instrumentation (mostly a microscope). The images contain 2D data that can be intensity, decay time, polarization, specral ratio and other such things. pcAL gives me the relation between digitizer output (stored numbers) and real values. faLS stores the false color table used to highlight important aspects of the image. drNG gives me a way to store the unaltered image and display the most useful range of data. The biggest problem I have with any of these chunks is that I have about 10-20,000 images to change whenever I change the format in the programs. Is there a way that draft chunks could have a version number so that the software could properly recognize older draft chunks. I've decided next time I update, it will be either with formal chunks or I'll include a unique text keyword such as "drNG version":"0.960406". pcAL: I have no use for equation types other than #0 (linear). The linear calibration suits my needs exactly. The other equation types are quite harmless and easy to implement. I have had occasion in the past to use exponential scaling al la eq #1. I have been storing the equivalent information in these images for about 3 years. faLS: This is much better than my original implementation. The faLS chunk compresses the 256 color palettes I use very well. The palettes are usually just ramps up and down of various colors. The 768 bytes (256*rgb 8 bit) of memory I use are normally stored as less than 500 as faLS. One palette stores as about 1700. I had to convert to color palettes I already had to gamma=1 to match the images. One thing I wish were included is a palette ID of some sort. The program which displays the images stores only one copy of each palette no matter how many images are using it. When a new image is loaded, I have to compare the entire palette to every one in memory. It would be easier if there were an ID attached to each palette. As it stands faLS works well for me. If it had an ID it would even be better. I have been storing false color palettes in these images for about 4 years. drNG: This chunk is critical to the way I want to store 2D data. Sometimes there are points in an image that are aberrently bright or there is a non-zero background. Although these points can easily be removed, I loath the removal of any of the raw data. I could just store the original image, the current best view and the changes but it is better to have just the original. Less chance of losing one, less storage required (there can easily be several hundred images created in a day). Without drNG, in my system, the image is still viewable. It just might have a background that is not zero. This is not a mistake, it is the exact image collected from the microscope. Sometimes the image just does not have values that span the full range of the detector. I have never had any problem with drNG in my system. This information has been stored in these kind of images for about 4 years. The ability of max and min to be outside the valid data range was added after the first implementations. All of the users (including me) kept asking for it until I finally added it. -todd -------------------------------------------------- Todd French Sandia National Labs tfrench@sandia.gov ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 11 17:55:25 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id RAA08016 for ; Wed, 11 Sep 1996 17:55:25 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA18050 for png-list-outgoing; Wed, 11 Sep 1996 17:55:52 -0500 Received: from epfl2 (epfl2.epflbalto.org [192.188.199.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id RAA18045 for ; Wed, 11 Sep 1996 17:55:47 -0500 Received: by epfl2 (5.0/SMI-SVR4) id AA29419; Wed, 11 Sep 1996 18:53:02 -0400 Date: Wed, 11 Sep 1996 18:53:02 -0400 (EDT) From: Glenn Randers-Pehrson To: PNG List Subject: Re: New Chunks In-Reply-To: <199609112150.PAA27011@sass165.sandia.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > > The biggest problem I have with any of these chunks is that I have > about 10-20,000 images to change whenever I change the format in the > programs. Is there a way that draft chunks could have a version > number so that the software could properly recognize older draft > chunks. I've decided next time I update, it will be either with > formal chunks or I'll include a unique text keyword such as "drNG > version":"0.960406". That would work. Once we register the chunks you won't have to do that any more. > faLS: > > One thing I wish were included is a palette ID of some sort. I was thinking about that very thing, today, while working on the next draft for MNG, which uses the "keywords" to select chunks to be copied from one frame to the next, in tEXt, zTXt, and spLT; I was wishing faLS had a name, too, for such management purposes. > program which displays the images stores only one copy of each > palette no matter how many images are using it. When a new image is > loaded, I have to compare the entire palette to every one in memory. > It would be easier if there were an ID attached to each palette. > > As it stands faLS works well for me. If it had an ID it would even > be better. I have been storing false color palettes in these images > for about 4 years. I'll add a "false palette name" field. > > drNG: Do you want a "name" field for drang, too? > This chunk is critical to the way I want to store 2D data. Too bad. The PNG defenders of the faith will be coming after you. > -todd > -------------------------------------------------- > Todd French > Sandia National Labs > tfrench@sandia.gov > To add some fuel to the drng fire: Digital Broadcast TV uses a slightly extended gamut, with black=16 and white=235. You could convert DBTV images without loss and put in a chunk with dRNG "digital tv" 16 235 16 235 16 235 and be all set. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 11 18:55:39 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA08405 for ; Wed, 11 Sep 1996 18:55:38 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA18845 for png-list-outgoing; Wed, 11 Sep 1996 18:56:16 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA18839 for ; Wed, 11 Sep 1996 18:56:09 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.5/8.7.3) with ESMTP id QAA11933 for ; Wed, 11 Sep 1996 16:48:10 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.5/8.7.3) id QAA16402 for png-list@dworkin.wustl.edu; Wed, 11 Sep 1996 16:48:10 -0700 (PDT) Message-Id: <199609112348.QAA16402@web1.calweb.com> Subject: Re: PNG Advertising... To: png-list@dworkin.wustl.edu Date: Wed, 11 Sep 1996 16:48:10 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <199609112046.PAA27130@inet.htcnet.com> from "Carl Morris" at Sep 11, 96 03:45:18 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > Maybe a way to gain more support in PNG would be to get permission to > post a small FAQ on PNG in the image news groups. This FAQ could > contain user and programmer related questions/answers and guide people > to the light, if you get what I mean... :) The image format FAQ has had PNG info for over a year now. -- Lee Daniel Crocker ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 11 20:29:15 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA08776 for ; Wed, 11 Sep 1996 20:29:12 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA20074 for png-list-outgoing; Wed, 11 Sep 1996 20:29:26 -0500 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA20068 for ; Wed, 11 Sep 1996 20:29:20 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id SAA03909 for ; Wed, 11 Sep 1996 18:27:59 -0700 X-Sender: davem@mail.cs.ubc.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Sep 1996 18:28:04 -0700 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: Re: New Chunks Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >To add some fuel to the drng fire: Digital Broadcast TV uses a slightly >extended gamut, with black=16 and white=235. You could convert DBTV images >without loss and put in a chunk with > >dRNG "digital tv" 16 235 16 235 16 235 > >and be all set. Hmm. For that to work properly, you have to scale the values according to dRNG and *then* apply any gamma correction needed. I've forgotten; does dRNG work that way, or is the gamma correction done first? Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 12 00:05:18 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id AAA09720 for ; Thu, 12 Sep 1996 00:05:18 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA23078 for png-list-outgoing; Thu, 12 Sep 1996 00:06:05 -0500 Received: from mail.microsoft.com (mail1.microsoft.com [131.107.3.41]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id AAA23069 for ; Thu, 12 Sep 1996 00:06:01 -0500 Received: by mail.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24) id <01BBA02D.8B396EB0@mail.microsoft.com>; Wed, 11 Sep 1996 22:06:55 -0700 Message-ID: From: John Bowler To: "'PNG List'" Subject: RE: New Chunks Date: Wed, 11 Sep 1996 22:04:39 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Encoding: 18 TEXT Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >From: Todd French[SMTP:tfrench@sandia.gov] > >faLS: >... >One thing I wish were included is a palette ID of some sort. The >program which displays the images stores only one copy of each >palette no matter how many images are using it. When a new image is >loaded, I have to compare the entire palette to every one in memory. >It would be easier if there were an ID attached to each palette. I don't think the cost of adding this to the file justifies the benefit. The overhead of not having an ID in this case is the overhead of generating one when the file is loaded - the palette has to be stored somewhere (in memory in this case) to be useful, the time to generate a checksum base ID is small. John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 12 07:26:54 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id HAA12778 for ; Thu, 12 Sep 1996 07:26:54 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA26882 for png-list-outgoing; Thu, 12 Sep 1996 07:27:37 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id HAA26876 for ; Thu, 12 Sep 1996 07:27:33 -0500 Date: Thu, 12 Sep 96 8:24:06 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New Chunks Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609120824.aa16697@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Wed, 11 Sep 1996 18:28:04 -0700 }From: Dave Martindale }Subject: Re: New Chunks }>To add some fuel to the drng fire: Digital Broadcast TV uses a slightly }>extended gamut, with black=16 and white=235. You could convert DBTV images }>without loss and put in a chunk with }> }>dRNG "digital tv" 16 235 16 235 16 235 }> }>and be all set. } }Hmm. For that to work properly, you have to scale the values according to }dRNG and *then* apply any gamma correction needed. I've forgotten; does }dRNG work that way, or is the gamma correction done first? } } Dave The draft says that dRNG/DRNG is done first. Of course, you would probably do it all at once in a lookup table, but in constructing the LUT you'd apply dRNG/DRNG first. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 12 07:41:36 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id HAA12950 for ; Thu, 12 Sep 1996 07:41:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA26992 for png-list-outgoing; Thu, 12 Sep 1996 07:42:45 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id HAA26987 for ; Thu, 12 Sep 1996 07:42:42 -0500 Date: Thu, 12 Sep 96 8:38:09 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: ID in fALS chunk [was New Chunks] Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609120838.aa16799@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }From: John Bowler }Subject: RE: New Chunks }Date: Wed, 11 Sep 1996 22:04:39 -0700 }>From: Todd French[SMTP:tfrench@sandia.gov] }> }>faLS: }>... }>One thing I wish were included is a palette ID of some sort. The }>program which displays the images stores only one copy of each }>palette no matter how many images are using it. When a new image is }>loaded, I have to compare the entire palette to every one in memory. }>It would be easier if there were an ID attached to each palette. } }I don't think the cost of adding this to the file justifies the benefit. } The overhead of not having an ID in this case is the overhead of }generating one when the file is loaded - the palette has to be stored }somewhere (in memory in this case) to be useful, the time to generate a }checksum base ID is small. } }John Bowler If you don't want to use this feature the overhead is two bytes, and your decoder needs to be able to print or just skip the "id" field (probably using coding already available for decoding tEXt and zTXt keywords or spLT names). I think the ID, if it is an ASCII string, can be very useful for a human who is managing a library of palettes. Also I am working on a MNG feature that would take advantage of ASCII keywords to select chunks for use in a "delta-PNG". ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 12 08:48:44 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA13928 for ; Thu, 12 Sep 1996 08:48:43 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA27613 for png-list-outgoing; Thu, 12 Sep 1996 08:49:43 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA27608 for ; Thu, 12 Sep 1996 08:49:40 -0500 Date: Thu, 12 Sep 96 9:48:01 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New Chunks Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609120948.aa18282@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Wed, 11 Sep 1996 18:53:02 -0400 (EDT) }From: Glenn Randers-Pehrson }Subject: Re: New Chunks }> }> The biggest problem I have with any of these chunks is that I have }> about 10-20,000 images to change whenever I change the format in the }> programs. Is there a way that draft chunks could have a version }> number so that the software could properly recognize older draft }> chunks. I've decided next time I update, it will be either with }> formal chunks or I'll include a unique text keyword such as "drNG }> version":"0.960406". } }That would work. Once we register the chunks you won't have to do that }any more. } On second thought, it will only work if the image remains under your own control. A PNG optimizer, treating tEXt as a known chunk that has no ordering requirements, might think it was being helpful by moving all the tEXt chunks to the end of the file, where they occur too late to influence your decoding of drNG. If the proposed drNG gets a "name" field at the beginning, you could include the version in that field of unregistered versions. drNG "960914 sepia" -128 255 -64 255 0 255 ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 12 10:38:30 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id KAA16737 for ; Thu, 12 Sep 1996 10:38:29 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA29386 for png-list-outgoing; Thu, 12 Sep 1996 10:37:42 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA29377 for ; Thu, 12 Sep 1996 10:37:36 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id LAA27780 for ; Thu, 12 Sep 1996 11:36:12 -0400 (EDT) To: PNG List Subject: Version IDs for draft chunks (was Re: New Chunks) In-reply-to: Your message of Thu, 12 Sep 96 9:48:01 EDT <9609120948.aa18282@THOR.ARL.MIL> Date: Thu, 12 Sep 1996 11:36:12 -0400 Message-ID: <27777.842542572@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > }> Is there a way that draft chunks could have a version > }> number so that the software could properly recognize older draft > }> chunks. I've decided next time I update, it will be either with > }> formal chunks or I'll include a unique text keyword such as "drNG > }> version":"0.960406". > On second thought, it will only work if the image remains under your own > control. A PNG optimizer, treating tEXt as a known chunk that has no > ordering requirements, might think it was being helpful by moving > all the tEXt chunks to the end of the file, where they occur too > late to influence your decoding of drNG. Even without pushing the text chunk all the way to the end, a PNG editor is free to move it beyond the draft chunk, making decoding difficult. Or even discard it. The only safe solution is to make the draft chunk self-identifying. A simple answer, and the one intended by the spec design, is that you choose a new chunk name each time you change the contents/layout of the chunk. There's no particular reason that the private chunk name(s) you use while developing a chunk should have to be spelled the same as the final public chunk name. Or, if you think it might be too confusing to do it that way, you could reserve the first byte(s) of the private chunk's data area for a version number. Then each successive developmental version has the same private chunk name but a different version field. The final public chunk, however, would contain no version ID --- public chunks are permanently frozen by definition. (Again, if we have second thoughts about a public chunk, we expect to pick a new chunk name for the "improved" version. We didn't use up 32 bits on the chunk names just to make them human-readable; the chunk name space was made large to allow exactly this sort of process. In essence, the chunk name is itself a version ID.) regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 12 12:19:36 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA18901 for ; Thu, 12 Sep 1996 12:19:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA01679 for png-list-outgoing; Thu, 12 Sep 1996 12:19:52 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA01665 for ; Thu, 12 Sep 1996 12:19:44 -0500 Received: by grommit.inria.fr (8.7.5/8.6.12) id TAA11223 for png-list@dworkin.wustl.edu; Thu, 12 Sep 1996 19:18:26 +0200 (DST) Date: Thu, 12 Sep 1996 19:18:26 +0200 (DST) From: Chris Lilley Message-Id: <9609121918.ZM11221@grommit.inria.fr> In-Reply-To: Cave Newt "mainstream apps (was RE: Anniversary of chunk proposals)" (Sep 10, 8:34pm) References: <199609110134.UAA09536@ellis.uchicago.edu> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: mainstream apps (was RE: Anniversary of chunk proposals) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 10, 8:34pm, Cave Newt wrote: > John Bowler wrote: > >disservice - they show sufficient foresight to put in support for a file > >format which is not currently supported in any main stream commercial > >application but which they, presumably, think will become important. > > Presumably "main stream commercial application" refers to Windows apps > in this context... Even within that limited arena, I find it hard to > believe that you could dismiss *all* of the following as non-mainstream: > [... list ...] Plus of course Macromedia XRes 2.0, Freehand 7.0, Extreme 3D 2.0 and Adobe Photoshop 4.0 I think that by any imaginable criteria, Photoshop would have to be considered a mainstream commercial application. ( - just back from Seybold - ) -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 12 12:28:46 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA19175 for ; Thu, 12 Sep 1996 12:28:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA01902 for png-list-outgoing; Thu, 12 Sep 1996 12:29:57 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA01897 for ; Thu, 12 Sep 1996 12:29:53 -0500 Received: by grommit.inria.fr (8.7.5/8.6.12) id TAA11229 for png-list@dworkin.wustl.edu; Thu, 12 Sep 1996 19:28:35 +0200 (DST) Date: Thu, 12 Sep 1996 19:28:35 +0200 (DST) From: Chris Lilley Message-Id: <9609121928.ZM11227@grommit.inria.fr> In-Reply-To: John Bowler "RE: mainstream apps (was RE: Anniversary of chunk proposals)" (Sep 10, 8:05pm) References: X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: mainstream apps (was RE: Anniversary of chunk proposals) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 10, 8:05pm, John Bowler wrote: > Like PhotoShop these are all image processing apps I think (not sure > about 3D Studio Max and maybe the WebImage isn't really in this class). I saw several 3D apps at Seybold which either had PNG import for textures, or output for rendered scenes, or both. Or had it coming in the next release. People seem to like the alpha. People seem to find the idea of an image that actually looks similar on a Mac and on a PC appealing ;-) > My statement was imprecise - there are producers but no consumers (a > generalization). Right. A major Web browser on Win95 which had native PNG support anywhere you could put an image would be a nice example of such a consumer, for example. > As a file interchange format PNG is important because > of its ability to handle most other common formats in a consistent and > simple way, that means both ends of the process are needed. Agreed > Where are the multi-media creation tools? What about the illustration > packages (Freehand Graphics Studio maybe?)? My mail must have crossed yours, sorry. Macromedia announced Freehand 7.0 at Seybold, it has PNG import and export. So in fact does the entire Freehand studio, including XRes 3.0 and Extreme 3D 2.0 - not Fontographer, that has not been upgraded yet. From speaking to product managers the whole range is being made inter-operable and part of that is PNG support. So if Director does not have it now (I didn't check, sorry) it will have in short order. > What about the print service bureaus? Desktop publishing? I suspect the appearance of PNG in Photoshop 4.0 will have some effect there. I have also detected interest in the Medical Imaging / healthcare intranet community. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 12 12:47:13 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA19373 for ; Thu, 12 Sep 1996 12:47:06 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA02249 for png-list-outgoing; Thu, 12 Sep 1996 12:48:01 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id MAA02244 for ; Thu, 12 Sep 1996 12:47:56 -0500 Date: Thu, 12 Sep 96 13:44:45 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Version IDs for draft chunks (was Re: New Chunks) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609121344.aa25550@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List tom sez: }A simple answer, and the one intended by the spec design, is that you }choose a new chunk name each time you change the contents/layout of }the chunk. There's no particular reason that the private chunk name(s) }you use while developing a chunk should have to be spelled the same as }the final public chunk name. The trouble with this is the first name is going to be the one that is desired for the registered version, unless it gets changed along the way for some good reason. For example, the proposed chunk would follow a progression like psEU faLS ! change name faLT faLU faLV faLW fALS ! registered rpLT rpLU rpLV spLT ! change name spLU spLV sPLT ! registered which I guess is ok. But what about the MNG proposal; do we have to keep changing all the names with each draft? seEK would now be seEL or seEM DHDR would be DHDT > DHDU > DHDV > DHDW by now } }Or, if you think it might be too confusing to do it that way, you could }reserve the first byte(s) of the private chunk's data area for a version }number. Then each successive developmental version has the same private }chunk name but a different version field. In MNG, would the version ID of every chunk change, or just those that were changed in a given draft? Meaning one would have to keep all those drafts available... The main problem with this is it makes the trial implementations more difficult and error prone than they need to be, and it messes up the spec where we would otherwise say, "the number of entries is determined by the chunk length divided by eight" or whatever. } }The final public chunk, however, would contain no version ID --- public }chunks are permanently frozen by definition. (Again, if we have second }thoughts about a public chunk, we expect to pick a new chunk name for the }"improved" version. We didn't use up 32 bits on the chunk names just to }make them human-readable; the chunk name space was made large to allow }exactly this sort of process. Actually 26^4 or about 456k, though, not 256^4 or about 4G, because of the naming conventions. }In essence, the chunk name is itself a }version ID.) What would you think about defining a VERS chunk, that lists chunks and their version numbers, that would be required to appear ahead of any affected unregistered chunks? Of course we wouldn't be able to iterate on the format of the VERS chunk itself. Todd, you could use it as VeRS if you want to try this concept out. VERS faLS 19960411 pcAL 19960907 .... Make the version number an 8-byte date (with 4 digit year so we don't get accused of falling into the Y2K trap). I don't see an objection because of the installed software base, because you'd install the VERS chunk mechanism at the same time you installed your first unregistered chunk where you cared about the version number. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 12 18:20:22 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA24026 for ; Thu, 12 Sep 1996 18:20:20 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA09073 for png-list-outgoing; Thu, 12 Sep 1996 18:20:40 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id SAA09068 for ; Thu, 12 Sep 1996 18:20:34 -0500 Date: Thu, 12 Sep 96 19:17:35 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: png-list@dworkin.wustl.edu Subject: proposed PNG sRGB chunk Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609121917.aa08996@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I have received the following proposal from a Chris Lilley. I had planned to put it into the proposed chunks document, but I'm up to my ears in drafts right now and don't have time this week to do that. So here it is. I'm not the champion of the proposed chunk, just the messenger. I expect that Dave M. and Chris will evaluate it: Proposed sRGB ancillary chunk for PNG: ====================================== We would like to have a means to specify that a particular PNG image uses the sRGB transfer curve, chromaticities, flare, ambient illumination and other ICC properties. This would not require embedding a full ICC profile in each image, just indicating that the externally defined sRGB profile was in effect. Please accept this as a formal request to include the sRGB flag in the PNG spec. See http://www.hpl.hp.com/personal/Michael_Stokes/srgb.htm Support for the basic ICC intents has been added to the sRGB profile. In order to call and use these intents over the Internet, we need to have a means of communicating the proposed intent to the browser. It would appear the simplest way to do this is to assume a Photographic intent for all unlabeled colors, and label absolute and saturated. --- background sRGB is a pretty good "standard", well defined colorspace. It uses the monitor phosphors defined in 709 and recommended as an interchange space by Poynton and others. It specifies a full ICC profile - you may remember that this was discussed when PNG was being designed. At the time, ICC was unfinished and unproven. Since then it has been finished and found wide industry acceptance. Color Management Systems from several manufacturers, which usd to use proprietary formats, have now been released in 2.0 versions that use the open ICC profile format instead, so they can actually exchange profiles. Devices are shipping with profiles. Equipment is being made available at moderate cost so manufacturers can measure these profiles without a lab full of equipment. Apple support them in ColorSync 2, the CMS shipped with all Macs. There is an Agfa produict which provides a CMS for Win95 and this uses ICC profiles too. Sun's KCMS and SGI's in-house development CMS are also ICC compliant. So, in the last year and a half, ICC has gone from nowhere to widespread acceptance. The profile is still a potentially hefty chunk of data, though. Hence the idea of defining a standard profile which is referenced by name instead of included in each file. This would require a small extension chunk which could either go in the extensions document or the main spec. In case you were wondering, Michael Stokes is the chairman of ICC, that's why the document hangs off his homepage. I expect it will be moved somewhere else in due course. --- discussion PNG can very readilly have an sRGB chunk added which contains a single byte to assert to ICC-aware systems that the image data is in sRGB, and to give the rendering intent, which can take one of four possible values. For backwards compatibility, the gamma and chromaticity chunks should also be filled in with matching values. This allows systems with no ICC-compatible CMS to display the image with better fidelity than if they were omitted. --- summary No backwards-incompatible changes requested, just a chunk which gives extra details. Interestingly the name of the profile is exactly right as a PNG chunk name - ancillary, public, unsafe-to-copy. I suggest: sRGB: Standard RGB profile flag If present, the image conforms to the transfer characteristic, chromaticities, illuminant, viewing flare, ambient illumination, and other properties as specified by the International Color Consortium [ref http://www.color.org/] sRGB named profile [ref http://www.hpl.hp.com/personal/Michael_Stokes/srgb.htm]. This means that the image was written by an ICC-aware application and if displayed by an ICC-aware application using the specified rendering intent will achieve near-optimum rendering within the physical limitations of the output device. An sRGB chunk contains: Rendering intent: 1 byte The following values are legal for the rendering intent specifier: 0: Perceptual rendering intent 1: Relative colorimetric rendering intent 2: Saturation preserving rendering intent 3: Absolute colorimetric rendering intent If this chunk is used, the gAMA and cHRM chunks should also be present for compatibility with non-ICC-aware applications and should contain the following values: gAMA: Image gamma: 45000 cHRM: White Point x: 31270 White Point y: 32900 Red x: 64000 Red y: 33000 Green x: 30000 Green y: 60000 Blue x: 15000 Blue y: 06000 ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 12 18:24:18 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA24168 for ; Thu, 12 Sep 1996 18:24:18 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA09124 for png-list-outgoing; Thu, 12 Sep 1996 18:25:29 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA09114 for ; Thu, 12 Sep 1996 18:25:24 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id TAA00382 for ; Thu, 12 Sep 1996 19:24:04 -0400 (EDT) To: PNG List Subject: Re: Version IDs for draft chunks (was Re: New Chunks) In-reply-to: Your message of Thu, 12 Sep 96 13:44:45 EDT <9609121344.aa25550@THOR.ARL.MIL> Date: Thu, 12 Sep 1996 19:24:04 -0400 Message-ID: <379.842570644@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > tom sez: > }A simple answer, and the one intended by the spec design, is that you > }choose a new chunk name each time you change the contents/layout of > }the chunk. > But what about the MNG proposal; do we have to keep changing all > the names with each draft? No, because no one is making permanent files according to these drafts. (One hopes not, anyway ;-).) Todd is complaining because he's got tens of thousands of files written with draft versions of chunks. When you're committing to a draft chunk to the tune of thousands of files is when you should be thinking about version control for the chunk. I think the two alternatives I offered are quite adequate for that scenario: if you think about it beforehand, you might put in a version field; if you only realize later that your chunk design is wrong, you change the chunk name. > What would you think about defining a VERS chunk, that lists chunks and their > version numbers, that would be required to appear ahead of any > affected unregistered chunks? This solution is *far* worse than the disease, because it introduces a new critical chunk, thereby breaking every decoder in existence whether or not they care about unregistered ancillary chunks. Yet a VERS chunk would have to be critical, or it could lose due to reordering or simple discard (as we discussed before). Moreover, it's unnecessarily complex. (What if there's more than one occurrence of the target chunk type? Must they all be the same version?) IMHO, self-identifying chunks are the only reasonable way to cope with changes in ancillary chunk definitions. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 12 20:00:19 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA24995 for ; Thu, 12 Sep 1996 20:00:17 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA10863 for png-list-outgoing; Thu, 12 Sep 1996 20:00:58 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id UAA10858 for ; Thu, 12 Sep 1996 20:00:54 -0500 Date: Thu, 12 Sep 96 20:58:17 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Version IDs for draft chunks (was Re: New Chunks) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609122058.aa12760@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Subject: Re: Version IDs for draft chunks (was Re: New Chunks) }Date: Thu, 12 Sep 1996 19:24:04 -0400 }Message-ID: <379.842570644@sss.pgh.pa.us> }From: Tom Lane }Glenn writes: }> tom sez: }> }A simple answer, and the one intended by the spec design, is that you }> }choose a new chunk name each time you change the contents/layout of }> }the chunk. } }> But what about the MNG proposal; do we have to keep changing all }> the names with each draft? } }No, because no one is making permanent files according to these drafts. }(One hopes not, anyway ;-).) Todd is complaining because he's got tens of }thousands of files written with draft versions of chunks. When you're }committing to a draft chunk to the tune of thousands of files is when you }should be thinking about version control for the chunk. I think we may have done Todd a disservice by spending over a year on his proposal. } }I think the two alternatives I offered are quite adequate for that }scenario: if you think about it beforehand, you might put in a version }field; if you only realize later that your chunk design is wrong, you }change the chunk name. } OK, forget about the VERS idea. I didn't think it would break any decoders because files with experimental chunks aren't supposed to escape into the wild, anyway, and files without them wouldn't have a VERS chunk. Anyhow... I'm rewriting the latest "scivis" and "proposed" documents to change chunk names when appropriate. I'm ignoring any problems due to differences between the December and April versions. Because of differences in the April and August versions, I'm changing the names of zsCL (to zsCA) and faLS (to faLT), but saying that the intent is to register them as zSCL and fALS, respectively. I'll probably not get them out until next week, so, everyone will please just make a pen-and-ink change for now. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 12 20:05:59 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA28125 for ; Thu, 12 Sep 1996 20:05:58 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA10912 for png-list-outgoing; Thu, 12 Sep 1996 20:07:14 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id UAA10907 for ; Thu, 12 Sep 1996 20:07:11 -0500 Date: Thu, 12 Sep 96 21:04:43 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: Glenn Randers-Pehrson ARL-WMRD-TED-TIB cc: PNG List Subject: Re: Version IDs for draft chunks (was Re: New Chunks) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609122104.aa13341@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Another pen-and-ink change, please. I am changing spLT to spAL because we are adding a gamma field. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 12 20:39:31 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA00920 for ; Thu, 12 Sep 1996 20:39:31 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA11398 for png-list-outgoing; Thu, 12 Sep 1996 20:40:43 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA11391 for ; Thu, 12 Sep 1996 20:40:36 -0500 Received: from willem.gintic.ntu.edu.sg ([155.69.31.9]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id JAA18424 for ; Fri, 13 Sep 1996 09:39:04 +0800 (SST) Date: Fri, 13 Sep 1996 09:39:04 +0800 (SST) Message-Id: <199609130139.JAA18424@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: Willem van Schaik Subject: Re: Adobe announces PNG support in Photoshop 4.0 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 15:05 10-09-1996 -0700, Dave wrote: >>Adobe has announced Photoshop 4.0 --- it's not gonna actually ship >>till November, though. There's fairly extensive material at >> http://www.adobe.com/prodindex/photoshop/main.html >>What got my attention was PNG and progressive JPEG support (yay!). > >Hmm. Any likelihood of someone getting a beta test copy so we >can make sure that things like gAMA and alpha and cHRM work right? >Or is there an extensive enough test suite somewhere that the Adobe >people can do thorough testing on their own? > Of course I (me myself and I :-) must say that there is an extensive test suite (PngSuite), but the test-suite is only one. Especially with alpha, gamma, etc. you need to be knowledgable to interpret the results. The decoding will probably be fine, but is the image exactly looking as it should look, that's the question. So I agree that a few PNG people should be beta-testing. I do volunteer, but nobody asked me ... :-). Willem ------------------------------------------------------------------------------ Gintic Institute of Manufacturing Technology gwillem@ntuvax.ntu.ac.sg Singapore http://mht3.gintic.ntu.ac.sg:8000/wwwillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 12 21:28:41 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id VAA01270 for ; Thu, 12 Sep 1996 21:28:40 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA12047 for png-list-outgoing; Thu, 12 Sep 1996 21:29:34 -0500 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id VAA12042 for ; Thu, 12 Sep 1996 21:29:30 -0500 Received: by mail2.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24) id <01BBA0E0.81C461B0@mail2.microsoft.com>; Thu, 12 Sep 1996 19:27:59 -0700 Message-ID: From: John Bowler To: "'PNG List'" Subject: RE: Version IDs for draft chunks (was Re: New Chunks) Date: Thu, 12 Sep 1996 19:27:25 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Encoding: 28 TEXT Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I have support for a private chunk, "msOC", which contains the "biClrImportant" field from a BMP file (the count of the leading palette entries which an app should try to retain when it is unable to provide the full set of palette entries). To make this "safe" I set the first 7 bytes of the chunk (data) to the sequence:- png_byte const FARDATA png_msOCSignature[7] = { 77, 83, 79, 32, 97, 97, 99 }; then set the only real data byte to the required number. This is safe because the check for "MSO aac" and a chunk data length of 8 is very unlikely to accidentally match another private chunk and is easy to version simply by changing the last three letters. There could be a formal way of doing this, for example by using 8 bytes, the first four of which are the authors 'phone number and the last four a timestamp (pretty much guaranteed to be unique and obviously easy to version - just change the time stamp). On the other hand it is very easy to come up with signature methods which will be reliable - the process doesn't need to be formalized. An identical technique works with JPEG APPn markers. For draft chunks all that is really required is to put in such a signature, then simply remove it when the chunk is approved (the data just shifts up by a few bytes). John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 13 02:32:21 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id CAA02887 for ; Fri, 13 Sep 1996 02:32:21 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id CAA15615 for png-list-outgoing; Fri, 13 Sep 1996 02:33:05 -0500 Received: from ntuix.ntu.ac.sg (ntuix.ntu.ac.sg [155.69.1.5]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id CAA15606 for ; Fri, 13 Sep 1996 02:32:59 -0500 Received: from willem.gintic.ntu.edu.sg ([155.69.31.9]) by ntuix.ntu.ac.sg (8.7.5/8.7.3) with SMTP id PAA25708 for ; Fri, 13 Sep 1996 15:31:34 +0800 (SST) Date: Fri, 13 Sep 1996 15:31:34 +0800 (SST) Message-Id: <199609130731.PAA25708@ntuix.ntu.ac.sg> X-Sender: gwillem@ntuvax.ntu.ac.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: Willem van Schaik Subject: Re: PNG Advertising... Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 15:45 11-09-1996 -0500, you wrote: >Maybe a way to gain more support in PNG would be to get permission to >post a small FAQ on PNG in the image news groups. This FAQ could >contain user and programmer related questions/answers and guide people >to the light, if you get what I mean... :) Good idea. Willem ------------------------------------------------------------------------------ Gintic Institute of Manufacturing Technology gwillem@ntuvax.ntu.ac.sg Singapore http://mht3.gintic.ntu.ac.sg:8000/wwwillem.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 13 07:54:14 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id HAA05024 for ; Fri, 13 Sep 1996 07:54:13 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA18173 for png-list-outgoing; Fri, 13 Sep 1996 07:55:01 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id HAA18168 for ; Fri, 13 Sep 1996 07:54:59 -0500 Date: Fri, 13 Sep 96 8:51:33 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Version IDs for draft chunks (was Re: New Chunks) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609130851.aa10731@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Message-ID: }Subject: RE: Version IDs for draft chunks (was Re: New Chunks) }[..] }There could be a formal way of doing this, for example by using 8 bytes, }the first four of which are the authors 'phone number and the last four }a timestamp (pretty much guaranteed to be unique and obviously easy to }version - just change the time stamp). On the other hand it is very }easy to come up with signature methods which will be reliable - the }process doesn't need to be formalized. } I started out with something similar back in April when I was first writing up the proposed documents. The signature would have been 16 bytes, "PNG GROUP 960406". I envisioned a big fight about identifying dRNG with "PNG GROUP"... And I thought the chunks in question had all had enough discussion that the format was unlikely to change... (wrong, now we add gamma to spLT and a name to faLS) }An identical technique works with JPEG APPn markers. } }For draft chunks all that is really required is to put in such a }signature, then simply remove it when the chunk is approved (the data }just shifts up by a few bytes). But the problem was that the presence of the keyword interfered with the rest of the chunk specification. Where I wanted to say "the number of entries is the chunk length divided by eight," I had to add more. So the "proposed" specification would differ from the "registered" specification in more ways than just changing the second byte of the chunk name. } }John Bowler } I am about to add the proposed sRGB chunk. Should it have a version ID? The chunk is so simple that I just can't imagine any other incompatible version of it. On the other hand, someone may already be using another unregistered chunk called srGB, so maybe it's not that bad an idea anyway: srGB 16 bytes: "PNG GROUP 960913" 1 byte: rendering intent ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 13 12:35:21 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA11756 for ; Fri, 13 Sep 1996 12:35:20 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA22118 for png-list-outgoing; Fri, 13 Sep 1996 12:35:58 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA22113 for ; Fri, 13 Sep 1996 12:35:53 -0500 Received: by grommit.inria.fr (8.7.5/8.6.12) id TAA15511 for png-list@dworkin.wustl.edu; Fri, 13 Sep 1996 19:34:29 +0200 (DST) Date: Fri, 13 Sep 1996 19:34:29 +0200 (DST) From: Chris Lilley Message-Id: <9609131934.ZM15509@grommit.inria.fr> In-Reply-To: Willem van Schaik "Re: Adobe announces PNG support in Photoshop 4.0" (Sep 13, 9:39am) References: <199609130139.JAA18424@ntuix.ntu.ac.sg> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: Adobe announces PNG support in Photoshop 4.0 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 13, 9:39am, Willem van Schaik wrote: > At 15:05 10-09-1996 -0700, Dave wrote: > >[someone] > >>Adobe has announced Photoshop 4.0 > >>What got my attention was PNG and progressive JPEG support (yay!). > >Hmm. Any likelihood of someone getting a beta test copy so we > >can make sure that things like gAMA and alpha and cHRM work right? > So I agree that a few PNG people should be beta-testing. I do > volunteer, but nobody asked me ... :-). Gamma testers - ha, I'll leave that typo in, it's amusing! Beta testers for Photoshop have to sign a non-disclosure agreement for the duration of the testing period, which limits the amount of feedback that can be given to the list. Rest assured however that Willem's suggestion is already taken care of and that gamma, chromaticity, alpha, tEXT and zTXT (for example) will be fully exercised and the appropriate feedback given to Adobe by beta testers. I know one very well ;-) -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 13 19:20:09 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA16746 for ; Fri, 13 Sep 1996 19:20:08 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA00371 for png-list-outgoing; Fri, 13 Sep 1996 19:18:58 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id TAA00359; Fri, 13 Sep 1996 19:18:54 -0500 Date: Fri, 13 Sep 96 20:12:59 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: png-list@dworkin.wustl.edu cc: mpng-list@dworkin.wustl.edu Subject: New drafts, 19960914 versions Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609132012.aa19211@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List New drafts posted to swrinde: draft-mng-19960914.html, .ps.gz, .txt.gz png-proposed-chunks-19960914.html, .ps.gz, .txt.gz png-scivis-chunks-19960914.html, .ps.gz, .txt.gz Other files: viewpng.gz pngballs_d16.mng Keith you can just mv lena_d15.mng lena_d16.mng because there was no incompatible change affecting the lena_d15.mng I'll mail the txt of the proposed and scivis documents to png-list and the mng document to mpng-list. I'll post a new impact_d16.mng later, but it's still cooking now... ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 13 19:20:12 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA16749 for ; Fri, 13 Sep 1996 19:20:09 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA00372 for png-list-outgoing; Fri, 13 Sep 1996 19:18:59 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id TAA00361 for ; Fri, 13 Sep 1996 19:18:54 -0500 Date: Fri, 13 Sep 96 20:14:05 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: png-list@dworkin.wustl.edu Subject: Proposed chunks, version 19960914 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609132014.aa19473@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List png-proposed-chunks-19960914 ============cut here=============== PNG-GROUP-DRAFT PNG Development Group PNG-Proposals png-list@dworkin.wustl.edu Expires: 14 Mar 1997 14 Sep 1996 PNG Proposed Chunks, draft 19960914 File png-proposed-chunks-19960914.txt Status of this Memo This document is an informal draft of the PNG development group. Comments on this document can be sent to the PNG specification maintainers at png-info@uunet.uu.net or at png- list@dworkin.wustl.edu. Distribution of this memo is unlimited. At present, the latest version of this document is available on the World Wide Web from ftp://swrinde.nde.swri.edu/pub/png- group/documents/. Notices Copyright (c) 1996 Thomas Boutell Permission is granted to copy and distribute this document for any purpose and without charge, provided that the copyright notice and this notice are preserved, and that any substantive changes or deletions from the original are clearly marked. Abstract This document describes some special-purpose chunk types that have been proposed for use in various PNG (Portable Network Graphics) applications. They have not yet been approved for registration by the PNG developers, and therefore are experimental and their format is subject to change. The proposed chunks are alIG, fiNG, spAL, and srGB. PNG Development Group [Page 1] PNG-GROUP-DRAFT PNG Proposed Chunks 19960914 06 Sep 1996 Table of Contents 1. Introduction ................................................... 2 2. Using Proposed PNG Chunks ...................................... 2 3. Summary of Proposed Chunks ..................................... 3 4. Proposed Chunk Specifications .................................. 3 4.1. alIG Alignment ........................................... 3 4.2. fiNG Fingerprint ......................................... 4 4.3. spAL Suggested Palette ................................... 5 4.4. srGB Standard RGB profile ................................ 7 5. Chunks not described here ...................................... 8 6. Security considerations ........................................ 8 7. References ..................................................... 8 8. Credits ........................................................ 9 1. Introduction Chunks described here have been proposed to the PNG development group. Their definitions are subject to change until such time as the group formally registers them. No decoder is required or expected to implement these chunks except for experimental or evaluation purposes. Comments on these proposals, and new proposals for additional chunk types, should be sent to the PNG specification maintainers at png-info@uunet.uu.net. The basic PNG specification is available from the W3C archive at http://www.w3.org/pub/WWW/TR/WD- png. 2. Using Proposed PNG Chunks No chunks described in this document have yet been registered by the PNG maintainers. Therefore they have a lower-case letter in the second position of the chunkname. They are experimental chunks and the format is subject to change. If and when any become registered, the second letter of the chunk name will become uppercase, the "signature" field, if present, and its zero-byte terminator will be deleted. The chunk description will be moved either to a PNG extensions document or to the core PNG specification. There will be no further change to the format. Whenever you use any of these unregistered chunks you should also include a tEXt chunk describing it, for example: tEXtComment\0 This file contains a spAL chunk written according to the format given in Version 19960914 of the PNG Proposed Chunks document. For those proposed chunks that have a "signature" field, decoders should check to ensure that the signature field is present and that its contents exactly match the specified string. PNG Development Group [Page 2] PNG-GROUP-DRAFT PNG Proposed Chunks 19960914 06 Sep 1996 3. Summary of Proposed Chunks This table summarizes some properties of the proposed chunks described in this document. Chunk name Multiple Ordering OK? constraints alIG No Before IDAT fiNG No None spAL Yes Before IDAT srGB No Before IDAT 4. Proposed Chunk Specifications This section provides the detailed specifications for the proposed chunks. 4.1. alIG Alignment This chunk can be used to provide alignment information to applications. It is especially useful for transparent images in which the edges of the interesting part of the picture do not correspond exactly to the edges of the image data. It can be helpful in aligning the picture with adjacent text, if there is a specific location in the picture that should be aligned with the text baseline. (We use "picture" to mean the thing depicted, as opposed to "image" which is the entire width x height rectangle described by the PNG stream.) The format of this chunk has not changed since version 19960406 of this document. This chunk's contents are left 4 bytes left side of picture center 4 bytes center of picture (horizontal) right 4 bytes right side of picture top 4 bytes top of picture middle 4 bytes middle of picture (vertical) baseline 4 bytes typographic baseline of picture (vertical) bottom 4 bytes bottom of picture All values are signed 32-bit integer values, measured in pixels downward from the top of the image or rightward from the left edge of the image. Applications will not normally try to use all of the alignment values at once. A browser might use the "center" value when it wishes to center the image left-to-right on a page. A typographic system might use the "top" value to line up an image that contains a fancy capital letter with the top of the adjacent text, or the PNG Development Group [Page 3] PNG-GROUP-DRAFT PNG Proposed Chunks 19960914 06 Sep 1996 "baseline" value to line up images containing mathematical equations. Typographic systems could also determine the typographic "height", "depth", "width", and reference point values: font_height := baseline - top font_width := right - left font_depth := bottom - baseline font_ref_x := left font_ref_y := baseline If the alIG chunk is not present, applications can assume the following values: left := 0 center := width/2 right := width top := 0 middle := height/2 baseline := height bottom := height If an encoder writes the alIG chunk, it must supply all of the fields, and should use these values as defaults. Only one alIG chunk is permitted in a PNG datastream. If present, it must appear prior to the first IDAT chunk. 4.2. fiNG Fingerprint This chunk contains an MD5 fingerprint of the uncompressed, unfiltered, uninterlaced image data, that can be used for rapidly determining whether two files contain the same image, without having to actually decode the IDAT chunks. The MD5 fingerprint is calculated according to the RSA Data Security, Inc. MD5 Message-Digest Algorithm, copyright by RDS Data Security, Inc., 1991-1992. A reference implementation of the algorithm and the license for its use are given in [MD5]. The format of this chunk has not changed since version 19960710 of this document. The fiNG chunk's contents are 16 bytes: image fingerprint The fingerprint is the MD5 digest value computed on the image data, promoted by left-bit-replication (see bit_depth scaling in PNG spec) to 16-bit RGBA (colortype 6). Scaling is done without regard to the sBIT chunk, if present. When promoting truecolor images, fill the alpha samples with 0xffff (all ones). The PNG Development Group [Page 4] PNG-GROUP-DRAFT PNG Proposed Chunks 19960914 06 Sep 1996 fingerprint is calculated without regard to any ancillary chunks. The value is computed on the data in the same order as the bytes would appear in a color type 6 datastream, except that no filter bytes are included in the calculation. The MD5 fingerprint value is computed as described in RFC 1321 [RFC1321]. An image's fingerprint will not change if the image is changed from interlaced to noninterlaced, or compressed with a different method, or filtered differently, or if any ancillary chunks are added, modified, or removed. It will change if there is any lossy conversion of the pixel data or if the PLTE data is changed in an indexed-color image. The fiNG fingerprint is trivial to forge. Be cautious when using a fingerprint chunk generated by someone else. It is safer to recalculate and install your own fiNG chunk when you receive an image from outside of your control. While the fiNG chunk does not have any ordering requirements, you should put it early in the file for quick access. 4.3. spAL Suggested Palette This chunk can be used to suggest a reduced palette to be used when the display device is not capable of displaying the full range of colors present in the image. If present, it provides a recommended set of colors, with alpha and frequency information, that can be used to construct a reduced palette to which the truecolor image can be quantized. The format of this chunk has not changed since version 19960914 of this document. In the previous version it was called spLT and the name has been changed to avoid confusion. It is intended to register the chunk as sPLT. The "signature" field and its null separator will not be included in the registered chunk. This chunk's contents are a zero-byte-terminated text string that names the palette, a zero-byte-terminated signature to identify the version, followed by a 4-byte gamma value, followed by a series of palette entries, each a ten-byte series, containing five unsigned integers: n bytes: (ASCII text) palette name 1 byte: (null) terminator 20 bytes: signature ("PNG group 1996-09-14") 1 byte: (null) separator 4 bytes: (unsigned integer) gamma PNG Development Group [Page 5] PNG-GROUP-DRAFT PNG Proposed Chunks 19960914 06 Sep 1996 2 bytes: (unsigned integer) red intensity 0: black etc. 65535: full red intensity 2 bytes: (unsigned integer) green intensity 2 bytes: (unsigned integer) blue intensity 2 bytes: (unsigned integer) alpha 0: fully transparent etc. 65535: fully opaque 2 bytes: (unsigned integer) frequency (relative frequency of occurrence) etc. There can be any number of entries; a decoder determines the number of entries from the remaining chunk length after the gamma field. This length not divisible by ten is an error. Entries must appear in decreasing order of "frequency". The "name" (e.g. "rgba512 8-8-4-2 color cube", "rgb256 winter scenery", "rgb242 6-6-6 color cube plus 26 gray levels", "Windows white background", "Browser Safe Palette", "Sepia") identifies the palette, which can permit applications or people to choose the appropriate one when more than one suggested palette appears in a PNG file. The "name" string must follow the format of a tEXt keyword: It must consist only of printable ASCII characters and must not have leading or trailing blanks, but can have single embedded blanks. There must be at least one and no more than 79 characters in the name. Names are case-sensitive. The gamma field gives the value of gamma, times 100000, that is associated with the palette entries. The red, green, and blue values are not premultiplied by alpha, nor are they precomposited against any background. A decoder can build a palette by compositing those palette entries against any background color or set of background colors that it chooses. See [link to bKGD] Each frequency entry is proportional to the fraction of pixels in the image that are closest to that palette entry, without regard to any compositing against a background palette. The exact scale factor is chosen by the encoder, but should be chosen so that the range of individual values reasonably fills the range 0 to 65535. It is acceptable to artificially inflate the "frequency" values for "important" colors such as those in a company logo or in the facial features of a portrait. Zero is a valid value for frequency, meaning the color is "least important" or that it is rarely if ever used. The palette uses 16 bits (2 bytes) per value regardless of the image bit depth specification. Decoders wishing to construct a PNG Development Group [Page 6] PNG-GROUP-DRAFT PNG Proposed Chunks 19960914 06 Sep 1996 palette with a smaller bit depth can accomplish this by scaling down the RGB entries, as described under "bit depth rescaling" in the PNG specification. Note: Earlier versions of the PNG specification recommended that the PLTE [link to PLTE] and hIST chunks be used for this purpose. While this is still allowed, to maintain backward compatibility, the spAL chunk is preferable, particularly when transparent pixels are present. When both the PLTE and spAL chunks are present, the PLTE data should only be used for decoding the indexed-color (color type 3) pixels, and the spAL data should be used for constructing the display palette. If the hIST chunk is also present, decoders that process the spAL chunk should ignore it. This chunk can appear for any color type. If this chunk does appear, it must precede the first IDAT chunk. There can be multiple spAL chunks, with different names. 4.4. srGB Standard RGB profile If the srGB chunk is present, the image conforms to the International Color Commission's sRGB profile, and should be displayed using the specified rendering intent. The format of this chunk has not changed since version 19960914 of this document. The "signature" field and its null separator will not be included in the registered chunk. An srGB chunk contains: 20 bytes: signature ("PNG group 1996-09-14") 1 byte: null separator 1 byte: Rendering intent 0: Perceptual rendering intent 1: Relative colorimetric rendering intent 2: Saturation preserving rendering intent 3: Absolute colorimetric rendering intent If the srGB chunk is present, the image conforms to the transfer characteristic, chromaticities, illuminant, viewing flare, ambient illumination, and other properties as specified by the International Color Consortium [ICC] sRGB named profile described in [STOKES]. This means that the image was written by an ICC- aware application and if displayed by an ICC-aware application using the specified rendering intent will achieve near-optimum rendering within the physical limitations of the output device. If this chunk is used, the gAMA and cHRM chunks should also be present for compatibility with non-ICC-aware applications and should contain the following values: PNG Development Group [Page 7] PNG-GROUP-DRAFT PNG Proposed Chunks 19960914 06 Sep 1996 gAMA: Image gamma: 45000 cHRM: White Point x: 31270 White Point y: 32900 Red x: 64000 Red y: 33000 Green x: 30000 Green y: 60000 Blue x: 15000 Blue y: 06000 5. Chunks not described here Additional chunks have been proposed for scientific visualization purposes. Since they are not expected to be implemented by general- purpose decoders, the are described separately in the PNG Scientific Visualization Chunks document [SCIVIS]. The proposed chunks described there are drNG/DrNG, faLT, loGE/LoGE, pCAL, tsCL, xsCL, ysCL, and zsCA. 6. Security considerations Security considerations are addressed in the basic PNG specification, http://www.w3.org/pub/WWW/TR/WD-png. The same precautions taken when displaying tEXt data should be taken when displaying the text contained in the "name" strings of the spAL chunk. Viewers should not display these strings directly without first checking for the presence of nonprintable characters, and for the character in particular. The fiNG fingerprint is trivial to forge. Be cautious when using a fingerprint chunk generated by someone else. No known additional security hazards are posed by the chunks described here. 7. References [MD5] RFC 1321, The MD5 Message-Digest Algorithm. [STOKES] http://www.hpl.hp.com/personal/Michael_Stokes/srgb.htm . [SCIVIS] PNG Scientific Visualization Chunks, available at ftp://swrinde.nde.swri.edu/png-group/documents/ PNG Development Group [Page 8] PNG-GROUP-DRAFT PNG Proposed Chunks 19960914 06 Sep 1996 8. Credits Trademarks * Windows is a trademark of MicroSoft Corp. Contributors Contributors' names are presented in alphabetical order: * Mark Adler, madler@alumni.caltech.edu * Thomas Boutell, boutell@boutell.com * Christian Brunschen, cb@df.lth.se * Adam M. Costello, amc@cs.berkeley.edu * Lee Daniel Crocker, lee@piclab.com * Andreas Dilger, adilger@enel.ucalgary.ca * Oliver Fromme, fromme@rz.tu-clausthal.de * Todd French, tfrench@sandia.gov * Jean-loup Gailly, gzip@prep.ai.mit.edu * Chris Herborth, chrish@qnx.com * Alex Jakulin, alex@hermes.si * Neal Kettler, kettler@cs.colostate.edu * Jim King, jimk@mathtype.com * Tom Lane, tgl@sss.pgh.pa.us * Alexander Lehmann, alex@hal.rhein-main.de * Chris Lilley, chris@w3.org * Dave Martindale, davem@cs.ubc.ca * Owen Mortensen, ojm@csi.compuserve.com * Robert P. Poole, lionboy@primenet.com * Glenn Randers-Pehrson, glennrp@arl.mil or randeg@alumni.rpi.edu * Greg Roelofs, newt@pobox.com * Willem van Schaik, gwillem@ntuvax.ntu.ac.sg * Guy Schalnat * Paul Schmidt, pschmidt@photodex.com * Tim Wegner, 71320.675@compuserve.com Editor * Glenn Randers-Pehrson, glennrp@arl.mil or randeg@alumni.rpi.edu End of PNG Proposed Chunks Listing. Expires 06 Mar 1997. PNG Development Group [Page 9] ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 13 19:20:10 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA16747 for ; Fri, 13 Sep 1996 19:20:08 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA00379 for png-list-outgoing; Fri, 13 Sep 1996 19:19:04 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id TAA00367 for ; Fri, 13 Sep 1996 19:18:57 -0500 Date: Fri, 13 Sep 96 20:15:11 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: png-list@dworkin.wustl.edu Subject: Scivis chunks, version 19960914 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609132015.aa19525@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List png-scivis-chunks-19960914 ============cut here===============%<------------- PNG-GROUP-DRAFT PNG Development Group PNG-SciVis png-list@dworkin.wustl.edu Expires: 14 Mar 1997 14 Sep 1996 PNG Scientific Visualization Chunks, draft 19960914 File png-scivis-chunks-19960914.txt Status of this Memo This document is an informal draft of the PNG development group. Comments on this document can be sent to the PNG specification maintainers at png-info@uunet.uu.net or at png- list@dworkin.wustl.edu. Distribution of this memo is unlimited. At present, the latest version of this document is available on the World Wide Web from ftp://swrinde.nde.swri.edu/pub/png- group/documents/. Notices Copyright (c) 1996 Thomas Boutell Permission is granted to copy and distribute this document for any purpose and without charge, provided that the copyright notice and this notice are preserved, and that any substantive changes or deletions from the original are clearly marked. Changes from the 06 April 1996 draft: * Changed name of zsCL chunk back to pcAL * Added equation_type 3 to the pCAL chunk (signed log encoding) * Separated xySC chunk into xsCL and ysCL chunks * Added tsCL and zsCA chunks for use in multi-image formats * Added "purpose" field to faLS (and changed its name to faLT). * Added version-identifying "signatures" to those chunks that have changed since the April version. PNG Development Group [Page 1] PNG-GROUP-DRAFT PNG Proposed SciVis Chunks 19960914 14 Sep 1996 Abstract This document describes some special-purpose chunk types that have been proposed for use in various PNG (Portable Network Graphics) and related multi-image applications. They have not yet been approved for registration by the PNG developers, and therefore are experimental and their format is subject to change. The proposed chunks are drNG/DrNG, faLT, loGE/LoGE, pcAL, tsCL, xsCL, ysCL, and zsCA. Table of Contents 1. Introduction ................................................... 2 2. Using Proposed PNG Chunks ...................................... 2 3. Summary of Proposed Sci-Vis Chunks ............................. 3 4. Proposed Chunk Specifications .................................. 3 4.1. drNG/DrNG Pixel display range ............................ 3 4.2. faLT False-color Palette ................................. 5 4.3. loGE/LoGE Logarithmic Encoding ........................... 7 4.4. pcAL Scale of Pixel Values ............................... 9 4.5. tsCL Physical time scale ................................ 11 4.6. xsCL X-Scale of Image Subject ........................... 11 4.7. ysCL Y-Scale of Image Subject ........................... 12 4.8. zsCA Z scale ............................................ 13 5. Security considerations ....................................... 14 6. Credits ....................................................... 14 1. Introduction Chunks described here have been proposed to the PNG development group for use by the scientific visualization community. Their definitions are subject to change until such time as the group formally registers them. No decoder is required or expected to implement these chunks except for experimental or evaluation purposes. Comments on these proposals, and new proposals for additional chunk types, should be sent to the PNG specification maintainers at png-info@uunet.uu.net. The basic PNG specification is available from the W3C archive at http://www.w3.org/pub/WWW/TR/WD-png. 2. Using Proposed PNG Chunks No chunks described in this document have yet been registered by the PNG Development Group [Page 2] PNG-GROUP-DRAFT PNG Proposed SciVis Chunks 19960914 14 Sep 1996 PNG maintainers. Therefore they have a lower-case letter in the second position of the chunkname. They are experimental chunks and the format is subject to change. If and when any become registered, the second letter of the chunk name will become uppercase, the "signature" field and it zero-byte terminator will be deleted, and there will be no further change to the format. Whenever you use any of these unregistered chunks you should also include a tEXt chunk describing it, for example: tEXtComment\0 This file contains a pcAL chunk written according to the format given in Version 19960813 of the PNG Proposed Chunks document. For those proposed chunks that have a "signature" field, decoders should check to ensure that the signature field is present and that its contents exactly match the specified string. 3. Summary of Proposed Sci-Vis Chunks This table summarizes some properties of the proposed chunks described in this document. Chunk name Multiple Ordering OK? constraints drNG/DrNG No Before IDAT faLT No Before IDAT loGE/LoGE No Before IDAT tsCL (used in multi-image format) xsCL No Before IDAT ysCL No Before IDAT zsCA (used in multi-image format) pcAL No Before IDAT 4. Proposed Chunk Specifications This section provides the detailed specifications for the proposed chunks. 4.1. drNG/DrNG Pixel display range Format last changed 06 April 1996 (Version 19960406). The proposed registered name for this chunk is dRNG/DRNG. This chunk can be used when the pixel values do not occupy the full range of possible values, and when bit depth scaling is not appropriate. It can also be used to enhance contrast by scaling to a larger range than the actual range of pixel values. It can be used to correct the brightness of an image that has been scaled by zero-filling rather than linear scaling. See [link to sBIT in core spec]. The chunk defines the pixel values that correspond to PNG Development Group [Page 3] PNG-GROUP-DRAFT PNG Proposed SciVis Chunks 19960914 14 Sep 1996 minimum and maximum intensity, to which the pixel data is to be scaled. The chunk can be used as a critical chunk, named DrNG, or as an ancillary chunk, named drNG. The syntax and function is exactly the same whichever name is used. The critical version should only be used if the image cannot be meaningfully displayed without performing DrNG scaling. Decoders not recognizing DrNG will not attempt to display the image at all. Encoders are strongly encouraged to scale the image data properly and to use the noncritical version, drNG, if at all possible. This chunk's contents are min_sample m bytes Raw sample value corresponding to minimum intensity of the graylevel or red channel, written as a text floating-point value [link to Floating-Point Values in extensions document] 0 1 byte a zero byte to separate fields max_sample n bytes Raw sample value corresponding to maximum intensity for the graylevel or red channel (The following entries can be omitted for grayscale images, or for color images where identical values are to be applied to all three color channels) 0 1 byte a zero byte to separate fields min_green m bytes raw sample value corresponding to minimum green intensity 0 1 byte a zero byte to separate fields max_green m bytes raw sample value corresponding to maximum green intensity 0 1 byte a zero byte to separate fields min_blue m bytes raw sample value corresponding to minimum blue intensity 0 1 byte a zero byte to separate fields max_blue m bytes raw sample value corresponding to maximum blue intensity If this chunk is present, graylevel or color sample values are to PNG Development Group [Page 4] PNG-GROUP-DRAFT PNG Proposed SciVis Chunks 19960914 14 Sep 1996 be scaled for display between minimum and maximum intensity by linear interpolation. When the sample value falls outside the range min_value..max_value, it is to be set to min_value or max_value as appropriate. For each graylevel or color sample, the conversion is ratio := (2^bit_depth - 1)/(max_value - min_value) result := (input_sample - min_value) * ratio output_sample := LIMIT (0, result, 2^output_bit_depth-1) in which the function LIMIT (low, x, high) is MAX (MIN (x, high), low). In indexed-color images, bit_depth == 8 in this calculation, regardless of the bit depth actully used to store the indices. Note that min_value and max_value are permitted to be negative, positive, or zero. The only restriction is that they be different from each other. Encoders should not use drNG/DrNG in lieu of reasonably scaling the samples. For example, if the sample values range from 0 (black) to 1000 (white), it would be an extremely bad idea to use the drNG chunk to request the decoder to scale 1000 up to 65535, because a PNG viewer that does not understand drNG/DrNG (and, since this is an extension chunk, most viewers will probably not understand drNG/DrNG) would simply display a very dark rectangle. Instead, multiply your samples by 64, and use drNG with max_sample=64000 to request the decoder to do the final adjustment. If the tRNS chunk is present, its value is compared to the unscaled pixel value, prior to applying the drNG/DrNG scaling. The faLT, gAMA, cHRM, and alpha conversions, if present, are applied to the scaled sample values. If present, this chunk must appear before the first IDAT chunk. Only one drNG/DrNG chunk is permitted in a PNG file. 4.2. faLT False-color Palette Format last changed in version 19960914 of this document (September 1996). The name has been changed from faLS to faLT to distinguish the versions; the proposed name of the registered chunk is fALS. The "signature" field and its null separator will not be included in the registered chunk. This chunk is used with grayscale data, where the pixels are to be rendered in a false color according to the grayscale value. The grayscale sample of each pixel serves as a pointer into the false-color palette. PNG Development Group [Page 5] PNG-GROUP-DRAFT PNG Proposed SciVis Chunks 19960914 14 Sep 1996 This chunk's contents are a zero-byte-terminated text string (purpose) that names the palette, followed (after the 20-byte signature and its null-byte separator) by a series of false-color palette entries: purpose: n bytes (ASCII text) separator: 1 byte, null signature: 20 bytes ("PNG group 1996-09-14") separator: 1 byte, null index: 2 bytes, range 0 .. (2^bitdepth) -1) red: 2 bytes, range 0 .. 65535 green: 2 bytes, range 0 .. 65535 blue: 2 bytes, range 0 .. 65535 etc. The number of entries is determined from the remaining chunk length after the signature field and the null separator. This length not divisible by 8 is an error. The "purpose" identifies the palette, which can permit applications or people to choose the appropriate one when more than one false-color palette is stored in a multiple-image file. The "purpose" string must follow the format of a tEXt keyword, i.e. 1-79 printable ASCII characters. The gamma field gives the value of gamma, times 100000, that is associated with the false-color palette entries. This chunk can appear for color type 0 or color type 4. If it appears for any other color type, it will be ignored. The complete 2^bitdepth-entry false-color palette can be built from the chunk data. If the first entry (index value 0) is missing, it will be assumed to be {0, 0, 0} (black). If the last entry (index value 2^bitdepth - 1) is missing, it will be assumed to be {65535, 65535, 65535} (white). The red, green, blue samples for other missing entries are filled in by linearly interpolating between the samples that are present, independently for each of the three color components. Once the complete false-color palette is established, it is used similarly to PLTE. The first entry in the completed false-color palette is referenced by the grayscale value 0, the second by grayscale value 1, etc. If the tRNS chunk is present, its value is compared to the graylevel, not to the converted false-color of the pixels. If the bKGD chunk is present, background pixels will be displayed in the false-color corresponding to the grayscale value found in the bKGD chunk. The cHRM and alpha conversions, if present, are applied to the color samples in the converted false-color pixels. The gAMA PNG Development Group [Page 6] PNG-GROUP-DRAFT PNG Proposed SciVis Chunks 19960914 14 Sep 1996 chunk is ignored when the faLT chunk is processed, and the supplied gamma value is used instead. Note that the gAMA and other values must be selected so that the grayscale image is meaningfully displayed when the faLT chunk is unrecognized or ignored. If this chunk does appear, it must precede the first IDAT chunk. There can be only one faLT chunk in a PNG file. 4.3. loGE/LoGE Logarithmic Encoding Format last changed 06 April 1996 (Version 19960406). The proposed registered name for this chunk is lOGE/LOGE. The loGE/LoGE chunk is used to decode image data whose grayscale or color samples have been logarithmically encoded. The chunk can be used as a critical chunk, named LoGE, or as an ancillary chunk, named loGE. The syntax and function is exactly the same whichever name is used. The critical version should only be used if the image cannot be meaningfully displayed without performing LoGE scaling. Decoders not recognizing LoGE will not attempt to display the image at all. Encoders are strongly encouraged to include a gAMA chunk that permits a meaningful if not completely accurate display, and use the noncritical version, loGE, if at all possible. The loGE/LoGE chunk's contents are P0 n0 bytes (First parameter, a real number written as a text floating-point value [link to Floating-Point Values in extensions document] Null separator: 1 byte P1 n1 bytes (Second parameter) Null separator: 1 byte P2 n2 bytes (Third parameter) There is no trailing zero for the final string. The scaling algorithm is PNG Development Group [Page 7] PNG-GROUP-DRAFT PNG Proposed SciVis Chunks 19960914 14 Sep 1996 normalized_sample_value := input_sample/(2^input_bitdepth-1) scaled_value := P0 + P1 * P2^normalized_sample_value output_sample := LIMIT (0, scaled_value, 2^output_bitdepth-1) in which the function LIMIT (low, x, high) is MAX (MIN (x, high), low). For color_types 0 and 4, the normalized sample value is the grayscale value of the pixel normalized to the range [0.0:1.0] by dividing it by the maximum value for the input bit depth, using floating point arithmetic. For color_types 2, 3, and 6, the scaling algorithm is applied independently to each of the color samples similarly normalized to [0.0:1.0]. The alpha channel, if present, is not affected by the loGE/LoGE transformation. Alpha compositing is done in the normal manner, with the transformed pixels forming the foreground image [link to Decoders: Alpha Processing in core spec] Pure logarithmic data can be expressed with P0 := 0 P1 := min_val P2 := max_val/min_val In which the range [min_val..max_val] includes the minimum and maximum values appearing in the source data. When the image is decoded using the loGE/LoGE data, the gamma calculation for the decoded samples should be done as though the file_gamma were 1.0, regardless of the contents of the gAMA chunk. It is advisable to include a gAMA chunk with logarithmic data, in case a viewer does not use the loGE data to decode it. A value of gamma should be chosen that allows the image to be displayed as well as it can be with a viewer that supports gAMA but not loGE. You can select a value of gamma (also called file_gamma) by eye as described in [link to Gamma Tutorial: General Gamma Handling in core spec], or you can calculate one as follows: If the maximum value of the logarithmically decoded pixels can reasonably be displayed as white on the monitor, then specifying a value of gamma given by gamma := LN( LN(0.2) / LN(max_val/min_val) + 1) / LN(0.2) (in which LN() is the natural logarithm function) causes the two values max_val and 0.2*max_val to be reproduced at correct brightness on screen - these can be thought of as white PNG Development Group [Page 8] PNG-GROUP-DRAFT PNG Proposed SciVis Chunks 19960914 14 Sep 1996 and mid-grey. Tones between white and mid-grey will be a bit too bright, ones darker than mid-grey will be increasingly too dark, but it's a reasonable approximation for viewable display. A max_val/min_val ratio of 64 gives a gamma of about 0.3, a max_val/min_val of 1000 gives a gamma of about 0.165, so a viewer assuming a default gamma of 0.45 is going to give a bright, washed-out image for any log-encoded image. In cases where the maximum sample value is many times brighter than scene white (i.e. the image is encoded to retain specular highlight information), the formula above doesn't apply, but there's probably no way of getting such an image to display reasonably anyway with a viewer that doesn't understand loGE. If present, the loGE/LoGE chunk must appear before the first IDAT chunk. Only one instance of the loGE/LoGE chunk is permitted in a PNG datastream. 4.4. pcAL Scale of Pixel Values Format last changed 20 August 1996 (Version 19960914) In the previous version, this chunk was called zsCL. The proposed registered name for this chunk is pCAL. When a PNG file is being used to store physical data other than color values, such as a two-dimensional temperature field, the pcAL chunk can be used to record the relationship between pixel values and actual physical values. The pcAL data might be used to construct a reference color bar beside the image. It is not expected to affect the way the image is displayed. The pcAL chunk's contents are are a zero-byte-terminated text string (purpose) that names the equation, followed (after the 20- byte signature and its null-byte separator) by an equation type and a set of parameters for the equation: purpose: n bytes (ASCII text) separator: 1 byte, null signature: 20 bytes ("PNG group 1996-09-14") separator: 1 byte, null Equation type 1 byte (0 for linear scaling, 1 for base-e exponential scaling, 2 for arbitrary-base exponential scaling, 3 for hypberbolic scaling) N 1 byte (Number of parameters) PNG Development Group [Page 9] PNG-GROUP-DRAFT PNG Proposed SciVis Chunks 19960914 14 Sep 1996 Unit u bytes (Latin-1 symbol or description of the unit, eg. K, Population Density, MPa, etc). A zero-length string can be used if the data is dimensionless. Null separator: 1 byte P0 p0 bytes (First parameter, a real number written as a text floating-point value [link to Floating-Point Values in PNG extensions document] Null separator: 1 byte P1 p1 bytes (Second parameter) Null separator: 1 byte (must appear if P2 is present) P2 p2 bytes (Third parameter, optional) etc. Null separator: 1 byte (must appear if PM is present) PM pm bytes (M+1 parameter, optional, where M < N. If PM is present, P[M-1] must also be present) There is no trailing zero for the final string. The "purpose" identifies the equation, which can permit applications or people to choose the appropriate one when more than one scaling equation is stored in a multiple-image file. The "purpose" string must follow the format of a tEXt keyword, i.e. 1-79 printable ASCII characters. The scaling algorithm is if equation_type == 0 then scaled_value := P0 + P1 * normalized_sample_value else if equation_type == 1 then scaled_value := P0 + P1 * EXP(P2 * normalized_sample_value) else if equation_type == 2 then scaled_value := P0 + P1 * P2^normalized_sample_value else if equation_type == 3 then scaled_value := P0 + P1*SINH((normalized_sample_value - P2)/P3) in which PNG Development Group [Page 10] PNG-GROUP-DRAFT PNG Proposed SciVis Chunks 19960914 14 Sep 1996 * EXP(x) is the exponential function, e^x, in which "e" is the base of natural logarithms (approximately 2.718282) * SINH(x) is the hyperbolic sine of x, SINH(x) := 0.5 * ( EXP(x) - EXP(-x) ) For color_types 0 and 4, the normalized sample value is the grayscale sample value of the pixel normalized to the range [0.0:1.0] by dividing it by the maximum value for the bit depth, using floating point arithmetic. For color_types 2, 3, and 6, the scaling algorithm is applied independently to each of the color sample values similarly normalized to [0.0:1.0]. Pure logarithmic data can be expressed either with Equation_type =: 1 Equation_type := 2 N =: 3 or with N := 3 P0 =: 0 P0 := 0 P1 =: min P1 := min P2 =: LOGe(max/min) P2 := max/min The pcAL data is not intended to be used by a decoder to affect the way the pixels are displayed. pcAL is simply a comment, and could be used, for example, to construct a reference color bar scale beside the image, or to extract the original physical values recorded in the file. The drNG/DrNG or loGE/LoGE chunk should be used if the encoder wants the decoder to modify the sample values for display purposes. If present, the pcAL chunk must appear before the first IDAT chunk. Only one instance of the pcAL chunk is permitted in a PNG stream. 4.5. tsCL Physical time scale New proposed chunk, 16 August 1996 (Version 19960816). The proposed registered name for this chunk is tSCL. This is like xsCL chunk except that it gives the scale and offset in the frame-to-frame direction, which would normally be the physical time scale. It would be meaningless in a PNG stream, but in a multi-image format it could be used at the top level, to provide the physical scale (rather than the display frame rate) in the frame-to-frame direction. 4.6. xsCL X-Scale of Image Subject New chunk, 16 August 1996 (Version 19960816). This chunk was formerly included in the xySC chunk. The proposed registered name for this chunk is xSCL. PNG Development Group [Page 11] PNG-GROUP-DRAFT PNG Proposed SciVis Chunks 19960914 14 Sep 1996 This chunk relates the actual dimension of the image subject in the "x" (width) direction to the column position of a pixel. It provides some additional capability beyond that available in the sCAL [link to sCAL in PNG extensions document] chunk, which does not provide for an offset, and does not provide for different units in the width and height directions. The latter could be useful, for example, in racing photo-finish "streak" images, where one of the dimensions is time and the other is length. The chunk does not affect the image display, but could be used to construct scaled axes adjacent to the image. The xSCL chunk's contents are Xunit xu bytes (Latin-1 symbol or description of the width unit, eg. milliseconds, degrees West Longitude, etc). A zero-length string can be used if the data is dimensionless. Null separator: 1 byte Xoffset xo bytes X offset, a real number written as a text floating-point value [link to Floating-Point Values in PNG extensions document] This is the physical value of "x" corresponding to the left edge of the image. Null separator: 1 byte Xscale xs bytes X scale, the x-distance corresponding to the width of a pixel. Must be non-zero. There is no trailing zero for the final string. The scaling algorithm for finding the physical x-value of the middle of a pixel is physical_x_value := Xoffset + Xscale * (column_number + 0.5) If present, the xsCL chunk must appear before the first IDAT chunk. Only one instance of the xsCL chunk is permitted in a PNG stream. 4.7. ysCL Y-Scale of Image Subject New chunk, 16 August 1996 (Version 19960816). This chunk was formerly included in the xySC chunk. The proposed registered name for this chunk is ySCL. This chunk is similar to the xsCL chunk. It relates the actual PNG Development Group [Page 12] PNG-GROUP-DRAFT PNG Proposed SciVis Chunks 19960914 14 Sep 1996 dimension of the image subject in the "y" (height) direction to the row position of a pixel, positive downward from the top. The ysCL chunk's contents are Yunit yu bytes (Latin-1 symbol or description of the width unit, eg. milliseconds, degrees North Latitude, etc). A zero-length string can be used if the data is dimensionless. Null separator: 1 byte Yoffset yo bytes Y offset, a real number written as a text floating-point value [link to Floating-Point Values in extensions document] This is the physical value of "y" corresponding to the top edge of the image. Null separator: 1 byte Yscale ys bytes Y scale, the y-distance corresponding to the height of a pixel. Must be non-zero. The positive direction is downward. There is no trailing zero for the final string. The scaling algorithm for finding the physical y-value of the middle of a pixel is physical_y_value := Yoffset + Yscale * (row_number + 0.5) If present, the ysCL chunk must appear before the first IDAT chunk. Only one instance of the ysCL chunk is permitted in a PNG stream. 4.8. zsCA Z scale New proposal, 16 August 1996 (Version 19960816). The proposed registered name for this chunk is zSCL. We use zsCA here instead of zsCL because the name zsCL was used in another context in a previous draft. This is like xsCL chunk except that it gives the z-scale and offset in the thickness direction, when a series of images are considered to be layers of voxels (tomographics slices). It would be meaningless in a PNG stream, but in a multi-image format it could be used to provide the physical dimension in the frame-to- frame direction, or when images are grouped as in a composite frame, to give the dimension in the plane-to-plane direction PNG Development Group [Page 13] PNG-GROUP-DRAFT PNG Proposed SciVis Chunks 19960914 14 Sep 1996 within the group. 5. Security considerations Security considerations are addressed in the basic PNG specification, http://www.w3.org/pub/WWW/TR/WD-png. The same precautions taken when displaying tEXt data should be taken when displaying the text contained in the "unit" strings of the xsCL and pcAL chunks and the "purpose" string of the faLT and pcAL chunks. Viewers should not display these strings directly without first checking for the presence of nonprintable characters, and for the character in particular. No known additional security hazards are posed by the chunks described here. 6. Credits Contributors Contributors' names are presented in alphabetical order: * Mark Adler, madler@alumni.caltech.edu * Thomas Boutell, boutell@boutell.com * Christian Brunschen, cb@df.lth.se * Adam M. Costello, amc@cs.berkeley.edu * Lee Daniel Crocker, lee@piclab.com * Andreas Dilger, adilger@enel.ucalgary.ca * Oliver Fromme, fromme@rz.tu-clausthal.de * Todd French, tfrench@sandia.gov * Jean-loup Gailly, gzip@prep.ai.mit.edu * Chris Herborth, chrish@qnx.com * Alex Jakulin, alex@hermes.si * Neal Kettler, kettler@cs.colostate.edu * Jim King, jimk@mathtype.com * Tom Lane, tgl@sss.pgh.pa.us * Alexander Lehmann, alex@hal.rhein-main.de * Chris Lilley, chris@w3.org * Dave Martindale, davem@cs.ubc.ca * Owen Mortensen * Robert P. Poole, lionboy@primenet.com * Glenn Randers-Pehrson, glennrp@arl.mil or randeg@alumni.rpi.edu * Greg Roelofs, newt@pobox.com * Willem van Schaik, gwillem@ntuvax.ntu.ac.sg * Guy Schalnat * Paul Schmidt, pschmidt@photodex.com * Tim Wegner, 71320.675@compuserve.com PNG Development Group [Page 14] PNG-GROUP-DRAFT PNG Proposed SciVis Chunks 19960914 14 Sep 1996 Editor * Glenn Randers-Pehrson, glennrp@arl.mil or randeg@alumni.rpi.edu End of PNG Sci-Vis Chunks Specification. Expires 14 Mar 1997. PNG Development Group [Page 15] ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 14 08:37:06 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA26004 for ; Sat, 14 Sep 1996 08:37:05 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA07957 for png-list-outgoing; Sat, 14 Sep 1996 08:37:48 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA07952 for ; Sat, 14 Sep 1996 08:37:44 -0500 Date: Sat, 14 Sep 96 9:27:18 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: png-list@dworkin.wustl.edu Subject: Re: New drafts, 19960914 versions Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609140927.aa19248@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Fri, 13 Sep 96 20:12:59 EDT }From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB }Subject: New drafts, 19960914 versions }Message-ID: <9609132012.aa19211@THOR.ARL.MIL> } }New drafts posted to swrinde: } } png-proposed-chunks-19960914.html, .ps.gz, .txt.gz } png-scivis-chunks-19960914.html, .ps.gz, .txt.gz I reposted these two again to correct some typos (mainly a wrong date, September 06, in the header). Perfectionists can download a fresh copy from swrinde. If you're just interested in the technical content, don't bother; the ones I mailed out are otherwise identical. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 18 10:26:26 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.5/8.7.1) with SMTP id KAA18381 for ; Wed, 18 Sep 1996 10:26:24 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA24998 for png-list-outgoing; Wed, 18 Sep 1996 10:27:03 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA24958 for ; Wed, 18 Sep 1996 10:26:20 -0500 Received: by grommit.inria.fr (8.7.5/8.6.12) id RAA06976 for png-list@dworkin.wustl.edu; Wed, 18 Sep 1996 17:24:23 +0200 (DST) Date: Wed, 18 Sep 1996 17:24:23 +0200 (DST) From: Chris Lilley Message-Id: <9609181724.ZM6974@grommit.inria.fr> In-Reply-To: Chris Lilley "Re: Animation in the PNG format" (Aug 26, 3:31pm) References: <199608242010.PAA04122@mail.phoenix.net> <9608261531.ZM13694@grommit.inria.fr> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Long-term mail alias for PNG Group. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List The PNG spec says " Additional chunk types can be proposed for inclusion in that list by contacting the PNG specification maintainers at png-info@uunet.uu.net. " Concern was expressed how long that mail address would remain valid - a year? five? if it is going to get written into a specification that will hopefully last ten or more years. Tim Berners-Lee stated that W3C could host a long-term mail alias as a contact point for the PNG Group. So, I am about to set up png-group@w3.org which will simply point to png-list@dworkin.wustl.edu unless that address changes. How do folks feel about having this mail address? Comments please. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 18 11:05:28 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.1) with SMTP id LAA19816 for ; Wed, 18 Sep 1996 11:05:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA25829 for png-list-outgoing; Wed, 18 Sep 1996 11:07:00 -0500 Received: from boutell.com (boutell.com [206.125.69.81]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA25824 for ; Wed, 18 Sep 1996 11:06:55 -0500 Received: from localhost (boutell@localhost) by boutell.com (8.7.3/8.7.3) with SMTP id JAA31091 for ; Wed, 18 Sep 1996 09:13:11 -0700 Date: Wed, 18 Sep 1996 09:13:10 -0700 (PDT) From: Thomas Boutell To: PNG List Subject: Re: Long-term mail alias for PNG Group. In-Reply-To: <9609181724.ZM6974@grommit.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Wed, 18 Sep 1996, Chris Lilley wrote: > The PNG spec says > > " Additional chunk types can be proposed for inclusion in that > list by contacting the PNG specification maintainers at > png-info@uunet.uu.net. " > > Concern was expressed how long that mail address would remain valid - a year? > five? if it is going to get written into a specification that will hopefully > last ten or more years. > > Tim Berners-Lee stated that W3C could host a long-term mail alias as a > contact point for the PNG Group. So, I am about to set up > > png-group@w3.org > > which will simply point to png-list@dworkin.wustl.edu unless that address > changes. > > How do folks feel about having this mail address? Comments please. Sounds great to me. I tend to just forward those messages to png-list anyway. -T ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 18 12:58:30 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id MAA21521 for ; Wed, 18 Sep 1996 12:58:29 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA29008 for png-list-outgoing; Wed, 18 Sep 1996 12:59:00 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA29003 for ; Wed, 18 Sep 1996 12:58:52 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.5/8.7.3) with ESMTP id KAA17919 for ; Wed, 18 Sep 1996 10:50:21 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.5/8.7.3) id KAA29088 for png-list@dworkin.wustl.edu; Wed, 18 Sep 1996 10:50:20 -0700 (PDT) Message-Id: <199609181750.KAA29088@web1.calweb.com> Subject: Long-term mail alias for PNG Group. To: png-list@dworkin.wustl.edu Date: Wed, 18 Sep 1996 10:50:20 -0700 (PDT) From: "Lee Daniel Crocker" Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > Tim Berners-Lee stated that W3C could host a long-term mail > alias as a contact point for the PNG Group. So, I am about > to set up png-group@w3.org... I have no reason to think this is more stable or long-term than "png-info@uunet.uu.net". In fact, I think Uunet has a better history, a reputation for reliability, and a greater chance of remaining unchanged than does w3.org. Has Uunet expressed any reservation about the address? I can't imagine them not wanting to host the contact address of an RFC. The W3C is a technology creating entity--on the bleeding edge, a moving target. Uunet is the old guard, stable, reliable, inflexible. -- Lee Daniel Crocker ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 18 15:29:31 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id PAA24078 for ; Wed, 18 Sep 1996 15:29:28 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA02424 for png-list-outgoing; Wed, 18 Sep 1996 15:30:06 -0500 Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA02419 for ; Wed, 18 Sep 1996 15:30:02 -0500 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id PAA06121 for ; Wed, 18 Sep 1996 15:27:12 -0500 (CDT) Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.5/8.7.3) id PAA10068 for png-list@dworkin.wustl.edu; Wed, 18 Sep 1996 15:28:08 -0500 (CDT) Date: Wed, 18 Sep 1996 15:28:08 -0500 (CDT) Message-Id: <199609182028.PAA10068@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: Re: Long-term mail alias for PNG Group. From: Cave Newt Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List "Lee Daniel Crocker" wrote: >I have no reason to think this is more stable or long-term >than "png-info@uunet.uu.net". In fact, I think Uunet has a >better history, a reputation for reliability, and a greater >chance of remaining unchanged than does w3.org. I think this is debatable. By all accounts, service providers are feeling a pinch these days, and removing freebies (or starting to charge for them) might become policy sooner rather than later. UUNET is also aligning itself with Microsoft these days, which could portend many things but certainly suggests that there might be changes in their mail setup before long. In any case, W3C is the only entity that matters with respect to the current Working Draft. If they want their e-mail address in their copy, who cares? Nobody said anything about touching the RFCs. >The W3C is a technology creating entity--on the bleeding edge, >a moving target. Uunet is the old guard, stable, reliable, >inflexible. ...commercial, busy, semi-unresponsive, and switching from Unix to NT. Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 18 16:53:30 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA25200 for ; Wed, 18 Sep 1996 16:53:17 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA03740 for png-list-outgoing; Wed, 18 Sep 1996 16:53:40 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA03734 for ; Wed, 18 Sep 1996 16:53:29 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id OAA28552 for ; Wed, 18 Sep 1996 14:44:53 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.5/8.7.3) id OAA02790 for png-list@dworkin.wustl.edu; Wed, 18 Sep 1996 14:44:52 -0700 (PDT) Message-Id: <199609182144.OAA02790@web1.calweb.com> Subject: Re: Long-term mail alias for PNG Group. To: png-list@dworkin.wustl.edu Date: Wed, 18 Sep 1996 14:44:52 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <199609182028.PAA10068@ellis.uchicago.edu> from "Cave Newt" at Sep 18, 96 03:28:08 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > In any case, W3C is the only entity that matters with respect to > the current Working Draft. If they want their e-mail address in > their copy, who cares? Nobody said anything about touching the > RFCs. If they want a W3 address, that't great. I just assumed that since the message said something like "concern was expressed" about the permanence of the Uunet address, that the issue was about the permanent document, i.e., the RFC. I agree that Uunet might start charging for their traditionally free services (though I doubt it--hundreds of newsgroup moderators and other net groups depend on them, and if they started changing their benevolence, they would quickly lose their respect and de facto power over things like newsgroup creation). I also agree that W3C's copy of the spec should have a W3C address. But when it comes to the real RFC, I think the Uunet address is the only way to go. And as for your comment about Uunet "aligning themselves" with Microsoft: name an instance where Uunet has allowed Microsoft to have any influence over its services or the nature of the net or with standards they support, the way W3C bowed to their inclusion of DCOM and VBScript in the OBJECT spec. W3C is a good thing overall, and I'm glad they exist, and I'm glad they're on our side, but let's not throw ourselves at them blindly before they prove themselves the way Uunet has. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 18 16:56:09 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA25225 for ; Wed, 18 Sep 1996 16:56:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA03812 for png-list-outgoing; Wed, 18 Sep 1996 16:57:35 -0500 Received: from inet.htcnet.com (inet.htcnet.com [199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA03806 for ; Wed, 18 Sep 1996 16:57:32 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id QAA07117 for ; Wed, 18 Sep 1996 16:58:23 -0500 Message-Id: <199609182158.QAA07117@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: Re: Long-term mail alias for PNG Group. Date: Wed, 18 Sep 1996 16:55:36 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List | I have no reason to think this is more stable or long-term | than "png-info@uunet.uu.net". In fact, I think Uunet has a | better history, a reputation for reliability, and a greater | chance of remaining unchanged than does w3.org. Has Uunet | expressed any reservation about the address? I can't imagine | them not wanting to host the contact address of an RFC. I don't know about you, but have you been reading the news... UU net has appearently gone through some ownership changes... in otherwords their a corporation subject to anything... The W3C is really an organization charged with WWW and internet based standards, ie PNG... ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 18 17:35:01 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA25622 for ; Wed, 18 Sep 1996 17:34:58 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA04189 for png-list-outgoing; Wed, 18 Sep 1996 17:36:29 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA04163 for ; Wed, 18 Sep 1996 17:36:24 -0500 Received: by grommit.inria.fr (8.7.5/8.6.12) id AAA08156 for png-list@dworkin.wustl.edu; Thu, 19 Sep 1996 00:34:31 +0200 (DST) Date: Thu, 19 Sep 1996 00:34:31 +0200 (DST) From: Chris Lilley Message-Id: <9609190034.ZM8154@grommit.inria.fr> In-Reply-To: Lee Daniel Crocker "Re: Long-term mail alias for PNG Group." (Sep 18, 2:44pm) References: <199609182144.OAA02790@web1.calweb.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: Long-term mail alias for PNG Group. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 18, 2:44pm, Lee Daniel Crocker wrote: > > In any case, W3C is the only entity that matters with respect to > > the current Working Draft. If they want their e-mail address in > > their copy, who cares? Nobody said anything about touching the > > RFCs. > > If they want a W3 address, that't great. I just assumed that > since the message said something like "concern was expressed" about > the permanence of the Uunet address, that the issue was about the > permanent document, i.e., the RFC. If all goes well and the W3C Recommendation is announced soon, that will also be a permanent document. Recommendation is what non-standards bodies such as the CCIR, CIE and ITU call their standards documents. This will be available online but will also be a printed document that libraries and such can order. It is also a permanent document in that it is a visibly finished work which other bodies can cite in their documents. W3C has already had enquiries from a couple of organisations about citing PNG as _the_ standard format for losslessly compressed still images. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 18 17:42:54 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA25741 for ; Wed, 18 Sep 1996 17:42:54 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA04349 for png-list-outgoing; Wed, 18 Sep 1996 17:44:30 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA04342 for ; Wed, 18 Sep 1996 17:44:25 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id PAA08361 for ; Wed, 18 Sep 1996 15:35:47 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id PAA29944 for png-list@dworkin.wustl.edu; Wed, 18 Sep 1996 15:35:47 -0700 (PDT) Message-Id: <199609182235.PAA29944@web1.calweb.com> Subject: Re: Long-term mail alias for PNG Group. To: png-list@dworkin.wustl.edu Date: Wed, 18 Sep 1996 15:35:46 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <199609182158.QAA07117@inet.htcnet.com> from "Carl Morris" at Sep 18, 96 04:55:36 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > I don't know about you, but have you been reading the news... UU net > has appearently gone through some ownership changes... in otherwords > their a corporation subject to anything... The W3C is really an > organization charged with WWW and internet based standards, ie PNG... Yes, I've been reading the news, including Usenet news, for 12 years. UUnet was here when I got here, and they've been here ever since. This newfangled "Web" thing has only been here for a fraction of that. If UUnet started losing money every quarter equivalent to W3C's entire budget, they'd still be around for 50 years. It is precisely because UUnet is a commercial entity, with millions of customers to which they are accountable, that I trust them to be around longer than an undercapitalized academic organization that could fold tomorrow with few repurcussions, or be supplanted by some new emerging technology or a better-capitalized industry consortium. Don't get me wrong, I applaud W3C's efforts, and I hope they do grow into an old, well-repected, powerful organization like MIT itself has become--but right now they're just the new kids on the block. -- Lee Daniel Crocker ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 18 18:02:24 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA25834 for ; Wed, 18 Sep 1996 18:02:24 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA04743 for png-list-outgoing; Wed, 18 Sep 1996 18:03:25 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA04737 for ; Wed, 18 Sep 1996 18:03:21 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id PAA11843 for ; Wed, 18 Sep 1996 15:54:49 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id PAA09452 for png-list@dworkin.wustl.edu; Wed, 18 Sep 1996 15:54:48 -0700 (PDT) Message-Id: <199609182254.PAA09452@web1.calweb.com> Subject: Re: Long-term mail alias for PNG Group. To: png-list@dworkin.wustl.edu Date: Wed, 18 Sep 1996 15:54:48 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <9609190034.ZM8154@grommit.inria.fr> from "Chris Lilley" at Sep 19, 96 00:34:31 am Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > If all goes well and the W3C Recommendation is announced soon, that will > also be a permanent document. Recommendation is what non-standards bodies > such as the CCIR, CIE and ITU call their standards documents. This will be > available online but will also be a printed document that libraries and > such can order. > > It is also a permanent document in that it is a visibly finished work which > other bodies can cite in their documents. W3C has already had enquiries > from a couple of organisations about citing PNG as _the_ standard format > for losslessly compressed still images. Cool. Again, I think if the W3C wants to have its name in the contact address for its copy of the document, that's fine. I hope the W3C is alive and well years from now and still doing good work. I just think it's funny that "concerns were expressed" (whatever that means) about the permanence of the UUnet address by an organization as new and as small (compared to UUnet) as the W3C. -- Lee Daniel Crocker ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 18 18:06:26 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA25848 for ; Wed, 18 Sep 1996 18:06:25 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA04867 for png-list-outgoing; Wed, 18 Sep 1996 18:08:14 -0500 Received: from u11.CS.Berkeley.EDU (u11.CS.Berkeley.EDU [128.32.38.135]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA04862 for ; Wed, 18 Sep 1996 18:08:11 -0500 Received: (from amc@localhost) by u11.CS.Berkeley.EDU (8.6.11/8.6.9) id QAA11684 for png-list@dworkin.wustl.edu; Wed, 18 Sep 1996 16:06:18 -0700 Date: Wed, 18 Sep 1996 16:06:18 -0700 Message-Id: <199609182306.QAA11684@u11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: Long-term mail alias for PNG Group. X-Advice: perhaps read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Cave Newt says: > In any case, W3C is the only entity that matters with respect to the > current Working Draft. If they want their e-mail address in their > copy, who cares? Nobody said anything about touching the RFCs. I'd prefer the two documents to be as identical as possible. Also, one email-address is easier to maintain than two. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 18 18:28:33 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA26009 for ; Wed, 18 Sep 1996 18:28:32 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA05762 for png-list-outgoing; Wed, 18 Sep 1996 18:30:08 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id SAA05749 for ; Wed, 18 Sep 1996 18:29:59 -0500 Date: Wed, 18 Sep 96 19:25:17 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Long-term mail alias for PNG Group. Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609181925.aa24161@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List } }Also, one email-address is easier to maintain than two. } I can't imagine that much maintenance would be required if they are just pointers to png-list (although png-info@uunet is a pointer to Thomas Boutell, not to png-list). Maybe it wouldn't hurt to have the redundancy: mention both Uunet and W3.org in all versions of the spec. Then as long as both uunet and w3c don't go belly-up in the next 10 years we're covered. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 18 18:49:10 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA26064 for ; Wed, 18 Sep 1996 18:49:09 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA06025 for png-list-outgoing; Wed, 18 Sep 1996 18:50:37 -0500 Received: from u11.CS.Berkeley.EDU (u11.CS.Berkeley.EDU [128.32.38.135]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA06020 for ; Wed, 18 Sep 1996 18:50:33 -0500 Received: (from amc@localhost) by u11.CS.Berkeley.EDU (8.6.11/8.6.9) id QAA11989 for png-list@dworkin.wustl.edu; Wed, 18 Sep 1996 16:48:40 -0700 Date: Wed, 18 Sep 1996 16:48:40 -0700 Message-Id: <199609182348.QAA11989@u11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: Long-term mail alias for PNG Group. X-Advice: perhaps read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > Maybe it wouldn't hurt to have the redundancy: mention both Uunet and > W3.org in all versions of the spec. The redundancy might outweigh the extra maintenance. And I like the consistency. The spec should advise people to send mail to one or the other, not both. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 19 08:21:29 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id IAA01891 for ; Thu, 19 Sep 1996 08:21:29 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA13695 for png-list-outgoing; Thu, 19 Sep 1996 08:22:35 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA13690 for ; Thu, 19 Sep 1996 08:22:32 -0500 Date: Thu, 19 Sep 96 9:19:13 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Long-term mail alias for PNG Group. Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609190919.aa04856@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I'll send a note to RFC editor asking her to add "or at png-group@w3.org" at the end of the two sentences in the PNG 1.0 draft RFC that refer to png-info@uunet.uu.net. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 19 08:47:32 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id IAA02516 for ; Thu, 19 Sep 1996 08:47:31 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA13957 for png-list-outgoing; Thu, 19 Sep 1996 08:47:33 -0500 Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA13952 for ; Thu, 19 Sep 1996 08:47:30 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by wugate.wustl.edu (8.7.5/8.7.3) with ESMTP id IAA22706 for ; Thu, 19 Sep 1996 08:46:14 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id JAA17796 for ; Thu, 19 Sep 1996 09:44:32 -0400 (EDT) To: PNG List Subject: Re: Long-term mail alias for PNG Group. In-reply-to: Your message of Thu, 19 Sep 96 9:19:13 EDT <9609190919.aa04856@THOR.ARL.MIL> Date: Thu, 19 Sep 1996 09:44:31 -0400 Message-ID: <17794.843140671@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List FWIW, I have had zero trouble with the jpeg-info@uunet.uu.net alias, which has been in existence since late 1991. If I had to bet on whether a uunet or w3.org address would last longer, I'd take uunet. But having some redundancy in the listing in the spec is not a bad idea, particularly since the only archive site mentioned is uunet. We should definitely list both uunet and w3 mail addresses. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 19 10:45:58 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id KAA04012 for ; Thu, 19 Sep 1996 10:45:57 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA16264 for png-list-outgoing; Thu, 19 Sep 1996 10:46:58 -0500 Received: from www10.w3.org (www10.w3.org [18.23.0.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA16249 for ; Thu, 19 Sep 1996 10:46:51 -0500 Received: from baltazar.inria.fr (baltazar.inria.fr [138.96.32.59]) by www10.w3.org (8.7.5/8.7.3) with ESMTP id LAA25159 for ; Thu, 19 Sep 1996 11:44:50 -0400 (EDT) Received: by baltazar.inria.fr (8.7.5/8.6.12) id RAA02804; Thu, 19 Sep 1996 17:45:01 +0200 (MET DST) Message-Id: <199609191545.RAA02804@baltazar.inria.fr> X-Mailer: exmh version 1.6.7 5/3/96 To: png-group@w3.org Subject: test : don't read it Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Sep 1996 17:45:00 +0200 From: Stephane Boyera Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List testing the alias png-group@w3.org -- Stephane Boyera stephane.boyera@sophia.inria.fr INRIA/Semir/W3C +33 93 65 78 34 BP 93 fax: +33 93 65 76 02 F-06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 19 15:54:56 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id PAA12519 for ; Thu, 19 Sep 1996 15:54:54 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA22044 for png-list-outgoing; Thu, 19 Sep 1996 15:55:33 -0500 Received: from www10.w3.org (www10.w3.org [18.23.0.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA22039 for ; Thu, 19 Sep 1996 15:55:27 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by www10.w3.org (8.7.5/8.7.3) with ESMTP id QAA05826 for ; Thu, 19 Sep 1996 16:53:25 -0400 (EDT) Received: by grommit.inria.fr (8.7.6/8.6.12) id WAA12337 for png-group@w3.org; Thu, 19 Sep 1996 22:53:26 +0200 (DST) Date: Thu, 19 Sep 1996 22:53:26 +0200 (DST) From: Chris Lilley Message-Id: <9609192253.ZM12335@grommit.inria.fr> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: png-group@w3.org Subject: PNG decode deterministic? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Hi I was asked something about PNG recently and I didn't know the anser, so... PNG has asymetric encode/decode, such that decode is faster. Fine. Is the decode time for PNG deterministic? Is there a calculable worst-case time for a given size of image, or is it possible with some particular image data and filter type that it takes a really long time? Question was for a specification for a real-time multimedia system. As I understand it the operations are: per IDAT chunk check checksum, this is linear WRT IDAT size? per scanline call zlib with compressed data - is this linear? Does a wide, short image decode slower than a narrow, tall image? Is decompress time affected by the zlib compression level usedt o compress it? read filter byte - constant apply reverse filter - per filter, linear wrt scanline size. Paeth is the slowest? perform gamma correction - linear wrt number of pixels Comments? -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 19 17:10:41 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA13774 for ; Thu, 19 Sep 1996 17:10:40 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA23856 for png-list-outgoing; Thu, 19 Sep 1996 17:11:50 -0500 Received: from inet.htcnet.com (inet.htcnet.com [199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA23851 for ; Thu, 19 Sep 1996 17:11:46 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id RAA19920 for ; Thu, 19 Sep 1996 17:12:42 -0500 Message-Id: <199609192212.RAA19920@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: Re: PNG decode deterministic? Date: Thu, 19 Sep 1996 17:09:45 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List | PNG has asymetric encode/decode, such that decode is faster. Fine. Is | the decode time for PNG deterministic? Is there a calculable worst-case | time for a given size of image, or is it possible with some particular | image data and filter type that it takes a really long time? Question | was for a specification for a real-time multimedia system. I am not sure, but I think its pretty simply something like n*m where m is the number of bytes and n is a constant that represents the amount of time the decode rotuine takes to decode a byte... (averaged over many bytes of course)... Of course each decoder has a different aprox speed... but it seems to be that in deflate, the time seems to be more dependant on just the number of bytes in the final output.... I am sure PNG adds some extra time with filters when used... -|- Carl Morris (N0YUV) -|- 1:285/302 -|- msftrncs@htcnet.com -|- -|- Hooper Connections BBS -|- 1-(402)-654-2102 -|- 28.8kbps V.34 -|- -|- http://199.120.83.179/~moreese/ -|- ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 19 17:39:21 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA14204 for ; Thu, 19 Sep 1996 17:39:17 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA24306 for png-list-outgoing; Thu, 19 Sep 1996 17:41:05 -0500 Received: from www10.w3.org (www10.w3.org [18.23.0.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA24301 for ; Thu, 19 Sep 1996 17:41:00 -0500 Received: from epfl2 (epfl2.epflbalto.org [192.188.199.6]) by www10.w3.org (8.7.5/8.7.3) with SMTP id SAA21337 for ; Thu, 19 Sep 1996 18:38:58 -0400 (EDT) Received: by epfl2 (5.0/SMI-SVR4) id AA24911; Thu, 19 Sep 1996 18:37:26 -0400 Date: Thu, 19 Sep 1996 18:37:25 -0400 (EDT) From: Glenn Randers-Pehrson To: PNG-group@w3.org Subject: Re: PNG decode deterministic? In-Reply-To: <9609192253.ZM12335@grommit.inria.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Chris wondered: > perform gamma correction - linear wrt number of pixels Gamma correction per pixel should just be a lookup operation. Yes, it's linear wrt number of pixels but insignificant compared to inflate and defiltering times. Building the LUT is linear wrt 2^bit_depth. ../randeg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 19 18:03:15 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA14524 for ; Thu, 19 Sep 1996 18:03:13 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA24801 for png-list-outgoing; Thu, 19 Sep 1996 18:05:01 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA24796 for ; Thu, 19 Sep 1996 18:04:54 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id PAA09720 for ; Thu, 19 Sep 1996 15:56:04 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id PAA08720 for png-list@dworkin.wustl.edu; Thu, 19 Sep 1996 15:56:06 -0700 (PDT) Message-Id: <199609192256.PAA08720@web1.calweb.com> Subject: Re: PNG decode deterministic? To: png-list@dworkin.wustl.edu Date: Thu, 19 Sep 1996 15:56:06 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <9609192253.ZM12335@grommit.inria.fr> from "Chris Lilley" at Sep 19, 96 10:53:26 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > check checksum, this is linear WRT IDAT size? Yep. And of course, the constant can be reduced to 0 if you want without affecting the decode process by just ignoring it. > per scanline > call zlib with compressed data - is this linear? Does a wide, short > image decode slower than a narrow, tall image? Is decompress time > affected by the zlib compression level usedt o compress it? I'm sure Mark or Jean-loup will correct me if I'm wrong, but deflate should be deterministic and bounded, but not linear, because you must traverse a Huffman tree for each input symbol. This is hard to put exact numbers on, because bizarre inputs can make the Huffman trees degenerate lists. So while average performance is O(n*log(n)), the worst case is probably O(n^2). The good news is that the compactness of the Huffman tree is roughly predictable from compression rate-- i.e., such a degenerate tree would fail to compress the data, so one can assume that data that is adequately compressed will decode in closer to the O(n*log(n)) time. > read filter byte - constant You can treat filter bytes as an extra column of pixels in terms of cost. > apply reverse filter - per filter, linear wrt scanline size. Paeth is > the slowest? Probably, because it requires compare/branch operations, and the rest are just computations. > perform gamma correction - linear wrt number of pixels Yep. Also reducible to 0. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 20 07:21:50 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id HAA19132 for ; Fri, 20 Sep 1996 07:21:49 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA04665 for png-list-outgoing; Fri, 20 Sep 1996 07:23:11 -0500 Received: from relay1.oleane.net (Relay1.OLEANE.NET [194.2.1.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA04660 for ; Fri, 20 Sep 1996 07:23:00 -0500 Received: from atlas.gemse.fr ([3.45.12.3]) by relay1.oleane.net (8.6.10/8.6.9) with SMTP id OAA17146 for ; Fri, 20 Sep 1996 14:20:55 +0200 Received: from bird.gemse.fr by atlas.gemse.fr (4.1/SMI-4.1) id AA07113; Fri, 20 Sep 96 14:02:34 +0200 Received: by bird.gemse.fr (5.0/SMI-SVR4) id AA19690; Fri, 20 Sep 1996 14:12:13 +0200 Date: Fri, 20 Sep 1996 14:12:13 +0200 Message-Id: <9609201212.AA19690@bird.gemse.fr> From: Jean-loup Gailly To: PNG List Subject: Re: PNG decode deterministic? In-Reply-To: <199609192256.PAA08720@web1.calweb.com> References: <9609192253.ZM12335@grommit.inria.fr> <199609192256.PAA08720@web1.calweb.com> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Chris writes: > Is the decode time for PNG deterministic? Yes. Decoding is linear in the output size. > per scanline > call zlib with compressed data - is this linear? Does a wide, short > image decode slower than a narrow, tall image? It's faster to decompress in chunks much larger than one scanline. In this case the shape of the image doesn't matter. If you really have to decode one scanline at a time, a wide short image should decode marginally faster than than a narrow, tall image. > Is decompress time affected by the zlib compression level used to > compress it? Very little. But zlib decompression is a bit faster if the data was compressed with the highest level (9) because there are fewer codes to decode. Lee writes: > I'm sure Mark or Jean-loup will correct me if I'm wrong, but deflate > should be deterministic and bounded, but not linear, because you must > traverse a Huffman tree for each input symbol. This is hard to put > exact numbers on, because bizarre inputs can make the Huffman trees > degenerate lists. So while average performance is O(n*log(n)), the > worst case is probably O(n^2). inflate uses a lookup table, so the decode time is O(n) if n is the number of input symbols. The longest codes cannot be decoded entirely with the lookup table, so they need a little extra tree traversal, but such codes are extremely rare, and only a few bits are decoded at worst, so there is a constant upper bound per input code in all cases. [I don't know the meaning of n for Lee, but if it is the number of input codes, decoding is definitely not O(n^2): the worst case length for a code is 15 bits, not n bits.] Jean-loup ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 20 16:02:50 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA25794 for ; Fri, 20 Sep 1996 16:02:48 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA13627 for png-list-outgoing; Fri, 20 Sep 1996 16:03:30 -0500 Received: from jeeves.va.pubnix.com (jeeves.va.pubnix.com [199.170.214.66]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA13619 for ; Fri, 20 Sep 1996 16:03:20 -0500 Received: from garotte.va.pubnix.com by jeeves.va.pubnix.com with ESMTP id RAA27360; Fri, 20 Sep 1996 17:01:07 -0400 (EDT) Received: from garotte.va.pubnix.com by garotte.va.pubnix.com with ESMTP id RAA12847; Fri, 20 Sep 1996 17:01:07 -0400 (EDT) Message-Id: To: PNG List Subject: Re: Long-term mail alias for PNG Group. In-reply-to: Your message of "Wed, 18 Sep 1996 10:50:20 PDT." <199609181750.KAA29088@web1.calweb.com> Date: Fri, 20 Sep 1996 17:01:06 -0400 From: "Josh M. Osborne" Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In message <199609181750.KAA29088@web1.calweb.com>, "Lee Daniel Crocker" writes : [...] >I have no reason to think this is more stable or long-term >than "png-info@uunet.uu.net". In fact, I think Uunet has a >better history, a reputation for reliability, and a greater >chance of remaining unchanged than does w3.org. Has Uunet >expressed any reservation about the address? I can't imagine >them not wanting to host the contact address of an RFC. [...] As an employee of UUNET Technologies, I must point out that "UUNET" is spelled in all caps (this goes under the heading of "I don't care what you write about me, just so long as my name is spelled right"). As I am not payed by UUNET to speak on their behalf I can not adress any of the fine points brought up by the other messages on this topic. At least not in any offical way. -- Not speaking for anyone other then myself - stripes@va.pubnix.com ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 22 10:13:01 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id KAA08593 for ; Sun, 22 Sep 1996 10:12:54 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA10769 for png-list-outgoing; Sun, 22 Sep 1996 10:12:03 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA10764 for ; Sun, 22 Sep 1996 10:11:58 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id QAA24843 for png-list@dworkin.wustl.edu; Sun, 22 Sep 1996 16:09:43 +0100 (MET) Date: Sun, 22 Sep 1996 16:09:43 +0100 (MET) From: Chris Lilley Message-Id: <9609221609.ZM24841@grommit.inria.fr> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: png-list@dworkin.wustl.edu Subject: Re: In defense of dRNG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Sorry for lag, folks, I used a different newsreader while reading mzail remotely in the USA, and it stuck all my unread mail in a file which I just now came across. Glenn writes, quoting the SGI image format spec: > PINMIN - The minimum pixel value in the image. The value of > 0 may be used if no pixel has a value that is smaller than 0. Does this mean that pixel values smaller than 0 are possible in this format? Interesting (and yes that can be desirable in some cases). > PINMAX - The maximum pixel value in the image. The value of > 255 may be used if no pixel has a value that is greater than 255. > This is the value that is considered to be full brightness in > the image. The problem is obvious - the spec isn't as well written as the PNG spec ;-) Two different things are treated as being the same. a) The value of the brightest pixel ocurring in the image (the statistical interpretation) b) The value for full brightness (that value might not occur in the image). It is also possible to have a format where pixels can have values greater than the maximum brightness - Kodak PhotoCD for example - but that does not appear to be the case here. > Disregarding the typos (PIN should be PIX), this description seems to > correspond to DRNG. It certainly appears that if your data ranged from > 30 to 240, PIXMAX could be 255, representing full brightness, and > PIXMIN by implication could be 0, representing full darkness. In your example, setting PIXMAX to either 255 or to 240 would both be in agreement with the spec - just different parts of the spec. > of PIXMIN and PIXMAX as statistical measures that you described seems > to be a result of another possible interpretation of this somewhat > terse spec, > that may not have been the intention of the author. Well, if the intentions of the author are not adequately described by the spec there is a problem. Since some tools from SGI themselves follow one interpretation and some follow another, I would conclude that the spec is ambiguous and we don't know which interpretation should be followed. The defect should be reported to SGI so they can fix the spec and fix whichever tool does not comply with the interpretation they settle on. At present, no, it is not possible to convert from SGI to PNG to SGI losslessly because it is also not possible to convert from SGI to anything to SGI loslessly because the supplied tools are inconsistent. It depends which of their tools you use. > The phrase > "considered to be full brightness in the image" is an exact description > of the max_sample value of DRNG. The problem is the word "in". Does that mean, full brightness for the scene (ie it may happen that no pixel has that value) or full brightness within that particular image? Take an example - some computer graphics of a room, with chair, table, and traditional desk lamp. The maximum brightness in the room is the bulb and that happens to be visible so there is a pixel with 255,255,255. Now crop the image so you cut out the lamp and just get the chair. Say the maximum pixel value is 138,164,147. Should this cropped image suddenly get brighter if we save it and load it in again? I would say not. It might be desirable in some instances to expand the range to see the shadow detail - particularly if there had been better than 8bit precision to start with - but that should be a change resulting from a conscious command from the user, not an automatic default promotion. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 22 10:17:37 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id KAA08618 for ; Sun, 22 Sep 1996 10:17:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA10877 for png-list-outgoing; Sun, 22 Sep 1996 10:18:21 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA10870 for ; Sun, 22 Sep 1996 10:18:18 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id QAA24847 for png-list@dworkin.wustl.edu; Sun, 22 Sep 1996 16:16:04 +0100 (MET) Date: Sun, 22 Sep 1996 16:16:04 +0100 (MET) From: Chris Lilley Message-Id: <9609221616.ZM24845@grommit.inria.fr> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: png-list@dworkin.wustl.edu Subject: sRGB proposed chunk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List As further input about the proposed sRGB chunk, I should add that W3C is in favour of the sRGB specification in general and has adopted it for Cascading Style Sheets. When you give an RGB value in CSS, you are specifying it in sRGB. So gamma, viewing flare, etc can be adjusted by good applications. It is likely IMHO that future versions of the HTML specification will also adopt sRGB so when you say the specification will actually define what color that is. My take on sRGB is that, as a chunk, it adds very few bytes to an image (well, the registered version without the id, at any rate) and if understood by an application can aid cross-platform portability and displayed quality. If not understood, then provided the gAMA and cHRM chunks were filled out with the suggested values, there is still some benefit. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 22 22:11:40 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id WAA14240 for ; Sun, 22 Sep 1996 22:11:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id WAA19964 for png-list-outgoing; Sun, 22 Sep 1996 22:13:15 -0500 Received: from mega.megamed.com (megamed.com [199.4.114.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id WAA19959 for ; Sun, 22 Sep 1996 22:13:10 -0500 Received: from coruisk (mega209.megamed.com [199.4.114.209]) by mega.megamed.com (8.7.5/8.7.3) with SMTP id UAA28061 for ; Sun, 22 Sep 1996 20:10:33 -0700 Date: Sun, 22 Sep 1996 20:10:33 -0700 Message-Id: <199609230310.UAA28061@mega.megamed.com> X-Sender: jbowler@megamed.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: John Bowler Subject: Re: sRGB proposed chunk Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 16:16 22/09/96 +0100, you wrote: >My take on sRGB is that, as a chunk, it adds very few bytes to an image >(well, the registered version without the id, at any rate) and if understood >by an application can aid cross-platform portability and displayed quality. >If not understood, then provided the gAMA and cHRM chunks were filled out >with the suggested values, there is still some benefit. Until sRGB is a part of the core PNG definition it is pretty much essential that applications write the gAMA and cHRM values too. Even when sRGB is part of the core definition there will be applications which handle cHRM and gAMA correctly but don't recognize sRGB - because they were implemented before the sRGB chunk is registered (or even suggested). These applications will be around for some time (years). The important extra in sRGB is the intent value - this specifies how to color match against a device which does not support the full gamut of the cHRM. Without this reliable good printing of a PNG image is impossible. My feeling is that this must become part of the core definition - i.e. a minimal requirement is a chunk which is the same as the current sRGB except that it does not imply cHRM or gAMA values. Such a chunk would allow data from a device with a non-sRGB gamut to be matched to a non-matching output device. Ironically when the gamut is not sRGB this is even more important - sRGB, to a first approximation, matches current video devices (at least in the gamut - Macs, PC video, Sun video and SGIs may well have a different gamma, but the cHRM tends to be the same). Other gamuts do not necessarily come close to a video device so color matching may be require too. In addition sRGB (the chunk, not the sRGB definition) has a problem of specification at present: If both cRHM (or gAMA) and sRGB are present and they differ, which takes precedence? It is viable, but not, I feel, useful to say that the image is invalid. It is viable to say that cHRM and gAMA take precedence - this allows sRGB to be used (or abused) to convey only the rendering intent. It would be useful if someone familiar with printing on systems other than Win32 PCs could comment on the suggested rendering intents:- "The following values are legal for the rendering intent specifier: 0: Perceptual rendering intent 1: Relative colorimetric rendering intent 2: Saturation preserving rendering intent 3: Absolute colorimetric rendering intent" John Bowler (jbowler@acm.org) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 00:25:19 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id AAA14691 for ; Mon, 23 Sep 1996 00:25:18 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA21763 for png-list-outgoing; Mon, 23 Sep 1996 00:27:24 -0500 Received: from mega.megamed.com (megamed.com [199.4.114.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id AAA21755 for ; Mon, 23 Sep 1996 00:27:18 -0500 Received: from coruisk (mega209.megamed.com [199.4.114.209]) by mega.megamed.com (8.7.5/8.7.3) with SMTP id WAA00155 for ; Sun, 22 Sep 1996 22:24:57 -0700 Date: Sun, 22 Sep 1996 22:24:57 -0700 Message-Id: <199609230524.WAA00155@mega.megamed.com> X-Sender: jbowler@megamed.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: John Bowler Subject: Re: A proposal for new-chunk process Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List No progress has been made on this since 9 September, thus it is in danger of suffering the same fate as the chunks which it is supposed to rescue. I suggest that unless we can get this right we will never be able to get chunk approval/registration/rejection right. No one commented on my suggestion, so I will quietly forget it - if you liked it speak now... Instead I'd like to try to formalize Tom's original proposal and the comments which followed it. With any luck this will be a working basis for a framework, without that luck I trust it will promote further discussion :-) Notes are in [], and would not appear in the final version, where I want real [] I have used \[\]. --------------------------------------- PNG chunk review and approval process ===================================== Purpose ======= To formally approve or reject a chunk for inclusion in the PNG extensions or core chunks documentation. Justification and additional aims ================================= Discussions on the PNG discussion list (png-list@dworkin.wustl.edu) at present fail to reach a clear consensus on the desirability of a particular chunk definition. The formal approval process is intended to aid such decisions by:- 1) Identifying consensus when it exists. 2) Giving a limited time period within which objections can be raised. 3) Encouraging discussion and preventing ambiguities when one party to the discussion simply falls silent. To meet these ends the formal process is based on a voting process exercised over a limited period of time. Prerequisites ============= 1) A specification of the chunk must exist in electronic form in a location on the current png-group discussion list FTP server (at present this is the tree based at ftp://swrinde.nde.swri.edu/pub/png-group/). 2) The specification may either be a whole single file, or group of files (which must be named by single ftp accessible directory name and implies all files in that directory and all directories beneath it) or an identified part of a single file. 3) Throughout the approval (voting) process the specification must remain substantially unchanged. A substantial change is one which is *not*:- i) A simple formatting or spelling change. ii) A printing or authorship date change. iii) An annotational change. "Annotational" refers to a part of the text which is not itself part of the specification (and is declared to be such) but merely annotates it. [This may all seem imprecise; in particular the phrase "an identified part of a single document" is imprecise. The rationale for this is that if the specification is imprecisely delimited then the voters will cast "NO" votes and it will be defeated. Also the voting process described below prevents abuse of the permission to make non-substantial changes.] Votes ===== Votes are cast by sending a message to the png-list indicating a YES or NO vote. Voters should take care to make their intentions clear (i.e. "YES" or "NO" and precisely what chunk specification is being voted on). To ensure that a vote is correctly registered the following form, as the first line of an email message, must always be accepted:- {YES|NO} \["specification change"\] For example:- YES ftp://swrinde.nde.swri.edu/pub/png-group/documents/png-new-chunks-19960914.h tml cNEW [NOTE: this differs from the current convention, whereby the chunks are called cnEW until approved then become cNEW. I don't want to burden this document with an attempt to specify that process, and I don't think it is necessary - the initiation of the voting process implies that at least one person thinks the chunk specification is ready.] If the words "specification change" appear following a "NO" vote the vote indicates that the author disagrees that a change to a specification in the voting period is non-substantial. To be valid there must have been a change to the file containing the specification (i.e. its content is no longer identical to the original). The words are ignored if they occur on a "YES" vote. Votes may be tallied by anyone and interpreted by anyone. [The purpose of this proposal is to fix the problem with approving chunks, not to build a system to document them, I think that part works OK at present, if it doesn't work we can fix that problem when we get to it.] Initiation ========== A vote is initiated by the first cast of a YES vote in favor of an identified specification. The voter should use the above form to avoid confusion. [If they don't use that form, well, I don't think it is necessary to explore the possibilities here.] Termination =========== The voting period ceases one calendar month after the initiation at the same time as the initiation. Should this day not exist the first day of the succeeding month is used. The time of the first vote is determined by the "Received:" line generated by the png-list email server, e.g. in:- Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA10764 for ; Sun, 22 Sep 1996 10:11:58 -0500 The date and time are "Sun, 22 Sep 1996 10:11:58 -0500" [I.e. if it starts on 31 Jan at 12:05 (UCT) it ends at 1 Mar 12:05 UCT. Personally I find this easier to understand, but I have no real problem with 30x86400 seconds.] Decision ======== A chunk specification is approved if the following conditions are met:- 1) 10 YES votes are received. [I think this is too high a hurdle, 5 sounds better]. 2) The number of YES votes is at least 5 more than the number of NO votes. [With the current numbers this is a redundant definition, but it seems better to have it now than to have to add it later.] 3) At least twice the number of YES votes than NO votes is received. [Willem's suggestion.] 4) No "NO" votes have been received with the "specification change" qualification. If these conditions are *not* met the chunk specification is rejected. A further vote requires a substantial change to the definition as a prerequisite. [I don't think I need to define "substantial" here - if the change isn't substantial all the NO voters will still vote NO and so, probably, will some of the YES voters.] Franchise ========= Anyone is eligible to vote who has:- 1) Submitted a message to the png-list in the last six calendar months. [I just added this, it hasn't been mentioned before.] 2) Submitted their first (or any subsequent) message to the png-list at least six calendar months before the *termination* of the voting period. If the corresponding (numerical) day does not exist in this month it is the *last* day of the *same* month. I.e. the day six months before 30 August is defined to be the last day of February. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 05:08:35 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id FAA16271 for ; Mon, 23 Sep 1996 05:08:34 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA23835 for png-list-outgoing; Mon, 23 Sep 1996 05:09:11 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id FAA23830 for ; Mon, 23 Sep 1996 05:09:07 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id EAA14208; Mon, 23 Sep 1996 04:06:49 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609231006.EAA14208@enel.ucalgary.ca> Subject: Re: Proposed chunks, version 19960914 To: png-list@dworkin.wustl.edu Date: Mon, 23 Sep 1996 04:06:49 -0600 (MDT) In-Reply-To: <9609132014.aa19473@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 13, 96 08:14:05 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > 4.3. spAL Suggested Palette > The "name" (e.g. "rgba512 8-8-4-2 color cube", "rgb256 winter > scenery", "rgb242 6-6-6 color cube plus 26 gray levels", "Windows > white background", "Browser Safe Palette", "Sepia") identifies the Can you please replace this with the newer names we worked out (maybe for the MNG spec?). As an aside, as I wade through 2 weeks of back email, I vote YES for the new voting procedure. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 08:02:57 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id IAA17693 for ; Mon, 23 Sep 1996 08:02:57 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA25268 for png-list-outgoing; Mon, 23 Sep 1996 08:04:49 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA25263 for ; Mon, 23 Sep 1996 08:04:46 -0500 Date: Mon, 23 Sep 96 9:00:55 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Proposed chunks, version 19960914 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609230900.aa20254@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }From: Andreas Dilger }Subject: Re: Proposed chunks, version 19960914 }Date: Mon, 23 Sep 1996 04:06:49 -0600 (MDT) }Glenn writes: }> 4.3. spAL Suggested Palette }> The "name" (e.g. "rgba512 8-8-4-2 color cube", "rgb256 winter }> scenery", "rgb242 6-6-6 color cube plus 26 gray levels", "Windows }> white background", "Browser Safe Palette", "Sepia") identifies the } }Can you please replace this with the newer names we worked out (maybe for }the MNG spec?). Is this OK? The "name" (e.g. "256 color including Macintosh default", "256 color including Windows-3.1 default", "Browser Safe Palette") identifies the ... } }As an aside, as I wade through 2 weeks of back email, I vote YES for the }new voting procedure. Your vote doesn't meet the proposed prescribed format.... for which version of the proposal are you voting YES? ;-) } }Cheers, Andreas. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 09:16:09 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id JAA18749 for ; Mon, 23 Sep 1996 09:16:06 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA26145 for png-list-outgoing; Mon, 23 Sep 1996 09:17:51 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA26140 for ; Mon, 23 Sep 1996 09:17:44 -0500 Date: Mon, 23 Sep 96 10:14:15 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: A proposal for new-chunk process Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609231014.aa20614@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Sun, 22 Sep 1996 22:24:57 -0700 }From: John Bowler }Subject: Re: A proposal for new-chunk process }No progress has been made on this since 9 September, thus it is in danger of }suffering the same fate as the chunks which it is supposed to rescue. } [...] }--------------------------------------- }PNG chunk review and approval process }===================================== } }Purpose }======= }To formally approve or reject a chunk for inclusion in the PNG extensions or }core chunks documentation. To formally approve or reject a chunk for registration as described in the PNG 1.0 specification. [...] }Prerequisites }============= }1) A specification of the chunk must exist in electronic form in a location }on the current png-group discussion list FTP server (at present this is the }tree based at ftp://swrinde.nde.swri.edu/pub/png-group/). and in a final publishable format, such as that of the PNG specification and PNG extensions document. }2) The specification may either be a whole single file, or group of files }(which must be named by single ftp accessible directory name and implies all }files in that directory and all directories beneath it) or an identified }part of a single file. Also, the specification must state the proposed disposition of the registered chunk: o PNG core specification, o PNG extensions document, o inclusion in an existing separate document, o or in a new separate document. If the chunk is proposed for inclusion in some subsidiary document rather than the PNG core specification or in the PNG extensions document, then the proposal must include proposed modifications to the PNG extensions document that will refer to the new specification. The names of all formally registered chunks will either appear in the PNG specification or in the PNG extensions document. }3) Throughout the approval (voting) process the specification must remain }substantially unchanged. A substantial change is one which is *not*:- } i) A simple formatting or spelling change. } ii) A printing or authorship date change. } iii) An annotational change. "Annotational" refers to a part of the }text which is not itself part of the specification (and is declared to be }such) but merely annotates it. iv) conversion of the chunk to registered form by making the second character of its name uppercase and by removing a version identifier. The proposal must state exactly how the chunk is to be converted to its registered form. } }[This may all seem imprecise; in particular the phrase "an identified part }of a single document" is imprecise. It would be up to the initial voter to identify the part precisely (e.g. "paragraphs 9.1 and 12.3") }The rationale for this is that if the }specification is imprecisely delimited then the voters will cast "NO" votes }and it will be defeated. Also the voting process described below prevents }abuse of the permission to make non-substantial changes.] } }Votes }===== }Votes are cast by sending a message to the png-list indicating a YES or NO }vote. Voters should take care to make their intentions clear (i.e. "YES" or }"NO" and precisely what chunk specification is being voted on). To ensure }that a vote is correctly registered the following form, as the first line of }an email message, must always be accepted:- } }{YES|NO} \["specification change"\] } }For example:- } }YES }ftp://swrinde.nde.swri.edu/pub/png-group/documents/png-new-chunks-19960914.h }tml cNEW I don't like long lines. How about separating the directory and filename? NO, specification change cNEW ftp://swrinde.nde.swri.edu/pub/png-group/documents/ png-new-chunks-19960914.html Also I think we should accept any variation on this format which contains all of this information. There should be no other topics of discussion in the same message. An "Oh, by the way, I vote NO on cNEW" buried in the text of a long message might get overlooked. But I think it would be fine to include additional explanation *after* the vote, such as the nature of the "specification change". We could require that the subject of the message make it clear that the message contains a vote ("cNEW YES") Also, only put one vote in a message. If a group of chunks is being voted on as a whole, then only one message is necessary, but if six different chunks are being voted upon during the same period, six different messages are required. For example, I would imagine that xSCL and ySCL could be voted on as a group, but that dRNG and lOGE would be voted on separately. The decision whether to group or separate chunks for voting is up to the person casting the initial YES vote. } }[NOTE: this differs from the current convention, whereby the chunks are }called cnEW until approved then become cNEW. I don't want to burden this }document with an attempt to specify that process, and I don't think it is }necessary - the initiation of the voting process implies that at least one }person thinks the chunk specification is ready.] I agree. The document will describe cnEW and it might have a "version id" that would be deleted upon registration. So the vote would indeed be on cNEW rather than cnEW. } }If the words "specification change" appear following a "NO" vote the vote }indicates that the author disagrees that a change to a specification in the }voting period is non-substantial. To be valid there must have been a change }to the file containing the specification (i.e. its content is no longer }identical to the original). The words are ignored if they occur on a "YES" }vote. } }Votes may be tallied by anyone and interpreted by anyone. } }[The purpose of this proposal is to fix the problem with approving chunks, }not to build a system to document them, I think that part works OK at }present, if it doesn't work we can fix that problem when we get to it.] } }Initiation }========== }A vote is initiated by the first cast of a YES vote in favor of an }identified specification. The voter should use the above form to avoid }confusion. } }[If they don't use that form, well, I don't think it is necessary to explore }the possibilities here.] } }Termination }=========== }The voting period ceases one calendar month after the initiation at the same }time as the initiation. Should this day not exist the first day of the }succeeding month is used. The time of the first vote is determined by the }"Received:" line generated by the png-list email server, e.g. in:- } }Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by }dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA10764 for }; Sun, 22 Sep 1996 10:11:58 -0500 } }The date and time are "Sun, 22 Sep 1996 10:11:58 -0500" } }[I.e. if it starts on 31 Jan at 12:05 (UCT) it ends at 1 Mar 12:05 UCT. }Personally I find this easier to understand, but I have no real problem with }30x86400 seconds.] The voting period also ceases immediately when a "NO, specification change" vote is received by the png-list server. } }Decision }======== }A chunk specification is approved if the following conditions are met:- } }1) 10 YES votes are received. }[I think this is too high a hurdle, 5 sounds better]. }2) The number of YES votes is at least 5 more than the number of NO votes. }[With the current numbers this is a redundant definition, but it seems }better to have it now than to have to add it later.] }3) At least twice the number of YES votes than NO votes is received. }[Willem's suggestion.] }4) No "NO" votes have been received with the "specification change" }qualification. } }If these conditions are *not* met the chunk specification is rejected. A }further vote requires a substantial change to the definition as a }prerequisite. If it was rejected on account of condition 4 a further vote can occur immediately, by a person voting YES on the changed specification, using a new filename that includes the changes. } }[I don't think I need to define "substantial" here - if the change isn't }substantial all the NO voters will still vote NO and so, probably, will some }of the YES voters.] We also ought to allow a revote after a year [six months?] without substantial change if the environment has changed. For example, if a is defeated as being premature, then a year from now it might have been implemented by a number of applications and not be premature any more, but would not need any change to the format. } }Franchise }========= }Anyone is eligible to vote who has:- } }1) Submitted a message to the png-list in the last six calendar months. }[I just added this, it hasn't been mentioned before.] Any inactive member could write and say "Hi, I'm back, and I'm about to vote." }2) Submitted their first (or any subsequent) message to the png-list at }least six calendar months before the *termination* of the voting period. If }the corresponding (numerical) day does not exist in this month it is the }*last* day of the *same* month. I.e. the day six months before 30 August is }defined to be the last day of February. } OK ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 10:17:10 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id KAA19533 for ; Mon, 23 Sep 1996 10:17:08 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA26843 for png-list-outgoing; Mon, 23 Sep 1996 10:17:31 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA26834 for ; Mon, 23 Sep 1996 10:17:23 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id LAA04397 for ; Mon, 23 Sep 1996 11:15:03 -0400 (EDT) To: PNG List Subject: Re: A proposal for new-chunk process In-reply-to: Your message of Sun, 22 Sep 1996 22:24:57 -0700 <199609230524.WAA00155@mega.megamed.com> Date: Mon, 23 Sep 1996 11:15:03 -0400 Message-ID: <4395.843491703@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Some comments on John's formalization of the voting proposal --- > 1) A specification of the chunk must exist It's not clear whether this spec should describe an unregistered form of a chunk (named "cnEW", possibly with a version field) or a registered form ("cNEW", no version field). Perhaps it doesn't matter much, though. Everyone familiar with the PNG spec should be able to make the necessary substitutions without thought. In general I don't feel that the chunk spec that's voted on needs to be word-for-word what will be in the revised PNG spec or PNG extensions document. The spec editors (that's me or Glenn, or whoever takes our place) will feel free to correct poor English, etc. The editors are also quite capable of inserting cross-references as necessary. Glenn suggested > If the chunk is proposed for inclusion in some subsidiary document > rather than the PNG core specification or in the PNG extensions > document, then the proposal must include proposed modifications to the > PNG extensions document that will refer to the new specification. but I think the editors are competent to do this. Requiring proposals to be practically "diff" patches to the spec will not accomplish much. > To ensure > that a vote is correctly registered the following form, as the first line of > an email message, must always be accepted:- > {YES|NO} \["specification change"\] This likewise strikes me as overly pedantic. I do like the separate-message-per-vote idea, though; burying "btw, I vote YES" in some other message is not a good move. How about requiring vote messages to carry the vote in their subject: Subject: YES for cNEW, cTOO A precise description of what is being voted for (document ID) probably is not necessary, but can be included in the message body if the voter feels it is important. The message body could also include reasons for the vote; in particular we should encourage NO voters to explain why not. > Votes may be tallied by anyone and interpreted by anyone. I don't like this because it leads to the possibility of *no one* bothering to do the tally ... except perhaps the chunk proponent, who is, um, not unbiased. Someone needs to volunteer to serve as the official votetaker. Also, don't forget to mention that a voter can change his/her vote before the close of the voting period. > A vote is initiated by the first cast of a YES vote in favor of an > identified specification. The trouble with that is that the most trigger-happy of us will set the clock running, possibly before everyone else has finished discussing the proposal. At a minimum I think we need a discussion period in which any possible problems can emerge. Instead of just a one-month period, how about (a) Discussion period: the chunk spec must be available and must not change for a period of at least two weeks before a vote can be called for. The chunk proponent starts this clock running by notifying the list that the proposed spec is available, and/or just posting it to the list (I think that's a good idea for short specs, to save people the trouble of ftping it). If discussion exposes flaws, the spec can be revised, thus starting a new two-week period. (b) Once the waiting period has elapsed, the chunk proponent can call for a vote. (Note that if it was pretty clear from the discussion that the chunk would fail, the vote can be skipped.) (c) Voting period: runs for two weeks from the date of the message calling for votes. Discussion may continue, and votes can be changed. If the proponent decides to change the proposed spec, the vote is cancelled and we go back to the discussion stage. This requires no more time overall than John's one-month proposal, but it adds some more structure to the process, and should reduce problems with hasty votes. > A chunk specification is approved if the following conditions are met:- > 1) 10 YES votes are received. > [I think this is too high a hurdle, 5 sounds better]. > 2) The number of YES votes is at least 5 more than the number of NO votes. > [With the current numbers this is a redundant definition, but it seems > better to have it now than to have to add it later.] > 3) At least twice the number of YES votes than NO votes is received. > [Willem's suggestion.] Condition 2 is redundant, as conditions 1 and 3 together have the same effect. > 4) No "NO" votes have been received with the "specification change" > qualification. This rule allows anyone to veto a chunk just by claiming that the spec has changed. I'd prefer a hard and fast rule: the document does not change during the waiting period and vote period. That's not subject to interpretation... There's a related question, though: what if the proposed spec wording is ambiguous? If the correct interpretation is agreed on during the discussion period, should the proponent be required to fix the text and thus restart the waiting-period clock? I can see people not wanting to do that if they're in a hurry. (But, hopefully, some people will vote NO if they find the text ambiguous.) > Anyone is eligible to vote who has:- > 1) Submitted a message to the png-list in the last six calendar months. > [I just added this, it hasn't been mentioned before.] Unnecessary, since as Glenn pointed out, a lapsed member could just send in a noise message to become eligible again. Also, this would require some of our quieter members to say something at least twice a year just to stay eligible to vote; that again seems like unnecessary traffic. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 10:32:39 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id KAA19780 for ; Mon, 23 Sep 1996 10:32:38 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA27032 for png-list-outgoing; Mon, 23 Sep 1996 10:34:46 -0500 Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA27025 for ; Mon, 23 Sep 1996 10:34:24 -0500 Received: from fb0430.mathematik.th-darmstadt.de (daemon@fb0430.mathematik.th-darmstadt.de [130.83.2.30]) by rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id QAA23259 for ; Mon, 23 Sep 1996 16:31:50 +0100 Received: from fb0432.mathematik.th-darmstadt.de by fb0430.mathematik.th-darmstadt.de (1.37.109.16/Server-1.5/HRZ-THD) id AA056482711; Mon, 23 Sep 1996 17:31:51 +0200 Received: by fb0432.mathematik.th-darmstadt.de (1.37.109.16/Client-1.5/HRZ-THD) id AA195782707; Mon, 23 Sep 1996 17:31:47 +0200 Date: Mon, 23 Sep 1996 17:31:47 +0200 Message-Id: <199609231531.AA195782707@fb0432.mathematik.th-darmstadt.de> From: Alexander Lehmann To: png-list@dworkin.wustl.edu Subject: (fwd) Did Unisys change its LZW policy? Newsgroups: comp.graphics.misc Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Hello all, I found this article in the news, it seems that now Unisys doesn't like anyone publishing LZW code regardless whether it is freeware or not. While this may be an additional incentive to switch to PNG, I'm not really sure what the effects of this for programs like mine and any other source code available LZW program are. Apparently Unisys has removed all previous press releases about their GIF licensing concept and replaced them with a `FAQ' which just states that it works differently now and how to obtain the information (which is probably bound to certain conditions as the poster below writes). -------- forwarded-message --------------> From: tcorat@theother.com (Tom Corat) Newsgroups: comp.graphics.misc Subject: Did Unisys change its LZW policy? Date: 21 Sep 1996 05:30:19 GMT Organization: Pixelogic Inc Message-ID: <51vuhb$b4v@nic.ott.hookup.net> I contacted Unisys about a license for our freeware Internet suite in case we try to introduce it as a commercial product and I was told bluntly that Unisys would never grant my company a license. He said that this is partly because our clients would be ISPs who are likely to distribute more copies than licensed to them (this, despite the fact that it would be in my company's best interest to try to stop them). The other reason is that according to the Unisys representative our freeware product was a clear infringement upon their patent right and unless we ceased and desisted to give away free software they wouldn't even send us a copy of the licensing agreement. Does wnyone know if there was change of policy in that regard? A couple of mnths ago their Web site said that freeware authors don't need a license and if they applied for one they would be given one but they didn't need to pay any fees. This is an actual quote from that page: "No license or license fees are required for non-commercial, not-for-profit GIF-based applications or for non-commercial, not-for-profit GIF-freeware, so long as the LZW capability provided is only for GIF." Now that statement is no longer there. Unisys rep told me that that freeware policy is not applicable anymore. My company is too small to fight Unisys and whoever else is behind this "screw Web authors" policy. I don't want to cease and desist after spending two years of our lives to create this program. Does anyone know if the alternative algorithms are compatible enough and where we would find them? Also, does anyone know why Unisys changed their policy after trying very hard to appease everyone last year? Tom Corat tcorat@theother.com <------- end-of-forwarded-message -------- http://www.unisys.com/LeadStory/lzwfaq.html License information on GIF and other LZW-based technologies More and more people are becoming aware that the reading and/or writing of GIF images requires a license to use Unisys patented Lempel Ziv Welch (LZW) data compression and decompression technology, including United States Patent No. 4,558,302 and foreign counterpart patents. Since January of 1995, Unisys has entered into a large number of license agreements for use of GIF and other LZW-based technology. As a result of both this extensive licensing and changes in the use and marketing of GIF and other LZW-based products, Unisys has had to adjust its licensing policies to reflect these changes and the needs of existing and future licensees. Currently applicable information as to Unisys licensing policies for products using LZW (GIF, TIFF-LZW, PostScript, Portable Document Format (PDF), V.42bis, etc.) can be obtained by contacting the following: Welch Patent Licensing Department; Unisys; Mail Stop C1SW19; P.O. Box 500, Blue Bell, PA 19424. Via the Internet, send E-mail to LZW_INFO@UNISYS.COM, or use a form available on the Contact Page of the Unisys Web Server to request follow-up information. --------------------------------------------------------------------------- bye, Alexander -- Alexander Lehmann, | "On the Internet, alex@hal.rhein-main.de (MIME, NeXT) | nobody knows lehmann@mathematik.th-darmstadt.de (MIME) | you're a dog." ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 11:27:27 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id LAA20667 for ; Mon, 23 Sep 1996 11:27:25 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA28500 for png-list-outgoing; Mon, 23 Sep 1996 11:29:02 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id LAA28495 for ; Mon, 23 Sep 1996 11:28:58 -0500 Date: Mon, 23 Sep 96 12:18:58 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: A proposal for new-chunk process Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609231218.aa25281@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List } }I don't like this because it leads to the possibility of *no one* }bothering to do the tally ... except perhaps the chunk proponent, }who is, um, not unbiased. Someone needs to volunteer to serve as the }official votetaker. Sometwo or somethree might be safer. If it's just one, it probably ought not to be the same people (tom_lane or glennrp for now) who do the formatting. BTW I am spending my lunchtime putting the registration proposal into a properly formatted document... ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 13:13:34 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA21758 for ; Mon, 23 Sep 1996 13:13:32 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA00700 for png-list-outgoing; Mon, 23 Sep 1996 13:15:24 -0500 Received: from mail.Clark.Net (mail.clark.net [168.143.0.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA00690 for ; Mon, 23 Sep 1996 13:15:13 -0500 Received: from glenc (glenc.clark.net [168.143.4.56]) by mail.Clark.Net (8.7.3/8.6.5) with SMTP id OAA17367 for ; Mon, 23 Sep 1996 14:11:08 -0400 (EDT) Message-Id: <199609231811.OAA17367@mail.Clark.Net> Comments: Authenticated sender is From: "Glen Chapman" To: png-list@dworkin.wustl.edu Date: Mon, 23 Sep 1996 14:15:06 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: new-chunk process evaluation. Priority: normal X-mailer: Pegasus Mail for Win32 (v2.42) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Hi all, I'm one of the lurkers here on the lists. I've been following the registration threads and feel that it's progressing. The one problem thats been lurking in the back of my mind is the issue of peer review of new chunks by experts (and real users) in the field that a proposed chunk is designed for. It appears that in lot's of areas we have quite a bit of expertise, but in others we "may" be a bit weak such as multi-media, SciVis, Desktop publishing etc. One of the other things I've noticed is that to much of the outside world, PNG is just a replacement for GIF. That the structure of PNG lends itself to extension and that extensions exist in certain areas needs more PR. I guess what I'm wondering is if we need something like an RFC thats published in news groups that may possibly need the chunk that is being specified. If nothing else this may expose more people in other disciplines to PNG's capabilities and get them to join and participate on the PNG lists. Along the same line, I think that any vote should take place on these lists but that we need ways to get more individuals with specific area knowledge to join the list. Glen Chapman Reed Technology & Information Systems ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 13:45:41 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA22266 for ; Mon, 23 Sep 1996 13:45:38 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA01372 for png-list-outgoing; Mon, 23 Sep 1996 13:47:40 -0500 Received: from tide21.microsoft.com (tide21.microsoft.com [131.107.3.31]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id NAA01367 for ; Mon, 23 Sep 1996 13:47:36 -0500 Received: by tide21.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBA945.0AD13160@tide21.microsoft.com>; Mon, 23 Sep 1996 11:47:48 -0700 Message-ID: From: John Bowler To: "'PNG List'" Subject: RE: A proposal for new-chunk process Date: Mon, 23 Sep 1996 11:45:34 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 57 TEXT Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List As Tom points out, I left an important item out of the "Votes" section - the ability to change your vote by sending another vote. So a paragraph should be added to the end of the "Votes" section:- "Multiple votes may be sent by the same person, in which case only the last sent vote is tallied (as recorded by the time stamp in the email header)." Also the "approved" format should probably include the email name of the voter if the person in question uses multiple email addresses to send to png-list. This will avoid confusion and accidental double counting. Following Glenn's suggested format, at the top of the message:- jbowler@acm.org NO, specification change cNEW ftp://swrinde.nde.swri.edu/pub/png-group/documents/ png-new-chunks-19960914.html As Tom says this format is somewhat pedantic - my intention was not to mandate an exact format but to provide a fixed format in case of disputes, so if ever an argument occurs about whether a vote is valid the original voter can recast the vote in exactly the specified format. This is why I used the wording "... the following form ... must always be accepted". For example omitting the directory path name should be OK so long as the file name is unique and in most cases the chunk name alone should be sufficient. Early termination of the vote is important if it turns out that there is a fundamental flaw in the specification - again I omitted something from the proposal. There should be a paragraph in the "termination" section which says:- "The voting period also ceases immediately there are no YES votes remaining (because they have all been countermanded by NO votes)." I don't think it is desirable to terminate the voting immediately a "NO; specification change" vote is cast - this can happen in error (I might erroneously think that a change to the wording is a change to the specification and cast such a vote). I agree with Tom - if the specification cannot change at all during the voting period then item (3) of the "prerequisites" section can be simplified to:- "3) The specification must not change throughout the voting process." Overall this seems better (easier to understand, less likely to cause disputes). The editors can correct spelling and grammar. The addition to the termination procedure (when there are no remaining YES votes) allows voting on a broken specification to cease immediately (without the "specification change" option). Nothing in what I wrote disallows concurrent voting on two different specifications for the same chunk - perhaps this should be disallowed but it does mean that it is not necessary to formally terminate a vote when a specification needs substantial revision. John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 13:45:50 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA22274 for ; Mon, 23 Sep 1996 13:45:44 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA01387 for png-list-outgoing; Mon, 23 Sep 1996 13:48:00 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA01378 for ; Mon, 23 Sep 1996 13:47:51 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id LAA13911 for ; Mon, 23 Sep 1996 11:38:39 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id LAA13919 for png-list@dworkin.wustl.edu; Mon, 23 Sep 1996 11:38:39 -0700 (PDT) Message-Id: <199609231838.LAA13919@web1.calweb.com> Subject: Re: A proposal for new-chunk process To: png-list@dworkin.wustl.edu Date: Mon, 23 Sep 1996 11:38:38 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <199609230524.WAA00155@mega.megamed.com> from "John Bowler" at Sep 22, 96 10:24:57 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > Votes are cast by sending a message to the png-list indicating a > YES or NO vote. Votes need to be blind, so sending to the list is out. They should be sent to a vote-bot address that tallies them and only reports final results--with names--AFTER the vote is complete, just like the Usenet process. I'll be happy to set up a vote-bot at Piclab, or help set one up wherever else it might be needed. -- Lee Daniel Crocker ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 13:59:27 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA22408 for ; Mon, 23 Sep 1996 13:59:25 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA01656 for png-list-outgoing; Mon, 23 Sep 1996 14:01:39 -0500 Received: from u11.CS.Berkeley.EDU (u11.CS.Berkeley.EDU [128.32.38.135]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA01640 for ; Mon, 23 Sep 1996 14:01:24 -0500 Received: (from amc@localhost) by u11.CS.Berkeley.EDU (8.6.11/8.6.9) id LAA27147 for png-list@dworkin.wustl.edu; Mon, 23 Sep 1996 11:59:00 -0700 Date: Mon, 23 Sep 1996 11:59:00 -0700 Message-Id: <199609231859.LAA27147@u11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: A proposal for new-chunk process X-Advice: should read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List "Lee Daniel Crocker" says: > Votes need to be blind, so sending to the list is out. Why? We've never needed anonymity before. I wouldn't object strongly to blind voting, but I'd prefer everything to be out in the open. Does anyone else want blind voting? AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 14:20:46 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id OAA22980 for ; Mon, 23 Sep 1996 14:20:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA02158 for png-list-outgoing; Mon, 23 Sep 1996 14:22:00 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA02152 for ; Mon, 23 Sep 1996 14:21:54 -0500 Date: Mon, 23 Sep 96 15:19:03 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: A proposal for new-chunk process Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609231519.aa02770@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List } }Does anyone else want blind voting? Not I. We're just trying to formalize consensus; why go overboard? ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 14:25:04 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id OAA23022 for ; Mon, 23 Sep 1996 14:25:01 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA02406 for png-list-outgoing; Mon, 23 Sep 1996 14:27:11 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA02397 for ; Mon, 23 Sep 1996 14:26:55 -0500 Date: Mon, 23 Sep 96 15:20:55 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: A proposal for new-chunk process Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609231520.aa02835@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List PNG-GROUP-DRAFT PNG Development Group PNG-Registration png-list@dworkin.wustl.edu Expires: 23 Mar 1997 23 Sep 1996 PNG Chunk Registration Process, draft 19960923 File png-registration-19960923.txt Status of this Memo This document is an informal draft of the PNG development group. Comments on this document can be sent to the PNG specification maintainers at png-info@uunet.uu.net or at png- list@dworkin.wustl.edu. Distribution of this memo is unlimited. At present, the latest version of this document is available on the World Wide Web from ftp://swrinde.nde.swri.edu/pub/png- group/documents/. Notices Copyright (c) 1996 Thomas Boutell Permission is granted to copy and distribute this document for any purpose and without charge, provided that this notice is preserved, and that any substantive changes or deletions from the original are clearly marked. Abstract This document describes the approval process for registering public PNG chunks. Persons who have contributed to the PNG mailing list for at least six months are eligible to vote. Approval of a chunk registration requires at least 10 YES votes with at least twice as many YES votes as NO votes. The voting period follows a two-week discussion period, and is two weeks from the time the initial vote is received by the png-list server. Vote are cast by electronic mail to the png-list mailing list. PNG Development Group [Page 1] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960923 23 Sep 1996 Table of Contents 1. Purpose ........................................................ 2 2. Justification and additional aims .............................. 2 3. Prerequisites .................................................. 2 4. Votes .......................................................... 3 4.1. Casting votes ............................................. 3 4.2. Changing votes ............................................ 4 4.3. Tallying votes ............................................ 4 5. Initiation ..................................................... 4 6. Termination .................................................... 5 7. Decision ....................................................... 5 8. Franchise ...................................................... 5 9. Adoption of this procedure ..................................... 6 10. Editor ........................................................ 6 1. Purpose To formally approve or reject a chunk for registration as a public chunk as described in the PNG 1.0 specification. 2. Justification and additional aims Discussions on the PNG discussion list (png-list@dworkin.wustl.edu) at present fail to reach a clear consensus on the desirability of a particular chunk definition. The formal approval process is intended to aid such decisions by:- * Identifying consensus when it exists. * Giving a limited time period within which objections can be raised. * Encouraging discussion and preventing ambiguities when one party to the discussion simply falls silent. To meet these ends the formal process is based on a voting process exercised over a limited period of time. 3. Prerequisites * A proposed specification of the chunk must exist in electronic form in a location on the current png-group discussion list FTP server (at present this is the tree based at ftp://swrinde.nde.swri.edu/pub/png-group/). The proposal must be in a final publishable format, such as that of the PNG specification and PNG extensions document. * The specification may either be a whole single file, or group of files (which must be named by single ftp accessible directory name and implies all files in that directory and all directories beneath it) or an identified part of a single file. * The specification should describe the proposed chunk in its unregistered form, to avoid the possibility of premature distribution of documents describing chunks in their public PNG Development Group [Page 2] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960923 23 Sep 1996 form. The editors will make the necessary changes to the final document, by changing the second letter of the chunk name to uppercase and by removing any private version identification. If any other changes are needed, instructions to the editor should be provided in the proposal. * The specification or the call for votes must state the proposed disposition of the registered chunk: * PNG core specification * PNG extensions document * Inclusion in an existing separate document * A new separate document Note that the names of all formally registered chunks will either appear in the PNG specification or in the PNG extensions document. The editors will make the appropriate changes when a chunk is registered. * Throughout the two-week voting period the specification must remain absolutely unchanged. The two-week discussion period must be restarted upon making any change to the proposed specification, except for * Simple formatting, gramatical, or spelling changes. * A printing date or authorship change. Upon the objection of any voter, received by the png-list server prior to the call for votes, the two-week discussion period must be restarted in the event of any such change. 4. Votes 4.1. Casting votes Votes are cast by sending a message to the png-list indicating a YES or NO vote. Voters should take care to make their intentions clear (i.e. "YES" or "NO" and precisely what chunk specification is being voted on). To ensure that a vote is correctly registered the following form, as the first lines of an email message, must always be accepted: Name {YES|NO} For example: Glenn Randers-Pehrson YES cNEW ftp://swrinde.nde.swri.edu/pub/png-group/documents/ png-new-chunks-19960914.html The vote-takers can accept votes that do not adhere exactly to this format as long as the intent is clear. PNG Development Group [Page 3] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960923 23 Sep 1996 There should be no other topics of discussion in the same message. An "Oh, by the way, I vote NO on cNEW" buried in the text of a long message might get overlooked. It is acceptable and useful to include additional explanations in the message, but the vote itself should be placed at the beginning. It is recommended, but not required, that the subject of the message make it clear that the message contains a vote ("cNEW YES") Only one vote should be included in a message. If a group of chunks is being voted on as a whole, then only one message is necessary, but if different chunks are being separately voted upon during the same period, separate messages are required. The decision whether to group or separate chunks for voting is up to the person casting the initial YES vote. 4.2. Changing votes A person may submit a changed vote any time prior to the expiration of the voting period. Only the latest vote, determined by the time it was received by the png-list server, will be counted. 4.3. Tallying votes Votes will be tallied and interpreted by a group of [3?] vote- takers, to be selected by consensus for life-time appointment from among volunteers. [Who counts the votes if we want to impech the vote-takers?] 5. Initiation Voting can be initiated after a two-week discussion period. The proposed chunk specification must be available and must not change for a period of at least two weeks before a vote can be called for. The chunk proponent starts this clock running by notifying the list that the proposed spec is available. Short proposals should also be posted it to the list, to save people the trouble of downloading them. If discussion exposes flaws, the spec can be revised, thus starting a new two-week discussion period. After the two-week discussion period, the vote is initiated by any person submitting the first YES vote on an identified specification, using the format suggested above, clearly identifying the specification to be voted upon. PNG Development Group [Page 4] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960923 23 Sep 1996 6. Termination The voting period ceases two weeks after the initiation, at the same time of day as the initiation. The time of the call for votes is determined by the "Received:" line generated by the png-list email server, e.g. in Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA10764 for ; Sun, 22 Sep 1996 10:11:58 -0500 the date and time are "Sun, 22 Sep 1996 10:11:58 -0500", and the voting period ends on Sunday, 06 Oct 1996 10:11:50 -0500. The voting period also ceases immediately if all YES votes are countermanded by NO votes from the same voters originally casting the YES votes. The voting period ceases immediately upon approval of another specification for same chunk name. 7. Decision A chunk specification is approved if both of the following conditions are met: * Ten YES votes are received. * At least twice the number of YES votes as NO votes are received. If these conditions are met, then the chunk immediately becomes registered and people can start using it in its registered form. The PNG editors will include the chunk specification, or a reference to it, in the next release of the PNG documentation. If these conditions are not met the chunk specification is rejected. A further vote requires either a six-month waiting period, to allow for implementation and testing, or a substantial change to the definition as a prerequisite. 8. Franchise Anyone is eligible to vote who has: * Submitted their first (or any subsequent) message to the png- list at least six calendar months before the termination of the voting period. If the corresponding (numerical) day does not exist in this month it is the last day of the same month. I.e. the day six months before 30 August is defined to be the last day of February. PNG Development Group [Page 5] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960923 23 Sep 1996 9. Adoption of this procedure Adoption of this procedure for registering PNG chunks will be voted upon using the same procedure as used for approving a chunk registration. It will take effect immediately upon the successful completion of the required discussion and voting periods. Discussion periods for proposed chunks, but not voting periods, can run concurrently with the voting period for adoption of this procedure. The procedure described in this document can also be used for registering chunks in related formats such as MNG, provided it is separately adopted for use for the other format. The votes will be called for and cast using the appropriate mailing list (e.g. mpng- list) instead of png-list. 10. Editor * Glenn Randers-Pehrson glennrp@arl.mil or randeg@alumni.rpi.edu End of PNG Chunk Registration Process document. Expires 23 Mar 1997. PNG Development Group [Page 6] ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 14:58:23 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id OAA23542 for ; Mon, 23 Sep 1996 14:58:23 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA02883 for png-list-outgoing; Mon, 23 Sep 1996 14:59:40 -0500 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA02877 for ; Mon, 23 Sep 1996 14:59:35 -0500 Received: by mail3.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBA94E.64176A60@mail3.microsoft.com>; Mon, 23 Sep 1996 12:54:43 -0700 Message-ID: From: John Bowler To: "'PNG List'" Subject: RE: A proposal for new-chunk process Date: Mon, 23 Sep 1996 12:52:23 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 15 TEXT Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >From: Lee Daniel Crocker[SMTP:lcrocker@calweb.com] > >> Votes are cast by sending a message to the png-list indicating a >> YES or NO vote. > >Votes need to be blind, so sending to the list is out. Votes need to be cast on the png-list so as to achieve the aim - to crystallize the discussion. The theory is that this process normally happens when there is a consensus. A NO vote indicates that something still remains to be discussed so it is particularly important that the reasons for the vote are understood, and discussed. >John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 15:05:34 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id PAA23581 for ; Mon, 23 Sep 1996 15:05:33 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA02999 for png-list-outgoing; Mon, 23 Sep 1996 15:07:48 -0500 Received: from u11.CS.Berkeley.EDU (u11.CS.Berkeley.EDU [128.32.38.135]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA02994 for ; Mon, 23 Sep 1996 15:07:45 -0500 Received: (from amc@localhost) by u11.CS.Berkeley.EDU (8.6.11/8.6.9) id NAA27411; Mon, 23 Sep 1996 13:05:23 -0700 Date: Mon, 23 Sep 1996 13:05:23 -0700 Message-Id: <199609232005.NAA27411@u11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: A proposal for new-chunk process X-Advice: should read soon From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson ARL-WMRD-TED-TIB says: > It is recommended, but not required, that the subject of the > message make it clear that the message contains a vote ("cNEW > YES") I'd like a true requirement on the Subject field of a message containing a vote. It would make it much easier to re-tally a vote from the archives. Possible requirements: * A message containing a vote must have a Subject field containing the string "YES" or the string "NO". * A message containing a vote must have a Subject field containing the string "VOTE". > 4.3. Tallying votes > > Votes will be tallied and interpreted by a group of [3?] vote- > takers, to be selected by consensus for life-time appointment > from among volunteers. [Who counts the votes if we want to > impech the vote-takers?] Is this necessary? Anyone can tally the votes, and present a summary to the list after the voting period has ended. The summary refer to the spec in question, and would contain a table mapping voters to their votes. Anyone who was mis-counted can speak up. If the vote passed, then surely at least one person will step forward to construct the summary. The summary message(s) must contain a flag in the Subject field. Maybe the same flag used by the votes themselves, or maybe not (I don't care). AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 15:11:41 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id PAA23626 for ; Mon, 23 Sep 1996 15:11:38 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA03159 for png-list-outgoing; Mon, 23 Sep 1996 15:13:40 -0500 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id PAA03152 for ; Mon, 23 Sep 1996 15:13:34 -0500 Received: by mail2.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24) id <01BBA950.A619B100@mail2.microsoft.com>; Mon, 23 Sep 1996 13:10:53 -0700 Message-ID: From: John Bowler To: "'PNG List'" Subject: RE: A proposal for new-chunk process Date: Mon, 23 Sep 1996 13:11:29 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Encoding: 22 TEXT Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB[SMTP:glennrp@ARL.MIL] > 4.2. Changing votes > > A person may submit a changed vote any time prior to the > expiration of the voting period. Only the latest vote, determined > by the time it was received by the png-list server, will be > counted. I thought of this definition and rejected it, over use the "send" time, because I can conceive of a situation where I send a NO vote from work at Microsoft, then a YES vote from home and the two votes become transposed. It might be clear that this had happened - the tally might say "John Bowler: YES YES NO", but it would, apparently, still be a NO vote. > > the date and time are "Sun, 22 Sep 1996 10:11:58 -0500", and the > voting period ends on Sunday, 06 Oct 1996 10:11:50 -0500. ":50" in the second time should be ":58". (Now, *that* is pedantic :-) John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 15:18:19 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id PAA23704 for ; Mon, 23 Sep 1996 15:18:18 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA03334 for png-list-outgoing; Mon, 23 Sep 1996 15:20:28 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id PAA03327 for ; Mon, 23 Sep 1996 15:20:23 -0500 Date: Mon, 23 Sep 96 16:11:45 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: A proposal for new-chunk process Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609231611.aa04380@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List The abstract in the registration document wasn't consistent with the body. Also, I changed six months to 180 days to get rid of the business about short months. Here's a new abstract: This document describes the approval process for registering public PNG chunks. Persons who have contributed to the PNG mailing list at least 180 days prior to the end of the voting period are eligible to vote. A two-week voting period follows a two-week discussion period. Votes are cast by electronic mail to the png-list mailing list. Approval of a chunk registration requires at least 10 YES votes with at least twice as many YES votes as NO votes. Also, I know how to spell impeach and grammatical... I fixed those but apparently not in my master file because the errors crept back in... I posted the txt.gz and .html files (without the above corrections) on swrinde. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 15:53:04 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id PAA24227 for ; Mon, 23 Sep 1996 15:53:02 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA04328 for png-list-outgoing; Mon, 23 Sep 1996 15:54:58 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA04323 for ; Mon, 23 Sep 1996 15:54:52 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id NAA06869 for ; Mon, 23 Sep 1996 13:45:41 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id NAA14669 for png-list@dworkin.wustl.edu; Mon, 23 Sep 1996 13:45:40 -0700 (PDT) Message-Id: <199609232045.NAA14669@web1.calweb.com> Subject: Re: A proposal for new-chunk process To: png-list@dworkin.wustl.edu Date: Mon, 23 Sep 1996 13:45:40 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <199609231859.LAA27147@u11.CS.Berkeley.EDU> from "Adam M. Costello" at Sep 23, 96 11:59:00 am Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > > Votes need to be blind, so sending to the list is out. > > Why? We've never needed anonymity before. I wouldn't object strongly > to blind voting, but I'd prefer everything to be out in the open. I didn't say anonymous--all the votes are published with names after the voting period, but if votes are seen during that period, they influence future votes, just like hearing about East-coast exit polls on your way to the ballot box in California screws up the results. Some people might be encouraged to avoid voting if they perceive the results as forgone, as well, which prevents the tally from accurately representing the consensus. If I'm the only one wanting this (wouldn't be the first time), I can live with it either way, but there's a good reason this system was developed for Usenet, and it has worked well for years (more or less--I can't imagine a "white power" or "kashmir" chunk). ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 16:06:23 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA24619 for ; Mon, 23 Sep 1996 16:06:21 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA04813 for png-list-outgoing; Mon, 23 Sep 1996 16:08:23 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id QAA04806 for ; Mon, 23 Sep 1996 16:08:15 -0500 Date: Mon, 23 Sep 96 17:03:14 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: A proposal for new-chunk process Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609231703.aa06315@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }From: John Bowler }Subject: RE: A proposal for new-chunk process }Date: Mon, 23 Sep 1996 13:11:29 -0700 }>From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB[SMTP:glennrp@ARL.MIL] }> 4.2. Changing votes }> }> A person may submit a changed vote any time prior to the }> expiration of the voting period. Only the latest vote, determined }> by the time it was received by the png-list server, will be }> counted. } }I thought of this definition and rejected it, over use the "send" time, }because I can conceive of a situation where I send a NO vote from work }at Microsoft, then a YES vote from home and the two votes become }transposed. It might be clear that this had happened - the tally might }say "John Bowler: YES YES NO", but it would, apparently, still be a NO }vote. Good point. We'll use the "Date:" field from the message header. But it still has to arrive at the png-list remailer in order to count. }> }> the date and time are "Sun, 22 Sep 1996 10:11:58 -0500", and the }> voting period ends on Sunday, 06 Oct 1996 10:11:50 -0500. } }":50" in the second time should be ":58". (Now, *that* is pedantic :-) Dunno how that happened. Fixed in tomorrow's draft. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 17:32:39 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA27007 for ; Mon, 23 Sep 1996 17:32:38 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA06030 for png-list-outgoing; Mon, 23 Sep 1996 17:33:15 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA06024 for ; Mon, 23 Sep 1996 17:33:08 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id SAA08354 for ; Mon, 23 Sep 1996 18:30:47 -0400 (EDT) To: PNG List Subject: Re: A proposal for new-chunk process In-reply-to: Your message of Mon, 23 Sep 1996 13:45:40 -0700 (PDT) <199609232045.NAA14669@web1.calweb.com> Date: Mon, 23 Sep 1996 18:30:46 -0400 Message-ID: <8352.843517846@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I concur with Adam and John: blind voting is exactly the sort of process we *don't* want. It's a safeguard that's appropriate in real-world politics, but the last thing png-list needs is politics. If the atmosphere on png-list is ever such that I'm afraid to say what I think of some proposal, I'm outta here, and I suspect most of the other original members would be too. The idea of having voting is to provide a way to establish that we have consensus, not to provide a way to resolve irreconcilable differences. I'd really like to see people sending messages that read "I vote NO because x, y, and z are wrong with this chunk". If the votes are private but people send messages that say "x, y, and z are wrong with this chunk", it's not going to be too hard to guess which way they voted. And if they don't send any such message, but just vote YES or NO quietly, how can the proponent know what's wrong with a rejected chunk? Politics-as-usual is not the model I want for these discussions... regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 17:41:07 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA27042 for ; Mon, 23 Sep 1996 17:41:05 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA06098 for png-list-outgoing; Mon, 23 Sep 1996 17:41:57 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA06093 for ; Mon, 23 Sep 1996 17:41:53 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id SAA08379 for ; Mon, 23 Sep 1996 18:39:32 -0400 (EDT) To: PNG List Subject: Re: A proposal for new-chunk process In-reply-to: Your message of Mon, 23 Sep 1996 13:05:23 -0700 <199609232005.NAA27411@u11.CS.Berkeley.EDU> Date: Mon, 23 Sep 1996 18:39:32 -0400 Message-ID: <8377.843518372@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Adam says: > I'd like a true requirement on the Subject field of a message containing > a vote. It would make it much easier to re-tally a vote from the > archives. I agree; the votetaker should only need to scan the subject lines, not read whole messages. A possible problem with subject line votes, however: Person A posts: Subject: NO on cNEW I vote no because . Person B wants to respond to A's discussion, whereupon we get: Subject: Re: NO on cNEW A writes: > I vote no because . But . It's highly unlikely that B wants to be counted as a NO vote in this scenario... On the other hand we might have C writing Subject: Re: NO on cNEW Me too. which *is* a NO vote. How to resolve this without making the votetaker read all the messages? The first thought that comes to mind is: (1) Subject line must contain "VOTE on " (just to make the job of scanning the archives easier). (2) First line of message must contain actual YES or NO. If the message starts with a quote of someone else, it's not a vote. Better ideas? regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 18:22:33 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA27428 for ; Mon, 23 Sep 1996 18:22:30 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA06557 for png-list-outgoing; Mon, 23 Sep 1996 18:23:03 -0500 Received: from dawn11.CS.Berkeley.EDU (dawn11.CS.Berkeley.EDU [128.32.38.55]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA06549 for ; Mon, 23 Sep 1996 18:22:58 -0500 Received: (from amc@localhost) by dawn11.CS.Berkeley.EDU (8.6.11/8.6.9) id QAA25876 for png-list@dworkin.wustl.edu; Mon, 23 Sep 1996 16:20:36 -0700 Date: Mon, 23 Sep 1996 16:20:36 -0700 Message-Id: <199609232320.QAA25876@dawn11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: A proposal for new-chunk process X-Advice: perhaps read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Tom Lane says: > Subject: Re: NO on cNEW Yikes, I didn't think of that! > The first thought that comes to mind is: > > (1) Subject line must contain "VOTE on " (just to make the > job of scanning the archives easier). What if we're voting on a group of chunks? Should we just list all the chunks being voted on, preferably in the order they appear in the proposed spec? E.g: Subject: VOTE on xSCL ySCL > (2) First line of message must contain actual YES or NO. If the > message starts with a quote of someone else, it's not a vote. Sure. In practice, if someone flubs the format, someone (or several) will simply tell him/her to recast the vote properly, which will make moot any arguments about whether the first attempted vote counted. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 18:44:30 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA27499 for ; Mon, 23 Sep 1996 18:44:29 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA06817 for png-list-outgoing; Mon, 23 Sep 1996 18:45:13 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id SAA06812 for ; Mon, 23 Sep 1996 18:45:11 -0500 Date: Mon, 23 Sep 96 19:42:07 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: A proposal for new-chunk process Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609231942.aa08139@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Mon, 23 Sep 1996 16:20:36 -0700 }Subject: Re: A proposal for new-chunk process }From: "Adam M. Costello" }Tom Lane says: } }> Subject: Re: NO on cNEW } }Yikes, I didn't think of that! Subject line must NOT contain "Re:". } }> The first thought that comes to mind is: }> }> (1) Subject line must contain "VOTE on " (just to make the }> job of scanning the archives easier). } }What if we're voting on a group of chunks? Should we just list all }the chunks being voted on, preferably in the order they appear in the }proposed spec? E.g: } }Subject: VOTE on xSCL ySCL We can refer such groups as "xSCL etc." We do not allow splitting votes on groups; it's all or nothing. } }> (2) First line of message must contain actual YES or NO. If the }> message starts with a quote of someone else, it's not a vote. } }Sure. I think the first line is your e-mail address, but that can be changed; put the e-mail address last and YES|NO on the first line. } }In practice, if someone flubs the format, someone (or several) will }simply tell him/her to recast the vote properly, which will make moot }any arguments about whether the first attempted vote counted. Right. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 18:48:49 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA27516 for ; Mon, 23 Sep 1996 18:48:46 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA06931 for png-list-outgoing; Mon, 23 Sep 1996 18:51:03 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id SAA06926 for ; Mon, 23 Sep 1996 18:51:00 -0500 Date: Mon, 23 Sep 96 19:43:04 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: A proposal for new-chunk process Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609231943.aa08179@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Subject: Re: A proposal for new-chunk process }Date: Mon, 23 Sep 1996 18:30:46 -0400 }From: Tom Lane }I concur with Adam and John: blind voting is exactly the sort of process }we *don't* want. It's a safeguard that's appropriate in real-world Right! ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 19:01:24 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id TAA27554 for ; Mon, 23 Sep 1996 19:01:23 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA07075 for png-list-outgoing; Mon, 23 Sep 1996 19:03:29 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id TAA07070 for ; Mon, 23 Sep 1996 19:03:26 -0500 Date: Mon, 23 Sep 96 19:58:53 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: A proposal for new-chunk process Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609231958.aa08337@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List We might also want to allow ABSTAIN votes. Such votes wouldn't be counted, but it would provide a mechanism for a person to withdraw a YES or NO vote without having to cast a cancelling NO or YES. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 19:29:06 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id TAA27851 for ; Mon, 23 Sep 1996 19:29:05 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA07444 for png-list-outgoing; Mon, 23 Sep 1996 19:31:15 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id TAA07439 for ; Mon, 23 Sep 1996 19:31:07 -0500 Date: Mon, 23 Sep 96 20:26:44 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: png-list@dworkin.wustl.edu Subject: New chunk registration procedure 19960924 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609232026.aa08681@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Here's the second draft of the chunk registration process. -----cut here----- PNG-GROUP-DRAFT PNG Development Group PNG-Registration png-list@dworkin.wustl.edu Expires: 24 Mar 1997 24 Sep 1996 PNG Chunk Registration Process, draft 19960924 File png-registration-19960924.txt Status of this Memo This document is an informal draft of the PNG development group. Comments on this document can be sent to the PNG specification maintainers at png-info@uunet.uu.net or at png- list@dworkin.wustl.edu. Distribution of this memo is unlimited. At present, the latest version of this document is available on the World Wide Web from ftp://swrinde.nde.swri.edu/pub/png- group/documents/. Notices Copyright (c) 1996 Thomas Boutell Permission is granted to copy and distribute this document for any purpose and without charge, provided that this notice is preserved, and that any substantive changes or deletions from the original are clearly marked. Abstract This document describes the approval process for registering public PNG chunks. Persons who have contributed to the PNG mailing list at least 180 days prior to the end of the voting period are eligible to vote. A two-week voting period follows a two-week discussion period. Votes are cast by electronic mail to the png-list mailing list. Approval of a chunk registration requires at least 10 YES votes with at least twice as many YES votes as NO votes. PNG Development Group [Page 1] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960924 24 Sep 1996 Table of Contents 1. Purpose ........................................................ 2 2. Justification and additional aims .............................. 2 3. Prerequisites .................................................. 2 4. Voting ......................................................... 3 4.1. Initiation ................................................ 3 4.2. Casting votes ............................................. 4 4.3. Changing votes ............................................ 5 4.4. Termination ............................................... 5 5. Decision ....................................................... 5 6. Franchise ...................................................... 6 7. Adoption of this procedure ..................................... 6 8. Editor ......................................................... 6 1. Purpose To formally approve or reject a chunk for registration as a public chunk as described in the PNG 1.0 specification. This method can also be used to resolve other issues that need to be decided by the PNG group. 2. Justification and additional aims Discussions on the PNG discussion list (png-list@dworkin.wustl.edu) at present fail to reach a clear consensus on the desirability of particular chunk definitions. The formal approval process is intended to aid such decisions by * Identifying consensus when it exists. * Giving a limited time period within which objections can be raised. * Encouraging discussion and preventing ambiguities when one party to the discussion simply falls silent. To meet these ends the formal process is based on a discussion and voting process exercised over a limited period of time. 3. Prerequisites * A proposed specification of the chunk must exist in electronic PNG Development Group [Page 2] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960924 24 Sep 1996 form in a location on the current png-group discussion list FTP server (at present this is the tree based at ftp://swrinde.nde.swri.edu/pub/png-group/). The proposal must be in a final publishable format, such as that of the PNG specification and PNG extensions document. * The specification can either be a whole single file, or group of files (which must be named by single ftp accessible directory name and implies all files in that directory and all directories beneath it) or an identified part of a single file. * The specification should describe the proposed chunk in its unregistered form, to avoid the risk of premature distribution of documents describing public chunks that are not in their final form. The editors will make the necessary changes to the final document, by changing the second letter of the chunk name to uppercase and by removing any private version identification. If any other changes are needed, instructions to the editors should be provided in the proposal. * The specification or the call for votes must state the proposed disposition of the registered chunk: * Inclusion in the PNG core specification * Inclusion in the PNG extensions document * Inclusion in an existing separate document * Inclusion in a new separate document Note that the names of all formally registered chunks will either appear in the PNG specification or in the PNG extensions document. The editors will make the appropriate changes to those documents when a chunk is registered. * Throughout the two-week voting period the specification must remain absolutely unchanged. The two-week discussion period must be restarted upon making any change to the proposed specification, except for * Simple formatting, grammatical, or spelling changes. * A printing date or authorship change. Upon the objection of any voter, received by the png-list server prior to the call for votes, the two-week discussion period must be restarted in the event of any such change. 4. Voting 4.1. Initiation Voting can be initiated after a two-week discussion period. The proposed chunk specification must be available and must not change for a period of at least two weeks before a vote can be called for. The chunk proponent starts this clock running by notifying the list that the proposed specification is available. Short proposals should also be posted to the list, to save people the trouble of downloading them. If discussion exposes flaws, the specification can be revised, thus starting a new two-week discussion period. After the two-week discussion period, the vote is initiated by any PNG Development Group [Page 3] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960924 24 Sep 1996 person submitting the first YES vote on an identified specification, using the format suggested above, clearly identifying the specification to be voted upon. 4.2. Casting votes Votes are cast by sending a message to the png-list indicating a YES, NO, or ABSTAIN vote. Voters should take care to make their intentions clear (i.e. "YES" or "NO" and precisely what chunk specification is being voted on). To ensure that a vote is correctly registered the following form, as the first lines of an e-mail message, is suggested: {YES|NO|ABSTAIN} Name For example: YES cNEW ftp://swrinde.nde.swri.edu/pub/png-group/documents/ png-proposed-chunks-19991231.html Glenn Randers-Pehrson The vote-takers can accept votes that do not adhere exactly to this format as long as the intent is clear. There should be no other topics of discussion in the same message. An "Oh, by the way, I vote NO on cNEW" buried in the text of a long message might get overlooked. It is acceptable and useful to include additional explanations in the message, but the vote itself should be placed at the beginning. The subject of the message must contain the word "VOTE" (in uppercase letters), the word "YES" or "NO" or "ABSTAIN" (in uppercase letters), and the name of the proposal being voted upon, and the string "Re:" must not not appear in the subject. An example of a correctly formatted subject line is Subject: I VOTE YES on cNEW 19991231. Only one vote should be included in a message. If a group of chunks is being voted on as a whole, then only one message is necessary, but if different chunks are being separately voted upon during the same period, separate messages are required. The decision whether to group or separate chunks for voting is up to the person casting the initial YES vote. PNG Development Group [Page 4] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960924 24 Sep 1996 4.3. Changing votes A person can submit a changed vote any time prior to the expiration of the voting period. Only the latest vote, determined by the time it was mailed by the voter (from the "Date:" field of the message), that is received by the png-list server prior to the expiration of the voting period, will be counted. ABSTAIN votes are not counted. A person can cast an ABSTAIN vote to withdraw a YES or NO vote without having to cast a NO or YES to countermand it. 4.4. Termination The voting period ceases two weeks after the initiation, at the same time of day as the initiation. The time of the call for votes is determined by the "Received:" line generated by the png- list e-mail server, e.g. in the message header "Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA10764 for ; Sun, 22 Sep 1996 10:11:58 -0500" the date and time are "Sun, 22 Sep 1996 10:11:58 -0500", and the voting period ends on Sunday, 06 Oct 1996 10:11:58 -0500. The voting period also ceases immediately and the proposal is rejected if all YES votes are countermanded by NO or ABSTAIN votes from the voters originally casting the YES votes. The voting period ceases immediately and the proposal is rejected upon approval of a competing specification for same chunk name. 5. Decision Votes will be tallied and interpreted by a group of [3?] vote-takers, to be selected by consensus for life-time appointment from among volunteers. [Who counts the votes if we want to impeach the vote- takers?] A chunk specification is approved if both of the following conditions are met at the end of the voting period: * Ten YES votes are received. * At least twice the number of YES votes as NO votes are received. If these conditions are met, then the chunk immediately becomes registered and people can start using it in its registered form. The PNG editors will include the chunk specification, or a reference to it, in the next release of the PNG documentation. If these conditions are not met the chunk specification is rejected. PNG Development Group [Page 5] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960924 24 Sep 1996 A further vote requires either a 180-day waiting period, to allow for implementation and testing, or a substantial change to the definition as a prerequisite. 6. Franchise Anyone is eligible to vote who has: * Submitted their first (or any subsequent) message to the png- list at least 180 days before the termination of the voting period. 7. Adoption of this procedure Adoption of this procedure for registering PNG chunks will be voted upon using the same procedure as used for approving a chunk registration. It will take effect immediately upon the successful completion of the required discussion and voting periods. Discussion periods for proposed chunks, but not voting periods, can run concurrently with the voting period for adoption of this procedure. The procedure described in this document can also be used for registering chunks in related formats such as MNG, provided it is separately adopted for use for the other format. The votes will be called for and cast using the appropriate mailing list (e.g. mpng- list) instead of png-list. 8. Editor * Glenn Randers-Pehrson glennrp@arl.mil or randeg@alumni.rpi.edu End of PNG Chunk Registration Process document. Expires 24 Mar 1997. PNG Development Group [Page 6] ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 20:35:49 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id UAA28187 for ; Mon, 23 Sep 1996 20:35:48 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA08076 for png-list-outgoing; Mon, 23 Sep 1996 20:37:46 -0500 Received: from dawn11.CS.Berkeley.EDU (dawn11.CS.Berkeley.EDU [128.32.38.55]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA08071 for ; Mon, 23 Sep 1996 20:37:42 -0500 Received: (from amc@localhost) by dawn11.CS.Berkeley.EDU (8.6.11/8.6.9) id SAA26481 for png-list@dworkin.wustl.edu; Mon, 23 Sep 1996 18:35:20 -0700 Date: Mon, 23 Sep 1996 18:35:20 -0700 Message-Id: <199609240135.SAA26481@dawn11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: New chunk registration procedure 19960924 X-Advice: should read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson ARL-WMRD-TED-TIB says: > Votes are cast by sending a message to the png-list indicating a > YES, NO, or ABSTAIN vote. I like ABSTAIN. Good call. > Voters should take care to make their intentions clear > (i.e. "YES" or "NO" or "ABSTAIN" > An example of a correctly formatted subject line is > > Subject: I VOTE YES on cNEW 19991231. Actually, I think people should be discouraged from including the YES, NO, or ABSTAIN in the Subject field. That would force vote-counters to look at the message bodies of all VOTE messages, which they ought to be doing. As for messages that do contain the YES, NO, or ABSTAIN in the Subject field, we ought either to disallow all of them, or disallow the ones whose Subject fields are inconsistent with their bodies. > Votes will be tallied and interpreted by a group of [3?] > vote-takers, to be selected by consensus for life-time appointment > from among volunteers. [Who counts the votes if we want to impeach > the vote- takers?] I still question whether this is unnecessary complication. It raises the question of how to fill vacancies left by resignation. Using consensus looks fishy--the purpose of this procedure is to formalize consensus. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 21:09:40 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id VAA28408 for ; Mon, 23 Sep 1996 21:09:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA08486 for png-list-outgoing; Mon, 23 Sep 1996 21:11:42 -0500 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id VAA08479 for ; Mon, 23 Sep 1996 21:11:36 -0500 Received: by mail3.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBA96C.405D2970@mail3.microsoft.com>; Mon, 23 Sep 1996 16:28:28 -0700 Message-ID: From: John Bowler To: "'PNG List'" Subject: RE: A proposal for new-chunk process Date: Mon, 23 Sep 1996 16:25:58 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 17 TEXT Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB[SMTP:glennrp@ARL.MIL] > > This document describes the approval process for registering > public PNG chunks. Persons who have contributed to the PNG mailing list > at least 180 days prior to the end of the voting period are eligible > to vote. Ah, but I did it that way (6 months, not 6x30 days) because anyone can work out what day was six months ago - given that the ambiguity with months of different lengths is resolved, but I have yet to meet someone who can subtract 180 from the current date in their head - most of the people I know (including me) have difficulty even with the help of a calendar and a pencil. John Bowler > ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 23 21:23:40 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id VAA28478 for ; Mon, 23 Sep 1996 21:23:40 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA08749 for png-list-outgoing; Mon, 23 Sep 1996 21:25:52 -0500 Received: from boutell.com (boutell.com [206.125.69.81]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id VAA08744 for ; Mon, 23 Sep 1996 21:25:49 -0500 Received: from localhost (boutell@localhost) by boutell.com (8.7.3/8.7.3) with SMTP id TAA26958 for ; Mon, 23 Sep 1996 19:32:53 -0700 Date: Mon, 23 Sep 1996 19:32:53 -0700 (PDT) From: Thomas Boutell To: png-list@dworkin.wustl.edu Subject: Voting mechanism for new chunks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I favor public rather than blind voting for approval of new chunks. I also think the idea of an ABSTAIN vote is reasonable. Two bits from the mostly sleepy editor emeritus, -T Pick a newsgroup and rescue it: http://www.boutell.com/boutell/usenet.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 24 06:16:53 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id GAA01856 for ; Tue, 24 Sep 1996 06:16:41 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id GAA14084 for png-list-outgoing; Tue, 24 Sep 1996 06:18:30 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id GAA14079 for ; Tue, 24 Sep 1996 06:18:27 -0500 Date: Tue, 24 Sep 96 7:09:36 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: A proposal for new-chunk process Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609240709.aa13597@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Message-ID: }Subject: RE: A proposal for new-chunk process }Date: Mon, 23 Sep 1996 16:25:58 -0700 }>From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB[SMTP:glennrp@ARL.MIL] }> }> This document describes the approval process for registering }> public PNG chunks. Persons who have contributed to the PNG mailing list }> at least 180 days prior to the end of the voting period are eligible }> to vote. } }Ah, but I did it that way (6 months, not 6x30 days) because anyone can }work out what day was six months ago - given that the ambiguity with }months of different lengths is resolved, but I have yet to meet someone }who can subtract 180 from the current date in their head - most of the }people I know (including me) have difficulty even with the help of a }calendar and a pencil. } }John Bowler } Make it 1 year then. That should be easy enough. ;-) Let's resolve this soon, though, so we can start the two-week + two-week clock on this thing. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 24 09:08:52 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id JAA03153 for ; Tue, 24 Sep 1996 09:08:52 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA15749 for png-list-outgoing; Tue, 24 Sep 1996 09:11:04 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA15742 for ; Tue, 24 Sep 1996 09:10:59 -0500 Date: Tue, 24 Sep 96 10:04:16 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New chunk registration procedure 19960924 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609241004.aa16860@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List } }> Votes will be tallied and interpreted by a group of [3?] }> vote-takers, to be selected by consensus for life-time appointment }> from among volunteers. [Who counts the votes if we want to impeach }> the vote- takers?] } }I still question whether this is unnecessary complication. It raises }the question of how to fill vacancies left by resignation. Using }consensus looks fishy--the purpose of this procedure is to formalize }consensus. } }AMC } How about this: The person casting the first uncancelled YES vote and the person casting the first uncancelled NO vote are responsible for tallying the votes or finding a volunteer to do it. If there are no NO votes the first YES voter can tally the votes. A draft joint report by these two persons will be submitted to the png-list server and is due no later than one week following the close of voting. The report will include the name and e-mail address of each YES, NO, and ABSTAIN voter, the vote totals, and a statement as to whether the chunk was approved or not. If these two persons fail to submit a report, anyone can submit one after the week has elapsed. A final joint report accounting for any corrections or challenges is due one week after the draft report. Chunk registration is effective when the vote-takers' final report is received by the png-list server. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 24 09:18:48 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id JAA03292 for ; Tue, 24 Sep 1996 09:18:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA15955 for png-list-outgoing; Tue, 24 Sep 1996 09:21:04 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA15950 for ; Tue, 24 Sep 1996 09:21:01 -0500 Date: Tue, 24 Sep 96 10:15:00 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New chunk registration procedure 19960924 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609241015.aa17962@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List } }How about this: The person }casting the first uncancelled YES vote and the person casting the first }uncancelled NO vote are responsible for tallying the votes or finding a }volunteer to do it. Maybe even better would be the person casting the second YES vote and the person casting the first NO vote. That takes the power out of the hands of the proponent. ../g ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 24 12:09:20 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id MAA07733 for ; Tue, 24 Sep 1996 12:09:20 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA20164 for png-list-outgoing; Tue, 24 Sep 1996 12:10:32 -0500 Received: from mega.megamed.com (megamed.com [199.4.114.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA20159 for ; Tue, 24 Sep 1996 12:10:27 -0500 Received: from coruisk (mega202.megamed.com [199.4.114.202]) by mega.megamed.com (8.7.5/8.7.3) with SMTP id KAA07846 for ; Tue, 24 Sep 1996 10:07:49 -0700 Date: Tue, 24 Sep 1996 10:07:49 -0700 Message-Id: <199609241707.KAA07846@mega.megamed.com> X-Sender: jbowler@megamed.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: John Bowler Subject: Re: A proposal for new-chunk process Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 07:09 24/09/96 EDT, Glenn wrote: > >In reply to the message >}From: John Bowler >} >}Ah, but I did it that way (6 months, not 6x30 days) because anyone can >}work out what day was six months ago - given that the ambiguity with >}months of different lengths is resolved, but I have yet to meet someone >}who can subtract 180 from the current date in their head - most of the >}people I know (including me) have difficulty even with the help of a >}calendar and a pencil. >Make it 1 year then. That should be easy enough. ;-) > >Let's resolve this soon, though, so we can start the two-week + two-week >clock on this thing. I'd like to hear a third opinion - either definition creates complexity somewhere, I don't have any intuition for which is better so ultimately I would be happy with either. John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 24 12:10:35 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id MAA07763 for ; Tue, 24 Sep 1996 12:10:30 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA20233 for png-list-outgoing; Tue, 24 Sep 1996 12:12:51 -0500 Received: from mega.megamed.com (megamed.com [199.4.114.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA20228 for ; Tue, 24 Sep 1996 12:12:46 -0500 Received: from coruisk (mega202.megamed.com [199.4.114.202]) by mega.megamed.com (8.7.5/8.7.3) with SMTP id KAA08034 for ; Tue, 24 Sep 1996 10:10:19 -0700 Date: Tue, 24 Sep 1996 10:10:19 -0700 Message-Id: <199609241710.KAA08034@mega.megamed.com> X-Sender: jbowler@megamed.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: John Bowler Subject: Re: New chunk registration procedure 19960924 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 10:15 24/09/96 EDT, Glenn wrote: >} >}How about this: The person >}casting the first uncancelled YES vote and the person casting the first >}uncancelled NO vote are responsible for tallying the votes or finding a >}volunteer to do it. > >Maybe even better would be the person casting the second YES vote and >the person casting the first NO vote. That takes the power out of >the hands of the proponent. I'm not sure the position of votecounter actually conveys any power, however these seems like a good suggestion to me; it avoids the current dependence of the registratioon procedure on some external election of vote counters. John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 24 12:41:09 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id MAA08020 for ; Tue, 24 Sep 1996 12:40:55 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA20739 for png-list-outgoing; Tue, 24 Sep 1996 12:42:42 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA20734 for ; Tue, 24 Sep 1996 12:42:26 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id KAA11146 for ; Tue, 24 Sep 1996 10:29:33 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id KAA17520 for png-list@dworkin.wustl.edu; Tue, 24 Sep 1996 10:29:33 -0700 (PDT) Message-Id: <199609241729.KAA17520@web1.calweb.com> Subject: Tallying votes To: png-list@dworkin.wustl.edu Date: Tue, 24 Sep 1996 10:29:32 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <9609240709.aa13597@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 24, 96 07:09:36 am Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List OK, so public votes it is. Guess I'm just too immersed in politics right now to think otherwise. If the vote format is reasonably uniform--e.g. the word "VOTE" in the subject line, and "YES/NO" and chunk name in the body, then tallying with a robot is trivial, and you can have instant running results on a Web page. I see no reason at all to put the vote-tallier into the process spec; if no one volunteers for the job, then it isn't worth doing. Probably two or three talliers should do this, and if there is any discrepancy, we can investigate. I'll certainly be one (in fact, if the votes are public and in uniform format, I'll make the robot and Web page whether I'm asked to or not--public means public). In keeping with the apolitical informal nature of the process, it should simply be up to the editor of the document to see the results and include them in the doc. Since all the results will be kept for history, anyone can check the doc against the votes and raise questions if necessary. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 24 12:56:03 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id MAA08259 for ; Tue, 24 Sep 1996 12:56:03 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA21159 for png-list-outgoing; Tue, 24 Sep 1996 12:58:11 -0500 Received: from dawn11.CS.Berkeley.EDU (dawn11.CS.Berkeley.EDU [128.32.38.55]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA21154 for ; Tue, 24 Sep 1996 12:58:06 -0500 Received: (from amc@localhost) by dawn11.CS.Berkeley.EDU (8.6.11/8.6.9) id KAA27718 for png-list@dworkin.wustl.edu; Tue, 24 Sep 1996 10:55:40 -0700 Date: Tue, 24 Sep 1996 10:55:40 -0700 Message-Id: <199609241755.KAA27718@dawn11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: A proposal for new-chunk process X-Advice: perhaps read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson ARL-WMRD-TED-TIB says: > Make it 1 year then. That should be easy enough. ;-) Except on 29 Feb! :) AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 24 13:04:18 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA08329 for ; Tue, 24 Sep 1996 13:04:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA21338 for png-list-outgoing; Tue, 24 Sep 1996 13:06:26 -0500 Received: from dawn11.CS.Berkeley.EDU (dawn11.CS.Berkeley.EDU [128.32.38.55]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA21333 for ; Tue, 24 Sep 1996 13:06:20 -0500 Received: (from amc@localhost) by dawn11.CS.Berkeley.EDU (8.6.11/8.6.9) id LAA27841 for png-list@dworkin.wustl.edu; Tue, 24 Sep 1996 11:03:50 -0700 Date: Tue, 24 Sep 1996 11:03:50 -0700 Message-Id: <199609241803.LAA27841@dawn11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: Tallying votes X-Advice: perhaps read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List "Lee Daniel Crocker" says: > I see no reason at all to put the vote-tallier into the process spec; > if no one volunteers for the job, then it isn't worth doing. Probably > two or three talliers should do this, and if there is any discrepancy, > we can investigate. I agree. > I'll certainly be one (in fact, if the votes are public and in uniform > format, I'll make the robot and Web page whether I'm asked to or > not--public means public). Thanks! AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 24 13:15:57 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA08523 for ; Tue, 24 Sep 1996 13:15:56 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA21556 for png-list-outgoing; Tue, 24 Sep 1996 13:17:53 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA21551 for ; Tue, 24 Sep 1996 13:17:48 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id OAA10151 for ; Tue, 24 Sep 1996 14:15:17 -0400 (EDT) To: PNG List Subject: Re: New chunk registration procedure 19960924 In-reply-to: Your message of Tue, 24 Sep 1996 10:10:19 -0700 <199609241710.KAA08034@mega.megamed.com> Date: Tue, 24 Sep 1996 14:15:16 -0400 Message-ID: <10149.843588916@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >> Maybe even better would be the person casting the second YES vote and >> the person casting the first NO vote. (A) this discourages people from being the first to vote if they don't feel like being votetaker. I can see it now: Proponent: call for votes Proponent: YES vote I personally have not got the time or interest to be votetaker, and thus would be one of those waiting for other people to drop the first shoe. (B) if you're looking for something not subject to gaming, this ain't it. If there are two proponents they can arrange for one to be the "pro" votetaker by sending in the CFV followed by two YES votes in quick succession. If there are three, one can vote NO and become the "con" votetaker as well. We need a volunteer, plain and simple. If there's any serious doubt about the result of a vote, everyone interested can inspect the archives for themselves; so it's not like you need to trust the votetaker 100%. An overly complicated vote counting procedure is just overhead. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 24 13:38:24 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA08844 for ; Tue, 24 Sep 1996 13:38:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA21872 for png-list-outgoing; Tue, 24 Sep 1996 13:40:23 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id NAA21867 for ; Tue, 24 Sep 1996 13:40:19 -0500 Date: Tue, 24 Sep 96 14:34:24 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New chunk registration procedure 19960924 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609241434.aa23910@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I'll take the vote-tallying stuff out of the draft and we can sort out how to count the votes when the time comes.. I'll leave the eligibility at 180 days. Anyone who cares about that can do the arithmetic. Odds are pretty good that no one will actually fall so close to the cutoff that it will be that hard to figure. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 24 14:19:41 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id OAA12509 for ; Tue, 24 Sep 1996 14:19:40 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA22644 for png-list-outgoing; Tue, 24 Sep 1996 14:21:35 -0500 Received: from natashya.eden.com (natashya.eden.com [199.171.21.14]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA22639 for ; Tue, 24 Sep 1996 14:21:29 -0500 Received: from cpic (net-2-068.austin.eden.com [206.81.226.68]) by natashya.eden.com (8.8.Beta.6/8.7.1.1) with SMTP id OAA07125 for ; Tue, 24 Sep 1996 14:18:59 -0500 (CDT) Date: Tue, 24 Sep 1996 14:18:59 -0500 (CDT) Message-Id: <199609241918.OAA07125@natashya.eden.com> X-Sender: pschmidt@mail.eden.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: pschmidt@photodex.com (Paul Schmidt) Subject: Re: A proposal for new-chunk process Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >The first thought that comes to mind is: > >(1) Subject line must contain "VOTE on " (just to make the job > of scanning the archives easier). >(2) First line of message must contain actual YES or NO. > If the message starts with a quote of someone else, it's not a vote. > >Better ideas? Why not just requre the voters to change the subject line unless they're voting. In other words, no vote can have "Re:" in it. Best Regards, Paul Schmidt ---------------------------------------------------------- Photodex Corporation Service GO/Keyword E-Mail 1106 Clayton Lane #200W AOL: Photodex Photodex Austin, TX 78723 CIS: Photodex 74774,3635 (512)406-3020 Voice (512)452-6825 Fax i'net: pschmidt@photodex.com "I play with dots... WWW: http://www.photodex.com ...lots of dots." FTP: ftp.photodex.com ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 24 16:58:28 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA18357 for ; Tue, 24 Sep 1996 16:58:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA25112 for png-list-outgoing; Tue, 24 Sep 1996 16:59:42 -0500 Received: from enel.ucalgary.ca ([136.159.99.2]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA25104 for ; Tue, 24 Sep 1996 16:59:33 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id PAA00643; Tue, 24 Sep 1996 15:57:04 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609242157.PAA00643@enel.ucalgary.ca> Subject: Re: libpng docs (was Re: fING) To: png-list@dworkin.wustl.edu Date: Tue, 24 Sep 1996 15:57:04 -0600 (MDT) In-Reply-To: <199609091727.MAA15233@ellis.uchicago.edu> from "Cave Newt" at Sep 9, 96 12:27:03 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Greg once wrote: > I do recall that the png_set_expand() thing is extremely poorly docu- > mented; it does about 8 different things under different conditions, and > there's no indication what thing is going to happen when, or how many > calls you have to make to get from one image type to another. At the > very least it needs a table describing input type and output type for > every possible image state. Actually, I don't like the whole multiple functionality issues of png_set_expand() at all. There are also other functions like png_set_strip_16(), and the png_set_gray_to_rgb() type functions which I think should be done away with. One solution is to have a function like png_set_bit_depth() and png_set_color_type(), and then libpng will internally set all of the transformations needed to convert from the existing format/depth to the desired format/depth (if they are different). I think this would make libpng considerably easier to use. However, it would change the API yet again, and in a significant way. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Tue Sep 24 17:15:10 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA18768 for ; Tue, 24 Sep 1996 17:15:04 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA25378 for png-list-outgoing; Tue, 24 Sep 1996 17:16:55 -0500 Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA25360; Tue, 24 Sep 1996 17:16:29 -0500 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id RAA28414; Tue, 24 Sep 1996 17:13:03 -0500 (CDT) Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.5/8.7.3) id RAA29192; Tue, 24 Sep 1996 17:14:02 -0500 (CDT) Date: Tue, 24 Sep 1996 17:14:02 -0500 (CDT) Message-Id: <199609242214.RAA29192@ellis.uchicago.edu> To: png-list@dworkin.wustl.edu Subject: Re: libpng docs (was Re: fING) Cc: png-implement@dworkin.wustl.edu From: Cave Newt Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I wrote: >> At the very least it needs a table describing input type and output type for >> every possible image state. Andreas wrote: >Actually, I don't like the whole multiple functionality issues of >png_set_expand() at all. I don't either; splitting it into multiple entry points was implied by the "very least" part of my comment, but I didn't want to get into that due to compatibility issues and time constraints on my part. I'm glad someone else agrees that the API needs work. :-) >One solution is to have a function like png_set_bit_depth() and >png_set_color_type(), and then libpng will internally set all of the >transformations needed to convert from the existing format/depth to >the desired format/depth (if they are different). I think this would >make libpng considerably easier to use. However, it would change the >API yet again, and in a significant way. One possibility would be to patch the current version up just enough to release it as 1.0, then set to work defining a better version ("2.0" or whatever). The next version might have MNG support built in, too, for example. This should probably move over to the png-implement list, though... Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 25 07:30:32 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id HAA24230 for ; Wed, 25 Sep 1996 07:30:29 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA05795 for png-list-outgoing; Wed, 25 Sep 1996 07:32:31 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA05788 for ; Wed, 25 Sep 1996 07:32:19 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id OAA12247 for png-list@dworkin.wustl.edu; Wed, 25 Sep 1996 14:29:48 +0200 (DST) Date: Wed, 25 Sep 1996 14:29:48 +0200 (DST) From: Chris Lilley Message-Id: <9609251429.ZM12245@grommit.inria.fr> In-Reply-To: John Bowler "Re: sRGB proposed chunk" (Sep 22, 8:10pm) References: <199609230310.UAA28061@mega.megamed.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: sRGB proposed chunk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 22, 8:10pm, John Bowler wrote: > At 16:16 22/09/96 +0100, I wrote: > > >My take on sRGB is that, as a chunk, it adds very few bytes to an image > >(well, the registered version without the id, at any rate) and if understood > >by an application can aid cross-platform portability and displayed quality. > >If not understood, then provided the gAMA and cHRM chunks were filled out > >with the suggested values, there is still some benefit. > > Until sRGB is a part of the core PNG definition it is pretty much essential > that applications write the gAMA and cHRM values too. Yes. That is why the proposed text of the chunk specifies that those chunks should be written, and provides the values to write, to make sure that this is done and done consistently. > Even when sRGB is part of the core definition there will be applications > which handle cHRM and gAMA correctly but don't recognize sRGB - because they > were implemented before the sRGB chunk is registered (or even suggested). > These applications will be around for some time (years). Yes. > The important extra in sRGB is the intent value - this specifies how to > color match against a device which does not support the full gamut of the > cHRM. No. The important extra is all the extra information that is being passed by reference, all of which is fixed, apart from the intent value. That is why that one item is included in the chunk. sRGB is not just adding one extra item of information. It adds all this, mainly describing the reference viewing conditions: Luminance level 80 cd/m2 Illuminant White x = 0.3127, y = 0.3291 (D65) Image surround 20% reflectance Encoding Ambient Illuminance Level 64 lux Encoding Ambient White Point x = 0.3457, y = 0.3585 (D50) Encoding Viewing Flare 1.0% Typical Ambient Illuminance Level 200 lux Typical Ambient White Point x = 0.3457, y = 0.3585 (D50) Typical Viewing Flare 5.0% Red Chromaticity x = 0.6400, y = 0.3300 Green Chromaticity x = 0.3000, y = 0.6000 Blue Chromaticity x = 0.1500, y = 0.0600 Transfer Characteristic for i=r,g,b if i <= 0.00304, i' = 12.92 * i else i' = 1.055* (i^(1/2.4)) - 0.055 See: http://www.hpl.hp.com/personal/Michael_Stokes/srgb.htm Without this reliable good printing of a PNG image is impossible. My > feeling is that this must become part of the core definition - i.e. a > minimal requirement is a chunk which is the same as the current sRGB except > that it does not imply cHRM or gAMA values. Such a chunk would allow data > from a device with a non-sRGB gamut to be matched to a non-matching output > device. > > Ironically when the gamut is not sRGB this is even more important - sRGB, to > a first approximation, matches current video devices (at least in the gamut > - Macs, PC video, Sun video and SGIs may well have a different gamma, but > the cHRM tends to be the same). Other gamuts do not necessarily come close > to a video device so color matching may be require too. > > In addition sRGB (the chunk, not the sRGB definition) has a problem of > specification at present: > > If both cRHM (or gAMA) and sRGB are present and they > differ, which takes precedence? > > It is viable, but not, I feel, useful to say that the image is invalid. I agree this is not useful > It > is viable to say that cHRM and gAMA take precedence - this allows sRGB > to be used (or abused) to convey only the rendering intent. No. If an application understands sRGB, the transfer curve from sRGB is always used (this cannot be fully expressed with a single number, because of the linear portion near the origin) and the sRGB chromaticities and white point are always used and all the other implicit sRGB information is used. If an application does not understand sRGB, it uses the cHRM if it understands cHRM and the gAMA (id it understands gAMA) and never uses the sRGB values becuase it does not know how to process that chunk. So in practice there are two disjoint sets and no conflict. > It would be useful if someone familiar with printing on systems other than > Win32 PCs could comment on the suggested rendering intents:- This does not have much to do with printing, though it could be used to help print; the primary intent is to control on-screen presentation. It does not have muxch to do with MS Windows or the word-length of the API - I am not sure what your intent was with that comment. > "The following values are legal for the rendering intent specifier: The four specified values are precisely those four listed in the International Color Consortium specification, and the numbers used to enumerate them are the same as those used in a ful ICC profile. I did not just make them up ;-) > 0: Perceptual rendering intent > 1: Relative colorimetric rendering intent > 2: Saturation preserving rendering intent > 3: Absolute colorimetric rendering intent" -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 25 08:28:03 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id IAA24809 for ; Wed, 25 Sep 1996 08:28:02 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA06220 for png-list-outgoing; Wed, 25 Sep 1996 08:30:24 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA06215 for ; Wed, 25 Sep 1996 08:30:19 -0500 Date: Wed, 25 Sep 96 9:25:50 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: sRGB proposed chunk Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609250925.aa10131@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Just to clarify, we can add the following line to the end of the srGB writeup (paragraph 4.4 in the 19960914 version of the png-proposed-chunks document). ICC-profile-aware applications should ignore the gAMA and cHRM chunks and process the srGB chunk instead. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 25 10:37:43 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id KAA27428 for ; Wed, 25 Sep 1996 10:37:42 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA08405 for png-list-outgoing; Wed, 25 Sep 1996 10:36:46 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA08394 for ; Wed, 25 Sep 1996 10:36:39 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id RAA12790 for png-list@dworkin.wustl.edu; Wed, 25 Sep 1996 17:36:37 +0200 (DST) Date: Wed, 25 Sep 1996 17:36:37 +0200 (DST) From: Chris Lilley Message-Id: <9609251736.ZM12788@grommit.inria.fr> In-Reply-To: Glenn Randers-Pehrson ARL-WMRD-TED-TIB "Re: sRGB proposed chunk" (Sep 25, 9:25am) References: <9609250925.aa10131@THOR.ARL.MIL> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: sRGB proposed chunk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 25, 9:25am, Glenn Randers-Pehrson ARL-WMRD-TED-TIB wrote: > Just to clarify, we can add the following line to the end of the > srGB writeup (paragraph 4.4 in the 19960914 version of the > png-proposed-chunks document). > > ICC-profile-aware applications should ignore the gAMA and > cHRM chunks and process the srGB chunk instead. Make that should a must. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 25 11:04:18 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id LAA27985 for ; Wed, 25 Sep 1996 11:04:16 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA08999 for png-list-outgoing; Wed, 25 Sep 1996 11:03:58 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id LAA08991 for ; Wed, 25 Sep 1996 11:03:24 -0500 Date: Wed, 25 Sep 96 11:56:19 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New chunk registration procedure 19960924 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609251156.aa15108@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Here's the third draft for the PNG chunk registration process. I think we can stop tinkering with it now and just let it simmer for a while. ../glennrp -----cut here--------- PNG-GROUP-DRAFT PNG Development Group PNG-Registration png-list@dworkin.wustl.edu Expires: 25 Mar 1997 25 Sep 1996 PNG Chunk Registration Process, draft 19960925 File png-registration-19960925.txt Status of this Memo This document is an informal draft of the PNG development group. Comments on this document can be sent to the PNG specification maintainers at png-info@uunet.uu.net or at png-group@w3.org. Distribution of this memo is unlimited. At present, the latest version of this document is available on the World Wide Web from ftp://swrinde.nde.swri.edu/pub/png- group/documents/. Notices Copyright (c) 1996 Thomas Boutell Permission is granted to copy and distribute this document for any purpose and without charge, provided that this notice is preserved, and that any substantive changes or deletions from the original are clearly marked. Abstract This document describes the approval process for registering public PNG chunks. Persons who have contributed to the PNG mailing list at least 180 days prior to the end of the voting period are eligible to vote. A two-week voting period follows a two-week discussion period. Votes are cast by electronic mail to the png-list mailing list. Approval of a chunk registration requires at least 10 YES votes with at least twice as many YES votes as NO votes. PNG Development Group [Page 1] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960925 25 Sep 1996 Table of Contents 1. Purpose ........................................................ 2 2. Justification and additional aims .............................. 2 3. Prerequisites .................................................. 2 4. Voting ......................................................... 3 4.1. Initiation ................................................ 3 4.2. Casting votes ............................................. 4 4.3. Changing votes ............................................ 5 4.4. Termination ............................................... 5 5. Decision ....................................................... 5 6. Franchise ...................................................... 6 7. Adoption of this process ....................................... 6 8. Sample call for votes .......................................... 6 9. Credits ........................................................ 7 10. Editor ........................................................ 8 1. Purpose To formally approve or reject a chunk for registration as a public chunk as described in the PNG 1.0 specification. This method can also be used to resolve other issues that need to be decided by the PNG group. 2. Justification and additional aims Discussions on the PNG discussion list (png-list@dworkin.wustl.edu) at present fail to reach a clear consensus on the desirability of particular chunk definitions. The formal approval process is intended to aid such decisions by * Identifying consensus when it exists. * Giving a limited time period within which objections can be raised. * Encouraging discussion and preventing ambiguities when one party to the discussion simply falls silent. To meet these ends the formal process is based on a discussion and voting process exercised over a limited period of time. 3. Prerequisites * A proposed specification of the chunk must exist in electronic PNG Development Group [Page 2] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960925 25 Sep 1996 form in a location on the current png-group discussion list FTP server. At present this is the tree based at ftp://swrinde.nde.swri.edu/pub/png-group/. The proposal must be in a final publishable format, such as that of the PNG 1.0 specification and PNG extensions documents found in ftp://swrinde.nde.swri.edu/pub/png-group/documents/. * The specification can either be a whole single file, or group of files (which must be named by single ftp accessible directory name and implies all files in that directory and all directories beneath it) or an identified part of a single file. * The specification should describe the proposed chunk in its unregistered form, to avoid the risk of premature distribution of documents describing public chunks that are not in their final form. The editors will make the necessary changes to the final document, by changing the second letter of the chunk name to uppercase and by removing any private version identification. If any other changes are needed, instructions to the editors should be provided in the proposal. * The specification or the call for votes must state the proposed disposition of the registered chunk: * Inclusion in the PNG core specification * Inclusion in the PNG extensions document * Inclusion in an existing separate document * Inclusion in a new separate document Note that the names of all formally registered chunks will either appear in the PNG specification or in the PNG extensions document. The editors will make the appropriate changes to those documents when a chunk is registered. * Throughout the two-week voting period the specification must remain absolutely unchanged. The two-week discussion period must be restarted upon making any change to the proposed specification, except for * Simple formatting, grammatical, or spelling changes. * A printing date or authorship change. Upon the objection of any voter, received by the png-list server prior to the call for votes, the two-week discussion period must be restarted in the event of any such change. 4. Voting 4.1. Initiation Voting can be initiated after a two-week discussion period. The proposed chunk specification must be available and must not change for a period of at least two weeks before a vote can be called for. The chunk proponent starts this clock running by notifying the list that the proposed specification is available. Short proposals should also be posted to the list, to save people the trouble of downloading them. If discussion exposes flaws, the specification can be revised, thus starting a new two-week discussion period. PNG Development Group [Page 3] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960925 25 Sep 1996 After the two-week discussion period, the vote is initiated by any person submitting the first YES vote on an identified specification. This message also serves as the call for votes. There is no provision for issuing a call for votes without also voting YES at the same time. The message must clearly identify the specification to be voted upon. Appendix 1 gives the recommended format for a call for votes. 4.2. Casting votes Votes are cast by sending a message to the png-list indicating a YES, NO, or ABSTAIN vote. Voters must take care to make their intentions clear (i.e. "YES" or "NO" or "ABSTAIN" and precisely what chunk specification is being voted on). It is possible that votes will be tallied automatically. Therefore, to ensure that a vote is correctly registered, the first five lines of the message must conform to the following format: {YES|NO|ABSTAIN} Name For example: YES cNEW ftp://swrinde.nde.swri.edu/pub/png-group/documents/ png-proposed-chunks-19991231.html Glenn Randers-Pehrson There should be no other topics of discussion in the same message. An "Oh, by the way, I vote NO on cNEW" buried in the text of a long message might get overlooked by a person tallying the votes and would most certainly be missed by an automatic vote tallying robot. It is acceptable and useful to include additional explanations in the message, but the vote itself must be placed at the beginning. The subject of the message must contain the word "VOTE" (in uppercase letters), the word "YES" or "NO" or "ABSTAIN" (in uppercase letters), and the name of the proposal being voted upon. The string "Re:" must not not appear in the subject. An example of a correctly formatted subject line is Subject: VOTE on cNEW 19991231. Only one vote should be included in a message. If a group of chunks is being voted on as a whole, then only one message is necessary, but if different chunks are being separately voted upon during the same period, separate messages are required. The PNG Development Group [Page 4] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960925 25 Sep 1996 decision whether to group or separate chunks for voting is up to the person casting the initial YES vote. 4.3. Changing votes A person can submit a changed vote any time prior to the expiration of the voting period. Only the latest vote, determined by the time it was mailed by the voter (from the "Date:" field of the message), that is received by the png-list server prior to the expiration of the voting period, will be counted. ABSTAIN votes are not counted. A person can cast an ABSTAIN vote to withdraw a YES or NO vote without having to cast a NO or YES to countermand it. 4.4. Termination The voting period ceases two weeks after the initiation, at the same time of day as the initiation. The time of the call for votes is determined by the "Received:" line generated by the png- list e-mail server, e.g. in the message header "Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA10764 for ; Sun, 22 Sep 1996 10:11:58 -0500" the date and time are "Sun, 22 Sep 1996 10:11:58 -0500", and the voting period ends on Sunday, 06 Oct 1996 10:11:58 -0500. The voting period also ceases immediately and the proposal is rejected if all YES votes are countermanded by NO or ABSTAIN votes from the voters originally casting the YES votes. The voting period ceases immediately and the proposal is rejected upon approval of a competing specification for same chunk name. 5. Decision A chunk specification is approved if both of the following conditions are met at the end of the voting period: * Ten YES votes are received. * At least twice the number of YES votes as NO votes are received. If these conditions are met, then the chunk becomes registered immediately upon the close of the voting period, and people can start using it in its registered form. The PNG editors will include the chunk specification, or a reference to it, in the next release of the PNG documentation. If these conditions are not met the chunk specification is rejected. The same chunk cannot be brought up again for another discussion PNG Development Group [Page 5] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960925 25 Sep 1996 period and vote until either a 180-day waiting period has elapsed, to allow for implementation and testing, or until a substantial change to the specification is made. 6. Franchise Any person is eligible to vote who has: * Submitted their first (or any subsequent) message to the png- list at least 180 days before the termination of the voting period. 7. Adoption of this process Adoption of this process for registering PNG chunks will be voted upon using the same process as used for approving a chunk registration. It will take effect immediately upon the successful completion of the required discussion and voting periods. Discussion periods for proposed chunks, but not voting periods, can run concurrently with the voting period for adoption of this process. If approved, this document will be converted by the editor to a non- draft form and maintained in the png-group/documents archives. The process described in this document can also be used for registering chunks in related formats such as MNG, provided it is separately adopted for use for the other format. The votes will be called for and cast using the appropriate mailing list (e.g. mpng- list) instead of png-list. 8. Sample call for votes This is a recommended format for a call for votes, to be used by the first person submitting a YES vote. Only the first five lines of the message, which contain your own YES vote, are mandatory; the rest can be omitted if it is clear that all participants are already aware of the voting process. When there has been a long lapse between votes, or when new people have become eligible to vote, the complete message should be sent. Subject: VOTE on CNEW 19991231 YES cNEW 19991231 ftp://swrinde.nde.swri.edu/pub/png-group/documents png-proposed-chunks-19991231 My Name This is a call for votes on the PNG proposal cNEW 19991231 PNG Development Group [Page 6] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960925 25 Sep 1996 To vote on this proposal, send a message to png-list@dworkin.wustl.edu The subject line of your message must contain the words VOTE on cNEW 19991231 and must NOT contain the string "Re:" (i.e. do not try to cast your vote by "replying" to this message. You must manually construct the proper subject line). The body of your message must contain the following five lines, which must appear first in the message. YES | NO | ABSTAIN cNEW 19991231 ftp://swrinde.nde.swri.edu/pub/png-group/documents png-proposed-chunks-19991231 Your Name After these five lines you can add an explanation of your vote, if you desire. Providing the rationale for a NO vote is particularly encouraged. The voting period closes exactly two weeks after the time that this message or any earlier YES vote on this proposal was received by the png-list server (dworkin@wustl.edu) You can change your vote by submitting a new message. Only the last message sent by you and received by the png-list server prior to the close of the voting period will be counted. You are eligible to vote if your earliest message to png-list was received at least 180 days earlier than the close of the voting period. regards, Chunk Proponent 9. Credits Contributors' names are presented in alphabetical order: * Thomas Boutell, boutell@boutell.com * John Bowler, jbowler@megamed.com * Adam M. Costello, amc@cs.berkeley.edu * Lee Daniel Crocker, lee@piclab.com * Tom Lane, tgl@sss.pgh.pa.us * Glenn Randers-Pehrson, glennrp@arl.mil or randeg@alumni.rpi.edu * Greg Roelofs, newt@pobox.com * Willem van Schaik, gwillem@ntuvax.ntu.ac.sg PNG Development Group [Page 7] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960925 25 Sep 1996 10. Editor Glenn Randers-Pehrson U.S. Army Research Laboratory ATTN: AMSRL-WM-TD Aberdeen Proving Ground, MD 21005-5066 Phone: (410) 278-6554 EMail: glennrp@arl.mil or randeg@alumni.rpi.edu End of PNG Chunk Registration Process document. Expires 25 Mar 1997. PNG Development Group [Page 8] ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 25 11:49:41 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id LAA28423 for ; Wed, 25 Sep 1996 11:49:38 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA09719 for png-list-outgoing; Wed, 25 Sep 1996 11:49:22 -0500 Received: from mega.megamed.com (megamed.com [199.4.114.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA09712 for ; Wed, 25 Sep 1996 11:49:16 -0500 Received: from coruisk (mega215.megamed.com [199.4.114.215]) by mega.megamed.com (8.7.5/8.7.3) with SMTP id JAA07907 for ; Wed, 25 Sep 1996 09:49:06 -0700 Date: Wed, 25 Sep 1996 09:49:06 -0700 Message-Id: <199609251649.JAA07907@mega.megamed.com> X-Sender: jbowler@megamed.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: John Bowler Subject: Re: sRGB proposed chunk Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 09:25 25/09/96 EDT, you wrote: > >Just to clarify, we can add the following line to the end of the >srGB writeup (paragraph 4.4 in the 19960914 version of the >png-proposed-chunks document). > > ICC-profile-aware applications should ignore the gAMA and > cHRM chunks and process the srGB chunk instead. Unfortunately there are already ICC-profile-aware applications which handle PNG data (and, in particular, handle cHRM and gAMA) but do not recognize the sRGB chunk. Of the three possible resolutions (invalid, cHRM/gAMA take precedence and sRGB takes precedence) this is the one which is most misleading. John Bowler (jbowler@acm.org) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 25 12:29:04 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id MAA29013 for ; Wed, 25 Sep 1996 12:28:57 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA10234 for png-list-outgoing; Wed, 25 Sep 1996 12:28:36 -0500 Received: from mega.megamed.com (megamed.com [199.4.114.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA10229 for ; Wed, 25 Sep 1996 12:28:31 -0500 Received: from coruisk (mega215.megamed.com [199.4.114.215]) by mega.megamed.com (8.7.5/8.7.3) with SMTP id KAA09315 for ; Wed, 25 Sep 1996 10:28:14 -0700 Date: Wed, 25 Sep 1996 10:28:14 -0700 Message-Id: <199609251728.KAA09315@mega.megamed.com> X-Sender: jbowler@megamed.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: John Bowler Subject: Re: sRGB proposed chunk Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I'm going to use "srGB" in this to mean the *chunk* and "sRGB" to mean the specification, quotes from previous messages (particularly my own) don't use such a convention so can be confusing. At 14:29 25/09/96 +0200, Chris Lilley wrote: >On Sep 22, 8:10pm, John Bowler wrote: [With respect to my comment about srGB only adding the intent information to a PNG] >No. The important extra is all the extra information that is being >passed by reference, all of which is fixed, apart from the intent value. >That is why that one item is included in the chunk. sRGB is not just >adding one extra item of information. It adds all this, mainly describing >the reference viewing conditions: > > > Luminance level 80 cd/m2 > Illuminant White x = 0.3127, y = 0.3291 (D65) > Image surround 20% reflectance > Encoding Ambient Illuminance Level 64 lux > Encoding Ambient White Point x = 0.3457, y = 0.3585 (D50) > Encoding Viewing Flare 1.0% > Typical Ambient Illuminance Level 200 lux > Typical Ambient White Point x = 0.3457, y = 0.3585 (D50) > Typical Viewing Flare 5.0% > Red Chromaticity x = 0.6400, y = 0.3300 > Green Chromaticity x = 0.3000, y = 0.6000 > Blue Chromaticity x = 0.1500, y = 0.0600 > Transfer Characteristic for i=r,g,b > if i <= 0.00304, i' = 12.92 * i > else i' = 1.055* (i^(1/2.4)) - 0.055 Illuminant white, chromacity are in cHRM, transfer characteristics are represented in gAMA. Both cHRM and gAMA lose some information (z values, full 709 transfer function) wrt the full sRGB spec, so the srGB chunk does add extra useful information - I agree. My limited understanding of color, however, suggests that image surround, typical ambient light information, viewing flare are properties of the viewing environment not of the image. This reflects, I believe, the fact that sRGB is more than just an image specification - it is a default/recommended behavior for monitors. The Encoding illuminant information is, I suspect useful when displaying the image (this is at, or beyond, the limit of my understanding), but I would argue that, if this is so, it should be possible to store that information in a separate PNG chunk. Note that this does not, in any way, imply that srGB is a bad idea - the point about precise specification of the transfer characteristic convinces me that it is:- >No. If an application understands sRGB, the transfer curve from sRGB is >always used (this cannot be fully expressed with a single number, because >of the linear portion near the origin) and the sRGB chromaticities and >white point are always used and all the other implicit sRGB information >is used. > >If an application does not understand sRGB, it uses the cHRM if it >understands cHRM and the gAMA (id it understands gAMA) and never uses >the sRGB values becuase it does not know how to process that chunk. So >in practice there are two disjoint sets and no conflict. Actually this is not true and will become less true in the future - as sRGB is adopted more and more PC systems will default to sRGB characteristics, so if an application understands cHRM and gAMA and uses them it will implicitly use the sRGB characteristics even though it does not recognize the srGB chunk. There is still no conflict in this. >> It would be useful if someone familiar with printing on systems other than >> Win32 PCs could comment on the suggested rendering intents:- > >This does not have much to do with printing, though it could be used to >help print; the primary intent is to control on-screen presentation. It >does not have muxch to do with MS Windows or the word-length of the API >- I am not sure what your intent was with that comment. Win32 is the name of a specific API which supports color management (via the ICM APIs) and with which I am familiar. "MS Windows" is a generic name used for an number of OS environments, some of which support Win32 - but only Win32 supports color management. MacOS supports color management (via the ColorSync stuff) - I am not familiar with this. There needs to be some way of satisfactorily mapping from the srGB (chunk) intent and the other sRGB (spec) intents into the MacOS support. This probably isn't a major issue for sRGB, but it is for PNG because we do not want to put something into the spec which meets an OS independent requirement but which is, itself, OS dependent. I'm fairly sure srGB is satisfactory from this point of view, but I'd like to hear confirmation from somewhere. John Bowler (jbowler@acm.org) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 25 12:29:07 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id MAA29020 for ; Wed, 25 Sep 1996 12:29:06 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA10249 for png-list-outgoing; Wed, 25 Sep 1996 12:29:03 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA10244 for ; Wed, 25 Sep 1996 12:28:59 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id NAA16054 for ; Wed, 25 Sep 1996 13:28:47 -0400 (EDT) To: PNG List Subject: Re: sRGB proposed chunk In-reply-to: Your message of Wed, 25 Sep 1996 09:49:06 -0700 <199609251649.JAA07907@mega.megamed.com> Date: Wed, 25 Sep 1996 13:28:46 -0400 Message-ID: <16052.843672526@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List How about: If a file containing an sRGB chunk has gAMA and/or cHRM chunks with values other than those given here, the file is incorrect. In such a case it is recommended that sRGB-aware decoders use the sRGB values and ignore the gAMA and cHRM chunks. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 25 13:12:25 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA29442 for ; Wed, 25 Sep 1996 13:12:08 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA10883 for png-list-outgoing; Wed, 25 Sep 1996 13:10:00 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id NAA10875 for ; Wed, 25 Sep 1996 13:09:54 -0500 Date: Wed, 25 Sep 96 14:03:28 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: sRGB proposed chunk Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609251403.aa00732@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Wed, 25 Sep 1996 09:49:06 -0700 }From: John Bowler }Subject: Re: sRGB proposed chunk }At 09:25 25/09/96 EDT, you wrote: }> }>Just to clarify, we can add the following line to the end of the }>srGB writeup (paragraph 4.4 in the 19960914 version of the }>png-proposed-chunks document). }> }> ICC-profile-aware applications should ignore the gAMA and }> cHRM chunks and process the srGB chunk instead. }sRGB chunk. That is certainly to be expected, since srGB is brand new and unregistered. I am glad that they process gAMA and cHRM. } }Of the three possible resolutions (invalid, cHRM/gAMA take precedence and }sRGB takes precedence) this is the one which is most misleading. } }John Bowler (jbowler@acm.org) Applications that don't recognize sRGB will ignore it and (hopefully) process gAMA and cHRM. Ones that do recognize sRGB will undoubtedly also recognize gAMA and cHRM but only use them if the sRGB chunk is not present. What is misleading? The only thing is that the image might look different if the cHRM and gAMA data aren't consistent with the sRGB profile; in this case there's no way to tell which is correct and the file is indeed inconsistent. But I don't see any value in declaring the file "invalid" (and as a general rule there's probably not much value in declaring a file "invalid" because of an inconsistency between two ancillary chunks). Applications can choose to obey either srGB or gAMA/cHRM, and we can recommend that srGB take precedence. We can change the sentence, though, to read Applications that recognize the srGB chunk and are capable of processing the ICC sRGB profile should ignore the gAMA and cHRM chunks and process the srGB chunk instead. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 25 14:01:53 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id OAA00923 for ; Wed, 25 Sep 1996 14:01:50 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA12063 for png-list-outgoing; Wed, 25 Sep 1996 14:00:04 -0500 Received: from mail.Clark.Net (mail.clark.net [168.143.0.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA12053 for ; Wed, 25 Sep 1996 13:59:56 -0500 Received: from glenc (glenc.clark.net [168.143.4.56]) by mail.Clark.Net (8.7.3/8.6.5) with SMTP id OAA01760 for ; Wed, 25 Sep 1996 14:59:45 -0400 (EDT) Message-Id: <199609251859.OAA01760@mail.Clark.Net> Comments: Authenticated sender is From: "Glen Chapman" To: png-list@dworkin.wustl.edu Date: Wed, 25 Sep 1996 15:03:51 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: sRGB proposed chunk Priority: normal X-mailer: Pegasus Mail for Win32 (v2.42) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > Date: Wed, 25 Sep 1996 10:28:14 -0700 > To: PNG List > From: John Bowler > Subject: Re: sRGB proposed chunk > Reply-to: PNG List John Bowler says: > Win32 is the name of a specific API which supports color management (via the > ICM APIs) and with which I am familiar. "MS Windows" is a generic name used > for an number of OS environments, some of which support Win32 - but only > Win32 supports color management. At this point the ICM API is only supported in Windows 95. MS says its going to be in NT at some point but as of NT 4.0 its not present. glen ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 25 14:20:24 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id OAA01029 for ; Wed, 25 Sep 1996 14:20:12 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA12340 for png-list-outgoing; Wed, 25 Sep 1996 14:18:21 -0500 Received: from dawn13.CS.Berkeley.EDU (dawn13.CS.Berkeley.EDU [128.32.38.57]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA12335 for ; Wed, 25 Sep 1996 14:18:16 -0500 Received: (from amc@localhost) by dawn13.CS.Berkeley.EDU (8.6.11/8.6.9) id LAA00559 for png-list@dworkin.wustl.edu; Wed, 25 Sep 1996 11:46:32 -0700 Date: Wed, 25 Sep 1996 11:46:32 -0700 Message-Id: <199609251846.LAA00559@dawn13.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: New chunk registration procedure 19960924 From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson ARL-WMRD-TED-TIB says: > I think we can stop tinkering with it now and just let it simmer for a > while. Alas, not quite. > Appendix 1 gives the recommended format for a call for votes. There is no Appendix 1. > The subject of the message must contain the word "VOTE" (in > uppercase letters), the word "YES" or "NO" or "ABSTAIN" (in > uppercase letters), and the name of the proposal being voted upon. > The string "Re:" must not not appear in the subject. An example > of a correctly formatted subject line is > > Subject: VOTE on cNEW 19991231. The example is not consistent with the spec. I think you forgot to remove the YES/NO/ABSTAIN from the spec. In the example call for votes: > Subject: VOTE on CNEW 19991231 > > YES > cNEW 19991231 > ftp://swrinde.nde.swri.edu/pub/png-group/documents > png-proposed-chunks-19991231 > My Name You forgot the email address on the line with My Name. > YES | NO | ABSTAIN > cNEW 19991231 > ftp://swrinde.nde.swri.edu/pub/png-group/documents > png-proposed-chunks-19991231 > Your Name Same thing. > The voting period closes exactly two weeks after the time > that this message or any earlier YES vote on this proposal > was received by the png-list server (dworkin@wustl.edu) png-list@dworkin.wustl.edu Finally, I notice that in some cases, the Date field is the date that counts, whereas in other cases, the time it was received by dworkin is what counts. That's fine, but there are several cases where it's not specified, like in the message that begins the discussion period, and messages that establish voter elligibility. I think the easiest way to fix this would be to declare a default: pick either the Date field or the Received time as the time that counts except where otherwise indicated. Should it be stated somewhere that the entire spec assumes that everyone is honest, that no one is forging header fields? Or does that go without saying? AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 25 15:22:09 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id PAA01545 for ; Wed, 25 Sep 1996 15:22:08 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA13409 for png-list-outgoing; Wed, 25 Sep 1996 15:20:05 -0500 Received: from tide21.microsoft.com (tide21.microsoft.com [131.107.3.31]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id PAA13402 for ; Wed, 25 Sep 1996 15:19:58 -0500 Received: by tide21.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBAAE4.9235DED0@tide21.microsoft.com>; Wed, 25 Sep 1996 13:22:16 -0700 Message-ID: From: John Bowler To: "'PNG List'" Subject: RE: sRGB proposed chunk Date: Wed, 25 Sep 1996 13:19:51 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 43 TEXT Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >From: John Bowler[SMTP:jbowler@acm.org] > >At 09:25 25/09/96 EDT, you wrote: "you" is Glenn - Eudora likes to send second person replies :-) > >>Just to clarify, we can add the following line to the end of the >>srGB writeup (paragraph 4.4 in the 19960914 version of the >>png-proposed-chunks document). >> >> ICC-profile-aware applications should ignore the gAMA and >> cHRM chunks and process the srGB chunk instead. > >Unfortunately there are already ICC-profile-aware applications which handle >PNG data (and, in particular, handle cHRM and gAMA) but do not recognize the >sRGB chunk. This is slightly inaccurate, since the application I was thinking of is actually aware of the sRGB spec but does not handle embedded ICC profiles within bitmaps. In a later message from Glenn:- Applications that recognize the srGB chunk and are capable of processing the ICC sRGB profile should ignore the gAMA and cHRM chunks and process the srGB chunk instead. This removes the confusion - the requirement on the application is to recognize srGB, not to be "ICC-profile-aware". I said:- > >Of the three possible resolutions (invalid, cHRM/gAMA take precedence and >sRGB takes precedence) this is the one which is most misleading. It's not misleading with the modified wording - this distinguishes understanding of the chunk from understanding of the sRGB specification. Also neither of the other two possibilities really work, because the srGB chunk actually has more gamma and end point information than can be encoded in gAMA or cHRM, so an app would have to test for equality of gAMA/cHRM with the sRGB values then use the sRGB coefficients if a match was found - no one would do this in practice, so the only workable solution is for srGB to take precedence. John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 25 15:43:13 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id PAA01815 for ; Wed, 25 Sep 1996 15:43:12 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA14112 for png-list-outgoing; Wed, 25 Sep 1996 15:41:30 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id PAA14106 for ; Wed, 25 Sep 1996 15:41:24 -0500 Date: Wed, 25 Sep 96 16:38:09 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New chunk registration procedure 19960924 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609251638.aa03180@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Wed, 25 Sep 1996 11:46:32 -0700 }Subject: Re: New chunk registration procedure 19960924 }From: "Adam M. Costello" }Glenn Randers-Pehrson ARL-WMRD-TED-TIB says: } }> I think we can stop tinkering with it now and just let it simmer for a }> while. } }Alas, not quite. } blush }> Appendix 1 gives the recommended format for a call for votes. } }There is no Appendix 1. ok 9. Appendix 1: Sample call for votes } }> The subject of the message must contain the word "VOTE" (in }> uppercase letters), the word "YES" or "NO" or "ABSTAIN" (in }> uppercase letters), and the name of the proposal being voted upon. }> The string "Re:" must not not appear in the subject. An example }> of a correctly formatted subject line is }> }> Subject: VOTE on cNEW 19991231. } }The example is not consistent with the spec. I think you forgot to }remove the YES/NO/ABSTAIN from the spec. right } }In the example call for votes: }> My Name } }You forgot the email address on the line with My Name. No, I forgot to change the angle brackets to the "<" form. } }> Your Name } }Same thing. same thing } }> The voting period closes exactly two weeks after the time }> that this message or any earlier YES vote on this proposal }> was received by the png-list server (dworkin@wustl.edu) } }png-list@dworkin.wustl.edu ok, no excuse for that one. } }Finally, I notice that in some cases, the Date field is the date that }counts, whereas in other cases, the time it was received by dworkin is }what counts. Date is only used to sort multiple votes from an individual. I'll add a clarifying paragraph (you tell me if it clarifies rather than muddying the water....) 7. Time Stamps The "Received:" field generated by the png-list server is used to determine the exact times of the the beginning of the discussion period and the voting period, the close of the voting period, and for all other timing purposes except that the sender's "Date:" field is used to determine the order of precedence of multiple votes from the same person. }Should it be stated somewhere that the entire spec assumes that everyone }is honest, that no one is forging header fields? Or does that go }without saying? If it doesn't go without saying, then how about: 6. Franchise Any person is eligible to vote who has: * Submitted their first (or any subsequent) message received by the png-list server at least 180 days before the termination of the voting period. * Not forged a vote or cheated in any other manner in any previous vote conducted under this specification. Cheating will not be tolerated. } }AMC } }------------------------------------------------------------ }To find out more about the mailing list server, send mail to }png-list-request@dworkin.wustl.edu }with the word "help" (and nothing else) in the message body. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 25 15:53:29 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id PAA01942 for ; Wed, 25 Sep 1996 15:53:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA14385 for png-list-outgoing; Wed, 25 Sep 1996 15:51:30 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id PAA14376 for ; Wed, 25 Sep 1996 15:51:25 -0500 Date: Wed, 25 Sep 96 16:46:05 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: sRGB proposed chunk Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609251646.aa04514@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List }In a later message from Glenn:- } } Applications that recognize the srGB chunk and are capable of } processing the ICC sRGB profile should ignore the gAMA and } cHRM chunks and process the srGB chunk instead. } That was still not quite right; it suggests that gAMA should be ignored even when srGB is not present, which is quite wrong... I now have: When the srGB chunk is present, applications that recognize the srGB chunk and are capable of processing the ICC sRGB profile should ignore the gAMA and cHRM chunks and process the srGB chunk instead. tom lane's suggested: If a file containing an sRGB chunk has gAMA and/or cHRM chunks with values other than those given here, the file is incorrect. In such a case it is recommended that sRGB-aware decoders use the sRGB values and ignore the gAMA and cHRM chunks. tom's looks fine too, except I might say "inconsistent" instead of "incorrect". In a MNG context a file could easily end up having a gamma=50000 instead of 45000 when it inherits gAMA from another image, or in the normal PNG context if a non-srgb-aware editor looks at the file, says "woops, no gamma; I'll fix that." If we use my version, then there's not even any inconsistency to deal with because the gAMA/cHRM with the inconsistent values are ignored and the decoder won't be aware of it. There's another issue, though. What about a decoder that cannot fully handle the ICC color profiles, but does do gamma and chrm, that encounters a file with sRGB but no gAMA and cHRM (despite our advice). I would think that a reasonable thing to do would be to treat the file as if it did indeed have gAMA and cHRM chunks with the srgb-consistent values. Should we say so in the spec? ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 25 16:22:29 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA02273 for ; Wed, 25 Sep 1996 16:22:26 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA15097 for png-list-outgoing; Wed, 25 Sep 1996 16:20:31 -0500 Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA15092 for ; Wed, 25 Sep 1996 16:20:27 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by wugate.wustl.edu (8.7.5/8.7.3) with ESMTP id QAA18542 for ; Wed, 25 Sep 1996 16:20:53 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id OAA06907 for ; Wed, 25 Sep 1996 14:11:49 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id OAA23053 for png-list@dworkin.wustl.edu; Wed, 25 Sep 1996 14:11:48 -0700 (PDT) Message-Id: <199609252111.OAA23053@web1.calweb.com> Subject: Re: sRGB proposed chunk To: png-list@dworkin.wustl.edu Date: Wed, 25 Sep 1996 14:11:48 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <9609251646.aa04514@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 25, 96 04:46:05 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > tom's looks fine too, except I might say "inconsistent" > instead of "incorrect". In a communication standard, inconsistency or ambiguity of any kind is unacceptable, so "incorrect" is a good term. Even better would be "invalid", and I would recommend that such a file should even produce a warning to the user to give him the opportunity to fix the file. In a communication standard, it is impossible to be too strict in what one is allowed to transmit; laxity in the receiver end is forgiveable, but even then I think it would be a mistake for the standard document itself to imply that any laxity exists. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 25 19:21:49 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id TAA04512 for ; Wed, 25 Sep 1996 19:21:47 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA17594 for png-list-outgoing; Wed, 25 Sep 1996 19:21:33 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id TAA17589 for ; Wed, 25 Sep 1996 19:21:29 -0500 Date: Wed, 25 Sep 96 20:15:56 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: sRGB proposed chunk Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609252015.aa05802@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Subject: Re: sRGB proposed chunk }Date: Wed, 25 Sep 1996 14:11:48 -0700 (PDT) }From: Lee Daniel Crocker }> tom's looks fine too, except I might say "inconsistent" }> instead of "incorrect". } }In a communication standard, inconsistency or ambiguity of any }kind is unacceptable, so "incorrect" is a good term. Even better }would be "invalid", and I would recommend that such a file should }even produce a warning to the user to give him the opportunity to }fix the file. I have a real problem with this, where a png editor can perform a perfectly legal operation on a legal png file and create a new png file that is deemed "invalid" by some all-knowing decoder: The legal file is one with srGB and no gAMA or cHRM. The editor does not recognize srGB and simply copies it, in accordance with the chunk copying rules, and installs gAMA and cHRM which look appropriate but (following the advice in PNG 1.0), sets gAMA to 50000 instead of the mandated 45000. But if our rule for using sRGB is a: ignore gAMA and cHRM if you are going to process srGB b: ignore sRGB otherwise then there's no ambiguity or even any apparent inconsistency. I guess "processing srGB" could mean either reconstructing the entire sRGB profile and using it, or it could just mean setting gamma=50000 and cHRM data to the srGB values and proceeding as though it had read them from gAMA and cHRM chunks. } }In a communication standard, it is impossible to be too strict }in what one is allowed to transmit; laxity in the receiver end }is forgiveable, but even then I think it would be a mistake for }the standard document itself to imply that any laxity exists. That philosophy certainly applies to the format of the chunks but does it necessarily also apply to their interpretation? ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 25 19:47:37 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id TAA04777 for ; Wed, 25 Sep 1996 19:47:33 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA17763 for png-list-outgoing; Wed, 25 Sep 1996 19:47:30 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA17758 for ; Wed, 25 Sep 1996 19:47:25 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id RAA14288 for ; Wed, 25 Sep 1996 17:40:22 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id RAA25950 for png-list@dworkin.wustl.edu; Wed, 25 Sep 1996 17:40:22 -0700 (PDT) Message-Id: <199609260040.RAA25950@web1.calweb.com> Subject: Re: sRGB proposed chunk To: png-list@dworkin.wustl.edu Date: Wed, 25 Sep 1996 17:40:21 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <9609252015.aa05802@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 25, 96 08:15:56 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > }In a communication standard, inconsistency or ambiguity of any > }kind is unacceptable, so "incorrect" is a good term. Even better > }would be "invalid", and I would recommend that such a file should > }even produce a warning to the user to give him the opportunity to > }fix the file. > > I have a real problem with this, where a png editor can perform > a perfectly legal operation on a legal png file and create a new > png file that is deemed "invalid" by some all-knowing decoder: > > The legal file is one with srGB and no gAMA or cHRM. > The editor does not recognize srGB and simply copies it, in accordance > with the chunk copying rules, and installs gAMA and cHRM which look > appropriate but (following the advice in PNG 1.0), sets gAMA to 50000 > instead of the mandated 45000. Damn. You're right, that's a problem. I guess, then, that we'll have to interpret gAMA and cHRM as "crude estimates" of srGB when the latter is present--i.e. the decoder will use gAMA/cHRM if it only knows those, but perfer srGB if it can. And define that srGB is always presumed to take precedence. > }In a communication standard, it is impossible to be too strict > }in what one is allowed to transmit; laxity in the receiver end > }is forgiveable, but even then I think it would be a mistake for > }the standard document itself to imply that any laxity exists. > > That philosophy certainly applies to the format of the chunks but > does it necessarily also apply to their interpretation? Absolutely, when possible. This time it wasn't possible. After all, the "interpretation" of the chunks is precisely the thing that we are trying to communicate. It's OK for a reader to make concessions for its hardware and such, but the spec itself should be completely unambiguous as to the intent of the writer, so that a more capable reader can reproduce that intent more closely. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Wed Sep 25 23:10:41 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id XAA05808 for ; Wed, 25 Sep 1996 23:10:40 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA21432 for png-list-outgoing; Wed, 25 Sep 1996 23:10:28 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id XAA21415 for ; Wed, 25 Sep 1996 23:10:15 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id AAA18738 for ; Thu, 26 Sep 1996 00:10:04 -0400 (EDT) To: PNG List Subject: Re: sRGB proposed chunk In-reply-to: Your message of Wed, 25 Sep 1996 17:40:21 -0700 (PDT) <199609260040.RAA25950@web1.calweb.com> Date: Thu, 26 Sep 1996 00:10:04 -0400 Message-ID: <18736.843711004@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn says: >> I have a real problem with this, where a png editor can perform >> a perfectly legal operation on a legal png file and create a new >> png file that is deemed "invalid" by some all-knowing decoder: >> The legal file is one with srGB and no gAMA or cHRM. This strikes me as a good argument for *requiring*, not merely suggesting, that an encoder that writes srGB also write gAMA and cHRM with the appropriate values. If this is done then the risk seems fairly small; to get to an inconsistent file you need to assume that the file has previously passed through a PNG editor that discards gAMA and cHRM but not srGB. It's fairly unlikely that an editor would discard known chunks but keep unknown ones. Lee says: > we'll have to interpret gAMA and cHRM as "crude estimates" of srGB when > the latter is present--i.e. the decoder will use gAMA/cHRM if it > only knows those, but perfer srGB if it can. And define that srGB > is always presumed to take precedence. I think we're all saying the same thing in different ways: if both srGB and gAMA/cHRM are present, an srGB-aware decoder should believe srGB in preference to the others. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 05:49:08 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id FAA08233 for ; Thu, 26 Sep 1996 05:49:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA25571 for png-list-outgoing; Thu, 26 Sep 1996 05:48:41 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id FAA25566 for ; Thu, 26 Sep 1996 05:48:38 -0500 Date: Thu, 26 Sep 96 6:47:57 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: sRGB proposed chunk Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609260647.aa09027@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Subject: Re: sRGB proposed chunk }Date: Thu, 26 Sep 1996 00:10:04 -0400 }Message-ID: <18736.843711004@sss.pgh.pa.us> }From: Tom Lane }Glenn says: }>> I have a real problem with this, where a png editor can perform }>> a perfectly legal operation on a legal png file and create a new }>> png file that is deemed "invalid" by some all-knowing decoder: }>> The legal file is one with srGB and no gAMA or cHRM. } }This strikes me as a good argument for *requiring*, not merely }suggesting, that an encoder that writes srGB also write gAMA and cHRM }with the appropriate values. If this is done then the risk seems }fairly small; to get to an inconsistent file you need to assume that }the file has previously passed through a PNG editor that discards gAMA }and cHRM but not srGB. It's fairly unlikely that an editor would }discard known chunks but keep unknown ones. But not so unlikely that it would change 45000 to 50000 or (see below) 45455. } }Lee says: }> we'll have to interpret gAMA and cHRM as "crude estimates" of srGB when }> the latter is present--i.e. the decoder will use gAMA/cHRM if it }> only knows those, but perfer srGB if it can. And define that srGB }> is always presumed to take precedence. gAMA 45000 *is* a crude estimate. The proposed sRGB profile described in the stokes document uses gamma=1/2.2, which is .454545... or gAMA 45455 Chris L or Dave M, please respond. } }I think we're all saying the same thing in different ways: if both }srGB and gAMA/cHRM are present, an srGB-aware decoder should believe }srGB in preference to the others. Yes we are, and if there's no objection we'll use this: When the srGB chunk is present, applications that recognize the srGB chunk and are capable of processing the ICC sRGB profile should ignore the gAMA and cHRM chunks and process the srGB chunk instead. Applications that recognize the srGB chunk but are not capable of processing the full sRGB profile data can also ignore any gAMA and cHRM chunks and instead use the values of gAMA and cHRM given above as though they had appeared in gAMA and cHRM chunks. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 06:03:02 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id GAA08275 for ; Thu, 26 Sep 1996 06:03:01 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id GAA25670 for png-list-outgoing; Thu, 26 Sep 1996 06:02:51 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id GAA25665 for ; Thu, 26 Sep 1996 06:02:48 -0500 Date: Thu, 26 Sep 96 7:00:54 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New chunk registration procedure 19960924 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609260700.aa09069@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Adam asked: } }}Should it be stated somewhere that the entire spec assumes that everyone }}is honest, that no one is forging header fields? Or does that go }}without saying? } I responded }If it doesn't go without saying, then how about: } }6. Franchise } } Any person is eligible to vote who has: } } * Submitted their first (or any subsequent) message received by } the png-list server at least 180 days before the termination of } the voting period. } * Not forged a vote or cheated in any other manner in any } previous vote conducted under this specification. Cheating will } not be tolerated. Leaves kind of a sour taste. Maybe a better idea: 6. Franchise Any person is eligible to vote who has: * Submitted their first (or any subsequent) message received by the png-list server at least 180 days before the termination of the voting period. * Not voted on the same matter the during the present voting period using a different name or e-mail address on the fifth line of the vote message. 10. Security considerations This process depends upon the integrity of the persons involved. We have no reason to believe that other measures are required. In the event of a prank or fraudulent vote, we will deal with it harshly, outside the scope of this process. This process depends upon the continued availability of the png-list server and its connection to the Internet. We will deal with system failure on a case-by-case basis, outside the scope of this process. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 06:09:27 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id GAA08323 for ; Thu, 26 Sep 1996 06:09:19 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id GAA25712 for png-list-outgoing; Thu, 26 Sep 1996 06:09:08 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id GAA25706 for ; Thu, 26 Sep 1996 06:09:06 -0500 Date: Thu, 26 Sep 96 7:07:02 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: sRGB proposed chunk Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609260707.aa09170@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List } }Yes we are, and if there's no objection we'll use this: } } When the srGB chunk is present, applications that recognize the } srGB chunk and are capable of processing the ICC sRGB profile } should ignore the gAMA and cHRM chunks and process the srGB chunk } instead. Applications that recognize the srGB chunk but are not } capable of processing the full sRGB profile data can also ignore } any gAMA and cHRM chunks and instead use the values of gAMA and } cHRM given above as though they had appeared in gAMA and cHRM chunks. or for you lawyers who worry about whether the "when..." clause binds to the second sentence: When the srGB chunk is present, applications that recognize the srGB chunk and are capable of processing the ICC sRGB profile should ignore the gAMA and cHRM chunks and process the srGB chunk instead. Applications that recognize the srGB chunk but are not capable of processing the full sRGB profile data can also ignore any gAMA and cHRM chunks when the sRGB chunk is present, and instead use the values of gAMA and cHRM given above as though they had appeared in gAMA and cHRM chunks. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 07:49:57 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id HAA09383 for ; Thu, 26 Sep 1996 07:49:57 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA26453 for png-list-outgoing; Thu, 26 Sep 1996 07:49:48 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id HAA26448 for ; Thu, 26 Sep 1996 07:49:46 -0500 Date: Thu, 26 Sep 96 8:47:11 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New chunk registration procedure 19960924 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609260847.aa11469@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List 4.4. Termination [...] The voting period also ceases immediately and the proposal is rejected if all YES votes are countermanded by NO or ABSTAIN votes I think we need to get rid of this paragraph. It's just too tempting: ===================== Received: 03:17:20 YES dRNG ... this is the call for votes on dRNG etc. ===================== Received: 03:17:22 NO dRNG ... Never mind, I have had second thoughts on this. See you again in 180 days. ===================== Better to just let the vote die at the end of the two weeks, or sooner if a competing proposal is approved. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 10:38:11 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id KAA11703 for ; Thu, 26 Sep 1996 10:38:00 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA29104 for png-list-outgoing; Thu, 26 Sep 1996 10:35:07 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id KAA29084 for ; Thu, 26 Sep 1996 10:33:29 -0500 Date: Thu, 26 Sep 96 11:30:34 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New chunk registration procedure 19960924 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609261130.aa16079@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List We have to say something about prematurely cast votes. Do we need to say, at the end of the "Initiation" section: Any votes received prematurely will not be counted. or should we say Any votes received prematurely will be treated as though they had been received immediately after the close of the two-week discussion period, in the order they were actually received. Such votes will be voided in the event that the discussion period is restarted. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 10:44:44 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id KAA11762 for ; Thu, 26 Sep 1996 10:44:33 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA29270 for png-list-outgoing; Thu, 26 Sep 1996 10:44:20 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id KAA29265 for ; Thu, 26 Sep 1996 10:44:11 -0500 Date: Thu, 26 Sep 96 11:39:14 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: Glenn Randers-Pehrson ARL-WMRD-TED-TIB cc: PNG List Subject: Re: New chunk registration procedure 19960924 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609261139.aa16633@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I wrote: } }We have to say something about prematurely cast votes. } }Do we need to say, at the end of the "Initiation" section: } }Any votes received prematurely will not be counted. } [alternative] Never mind, the alternative is inconsistent with "This message must not be received... before two weeks have elapsed..." ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 10:53:56 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id KAA11998 for ; Thu, 26 Sep 1996 10:53:50 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA29392 for png-list-outgoing; Thu, 26 Sep 1996 10:52:11 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA29383 for ; Thu, 26 Sep 1996 10:51:47 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id LAA19563 for ; Thu, 26 Sep 1996 11:51:39 -0400 (EDT) To: PNG List Subject: Re: New chunk registration procedure 19960924 In-reply-to: Your message of Thu, 26 Sep 96 11:30:34 EDT <9609261130.aa16079@THOR.ARL.MIL> Date: Thu, 26 Sep 1996 11:51:38 -0400 Message-ID: <19561.843753098@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > We have to say something about prematurely cast votes. I was wondering about this last night. The only plausible scenario for allowing premature votes is this: "I'm going to Bora Bora for a month, but I want to vote for cNEW which I expect Jane will call for a vote on next week. So here's my vote." The trouble with accepting such votes is that the departed voter will not see any subsequent discussion (later in the discussion period, or during the actual vote period). Perhaps he would've changed his vote if he'd been more fully informed. And the whole point of requiring a waiting period before a call for votes is to ensure fully informed, well-thought-out votes. Accepting premature votes undercuts this goal. So I'd say that votes sent before a valid call-for-votes is issued should be rejected. If you're not around during the voting period, tough luck. regards, tom lane PS: of course, there's always "cron" ... ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 12:14:12 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id MAA12696 for ; Thu, 26 Sep 1996 12:13:04 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA00840 for png-list-outgoing; Thu, 26 Sep 1996 12:10:57 -0500 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA00833 for ; Thu, 26 Sep 1996 12:10:49 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id KAA19432 for ; Thu, 26 Sep 1996 10:10:20 -0700 X-Sender: davem@mail.cs.ubc.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Sep 1996 10:10:26 -0700 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: Re: sRGB proposed chunk Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: >gAMA 45000 *is* a crude estimate. The proposed sRGB profile described >in the stokes document uses gamma=1/2.2, which is .454545... or gAMA 45455 > >Chris L or Dave M, please respond. I haven't looked at the "stokes document" directly, but in Chris Lilley's message of Sept 25 he quotes: Transfer Characteristic for i=r,g,b if i <= 0.00304, i' = 12.92 * i else i' = 1.055* (i^(1/2.4)) - 0.055 I've graphed this, and it's an amazingly close fit to a simple power function with an exponent (gamma) of 0.45000. The sRGB transfer function uses the multiply by 1.055 and the subtraction of 0.055 to "splice" the straight-line and power-function parts of the curve together, but the multiply by 1.055 also changes the shape of the power-function portion of the curve. The change in exponent from 1/2.2222 (0.45) to 1/2.4 (0.41667) mostly compensates for this, resulting in a function that very closely tracks the simple y = x^0.45 power function. So gAMA of 45000 is indeed quite an accurate approximation to the sRGB transfer function, and closer than 41667, which is I think what Glenn meant (since Stokes uses 1/2.4, not 1/2.2). The difference between a gAMA of 45000 and gAMA of 45455 are extremely small. A power function with a gamma of .45 fits sRGB slightly better for intensities of about mid-grey and above, while .454545 fits sRGB slightly better below that point. But really, nobody is likely to see the difference between these two. 45000 is simpler and will look familiar to people, so I suggest we leave that as the recommendation. > When the srGB chunk is present, applications that recognize the > srGB chunk and are capable of processing the ICC sRGB profile > should ignore the gAMA and cHRM chunks and process the srGB chunk > instead. Applications that recognize the srGB chunk but are not > capable of processing the full sRGB profile data can also ignore > any gAMA and cHRM chunks and instead use the values of gAMA and > cHRM given above as though they had appeared in gAMA and cHRM chunks. That sounds good. Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 12:50:40 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id MAA12992 for ; Thu, 26 Sep 1996 12:50:37 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA01415 for png-list-outgoing; Thu, 26 Sep 1996 12:48:40 -0500 Received: from mega.megamed.com ([199.4.114.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA01410 for ; Thu, 26 Sep 1996 12:48:32 -0500 Received: from coruisk (mega207.megamed.com [199.4.114.207]) by mega.megamed.com (8.7.5/8.7.3) with SMTP id KAA08586 for ; Thu, 26 Sep 1996 10:47:33 -0700 Date: Thu, 26 Sep 1996 10:47:33 -0700 Message-Id: <199609261747.KAA08586@mega.megamed.com> X-Sender: jbowler@megamed.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: John Bowler Subject: Re: New chunk registration procedure 19960924 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 11:51 26/09/96 -0400, Tom wrote: >The only plausible scenario for allowing premature votes is this: >"I'm going to Bora Bora for a month, but I want to vote for cNEW >which I expect Jane will call for a vote on next week. So here's >my vote." ... > >PS: of course, there's always "cron" ... All this talk of possible abuses of the system and the clever and ingenious methods by which they can be prevented seems, to me, to be over much paranoid. Either the abuse/error/naivety is in keeping with the concensus of the discussion, in which case it makes no difference, or it creates a conflict or lack of concensus where before there *seemed* to be a concensus. The latter is, I feel, merely stating the truth :-) The aim is to establish concensus. If large scale abuse occurs we have a problem - I don't expect this. If errors or foolish use of cron (or crontab, or at, or asking one's SO to push the return key in the middle of next week) occur then they are unlikely to remain unfixed for long, or to affect the final output. I wouldn't want this process to suffer death by application of rules. John Bowler (jbowler@acm.org) See also: http://www.arts.ucsb.edu/bodiesinc/ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 12:53:00 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id MAA13007 for ; Thu, 26 Sep 1996 12:52:02 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA01454 for png-list-outgoing; Thu, 26 Sep 1996 12:51:50 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA01445 for ; Thu, 26 Sep 1996 12:51:14 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id NAA21248 for ; Thu, 26 Sep 1996 13:51:05 -0400 (EDT) To: PNG List Subject: Re: New chunk registration procedure 199609245 In-reply-to: Your message of Wed, 25 Sep 96 11:56:19 EDT <9609251156.aa15108@THOR.ARL.MIL> Date: Thu, 26 Sep 1996 13:51:04 -0400 Message-ID: <21243.843760264@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Some comments on the third draft: > 3. Prerequisites > The proposal must > be in a final publishable format, such as that of the PNG 1.0 > specification and PNG extensions documents found in > ftp://swrinde.nde.swri.edu/pub/png-group/documents/. I think it's the editors' job to reduce text to publishable form. Requiring proposals to be HTML or whatever just distracts people from getting the technical content right. How about "The proposal must include the complete proposed specification text for the chunk(s)", but no specific requirements as to format. > Note that the names of all formally registered chunks will > either appear in the PNG specification or in the PNG extensions > document. ... or at least in a document referenced by the PNG extensions document. > * Throughout the two-week voting period the specification must > remain absolutely unchanged. The two-week discussion period > must be restarted upon making any change to the proposed > specification, except for > * Simple formatting, grammatical, or spelling changes. > * A printing date or authorship change. > Upon the objection of any voter, received by the png-list > server prior to the call for votes, the two-week discussion > period must be restarted in the event of any such change. "Prior to the call for votes" is no good. Unless the proponent actually jumps the gun, there would be no reason to make such an objection. How about replacing this item with: * A call for votes cannot be issued until the proposed specification has remained unchanged for at least two weeks. However, exceptions will be made for trivial changes, such as: * Simple formatting, grammatical, or spelling changes. * A printing date or authorship change. A call may be issued after two weeks have elapsed with no nontrivial changes. If there is any dispute as to whether a change is nontrivial, any eligible voter may object to the call for votes. In such case the vote is cancelled, and the call must be re-issued two weeks after the disputed change. > After the two-week discussion period, the vote is initiated by any > person submitting the first YES vote on an identified > specification. This message also serves as the call for votes. > There is no provision for issuing a call for votes without also > voting YES at the same time. I don't much care for this. I would like calls for votes to be clearly identifiable as such from the subject line. If there is already a vote or two in process, one has to look closely to notice that "VOTE for cXYZ" actually is a new call for votes and not just another vote for cYYZ whose vote started last week. I think posting a separate "CALL FOR VOTES on cNEW" message is a better idea, and the overhead is really pretty minimal. You could certainly take it as an implied YES if you like, but it should be easily identifiable as a vote initiation message rather than just another vote. > the first five lines of the message > must conform to the following format: > {YES|NO|ABSTAIN} > > > > Name If a prior CALL FOR VOTES message has identified the specification to be voted on, it's probably not really necessary to make each voter repeat this info. YES/NO/ABSTAIN and the chunk name(s) ought to be sufficient. > A chunk specification is approved if both of the following conditions > are met at the end of the voting period: > * Ten YES votes are received. "At least ten..." > The same chunk cannot be brought up again for another discussion > period and vote until either a 180-day waiting period has elapsed, to > allow for implementation and testing, or until a substantial change > to the specification is made. I'm not sure that I like this. I could see people insisting on a new vote every six months whether anything had changed or not. Also, there could be quibbles about whether a change to the spec was "substantial" enough to merit a revote. My first thought on how to fix it was: A chunk proposal that has failed may not be brought up for re-vote unless at least two voters who voted NO for it agree that a re-vote is appropriate. But this has its own semi-trailer-sized loopholes. (Eg, chunk is about to fail 7:3. Two proponents change their votes to NO just before close of voting. Now they can force an immediate revote.) I would like to see the spec say that revotes will be taken only if either the chunk spec itself or outside conditions have changed significantly, and get rid of any strictly time-based criterion. But I don't know how to define this. Maybe we just have to depend on proponents to be reasonable people. In a later message Glenn suggests: > * Not voted on the same matter the during the present voting period > using a different name or e-mail address on the fifth line of the > vote message. I think this is unnecessary given the proposed section 10: > 10. Security considerations > > This process depends upon the integrity of the persons involved. > We have no reason to believe that other measures are required. In > the event of a prank or fraudulent vote, we will deal with it > harshly, outside the scope of this process. > > This process depends upon the continued availability of the png-list > server and its connection to the Internet. We will deal with system > failure on a case-by-case basis, outside the scope of this process. which I agree with. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 13:14:59 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA13278 for ; Thu, 26 Sep 1996 13:14:49 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA01785 for png-list-outgoing; Thu, 26 Sep 1996 13:13:08 -0500 Received: from mega.megamed.com (megamed.com [199.4.114.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA01655 for ; Thu, 26 Sep 1996 13:06:21 -0500 Received: from coruisk (mega207.megamed.com [199.4.114.207]) by mega.megamed.com (8.7.5/8.7.3) with SMTP id LAA09445 for ; Thu, 26 Sep 1996 11:06:07 -0700 Date: Thu, 26 Sep 1996 11:06:07 -0700 Message-Id: <199609261806.LAA09445@mega.megamed.com> X-Sender: jbowler@megamed.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: John Bowler Subject: Re: sRGB proposed chunk Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 06:47 26/09/96 EDT, Glenn wrote: > >gAMA 45000 *is* a crude estimate. The proposed sRGB profile described >in the stokes document uses gamma=1/2.2, which is .454545... or gAMA 45455 There seem to be two equations given in the document to justify the 1.13 system gamma. One uses a monitor gamma of 2.5 and a camera gamma of 1/2.22, the other uses 2.2 and 1/1.95 respectively. The explanation of these numbers is unclear, but I think that the 2.5/2.22 pair refer to the powers in the transfer functions, whereas 2.2/1.95 takes into account the electronic biases in a video system (2.5->2.2) and the best approximation to the Rec 709 transfer function which can be obtained using a power law (1.95 in the document, my calculations suggest 1.934). In any case it is not clear to me that setting gAMA to 0.45 on the basis of the 0.45 in Rec 709 is better than setting gAMA to 0.5 on the basis that this is actually the best fit to the Rec709 transfer function. The very fact that the best fit is 0.5 while the number in the spec is 0.45 probably indicates that it doesn't matter very much - certainly much much bigger changes can be obtained by simply switching off the lights in the room where the image is viewed. John Bowler (jbowler@acm.org) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 13:27:45 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA13310 for ; Thu, 26 Sep 1996 13:26:50 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA02008 for png-list-outgoing; Thu, 26 Sep 1996 13:25:33 -0500 Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA01992 for ; Thu, 26 Sep 1996 13:25:27 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by wugate.wustl.edu (8.7.5/8.7.3) with SMTP id NAA10829 for ; Thu, 26 Sep 1996 13:24:22 -0500 Date: Thu, 26 Sep 96 14:17:26 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: sRGB proposed chunk Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609261417.aa20161@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Thu, 26 Sep 1996 10:10:26 -0700 }From: Dave Martindale }Subject: Re: sRGB proposed chunk }Glenn writes: }>gAMA 45000 *is* a crude estimate. The proposed sRGB profile described }>in the stokes document uses gamma=1/2.2, which is .454545... or gAMA 45455 }> }>Chris L or Dave M, please respond. } }I haven't looked at the "stokes document" directly, but in Chris Lilley's }message of Sept 25 he quotes: } } Transfer Characteristic for i=r,g,b } if i <= 0.00304, i' = 12.92 * i } else i' = 1.055* (i^(1/2.4)) - 0.055 By golly, that's right. The "stokes document" talks about using gamma=2.2 in the text, but in the equations (inline images, rendered illegibly by ghostview) do say 2.4 when printed out on a good printer. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 13:46:04 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA13433 for ; Thu, 26 Sep 1996 13:46:02 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA02463 for png-list-outgoing; Thu, 26 Sep 1996 13:45:43 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id NAA02455 for ; Thu, 26 Sep 1996 13:45:30 -0500 Date: Thu, 26 Sep 96 14:44:21 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: png-list@dworkin.wustl.edu Subject: New chunk registration process 19960926 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609261444.aa21334@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List This corrects the errors that Adam pointed out and makes some other minor clarifications. The Security considerations section is added. Any more tinkering needed? ../glennrp png-registration-19960926 Thu Sep 26 14:30:23 EDT 1996 --------------cut here--------------- PNG-GROUP-DRAFT PNG Development Group PNG-Registration png-list@dworkin.wustl.edu Expires: 26 Mar 1997 26 Sep 1996 PNG Chunk Registration Process, draft 19960926 File png-registration-19960926.txt Status of this Memo This document is an informal draft of the PNG development group. Comments on this document can be sent to the PNG specification maintainers at png-info@uunet.uu.net or at png-group@w3.org. Distribution of this memo is unlimited. At present, the latest version of this document is available on the World Wide Web from ftp://swrinde.nde.swri.edu/pub/png- group/documents/. Notices Copyright (c) 1996 Thomas Boutell Permission is granted to copy and distribute this document for any purpose and without charge, provided that this notice is preserved, and that any substantive changes or deletions from the original are clearly marked. Abstract This document describes the approval process for registering public PNG chunks. Persons who have contributed to the PNG mailing list at least 180 days prior to the end of the voting period are eligible to vote. A two-week voting period follows a two-week discussion period. Votes are cast by electronic mail to the png-list mailing list. Approval of a chunk registration requires at least 10 YES votes with at least twice as many YES votes as NO votes. PNG Development Group [Page 1] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960926 26 Sep 1996 Table of Contents 1. Purpose ........................................................ 2 2. Justification and additional aims .............................. 2 3. Prerequisites .................................................. 2 4. Voting ......................................................... 4 4.1. Initiation ................................................ 4 4.2. Casting votes ............................................. 4 4.3. Changing votes ............................................ 5 4.4. Termination ............................................... 5 5. Decision ....................................................... 6 6. Franchise ...................................................... 6 7. Time Stamps .................................................... 7 8. Adoption of this process ....................................... 7 9. Security considerations ........................................ 7 10. Appendix 1: Sample call for votes ............................. 7 11. Credits ....................................................... 9 12. Editor ........................................................ 9 1. Purpose To formally approve or reject a chunk for registration as a public chunk as described in the PNG 1.0 specification. This method can also be used to resolve other issues that need to be decided by the PNG group. 2. Justification and additional aims Discussions on the PNG discussion list (png-list@dworkin.wustl.edu) at present fail to reach a clear consensus on the desirability of particular chunk definitions. The formal approval process is intended to aid such decisions by * Identifying consensus when it exists. * Giving a limited time period within which objections can be raised. * Encouraging discussion and preventing ambiguities when one party to the discussion simply falls silent. To meet these ends the formal process is based on a discussion and voting process exercised over a limited period of time. 3. Prerequisites * A proposed specification of the chunk must exist in electronic PNG Development Group [Page 2] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960926 26 Sep 1996 form in a location on the current png-group discussion list FTP server. At present this is the tree based at ftp://swrinde.nde.swri.edu/pub/png-group/. The proposal must be in a final publishable format, such as that of the PNG 1.0 specification and PNG extensions documents found in ftp://swrinde.nde.swri.edu/pub/png/documents/. * The specification can be a whole single file, a group of files (which must be named by a single ftp accessible directory name and implies all files in that directory and all directories beneath it), or an identified part of a single file. * The specification should describe the proposed chunk in its unregistered form, to avoid the risk of premature distribution of documents describing public chunks that are not in their final form. The editors will make the necessary changes to the final document, by changing the second letter of the chunk name to uppercase and by removing any private version identification. If any other changes are needed, instructions to the editors should be provided in the proposal. * The specification or the call for votes must state the proposed disposition of the registered chunk: * Inclusion in the PNG core specification * Inclusion in the PNG extensions document * Inclusion in an existing separate document * Inclusion in a new separate document Note that the names of all formally registered chunks will either appear in the PNG specification or in the PNG extensions document. The editors will make the appropriate changes to those documents when a chunk is registered. * Throughout the two-week voting period the specification must remain absolutely unchanged. The two-week discussion period must be restarted upon making any change to the proposed specification, except for * Trivial formatting, grammatical, or spelling changes that do not change the meaning of the specification. * A printing date or authorship change. Upon the objection (on grounds that the change is nontrivial) of any person who would be eligible to vote if the voting period were to start immediately after the close of the discussion period, received by the png-list server prior to the call for votes, the two-week discussion period must be restarted in the event of any such change. The beginning of the new discussion period will be the time that the message announcing the change was received by the png-list server. PNG Development Group [Page 3] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960926 26 Sep 1996 4. Voting 4.1. Initiation Voting can be initiated after a two-week discussion period. The proposed chunk specification must be available and must not change for a period of at least two weeks before a vote can be called for. The chunk proponent starts this clock running by notifying the list that the proposed specification is available. Short proposals should also be posted to the list, to save people the trouble of downloading them. If discussion exposes flaws, the specification can be revised, thus starting a new two-week discussion period. Any person can initiate the voting period by submitting the first YES vote on an identified specification. This message also serves as the call for votes. This message must not be received by the png-list server before two weeks have elapsed since the message initiating or reinitiating the discussion period was received by the png-list server. There is no provision for issuing a call for votes without also voting YES at the same time. The message must clearly identify the specification to be voted upon. Appendix 1 gives the recommended format for a call for votes. 4.2. Casting votes Votes are cast by sending a message to the png-list indicating a YES, NO, or ABSTAIN vote. Voters must take care to make their intentions clear (i.e. "YES" or "NO" or "ABSTAIN" and precisely what chunk specification is being voted on). It is possible that votes will be tallied automatically. Therefore, to ensure that a vote is correctly registered, the first five lines of the message must conform to the following format: {YES|NO|ABSTAIN} Name For example: YES cNEW ftp://swrinde.nde.swri.edu/pub/png-group/documents/ png-proposed-chunks-19991231.html Glenn Randers-Pehrson There should be no other topics of discussion in the same message. An "Oh, by the way, I vote NO on cNEW" buried in the text of a long message might get overlooked by a person tallying the votes and would most certainly be missed by an automatic vote tallying PNG Development Group [Page 4] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960926 26 Sep 1996 robot. It is acceptable and useful to include additional explanations in the message, but the vote itself must be placed at the beginning. The subject of the message must contain the word "VOTE" (in uppercase letters) and the name of the proposal being voted upon. The string "Re:" must not not appear in the subject. An example of a correctly formatted subject line is Subject: VOTE on cNEW 19991231. Only one vote should be included in a message. If a group of chunks is being voted on as a whole, then only one message is necessary, but if different chunks are being separately voted upon during the same period, separate messages are required. The decision whether to group or separate chunks for voting is up to the person casting the initial YES vote. Persons are expected to identify themselves with their own name and their preferred e-mail address on the fifth line of the message, regardless of the account name from which they actually submit the message. Any votes received prior to the call for votes (i.e. the first YES vote after the close of the discusson period) will not be counted. 4.3. Changing votes A person can submit a changed vote any time prior to the expiration of the voting period. Only the latest vote, determined by the time it was mailed by the voter (from the "Date:" field of the message), that is received by the png-list server prior to the expiration of the voting period, will be counted. ABSTAIN votes are not counted. A person can cast an ABSTAIN vote to withdraw a YES or NO vote without having to cast a NO or YES to countermand it. The first YES vote, even if countermanded, continues to serve as the call for votes. The name and e-mail address on the fifth line of the changed vote must match those of the original vote, even if the new vote is submitted from another e-mail account. 4.4. Termination The voting period ceases two weeks after the initiation, at the same time of day as the initiation. The time of the call for votes is determined by the "Received:" line generated by the png- list e-mail server, e.g. in the message header "Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA10764 for ; Sun, 22 Sep 1996 10:11:58 -0500" PNG Development Group [Page 5] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960926 26 Sep 1996 the date and time are "Sun, 22 Sep 1996 10:11:58 -0500", and the voting period ends on Sunday, 06 Oct 1996 10:11:58 -0500. The voting period ceases immediately and the proposal is rejected upon approval of a competing specification for the same chunk name. 5. Decision A chunk specification is approved if both of the following conditions are met at the end of the voting period: * Ten YES votes are received. * At least twice the number of YES votes as NO votes are received. If these conditions are met, then the chunk becomes registered immediately upon the close of the voting period, and people can start using it in its registered form. The PNG editors will include the chunk specification, or a reference to it, in the next release of the PNG documentation. If these conditions are not met the chunk specification is rejected. The same chunk cannot be brought up again for another discussion period and vote either until a 180-day waiting period has elapsed, to allow for implementation and testing, or until a substantial change to the specification is made. 6. Franchise Any person is eligible to vote who has: * Submitted their first (or any subsequent) message received by the png-list server at least 180 days before the termination of the voting period. * Not voted on the same matter during the present voting period using a different name or e-mail address on the fifth line of the vote message. PNG Development Group [Page 6] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960926 26 Sep 1996 7. Time Stamps The "Received:" field generated by the png-list server is used to determine the exact times of the the beginning of the discussion period and the voting period, the close of the voting period, and for all other timing purposes except that the sender's "Date:" field is used to determine the order of precedence of multiple votes from the same person. 8. Adoption of this process Adoption of this process for registering PNG chunks will be voted upon using the same process as used for approving a chunk registration. It will take effect immediately upon the successful completion of the required discussion and voting periods. Discussion periods for proposed chunks, but not voting periods, can run concurrently with the voting period for adoption of this process. If approved, this document will be converted by the editor to a non- draft form and maintained in the appropriate public documents directory on the png-group discussion list FTP server. The process described in this document can also be used in a suitably amended form for registering chunks in related formats such as MNG, provided it is separately adopted for use for the other format. 9. Security considerations This process depends upon the integrity of the persons involved. We have no reason to believe that other measures are required. In the event of a prank or fraudulent vote, we will deal with it harshly, outside the scope of this process. This process depends upon the continued availability of the png-list server and its connection to the Internet. We will deal with system failures on a case-by-case basis, outside the scope of this process. 10. Appendix 1: Sample call for votes This is a recommended format for a call for votes, to be used by the first person submitting a YES vote. Only the first five lines of the message, which contain your own YES vote, are mandatory; the rest can be omitted if it is clear that all participants are already aware of the voting process. When there has been a long lapse between votes, or when new people have become eligible to vote, the complete message should be sent. Subject: VOTE on CNEW 19991231 PNG Development Group [Page 7] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960926 26 Sep 1996 YES cNEW 19991231 ftp://swrinde.nde.swri.edu/pub/png-group/documents png-proposed-chunks-19991231 My Name This is a call for votes on the PNG proposal cNEW 19991231 To vote on this proposal, send a message to png-list@dworkin.wustl.edu The subject line of your message must contain the words VOTE on cNEW 19991231 and must NOT contain the string "Re:" (i.e. do not try to cast your vote by "replying" to this message. You must manually construct the proper subject line). The body of your message must contain the following five lines, which must appear first in the message. YES | NO | ABSTAIN cNEW 19991231 ftp://swrinde.nde.swri.edu/pub/png-group/documents png-proposed-chunks-19991231 Your Name After these five lines you can add an explanation of your vote, if you desire. Providing the rationale for a NO vote is particularly encouraged. The voting period closes exactly two weeks after the time that this message or any earlier valid YES vote on this proposal was received by the png-list server (png-list@dworkin.wustl.edu) You can change your vote by submitting a new message. Only the last message sent by you and received by the png-list server prior to the close of the voting period will be counted. Your messages can be sent from different e-mail accounts, but the fifth line of all of your messages, containing your name and your preferred e-mail address, must be identical. You are eligible to vote if your earliest message to png-list was received at least 180 days earlier than the close of the voting period. regards, Chunk Proponent PNG Development Group [Page 8] PNG-GROUP-DRAFT PNG Chunk Registration Process 19960926 26 Sep 1996 11. Credits Contributors' names are presented in alphabetical order: * Thomas Boutell, boutell@boutell.com * John Bowler, jbowler@megamed.com * Adam M. Costello, amc@cs.berkeley.edu * Lee Daniel Crocker, lee@piclab.com * Tom Lane, tgl@sss.pgh.pa.us * Glenn Randers-Pehrson, glennrp@arl.mil or randeg@alumni.rpi.edu * Greg Roelofs, newt@pobox.com * Willem van Schaik, gwillem@ntuvax.ntu.ac.sg 12. Editor Glenn Randers-Pehrson U.S. Army Research Laboratory ATTN: AMSRL-WM-TD Aberdeen Proving Ground, MD 21005-5066 Phone: (410) 278-6554 EMail: glennrp@arl.mil or randeg@alumni.rpi.edu End of PNG Chunk Registration Process document. Expires 26 Mar 1997. PNG Development Group [Page 9] ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 14:07:19 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id OAA13675 for ; Thu, 26 Sep 1996 14:07:18 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA02861 for png-list-outgoing; Thu, 26 Sep 1996 14:07:16 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA02854 for ; Thu, 26 Sep 1996 14:07:11 -0500 Received: from munet-h.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id NAA01382; Thu, 26 Sep 1996 13:07:03 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Received: (adilger@localhost) by munet-h.enel.ucalgary.ca (8.6.12/8.6.12) id NAA04681 for png-list@dworkin.wustl.edu; Thu, 26 Sep 1996 13:04:07 -0600 Message-Id: <199609261904.NAA04681@munet-h.enel.ucalgary.ca> Subject: Re: New chunk registration procedure 199609245 To: png-list@dworkin.wustl.edu Date: Thu, 26 Sep 1996 13:04:07 -0600 (MDT) In-Reply-To: <21243.843760264@sss.pgh.pa.us> from "Tom Lane" at Sep 26, 96 01:51:04 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Tom writes: > I think posting a separate "CALL FOR VOTES on cNEW" message is a better > idea, and the overhead is really pretty minimal. You could certainly take > it as an implied YES if you like, but it should be easily identifiable as > a vote initiation message rather than just another vote. > > > the first five lines of the message > > must conform to the following format: > > {YES|NO|ABSTAIN} > > > > > > > > Name Just to make things easier for the voters, I'd suggest that the "CALL FOR VOTES on cNEW" message contain all of the above fields, and then the voters can just reply to the "CFV" message and fill in the fields. This will make things a lot easier than having to bring out "Volume 2 of the png-list voting procedure manual" in order to fill out all of the fields properly. The "CFV" message should have the chunk-tag, ftp-directory, and file-name fields filled out already, so there is no ambiguity about which chunk we are voting for. As an aside, I don't really like the way this whole thing is going. For the PNG development, which was much more complex than this, we all accepted that the members of this list were rational adults, and that cheating, ballot stuffing, etc, was unthinkable. I don't see that this has changed. No matter how complex we make the rules, there will always be loopholes, and no doubt at some point people will want lawyers to interpret the exact semantics of the rules, and follow the letter of the law, and not the intent. I think we should stop quibbling about details in the voting procedure and get back to what we really want to do - finish up with the extension chunks. In the end, I think we have to realize that some people want chunks for a specific purpose (ie dRNG/DRNG), and it is better to standardize such a chunk with notices saying this is for a specific purpose (ie not for general consumption, but can be useful for decoders to support, but only written in specific applictions). The gist of this is that it's better to have a single, well discussed "thorn" than dozens of haphazard private critical chunks that do nearly the same thing. We made PNG expandable for the reason that we don't know what everyone wants to do with it, and rather than trying to hamstring developers (which is futile in the end anyways - look at all of the "standard" x-??? MIME types), we should do our best to make an extension chunk as sensible and orthogonal to other chunks as possible, and then be done with it. The last thing we want is for a private chunk to become a defacto standard because we don't want to approve it. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 14:56:39 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id OAA14840 for ; Thu, 26 Sep 1996 14:56:37 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA03978 for png-list-outgoing; Thu, 26 Sep 1996 14:56:15 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA03965 for ; Thu, 26 Sep 1996 14:56:07 -0500 Date: Thu, 26 Sep 96 15:55:13 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New chunk registration procedure 199609245 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609261555.aa23172@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Andreas wrote: } }I think we should stop quibbling about details in the voting procedure and }get back to what we really want to do - finish up with the extension chunks. well said. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 14:56:47 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id OAA14846 for ; Thu, 26 Sep 1996 14:56:44 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA03979 for png-list-outgoing; Thu, 26 Sep 1996 14:56:16 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA03963 for ; Thu, 26 Sep 1996 14:56:03 -0500 Date: Thu, 26 Sep 96 15:51:52 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New chunk registration procedure 199609245 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609261551.aa22507@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Subject: Re: New chunk registration procedure 199609245 }Date: Thu, 26 Sep 1996 13:51:04 -0400 }Message-ID: <21243.843760264@sss.pgh.pa.us> }From: Tom Lane }Some comments on the third draft: } }> 3. Prerequisites } }> The proposal must }> be in a final publishable format, such as that of the PNG 1.0 }> specification and PNG extensions documents found in }> ftp://swrinde.nde.swri.edu/pub/png-group/documents/. } }I think it's the editors' job to reduce text to publishable form. }Requiring proposals to be HTML or whatever just distracts people from }getting the technical content right. Experience with all of the proposals so far shows (I think) that putting them in a final form was needed to serve as the focal point for debate. }How about "The proposal must }include the complete proposed specification text for the chunk(s)", }but no specific requirements as to format. "such as" above was not to mean a specific requirement. ASCII text would be ok as far as I am concerned. } }> Note that the names of all formally registered chunks will }> either appear in the PNG specification or in the PNG extensions }> document. } }... or at least in a document referenced by the PNG extensions document. I don't think it's a good idea to have the list of registered chunks to widely scattered, no matter how distasteful some of them may turn out to be. } }> * Throughout the two-week voting period the specification must }> remain absolutely unchanged. The two-week discussion period }> must be restarted upon making any change to the proposed }> specification, except for }> * Simple formatting, grammatical, or spelling changes. }> * A printing date or authorship change. }> Upon the objection of any voter, received by the png-list }> server prior to the call for votes, the two-week discussion }> period must be restarted in the event of any such change. } }"Prior to the call for votes" is no good. Unless the proponent actually }jumps the gun, there would be no reason to make such an objection. How }about replacing this item with: } } * A call for votes cannot be issued until the proposed } specification has remained unchanged for at least two weeks. } However, exceptions will be made for trivial changes, such as: } * Simple formatting, grammatical, or spelling changes. } * A printing date or authorship change. } A call may be issued after two weeks have elapsed with no } nontrivial changes. If there is any dispute as to whether a } change is nontrivial, any eligible voter may object to the call } for votes. In such case the vote is cancelled, and the call } must be re-issued two weeks after the disputed change. There should be a time limit on the right to make an objection, such as within the two weeks after the disputed change. } }> After the two-week discussion period, the vote is initiated by any }> person submitting the first YES vote on an identified }> specification. This message also serves as the call for votes. }> There is no provision for issuing a call for votes without also }> voting YES at the same time. } }I don't much care for this. I would like calls for votes to be clearly }identifiable as such from the subject line. If there is already a vote }or two in process, one has to look closely to notice that "VOTE for cXYZ" }actually is a new call for votes and not just another vote for cYYZ whose }vote started last week. This provision was in John Bowler's original message and in the several drafts since... I don't quite understand the rationale myself. Maybe to facilitate the "terminate if no YES votes remain", but that's gone anyway. } }I think posting a separate "CALL FOR VOTES on cNEW" message is a better }idea, and the overhead is really pretty minimal. You could certainly take }it as an implied YES if you like, but it should be easily identifiable as }a vote initiation message rather than just another vote. } }> the first five lines of the message }> must conform to the following format: }> {YES|NO|ABSTAIN} }> }> }> }> Name } }If a prior CALL FOR VOTES message has identified the specification to be }voted on, it's probably not really necessary to make each voter repeat }this info. YES/NO/ABSTAIN and the chunk name(s) ought to be sufficient. The trouble here is there might be lingering votes from an earlier, cancelled voting session. If we're doing manual tallying, ok, but if we use Lee's automatic vote counter it might get confused if it doesn't have all of the specified information. Certainly it must have the voter's name and e-mail address. Lee, what do you think? } }> A chunk specification is approved if both of the following conditions }> are met at the end of the voting period: }> * Ten YES votes are received. } }"At least ten..." Oh, all right. } }> The same chunk cannot be brought up again for another discussion }> period and vote until either a 180-day waiting period has elapsed, to }> allow for implementation and testing, or until a substantial change }> to the specification is made. } }I'm not sure that I like this. I could see people insisting on a new vote }every six months whether anything had changed or not. Also, there could }be quibbles about whether a change to the spec was "substantial" enough to }merit a revote. My first thought on how to fix it was: } } A chunk proposal that has failed may not be brought up for re-vote } unless at least two voters who voted NO for it agree that a re-vote } is appropriate. } }But this has its own semi-trailer-sized loopholes. (Eg, chunk is about }to fail 7:3. Two proponents change their votes to NO just before close }of voting. Now they can force an immediate revote.) } }I would like to see the spec say that revotes will be taken only if either }the chunk spec itself or outside conditions have changed significantly, }and get rid of any strictly time-based criterion. But I don't know how to }define this. Maybe we just have to depend on proponents to be reasonable }people. } I think they are, and I think we know what the paragraph means. If nothing has happened, it's inappropriate to bring it up just because 180 days have elapsed. There must at least have been some implementation, testing, or whatnot that makes the proposal more mature, or if, as you say, outside conditions have changed. Let's just leave the paragraph as it is, and if people abuse it, we can revise the process. } }In a later message Glenn suggests: } }> * Not voted on the same matter the during the present voting period }> using a different name or e-mail address on the fifth line of the }> vote message. } }I think this is unnecessary given the proposed section 10: Agreed. I forgot to take it out after writing section 10. } }> 10. Security considerations }> }> This process depends upon the integrity of the persons involved. }> We have no reason to believe that other measures are required. In }> the event of a prank or fraudulent vote, we will deal with it }> harshly, outside the scope of this process. }> }> This process depends upon the continued availability of the png-list }> server and its connection to the Internet. We will deal with system }> failure on a case-by-case basis, outside the scope of this process. } }which I agree with. } } regards, tom lane } I want to put this thing to bed so we can start voting on real issues. Hoping for some consensus, I pointed out that Todd's chunks and sPLT had been in the hopper for a year. Instead we got this, which threatens to drag out until we all get bored with it, and certainly has put off any action on Todd's chunks and sPLT for a couple of months. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 15:16:42 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id PAA15495 for ; Thu, 26 Sep 1996 15:16:41 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA04298 for png-list-outgoing; Thu, 26 Sep 1996 15:16:19 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id PAA04291 for ; Thu, 26 Sep 1996 15:16:11 -0500 Date: Thu, 26 Sep 96 16:12:27 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New chunk registration procedure 199609245 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609261612.aa23828@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Thu, 26 Sep 96 15:55:13 EDT }From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB }Subject: Re: New chunk registration procedure 199609245 }Message-ID: <9609261555.aa23172@THOR.ARL.MIL> }Andreas wrote: }} }}I think we should stop quibbling about details in the voting procedure and }}get back to what we really want to do - finish up with the extension chunks. } Since we are generally insisting on an implementation of a chunk before we approve it, perhaps we ought to do a trial run of the voting system before we approve it. We have three chunks that have had a sufficient discussion period, and their draft specs have been stable since April. They are drNG, alIG, and loGE. Just to make things interesting, let's start with the controversial one. Watch for a call for votes. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 15:22:57 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id PAA15563 for ; Thu, 26 Sep 1996 15:22:56 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA04422 for png-list-outgoing; Thu, 26 Sep 1996 15:22:54 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA04412 for ; Thu, 26 Sep 1996 15:22:46 -0500 Received: from munet-h.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id OAA02139; Thu, 26 Sep 1996 14:22:37 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Received: (adilger@localhost) by munet-h.enel.ucalgary.ca (8.6.12/8.6.12) id OAA04821 for png-list@dworkin.wustl.edu; Thu, 26 Sep 1996 14:19:41 -0600 Message-Id: <199609262019.OAA04821@munet-h.enel.ucalgary.ca> Subject: Re: New chunk registration procedure 199609245 To: png-list@dworkin.wustl.edu Date: Thu, 26 Sep 1996 14:19:40 -0600 (MDT) In-Reply-To: <9609261551.aa22507@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 26, 96 03:51:52 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: [re when to vote after a failed vote] > I think they are, and I think we know what the paragraph means. If > nothing has happened, it's inappropriate to bring it up just because > 180 days have elapsed. There must at least have been some implementation, > testing, or whatnot that makes the proposal more mature, or if, as you > say, outside conditions have changed. Let's just leave the paragraph > as it is, and if people abuse it, we can revise the process. I'm not sure how you want to leave this. I would have to say that I oppose a strictly time-based re-vote rule, as this could force a 6-month delay for a trivial reason. Example: I propose a chunk, it is discussed, and it goes to a vote. During the voting period, someone brings up an issue with the chunk that hadn't been thought of before (ie people read the spec more closely just before they vote for it), which forces a non-trivial change in the chunk spec, and people vote against the chunk. This would force a 6-month delay in approval for an issue that may be solved immediately. Granted that we don't want people to keep on asking for re-votes, but if we assume reasonable members on the list, this probably won't happen. They will realize that the vote will go the same way as before, unless there have been significant enough changes to sway the opponents, and this is what really counts (ie a self correcting system free of trivial rules). Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 16:07:08 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA16320 for ; Thu, 26 Sep 1996 16:07:04 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA05407 for png-list-outgoing; Thu, 26 Sep 1996 16:06:21 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id QAA05389 for ; Thu, 26 Sep 1996 16:05:42 -0500 Date: Thu, 26 Sep 96 17:04:54 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New chunk registration procedure 199609245 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609261704.aa26209@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List } }I'm not sure how you want to leave this. I would have to say that I oppose }a strictly time-based re-vote rule, as this could force a 6-month delay for }a trivial reason. } }Example: I propose a chunk, it is discussed, and it goes to a vote. During }the voting period, someone brings up an issue with the chunk that hadn't }been thought of before (ie people read the spec more closely just before }they vote for it), which forces a non-trivial change in the chunk spec, }and people vote against the chunk. This would force a 6-month delay in }approval for an issue that may be solved immediately. } That's covered: if the spec has had a non-trivial change then it can be re-voted. I guess we can nit-pick over whether the change is major enough to cancel the ongoing vote but not significant enough to allow a new vote. The way I see it is a re-vote should be permitted when - the spec has been significantly altered - outside circumstances have significantly changed - the chunk has achieved significantly more maturity from implementation and testing. The 180-day rule is to allow a re-vote without having to conduct a 180-day debate over whether significant changes have occurred. Anyway, if the rules turn out not to work, we can change them. They're *our* rules. Still waiting for someone to submit a trial call-for-votes (by the way, I suggest that, although it's a trial, it would be a real vote). The proponents of the three eligible chunks are Jim K, Todd F, and Dave M..... I'm just the editor/formatter, so it's not necessarily my job to put in calls for votes. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 16:30:11 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA16673 for ; Thu, 26 Sep 1996 16:30:11 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA05754 for png-list-outgoing; Thu, 26 Sep 1996 16:30:08 -0500 Received: from tide21.microsoft.com (tide21.microsoft.com [131.107.3.31]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id QAA05747 for ; Thu, 26 Sep 1996 16:30:03 -0500 Received: by tide21.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBABB7.886BED80@tide21.microsoft.com>; Thu, 26 Sep 1996 14:32:23 -0700 Message-ID: From: John Bowler To: "'PNG List'" Subject: RE: New chunk registration procedure 199609245 Date: Thu, 26 Sep 1996 14:29:50 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 16 TEXT Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB[SMTP:glennrp@ARL.MIL] > >I want to put this thing to bed so we can start voting on real issues. >Hoping for some consensus, I pointed out that Todd's chunks and sPLT >had been in the hopper for a year. Instead we got this, which threatens to >drag out until we all get bored with it, and certainly has put off >any action on Todd's chunks and sPLT for a couple of months. I hope not - 2 weeks if we don't waste time arguing small points. This on the basis that someone suggested we should vote for this process using the process (probably a reasonable sanity check) and that the discussion/stability period for actual chunks could start when the voting period for the process started. So this is a minimum elapsed time of 6 weeks to approve, for example, sPLT. John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 16:41:12 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA17119 for ; Thu, 26 Sep 1996 16:41:10 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA06007 for png-list-outgoing; Thu, 26 Sep 1996 16:40:30 -0500 Received: from enel.ucalgary.ca ([136.159.99.2]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA06000 for ; Thu, 26 Sep 1996 16:40:22 -0500 Received: from munet-h.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id PAA02663; Thu, 26 Sep 1996 15:40:13 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Received: (adilger@localhost) by munet-h.enel.ucalgary.ca (8.6.12/8.6.12) id PAA04942 for png-list@dworkin.wustl.edu; Thu, 26 Sep 1996 15:37:17 -0600 Message-Id: <199609262137.PAA04942@munet-h.enel.ucalgary.ca> Subject: CALL FOR VOTES on dRNG To: png-list@dworkin.wustl.edu (PNG Graphics discussion) Date: Thu, 26 Sep 1996 15:37:15 -0600 (MDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List YES/NO/ABSTAIN dRNG ftp://swrinde.nde.swri.edi/pub/png-group/documents/ png-scivis-chunks-19960914 Name Note that in the png-scivis-chunks-19960914.txt.gz file, the description of the dRNG "ratio" should specify "output_bit_depth" instead of "bit_depth", and also under the discussion of indexed color images immediately below. This vote on dRNG/DRNG is based on these minor changes. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 16:54:21 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA17254 for ; Thu, 26 Sep 1996 16:54:20 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA06271 for png-list-outgoing; Thu, 26 Sep 1996 16:54:07 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA06266 for ; Thu, 26 Sep 1996 16:54:03 -0500 Received: from munet-h.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id PAA02732; Thu, 26 Sep 1996 15:53:54 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Received: (adilger@localhost) by munet-h.enel.ucalgary.ca (8.6.12/8.6.12) id PAA04976 for png-list@dworkin.wustl.edu; Thu, 26 Sep 1996 15:50:57 -0600 Message-Id: <199609262150.PAA04976@munet-h.enel.ucalgary.ca> Subject: Discussion on pCAL To: png-list@dworkin.wustl.edu (PNG Graphics discussion) Date: Thu, 26 Sep 1996 15:50:52 -0600 (MDT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I was ready to put in a CFV for pCAL, but after reading the spec once more (version 19960914), I came upon the addition of "purpose" which I don't remember seeing before. The spec gives the reason for the "purpose" field as being useful for multi-image files. However, I can't see this at all - surely the data in the PNG file only has one true physical value? If there are multiple images, and multiple pCAL values, the pCAL should be stored with the relevant PNG sub-image, or potentially a single pCAL useful for a whole series of images can be stored at the top of the file. pCAL isn't the same as fALS in that there may be various useful ways of looking at a dataset - it represents the actual data values, of which there can be only one. I guess we need to wait another 2 weeks for this one. There are no other chunks that I'm interested in enough to do the CFV myself. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 16:55:09 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA17264 for ; Thu, 26 Sep 1996 16:55:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA06294 for png-list-outgoing; Thu, 26 Sep 1996 16:55:08 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA06289 for ; Thu, 26 Sep 1996 16:55:03 -0500 Received: from munet-h.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id PAA02736; Thu, 26 Sep 1996 15:54:48 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Received: (adilger@localhost) by munet-h.enel.ucalgary.ca (8.6.12/8.6.12) id PAA04983 for png-list@dworkin.wustl.edu; Thu, 26 Sep 1996 15:51:51 -0600 Message-Id: <199609262151.PAA04983@munet-h.enel.ucalgary.ca> Subject: Re: CALL FOR VOTES on dRNG To: png-list@dworkin.wustl.edu Date: Thu, 26 Sep 1996 15:51:47 -0600 (MDT) In-Reply-To: <199609262137.PAA04942@munet-h.enel.ucalgary.ca> from "Andreas Dilger" at Sep 26, 96 03:37:15 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List YES dRNG ftp://swrinde.nde.swri.edi/pub/png-group/documents/ png-scivis-chunks-19960914 Andreas Dilger ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 16:55:13 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA17271 for ; Thu, 26 Sep 1996 16:55:12 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA06304 for png-list-outgoing; Thu, 26 Sep 1996 16:55:13 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA06296 for ; Thu, 26 Sep 1996 16:55:09 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id RAA22650 for ; Thu, 26 Sep 1996 17:54:51 -0400 (EDT) To: PNG List Subject: Re: CALL FOR VOTES on dRNG In-reply-to: Your message of Thu, 26 Sep 1996 15:37:15 -0600 (MDT) <199609262137.PAA04942@munet-h.enel.ucalgary.ca> Date: Thu, 26 Sep 1996 17:54:50 -0400 Message-ID: <22648.843774890@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List This is a little premature given that we haven't approved the process yet... In any case, I would prefer to see us do the full discussion-period- followed-by-vote-period for those old chunks. I dunno about the rest of you, but I've forgotten what the issues were, and I'd like to have my memory refreshed before I have to vote. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 17:12:57 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA17620 for ; Thu, 26 Sep 1996 17:12:54 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA06611 for png-list-outgoing; Thu, 26 Sep 1996 17:12:29 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA06599 for ; Thu, 26 Sep 1996 17:11:55 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id PAA19710 for ; Thu, 26 Sep 1996 15:04:22 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id PAA00818 for png-list@dworkin.wustl.edu; Thu, 26 Sep 1996 15:04:22 -0700 (PDT) Message-Id: <199609262204.PAA00818@web1.calweb.com> Subject: Re: CALL FOR VOTES on dRNG To: png-list@dworkin.wustl.edu Date: Thu, 26 Sep 1996 15:04:22 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <22648.843774890@sss.pgh.pa.us> from "Tom Lane" at Sep 26, 96 05:54:50 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > In any case, I would prefer to see us do the full discussion-period- > followed-by-vote-period for those old chunks. I dunno about the rest > of you, but I've forgotten what the issues were, and I'd like to have > my memory refreshed before I have to vote. Yes, I wanted to make some changes to aLIG, too, which I think is a good idea, but not complete yet. At least now when we start discussion, it will be knowing that a vote is imminent and I'll be more inclined to pay attention. BTW, I set up the tallying robot, so if anyone wants to send votes anyway to test it, go ahead. I haven't got the Web page yet, but I'll let you know. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 17:45:47 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA18146 for ; Thu, 26 Sep 1996 17:45:46 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA07223 for png-list-outgoing; Thu, 26 Sep 1996 17:45:36 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA07213 for ; Thu, 26 Sep 1996 17:45:29 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id SAA22958 for ; Thu, 26 Sep 1996 18:45:20 -0400 (EDT) To: PNG List Subject: Re: CALL FOR VOTES on dRNG In-reply-to: Your message of Thu, 26 Sep 1996 17:54:50 -0400 <22648.843774890@sss.pgh.pa.us> Date: Thu, 26 Sep 1996 18:45:20 -0400 Message-ID: <22956.843777920@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I said: > This is a little premature given that we haven't approved the process > yet... Hmm, has anyone else noticed rather flaky service from png-list lately? I received this afternoon's discussion proposing a trial vote a good half hour after Andreas' CFV arrived, so naturally I hadn't a clue what was going on. Now that I think of it, png-list traffic has been coming in with odd delays for several days. If people want to start a trial run, it's OK with me. I still would like to see a discussion period first, though. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 17:47:48 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA18163 for ; Thu, 26 Sep 1996 17:47:46 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA07420 for png-list-outgoing; Thu, 26 Sep 1996 17:47:50 -0500 Received: from fm3.facility.pipex.com (fm3.facility.pipex.com [194.131.104.13]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id RAA07414 for ; Thu, 26 Sep 1996 17:47:46 -0500 Received: from 193.130.252.145 (am145.du.pipex.com) by fm3.facility.pipex.com (5.x/PIPEX simple 1.26) id AA22731; Thu, 26 Sep 1996 22:48:27 +0100 Message-Id: <9609262148.AA22731@fm3.facility.pipex.com> Mime-Version: 1.0 From: ttehtann@argonet.co.uk (Tom Tanner) To: png-list@dworkin.wustl.edu Date: Thu, 26 Sep 96 23:35:13 X-Mailer: VTi Internet Email reader 1.08 : aa Subject: Re: Re: New chunk registration procedure 199609245 Content-Type: text/plain Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >Since we are generally insisting on an implementation of a chunk before >we approve it, perhaps we ought to do a trial run of the voting system >before we approve it. > >We have three chunks that have had a sufficient discussion period, and >their draft specs have been stable since April. They are drNG, alIG, >and loGE. > >Just to make things interesting, let's start with the controversial >one. The most controversial thing on this group so far has been the voting system. Are we going to have a vote on that first ? ;-> -- Thos -- T. R. Tanner email: ttehtann@argonet.co.uk ZFC: A Alien %0100 : In CyberSpace, no one can hear you scream ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 17:56:08 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA18288 for ; Thu, 26 Sep 1996 17:56:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA07710 for png-list-outgoing; Thu, 26 Sep 1996 17:56:09 -0500 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA07705 for ; Thu, 26 Sep 1996 17:56:06 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id PAA14515 for ; Thu, 26 Sep 1996 15:55:55 -0700 X-Sender: davem@mail.cs.ubc.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Sep 1996 15:56:02 -0700 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: the fate of loGE Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Hmm. It seems that I'm the official proponent of loGE. However, I'm having some second thoughts abouts status as a PNG chunk. Some of my thoughts: 1. Wide-dynamic-range images *do* exist, and I work with them. They are normally stored in one of two forms: 10-bit logarithmic sample values, and 16-bit linear sample values where nominal white is about 4096. It seems that, with the addition of the drNG chunk, the latter form could be stored as PNG images and displayed correctly. The 10-bit log form requires loGE, though. If we have drNG and not loGE, I could always convert a 10-bit log to 16-bit linear image for storage as PNG, but it probably wouldn't compress as well. So loGE is at least theoretically useful. 2. However, it isn't clear that I would use PNG in my work even if loGE was available, because of compression overhead. PNG doesn't allow uncompressed files, and I often produce images using a pipeline of several tools. An uncompressed format is better for this. As a result, I've been storing images using PPM plus a homegrown format, not PNG. 3. Something like loGE breaks one of the fairly basic design decisions of PNG: that pixel values are scaled (if necessary) during encoding to use the entire 0 to 2^nbits-1 range for the displayable brightness range from black to white, with no extra "footroom" or "headroom". It's true that dRNG also breaks this - but I suspect that in many cases images using dRNG will be recognizable when displayed by decoders that don't recognize the dRNG chunk. Images using loGE will always look awful when decoded by non-loGE capable decoders. So perhaps the utility of loGE does not outweigh the pain it will cause. 4. If it *is* worth adding an entirely different transfer function to PNG, such as loGE, then it's probably worth defining something that is more general than loGE - perhaps an arbitrary transfer function specified by multiple points along it, or the ability to write expressions for the transfer function in some pseudo-language. Anyway, as a result of these misgivings, I won't be calling for a vote on loGE any time soon. Discussion of the points raised above is welcome, though. Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 18:11:52 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA18517 for ; Thu, 26 Sep 1996 18:11:51 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA07955 for png-list-outgoing; Thu, 26 Sep 1996 18:10:32 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA07950 for ; Thu, 26 Sep 1996 18:10:28 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id QAA29808 for ; Thu, 26 Sep 1996 16:02:52 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id QAA19157 for png-list@dworkin.wustl.edu; Thu, 26 Sep 1996 16:02:52 -0700 (PDT) Message-Id: <199609262302.QAA19157@web1.calweb.com> Subject: Re: the fate of loGE To: png-list@dworkin.wustl.edu Date: Thu, 26 Sep 1996 16:02:52 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: from "Dave Martindale" at Sep 26, 96 03:56:02 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > 4. If it *is* worth adding an entirely different transfer function to > PNG, such as loGE, then it's probably worth defining something that > is more general than loGE - perhaps an arbitrary transfer function > specified by multiple points along it, or the ability to write > expressions for the transfer function in some pseudo-language. Yes, I hearily agree (surprize). I would be entirely in favor of a chunk that specified arbitrary functions for converting IDAT pixel values into source values with formulas or tables, thereby serving the purpose of both DRNG and LOGE and others. Regardless of what the original values were or what they represent, so long as they don't have more than 65,536 distinct sample values, it is always possible to scale them into IDAT values with full range for viewability on all readers. Rather than a full-blown formula or language, though, I'd be more inclined to something like a "custom transfer" chunk with IDs for each case that somebody found useful, and a variable-length body for parameters of each case. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 18:25:59 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA18614 for ; Thu, 26 Sep 1996 18:25:59 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA08356 for png-list-outgoing; Thu, 26 Sep 1996 18:25:47 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA08350 for ; Thu, 26 Sep 1996 18:25:41 -0500 Received: from munet-h.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id RAA03156; Thu, 26 Sep 1996 17:25:32 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Received: (adilger@localhost) by munet-h.enel.ucalgary.ca (8.6.12/8.6.12) id RAA05123 for png-list@dworkin.wustl.edu; Thu, 26 Sep 1996 17:22:34 -0600 Message-Id: <199609262322.RAA05123@munet-h.enel.ucalgary.ca> Subject: Re: the fate of loGE To: png-list@dworkin.wustl.edu Date: Thu, 26 Sep 1996 17:22:34 -0600 (MDT) In-Reply-To: from "Dave Martindale" at Sep 26, 96 03:56:02 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Dave writes: > 2. However, it isn't clear that I would use PNG in my work even if loGE was > available, because of compression overhead. PNG doesn't allow uncompressed > files, and I often produce images using a pipeline of several tools. > An uncompressed format is better for this. > > As a result, I've been storing images using PPM plus a homegrown > format, not PNG. This is sort of a misnomer, as it is possible to just set the zlib compression level to "0", and you will get uncompressed data, although segmented up in chunks. If the issue is speed, then this will work. If the issue is being able to dump out raw pixel values from your application, then you would need to work out the raw zlib chunk structure for uncompressed data. The zlib spec defines this exactly, but it shouldn't be more than zlib magic bytes, repeated, data checksum. > 3. Something like loGE breaks one of the fairly basic design decisions of > PNG: that pixel values are scaled (if necessary) during encoding to > use the entire 0 to 2^nbits-1 range for the displayable brightness > range from black to white, with no extra "footroom" or "headroom". However, if the images are used by a specific application in this manner to efficiently store data, people may not be viewing the images much anyways? The suggested gAMA info would make the data understandable, and your application would do proper decoding. > 4. If it *is* worth adding an entirely different transfer function to > PNG, such as loGE, then it's probably worth defining something that > is more general than loGE - perhaps an arbitrary transfer function > specified by multiple points along it, or the ability to write > expressions for the transfer function in some pseudo-language. This is something we should avoid, IMHO. If you need a chunk to do a specific purpose, then we should create that chunk. If, during the discussion period, people have other applications which would use such a chunk or a variant thereof, we will modify the spec. I don't, however, like the idea of chunk bloat, where we dream up potential uses for chunks that nobody really needs, and then when someone actually needs to use a chunk we find we did it wrong anyways. In that vein, I think it useful that we somehow make people aware that there are chunks other than those in the official png-extension document so that if they are looking for a specific type of chunk they can look at the proposed chunks and perhaps become a chunk advocate on this list. Maybe we even need a separate png-chunk-list, so that people solely interested in adding new chunks don't have to be a part of the general PNG discussion. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 18:49:17 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA18721 for ; Thu, 26 Sep 1996 18:49:14 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA08796 for png-list-outgoing; Thu, 26 Sep 1996 18:47:57 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA08773 for ; Thu, 26 Sep 1996 18:44:19 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id QAA06267 for ; Thu, 26 Sep 1996 16:34:42 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id QAA02042 for png-list@dworkin.wustl.edu; Thu, 26 Sep 1996 16:34:41 -0700 (PDT) Message-Id: <199609262334.QAA02042@web1.calweb.com> Subject: Re: the fate of loGE To: png-list@dworkin.wustl.edu Date: Thu, 26 Sep 1996 16:34:41 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <199609262322.RAA05123@munet-h.enel.ucalgary.ca> from "Andreas Dilger" at Sep 26, 96 05:22:34 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > This is sort of a misnomer, as it is possible to just set the zlib compression > level to "0", and you will get uncompressed data, although segmented up in > chunks. If the issue is speed, then this will work. But don't let our "dirty little secret" of uncompressed PNG get spread out too far into the public--yes, it's possible, and I don't mind a writer or reader/writer combo that does it, but we don't want anyone to make a reader that only accepts uncompressed PNG calling itself a PNG reader. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 19:15:25 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id TAA19153 for ; Thu, 26 Sep 1996 19:15:24 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA09235 for png-list-outgoing; Thu, 26 Sep 1996 19:14:00 -0500 Received: from dawn13.CS.Berkeley.EDU (dawn13.CS.Berkeley.EDU [128.32.38.57]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA09230 for ; Thu, 26 Sep 1996 19:13:56 -0500 Received: (from amc@localhost) by dawn13.CS.Berkeley.EDU (8.6.11/8.6.9) id RAA04227 for png-list@dworkin.wustl.edu; Thu, 26 Sep 1996 17:13:46 -0700 Date: Thu, 26 Sep 1996 17:13:46 -0700 Message-Id: <199609270013.RAA04227@dawn13.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: CALL FOR VOTES on dRNG X-Advice: should read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List The dRNG proposal says: > This chunk can be used when the pixel values do not occupy the > full range of possible values, and when bit depth scaling is not > appropriate. When is that, exactly? Scaling can be done in a reversible way. All you might need would be a chunk that says which reversible function was used. Well, there is an exception: if max_value - min_value is greater than 2^16, you can't do the scaling reversibly. The proposal then says: > It can also be used to enhance contrast by scaling to a larger range > than the actual range of pixel values. This opens up a more general scenario. There are some original (perhaps scanned) samples, and the image creator wants those samples preserved in the file. But there are some transformations of the image which the creator recommends for making the image more viewable. These are the same transformations that any viewing software might put under the control of the user. Think of the image creator suggesting initial values for all of xv's knobs. How useful is this, and how general would we want to make it? The proposal then says: > It can be used to correct the brightness of an image that has been > scaled by zero-filling rather than linear scaling. sBIT already takes care of that. On a completely different subject, Tom Lane says: > Hmm, has anyone else noticed rather flaky service from png-list > lately? I haven't noticed. AMc ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 20:35:03 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id UAA19651 for ; Thu, 26 Sep 1996 20:35:02 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA10507 for png-list-outgoing; Thu, 26 Sep 1996 20:33:17 -0500 Received: from dawn13.CS.Berkeley.EDU (dawn13.CS.Berkeley.EDU [128.32.38.57]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA10502 for ; Thu, 26 Sep 1996 20:33:13 -0500 Received: (from amc@localhost) by dawn13.CS.Berkeley.EDU (8.6.11/8.6.9) id SAA04439 for png-list@dworkin.wustl.edu; Thu, 26 Sep 1996 18:33:04 -0700 Date: Thu, 26 Sep 1996 18:33:04 -0700 Message-Id: <199609270133.SAA04439@dawn13.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: the fate of loGE From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List "Lee Daniel Crocker" says: > I would be entirely in favor of a chunk that specified arbitrary > functions for converting IDAT pixel values into source values with > formulas or tables, thereby serving the purpose of both DRNG and LOGE > and others. We could have a chunk that contains Java bytecode that does the transformation. Taking the next leap, we could do without graphic file formats altogether. We could instead have a standard interface for asking an image for information about itself, and let the image (a Java object) store the information any way it pleases. We could even provide a standard library of commonly used functions so that image objects don't have to carry around much code with them. I'm not sure I'm serious, but isn't this exactly the sort of thing Java was designed for? Is it only a matter of time before this kind of practice becomes commonplace, or is there something inherently wrong with this approach? AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 22:01:09 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id WAA20026 for ; Thu, 26 Sep 1996 22:01:06 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA11717 for png-list-outgoing; Thu, 26 Sep 1996 21:59:33 -0500 Received: from inet.htcnet.com (inet.htcnet.com [199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id VAA11711 for ; Thu, 26 Sep 1996 21:59:28 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id WAA17110 for ; Thu, 26 Sep 1996 22:03:32 -0500 Message-Id: <199609270303.WAA17110@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: Re: the fate of loGE Date: Thu, 26 Sep 1996 21:59:16 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List | 2. However, it isn't clear that I would use PNG in my work even if loGE was | available, because of compression overhead. PNG doesn't allow uncompressed | files, and I often produce images using a pipeline of several tools. | An uncompressed format is better for this. | | As a result, I've been storing images using PPM plus a homegrown | format, not PNG. That was always one of my gripes... I would have thought that every image format would have an uncompressed or nearly not compressed form... but PNG is pretty strict ... and yes I could see it cost you a bunch in terms of time... Its bad enough that not every PNG application compresses as well as the next, so I don't see where an uncompressed form would have hurt... but things are done now... | 3. Something like loGE breaks one of the fairly basic design decisions of | PNG: that pixel values are scaled (if necessary) during encoding to | use the entire 0 to 2^nbits-1 range for the displayable brightness | range from black to white, with no extra "footroom" or "headroom". Thats probably another sore point, in that PNG's way allows for definate "loss" in the process (the error factor is nill, but there nonetheless.)... But then again you are free to use a format similiar to PNG, but with the mild changes needed for your formats, and then publish the differences, then maybe sometime in the future PNG can be reimplemented with a new name and a few shortcomings solved... ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Thu Sep 26 22:06:23 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id WAA20082 for ; Thu, 26 Sep 1996 22:06:20 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id WAA11777 for png-list-outgoing; Thu, 26 Sep 1996 22:05:03 -0500 Received: from inet.htcnet.com (inet.htcnet.com [199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id WAA11769 for ; Thu, 26 Sep 1996 22:04:59 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id WAA17152 for ; Thu, 26 Sep 1996 22:09:03 -0500 Message-Id: <199609270309.WAA17152@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: Re: the fate of loGE Date: Thu, 26 Sep 1996 22:04:47 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List | > This is sort of a misnomer, as it is possible to just set the zlib compression | > level to "0", and you will get uncompressed data, although segmented up in | > chunks. If the issue is speed, then this will work. | | But don't let our "dirty little secret" of uncompressed PNG get | spread out too far into the public--yes, it's possible, and I | don't mind a writer or reader/writer combo that does it, but we | don't want anyone to make a reader that only accepts uncompressed | PNG calling itself a PNG reader. I don't think thats possible, not with the above idea... because ZLIB would still be in the code, and so there to handle all forms of compressed data, not just value 0... but I also take it that that is not truely uncompressed ... its segmented? If so, that doesn't help any ... I think I could show you examples where the compression overhead actually causes the end file to be larger ... not sure though .. (little 8x8 images...?) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 01:09:14 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id BAA21170 for ; Fri, 27 Sep 1996 01:09:12 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id BAA14510 for png-list-outgoing; Fri, 27 Sep 1996 01:07:41 -0500 Received: from enel.ucalgary.ca ([136.159.99.2]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id BAA14493 for ; Fri, 27 Sep 1996 01:07:33 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id AAA04183; Fri, 27 Sep 1996 00:07:22 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609270607.AAA04183@enel.ucalgary.ca> Subject: Discussion on dRNG (was CALL FOR VOTES on dRNG) To: png-list@dworkin.wustl.edu Date: Fri, 27 Sep 1996 00:07:21 -0600 (MDT) In-Reply-To: <199609270013.RAA04227@dawn13.CS.Berkeley.EDU> from "Adam M. Costello" at Sep 26, 96 05:13:46 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Adam writes: > > This chunk can be used when the pixel values do not occupy the > > full range of possible values, and when bit depth scaling is not > > appropriate. > > When is that, exactly? Scaling can be done in a reversible way. All > you might need would be a chunk that says which reversible function was > used. I think you are both in violent agreement. dRNG IS the chunk which describes the reversible function used to do the scaling. What the spec is saying is that left-bit replication or other "bit-depth" scaling which forces 2^n - 1 = white and 0 = black as per the PNG spec is not always appropriate. It is interesting to note that Carl (I think) mentions in his recent post that it is a "deficieny" of PNG that there is no "headroom" or "footroom" for the pixel values, and suggests that a new format be created (along with an "uncompressed" version) - shame on you (:-). This is the whole point of the dRNG chunk - creating "headroom" and "footroom" for an image. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 01:24:34 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id BAA21241 for ; Fri, 27 Sep 1996 01:24:31 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id BAA14805 for png-list-outgoing; Fri, 27 Sep 1996 01:22:51 -0500 Received: from enel.ucalgary.ca ([136.159.99.2]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id BAA14800 for ; Fri, 27 Sep 1996 01:22:44 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id AAA04204; Fri, 27 Sep 1996 00:22:33 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609270622.AAA04204@enel.ucalgary.ca> Subject: Re: the fate of loGE To: png-list@dworkin.wustl.edu Date: Fri, 27 Sep 1996 00:22:33 -0600 (MDT) In-Reply-To: <199609270309.WAA17152@inet.htcnet.com> from "Carl Morris" at Sep 26, 96 10:04:47 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Lee writes: > | But don't let our "dirty little secret" of uncompressed PNG get > | spread out too far into the public--yes, it's possible, and I > | don't mind a writer or reader/writer combo that does it, but we > | don't want anyone to make a reader that only accepts uncompressed > | PNG calling itself a PNG reader. I never suggested a special case DEcoder, just a special case ENcoder. Sorry if it didn't come out that way. Even so, the PNG spec even says that reducing compression levels can speed things up. Carl replies: > I don't think thats possible, not with the above idea... because ZLIB > would still be in the code, and so there to handle all forms of > compressed data, not just value 0... but I also take it that that is > not truely uncompressed ... its segmented? If so, that doesn't help > any ... I think I could show you examples where the compression > overhead actually causes the end file to be larger ... not sure though > .. (little 8x8 images...?) You are correct in saying that ZLIB compression level 0 is not EQUIVALENT to a raw image dump, but even then you would probably segment the raw image data into IDAT chunks, which has a 12 byte overhead per IDAT chunk (length+chunk name+CRC - about 0.15% for 8K chunks or 0.03% for 32K chunks). In zlib.h it says that at most it will add 0.1% + 12 bytes to the input data if it is storing the data uncompressed (ie compression level 0 or if the data "compresses" to be larger than the original data"). Carl, with the new knowledge of ZLIB compression level 0, and dRNG you should be able to put your ideas for a new format away... Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 05:15:12 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id FAA22739 for ; Fri, 27 Sep 1996 05:15:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA16901 for png-list-outgoing; Fri, 27 Sep 1996 05:13:38 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id FAA16895 for ; Fri, 27 Sep 1996 05:13:29 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id MAA06179 for png-list@dworkin.wustl.edu; Fri, 27 Sep 1996 12:13:06 +0200 (DST) Date: Fri, 27 Sep 1996 12:13:06 +0200 (DST) From: Chris Lilley Message-Id: <9609271213.ZM6177@grommit.inria.fr> In-Reply-To: Tom Lane "Re: sRGB proposed chunk" (Sep 26, 12:10am) References: <18736.843711004@sss.pgh.pa.us> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: sRGB proposed chunk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 26, 12:10am, Tom Lane wrote: > Glenn says: > >> I have a real problem with this, where a png editor can perform > >> a perfectly legal operation on a legal png file and create a new > >> png file that is deemed "invalid" by some all-knowing decoder: > >> The legal file is one with srGB and no gAMA or cHRM. > > This strikes me as a good argument for *requiring*, not merely > suggesting, that an encoder that writes srGB also write gAMA and cHRM > with the appropriate values. Yes. I think the original proposal says should wheremust would be better. > If this is done then the risk seems > fairly small; to get to an inconsistent file you need to assume that > the file has previously passed through a PNG editor that discards gAMA > and cHRM but not srGB. It's fairly unlikely that an editor would > discard known chunks but keep unknown ones. Yes. And the registered chunk would be cHRM, not cHRm. If the image editor futzes around with the image date - like color correction, doing gamma correction on the pixels, etc - and writes new gAMA and cHRM, it should discard sRGB because of the unsafe-to-copy. This applies whether it understands sRGB or not. An image editor that discards gAMA needs a swift email sent to the program author. > Lee says: > > we'll have to interpret gAMA and cHRM as "crude estimates" of srGB when > > the latter is present--i.e. the decoder will use gAMA/cHRM if it > > only knows those, but perfer srGB if it can. And define that srGB > > is always presumed to take precedence. > > I think we're all saying the same thing in different ways: if both > srGB and gAMA/cHRM are present, an srGB-aware decoder should believe > srGB in preference to the others. Yes. The supplied value for gAMA isthe closest approximation to the actual curve, given that gAMA is a single number; the values in cHRM are exacly the same as those used for sRGB. Giving the exact values to use in the definition of the sRGB chunk should eliminate problems here, I think. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 05:35:01 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id FAA22939 for ; Fri, 27 Sep 1996 05:35:00 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA17072 for png-list-outgoing; Fri, 27 Sep 1996 05:33:40 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id FAA17063 for ; Fri, 27 Sep 1996 05:33:37 -0500 Date: Fri, 27 Sep 96 6:31:30 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: CALL FOR VOTES on dRNG Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609270631.aa25152@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Thu, 26 Sep 1996 17:13:46 -0700 }Subject: Re: CALL FOR VOTES on dRNG }From: "Adam M. Costello" }The dRNG proposal says: } }> This chunk can be used when the pixel values do not occupy the }> full range of possible values, and when bit depth scaling is not }> appropriate. } }When is that, exactly? Scaling can be done in a reversible way. All }you might need would be a chunk that says which reversible function was }used. Such as drNG? ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 05:35:01 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id FAA22940 for ; Fri, 27 Sep 1996 05:35:00 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA17071 for png-list-outgoing; Fri, 27 Sep 1996 05:33:40 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id FAA17060 for ; Fri, 27 Sep 1996 05:33:36 -0500 Date: Fri, 27 Sep 96 6:29:07 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: the fate of loGE Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609270629.aa24955@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Dave wrote: }2. However, it isn't clear that I would use PNG in my work even if loGE was } available, because of compression overhead. PNG doesn't allow uncompressed } files, and I often produce images using a pipeline of several tools. } An uncompressed format is better for this. } } As a result, I've been storing images using PPM plus a homegrown } format, not PNG. } We can never allow a public uncompressed version of PNG because people would use it to deliver images over the net. There's no reason you can't use a private UdAT chunk, though. Works fine. Homegrown, but *is* PNG. :-) ../glennrp :wq ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 05:46:21 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id FAA23030 for ; Fri, 27 Sep 1996 05:46:12 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA17151 for png-list-outgoing; Fri, 27 Sep 1996 05:44:41 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id FAA17145 for ; Fri, 27 Sep 1996 05:44:38 -0500 Date: Fri, 27 Sep 96 6:38:31 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: sRGB proposed chunk Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609270638.aa25332@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Fri, 27 Sep 1996 12:13:06 +0200 (DST) }From: Chris Lilley }Subject: Re: sRGB proposed chunk }On Sep 26, 12:10am, Tom Lane wrote: }> Glenn says: }> >> I have a real problem with this, where a png editor can perform }> >> a perfectly legal operation on a legal png file and create a new }> >> png file that is deemed "invalid" by some all-knowing decoder: }> >> The legal file is one with srGB and no gAMA or cHRM. }> }> This strikes me as a good argument for *requiring*, not merely }> suggesting, that an encoder that writes srGB also write gAMA and cHRM }> with the appropriate values. } }Yes. I think the original proposal says should wheremust would be better. We have had arguments before about making requirements on one ancillary chunk based on the contents of another ancillary chunk. It just doesn't work. But the wording we have now (not in front of me right now) that ensure that there is no circumstance where a decoder has to interpret both sRGB and cHRM seems sufficien;t. ..?glennrp } }> If this is done then the risk seems }> fairly small; to get to an inconsistent file you need to assume that }> the file has previously passed through a PNG editor that discards gAMA }> and cHRM but not srGB. It's fairly unlikely that an editor would }> discard known chunks but keep unknown ones. } }Yes. And the registered chunk would be cHRM, not cHRm. If the image }editor futzes around with the image date - like color correction, doing }gamma correction on the pixels, etc - and writes new gAMA and cHRM, it }should discard sRGB because of the unsafe-to-copy. This applies whether }it understands sRGB or not. } }An image editor that discards gAMA needs a swift email sent to the }program author. } }> Lee says: }> > we'll have to interpret gAMA and cHRM as "crude estimates" of srGB when }> > the latter is present--i.e. the decoder will use gAMA/cHRM if it }> > only knows those, but perfer srGB if it can. And define that srGB }> > is always presumed to take precedence. }> }> I think we're all saying the same thing in different ways: if both }> srGB and gAMA/cHRM are present, an srGB-aware decoder should believe }> srGB in preference to the others. } }Yes. The supplied value for gAMA isthe closest approximation to the }actual curve, given that gAMA is a single number; the values in cHRM }are exacly the same as those used for sRGB. Giving the exact values }to use in the definition of the sRGB chunk should eliminate problems }here, I think. } } }-- }Chris Lilley, W3C [ http://www.w3.org/ ] }Graphics and Fonts Guy The World Wide Web Consortium }http://www.w3.org/people/chris/ INRIA, Projet W3C }chris@w3.org 2004 Rt des Lucioles / BP 93 }+33 93 65 79 87 06902 Sophia Antipolis Cedex, France } }------------------------------------------------------------ }To find out more about the mailing list server, send mail to }png-list-request@dworkin.wustl.edu }with the word "help" (and nothing else) in the message body. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 06:22:12 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id GAA23170 for ; Fri, 27 Sep 1996 06:22:11 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id GAA17414 for png-list-outgoing; Fri, 27 Sep 1996 06:22:07 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id GAA17409 for ; Fri, 27 Sep 1996 06:22:03 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id NAA06376 for png-list@dworkin.wustl.edu; Fri, 27 Sep 1996 13:21:55 +0200 (DST) Date: Fri, 27 Sep 1996 13:21:55 +0200 (DST) From: Chris Lilley Message-Id: <9609271321.ZM6374@grommit.inria.fr> In-Reply-To: Tom Lane "Re: sRGB proposed chunk" (Sep 25, 1:28pm) References: <16052.843672526@sss.pgh.pa.us> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: sRGB proposed chunk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 25, 1:28pm, Tom Lane wrote: > If a file containing an sRGB chunk has gAMA and/or cHRM chunks > with values other than those given here, the file is incorrect. Fine. I agree this is an incorrect file. > In such a case it is recommended that sRGB-aware decoders use > the sRGB values and ignore the gAMA and cHRM chunks. Stonger. I would say must. But yes, this is error correction. Decoders which understand and can process an sRGB-tagged image will always ignore gAMA and CHRM anyways. Decoders which have heard of sRGB chunk but can't do anything with it can ignore gAMA and cHRM if they have invalid values - in fact they can ignore those chunks regardless of their values if they meet a cHRM chunk Decoders which have not heard of sRGB chunk will use the incorrect values, since they don't know the valiues are incorrect. The fault is with the encoder that wrote the invalid file, not the decoder. Editors which have heard of sRGB chunk but can't do anything with it will know to discard sRGB if they alter gAMA or cHRM. Since it is hard to imagine when this would be done without also altering the image data, editorswhich have not heard of the sRGB chunk will also correctly discard it in such a circumstance. Editors such as the PNG optimiser that gets mentioned every now and again must discard the incorrect gAMA and cHRM chunks and substitute correct ones on encountering such a file. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 06:44:30 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id GAA23366 for ; Fri, 27 Sep 1996 06:44:29 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id GAA17546 for png-list-outgoing; Fri, 27 Sep 1996 06:44:34 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id GAA17540 for ; Fri, 27 Sep 1996 06:44:29 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id NAA06390 for png-list@dworkin.wustl.edu; Fri, 27 Sep 1996 13:44:23 +0200 (DST) Date: Fri, 27 Sep 1996 13:44:23 +0200 (DST) From: Chris Lilley Message-Id: <9609271344.ZM6388@grommit.inria.fr> In-Reply-To: John Bowler "Re: sRGB proposed chunk" (Sep 25, 10:28am) References: <199609251728.KAA09315@mega.megamed.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: sRGB proposed chunk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 25, 10:28am, John Bowler wrote: > At 14:29 25/09/96 +0200, Chris Lilley wrote: > >No. The important extra is all the extra information that is being > >passed by reference, all of which is fixed, apart from the intent value. > >That is why that one item is included in the chunk. sRGB is not just > >adding one extra item of information. It adds all this, mainly describing > >the reference viewing conditions: > > [list of stuff] > Illuminant white, chromacity are in cHRM, yes > transfer characteristics are represented in gAMA. yes > Both cHRM and gAMA lose some information no, only gAMA >(z values, No. Check out what z means. > full 709 transfer function) yes, except it isn't the 709 transfer function. But it does have a linear portion. > My limited understanding of color, however, suggests that image surround, > typical ambient light information, viewing flare are properties of the > viewing environment not of the image. No. These are properties of how the image was constructed. They are properties of the creation environment. They provide information about the color appearance of the original image. > This reflects, I believe, the fact > that sRGB is more than just an image specification - it is a > default/recommended behavior for monitors. Sort of. Most profiles describe the device that created them - like a scanner or camers - and thus require correction for display. sRGB describes the characteristics of the device the image was created for; if the actual viewing device and conditions are different, correction is required. Compared to your typical scanner profile with itscomplex transfer curve that needs correcting, an sRGB image can reasonably be displayed as is, with no processing, on a system that does no gamma correction (eg a PC) and it will look reasonable. > The Encoding illuminant information is, I suspect useful when displaying the > image (this is at, or beyond, the limit of my understanding), but I would > argue that, if this is so, it should be possible to store that information > in a separate PNG chunk. No, not really. I suggest you expand your understanding before proposing a change. Matthew Anderson, matta@microsoft.com, would be able to help you there. > Note that this does not, in any way, imply that srGB is a bad idea Good. Glad you like it. > Win32 is the name of a specific API which supports color management (via the > ICM APIs) and with which I am familiar. OK. I gather that ICM is being upgraded and that a future version of Windows 9x where x>6 will provide an improved, ICC-compliant CMS. > MacOS supports color management (via the ColorSync stuff) - I am not > familiar with this. There needs to be some way of satisfactorily mapping > from the srGB (chunk) intent and the other sRGB (spec) intents into the > MacOS support. There is. sRGB is the name of an ICC profile. ColorSync 2 can read such profiles in addition to it's own format. ColorSync is then responsible for accurately rendering the colors in the image. This is already sorted out. Same goes for the Color Management System that ships with Irix 6.2 for Silicon Graphics systems. The mapping is already defined and is trivial. > This probably isn't a major issue for sRGB, but it is for > PNG because we do not want to put something into the spec which meets an OS > independent requirement but which is, itself, OS dependent. I'm fairly sure > srGB is satisfactory from this point of view, but I'd like to hear > confirmation from somewhere. ICC-compliant Color Management Systems are native to MacOS 7.5.x and Irix 6.2 and are available for MacOS, Solaris 2.5, Windows95 and Windows NT 4.0 from third parties. They may be available for other unixes as well; these are just the platforms that I am aware of. Systems which understand the sRGB information without having full generic ICC support are also possible; the specification is open, the meaning of the terms is as defined in the appropriate international standards, which are also in this instance the industry standards. Someone with an interest in color, who is developing for any arbitrary minority platform can code up a viewer which uses the information contained in and implied by the sRGB chunk if they wish to do so. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 06:52:52 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id GAA23409 for ; Fri, 27 Sep 1996 06:52:42 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id GAA17603 for png-list-outgoing; Fri, 27 Sep 1996 06:52:49 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id GAA17597 for ; Fri, 27 Sep 1996 06:52:44 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id NAA06396 for png-list@dworkin.wustl.edu; Fri, 27 Sep 1996 13:52:39 +0200 (DST) Date: Fri, 27 Sep 1996 13:52:39 +0200 (DST) From: Chris Lilley Message-Id: <9609271352.ZM6394@grommit.inria.fr> In-Reply-To: John Bowler "Re: sRGB proposed chunk" (Sep 25, 9:49am) References: <199609251649.JAA07907@mega.megamed.com> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: sRGB proposed chunk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 25, 9:49am, John Bowler wrote: > Unfortunately there are already ICC-profile-aware applications which handle > PNG data (and, in particular, handle cHRM and gAMA) but do not recognize the > sRGB chunk. Well fine, since the chunk only got proposed very recently . Could you tell me the names of those ICC-aware applications that handle gAMA and cHRM? This is very interesting. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 07:35:59 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id HAA23800 for ; Fri, 27 Sep 1996 07:35:58 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA17947 for png-list-outgoing; Fri, 27 Sep 1996 07:35:56 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id HAA17941 for ; Fri, 27 Sep 1996 07:35:53 -0500 Date: Fri, 27 Sep 96 8:32:02 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: sRGB proposed chunk Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609270832.aa29429@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Fri, 27 Sep 1996 13:21:55 +0200 (DST) }From: Chris Lilley }Subject: Re: sRGB proposed chunk }On Sep 25, 1:28pm, Tom Lane wrote: } }> If a file containing an sRGB chunk has gAMA and/or cHRM chunks }> with values other than those given here, the file is incorrect. } }Fine. I agree this is an incorrect file. Only the PNG police care whether it is "incorrect" or "inconsistent". } }> In such a case it is recommended that sRGB-aware decoders use }> the sRGB values and ignore the gAMA and cHRM chunks. } }Stonger. I would say must. But yes, this is error correction. } }Decoders which understand and can process an sRGB-tagged image }will always ignore gAMA and CHRM anyways. } }Decoders which have heard of sRGB chunk but can't do anything with }it can ignore gAMA and cHRM if they have invalid values - in fact }they can ignore those chunks regardless of their values if they }meet a [srGB] chunk They can ignore gAMA and cHRM of srGB is present. They don't give a hoot whether they contain values that are consistent with srGB or not. } }Decoders which have not heard of sRGB chunk will use the incorrect }values, since they don't know the valiues are incorrect. The fault }is with the encoder that wrote the invalid file, not the decoder. Agreed. Except I call it an inconsistent file, not an invalid file, for reasons I have explained in a previous message. } }Editors which have heard of sRGB chunk but can't do anything with it }will know to discard sRGB if they alter gAMA or cHRM. Since it is hard to }imagine when this would be done without also altering the image data, }editorswhich have not heard of the sRGB chunk will also correctly }discard it in such a circumstance. Agreed. } }Editors such as the PNG optimiser that gets mentioned every now and }again must discard the incorrect gAMA and cHRM chunks and substitute }correct ones on encountering such a file. This doesn't seem to be a job for an optimizer whose business is recompressing and refiltering the IDATs. Granted, the optimizer has to recognize sRGB, cHRM, and gAMA, because if it doesn't it is forced to discard them according to the chunk-copying rules. It is, however, an appropriate job for a png quality-checker. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 08:16:13 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id IAA24217 for ; Fri, 27 Sep 1996 08:16:12 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA18401 for png-list-outgoing; Fri, 27 Sep 1996 08:16:06 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA18396 for ; Fri, 27 Sep 1996 08:16:03 -0500 Date: Fri, 27 Sep 96 9:14:54 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Discussion on pCAL Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609270914.aa01015@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }From: Andreas Dilger }Subject: Discussion on pCAL }Date: Thu, 26 Sep 1996 15:50:52 -0600 (MDT) }I was ready to put in a CFV for pCAL, but after reading the spec once more }(version 19960914), I came upon the addition of "purpose" which I don't }remember seeing before. The spec gives the reason for the "purpose" }field as being useful for multi-image files. However, I can't see this }at all - surely the data in the PNG file only has one true physical value? True }If there are multiple images, and multiple pCAL values, the pCAL should }be stored with the relevant PNG sub-image, or potentially a single pCAL }useful for a whole series of images can be stored at the top of the file. You could have a series of images that you plan to display in composite frames. Each frame has a subimage with a pressure field and another with a vorticity field. You'd lead off with a PNG basis "image" that contains nothing but your library of pcAL and faLT chunks and maybe a dummy 1x1 IDAT. Such a PNG image would be invalid if you tried to display it by itself because of the multiple pcAL and faLT chunks. You'd use the INHR and SBYK mechanism to pick out the ones you need in the subsequent images. In an actual PNG file only one would be allowed, just as in an actual PNG file only one faLT chunk is allowed. }pCAL isn't the same as fALS in that there may be various useful ways of }looking at a dataset - it represents the actual data values, of which }there can be only one. True, but in a multiple image context there can be multiple datasets in the file. } }I guess we need to wait another 2 weeks for this one. Only if you insist on removing the "purpose" field. If your application doesn't need it, it's fairly harmless, requiring you to supply a single meaningless ASCII character and a null. }There are no other }chunks that I'm interested in enough to do the CFV myself. } }Cheers, Andreas. }-- }Andreas Dilger University of Calgary \"If a man ate a pound of pasta and }(403) 220-8792 Micronet Research Group \ a pound of antipasto, would they }Dept of Electrical & Computer Engineering \ cancel out, leaving him still }http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert } }------------------------------------------------------------ }To find out more about the mailing list server, send mail to }png-list-request@dworkin.wustl.edu }with the word "help" (and nothing else) in the message body. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 08:36:16 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id IAA24868 for ; Fri, 27 Sep 1996 08:36:15 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA18577 for png-list-outgoing; Fri, 27 Sep 1996 08:36:11 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA18568 for ; Fri, 27 Sep 1996 08:36:07 -0500 Date: Fri, 27 Sep 96 9:32:22 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: CALL FOR VOTES on dRNG Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609270932.aa01600@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }From: Andreas Dilger }Subject: CALL FOR VOTES on dRNG }Date: Thu, 26 Sep 1996 15:37:15 -0600 (MDT) } }Note that in the png-scivis-chunks-19960914.txt.gz file, the description }of the dRNG "ratio" should specify "output_bit_depth" instead of "bit_depth", }and also under the discussion of indexed color images immediately below. }This vote on dRNG/DRNG is based on these minor changes. OK. Also, if the chunk should happen to be approved, the editor would add a clarifying sentence saying that for other color types, the output_bit_depth is the same as the bit_depth in IHDR. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 08:41:09 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id IAA25004 for ; Fri, 27 Sep 1996 08:41:06 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA18636 for png-list-outgoing; Fri, 27 Sep 1996 08:41:13 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA18630 for ; Fri, 27 Sep 1996 08:41:05 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id PAA06790 for png-list@dworkin.wustl.edu; Fri, 27 Sep 1996 15:40:59 +0200 (DST) Date: Fri, 27 Sep 1996 15:40:59 +0200 (DST) From: Chris Lilley Message-Id: <9609271540.ZM6788@grommit.inria.fr> In-Reply-To: davem@cs.ubc.ca (Dave Martindale) "Re: sRGB proposed chunk" (Sep 26, 10:10am) References: X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: sRGB proposed chunk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 26, 10:10am, Dave Martindale wrote: > Glenn writes: > >gAMA 45000 *is* a crude estimate. The proposed sRGB profile described > >in the stokes document uses gamma=1/2.2, which is .454545... or gAMA 45455 No, sRGB specification uses a transfer function which I quoted earlier.. > >Chris L or Dave M, please respond. > > I haven't looked at the "stokes document" directly, If you wish to do so, it's at http://www.hpl.hp.com/personal/Michael_Stokes/srgb.htm > but in Chris Lilley's message of Sept 25 he quotes: > > Transfer Characteristic for i=r,g,b > if i <= 0.00304, i' = 12.92 * i > else i' = 1.055* (i^(1/2.4)) - 0.055 > > I've graphed this, and it's an amazingly close fit to a simple power > function with an exponent (gamma) of 0.45000. It was specifically designed to be an amazingly close fit to 0.45 > The sRGB transfer function > uses the multiply by 1.055 and the subtraction of 0.055 to "splice" the > straight-line and power-function parts of the curve together, but the > multiply by 1.055 also changes the shape of the power-function portion > of the curve. Just like the 709 curve > The change in exponent from 1/2.2222 (0.45) to 1/2.4 (0.41667) > mostly compensates for this, unlike the 709 curve ;-) > resulting in a function that very closely > tracks the simple y = x^0.45 power function. So gAMA of 45000 is indeed > quite an accurate approximation to the sRGB transfer function, [...] > 45000 is simpler and will look familiar > to people, so I suggest we leave that as the recommendation. I concur. > > When the srGB chunk is present, applications that recognize the > > srGB chunk and are capable of processing the ICC sRGB profile > > should ignore the gAMA and cHRM chunks and process the srGB chunk > > instead. Applications that recognize the srGB chunk but are not > > capable of processing the full sRGB profile data can also ignore > > any gAMA and cHRM chunks and instead use the values of gAMA and > > cHRM given above as though they had appeared in gAMA and cHRM chunks. > > That sounds good. It sounds good but in keeping with the core spec I would like some rationale in there. So folk not only know what to do, but also why we do it and that, yes, we did consider the idea they just thought of but what is in the spec is actually better because ... How about When the srGB chunk is present, applications that recognize the srGB chunk and are capable of processing the ICC sRGB profile should ignore the gAMA and cHRM chunks and process the srGB chunk instead, as this gives a more precise version of the same information. Applications that recognize the srGB chunk but are not capable of processing the full sRGB profile data should also ignore the gAMA and cHRM chunks, since they already know the values which they should contain, and instead use the values of gAMA and cHRM given above as though they had appeared in gAMA and cHRM chunks. Note for any future editing of these paragraphs: retain "the ICC sRGB profile" rather than "ICC profiles" because some applications might be able to handle sRGB but not an arbitrary ICC profile. I changed "any" to "the" because the chunk description says (or should say) that these chunks must be created by an application that writes the sRGB chunk and that those chunks must contain the given values. Any implies that the chunks could likely be missing or that they are optional. I added a brief description of why the chunks should be ignored. As Dave confirms, the specified transfer curve is very close to a 0.45 power curve. sRGB just gives a slightly more precise version of the same information. I wondered about appendng to the second paragraph "This provides an efficiency saving compared to decoding the two chunks, and a measure of resiliency if the gAMA or cHRM chunk should erroneously contain different values." -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 08:53:37 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id IAA25398 for ; Fri, 27 Sep 1996 08:53:36 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA19033 for png-list-outgoing; Fri, 27 Sep 1996 08:53:41 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA19026 for ; Fri, 27 Sep 1996 08:53:36 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id PAA06796 for png-list@dworkin.wustl.edu; Fri, 27 Sep 1996 15:53:29 +0200 (DST) Date: Fri, 27 Sep 1996 15:53:29 +0200 (DST) From: Chris Lilley Message-Id: <9609271553.ZM6794@grommit.inria.fr> In-Reply-To: adilger@enel.ucalgary.ca (Andreas Dilger) "Re: New chunk registration procedure 199609245" (Sep 26, 1:04pm) References: <199609261904.NAA04681@munet-h.enel.ucalgary.ca> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: New chunk registration procedure 199609245 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 26, 1:04pm, Andreas Dilger wrote: > As an aside, I don't really like the way this whole thing is going. For > the PNG development, which was much more complex than this, we all accepted > that the members of this list were rational adults, and that cheating, > ballot stuffing, etc, was unthinkable. Yep. Problem was, we all became rather good at writing specifications, so as soon as something like voting rules came up, we all threw ourselves into writing a meta-specification. > We made PNG expandable for the reason that we don't know what everyone wants > to do with it, and rather than trying to hamstring developers (which is futile > in the end anyways - look at all of the "standard" x-??? MIME types), Oh, good one. Yes. Having subscribed to the IETF/IANA types list for 18 months, 2 years, something like that, I must agree here. > The last thing we want is for a private chunk to become a defacto > standard because we don't want to approve it. Yes. The whole Chemical MIME scandal is a prime example of what happens when an allegedly lightweight registrsation process isn't. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 08:56:20 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id IAA25435 for ; Fri, 27 Sep 1996 08:56:19 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA19186 for png-list-outgoing; Fri, 27 Sep 1996 08:56:26 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA19176 for ; Fri, 27 Sep 1996 08:56:22 -0500 Date: Fri, 27 Sep 96 9:53:08 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New chunk registration procedure 199609245 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609270953.aa01963@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Message-ID: }Subject: RE: New chunk registration procedure 199609245 }Date: Thu, 26 Sep 1996 14:29:50 -0700 }>From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB[SMTP:glennrp@ARL.MIL] }> }>I want to put this thing to bed so we can start voting on real issues. }>Hoping for some consensus, I pointed out that Todd's chunks and sPLT }>had been in the hopper for a year. Instead we got this, which threatens to }>drag out until we all get bored with it, and certainly has put off }>any action on Todd's chunks and sPLT for a couple of months. } }I hope not - 2 weeks if we don't waste time arguing small points. This }on the basis that someone suggested we should vote for this process }using the process (probably a reasonable sanity check) and that the }discussion/stability period for actual chunks could start when the }voting period for the process started. So this is a minimum elapsed }time of 6 weeks to approve, for example, sPLT. Six weeks from now, minimum, plus 20 days already spent working out the registration process, := a couple of months. And I haven't seen good evidence that we won't waste time arguing small points. I believe we do have consensus, though, on the major parts of the concept: - 180 days since first submission for voter eligibility [in mpng-list I will suggest a shorter time like 90 days because the list hasn't been around so long] - 2-week discussion period - 2-week voting period - votes submitted publicly to png-list - [at least] 10 votes to approve - 2:1 YES:NO required to approve - rejected chunks not to be re-voted unless external conditions change, the proposal changes, or sufficent time [180 days?] has elapsed. The rest is formality and perhaps unnecessary. I have not even decided to vote YES on the process because I think the formality may actually be destructive; consensus on the above seems to me to be sufficent. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 09:16:37 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id JAA25632 for ; Fri, 27 Sep 1996 09:16:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA19743 for png-list-outgoing; Fri, 27 Sep 1996 09:16:30 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA19735 for ; Fri, 27 Sep 1996 09:16:24 -0500 Date: Fri, 27 Sep 96 10:08:09 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: sRGB proposed chunk Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609271008.aa02174@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Fri, 27 Sep 1996 15:40:59 +0200 (DST) }From: Chris Lilley }Subject: Re: sRGB proposed chunk }On Sep 26, 10:10am, Dave Martindale wrote: } }> Glenn writes: }> >gAMA 45000 *is* a crude estimate. The proposed sRGB profile described }> >in the stokes document uses gamma=1/2.2, which is .454545... or gAMA 45455 } }No, sRGB specification uses a transfer function which I quoted earlier.. Yes, I agree now. 45000 is the right number to use.. }How about } } When the srGB chunk is present, applications that recognize the } srGB chunk and are capable of processing the ICC sRGB profile } should ignore the gAMA and cHRM chunks and process the srGB chunk } instead, as this gives a more precise version of the same } information. } } Applications that recognize the srGB chunk but are not capable } of processing the full sRGB profile data should also ignore the } gAMA and cHRM chunks, since they already know the values which } they should contain, and instead use the values of gAMA and cHRM } given above as though they had appeared in gAMA and cHRM chunks. That sounds very good. } } }Note for any future editing of these paragraphs: retain "the ICC sRGB }profile" rather than "ICC profiles" because some applications might be }able to handle sRGB but not an arbitrary ICC profile. OK } }I changed "any" to "the" because the chunk description says (or should }say) that these chunks must be created by an application that writes the }sRGB chunk and that those chunks must contain the given values. Any }implies that the chunks could likely be missing or that they are optional. OK } }I added a brief description of why the chunks should be ignored. As Dave }confirms, the specified transfer curve is very close to a 0.45 power curve. }sRGB just gives a slightly more precise version of the same information. Good } }I wondered about appendng to the second paragraph "This provides an }efficiency saving compared to decoding the two chunks, and a measure of }resiliency if the gAMA or cHRM chunk should erroneously contain different }values." It would only be efficient if we could guarantee that srGB would occur ahead of gAMA and cHRM in the stream. I don't think we can. Which reminds me that the usual sentence is needed: Only one instance of the srGB chunk is permitted in a PNG datastream. If it appears, it must appear ahead of the IDAT chunk, and ahead of the PLTE chunk, if the PLTE chunk is present. Also the summary table needs to say "Before PLTE and IDAT" instead of "Before IDAT". (I am assuming that the same rationale that requires gAMA and cHRM to precede PLTE also applies to srGB) ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 09:26:29 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id JAA25693 for ; Fri, 27 Sep 1996 09:26:28 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA19942 for png-list-outgoing; Fri, 27 Sep 1996 09:26:30 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA19937 for ; Fri, 27 Sep 1996 09:26:25 -0500 Date: Fri, 27 Sep 96 10:23:54 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: CALL FOR VOTES on dRNG Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609271023.aa02730@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Thu, 26 Sep 1996 17:13:46 -0700 }Subject: Re: CALL FOR VOTES on dRNG }From: "Adam M. Costello" }The dRNG proposal says: } }> This chunk can be used when the pixel values do not occupy the }> full range of possible values, and when bit depth scaling is not }> appropriate. } }When is that, exactly? Scaling can be done in a reversible way. All }you might need would be a chunk that says which reversible function was }used. } }Well, there is an exception: if max_value - min_value is greater than }2^16, you can't do the scaling reversibly. } }The proposal then says: } }> It can also be used to enhance contrast by scaling to a larger range }> than the actual range of pixel values. } }This opens up a more general scenario. There are some original (perhaps }scanned) samples, and the image creator wants those samples preserved }in the file. But there are some transformations of the image which }the creator recommends for making the image more viewable. These are }the same transformations that any viewing software might put under the }control of the user. Think of the image creator suggesting initial }values for all of xv's knobs. How useful is this, and how general would }we want to make it? The bragzone color lena image is a good example of this. It's way too red, and the appearance is much more natural IMHO with drNG 0 315 0 255 0 255. If you have an SGI you can see for yourself. ARL viewpng can insert a drng chunk if one does not appear in the file, using a commandline option "-drng 0 315 0 255 0 255". It also recognizes the drNG chunk if present (there's none in swride's lena_d16.mng or in any image that I've made public). } }The proposal then says: } }> It can be used to correct the brightness of an image that has been }> scaled by zero-filling rather than linear scaling. } }sBIT already takes care of that. Right, you pointed that out two or three weeks ago and I've put that into viewpng. (with viewpng, use -sbit 3 3 2 or the like to insert an sBIT chunk, or -sbit 0 0 0 to ignore an sBIT chunk that is present in the datastream) Would you vote differently if this sentence were removed? ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 09:33:53 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id JAA25860 for ; Fri, 27 Sep 1996 09:33:52 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA20169 for png-list-outgoing; Fri, 27 Sep 1996 09:33:52 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA20152 for ; Fri, 27 Sep 1996 09:33:34 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id KAA24580 for ; Fri, 27 Sep 1996 10:33:20 -0400 (EDT) To: PNG List Subject: Re: sRGB proposed chunk In-reply-to: Your message of Fri, 27 Sep 96 10:08:09 EDT <9609271008.aa02174@THOR.ARL.MIL> Date: Fri, 27 Sep 1996 10:33:20 -0400 Message-ID: <24578.843834800@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > }I wondered about appendng to the second paragraph "This provides an > }efficiency saving compared to decoding the two chunks, and a measure of > }resiliency if the gAMA or cHRM chunk should erroneously contain different > }values." > It would only be efficient if we could guarantee that srGB would occur > ahead of gAMA and cHRM in the stream. I don't think we can. The time savings would be minuscule anyway, certainly not worth citing as a justification. The resiliency argument is the one to use. How about: Using the sRGB values in preference to gAMA/cHRM provides a measure of resiliency in case a non-sRGB-aware PNG editor erroneously changes gAMA or cHRM. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 09:38:31 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id JAA25936 for ; Fri, 27 Sep 1996 09:38:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA20262 for png-list-outgoing; Fri, 27 Sep 1996 09:38:32 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA20257 for ; Fri, 27 Sep 1996 09:38:27 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id KAA24601 for ; Fri, 27 Sep 1996 10:38:15 -0400 (EDT) To: PNG List Subject: Re: New chunk registration procedure 199609245 In-reply-to: Your message of Fri, 27 Sep 96 9:53:08 EDT <9609270953.aa01963@THOR.ARL.MIL> Date: Fri, 27 Sep 1996 10:38:14 -0400 Message-ID: <24599.843835094@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn sez: > I believe we do have consensus, though, on the major parts of the concept: > - 180 days since first submission for voter eligibility > [in mpng-list I will suggest a shorter time like 90 days > because the list hasn't been around so long] > - 2-week discussion period > - 2-week voting period > - votes submitted publicly to png-list > - [at least] 10 votes to approve > - 2:1 YES:NO required to approve > - rejected chunks not to be re-voted unless external conditions > change, the proposal changes, or sufficent time [180 days?] > has elapsed. > The rest is formality and perhaps unnecessary. Y'know, I like this specification a whole lot better than the more formal one. If we left it just like this, we might discourage people from applying legalistic nitpicking skills. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 09:56:33 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id JAA26789 for ; Fri, 27 Sep 1996 09:56:32 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA20546 for png-list-outgoing; Fri, 27 Sep 1996 09:56:30 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id JAA20541 for ; Fri, 27 Sep 1996 09:56:27 -0500 Date: Fri, 27 Sep 96 10:56:11 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: VOTE on dRNG Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609271056.aa03579@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List YES dRNG ftp://swrinde.nde.swri.edi/pub/png-group/documents/ png-scivis-chunks-19960914 Glenn Randers-Pehrson ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 09:57:06 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id JAA26803 for ; Fri, 27 Sep 1996 09:57:03 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA20609 for png-list-outgoing; Fri, 27 Sep 1996 09:57:11 -0500 Received: from haven.uchicago.edu (haven.uchicago.edu [128.135.12.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA20599 for ; Fri, 27 Sep 1996 09:57:05 -0500 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by haven.uchicago.edu (8.7.5/8.7.3) with ESMTP id JAA15859; Fri, 27 Sep 1996 09:55:41 -0500 (CDT) Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.5/8.7.3) id JAA11707; Fri, 27 Sep 1996 09:56:39 -0500 (CDT) Date: Fri, 27 Sep 1996 09:56:39 -0500 (CDT) Message-Id: <199609271456.JAA11707@ellis.uchicago.edu> To: tcorat@theother.com Subject: Re: GIF to PNG converter Cc: png-list@dworkin.wustl.edu From: Cave Newt Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Tom, > We are small group of programmers who produced a very decent Internet > suite called the Other Internet Package. It is freely available from > our home page. I've heard of it... > Anyway, we always had the PNG feature on our list but never found the > time to implement it. We are looking at the libraries you guys put > together. I have one question. If we were to use your GIF to PNG > converter (I confess I haven't looked at it yet) would we have legal > problems with Unisys as I assume it contains the same algorithm? The only folks who could say for sure would be Unisys, and I'm sure you can guess what they'd *say*. The upshot is that it's not clear and won't be until someone takes it to court. The patent appears to claim protection for an LZW decoder only in the presence of a corresponding LZW encoder, or at least that's what I recall. But even if that's true (which Unisys dis- putes), there's still the potential problem of contributory infringement, which would be the case if your software (or gif2png) encouraged the use of infringing encoders. That seems pretty clearly not to be the case here, but then, many things that seem pretty clear to normal people do not seem that way to the courts or lawyers or USPTO. > Incidentally, I posted the situation on four news groups and only four > people responded. So much for online community standing up to big > corporations! I believe your message (comp.compression version) was reposted to the png-list mailing list, where it generated a fair amount of discussion for a few days. Others may be discussing it as well but not on Usenet, in hopes of staying below Unisys' radar. In any case, the PNG community is obviously doing its part; now it's up to users to start taking advantage of what we've created. I'll cc this to png-list and see if anyone else has input. PNG folks: remember to cc Tom explicitly (tcorat@theother.com). Tom: please don't MIME-encode ASCII text; it's pretty annoying to those of us with old mail programs... Greg ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 09:59:33 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id JAA26846 for ; Fri, 27 Sep 1996 09:59:32 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA20665 for png-list-outgoing; Fri, 27 Sep 1996 09:59:40 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA20659 for ; Fri, 27 Sep 1996 09:59:34 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id QAA06994 for png-list@dworkin.wustl.edu; Fri, 27 Sep 1996 16:59:27 +0200 (DST) Date: Fri, 27 Sep 1996 16:59:27 +0200 (DST) From: Chris Lilley Message-Id: <9609271659.ZM6992@grommit.inria.fr> In-Reply-To: Glenn Randers-Pehrson ARL-WMRD-TED-TIB "Re: sRGB proposed chunk" (Sep 27, 10:08am) References: <9609271008.aa02174@THOR.ARL.MIL> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: sRGB proposed chunk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 27, 10:08am, Glenn Randers-Pehrson ARL-WMRD-TED-TIB wrote: > [Chris wrote]: > }I wondered about appendng to the second paragraph "This provides an > }efficiency saving compared to decoding the two chunks, and a measure of > }resiliency if the gAMA or cHRM chunk should erroneously contain different > }values." > > It would only be efficient if we could guarantee that srGB would occur > ahead of gAMA and cHRM in the stream. I don't think we can. No, we can't. I appreciate the need to try and keep the chunks independant, and that we cannot specify ordering of chunks any more than the existing core spec already does. We already have an existing case in cHRM, where (in the appendix) we say "If it does so, the gAMA chunk should also be written; decoders can do little with cHRM if gAMA is missing." This case is much the same, except that if it writes sRGB it should also write gAMA and cHTM with these particular values. If it does, though, the decoder can skip reading the gAMA and cHRM chunks, checking the checksums etc. If it occurs after, the decoder should overwrite any values it may have read? Since I didn't really want to say that, I went for the language about just skipping the chunks instead. > Which reminds me that the usual sentence is needed: > > Only one instance of the srGB chunk is permitted in a PNG datastream. > If it appears, it must appear ahead of the IDAT chunk, and ahead of the > PLTE chunk, if the PLTE chunk is present. Yes, thanks. > Also the summary table needs to say "Before PLTE and IDAT" instead > of "Before IDAT". (I am assuming that the same rationale that requires > gAMA and cHRM to precede PLTE also applies to srGB) Yes. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 10:08:11 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id KAA26957 for ; Fri, 27 Sep 1996 10:08:10 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA20885 for png-list-outgoing; Fri, 27 Sep 1996 10:08:16 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA20876 for ; Fri, 27 Sep 1996 10:08:11 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id RAA07133 for png-list@dworkin.wustl.edu; Fri, 27 Sep 1996 17:08:03 +0200 (DST) Date: Fri, 27 Sep 1996 17:08:03 +0200 (DST) From: Chris Lilley Message-Id: <9609271708.ZM7131@grommit.inria.fr> In-Reply-To: Tom Lane "Re: sRGB proposed chunk" (Sep 27, 10:33am) References: <24578.843834800@sss.pgh.pa.us> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: sRGB proposed chunk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 27, 10:33am, Tom Lane wrote: > The time savings would be minuscule anyway, certainly not worth citing as > a justification. The resiliency argument is the one to use. I now concur > How about: > > Using the sRGB values in preference to gAMA/cHRM provides a > measure of resiliency in case a non-sRGB-aware PNG editor > erroneously changes gAMA or cHRM. Excellent. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 10:11:14 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id KAA26988 for ; Fri, 27 Sep 1996 10:11:13 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA20940 for png-list-outgoing; Fri, 27 Sep 1996 10:11:18 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA20932 for ; Fri, 27 Sep 1996 10:11:11 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id RAA07143 for png-list@dworkin.wustl.edu; Fri, 27 Sep 1996 17:11:03 +0200 (DST) Date: Fri, 27 Sep 1996 17:11:03 +0200 (DST) From: Chris Lilley Message-Id: <9609271711.ZM7141@grommit.inria.fr> In-Reply-To: Tom Lane "Re: New chunk registration procedure 199609245" (Sep 27, 10:38am) References: <24599.843835094@sss.pgh.pa.us> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: New chunk registration procedure 199609245 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 27, 10:38am, Tom Lane wrote: > Glenn sez: > > I believe we do have consensus, though, on the major parts of the concept: > > [short list deleted] > > The rest is formality and perhaps unnecessary. Quite > Y'know, I like this specification a whole lot better than the more > formal one. If we left it just like this, we might discourage people > from applying legalistic nitpicking skills. I must admit that this short list I read through and understood, wheras I put aside the more ISO-like documents to read later when I had time. And when Glenn's testing-the-waters call for votes came in, I put it aside until after I had read and understood the voting procedure ;-( -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 10:18:07 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id KAA27131 for ; Fri, 27 Sep 1996 10:18:04 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA21075 for png-list-outgoing; Fri, 27 Sep 1996 10:16:51 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id KAA21069 for ; Fri, 27 Sep 1996 10:16:47 -0500 Date: Fri, 27 Sep 96 11:15:56 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: sRGB proposed chunk Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609271115.aa03930@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List }I appreciate the need to try and keep the chunks independant, }and that we cannot specify ordering of chunks any more than the existing core }spec already does. } }We already have an existing case in cHRM, where (in the appendix) we say }"If it does so, the gAMA chunk should also be written; decoders can do }little with cHRM if gAMA is missing." } I have no problem with recommendations that use "should". It is just that I have a serious concern about declaring streams "invalid" based on adverse interactions between ancillary chunks. I think it our responsibility to make sure that the specification for any new registered chunk addresses such interactions and resolves them, in a manner that doesn't create any backward incompatiblity. The proposed statement (now two paragraphs) about the srGB/gAMA/cHRM precedence seems to do that adequately. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 10:34:37 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id KAA27332 for ; Fri, 27 Sep 1996 10:34:36 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA21327 for png-list-outgoing; Fri, 27 Sep 1996 10:34:30 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA21321 for ; Fri, 27 Sep 1996 10:34:26 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id LAA27050 for ; Fri, 27 Sep 1996 11:34:13 -0400 (EDT) To: PNG List Subject: Re: sRGB proposed chunk In-reply-to: Your message of Fri, 27 Sep 96 6:38:31 EDT <9609270638.aa25332@THOR.ARL.MIL> Date: Fri, 27 Sep 1996 11:34:13 -0400 Message-ID: <27048.843838453@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn Randers-Pehrson ARL-WMRD-TED-TIB writes: > }On Sep 26, 12:10am, Tom Lane wrote: > }> This strikes me as a good argument for *requiring*, not merely > }> suggesting, that an encoder that writes srGB also write gAMA and cHRM > }> with the appropriate values. > We have had arguments before about making requirements on one ancillary chunk > based on the contents of another ancillary chunk. It just doesn't work. Agreed, we cannot assume that a file containing srGB will contain matching gAMA/cHRM values; a PNG editor aware of the meaning of only some of these chunks might easily create a file in which they are inconsistent. BUT: there is no logical inconsistency in requiring that an encoder that initially creates an srGB chunk also create matching gAMA/cHRM. This is clearly something that the original encoder can always do. The advantage of making such a requirement is that it reduces the odds that a PNG editor will subsequently mangle the file. The assumption is that an editor is less likely to override existing gAMA/cHRM than it is to "helpfully" supply such chunks if they are missing. Basically we are talking about increasing the resiliency of the file --- it's not bulletproof but it should tilt the odds in our favor. I think that this consideration justifies requiring, not just recommending, that srGB always be created with matching gAMA and cHRM. Backwards compatibility with pre-srGB decoders is also a sufficient justification for requiring gAMA/cHRM to be included. Nonetheless, because of the possibility that non-srGB-aware editors may insert inconsistent gAMA/cHRM values without discarding srGB, we must also specify what decoders should do upon encountering such a file. Ignoring gAMA/cHRM when srGB is present is clearly the right answer for the decoding end. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 11:00:33 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id LAA27750 for ; Fri, 27 Sep 1996 11:00:32 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA22109 for png-list-outgoing; Fri, 27 Sep 1996 11:00:22 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA22104 for ; Fri, 27 Sep 1996 11:00:17 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id SAA07213 for png-list@dworkin.wustl.edu; Fri, 27 Sep 1996 18:00:09 +0200 (DST) Date: Fri, 27 Sep 1996 18:00:09 +0200 (DST) From: Chris Lilley Message-Id: <9609271800.ZM7210@grommit.inria.fr> In-Reply-To: Tom Lane "Re: sRGB proposed chunk" (Sep 27, 11:34am) References: <27048.843838453@sss.pgh.pa.us> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: sRGB proposed chunk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 27, 11:34am, Tom Lane wrote: > BUT: there is no logical inconsistency in requiring that an encoder that > initially creates an srGB chunk also create matching gAMA/cHRM. This > is clearly something that the original encoder can always do. > [...] > Nonetheless, because of the possibility that non-srGB-aware editors may > insert inconsistent gAMA/cHRM values without discarding srGB, we must > also specify what decoders should do upon encountering such a file. > Ignoring gAMA/cHRM when srGB is present is clearly the right answer > for the decoding end. Excellent summary as ever, Tom. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 13:11:36 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA29694 for ; Fri, 27 Sep 1996 13:11:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA25410 for png-list-outgoing; Fri, 27 Sep 1996 13:11:05 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id NAA25401 for ; Fri, 27 Sep 1996 13:11:00 -0500 Date: Fri, 27 Sep 96 14:09:30 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: sRGB proposed chunk Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609271409.aa06572@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List }BUT: there is no logical inconsistency in requiring that an encoder that }initially creates an srGB chunk also create matching gAMA/cHRM. This }is clearly something that the original encoder can always do. } OK: An application that creates the sRGB chunk must also create gAMA and cHRM chunks for compatibility with applications that do not recognize and process the srGB chunk. They must contain the following values: ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 13:13:40 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA29783 for ; Fri, 27 Sep 1996 13:13:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA25495 for png-list-outgoing; Fri, 27 Sep 1996 13:13:48 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA25490 for ; Fri, 27 Sep 1996 13:13:41 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id LAA08244 for ; Fri, 27 Sep 1996 11:06:10 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id LAA12130 for png-list@dworkin.wustl.edu; Fri, 27 Sep 1996 11:06:09 -0700 (PDT) Message-Id: <199609271806.LAA12130@web1.calweb.com> Subject: Re: the fate of loGE To: png-list@dworkin.wustl.edu Date: Fri, 27 Sep 1996 11:06:09 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <9609270629.aa24955@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 27, 96 06:29:07 am Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > We can never allow a public uncompressed version of PNG because people > would use it to deliver images over the net. There's no reason you > can't use a private UdAT chunk, though. Works fine. Homegrown, but > *is* PNG. :-) I think I'd still prefer he use the existing "secret" uncompressed format, then at least the files would be readable by existing viewers. But yes, the less said in public, the better. > :wq Ah, a real programmer. Forgot to put vi in beep mode :) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 13:24:01 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA29903 for ; Fri, 27 Sep 1996 13:24:00 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA25733 for png-list-outgoing; Fri, 27 Sep 1996 13:24:07 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA25724 for ; Fri, 27 Sep 1996 13:24:02 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id LAA09997 for ; Fri, 27 Sep 1996 11:16:50 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id LAA16228 for png-list@dworkin.wustl.edu; Fri, 27 Sep 1996 11:16:50 -0700 (PDT) Message-Id: <199609271816.LAA16228@web1.calweb.com> Subject: Re: the fate of loGE To: png-list@dworkin.wustl.edu Date: Fri, 27 Sep 1996 11:16:50 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <199609270133.SAA04439@dawn13.CS.Berkeley.EDU> from "Adam M. Costello" at Sep 26, 96 06:33:04 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > We could have a chunk that contains Java bytecode that does the > transformation. > > Taking the next leap, we could do without graphic file formats > altogether. We could instead have a standard interface for asking an > image for information about itself, and let the image (a Java object) > store the information any way it pleases. We could even provide a > standard library of commonly used functions so that image objects don't > have to carry around much code with them. > > I'm not sure I'm serious, but isn't this exactly the sort of thing Java > was designed for? Is it only a matter of time before this kind of > practice becomes commonplace, or is there something inherently wrong > with this approach? Hmm. Interesting thoughts. I don't think I'd clutter PNG with anything like this, but there are some things there to investigate, particularly with animation. You have to be careful about security to avoid getting viruses into your movie. Damn. And just when I was starting to catch up... ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 13:42:23 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA00233 for ; Fri, 27 Sep 1996 13:42:21 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA25964 for png-list-outgoing; Fri, 27 Sep 1996 13:42:11 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id NAA25959 for ; Fri, 27 Sep 1996 13:42:07 -0500 Date: Fri, 27 Sep 96 14:40:49 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Uncompressed PNG (was the fate of loGE) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609271440.aa06957@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Subject: Re: the fate of loGE }Date: Fri, 27 Sep 1996 11:11:57 -0700 (PDT) }From: Lee Daniel Crocker }> | But don't let our "dirty little secret" of uncompressed PNG get }> | spread out too far into the public--yes, it's possible, and I }> | don't mind a writer or reader/writer combo that does it, but we }> | don't want anyone to make a reader that only accepts uncompressed }> | PNG calling itself a PNG reader. }> }> I don't think thats possible, not with the above idea... because ZLIB }> would still be in the code, and so there to handle all forms of }> compressed data, not just value 0... but I also take it that that is }> not truely uncompressed ... its segmented? If so, that doesn't help }> any ... I think I could show you examples where the compression }> overhead actually causes the end file to be larger ... not sure though }> .. (little 8x8 images...?) } }One could write an uncompressed-only PNG reader in a day or two without }ZLIB, and such a piece of software would be useful for certain tasks, }but we just want to ensure that such a beast doesn't get out of its }cage. I think it is sufficient to ensure that browser writers understand that they are expected to reject such files, so people won't put them on the 'net. }And of course ZLIB isn't really necessary for the full format }either--PTOT reads all PNGs, and doesn't use it (it does use some of }Mark Adler's inflation code). ARL Viewpng doesn't use it except for what's included in gzip. And Oliver's QPV/QPNG code is in Pascal, isn't it? Viewpng and qpv (alias qpeg) predate zlib. Fooling with zlib is the wrong way to go about writing an uncompressed PNG anyway. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 13:48:20 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA00467 for ; Fri, 27 Sep 1996 13:48:19 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA26039 for png-list-outgoing; Fri, 27 Sep 1996 13:48:27 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id NAA26034 for ; Fri, 27 Sep 1996 13:48:22 -0500 Date: Fri, 27 Sep 96 14:45:14 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: the fate of loGE Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609271445.aa07204@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Subject: Re: the fate of loGE }Date: Fri, 27 Sep 1996 11:06:09 -0700 (PDT) }From: Lee Daniel Crocker }> We can never allow a public uncompressed version of PNG because people }> would use it to deliver images over the net. There's no reason you }> can't use a private UdAT chunk, though. Works fine. Homegrown, but }> *is* PNG. :-) } }I think I'd still prefer he use the existing "secret" uncompressed }format, then at least the files would be readable by existing viewers. }But yes, the less said in public, the better. Readable by existing viewers is the problem; people can put them on the 'net. With UdAT they get rejected and the culprit is caught. } }> :wq } }Ah, a real programmer. Forgot to put vi in beep mode :) Nope. The screen was getting covered with 30 seconds to shutdown 20 seconds to shutdown 10 seconds to shutdown 5 seconds to shutdown and I made it with about 2 seconds to spare. Didn't have time to get rid of the :wq. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 14:10:26 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id OAA00844 for ; Fri, 27 Sep 1996 14:10:26 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA26534 for png-list-outgoing; Fri, 27 Sep 1996 14:10:05 -0500 Received: from inet.htcnet.com (inet.htcnet.com [199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA26524 for ; Fri, 27 Sep 1996 14:09:59 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id OAA25204 for ; Fri, 27 Sep 1996 14:14:07 -0500 Message-Id: <199609271914.OAA25204@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: Re: the fate of loGE Date: Fri, 27 Sep 1996 14:09:40 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List | Carl, with the new knowledge of ZLIB compression level 0, and dRNG you | should be able to put your ideas for a new format away... I don't know ... another gripe I had when I got on this list was about the palette support... 256 index's is not very many, plus the palette itself is limited to 8bit samples... I think it is foreseeable that at some point in the future poeple could remake PNG like they remade GIF... I don't know if GIF89 was compatible with GIF87 only decoders or not, but I could foresee the need to support raw rastered 4 dimensional images. With all the alpha and related things PNG has, it could be a pretty interresting format if it could store 3d samples at least... :) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 14:14:11 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id OAA00939 for ; Fri, 27 Sep 1996 14:14:09 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA26643 for png-list-outgoing; Fri, 27 Sep 1996 14:14:11 -0500 Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA26634 for ; Fri, 27 Sep 1996 14:13:52 -0500 Received: from fb0430.mathematik.th-darmstadt.de (daemon@fb0430.mathematik.th-darmstadt.de [130.83.2.30]) by rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id UAA27202 for ; Fri, 27 Sep 1996 20:13:31 +0100 Received: from fb0401.mathematik.th-darmstadt.de by fb0430.mathematik.th-darmstadt.de (1.37.109.16/Server-1.5/HRZ-THD) id AA262001613; Fri, 27 Sep 1996 21:13:33 +0200 Received: from localhost by fb0401.mathematik.th-darmstadt.de (1.37.109.16/Client-1.5/HRZ-THD) id AA174251608; Fri, 27 Sep 1996 21:13:28 +0200 Date: Fri, 27 Sep 1996 21:13:28 +0200 (MESZ) From: Alexander Lehmann To: PNG List Subject: Re: Uncompressed PNG (was the fate of loGE) In-Reply-To: <9609271440.aa06957@THOR.ARL.MIL> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Fri, 27 Sep 1996, Glenn Randers-Pehrson ARL-WMRD-TED-TIB wrote: > > In reply to the message > }Subject: Re: the fate of loGE > }Date: Fri, 27 Sep 1996 11:11:57 -0700 (PDT) > }From: Lee Daniel Crocker > }> | But don't let our "dirty little secret" of uncompressed PNG get > }> | spread out too far into the public--yes, it's possible, and I > }> | don't mind a writer or reader/writer combo that does it, but we > }> | don't want anyone to make a reader that only accepts uncompressed > }> | PNG calling itself a PNG reader. > }> > }> I don't think thats possible, not with the above idea... because ZLIB > }> would still be in the code, and so there to handle all forms of > }> compressed data, not just value 0... but I also take it that that is > }> not truely uncompressed ... its segmented? If so, that doesn't help > }> any ... I think I could show you examples where the compression > }> overhead actually causes the end file to be larger ... not sure though > }> .. (little 8x8 images...?) > } > }One could write an uncompressed-only PNG reader in a day or two > }without ZLIB, and such a piece of software would be useful for > }certain tasks, but we just want to ensure that such a beast doesn't > }get out of its cage. > > I think it is sufficient to ensure that browser writers understand > that they are expected to reject such files, so people won't put > them on the 'net. Actually, since the uncompressed data blocks are part of the deflate spec, any PNG-reading program cannot reject them (the uncompressed blocks are necessary to encode uncompressable data and there might be (theoretically) an image that is stored completely uncompressed). An uncompressed-only reader probably will not work well since most PNG writing programs don't even have an option to write the files uncompressed. The main reason why a couple of readers only support uncompressed TIFF seems to be that any TIFF compliant writer has to have an option to store the files uncompressed, which PNG doesn't. > }And of course ZLIB isn't really necessary for the full format > }either--PTOT reads all PNGs, and doesn't use it (it does use some > }of Mark Adler's inflation code). > > ARL Viewpng doesn't use it except for what's included in gzip. And > Oliver's QPV/QPNG code is in Pascal, isn't it? Viewpng and qpv > (alias qpeg) predate zlib. Fooling with zlib is the wrong way to go > about writing an uncompressed PNG anyway. Well, you could at least use the crc and checksum code plus the file handling, stripping down zlib to remove the compression code wouldn't be to difficult, but writing a small library from scratch is probably easier. (I have to admit that I considered doing this for the PNG support in gnuplot, currently this doesn't come with the library, obviously, and hence the default is not to compile PNG support. A small uncompressed write function would have been somewhat useful there, but I ended up just using libpng and zlib, which is much easier). bye, Alexander -- Alexander Lehmann, | "On the Internet, alex@hal.rhein-main.de (MIME, NeXT) | nobody knows lehmann@mathematik.th-darmstadt.de (MIME) | you're a dog." ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 14:15:35 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id OAA00955 for ; Fri, 27 Sep 1996 14:15:33 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA26722 for png-list-outgoing; Fri, 27 Sep 1996 14:15:29 -0500 Received: from inet.htcnet.com (inet.htcnet.com [199.120.83.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA26715 for ; Fri, 27 Sep 1996 14:15:26 -0500 Received: from msftrncs.htcnet.com (p179.htcnet.com [199.120.83.179]) by inet.htcnet.com (8.6.9/8.6.9) with ESMTP id OAA25213 for ; Fri, 27 Sep 1996 14:19:34 -0500 Message-Id: <199609271919.OAA25213@inet.htcnet.com> From: "Carl Morris" To: "PNG List" Subject: Re: the fate of loGE Date: Fri, 27 Sep 1996 14:15:10 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List | } As a result, I've been storing images using PPM plus a homegrown | } format, not PNG. | We can never allow a public uncompressed version of PNG because people | would use it to deliver images over the net. There's no reason you | can't use a private UdAT chunk, though. Works fine. Homegrown, but | *is* PNG. :-) First, there is no reason he can't define his own compression value, for no compression, and store it in an idat chunk, providing he never hopes in other decoders support for it... second, giving people an option for an uncompressed form of PNG will not cause them to send them across the net uncompressed.... I ran a BBS back before the WWW became graphical and at that time GIF standardly was sent uncompressed (or compressed so poorly it needed help), and many programs floated around to help compress them... I never saw another bloated GIF after that... of course that was one of the best compressions at the time... now we consider all GIF's bloated don't we? :) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 14:16:08 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id OAA00972 for ; Fri, 27 Sep 1996 14:16:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA25635 for png-list-outgoing; Fri, 27 Sep 1996 13:19:30 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA25623 for ; Fri, 27 Sep 1996 13:19:09 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id LAA09154 for ; Fri, 27 Sep 1996 11:11:57 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id LAA14297 for png-list@dworkin.wustl.edu; Fri, 27 Sep 1996 11:11:57 -0700 (PDT) Message-Id: <199609271811.LAA14297@web1.calweb.com> Subject: Re: the fate of loGE To: png-list@dworkin.wustl.edu Date: Fri, 27 Sep 1996 11:11:57 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <199609270309.WAA17152@inet.htcnet.com> from "Carl Morris" at Sep 26, 96 10:04:47 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > | But don't let our "dirty little secret" of uncompressed PNG get > | spread out too far into the public--yes, it's possible, and I > | don't mind a writer or reader/writer combo that does it, but we > | don't want anyone to make a reader that only accepts uncompressed > | PNG calling itself a PNG reader. > > I don't think thats possible, not with the above idea... because ZLIB > would still be in the code, and so there to handle all forms of > compressed data, not just value 0... but I also take it that that is > not truely uncompressed ... its segmented? If so, that doesn't help > any ... I think I could show you examples where the compression > overhead actually causes the end file to be larger ... not sure though > .. (little 8x8 images...?) One could write an uncompressed-only PNG reader in a day or two without ZLIB, and such a piece of software would be useful for certain tasks, but we just want to ensure that such a beast doesn't get out of its cage. And of course ZLIB isn't really necessary for the full format either--PTOT reads all PNGs, and doesn't use it (it does use some of Mark Adler's inflation code). ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 14:53:21 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id OAA01207 for ; Fri, 27 Sep 1996 14:53:20 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA27814 for png-list-outgoing; Fri, 27 Sep 1996 14:53:19 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA27807 for ; Fri, 27 Sep 1996 14:53:15 -0500 Received: from munet-f.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id NAA06746; Fri, 27 Sep 1996 13:52:50 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609271952.NAA06746@enel.ucalgary.ca> Received: by munet-f.enel.ucalgary.ca (NX5.67d/NX3.0X) id AA01828; Fri, 27 Sep 96 13:52:49 -0600 Subject: Re: sRGB proposed chunk To: png-list@dworkin.wustl.edu Date: Fri, 27 Sep 1996 13:52:49 -0600 (MDT) In-Reply-To: <9609271008.aa02174@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 27, 96 10:08:09 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > It would only be efficient if we could guarantee that srGB would occur > ahead of gAMA and cHRM in the stream. I don't think we can. I'm not sure exactly how other PNG decoders work, but libpng based ones do not strictly require a given chunk ordering as given in the PNG spec, as it reads all of the info before the first IDAT chunk prior to returning control to the decoder. This also (rightly) prevents people from assuming anything about the ordering of ancillary chunks. Real Soon Now (after I release the next libpng version), I intend to add capabilities to libpng which allow an application to read and write arbitrary chunks, and probably also a function which copies chunk info from an input PNG stream to an output PNG stream, using info from the application on whether the image or other critical chunks have changed. At long last, this will allow us to put those chunk copying flags to good use, and will allow the creation of the pngtopng program that has become legend around these parts (not that I will write this). Even so, it may be easier to just use the pngtopnm and pnmtopng conversions, so that you can edit everything by hand. Cheers, Andreas. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 15:10:05 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id PAA04573 for ; Fri, 27 Sep 1996 15:10:05 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA28440 for png-list-outgoing; Fri, 27 Sep 1996 15:10:11 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id PAA28430 for ; Fri, 27 Sep 1996 15:10:07 -0500 Date: Fri, 27 Sep 96 16:09:21 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: sRGB proposed chunk Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609271609.aa09898@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Andreas wrote: } }I'm not sure exactly how other PNG decoders work, but libpng based ones }do not strictly require a given chunk ordering as given in the PNG spec, ARL viewpng is similar. It doesn't bother to check for chunks being out of order with respect to PLTE, but the before-IDAT stuff must appear before IDAT. It has no memory of the order in which the chunks were received. ARL png-png (actually a script that does png-pnm and pnm-png) does the same, and just writes the chunks in a legal order. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 15:16:36 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id PAA04646 for ; Fri, 27 Sep 1996 15:16:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA28567 for png-list-outgoing; Fri, 27 Sep 1996 15:16:34 -0500 Received: from enel.ucalgary.ca ([136.159.100.11]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA28561 for ; Fri, 27 Sep 1996 15:16:28 -0500 Received: from munet-f.enel.ucalgary.ca by enel.ucalgary.ca (SMI-8.6/ENEL-5) id OAA06843; Fri, 27 Sep 1996 14:16:14 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609272016.OAA06843@enel.ucalgary.ca> Received: by munet-f.enel.ucalgary.ca (NX5.67d/NX3.0X) id AA01850; Fri, 27 Sep 96 14:16:13 -0600 Subject: Re: Uncompressed PNG To: png-list@dworkin.wustl.edu Date: Fri, 27 Sep 1996 14:16:13 -0600 (MDT) In-Reply-To: <9609271440.aa06957@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 27, 96 02:40:49 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > I think it is sufficient to ensure that browser writers understand that > they are expected to reject such files, so people won't put them on the > 'net. I don't see how you can say this. In what way is it NOT a PNG file? Just because someone might be foolish enough to make uncompressed PNG files available, doesn't mean that browsers should discard perfectly legal PNG files. Why would people even use PNG in the first place to do this (ie going to the effort to use a less popular format thats main benefit is its improved comrpression) just to make an uncompressed file? Why not use any of a number of more popular formats like TIFF or TGA or BMP and be done with it? I think you are worried about a situation that will never happen. In general, people come to some sort of disk space crunch in one way or another. A big part of why JPEG is popular on the Web is the space savings for photographic-quality images, not just the increased quality (which isn't noticable if you only have an 8-bit display). If they care about WWW downloading speed, they will probably go with the maximum compression rather than the uncompressed file, since bandwidth is usually more of a constraint than end-user computational power (look at all the small, yet funky animated JAVA stuff on the net that sucks the life out of an older computer). Cheers, Andreas. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 15:44:35 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id PAA04882 for ; Fri, 27 Sep 1996 15:44:34 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA29181 for png-list-outgoing; Fri, 27 Sep 1996 15:44:18 -0500 Received: from enel.ucalgary.ca ([136.159.100.11]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA29176 for ; Fri, 27 Sep 1996 15:44:14 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id OAA06958; Fri, 27 Sep 1996 14:44:00 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609272044.OAA06958@enel.ucalgary.ca> Subject: Re: CALL FOR VOTES on dRNG To: png-list@dworkin.wustl.edu Date: Fri, 27 Sep 1996 14:43:59 -0600 (MDT) In-Reply-To: <9609270932.aa01600@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 27, 96 09:32:22 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > }Note that in the png-scivis-chunks-19960914.txt.gz file, the description > }of the dRNG "ratio" should specify "output_bit_depth" instead of "bit_depth", > }and also under the discussion of indexed color images immediately below. > }This vote on dRNG/DRNG is based on these minor changes. > > OK. Also, if the chunk should happen to be approved, the editor would > add a clarifying sentence saying that for other color types, the > output_bit_depth is the same as the bit_depth in IHDR. Maybe I'm just being contrary with Glenn today, but this is exactly what we DON't want. For example, if I have an input PNG with 16-bit/channel RGB, and I'm displaying on a regular 24-bit system, the output_bit_depth is 8, not 16, so even if the input values are in the range [0,65535] I want to scale them to [0,255] when decoding the image. For dRNG, the bit_depth in the IHDR is only used to determine the number of bits in the input sample value, since we are stricly using min_val and max_val to set the range of the input data values, rather than using min_val = 0 and max_val = (2^IHDR_bit_depth - 1) like most PNG files. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 15:50:01 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id PAA04932 for ; Fri, 27 Sep 1996 15:50:00 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA29364 for png-list-outgoing; Fri, 27 Sep 1996 15:50:09 -0500 Received: from enel.ucalgary.ca ([136.159.99.2]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA29359 for ; Fri, 27 Sep 1996 15:50:05 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id OAA06978; Fri, 27 Sep 1996 14:49:51 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609272049.OAA06978@enel.ucalgary.ca> Subject: Re: Discussion on pCAL To: png-list@dworkin.wustl.edu Date: Fri, 27 Sep 1996 14:49:51 -0600 (MDT) In-Reply-To: <9609270914.aa01015@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 27, 96 09:14:54 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > Only if you insist on removing the "purpose" field. If your application > doesn't need it, it's fairly harmless, requiring you to supply a single > meaningless ASCII character and a null. However, I think your proposed application would be the rare exception, rather than the rule, and since the pCAL chunk is only on the order of 10 or 20 bytes or so (unlike a large fALS or sPLT which can be hundreds of bytes), I would much rather force the application to duplicate the pCAL chunk in each sub-image on those rare occasions where you have a series of multiple images composited in a single MNG file (whose size will already be quite large), rather than have "meaningless" bytes in each and every PNG image that uses pCAL. It's not so much the two bytes I'm concerned about, but rather that they have no purpose at all. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 15:51:13 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id PAA04943 for ; Fri, 27 Sep 1996 15:51:12 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA29395 for png-list-outgoing; Fri, 27 Sep 1996 15:51:21 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id PAA29390 for ; Fri, 27 Sep 1996 15:51:17 -0500 Date: Fri, 27 Sep 96 16:50:48 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Uncompressed PNG Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609271650.aa10599@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }From: Andreas Dilger }Subject: Re: Uncompressed PNG }Date: Fri, 27 Sep 1996 14:16:13 -0600 (MDT) }Glenn writes: }> I think it is sufficient to ensure that browser writers understand that }> they are expected to reject such files, so people won't put them on the }> 'net. } }I don't see how you can say this. In what way is it NOT a PNG }file? Just because someone might be foolish enough to make }uncompressed PNG files available, doesn't mean that browsers should }discard perfectly legal PNG files. Why would people even use PNG }in the first place to do this (ie going to the effort to use a }less popular format thats main benefit is its improved comrpression) }just to make an uncompressed file? Why not use any of a number of }more popular formats like TIFF or TGA or BMP and be done with it? Why I used it in the past was when I was first getting all the filtering algorithms running. Instead of writing IDATs I wrote UDATs that were easy to inspect with od. There are perfectly valid uses for uncompressed PNG's, as Dave mentioned. What's wrong with this picture? scan > scanned.png (compress) crop < scanned.png > cropped.png (decompress and compress) scale < cropped.png > scaled.png (decompress and compress) touchup < scaled.png > touchedup.png (decompress and compress) png-optimize < touchedup.png > final.png (decompress and maxcompress) png-qc < final.png (decompress) isn't this better? scan -u > scanned.png (write) crop -u < scanned.png > cropped.png (read and write) scale -u < cropped.png > scaled.png (read and write) touchup -u < scaled.png > touchedup.png (read and write) png-optimize < touchedup.png > final.png (read and maxcompress) png-qc < final.png (decompress) }I think you are worried about a situation that will never happen. I am not the person who worried about that. The decree "no uncompressed version of PNG" was made very early in the game, before I joined png-list. }In }general, people come to some sort of disk space crunch in one way or }another. A big part of why JPEG is popular on the Web is the space }savings for photographic-quality images, not just the increased quality }(which isn't noticable if you only have an 8-bit display). If they care }about WWW downloading speed, they will probably go with the maximum }compression rather than the uncompressed file, since bandwidth is usually }more of a constraint than end-user computational power (look at all the }small, yet funky animated JAVA stuff on the net that sucks the life out }of an older computer). Yes. I really wonder why they are sticking with GIF, when PNG almost always gives significantly better compression? I thought Tom's recent message about Unisys' regeging on the freeware agreement would spark some debate, but Tom's message on comp.compression has gone publicly unanswered [checks newsgroup... this is interesting; it's been cancelled again] until now (I was one of the four who wrote him). ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 16:20:23 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA05148 for ; Fri, 27 Sep 1996 16:20:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA29952 for png-list-outgoing; Fri, 27 Sep 1996 16:20:17 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id QAA29946 for ; Fri, 27 Sep 1996 16:20:08 -0500 Date: Fri, 27 Sep 96 17:16:33 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Discussion on pCAL Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609271716.aa11002@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }From: Andreas Dilger }Subject: Re: Discussion on pCAL }Date: Fri, 27 Sep 1996 14:49:51 -0600 (MDT) }Glenn writes: }> Only if you insist on removing the "purpose" field. If your application }> doesn't need it, it's fairly harmless, requiring you to supply a single }> meaningless ASCII character and a null. } }However, I think your proposed application would be the rare exception, }rather than the rule, and since the pCAL chunk is only on the order of }10 or 20 bytes or so (unlike a large fALS or sPLT which can be hundreds }of bytes), I would much rather force the application to duplicate the }pCAL chunk in each sub-image on those rare occasions where you have a }series of multiple images composited in a single MNG file (whose size }will already be quite large) [but very small compared to an animated GIF or SGI movie with the same content] , rather than have "meaningless" bytes in each }and every PNG image that uses pCAL. It's not so much the two bytes I'm }concerned about, but rather that they have no purpose at all. They help human beings who are looking at the chunk to tell what it is for. The MNG example that I gave was just one example of using the "purpose" field. Suppose I have a library of pcAL chunks (and I expect that I will have a library of several) my application can display them, with their "purpose" strings, and then I can just click on the one I want. I believe this is how Todd described his use of fALS chunks. The fact that pcAL chunks are smaller doesn't make the "purpose" tag less useful. If it comes to rewriting the dRNG spec I might want to add a "purpose" tag to that, too. Why would it be a rare exception? pCAL, as a sci-vis chunk, will be rarely used anyway. But of those rare uses, here at ARL it would probably always be used in a manner that takes advantage of the "purpose" chunk. If pCAL is approved without it, I'll have to design a new private chunk, just like pCAL, but with another name and with a "purpose" field, and then some kind of png-png software that converts the private chunk to the public chunk and duplicates it in each sub-image. Even single PNG images that use pCAL are likely to be large ones where the "purpose" byte overhead is negligible, with rare exceptions [I guess]. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 16:21:13 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA05155 for ; Fri, 27 Sep 1996 16:21:11 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA29969 for png-list-outgoing; Fri, 27 Sep 1996 16:21:20 -0500 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA29963 for ; Fri, 27 Sep 1996 16:21:16 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id OAA07479 for ; Fri, 27 Sep 1996 14:20:56 -0700 X-Sender: davem@mail.cs.ubc.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Sep 1996 14:21:03 -0700 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: Re: the fate of loGE Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I wrote: >> As a result, I've been storing images using PPM plus a homegrown >> format, not PNG. Andreas wrote: >This is sort of a misnomer, as it is possible to just set the zlib compression >level to "0", and you will get uncompressed data, although segmented up in >chunks. If the issue is speed, then this will work. I hadn't realized that this was possible. Yes, that would answer my objections about compression - I'm concerned about the time it takes, not about wanting to avoid zlib or compression code entirely. Here is one kind of thing that I do, in more detail: Start with a collection of tens or hundreds or even thousands of images. Apply some "operation" to all of them. The "operation" may actually be implemented by a sequence of programs operating on intermediate temporary images. In this context, size of the input images and the final output images matters, since there are many of them present simultaneously. Size of the intermediate temporary images does *not* matter - even if it is 10 or 100 times the compressed size, it's still insignificant compared to the total space taken up by the whole set of images, and there are generally at most 2 temp files present at any one time. However, time to compress and decompress each temporary image *is* important, since every one of those thousand input images has to be read and written for *each* stage of the processing pipeline. Thus, in this application, writing uncompressed PNG files as the intermediate images might make perfect sense. Particularly if uncompressed PNG is no slower than PPM storage of the same data (the PBMPLUS stuff is written for portability, not speed). Despite that, I'll probably continue using my homegrown stuff because it has other things that PNG doesn't: - written for speed - it's several times faster than PPM last time I looked - I can store 32-bit floating point sample values, as well as integers up to 31 bits - I can store an arbitrary number of components per "pixel", not just 3 or 4. - scanlines can be read in random order None of this is a criticism of PNG. These capabilities are interesting to me because not all of the "images" I store are intended for CRT viewing, and some of them aren't directly meaningful to look at at all. (e.g the Fourier transform of an image). PNG was designed primarily for storing images that are intended to be displayed, and it does that pretty well. Andreas again: >However, if the images are used by a specific application in this manner >to efficiently store data, people may not be viewing the images much >anyways? The suggested gAMA info would make the data understandable, >and your application would do proper decoding. The "suggested gAMA" for loGE-encoded images would make the image viewable as *something*, but it will never look close to correct on a standard viewer. In this respect, loGE is a considerably greater departure from "standard PNG" than dRNG is. Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 16:27:26 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA05312 for ; Fri, 27 Sep 1996 16:27:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA00225 for png-list-outgoing; Fri, 27 Sep 1996 16:27:31 -0500 Received: from enel.ucalgary.ca ([136.159.99.2]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA00218 for ; Fri, 27 Sep 1996 16:27:26 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id PAA07330; Fri, 27 Sep 1996 15:26:59 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609272126.PAA07330@enel.ucalgary.ca> Subject: Re: the fate of loGE To: png-list@dworkin.wustl.edu (PNG Graphics discussion) Date: Fri, 27 Sep 1996 15:26:58 -0600 (MDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > We can never allow a public uncompressed version of PNG because people > would use it to deliver images over the net. There's no reason you > can't use a private UdAT chunk, though. Works fine. Homegrown, but > *is* PNG. :-) I contacted Glenn privately late last night to make sure that my lack of sleep wasn't causing humor impairment, but he assured me that he is serious in this statement. I strongly object to calling an essentially proprietary file with "UdAT" chunks and no IDAT chunks a PNG file (which is against the spec in the worst sort of way), while a perfectly legal, although larger, PNG file using the "stored block" mode of ZLIB is implied to not be a PNG file. Surely you must remember when libpng was ahead of the development of ZLIB, and we could only use the "stored block" (ie uncompressed) mode of ZLIB to read and write PNG files for testing. They were legal then, and they are still legal now. Don't get me wrong, I'm against people using uncompressed PNG files on a regular basis, especially for transmission over the Internet (although I don't see this as a reason to worry at all). I'm dead against anyone writing a decoder that can only read uncompressed PNG images (it would be evolution in action - nobody would use such a thing, since it couldn't read 99.999% of all PNG files). I just don't see any point in muddying the waters with files called "PNG" that really aren't just to make things "safe" for foolish people in the outside world, especially when such "safety" comes at the expense of standards and usability (maybe people shouldn't be allowed to put gas in their cars, since stationary cars rarely, if ever, kill anyone). However, you seem to discount the fact that there ARE applications which need to have the speed of ZLIB level 0 "compression", and yet it would be foolish to write a special-purpose reader and writer of so-called "PNG" files that contain the image in UdAT chunks. I see no reason why someone shouldn't write a "real-time" sci-vis (or whatever) application which dumps valid PNG files on a time-constrained basis with little or no compression, yet can be viewed with the ever- increasing number of PNG viewers. Why would one use PNG and not another uncompressed format in this situation? We all know that PNG is superior, or course (:-). Possibly because of the the gamma/color correction, physical calibration data, multiple keyword/text annotations, any number of other reasons that mean you can use an (albeit sophisticated, yet standard) PNG viewer instead of writing your own viewer to understand proprietary, yet redundant, UdAT or whatever. When it gets to this point you may as well discard PNG entirely and make up your own format. Cheers, Andreas (sounding slightly more argumentative than I should, but with a (rarely ocurring) strong opinion about something). -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 16:44:14 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA05711 for ; Fri, 27 Sep 1996 16:44:13 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA00691 for png-list-outgoing; Fri, 27 Sep 1996 16:44:19 -0500 Received: from enel.ucalgary.ca ([136.159.99.2]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA00686 for ; Fri, 27 Sep 1996 16:44:15 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id PAA07398; Fri, 27 Sep 1996 15:44:01 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609272144.PAA07398@enel.ucalgary.ca> Subject: Re: Discussion on pCAL To: png-list@dworkin.wustl.edu Date: Fri, 27 Sep 1996 15:44:00 -0600 (MDT) In-Reply-To: <9609271716.aa11002@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 27, 96 05:16:33 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > Suppose I have a library of pcAL chunks (and I expect that I will have a > library of several) my application can display them, with their "purpose" > strings, and then I can just click on the one I want. I believe this > is how Todd described his use of fALS chunks. So when you select the various pCAL chunks from your list of available options, the object/field/whatnot you are measuring will corresponding change in height, temperature, density, etc? This is fine with the fALS chunk, and may even be a good idea for dRNG (for MNG that is), but you don't see a need for a "purpose" field in pHYS, do you? With pCAL, we are talking about the relationchip between the sample values stored in the PNG (or MNG sub-) image and the original physical measurement - to which there can only be a single correct mapping - given by a single pCAL chunk for that (sub-)image. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 16:50:43 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA05758 for ; Fri, 27 Sep 1996 16:50:41 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA00823 for png-list-outgoing; Fri, 27 Sep 1996 16:50:46 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id QAA00818 for ; Fri, 27 Sep 1996 16:50:43 -0500 Date: Fri, 27 Sep 96 17:48:28 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: CALL FOR VOTES on dRNG Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609271748.aa11317@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }From: Andreas Dilger }Subject: Re: CALL FOR VOTES on dRNG }Date: Fri, 27 Sep 1996 14:43:59 -0600 (MDT) }Glenn writes: }> }Note that in the png-scivis-chunks-19960914.txt.gz file, the description }> }of the dRNG "ratio" should specify "output_bit_depth" instead of "bit_depth" }, }> }and also under the discussion of indexed color images immediately below. }> }This vote on dRNG/DRNG is based on these minor changes. }> }> OK. Also, if the chunk should happen to be approved, the editor would }> add a clarifying sentence saying that for other color types, the }> output_bit_depth is the same as the bit_depth in IHDR. } }Maybe I'm just being contrary with Glenn today, Quite. But I prefer that to silence any day. but this is exactly what }we DON't want. For example, if I have an input PNG with 16-bit/channel }RGB, and I'm displaying on a regular 24-bit system, the output_bit_depth }is 8, not 16, so even if the input values are in the range [0,65535] I }want to scale them to [0,255] when decoding the image. For dRNG, the }bit_depth in the IHDR is only used to determine the number of bits in the }input sample value, since we are stricly using min_val and max_val to set }the range of the input data values, rather than using min_val = 0 and }max_val = (2^IHDR_bit_depth - 1) like most PNG files. The "output_bit_depth" refers to the output of the drng operation and has nothing to do with the output frame buffer. I tried a year ago to get us to use a better terminology that distinguished between the PNG datastream bit_depth (IHDR_bit_depth) and the sample_bit_depth, where sample_bit_depth == IHDR_bit_depth except for indexed color images, where sample_bit_depth = 8. "sample_bit_depth" wasn't too satisfactory, though, because it doesn't clearly apply only to the color samples and not to the index samples. "component_bit_depth" was my preference, as I recall. But we continued to use "bit depth" to mean either, except for one place in the sBIT discussion where we say "sample depth" to mean "component_bit_depth". Most of the time "bit depth" means "IHDR_bit_depth", but in the gamma and alpha discussions it means "component_bit_depth". I didn't use the term IHDR_bit_depth, though, but that seems to say it precisely. Naturally it's too late to change anything in the PNG spec. But maybe we could use "component_bit_depth" here, for clarity. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 17:10:52 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA05880 for ; Fri, 27 Sep 1996 17:10:51 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA01235 for png-list-outgoing; Fri, 27 Sep 1996 17:10:50 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id RAA01229 for ; Fri, 27 Sep 1996 17:10:46 -0500 Date: Fri, 27 Sep 96 18:01:56 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Discussion on pCAL Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609271801.aa11622@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }From: Andreas Dilger }Subject: Re: Discussion on pCAL }Date: Fri, 27 Sep 1996 15:44:00 -0600 (MDT) }Glenn writes: }> Suppose I have a library of pcAL chunks (and I expect that I will have a }> library of several) my application can display them, with their "purpose" }> strings, and then I can just click on the one I want. I believe this }> is how Todd described his use of fALS chunks. } }So when you select the various pCAL chunks from your list of available }options, the object/field/whatnot you are measuring will corresponding }change in height, temperature, density, etc? Precisely. I can pick the "pressure megapascals" when I am looking at it but when an engineer walks in and can't figure it out I just hit the "pressure psi" button and make the engineer happy. }This is }fine with the fALS chunk, and may even be a good idea for dRNG (for MNG }that is), but you don't see a need for a "purpose" field in pHYS, do you? No, nor do I see one for xsCL because the units field at the beginning does the same job. } }With pCAL, we are talking about the relationchip between the sample values }stored in the PNG (or MNG sub-) image and the original physical measurement - }to which there can only be a single correct mapping - given by a single pCAL }chunk for that (sub-)image. There are as many mappings as there are systems of units. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 17:13:33 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA05903 for ; Fri, 27 Sep 1996 17:13:30 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA01265 for png-list-outgoing; Fri, 27 Sep 1996 17:13:33 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA01259 for ; Fri, 27 Sep 1996 17:13:20 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id PAA18570 for ; Fri, 27 Sep 1996 15:06:06 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id PAA19542 for png-list@dworkin.wustl.edu; Fri, 27 Sep 1996 15:06:06 -0700 (PDT) Message-Id: <199609272206.PAA19542@web1.calweb.com> Subject: "Component bit depth To: png-list@dworkin.wustl.edu Date: Fri, 27 Sep 1996 15:06:05 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <9609271748.aa11317@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 27, 96 05:48:28 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > I tried a year ago to get us to use a better terminology that > distinguished between the PNG datastream bit_depth (IHDR_bit_depth) > and the sample_bit_depth,... I don't remember that discussion, but I would have agreed. Using the same term for two things is a bad way to write a spec. > Naturally it's too late to change anything in the PNG spec. But maybe > we could use "component_bit_depth" here, for clarity. It's not too late to clarify the RFC, is it? ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 17:15:20 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA05913 for ; Fri, 27 Sep 1996 17:15:19 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA01317 for png-list-outgoing; Fri, 27 Sep 1996 17:15:23 -0500 Received: from enel.ucalgary.ca ([136.159.99.2]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA01310 for ; Fri, 27 Sep 1996 17:15:20 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id QAA07536; Fri, 27 Sep 1996 16:15:06 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609272215.QAA07536@enel.ucalgary.ca> Subject: Re: Uncompressed PNG To: png-list@dworkin.wustl.edu Date: Fri, 27 Sep 1996 16:15:05 -0600 (MDT) In-Reply-To: <9609271650.aa10599@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 27, 96 04:50:48 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > Why I used it in the past was when I was first getting all the > filtering algorithms running. Instead of writing IDATs I wrote UDATs > that were easy to inspect with od. There are perfectly valid uses > for uncompressed PNG's, as Dave mentioned. I don't dispute you on this at all. > What's wrong with this picture? > > scan > scanned.png (compress) > crop < scanned.png > cropped.png (decompress and compress) > scale < cropped.png > scaled.png (decompress and compress) > touchup < scaled.png > touchedup.png (decompress and compress) > png-optimize < touchedup.png > final.png (decompress and maxcompress) > png-qc < final.png (decompress) > > isn't this better? > > scan -u > scanned.png (write) > crop -u < scanned.png > cropped.png (read and write) > scale -u < cropped.png > scaled.png (read and write) > touchup -u < scaled.png > touchedup.png (read and write) > png-optimize < touchedup.png > final.png (read and maxcompress) > png-qc < final.png (decompress) I agree with you whole heartedly. However, it's in the details that we disagree. You want all of these programs (scan, crop, scale, etc) to be able to read and write two different types of images - those stored with IDATs and those stored with UdATs. What if, between the "scale" and "touchup" steps in your uncompressed example, you wanted to add some fancy text annotation with the GIMP or PhotoShop 4.0 (possibly using some scripting features of this software, if available)? You would still need to have additional UdAT-PNG to IDAT-PNG and IDAT-PNG to UdAT-PNG conversion steps in order to use the UdAT "so-called PNG" files with any program to which you don't control the source code. However, using zlib level 0 compression you lose nothing in speed compared to the UdAT storage, yet is totally portible (I don't think ANY implementation of deflate could conceivably exist without the uncompressed stored-block mode). You can even write uncompressed IDAT-PNG files with this software if it gives you sufficient control over the compression level. > I am not the person who worried about that. The decree "no uncompressed > version of PNG" was made very early in the game, before I joined png-list. Yes, I believe this is intended to avoid "raw" image dumps as can be found in many formats, like PPM, TGA, etc, without the zlib flags, blocks, and IDATs. However, even the PNG spec, under section 5 - Deflate/Inflate Compression states: "The compressed data within the zlib datastream is stored as a series of blocks, each of which can represent raw (uncompressed) data, LZ77-compressed data encoded with fixed Huffman codes, or LZ77-compressed data encoded with custom Huffman codes." As it further states in the PNG spec, in section 12 - Rationale. "There is no uncompressed variant of PNG. It is possible to store uncompressed data by using only uncompressed deflate blocks (a feature normally used to guarantee that deflate does not make incompressible data much larger)." Since we don't have pure "raw" bitmap dumps, we can always use zlib to read the image, and we don't need to special-case the IDAT data like we would if there was a separate "raw" format. > Yes. I really wonder why they are sticking with GIF, when PNG almost > always gives significantly better compression? Purely a matter of "big-name" software support. We all know what is needed before PNG is widely used on the Web - Netscape and/or MSIE support. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 17:17:59 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA05940 for ; Fri, 27 Sep 1996 17:17:56 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA01353 for png-list-outgoing; Fri, 27 Sep 1996 17:18:06 -0500 Received: from dawn13.CS.Berkeley.EDU (dawn13.CS.Berkeley.EDU [128.32.38.57]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA01348 for ; Fri, 27 Sep 1996 17:17:59 -0500 Received: (from amc@localhost) by dawn13.CS.Berkeley.EDU (8.6.11/8.6.9) id PAA08191; Fri, 27 Sep 1996 15:17:39 -0700 Date: Fri, 27 Sep 1996 15:17:39 -0700 Message-Id: <199609272217.PAA08191@dawn13.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: Discussion on dRNG X-Advice: should read soon From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List adilger@enel.ucalgary.ca (Andreas Dilger) says: > I think you are both in violent agreement. dRNG IS the chunk which > describes the reversible function used to do the scaling. Glenn said something similar. I did not make myself understood. dRNG does *not* allow the encoder to say, "This is the reversible scaling function I applied." Rather, it allows the encoder to say, "This is the scaling function I want the *decoder* to apply." The core PNG spec places the responsibility for scaling the samples to the range [0..2^bitdepth-1] on the encoder. The dRNG proposal shifts that responsibility to the decoder, which changes the file format. My point is that this is not necessary. The encoder, with its samples in the range [min..max], can do the scaling, and store samples in the range [0..255], in accordance with the PNG spec. It can then indicate what reversible function it used to do the scaling. The decoder, if it wants to recover those unscaled samples in the range [min..max], can apply the reverse function. But a decoder that doesn't know or care about this scaling business is completely unaffected. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 17:20:56 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA05964 for ; Fri, 27 Sep 1996 17:20:55 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA01380 for png-list-outgoing; Fri, 27 Sep 1996 17:20:50 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id RAA01375 for ; Fri, 27 Sep 1996 17:20:47 -0500 Date: Fri, 27 Sep 96 18:15:00 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: the fate of loGE Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609271815.aa11730@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }From: Andreas Dilger }Subject: Re: the fate of loGE }Date: Fri, 27 Sep 1996 15:26:58 -0600 (MDT) }Glenn writes: }> We can never allow a public uncompressed version of PNG because people }> would use it to deliver images over the net. There's no reason you }> can't use a private UdAT chunk, though. Works fine. Homegrown, but }> *is* PNG. :-) } }I contacted Glenn privately late last night to make sure that my lack of }sleep wasn't causing humor impairment, but he assured me that he is }serious in this statement. I strongly object to calling an essentially }proprietary file with "UdAT" chunks and no IDAT chunks a PNG file (which }is against the spec in the worst sort of way), while a perfectly legal, }although larger, PNG file using the "stored block" mode of ZLIB is implied }to not be a PNG file. } OK. UdAT is a bad idea. But it worked for me back in February of last year when I was debugging my software. Haven't actually used UDAT since, or even thought about it until Dave's message about lOGE. Yes, the file is proprietary. I'm not sure it's against the spec, though, because the meaning of UdAT includes the notion that IDAT can be omitted. Such a file could be made legal by including one empty IDAT, though. I didn't say (or mean to say) that using the stored block mode of zlib is not a PNG file. What I did mean to say was that they are legal files, but uncompressed, and don't belong on the 'net. Therefore, using the "stored block" mode of zlib is a bad idea because such files could escape undetected. And it was not such files that I was referring to when I suggested that browsers should reject them. I meant that browsers should never accept the UdAT chunk or equivalent. Someone suggested using a compression_method other than zero to mean uncompressed IDATs. I think that is a much better idea than UdAT and would also make such files rejected by browsers when they look at IHDR. I'd probably include a filter_method other than zero as well, to mean no filter bytes. Then you could make a legitimate IDAT by simply decapitating a ppm file. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 17:21:17 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA05977 for ; Fri, 27 Sep 1996 17:21:11 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA01393 for png-list-outgoing; Fri, 27 Sep 1996 17:21:18 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA01387 for ; Fri, 27 Sep 1996 17:21:14 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id SAA28851 for ; Fri, 27 Sep 1996 18:21:00 -0400 (EDT) To: PNG List Subject: Re: "Component bit depth In-reply-to: Your message of Fri, 27 Sep 1996 15:06:05 -0700 (PDT) <199609272206.PAA19542@web1.calweb.com> Date: Fri, 27 Sep 1996 18:20:59 -0400 Message-ID: <28849.843862859@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List "Lee Daniel Crocker" writes: > It's not too late to clarify the RFC, is it? I'm afraid it is, unless you want to risk rfc-editor dropping it back down to the bottom of her queue. Or worse, kicking it back to IETF for re-approval :-( The spec *would* have been clarified last year if we could have agreed on a uniform, non intrusive terminology; neither Glenn nor I were happy about the slippery usage of "bit depth" to mean several not-quite-identical things. But no two of us seemed to agree on quite what to use for which concept. In practice, I believe that all the uses are reasonably clear in context, and that insisting on three or four precisely defined terms would be mostly pedantry. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 17:30:44 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA06347 for ; Fri, 27 Sep 1996 17:30:41 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA01687 for png-list-outgoing; Fri, 27 Sep 1996 17:30:51 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id RAA01682 for ; Fri, 27 Sep 1996 17:30:48 -0500 Date: Fri, 27 Sep 96 18:22:49 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: "Component bit depth Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609271822.aa11888@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Subject: "Component bit depth }Date: Fri, 27 Sep 1996 15:06:05 -0700 (PDT) }From: Lee Daniel Crocker }> I tried a year ago to get us to use a better terminology that }> distinguished between the PNG datastream bit_depth (IHDR_bit_depth) }> and the sample_bit_depth,... } }I don't remember that discussion, but I would have agreed. Using }the same term for two things is a bad way to write a spec. } }> Naturally it's too late to change anything in the PNG spec. But maybe }> we could use "component_bit_depth" here, for clarity. } }It's not too late to clarify the RFC, is it? } Gotta go home, but these messages keep coming in... When I wrote to the rfc-editor on 27 August, she said we were "chugging up the queue". I assume we are in exactly the same backlogged position today, because no RFC's have been released since then. I assume that she hasn't started work on ours yet so it would be ok to resubmit. She's already accepted a couple from me with updated author addresses and one with the month changed from August to September. It would not be a big deal to sweep through the spec hunting for "depth" and change wording, if only we could decide on the right words for the two meanings. I can't really think of good ones. IHDR_bit_depth is precise but somewhat ugly. Maybe "sample depth" and "bit depth" would work best, if we define them carefully.. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 17:31:18 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA06367 for ; Fri, 27 Sep 1996 17:31:14 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA01702 for png-list-outgoing; Fri, 27 Sep 1996 17:31:23 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA01696 for ; Fri, 27 Sep 1996 17:31:19 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id QAA07617; Fri, 27 Sep 1996 16:31:05 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609272231.QAA07617@enel.ucalgary.ca> Subject: Re: Discussion on pCAL To: png-list@dworkin.wustl.edu Date: Fri, 27 Sep 1996 16:31:05 -0600 (MDT) In-Reply-To: <9609271801.aa11622@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 27, 96 06:01:56 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > Precisely. I can pick the "pressure megapascals" when I am looking at it > but when an engineer walks in and can't figure it out I just hit the > "pressure psi" button and make the engineer happy. Only engineers in the USA . > }This is > }fine with the fALS chunk, and may even be a good idea for dRNG (for MNG > }that is), but you don't see a need for a "purpose" field in pHYS, do you? > > No, nor do I see one for xsCL because the units field at the beginning > does the same job. However, dRNG also has a textual "Unit" field like pHYS and xSCL, which you would use to select the correct version of pCAL without the need for a redundant "purpose" field (maybe it was overlooked as it slid farther down the list of fields after the addition of the "signature" field - ie about the same time the "purpose" field was added). Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 17:42:27 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA06575 for ; Fri, 27 Sep 1996 17:42:24 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA01941 for png-list-outgoing; Fri, 27 Sep 1996 17:42:30 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA01934 for ; Fri, 27 Sep 1996 17:42:23 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id PAA23228 for ; Fri, 27 Sep 1996 15:35:03 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id PAA03715 for png-list@dworkin.wustl.edu; Fri, 27 Sep 1996 15:35:03 -0700 (PDT) Message-Id: <199609272235.PAA03715@web1.calweb.com> Subject: Re: "Component bit depth" To: png-list@dworkin.wustl.edu Date: Fri, 27 Sep 1996 15:35:02 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <9609271822.aa11888@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 27, 96 06:22:49 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > It would not be a big deal to sweep through the spec hunting for "depth" > and change wording, if only we could decide on the right words for the > two meanings. I can't really think of good ones. IHDR_bit_depth is > precise but somewhat ugly. Maybe "sample depth" and "bit depth" would > work best, if we define them carefully.. Like Tom, I would not want to jeopardize our position in the queue for this, but it would be nice. I'm really surprized I missed this discussion--it's right up my alley. How about "encoded bit depth" and "sampled bit depth"? ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 18:02:44 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA06956 for ; Fri, 27 Sep 1996 18:02:38 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA01464 for png-list-outgoing; Fri, 27 Sep 1996 17:23:57 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA01451 for ; Fri, 27 Sep 1996 17:23:52 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id QAA07576; Fri, 27 Sep 1996 16:23:38 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609272223.QAA07576@enel.ucalgary.ca> Subject: Re: Discussion on dRNG To: png-list@dworkin.wustl.edu Date: Fri, 27 Sep 1996 16:23:37 -0600 (MDT) In-Reply-To: <9609271748.aa11317@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 27, 96 05:48:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > The "output_bit_depth" refers to the output of the drng operation and > has nothing to do with the output frame buffer. I'm not sure I agree. From the standpoint of someone who is writing an encoder and/or decoder, the output_bit_depth would be the final size at which they wanted the data to be in, rather than anything related to the bit depth stored in the file. Why would they want to do multiple conversions of the data (ie from 16-bit dRNG encoded to 16-bit raw RGB (if this makes any kind of sense) to 5- or 8- or 12- bit RGB for display), when it can be done in a single step with fewer calculations? Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 18:11:41 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA07026 for ; Fri, 27 Sep 1996 18:11:40 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA02448 for png-list-outgoing; Fri, 27 Sep 1996 18:11:38 -0500 Received: from enel.ucalgary.ca ([136.159.99.2]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA02441 for ; Fri, 27 Sep 1996 18:11:34 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id RAA07777; Fri, 27 Sep 1996 17:11:16 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609272311.RAA07777@enel.ucalgary.ca> Subject: Re: Discussion on dRNG To: png-list@dworkin.wustl.edu Date: Fri, 27 Sep 1996 17:11:16 -0600 (MDT) In-Reply-To: <199609272217.PAA08191@dawn13.CS.Berkeley.EDU> from "Adam M. Costello" at Sep 27, 96 03:17:39 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Adam (not Glenn, phew) writes: > The core PNG spec places the responsibility for scaling the samples to > the range [0..2^bitdepth-1] on the encoder. The dRNG proposal shifts > that responsibility to the decoder, which changes the file format. My > point is that this is not necessary. However, this assumes that the encoder knows what is the best way of encoding the file, which is often difficult without human intervention. I think you are only looking at dRNG from one point of view - the encoder is storing values in the range [min,max] (where min is the actual minimum data value, and max is the actual maximum data value stored in the file). However, in the application that I want to use dRNG in, [min,max] is just the suggested initial viewing range, but allows pixel values to be whiter-than-white, and perhaps negative values as well. When rendering an image with POV-Ray (which may take a great deal of time), it is difficult to determine appropriate lighting values that make the image have a good dynamic range of intensities. Normally POV clips values to [0.0,1.0] before converting to a given bit depth for storage in a file. With dRNG, POV would be able to tell the PNG decoder where it would have clipped the data values to [0.0,1.0] and yet store values in the range [0.0,16.0] and allow the user to decide what the maximum intensity should be without having to re-render the whole image after adjusting the lighting levels (this is eqivalent to a videographer changing the brightness setting while filming and viewing on the monitor, rather than a filmographer developing a movie reel and having to go back and re-shoot the whole scene because it was under- or over-exposed (or maybe getting fired :-)). I can't remember which other renderer does this (I suspect Radiance), but it stores the output in a proprietary 32-bit floating-point output format, and comes with its own viewer and conversion tools, but I would rather use PNG. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 18:43:43 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA07173 for ; Fri, 27 Sep 1996 18:43:42 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA02825 for png-list-outgoing; Fri, 27 Sep 1996 18:43:44 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA02819 for ; Fri, 27 Sep 1996 18:43:24 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id QAA03278 for ; Fri, 27 Sep 1996 16:36:06 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id QAA04102 for png-list@dworkin.wustl.edu; Fri, 27 Sep 1996 16:36:05 -0700 (PDT) Message-Id: <199609272336.QAA04102@web1.calweb.com> Subject: Re: Discussion on dRNG To: png-list@dworkin.wustl.edu Date: Fri, 27 Sep 1996 16:36:05 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <199609272311.RAA07777@enel.ucalgary.ca> from "Andreas Dilger" at Sep 27, 96 05:11:16 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > Adam (not Glenn, phew) writes: > > The core PNG spec places the responsibility for scaling the samples to > > the range [0..2^bitdepth-1] on the encoder. The dRNG proposal shifts > > that responsibility to the decoder, which changes the file format. My > > point is that this is not necessary. > > However, this assumes that the encoder knows what is the best way of > encoding the file, which is often difficult without human intervention. That's true, but we made that decision and we have to stick to it. Even if the encoder doesn't have all the facts, it has more than the decoder does. If the encoder has to guess or solicit human input, that's still 100 times better than asking the decoder to. Guessing is perfectly acceptable. Abrogating the responsibility is not. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 19:09:32 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id TAA07277 for ; Fri, 27 Sep 1996 19:09:32 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA03124 for png-list-outgoing; Fri, 27 Sep 1996 19:09:40 -0500 Received: from epfl2 ([192.188.199.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id TAA03119 for ; Fri, 27 Sep 1996 19:09:36 -0500 Received: by epfl2 (5.0/SMI-SVR4) id AA11367; Fri, 27 Sep 1996 20:07:51 -0400 Date: Fri, 27 Sep 1996 20:07:51 -0400 (EDT) From: Glenn Randers-Pehrson To: PNG List Subject: Re: Discussion on dRNG In-Reply-To: <199609272223.QAA07576@enel.ucalgary.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Fri, 27 Sep 1996, Andreas Dilger wrote: > Glenn writes: > > The "output_bit_depth" refers to the output of the drng operation and > > has nothing to do with the output frame buffer. > > I'm not sure I agree. From the standpoint of someone who is writing an > encoder and/or decoder, the output_bit_depth would be the final size at > which they wanted the data to be in, rather than anything related to the > bit depth stored in the file. Why would they want to do multiple conversions > of the data (ie from 16-bit dRNG encoded to 16-bit raw RGB (if this makes > any kind of sense) to 5- or 8- or 12- bit RGB for display), when it can be > done in a single step with fewer calculations? They wouldn't want to. The spec just describes the intended outcome of the dRNG step. It is up to the application writer to gather all of the steps (PLTE lookup, dRNG, gAMA, cHRM) up into a lookup table. Doesn't libpng do that (except for dRNG)? ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 19:18:44 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id TAA07314 for ; Fri, 27 Sep 1996 19:18:41 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA03290 for png-list-outgoing; Fri, 27 Sep 1996 19:18:51 -0500 Received: from epfl2 ([192.188.199.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id TAA03285 for ; Fri, 27 Sep 1996 19:18:47 -0500 Received: by epfl2 (5.0/SMI-SVR4) id AA11699; Fri, 27 Sep 1996 20:17:01 -0400 Date: Fri, 27 Sep 1996 20:17:00 -0400 (EDT) From: Glenn Randers-Pehrson To: PNG List Subject: Re: Discussion on pCAL In-Reply-To: <199609272231.QAA07617@enel.ucalgary.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Fri, 27 Sep 1996, Andreas Dilger wrote: > Glenn writes: > > No, nor do I see one for xsCL because the units field at the beginning > > does the same job. > > However, [pCAL] also has a textual "Unit" field like [xSCL], which > you would use to select the correct version of pCAL without the need for > a redundant "purpose" field (maybe it was overlooked as it slid farther It was already in the wrong place, after the "equation type". Anyway, I do see a need for one for xsCL and friends, too, because the unit field is likely to be long and unwieldy while the purpose field can be a convenient single word. Now that I think about it a little more, I'd probably arrange the library so that the handles were "SI", "cgms", and "english", so I could pick a whole suite of pCAL, xsCL, and ysCL with one click of the mouse (or command-line option in my case). ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 19:24:26 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id TAA07340 for ; Fri, 27 Sep 1996 19:24:23 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA03345 for png-list-outgoing; Fri, 27 Sep 1996 19:24:31 -0500 Received: from epfl2 ([192.188.199.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id TAA03340 for ; Fri, 27 Sep 1996 19:24:28 -0500 Received: by epfl2 (5.0/SMI-SVR4) id AA11847; Fri, 27 Sep 1996 20:22:37 -0400 Date: Fri, 27 Sep 1996 20:22:37 -0400 (EDT) From: Glenn Randers-Pehrson To: PNG List Subject: Re: "Component bit depth" In-Reply-To: <199609272235.PAA03715@web1.calweb.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Fri, 27 Sep 1996, Lee Daniel Crocker wrote: > > It would not be a big deal to sweep through the spec hunting for "depth" > > and change wording, if only we could decide on the right words for the > > two meanings. I can't really think of good ones. IHDR_bit_depth is > > precise but somewhat ugly. Maybe "sample depth" and "bit depth" would > > work best, if we define them carefully.. > > Like Tom, I would not want to jeopardize our position in the queue > for this, but it would be nice. I'm really surprized I missed this > discussion--it's right up my alley. It may have been off-list when tom and I were preparing the RFC. I seem to recall that it was while we were working on the glossary last August (my SO's idea, does she get to vote?) > > How about "encoded bit depth" and "sampled bit depth"? "bit depth" and "sample depth" would require the smallest amount of change to the document. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 20:23:35 1996 Received: from dworkin.wustl.edu ([128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id UAA07705 for ; Fri, 27 Sep 1996 20:23:30 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA04170 for png-list-outgoing; Fri, 27 Sep 1996 20:23:24 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id UAA04164 for ; Fri, 27 Sep 1996 20:23:20 -0500 Date: Fri, 27 Sep 96 21:22:54 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: "Component bit depth" Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609272122.aa12774@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List }From: Lee Daniel Crocker }Like Tom, I would not want to jeopardize our position in the queue }for this, but it would be nice. I'm really surprized I missed this }discussion--it's right up my alley. } I found the thread, entitled Charles Poynton's comments. The messages are longish; here are the snippets dealing with the topic at hand: ----- Forwarded message # 1: Date: Tue, 4 Jul 95 2:00:29 GMT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: png-list@godzilli.cs.sunysb.edu Subject: Re: Charles Poynton's comments Organization: U.S. Army Research Laboratory, APG, MD In reply to the message > Date: Mon, 3 Jul 1995 12:38:38 -0700 > From: Dave Martindale > Subject: Charles Poynton's comments Charles Poynton wrote: >This note comments on the PNG specification, ninth draft. [...] >It seems to me that the depth of a bit is one. I suggest that the term >"bits per sample" replace "bit depth". This also makes it clear that it's >per sample (component), not per pixel. OK. But some places we're talking about the bits per field in the data stream. So maybe we need "bits per field" (the number found in the IHDR chunk) and bits per component/sample/channel (which is the same as bits per field except for colormapped pixels, which have 8 bits per component regardless of the number of bits per field). [...] ../glennrp ----- Forwarded message # 2: From: lilley Subject: More on Charles Poynton's comments To: png-list@dworkin.wustl.edu Date: Fri, 11 Aug 1995 19:09:04 +0100 (BST) On Tue, 4 Jul 95 Glenn said: > On Mon, 3 Jul 1995 Charles Poynton said. >>It seems to me that the depth of a bit is one. I suggest that the term >>"bits per sample" replace "bit depth". This also makes it clear that it's >>per sample (component), not per pixel. > OK. But some places we're talking about the bits per field in the > data stream. So maybe we need "bits per field" (the number found in > the IHDR chunk) and bits per component/sample/channel (which is the > same as bits per field except for colormapped pixels, which have 8 > bits per component regardless of the number of bits per field). Again I agree with Glenn. We should use both of the terms bits per component and bits per field, as appropriate. -- Chris Lilley, Technical Author ----- Forwarded message # 3: Subject: Re: More on Charles Poynton's comments Date: Fri, 11 Aug 1995 15:19:30 -0400 From: Tom Lane >> So, yes, use the term component. A grey scale image has one component, >> and RGB image three components and an RGBA image four components. > Hmmm. I think it has 3 components and an alpha channel. The components > are the things you mix together to make the color, while alpha is some > additional information, i.e. how to mix the components with the existing > background. > I still like "component" better, but these are good reasons for maybe > using "channel" to describe the pixel data field that represents each > primary color component or alpha. The existing spec text is actually fairly consistent in using this terminology: sample = one value pixel = all the samples at one physical location channel = one image plane, ie all the samples of the "same kind" In other words, sample is to pixel as channel is to image. A quick search finds one or two places where "component" is used instead of "channel"; that should be fixed for consistency. And a couple of uses of "bits per channel" that should be "bits per sample". But the inconsistency is not as great as was alleged at the start of this thread. > One way to handle this would to add a glossary section to the spec/rfc > (which my wife recommended). Not a bad idea at all. Can we steal our definitions from somewhere, or will we have to come up with them ourselves? regards, tom lane ----- End of forwarded messages ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Fri Sep 27 23:58:15 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id XAA08671 for ; Fri, 27 Sep 1996 23:58:14 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA06669 for png-list-outgoing; Fri, 27 Sep 1996 23:58:07 -0500 Received: from dawn13.CS.Berkeley.EDU (dawn13.CS.Berkeley.EDU [128.32.38.57]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id XAA06664 for ; Fri, 27 Sep 1996 23:58:03 -0500 Received: (from amc@localhost) by dawn13.CS.Berkeley.EDU (8.6.11/8.6.9) id VAA11341 for png-list@dworkin.wustl.edu; Fri, 27 Sep 1996 21:57:47 -0700 Date: Fri, 27 Sep 1996 21:57:47 -0700 Message-Id: <199609280457.VAA11341@dawn13.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: "Component bit depth" X-Advice: should read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List PNG is going to be both an RFC and a W3C Recommendation. Can someone assure me that, except for meta-content (like the intro at the very beginning), the two will be word-for-word identical? If this bit-depth edit sacrifices consistency, then I say forget it. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 02:15:11 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id CAA09365 for ; Sat, 28 Sep 1996 02:15:10 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id CAA07888 for png-list-outgoing; Sat, 28 Sep 1996 02:14:55 -0500 Received: from mega.megamed.com (megamed.com [199.4.114.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id CAA07883 for ; Sat, 28 Sep 1996 02:14:51 -0500 Received: from coruisk (mega211.megamed.com [199.4.114.211]) by mega.megamed.com (8.7.5/8.7.3) with SMTP id AAA14378 for ; Sat, 28 Sep 1996 00:14:20 -0700 Date: Sat, 28 Sep 1996 00:14:20 -0700 Message-Id: <199609280714.AAA14378@mega.megamed.com> X-Sender: jbowler@megamed.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: John Bowler Subject: Re: New chunk registration process 19960926 Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 14:44 26/09/96 EDT, Glenn wrote: > >This corrects the errors that Adam pointed out and makes some >other minor clarifications. The Security considerations section >is added. Any more tinkering needed? > >../glennrp > >png-registration-19960926 >Thu Sep 26 14:30:23 EDT 1996 No, I think not. I see only trivial changes, and very few of those. We should consider this the start of the discussion period, with the specification being:- png-registration 19960926 ftp://swrinde.nde.swri.edu/pub/png-group/documents/ png-registration-19960926.html John Bowler (jbowler@acm.org) Suggestions for non-substantive changes (I don't regard any of these as essential):- > Upon the objection (on grounds that the change is nontrivial) > of any person who would be eligible to vote if the voting > period were to start immediately after the close of the > discussion period, received by the png-list server prior to the > call for votes, the two-week discussion period must be > restarted in the event of any such change. I find this somewhat difficult to read, maybe:- "If an objection that a change is nontrivial is received from an eligible person the two-week discussion period must be restarted. Any person is eligible to raise such an objection if they would also be eligible to vote if the voting period were to start immediately after the close of the current discussion period. Such an objection must be received by the png-list servier prior to the call for votes." > 4.2. Casting votes The HTML version referenced above has no section number (similarly for section 4.3). > > {YES|NO|ABSTAIN} > In Appendix 1 the sample message uses:- > cNEW 19991231 So, perhaps, this item should be:- [] > * John Bowler, jbowler@megamed.com I prefer jbowler@acm.org - this is the ACM email redirector, thus is more likely to remain valid. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 02:19:32 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id CAA09378 for ; Sat, 28 Sep 1996 02:19:31 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id CAA07962 for png-list-outgoing; Sat, 28 Sep 1996 02:19:43 -0500 Received: from enel.ucalgary.ca ([136.159.100.11]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id CAA07957 for ; Sat, 28 Sep 1996 02:19:40 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id BAA08699; Sat, 28 Sep 1996 01:19:23 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609280719.BAA08699@enel.ucalgary.ca> Subject: Re: Discussion on dRNG To: png-list@dworkin.wustl.edu Date: Sat, 28 Sep 1996 01:19:23 -0600 (MDT) In-Reply-To: <199609272336.QAA04102@web1.calweb.com> from "Lee Daniel Crocker" at Sep 27, 96 04:36:05 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I wrote: > > However, this assumes that the encoder knows what is the best way of > > encoding the file, which is often difficult without human intervention. Adam replied: > Even if the encoder doesn't have all the facts, it has more than the > decoder does. If the encoder has to guess or solicit human input, > that's still 100 times better than asking the decoder to. Guessing > is perfectly acceptable. Abrogating the responsibility is not. dRNG is the way of passing on the "known facts" or the "guess" from the encoder to the decoder, so it doesn't have to "guess" any more than the encoder does, yet without discarding possibly useful info until the viewer can make a final decision. In POV-Ray, it is impractical to solicit human input without building a full-fledged image processing system into POV. The current method is the "guess" you are talking about - assuming that data values in the range [0.0, 1.0] contain a range of intensity values that allows the viewer to see the desired scene contents well. I'm trying to make it better than simply a guess by allowing user "feedback" in an offline setting since ray tracing can be very slow. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 02:53:21 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id CAA09477 for ; Sat, 28 Sep 1996 02:53:18 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id CAA08208 for png-list-outgoing; Sat, 28 Sep 1996 02:53:29 -0500 Received: from enel.ucalgary.ca ([136.159.99.2]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id CAA08203 for ; Sat, 28 Sep 1996 02:53:25 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id BAA08719; Sat, 28 Sep 1996 01:53:07 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609280753.BAA08719@enel.ucalgary.ca> Subject: Re: Discussion on dRNG To: png-list@dworkin.wustl.edu Date: Sat, 28 Sep 1996 01:53:06 -0600 (MDT) In-Reply-To: from "Glenn Randers-Pehrson" at Sep 27, 96 08:07:51 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > The spec just describes the intended outcome of the dRNG step. In this case, wouldn't it be best to keep the outcome of the dRNG step in a floating-point value in the range [0.0, 1.0] (ie between min_value and max_value) until we know the desired final output bit depth? Given the way the "ratio" formula and the "output_sample" LIMIT are written, you have to agree that the bit_depth referred two in the two equations should be called the same thing. However, in saying that the output_bit_depth is the same as the IHDR_bit_depth is confusing, IMHO. I had always taken it to be the desired final screen bit depth (which is what this chunk is in essence describing). But after more thought I now realize that it needs to be stored at the IHDR_bit_depth for subsequent processing by the gAMA, cHRM, and alpha conversions. Maybe this should be clarified? In the initial chunk description, it mentions dRNG useful when pixel values do not occupy the full range of possible values, but it does not mention my particular application - when the pixel values occupy a larger range of values than is viewable at a given time. We have already discussed the removal of the sBIT reference. Also, in looking at the proposal closer, the mention of indexed-color images after the formula descriptions disturbs me. I think we should make it clear that the dRNG transformation should be applied to the values in the colormap and not on the indices themselves. Even so, I doubt any indexed-color images exist that would need to use this chunk (ie they would need to be converted from images that had non-power-of-two color representations - very rare indeed). > It is up to the application writer to gather all of the > steps (PLTE lookup, dRNG, gAMA, cHRM) up into a lookup table. > Doesn't libpng do that (except for dRNG)? libpng handles the gAMA correction in a table, but still doesn't do anything with cHRM. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 04:25:47 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id EAA10063 for ; Sat, 28 Sep 1996 04:25:37 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id EAA09118 for png-list-outgoing; Sat, 28 Sep 1996 04:25:38 -0500 Received: from enel.ucalgary.ca ([136.159.100.11]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id EAA09113 for ; Sat, 28 Sep 1996 04:25:35 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id DAA08871; Sat, 28 Sep 1996 03:25:18 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609280925.DAA08871@enel.ucalgary.ca> Subject: Re: Discussion on pCAL To: png-list@dworkin.wustl.edu Date: Sat, 28 Sep 1996 03:25:17 -0600 (MDT) In-Reply-To: from "Glenn Randers-Pehrson" at Sep 27, 96 08:17:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > Now that I think about it a little more, I'd probably arrange > the library so that the handles were "SI", "cgms", and "english", so I could > pick a whole suite of pCAL, xsCL, and ysCL with one click of the mouse Your suggestion is appealing in the sense of allowing multiple units of measure for a given data set - I hadn't thought of this. However, in this regard you would be forced to use MNG in order to store multiple pCAL for a single data set. Yet we can't be allowed to store multiple pCAL chunks a single PNG, in case they became inconsistent with each other. Since the equation type tells us how many parameters there are, we could allow a "repeated" unit/parameter sets if there was a Null separator after the last parameter. The equation type would remain at the beginning, and for each measurement system you would (obviously) use the same formula type, but just different parameters a different unit field. In many cases, the pCAL chunk would just have a single unit type, and would be identical to the current spec. Looking at the current spec more, do we need the "number of parameters" field anymore? I recall that at one time there were optional fields in this chunk, but now the equation type specifies how many parameters we need for each, so this is redundant unless we want to have a polynomial equation type in the future which has a variable number of parameters (no, I'm not suggesting we add such a beast). For example, for a converted USGS DEM topo map we might have: pCAL 0 - linear equation type feet above sea level\0 326\0 1\0 meters above sea level\0 99.3648\0 0.3048 For the decoder, it could simply pop up a menu during decoding to allow the user to pick the desired measurement system. For that matter, if it was creating a scale bar it could just show all of the available unit types at the same time. Also, is it worthwhile to extend xsCL and ysCL similarly, rather than using the "purpose" field, and forcing the use of MNG when it's not really needed? Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 04:43:51 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id EAA10112 for ; Sat, 28 Sep 1996 04:43:39 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id EAA09245 for png-list-outgoing; Sat, 28 Sep 1996 04:43:42 -0500 Received: from epfl2 ([192.188.199.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id EAA09240 for ; Sat, 28 Sep 1996 04:43:39 -0500 Received: by epfl2 (5.0/SMI-SVR4) id AA23256; Sat, 28 Sep 1996 05:41:52 -0400 Date: Sat, 28 Sep 1996 05:41:51 -0400 (EDT) From: Glenn Randers-Pehrson To: PNG List Subject: Re: Discussion on dRNG In-Reply-To: <199609280753.BAA08719@enel.ucalgary.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sat, 28 Sep 1996, Andreas Dilger wrote: > Glenn writes: > > The spec just describes the intended outcome of the dRNG step. > > In this case, wouldn't it be best to keep the outcome of the dRNG > step in a floating-point value in the range [0.0, 1.0] (ie between > min_value and max_value) until we know the desired final output > bit depth? Given the way the "ratio" formula and the "output_sample" > LIMIT are written, you have to agree that the bit_depth referred > two in the two equations should be called the same thing. > > However, in saying that the output_bit_depth is the same as the > IHDR_bit_depth is confusing, IMHO. I had always taken it to be > the desired final screen bit depth (which is what this chunk is > in essence describing). But after more thought I now realize > that it needs to be stored at the IHDR_bit_depth for subsequent > processing by the gAMA, cHRM, and alpha conversions. Maybe > this should be clarified? More importantly, the encoder hasn't the foggiest idea of what the decoder's frame buffer depth is. How can it set the values for dRNG using a scale of 0 to 2^frame_buffer_depth-1 ? > > In the initial chunk description, it mentions dRNG useful when > pixel values do not occupy the full range of possible values, > but it does not mention my particular application - when the > pixel values occupy a larger range of values than is viewable > at a given time. We have already discussed the removal of the > sBIT reference. Please write an appropriate sentence or two. Then duck. > > Also, in looking at the proposal closer, the mention of indexed-color > images after the formula descriptions disturbs me. I think we should > make it clear that the dRNG transformation should be applied to the > values in the colormap and not on the indices themselves. Doesn't the mention of bit_depth=8 take care of that? Certainly if we had used "sample depth" (where sample depth is defined to mean IHDR_bit_depth for truecolor files and 8 for indexed-color files) it would be crystal clear. > Even so, I > doubt any indexed-color images exist that would need to use this chunk > (ie they would need to be converted from images that had non-power-of-two > color representations - very rare indeed). If the colors look "wrong" but you want to preserve the PLTE anyway you could use dRNG. > > > It is up to the application writer to gather all of the > > steps (PLTE lookup, dRNG, gAMA, cHRM) up into a lookup table. > > Doesn't libpng do that (except for dRNG)? > > libpng handles the gAMA correction in a table, but still doesn't do > anything with cHRM. Maybe the authors don't know exactly how to write the algorithms to do the transformations? I wish I did; I'd put it in viewpng right away. I don't, and I can't figure it out from the color tutorial. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 04:54:04 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id EAA10133 for ; Sat, 28 Sep 1996 04:54:03 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id EAA09316 for png-list-outgoing; Sat, 28 Sep 1996 04:54:06 -0500 Received: from epfl2 (epfl2.epflbalto.org [192.188.199.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id EAA09311 for ; Sat, 28 Sep 1996 04:54:03 -0500 Received: by epfl2 (5.0/SMI-SVR4) id AA23380; Sat, 28 Sep 1996 05:52:16 -0400 Date: Sat, 28 Sep 1996 05:52:16 -0400 (EDT) From: Glenn Randers-Pehrson To: PNG List Subject: Re: Discussion on pCAL In-Reply-To: <199609280925.DAA08871@enel.ucalgary.ca> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sat, 28 Sep 1996, Andreas Dilger wrote: > Glenn writes: > > Now that I think about it a little more, I'd probably arrange > > the library so that the handles were "SI", "cgms", and "english", so I could > > pick a whole suite of pCAL, xsCL, and ysCL with one click of the mouse > > Your suggestion is appealing in the sense of allowing multiple units of > measure for a given data set - I hadn't thought of this. However, in this > regard you would be forced to use MNG in order to store multiple pCAL > for a single data set. Yet we can't be allowed to store multiple pCAL > chunks a single PNG, in case they became inconsistent with each other. That's ok. The writeup says "in a multiple image context" or words to that effect. > > Since the equation type tells us how many parameters there are, we could > allow a "repeated" unit/parameter sets if there was a Null separator after > the last parameter. The equation type would remain at the beginning, and > for each measurement system you would (obviously) use the same formula type, > but just different parameters a different unit field. In many cases, the > pCAL chunk would just have a single unit type, and would be identical to the > current spec. This is much more complex than my proposal, and it doesn't generalize. With a textual "handle" at the beginning of a chunk, the proposed SBYK MNG mechanism works the same way for text, splt, fals, etc., etc.. Putting multiple equations in one pcal is no different from allowing multiple pcals in a PNG file, and we don't want to do that because it in effect makes PNG a multiple image format. But I see nothing wrong with defining the chunks with MNG in mind. > > Looking at the current spec more, do we need the "number of parameters" > field anymore? I recall that at one time there were optional fields in > this chunk, but now the equation type specifies how many parameters we > need for each, so this is redundant unless we want to have a polynomial > equation type in the future which has a variable number of parameters > (no, I'm not suggesting we add such a beast). Your suggestion would preclude such a beast. We don't want to do that, either. > > For example, for a converted USGS DEM topo map we might have: > > > pCAL > 0 - linear equation type > feet above sea level\0 > 326\0 > 1\0 > meters above sea level\0 > 99.3648\0 > 0.3048 > > > For the decoder, it could simply pop up a menu during decoding to allow > the user to pick the desired measurement system. For that matter, if > it was creating a scale bar it could just show all of the available > unit types at the same time. This is in the province of MNG. > > Also, is it worthwhile to extend xsCL and ysCL similarly, rather than > using the "purpose" field, and forcing the use of MNG when it's not > really needed? What's wrong with encouraging the use of MNG for multiple image applications? ../glennrp (shell-shocked but rested up now) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 06:08:50 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id GAA11104 for ; Sat, 28 Sep 1996 06:08:47 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id GAA09863 for png-list-outgoing; Sat, 28 Sep 1996 06:08:44 -0500 Received: from enel.ucalgary.ca ([136.159.100.11]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id GAA09858 for ; Sat, 28 Sep 1996 06:08:41 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id FAA08991; Sat, 28 Sep 1996 05:08:24 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609281108.FAA08991@enel.ucalgary.ca> Subject: Re: Discussion on dRNG To: png-list@dworkin.wustl.edu Date: Sat, 28 Sep 1996 05:08:23 -0600 (MDT) In-Reply-To: from "Glenn Randers-Pehrson" at Sep 28, 96 05:41:51 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > More importantly, the encoder hasn't the foggiest idea of what > the decoder's frame buffer depth is. How can it set the values > for dRNG using a scale of 0 to 2^frame_buffer_depth-1 ? This is irrelevant, since the encoder is only storing min_val and max_val in the dRNG chunk - the decoder would supply frame_buffer_depth, which we both now agree is not the correct thing to use. [re the dRNG chunk description] > Please write an appropriate sentence or two. Then duck. How about: "This chunk is intended for use when the encoded pixel values do not reasonably span the full range of possible values as the PNG spec mandates. It can be used to clip the dynamic range of an image to a sub-set of the available pixel values, in order to allow the storage of values which are brighter than what the encoder considers a desirable "maximum intensity". Similarly, it can be used to enhance or reduce the contrast and brightness of pixel values that are stored losslessly and cannot be scaled to fill the full range of possible pixel values. The chunk defines the minimum and maximum pixel values that correspond to the minimum and maximum intensity, respectively. [Re indexed color images] > Doesn't the mention of bit_depth=8 take care of that? Certainly if > we had used "sample depth" (where sample depth is defined to mean > IHDR_bit_depth for truecolor files and 8 for indexed-color files) > it would be crystal clear. Maybe we should write: "For indexed-color images, bit-depth == 8 should be used with this calculation to correct the palette color values, and the color indices should not be changed." > Maybe the authors don't know exactly how to write the algorithms to > do the transformations? I wish I did; I'd put it in viewpng right away. > I don't, and I can't figure it out from the color tutorial. Nope, I don't know exactly how to use cHRM. It is unfortunate that, while the Color Tutorial in the PNG spec tells a lot about the concepts, neither it nor the cHRM chunk description give any code or examples of how to take the cHRM x,y values and the monitor x,y values and creating a simple transfer function from input RGB to output RGB. If it mentioned knew how to convert from Red x,y to Xr, Yr, Zr, etc it could be done. It gets you nearly there, but I'm just not putting it together, I guess. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 06:17:29 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id GAA11136 for ; Sat, 28 Sep 1996 06:17:26 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id GAA09955 for png-list-outgoing; Sat, 28 Sep 1996 06:17:40 -0500 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id GAA09950 for ; Sat, 28 Sep 1996 06:17:37 -0500 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id FAA09007; Sat, 28 Sep 1996 05:17:15 -0600 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199609281117.FAA09007@enel.ucalgary.ca> Subject: Re: Discussion on pCAL To: png-list@dworkin.wustl.edu Date: Sat, 28 Sep 1996 05:17:15 -0600 (MDT) In-Reply-To: from "Glenn Randers-Pehrson" at Sep 28, 96 05:52:16 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > Putting multiple equations in one pcal is no different from allowing > multiple pcals in a PNG file, and we don't want to do that because it > in effect makes PNG a multiple image format. But I see nothing wrong > with defining the chunks with MNG in mind. It differs in that you don't run the risk of one pCAL chunk being modified for some reason, or a new one being added, that doesn't give the same measurements as the other pCAL chunks stored in the file. I don't think this is in the domain of a multi-image format any more than having a text chunk in english and one in german that are saying the same thing. Unlike multiple dRNG, sPAL, or fALS chunks, we aren't changing the pixel values being viewed in any way. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 08:32:08 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id IAA11487 for ; Sat, 28 Sep 1996 08:32:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA10895 for png-list-outgoing; Sat, 28 Sep 1996 08:31:58 -0500 Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA10889 for ; Sat, 28 Sep 1996 08:31:53 -0500 Received: from fb0430.mathematik.th-darmstadt.de (daemon@fb0430.mathematik.th-darmstadt.de [130.83.2.30]) by rs2.hrz.th-darmstadt.de (8.6.12/8.6.12.1ms) with ESMTP id OAA15458 for ; Sat, 28 Sep 1996 14:31:34 +0100 Received: from fb0401.mathematik.th-darmstadt.de by fb0430.mathematik.th-darmstadt.de (1.37.109.16/Server-1.5/HRZ-THD) id AA026407494; Sat, 28 Sep 1996 15:31:35 +0200 Received: from localhost by fb0401.mathematik.th-darmstadt.de (1.37.109.16/Client-1.5/HRZ-THD) id AA202137490; Sat, 28 Sep 1996 15:31:30 +0200 Date: Sat, 28 Sep 1996 15:31:29 +0200 (MESZ) From: Alexander Lehmann To: PNG List Subject: Re: Uncompressed PNG In-Reply-To: <9609271650.aa10599@THOR.ARL.MIL> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Fri, 27 Sep 1996, Glenn Randers-Pehrson ARL-WMRD-TED-TIB wrote: > What's wrong with this picture? > > scan > scanned.png (compress) > crop < scanned.png > cropped.png (decompress and compress) > scale < cropped.png > scaled.png (decompress and compress) > touchup < scaled.png > touchedup.png (decompress and compress) > png-optimize < touchedup.png > final.png (decompress and maxcompress) > png-qc < final.png (decompress) > > isn't this better? > > scan -u > scanned.png (write) > crop -u < scanned.png > cropped.png (read and write) > scale -u < cropped.png > scaled.png (read and write) > touchup -u < scaled.png > touchedup.png (read and write) > png-optimize < touchedup.png > final.png (read and maxcompress) > png-qc < final.png (decompress) Actually, I would use PBM+ for this (or maybe uncompressed TIFF) unless you ancillary chunks to keep, this should usually be faster than even uncompressed PNG (no CRCs). If you have ancillary chunks about gamma or color characteristics, you can add them in the final step (chances are, they will be dropped by some tools anyway). > }In general, people come to some sort of disk space crunch in one > }way or another. A big part of why JPEG is popular on the Web is the > }space savings for photographic-quality images, not just the > }increased quality (which isn't noticable if you only have an 8-bit > }display). If they care about WWW downloading speed, they will > }probably go with the maximum compression rather than the > }uncompressed file, since bandwidth is usually more of a constraint > }than end-user computational power (look at all the small, yet funky > }animated JAVA stuff on the net that sucks the life out of an older > }computer). On-the-fly generated images may be a use for uncompressed files (if the server is heavily loaded), but usually the transmission time will be more important than the generation time. > Yes. I really wonder why they are sticking with GIF, when PNG almost > always gives significantly better compression? I thought Tom's recent > message about Unisys' regeging on the freeware agreement would spark > some debate, but Tom's message on comp.compression has gone publicly > unanswered [checks newsgroup... this is interesting; it's been cancelled > again] until now (I was one of the four who wrote him). Hm, I saw the article once posted by him (our server had a space shortage recently and it seems it has missed most of the cancel messages) and then reposted by Chris Lewis, if that one is cancelled again, there is something strange going on :-). bye, Alexander -- Alexander Lehmann, | "On the Internet, alex@hal.rhein-main.de (MIME, NeXT) | nobody knows lehmann@mathematik.th-darmstadt.de (MIME) | you're a dog." ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 13:13:20 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA12624 for ; Sat, 28 Sep 1996 13:13:16 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA15869 for png-list-outgoing; Sat, 28 Sep 1996 13:13:04 -0500 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA15863 for ; Sat, 28 Sep 1996 13:12:59 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id LAA18542 for ; Sat, 28 Sep 1996 11:12:34 -0700 X-Sender: davem@mail.cs.ubc.ca (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 28 Sep 1996 11:12:37 -0700 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: Re: Discussion on dRNG Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >> However, this assumes that the encoder knows what is the best way of >> encoding the file, which is often difficult without human intervention. > >That's true, but we made that decision and we have to stick to it. >Even if the encoder doesn't have all the facts, it has more than the >decoder does. If the encoder has to guess or solicit human input, >that's still 100 times better than asking the decoder to. Guessing >is perfectly acceptable. Abrogating the responsibility is not. This argument is fine when there *is* a unique "best" way to view a given image, and the role of the image file is to simply convey this appearance from the image creator to anyone else who wants to view the image. PNG is particularly good at providing enough information that the viewer sees the same image as the creator. However, there are several types of images where the "best" view of the image simply does not exist. Examples are: - digitized X-rays. There is a huge density range on the negative, and you don't want to discard any of it, but when looking at a particular feature (soft tissue, bone, etc) you want a small part of the density range in the data to be mapped to the whole brightness range of the display. But the mapping needed has to be adjusted by the viewer, based on exactly where they are looking - digitized photographic negatives. Film can capture a 10 or 12 f/stop intensity range, while a monitor can display only about 7 stops. It's generally possible to determine a mapping that gives a pleasing CRT image, and if all you want to do is display the image on a CRT then "standard PNG" works fine. But if you want to do further processing on the image data, you probably don't want to discard the information in the 3-5 f/stops of intensity that you can't display. - some astronomical images captured with good CCD cameras have 16 bits of real dynamic range (of course, the night sky itself has an even greater range). The mapping of this data for viewing is dependent on which particular star or galaxy or nebula you happen to be looking at at the moment. In all of these cases, the images *are* images, the sample values *do* represent intensity directly, yet there is no well-defined "maximum intensity" that can be mapped to 255 or 65535 and still have a good image. There is another class of "image" as well where pixel values represent some measurement other than radiant flux (pressure, height, voltage, whatever). Here the mapping from sample value to on-screen intensity is somewhat more arbitrary, but may still need adjustment by the viewer. When PNG was designed, we mostly designed it for an environment where someone predetermines things like brightness and contrast to "fit" the image to what a display can handle, then writes this displayable image into a file. The file is transmitted to someone else. PNG is good at ensuring that the second person sees the same displayable image that the originator saw. The problem comes with images that are not "ready to display", for example because they are beyond the capabilities of current displays. Should PNG simply say "I wasn't designed for that"? That's one legitimate route. But if PNG wants to support such images, we can't assume that there is a "right" way to encode an image. Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 13:51:59 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id NAA12743 for ; Sat, 28 Sep 1996 13:51:58 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA16226 for png-list-outgoing; Sat, 28 Sep 1996 13:52:11 -0500 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA16221 for ; Sat, 28 Sep 1996 13:52:08 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id LAA20753 for ; Sat, 28 Sep 1996 11:51:45 -0700 X-Sender: davem@mail.cs.ubc.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 28 Sep 1996 11:51:45 -0700 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: Re: Discussion on dRNG Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List >How about: > >"This chunk is intended for use when the encoded pixel values do not > reasonably span the full range of possible values as the PNG spec > mandates. It can be used to clip the dynamic range of an image to > a sub-set of the available pixel values, in order to allow the storage > of values which are brighter than what the encoder considers a desirable > "maximum intensity". Similarly, it can be used to enhance or reduce > the contrast and brightness of pixel values that are stored losslessly > and cannot be scaled to fill the full range of possible pixel values. > The chunk defines the minimum and maximum pixel values that correspond > to the minimum and maximum intensity, respectively. I'd suggest "minimum and maximum displayed intensity, respectively". We should clearly distinguish between intensity in the file data and intensity as displayed on screen. However, I've just noticed a problem with dRNG. As far as I can see, the proposed definition does not explain how dRNG interacts with gAMA processing during viewing. There seem to be two possibilities: 1. dRNG is used to rescale the pixel values first. Then any gAMA processing is done. 2. gAMA processing is done to convert sample values to linear space. Then dRNG processing is done to map part of this space to displayable pixel values on screen. Of these, #1 is easiest both to describe and implement. Unfortunately, #2 is, at least in some circumstances, the right thing to do. The gAMA chunk describes a non-linear mapping from scene intensity into sample value. Since many viewers will not understand dRNG, this mapping should be independent of what is in the dRNG chunk. (I hope we all agree on that). But in viewers that do understand dRNG, if the dRNG scaling is applied before any gAMA processing, then the contrast of the image as seen on screen will vary drastically as the "minimum sample value" value is changed. This is because the gAMA transfer function has a slope that varies rapidly near the "zero" point of the input. This may not matter for some applications, but in cases where you want to use dRNG to store an image with a wider dynamic range than you can view at one time, preserving proper image contrast during viewing *is* important. My conclusion is that there is only one correct way for dRNG and gAMA to interact: When decoding sample values for display, the dRNG processing must be inserted into the "gamma processing" pipeline AFTER the step that undoes the gamma encoding of the image file, but BEFORE any steps that account for the display system gamma. dRNG *must* do its linear scaling on sample values that are, in fact, linearly related to scene intensity. This makes implementing dRNG a bit awkward, in that the chunk specifies minimum and maximum values in the gamma-corrected "sample value" space, while the actual transformation must be performed on the linear-intensity intermediate values obtained partway through the gamma processing stages. This is not mathematically difficult - you just have to perform the first stage of gamma processing on the min_sample and max_sample values as well. But it does need to be explained far better than the proposed dRNG document currently does. By the way, thinking about this has, for the first time, pointed out to me an essential difference between dRNG and lOGE: lOGE specifies a nonlinear encoding of intensity into sample values that *replaces* the standard power function described by gAMA. dRNG should be seen as a linear intensity scaling operator that modifies the *linear* intensities that result after decoding either the gAMA or lOGE encoding of the input file, and could be applied with either. This also points out that, in writing the "gamma" sections of the PNG document, I should have been clearer about distinguishing different uses of power-function transfer functions. The non-linear "gamma encoding" used in storing pixels in the file is (logically) entirely independent of the "gamma correction" needed to compensate for the display system. The "gamma encoding" is entirely a function of the sample values in the file, and can be replaced by any other convenient encoding (e.g. lOGE). While the "gamma correction" for the display is always a power function, because the display itself has a power-function response. Hmph. Working out the proper way for all these things to interact is hard. Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 16:35:41 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA13337 for ; Sat, 28 Sep 1996 16:35:40 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA18527 for png-list-outgoing; Sat, 28 Sep 1996 16:35:31 -0500 Received: from epfl2 (epfl2.epflbalto.org [192.188.199.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id QAA18522 for ; Sat, 28 Sep 1996 16:35:26 -0500 Received: by epfl2 (5.0/SMI-SVR4) id AA11569; Sat, 28 Sep 1996 17:33:37 -0400 Date: Sat, 28 Sep 1996 17:33:36 -0400 (EDT) From: Glenn Randers-Pehrson To: PNG List Subject: Re: "Component bit depth" In-Reply-To: <199609280457.VAA11341@dawn13.CS.Berkeley.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Fri, 27 Sep 1996, Adam M. Costello wrote: > PNG is going to be both an RFC and a W3C Recommendation. Can someone > assure me that, except for meta-content (like the intro at the very > beginning), the two will be word-for-word identical? If this bit-depth > edit sacrifices consistency, then I say forget it. > I believe that Chris Lilley and I are in a position to make sure that they stay in sync. Once the rfc-editor releases the RFC it will be cast in stone. That should be Real Soon Now. Or maybe not, given the current rate of 0 rfcs/month ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 16:46:47 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id QAA13382 for ; Sat, 28 Sep 1996 16:46:47 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA18651 for png-list-outgoing; Sat, 28 Sep 1996 16:46:55 -0500 Received: from epfl2 (epfl2.epflbalto.org [192.188.199.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id QAA18646 for ; Sat, 28 Sep 1996 16:46:52 -0500 Received: by epfl2 (5.0/SMI-SVR4) id AA11929; Sat, 28 Sep 1996 17:45:02 -0400 Date: Sat, 28 Sep 1996 17:45:02 -0400 (EDT) From: Glenn Randers-Pehrson To: PNG List Subject: Re: Discussion on dRNG In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Dave wrote > > However, there are several types of images where the "best" view of > the image simply does not exist. Examples are: > > - digitized X-rays. There is a huge density range on the negative, and > you don't want to discard any of it, but when looking at a particular > feature (soft tissue, bone, etc) you want a small part of the density > range in the data to be mapped to the whole brightness range of the > display. But the mapping needed has to be adjusted by the viewer, > based on exactly where they are looking > this was one of the examples I gave way back when I was proposing MNMX, ca. Feb or Mar 1995. Dr. X sends an image to Dr. Y, with a [then MNMX] chunk that highlights a certain feature, with "what to you think of this?". Dr Y then looks at it but also has the full dataset and can readjust (as with "viewpng -drng some_other_set". Obviously it should have been mNMX but I didn't appreciate the critical vs ancillary business yet. Or maybe I did call it mNMX... ../glennrp ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 17:51:33 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA15040 for ; Sat, 28 Sep 1996 17:51:32 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA19335 for png-list-outgoing; Sat, 28 Sep 1996 17:51:29 -0500 Received: from dawn11.CS.Berkeley.EDU (dawn11.CS.Berkeley.EDU [128.32.38.55]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA19329 for ; Sat, 28 Sep 1996 17:51:25 -0500 Received: (from amc@localhost) by dawn11.CS.Berkeley.EDU (8.6.11/8.6.9) id PAA12402 for png-list@dworkin.wustl.edu; Sat, 28 Sep 1996 15:51:00 -0700 Date: Sat, 28 Sep 1996 15:51:00 -0700 Message-Id: <199609282251.PAA12402@dawn11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: Discussion on dRNG X-Advice: should read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List davem@cs.ubc.ca (Dave Martindale) says: > My conclusion is that there is only one correct way for dRNG and > gAMA to interact: When decoding sample values for display, the dRNG > processing must be inserted into the "gamma processing" pipeline AFTER > the step that undoes the gamma encoding of the image file, but BEFORE > any steps that account for the display system gamma. dRNG *must* > do its linear scaling on sample values that are, in fact, linearly > related to scene intensity. I see your point. > This makes implementing dRNG a bit awkward, in that the chunk > specifies minimum and maximum values in the gamma-corrected "sample > value" space, while the actual transformation must be performed on > the linear-intensity intermediate values obtained partway through the > gamma processing stages. In that case, perhaps it would be less confusing if min and max were expressed in the [0.0 .. 1.0] space. Then the procedure for the decoder would be: 1. Use a power function to map the raw samples from [0 .. 2^bitdepth-1] to [0.0 .. 1.0]. Use the reciprocal of the gamma value from the gAMA chunk. (Or, if there is a lOGE chunk, do something else, but get the samples into the [0.0 .. 1.0] linear space somehow.) 2. Use linear scaling and clipping to map samples in the range [min .. max] onto the range [0.0 .. 1.0]. To be precise, out = clip(0.0, (in - min) / (max - min), 1.0). 3. Use a power funtion to map the samples from the range [0.0 .. 1.0] to the range [0 .. 2^bitdepth-1]. Use viewing_gamma / display_gamma as the gamma value. (The bitdepths mentioned in 1 and 3 are not necessarily the same.) Of course, real implementations may optimize this. Multiple dRNG chunks should be allowed, each with a purpose tag, just like fALS. I now see dRNG as providing a very similar function to fALS: suggesting one possible view of the underlying data. Speaking of which, it looks like it should be impossible for a decoder to use a dRNG chunk and a fALS chunk at the same time. The fALS spec says to ignore gAMA, and since dRNG is now inextricably tied up with gAMA, a decoder processing fALS must ignore dRNG as well. Right? Perhaps this should be mentioned explicitly. Note that it's mainly the X-ray and astronomical image examples that are persuading me of the need for this chunk. These are not the motivations supplied in the current dRNG spec. The spec says: > This chunk can be used when the pixel values do not occupy the > full range of possible values, and when bit depth scaling is not > appropriate. I think that should be removed. > It can also be used to enhance contrast by scaling to a larger range > than the actual range of pixel values. That's sort of what I'm thinking of, but it should be more like: This chunk can be used to expand a sub-range of sample values to cover the entire range of displayed intensities. Samples outside the sub-range get clipped to the maximum or minimum displayed intensities. This would be useful, for example, for enhancing the contrast of some features of an X-ray or astronomical image. It's true that dRNG could be used to compress and shift as well as expand, and that becomes apparent when it is stated that min and max can be any real numbers (as long as they're not equal). But there's no point in mentioning that capability in the motivation until we can think of a real-life use for it. > It can be used to correct the brightness of an image that has been > scaled by zero-filling rather than linear scaling. No, please remove that. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 18:26:37 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA15307 for ; Sat, 28 Sep 1996 18:26:36 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA19687 for png-list-outgoing; Sat, 28 Sep 1996 18:26:45 -0500 Received: from dawn11.CS.Berkeley.EDU (dawn11.CS.Berkeley.EDU [128.32.38.55]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA19682 for ; Sat, 28 Sep 1996 18:26:42 -0500 Received: (from amc@localhost) by dawn11.CS.Berkeley.EDU (8.6.11/8.6.9) id QAA12488 for png-list@dworkin.wustl.edu; Sat, 28 Sep 1996 16:26:23 -0700 Date: Sat, 28 Sep 1996 16:26:23 -0700 Message-Id: <199609282326.QAA12488@dawn11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: lOGE X-Advice: should read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In light of Dave M's recent views about lOGE and gAMA, and my latest suggestion regarding dRNG, perhaps two changes should be made to the lOGE spec: 1. State explicitly that lOGE is analogous to gAMA. Whereas gAMA indicates that a power function was used to map the linear input to the stored samples, lOGE indicates that a logarithmic function was used instead. lOGE overrides gAMA. 2. Expect the scaled_sample value to be in the range [0.0 .. 1.0] instead of [0 .. 2^bitdepth-1]. This preserves the analogy to gAMA. When the decoder raises normalized_sample to the power 1/gamma, it expects a value in [0.0 .. 1.0]. The mapping to [0 .. 2^bitdepth-1] is separate, and not gAMA's concern. Looking at it from the encoder's point of view, we would have: linear_sample - P0 log_sample = log --------------------- P2 P1 stored_sample = clip(0, log_sample * (2^bitdepth-1), 1) From the decoder's point of view: log_sample = stored_sample / (2^bitdepth-1) linear_sample = P0 + P1 * P2^log_sample Note that I changed a variable name from scaled_sample to linear_sample. I don't want to think of these as scaling operations, but rather as encoding/decoding operations. I also changed a variable name from normalized_sample to log_sample. In both cases, I think indicating what space we're in provides helpful intuition. It also helps to choose names that work equally well for both the decoder and encoder. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 18:28:17 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA15319 for ; Sat, 28 Sep 1996 18:28:16 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA19708 for png-list-outgoing; Sat, 28 Sep 1996 18:28:30 -0500 Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA19703 for ; Sat, 28 Sep 1996 18:28:27 -0500 Received: from VMS.HUJI.AC.IL (vms.huji.ac.il [128.139.4.12]) by wugate.wustl.edu (8.7.5/8.7.3) with SMTP id SAA21813 for ; Sat, 28 Sep 1996 18:28:44 -0500 Message-Id: <199609282328.SAA21813@wugate.wustl.edu> Received: by HUJIVMS (HUyMail-V7b); Sun, 29 Sep 96 01:28:06 +0200 Received: by HUJIVMS via SMTP(194.90.120.213) (HUyMail-V7b); Sun, 29 Sep 96 01:24:57 +0200 Date: Sun, 29 Sep 96 1:24 +0200 Subject: PNG vs GIF Image sizes (again) From: Jeremy Moskovich To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Hi guys, There are currently 2 Macintosh programs that I know of that can encode PNGs (GraphicConverter and GIFConverter). When trying to create a PNG out of a GIF with EITHER of these programs, the PNG file invariably comes out 2-3 times bigger than the GIF inputted. This is using paeth encoding, no interlacing, 256 colors and level 9 compression. Shouldn't the PNG be smaller than (or at least the same size as) the GIF? What on earth is going on here??? all the best, Jeremy +-=-=-=-=-=-=-= Jeremy Moskovich * jeremy@pixel.co.il =-=-=-=-=-=-=-=+ | Master of Puppets, Pixel Multimedia Tel: +972-3-5377716 ext.209 | | /\___ \ Be, Mac, Linux, The Hunchback of Notre Dame, Rage Against | | \/__/\ \ __ _ __ __ ___ ___ __ __ The Machine, REM, | | _\ \ \ /'__`\/\`'__\/'__`\/' __` __`\/\ \/\ \ Roxette, Wierd Al,| | /\ \_\ \/\ __/\ \ \//\ __//\ \/\ \/\ \ \ \_\ \ Suzanne Vega, | | \ \____/\ \____\\ \_\\ \____\ \_\ \_\ \_\/`____ \ Rice Pilaf, | | \/___/ \/____/ \/_/ \/____/\/_/\/_/\/_/`/___/> \ Mr. Spock, | | C, C++, Perl, Lingo, JavaScript Programmer /\___/ Optimus Prime| | HTML scripter, and all-around good guy... \/__/ http://www.be.com| +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 18:48:04 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA15393 for ; Sat, 28 Sep 1996 18:48:03 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA19855 for png-list-outgoing; Sat, 28 Sep 1996 18:48:19 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id SAA19850 for ; Sat, 28 Sep 1996 18:48:17 -0500 Date: Sat, 28 Sep 96 19:46:31 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: png-list@dworkin.wustl.edu Subject: MNG Seventeenth draft Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609281946.aa17555@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I have uploaded the seventeenth MNG draft to swrinde and mailed the text version to mpng-list. The new BASI and SBYK chunks pertain to the current png-list discussion of the "purpose" field on pCAL, faLT, etc. Also I added an outline for a gif-animation to mng converter. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 19:08:05 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id TAA15452 for ; Sat, 28 Sep 1996 19:08:04 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA20045 for png-list-outgoing; Sat, 28 Sep 1996 19:08:20 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id TAA20028 for ; Sat, 28 Sep 1996 19:08:17 -0500 Date: Sat, 28 Sep 96 20:07:39 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: PNG vs GIF Image sizes (again) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609282007.aa17668@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Sun, 29 Sep 96 1:24 +0200 }Subject: PNG vs GIF Image sizes (again) }From: Jeremy Moskovich }Hi guys, } There are currently 2 Macintosh programs that I know of that can }encode PNGs (GraphicConverter and GIFConverter). When trying to create a }PNG out of a GIF with EITHER of these programs, the PNG file invariably }comes out 2-3 times bigger than the GIF inputted. This is using paeth }encoding, no interlacing, 256 colors and level 9 compression. } Shouldn't the PNG be smaller than (or at least the same size as) the }GIF? } What on earth is going on here??? Maybe they are writing color_type 2 instead of indexed-color. Or if the files are very small, maybe they are writing a 256-entry palette when fewer colors are needed. Point me to a couple of the PNGs (I don't care to see the GIFs, can't read 'em anyway without restoring some software from backups) and I'll investigate. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 21:28:33 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id VAA15830 for ; Sat, 28 Sep 1996 21:28:32 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA21448 for png-list-outgoing; Sat, 28 Sep 1996 21:28:24 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id VAA21441 for ; Sat, 28 Sep 1996 21:28:20 -0500 Date: Sat, 28 Sep 96 22:26:29 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Discussion on dRNG Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609282226.aa18103@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Andreas wrote: }[re the dRNG chunk description] }> Please write an appropriate sentence or two. Then duck. } }How about: } }"This chunk is intended for use when the encoded pixel values do not } reasonably span the full range of possible values as the PNG spec } mandates. It can be used to clip the dynamic range of an image to } a sub-set of the available pixel values, in order to allow the storage } of values which are brighter than what the encoder considers a desirable } "maximum intensity". Similarly, it can be used to enhance or reduce } the contrast and brightness of pixel values that are stored losslessly } and cannot be scaled to fill the full range of possible pixel values. ================ } The chunk defines the minimum and maximum pixel values that correspond } to the minimum and maximum intensity, respectively. } The phrase "cannot be scaled" was in an earlier draft, but some of the purists pointed out [correctly] that there is no such case. "cannot be conveniently scaled" was also unacceptable because it is coddling lazy programmers. We settled on what is in the latest draft on swrinde, i.e. "when it is not appropriate". The last sentence is more accurately stated "The chunk defines the pixel values that correspond to the minimum and maximum intensity." Otherwise, your paragraph looks better than what's in the draft at the moment. I suggest [...] Similarly, it can be used to enhance or reduce the contrast and brightness of pixel values that are stored losslessly and it is not appropriate to rescale them to fill the full range of possible pixel values. The chunk defines the values that correspond to the minimum and maximum intensity. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 21:36:26 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id VAA15889 for ; Sat, 28 Sep 1996 21:36:25 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id VAA21536 for png-list-outgoing; Sat, 28 Sep 1996 21:36:32 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id VAA21531 for ; Sat, 28 Sep 1996 21:36:29 -0500 Date: Sat, 28 Sep 96 22:36:07 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New chunk registration process 19960926 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609282236.aa18186@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List } }> * John Bowler, jbowler@megamed.com } }I prefer jbowler@acm.org - this is the ACM email redirector, thus is more }likely to remain valid. OK, I've fixed that in my master files.. didn't make it into the 17th MNG draft but will be in the next. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 22:06:23 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id WAA16024 for ; Sat, 28 Sep 1996 22:06:20 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id WAA21888 for png-list-outgoing; Sat, 28 Sep 1996 22:06:28 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id WAA21883 for ; Sat, 28 Sep 1996 22:06:25 -0500 Date: Sat, 28 Sep 96 23:05:31 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: VOTE on dRNG Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609282305.aa18348@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List ABSTAIN dRNG ftp://swrinde.nde.swri.edi/pub/png-group/documents/ png-scivis-chunks-19960914 Glenn Randers-Pehrson My purpose in abstaining is to allow further discussion and modification of the proposed dRNG chunk. I'm not sure how this will work, but I believe I have cast the only vote on this issue. (Andreas' YES vote had "Re:" in the subject and therefore doesn't count) ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 22:11:52 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id WAA16052 for ; Sat, 28 Sep 1996 22:11:51 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id WAA22017 for png-list-outgoing; Sat, 28 Sep 1996 22:12:08 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id WAA22011 for ; Sat, 28 Sep 1996 22:12:05 -0500 Date: Sat, 28 Sep 96 23:09:28 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: png-list@dworkin.wustl.edu Subject: Re: VOTE on dRNG Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609282309.aa18369@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I wrote: }(Andreas' YES vote }had "Re:" in the subject and therefore doesn't count) I mean it wouldn't count if we go by the strict formatting rules. Lee, did your automatic ballot box detect his vote? } }../glennrp } ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 22:16:16 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id WAA16068 for ; Sat, 28 Sep 1996 22:16:12 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id WAA22092 for png-list-outgoing; Sat, 28 Sep 1996 22:16:29 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id WAA22087 for ; Sat, 28 Sep 1996 22:16:26 -0500 Date: Sat, 28 Sep 96 23:12:15 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: png-list@dworkin.wustl.edu Subject: Vote on dRNG Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609282312.aa18379@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List ABSTAIN dRNG ftp://swrinde.nde.swri.edi/pub/png-group/documents/ png-scivis-chunks-19960914 Glenn Randers-Pehrson second attempt.... I'll try real hard to remember to get rid of the "Re:" this time... :-( p.s. I nearly hit the "s" key again :-C ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 22:43:15 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id WAA16148 for ; Sat, 28 Sep 1996 22:43:13 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id WAA22279 for png-list-outgoing; Sat, 28 Sep 1996 22:43:21 -0500 Received: from epfl2 (epfl2.epflbalto.org [192.188.199.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id WAA22273 for ; Sat, 28 Sep 1996 22:43:18 -0500 Received: by epfl2 (5.0/SMI-SVR4) id AA19223; Sat, 28 Sep 1996 23:41:27 -0400 Date: Sat, 28 Sep 1996 23:41:27 -0400 (EDT) From: Glenn Randers-Pehrson To: PNG List Subject: Re: Vote on dRNG In-Reply-To: <9609282312.aa18379@THOR.ARL.MIL> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sat, 28 Sep 1996, Glenn Randers-Pehrson ARL-WMRD-TED-TIB wrote: > ABSTAIN > dRNG > ftp://swrinde.nde.swri.edi/pub/png-group/documents/ > png-scivis-chunks-19960914 > Glenn Randers-Pehrson > > second attempt.... I'll try real hard to remember to get rid of > the "Re:" this time... :-( > > p.s. I nearly hit the "s" key again :-C > Ahah. Finally got it right. Should've used PINE; at least pine shows me my headers when I reply. On the arl machine I have to go out of my way to see them, and it's just too easy to hit :wqs Lesson learned is the rejection of votes based on "Re:" is a pretty bad idea. The model with VOTE as the first line of the body was better. -- Glenn Randers-Pehrson | | | ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sat Sep 28 23:19:55 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id XAA16299 for ; Sat, 28 Sep 1996 23:19:53 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA22888 for png-list-outgoing; Sat, 28 Sep 1996 23:19:57 -0500 Received: from mega.megamed.com (megamed.com [199.4.114.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id XAA22882 for ; Sat, 28 Sep 1996 23:19:45 -0500 Received: from coruisk (mega206.megamed.com [199.4.114.206]) by mega.megamed.com (8.7.5/8.7.3) with SMTP id VAA14032 for ; Sat, 28 Sep 1996 21:19:22 -0700 Date: Sat, 28 Sep 1996 21:19:22 -0700 Message-Id: <199609290419.VAA14032@mega.megamed.com> X-Sender: jbowler@megamed.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: PNG List From: John Bowler Subject: Recognizing votes (was: Vote on dRNG) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List At 23:41 28/09/96 -0400, Glenn wrote: >On Sat, 28 Sep 1996, Glenn Randers-Pehrson ARL-WMRD-TED-TIB wrote: > [ABSTAIN of valid vote invalidated by its own subject line, then] >Ahah. Finally got it right. Should've used PINE; at least pine shows >me my headers when I reply. On the arl machine I have to go out >of my way to see them, and it's just too easy to hit :wqs > >Lesson learned is the rejection of votes based on "Re:" is a pretty bad >idea. The model with VOTE as the first line of the body was better. I have to admit the arguments are impressive, on the other hand graphical news readers and, even, emacs, don't suffer from this problem (emacs email mode has the headers embedded in the message, whereas vi(le) invoked from binmail does not show the headers). The advantage to forcing the format of the subject line is that it is very easy to filter and identify the votes - even if you don't want to separate the messages into a separate folder. I just glanced at my (Eudora) inbox window and was able to find the only two valid votes on dRNG within 10 seconds. Equally vi users need only load mbox and type /^Subject: [Vv][Oo][Tt][Ee] (people who don't use vi may not appreciate how easy this is :-) (Note that the second valid vote on dRNG starts with "Vote", not "VOTE" :-) I think the rule should remain as it is (and case insensitive). John Bowler (jbowler@acm.org) ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 01:16:26 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id BAA17596 for ; Sun, 29 Sep 1996 01:16:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id BAA24136 for png-list-outgoing; Sun, 29 Sep 1996 01:14:58 -0500 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id BAA24131 for ; Sun, 29 Sep 1996 01:14:53 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id XAA27973 for ; Sat, 28 Sep 1996 23:13:27 -0700 X-Sender: davem@mail.cs.ubc.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 28 Sep 1996 23:13:29 -0700 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: Re: Discussion on dRNG Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Adam writes: >In that case, perhaps it would be less confusing if min and max were >expressed in the [0.0 .. 1.0] space. Then the procedure for the decoder >would be: > > 1. Use a power function to map the raw samples from [0 .. 2^bitdepth-1] > to [0.0 .. 1.0]. Use the reciprocal of the gamma value from the > gAMA chunk. > > (Or, if there is a lOGE chunk, do something else, but get the samples > into the [0.0 .. 1.0] linear space somehow.) Actually, the intensity may not be bounded at 1.0. One of the reasons for having something like loGE is to allow "headroom". A reasonable convention for loGE would be: the decoding step, using the equations specified in the loGE document and the parameters contained in the loGE chunk, decodes pixel values into non-negative floating point numbers. A value of 0 means black (no intensity), a value of 1.0 is "nominal white" (maps to 255 under default viewing conditions), but values greater than 1.0 are allowed. Then any scaling done by dRNG is performed, and only then are the values clamped to a [0.0..1.0] range. This allows dRNG to map "whiter than white" highlight details, which would normally be clamped, to visible pixel values. In fact, although loGE and gAMA encoding can't store negative numbers, negative numbers are sometimes useful (for out-of-gamut colours). It's conceivable that someone else might define yet another encoding that can store negative numbers, and there is no reason for those values to be clipped during the decoding step. The *only* place clipping is necessary is after dRNG processing and before the final display gamma correction step. So, in the most general case: - decoding of pixel values takes integers and yields floating point numbers of any size and sign - dRNG processing applies a linear transformation to these numbers - the result of the dRNG is clipped to the [0..1] range - output gamma correction and conversion back to integer frame buffer values is done. Of course, all this can be done by a single lookup table. But the processing should be described as happening mostly in floating point. >Multiple dRNG chunks should be allowed, each with a purpose tag, just >like fALS. I now see dRNG as providing a very similar function to fALS: >suggesting one possible view of the underlying data. Yes, I agree with this. Having multiple dRNG chunks does *not* make this into a multiple-image file - there is just one image, with multiple suggested ways of viewing it. Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 02:48:37 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id CAA17979 for ; Sun, 29 Sep 1996 02:48:36 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id CAA24938 for png-list-outgoing; Sun, 29 Sep 1996 02:47:10 -0500 Received: from dawn11.CS.Berkeley.EDU (dawn11.CS.Berkeley.EDU [128.32.38.55]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id CAA24932 for ; Sun, 29 Sep 1996 02:47:06 -0500 Received: (from amc@localhost) by dawn11.CS.Berkeley.EDU (8.6.11/8.6.9) id AAA13123 for png-list@dworkin.wustl.edu; Sun, 29 Sep 1996 00:46:40 -0700 Date: Sun, 29 Sep 1996 00:46:40 -0700 Message-Id: <199609290746.AAA13123@dawn11.CS.Berkeley.EDU> To: png-list@dworkin.wustl.edu Subject: Re: Discussion on dRNG X-Advice: perhaps read whenever From: amc@cs.berkeley.edu (Adam M. Costello) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List davem@cs.ubc.ca (Dave Martindale) says: > Actually, the intensity may not be bounded at 1.0. Right. I didn't mean to preclude values outside [0.0 .. 1.0] from what I called the [0.0 .. 1.0] space. I just called it that to indicate that 0.0 was black and 1.0 was the nominal white (or full red, etc.). Maybe there should be a name for this space. Anyway, I agree with the entire message. AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 05:46:29 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id FAA19724 for ; Sun, 29 Sep 1996 05:46:29 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA26240 for png-list-outgoing; Sun, 29 Sep 1996 05:46:32 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id FAA26235 for ; Sun, 29 Sep 1996 05:46:29 -0500 Date: Sun, 29 Sep 96 6:45:48 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: PNG vs GIF Image sizes (again) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609290645.aa20512@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Date: Sun, 29 Sep 96 1:24 +0200 }Subject: PNG vs GIF Image sizes (again) }From: Jeremy Moskovich }Hi guys, } There are currently 2 Macintosh programs that I know of that can }encode PNGs (GraphicConverter and GIFConverter). When trying to create a }PNG out of a GIF with EITHER of these programs, the PNG file invariably }comes out 2-3 times bigger than the GIF inputted. This is using paeth }encoding, no interlacing, 256 colors and level 9 compression. } Shouldn't the PNG be smaller than (or at least the same size as) the }GIF? } What on earth is going on here??? }all the best, }Jeremy Don't use Paeth filtering when there are 256 or fewer colors. The "none" filter is almost always more effective and frequently significantly more effective. That still doesn't explain 2-3 times bigger, though, but it might explain the first 30-50 percent increase. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 05:51:53 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id FAA19739 for ; Sun, 29 Sep 1996 05:51:52 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA26285 for png-list-outgoing; Sun, 29 Sep 1996 05:52:11 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id FAA26279 for ; Sun, 29 Sep 1996 05:52:08 -0500 Date: Sun, 29 Sep 96 6:50:01 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: Recognizing votes (was: Vote on dRNG) Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609290650.aa20528@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List } }(Note that the second valid vote on dRNG starts with "Vote", not "VOTE" :-) Could've been a lot worse. I was pretty well fed up by then. }I think the rule should remain as it is (and case insensitive). I don't. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 06:27:25 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id GAA19832 for ; Sun, 29 Sep 1996 06:27:24 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id GAA26540 for png-list-outgoing; Sun, 29 Sep 1996 06:26:35 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id GAA26535 for ; Sun, 29 Sep 1996 06:26:32 -0500 Date: Sun, 29 Sep 96 7:24:48 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: New chunk registration procedure 199609245 Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609290724.aa20589@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List In reply to the message }Subject: Re: New chunk registration procedure 199609245 }Date: Fri, 27 Sep 1996 10:38:14 -0400 }Message-ID: <24599.843835094@sss.pgh.pa.us> }From: Tom Lane }Glenn sez: }> I believe we do have consensus, though, on the major parts of the concept: }> - 180 days since first submission for voter eligibility }> [in mpng-list I will suggest a shorter time like 90 days }> because the list hasn't been around so long] }> - 2-week discussion period }> - 2-week voting period }> - votes submitted publicly to png-list }> - [at least] 10 votes to approve Based on the test vote, I suggest at least 5 NO votes to formally reject. Otherwise, a chunk gets banished with nobody explaining why. The two requirements (10 YES to approve, 5 NO to reject) can be replaced with a single requirement (a quorum of 15 voters--or 12, or whatever we think we can muster). That leaves the question of what to do when the quorum fails; I would suggest extending the voting period 1 week at a time until we get one. }> - 2:1 YES:NO required to approve }> - rejected chunks not to be re-voted unless external conditions }> change, the proposal changes, or sufficent time [180 days?] }> has elapsed. }> The rest is formality and perhaps unnecessary. } }Y'know, I like this specification a whole lot better than the more }formal one. If we left it just like this, we might discourage people }from applying legalistic nitpicking skills. } } regards, tom lane } }------------------------------------------------------------ }To find out more about the mailing list server, send mail to }png-list-request@dworkin.wustl.edu }with the word "help" (and nothing else) in the message body. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 07:45:47 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id HAA20026 for ; Sun, 29 Sep 1996 07:45:46 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA27052 for png-list-outgoing; Sun, 29 Sep 1996 07:44:57 -0500 Received: from epfl2 (epfl2.epflbalto.org [192.188.199.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id HAA27047 for ; Sun, 29 Sep 1996 07:44:53 -0500 Received: by epfl2 (5.0/SMI-SVR4) id AA24965; Sun, 29 Sep 1996 08:43:00 -0400 Date: Sun, 29 Sep 1996 08:42:59 -0400 (EDT) From: Glenn Randers-Pehrson To: PNG List Subject: VOTE on dRNG In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List ABSTAIN dRNG ftp://swrinde.nde.swri.edi/pub/png-group/documents/ png-scivis-chunks-19960914 Glenn Randers-Pehrson using PINE this time. ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 08:08:44 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id IAA20077 for ; Sun, 29 Sep 1996 08:08:44 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA27211 for png-list-outgoing; Sun, 29 Sep 1996 08:07:36 -0500 Received: from epfl2 (epfl2.epflbalto.org [192.188.199.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA27206 for ; Sun, 29 Sep 1996 08:07:33 -0500 Received: by epfl2 (5.0/SMI-SVR4) id AA25396; Sun, 29 Sep 1996 09:05:39 -0400 Date: Sun, 29 Sep 1996 09:05:39 -0400 (EDT) From: Glenn Randers-Pehrson To: PNG List Subject: Re: VOTE on dRNG In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Jeremy's message indicates that the authors of some apps may be misinterpreting section 9.6 of the PNG spec. Where it says "For images of color type 3 (indexed color), filter type 0 (none) is usually the most effective" and where it later recommends the Paeth filter for truecolor images, they seem to have interpreted this to mean that they should use truecolor with Paeth when converting 256-color GIFs. The first paragraph of section 9.6 should probably really read For color images with 256 or fewer colors, filter type 0 (none) is almost always the most effective, regardless of whether the image is stored as truecolor or as indexed color. Storing them as indexed color usually results in the smallest files. (if we happen to update the spec) -- Glenn Randers-Pehrson | | for a PNG image of the first PNG grandchild, see | ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 08:14:21 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id IAA20107 for ; Sun, 29 Sep 1996 08:14:20 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA27271 for png-list-outgoing; Sun, 29 Sep 1996 08:14:39 -0500 Received: from epfl2 (epfl2.epflbalto.org [192.188.199.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA27266 for ; Sun, 29 Sep 1996 08:14:36 -0500 Received: by epfl2 (5.0/SMI-SVR4) id AA25573; Sun, 29 Sep 1996 09:12:43 -0400 Date: Sun, 29 Sep 1996 09:12:40 -0400 (EDT) From: Glenn Randers-Pehrson To: png-list@dworkin.wustl.edu Subject: Filter selection In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Jeremy's message indicates that the authors of some apps may be misinterpreting section 9.6 of the PNG spec. Where it says "For images of color type 3 (indexed color), filter type 0 (none) is usually the most effective" and where it later recommends the Paeth filter for truecolor images, they seem to have interpreted this to mean that they should use truecolor with Paeth when converting 256-color GIFs. The first paragraph of section 9.6 should probably really read For color images with 256 or fewer colors, filter type 0 (none) is almost always the most effective, regardless of whether the image is stored as truecolor or as indexed color. Storing them as indexed color usually results in the smallest files. (if we happen to update the spec) -- Glenn Randers-Pehrson | | for a PNG image of the first PNG grandchild, see | ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 08:16:30 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id IAA20118 for ; Sun, 29 Sep 1996 08:16:29 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA27333 for png-list-outgoing; Sun, 29 Sep 1996 08:16:45 -0500 Received: from epfl2 (epfl2.epflbalto.org [192.188.199.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA27328 for ; Sun, 29 Sep 1996 08:16:42 -0500 Received: by epfl2 (5.0/SMI-SVR4) id AA25624; Sun, 29 Sep 1996 09:14:48 -0400 Date: Sun, 29 Sep 1996 09:14:48 -0400 (EDT) From: Glenn Randers-Pehrson To: PNG List Subject: Re: VOTE on dRNG In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sun, 29 Sep 1996, Glenn Randers-Pehrson wrote: [about filter selection] Wrong subject line. Some people will just never learn. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 08:54:22 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id IAA20220 for ; Sun, 29 Sep 1996 08:54:19 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA27548 for png-list-outgoing; Sun, 29 Sep 1996 08:52:21 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA27543 for ; Sun, 29 Sep 1996 08:52:17 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id PAA15882 for png-list@dworkin.wustl.edu; Sun, 29 Sep 1996 15:52:00 +0200 (DST) Date: Sun, 29 Sep 1996 15:52:00 +0200 (DST) From: Chris Lilley Message-Id: <9609291552.ZM15880@grommit.inria.fr> In-Reply-To: adilger@enel.ucalgary.ca (Andreas Dilger) "Re: Discussion on dRNG" (Sep 27, 5:11pm) References: <199609272311.RAA07777@enel.ucalgary.ca> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: Discussion on dRNG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 27, 5:11pm, Andreas Dilger wrote: > I can't remember which other renderer does this (I suspect Radiance), Yes > but > it stores the output in a proprietary 32-bit floating-point output format, > and comes with its own viewer and conversion tools, Yes, you can increase and decrease exposure setting by halp f-stops while viewing the picture. > but I would rather use PNG. I would rather use PNG for the selected output exposure. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 09:12:16 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id JAA20277 for ; Sun, 29 Sep 1996 09:12:15 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA27666 for png-list-outgoing; Sun, 29 Sep 1996 09:10:51 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA27661 for ; Sun, 29 Sep 1996 09:10:47 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id QAA16025; Sun, 29 Sep 1996 16:10:30 +0200 (DST) Date: Sun, 29 Sep 1996 16:10:30 +0200 (DST) From: Chris Lilley Message-Id: <9609291610.ZM16023@grommit.inria.fr> In-Reply-To: amc@cs.berkeley.edu (Adam M. Costello) "Re: "Component bit depth"" (Sep 27, 9:57pm) References: <199609280457.VAA11341@dawn13.CS.Berkeley.EDU> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: "Component bit depth" Cc: chris@w3.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 27, 9:57pm, Adam M. Costello wrote: > PNG is going to be both an RFC and a W3C Recommendation. Yes, though the latter information is not public. Good guess, though. > Can someone > assure me that, except for meta-content (like the intro at the very > beginning), the two will be word-for-word identical? Yes. > If this bit-depth edit sacrifices consistency, then I say forget it. The same edits will be made to both documents. Or rather, an edit will be made to the master document that a program processes to generate them both, thus ensuring complete lockstep consistency. There are a couple of minor editorial issues, like capitalisation of headers and the lack of a heading in section 12, which have been brought to W3C's attention during the course of the review, and these should be dealt with at the same time. I am working on this as we speak. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 09:35:20 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id JAA20345 for ; Sun, 29 Sep 1996 09:35:19 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA27860 for png-list-outgoing; Sun, 29 Sep 1996 09:35:32 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA27854 for ; Sun, 29 Sep 1996 09:35:28 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id QAA16050 for png-list@dworkin.wustl.edu; Sun, 29 Sep 1996 16:35:10 +0200 (DST) Date: Sun, 29 Sep 1996 16:35:10 +0200 (DST) From: Chris Lilley Message-Id: <9609291635.ZM16048@grommit.inria.fr> In-Reply-To: davem@cs.ubc.ca (Dave Martindale) "Re: Discussion on dRNG" (Sep 28, 11:13pm) References: X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: PNG List Subject: Re: Discussion on dRNG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 28, 11:13pm, Dave Martindale wrote: > Adam writes: > > (Or, if there is a lOGE chunk, do something else, but get the samples > > into the [0.0 .. 1.0] linear space somehow.) > Actually, the intensity may not be bounded at 1.0. One of the reasons > for having something like loGE is to allow "headroom". [...] > A value of 0 means black (no intensity), a value of 1.0 is "nominal white" > (maps to 255 under default viewing conditions), but values greater than > 1.0 are allowed. OK I managed to avoid getting sucked into this thread so far but here goes... So, values greater than 1.0 are desirable for headroom; on a greyscale image it is difficult to see why values less than0.0 would be required if 0..1 is a linear scale. For color images, values greater than 1.0 and less than 0.0 are desirable, as this is the only way to encode colors that fall outside the gamut of the source device (but may not be outside the gamut of some display device). The gamut of hexachrome printing, for example, has areas outside the gamut of 709 RGB. > In fact, although loGE and gAMA encoding can't store negative numbers, > negative numbers are sometimes useful (for out-of-gamut colours). It's > conceivable that someone else might define yet another encoding that > can store negative numbers, and there is no reason for those values to > be clipped during the decoding step. The *only* place clipping is > necessary is after dRNG processing and before the final display gamma > correction step. Right. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 09:42:09 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id JAA20378 for ; Sun, 29 Sep 1996 09:42:06 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA27898 for png-list-outgoing; Sun, 29 Sep 1996 09:42:13 -0500 Received: from grommit.inria.fr (grommit.inria.fr [138.96.48.84]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA27893 for ; Sun, 29 Sep 1996 09:42:08 -0500 Received: by grommit.inria.fr (8.7.6/8.6.12) id QAA16054; Sun, 29 Sep 1996 16:41:47 +0200 (DST) Date: Sun, 29 Sep 1996 16:41:47 +0200 (DST) From: Chris Lilley Message-Id: <9609291641.ZM16052@grommit.inria.fr> In-Reply-To: Jeremy Moskovich "PNG vs GIF Image sizes (again)" (Sep 29, 1:24am) References: <199609282328.SAA21813@wugate.wustl.edu> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: jeremy@vms.huji.ac.il, PNG List Subject: Re: PNG vs GIF Image sizes (again) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sep 29, 1:24am, Jeremy Moskovich wrote: > There are currently 2 Macintosh programs that I know of that can > encode PNGs (GraphicConverter and GIFConverter). When trying to create a > PNG out of a GIF with EITHER of these programs, the PNG file invariably > comes out 2-3 times bigger than the GIF inputted. Invariably, meaning in all cases and with more than one or two test files? In that case, something is very wierd with those programs. I have occasionally seen very small (200-800 byte) 1 bit GIFs which were smaller than the corresponding PNG by 40 bytes or so. I have never, ever, seen a PNG whichg was three times the size of the GIF that produced it; yet you are seeing this all the time? Please set up a directory on the Web or an FTP site containing a selection of GIFs and the corresponding PNG files created by those programs (please indicate which program was used for which file, in a readme or something). Then we can take a look at those files. -- Chris Lilley, W3C [ http://www.w3.org/ ] Graphics and Fonts Guy The World Wide Web Consortium http://www.w3.org/people/chris/ INRIA, Projet W3C chris@w3.org 2004 Rt des Lucioles / BP 93 +33 93 65 79 87 06902 Sophia Antipolis Cedex, France ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 09:46:46 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id JAA20407 for ; Sun, 29 Sep 1996 09:46:46 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA27971 for png-list-outgoing; Sun, 29 Sep 1996 09:47:04 -0500 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA27966 for ; Sun, 29 Sep 1996 09:47:00 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id HAA24367 for ; Sun, 29 Sep 1996 07:46:33 -0700 X-Sender: davem@mail.cs.ubc.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 29 Sep 1996 07:46:35 -0700 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: non-vote Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List If I *really* wanted to be picky, I could argue that all of the votes submitted so far have been invalid because they point to a non-existent file for their specification (which I found out when I tried to fetch it). The call for votes, and the votes themselves, all refer to >ftp://swrinde.nde.swri.edi/pub/png-group/documents/ >png-scivis-chunks-19960914 but the site is in the .edu domain, not .edi. How's that for legalistic? But realistically, I think we need to clarify issues of how dRNG interacts with gAMA, revise the description, and restart the voting. Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 10:18:15 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id KAA20489 for ; Sun, 29 Sep 1996 10:18:11 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA28248 for png-list-outgoing; Sun, 29 Sep 1996 10:18:27 -0500 Received: from enteract.com (enteract.com [206.54.252.1]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA28243 for ; Sun, 29 Sep 1996 10:18:24 -0500 Received: from localhost (kam@localhost) by enteract.com (8.8.Beta.6/8.7.6) with SMTP id KAA06365; Sun, 29 Sep 1996 10:18:00 -0500 (CDT) Date: Sun, 29 Sep 1996 10:17:59 -0500 (CDT) From: "Kevin A. Mitchell" X-Sender: kam@enteract.com To: PNG List cc: jeremy@vms.huji.ac.il Subject: Re: PNG vs GIF Image sizes (again) In-Reply-To: <9609291641.ZM16052@grommit.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List I was able to duplicate the problem in GIFConverter. It had nothing to do with the libpng code; GIFConverter had its wires crossed at a higher level and was saving a 24-bit full color image when the user had requested an 8-bit image. It was one of those really stupid code-editing mistakes, and none of my early testers caught it. Once fixed, a representative 256-color GIF saved at approximately the same size in PNG (it was a few bytes bigger). Jeremy reported it to me last night (thanks!), and it's already fixed in the sources for GIFConverter. It'll be fixed in the 2.4d18 release, which should be out in the next few days. Those wishing notification, please send mail with any content to gc-notify@kamit.com, where it'll be warped into a subscribe request for gifconverter-announce, a low-volume moderated list with only release information. I welcome the scrutiny. I work nearly full-time on GIFConverter now, and plan frequent releases as I add features and shake out bugs. I also plan to give a timely response to bug reports of this nature. Incidentally, there are two things I have on my list for PNG and comments are welcome: 1) Adding comments: I have some translation tables for ISO 8859-1 to and from Macintosh. Since GIFConverter only has user interface and internal representation for a monolithic comment, I plan to aggregate comments with keywords on read, and output a single Comment: comment when writing. I do plan to enhance the internal representation once I can hook up a decent user interface, hopefully something like the way Eudora handles mail headers. 2) Gamma: My goal is to have GIFConverter carry around gamma values on images internally, only modify the actual data when necessary: either when writing to the screen, or when saving to a format that assumes a fixed gamma. Accurate display of PNG files will come when I get the correct-on-the-fly-while-drawing code written. Completing support in these two areas is a relatively high priority. -- Kevin A. Mitchell, kam@kamit.com Personal: http://www.kamit.com/ GIFConverter: gifconverter@kamit.com or kam@kagi.com http://www.kamit.com/gifconverter.html ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 10:40:49 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id KAA20555 for ; Sun, 29 Sep 1996 10:40:46 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA28477 for png-list-outgoing; Sun, 29 Sep 1996 10:41:03 -0500 Received: from mail.Clark.Net (mail.clark.net [168.143.0.10]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA28472 for ; Sun, 29 Sep 1996 10:41:00 -0500 Received: from glenc (glenc.clark.net [168.143.4.56]) by mail.Clark.Net (8.7.3/8.6.5) with SMTP id LAA22199 for ; Sun, 29 Sep 1996 11:40:35 -0400 (EDT) Message-Id: <199609291540.LAA22199@mail.Clark.Net> Comments: Authenticated sender is From: "Glen Chapman" To: png-list@dworkin.wustl.edu Date: Sun, 29 Sep 1996 11:44:52 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Filter selection Priority: normal X-mailer: Pegasus Mail for Win32 (v2.42) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > > Jeremy's message indicates that the authors of some apps may be > misinterpreting section 9.6 of the PNG spec. I've seen several converters that allow the user to (optionally) pick the filter used. Used with care this can work well for 1 bitters and 8 bitters. Hopefully Jeremy can point us at the problem images. BTW: I'm close to having a breadboard working for PNG optimize, hopefully I'll figure out the state save stuff in zlib later today. glen ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 11:51:22 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id LAA20746 for ; Sun, 29 Sep 1996 11:51:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA29255 for png-list-outgoing; Sun, 29 Sep 1996 11:51:26 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA29249 for ; Sun, 29 Sep 1996 11:51:21 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id MAA00843 for ; Sun, 29 Sep 1996 12:50:56 -0400 (EDT) To: PNG List Subject: Re: "Component bit depth" In-reply-to: Your message of Sun, 29 Sep 1996 16:10:30 +0200 (DST) <9609291610.ZM16023@grommit.inria.fr> Date: Sun, 29 Sep 1996 12:50:55 -0400 Message-ID: <840.844015855@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List After searching the archives a little bit, it looks like the previous discussion of terminology was untimely cut off by the failure of the old list reflector at godzilli. The last thing I can find is a message from Glenn, excerpted below. So maybe we could have resolved the disagreement, but forgot to. There were two distinct issues; one was the naming of color channels and elements of a pixel ("sample", "channel", and "component"). I believe most of this has been adequately dealt with in later drafts. We never did deal with the fact that a "sample" in an indexed-color image isn't the same kind of animal as a "sample" in other color types. Some wanted to choose another word that would encompass both "sample" and "palette index", and use "sample" only for "color intensity value". I thought this was overly pedantic, mainly because none of the proposed replacements rolled trippingly off the tongue, and doing s/sample/multi word phrase/gi would've done severe damage to the readability of the spec. I'd just as soon leave well enough alone on that point. The other issue was names for bit depth and related concepts. I didn't like the "bits per field" and related names that Glenn proposes below, because they seemed too wordy. What I'd suggest is bit depth: bits per numeric value in the image data; the value given in IHDR. sample depth: precision of color samples. This is 8 in an indexed- color PNG and otherwise the same as the bit depth. original sample depth: the number given in sBIT. A quick pass through the spec to make this distinction consistent and to add appropriate glossary entries wouldn't take long. Actually, it looks like the spec does already use these terms in the places where it's critical; the sBIT discussion is the only place I found that would need many changes. Glenn seems to think that we could still squeeze in such a change without losing our place in the RFC queue. So if people are sufficiently concerned (I'm not, really) then let's get it done. regards, tom lane --------------- Date: Tue, 4 Jul 95 2:00:29 GMT From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: png-list@godzilli.cs.sunysb.edu Subject: Re: Charles Poynton's comments [ irrelevant material snipped by tgl ] Charles Poynton wrote: >Sample vs Pixel >I suggest that the definition be made that a truecolor pixel comprises >three "samples". In the 10th draft, we have been using "sample", "channel", and "component" indiscriminately. I prefer "component", which might confuse fewer people, but would go along with "sample". >It seems to me that the depth of a bit is one. I suggest that the term >"bits per sample" replace "bit depth". This also makes it clear that it's >per sample (component), not per pixel. OK. But some places we're talking about the bits per field in the data stream. So maybe we need "bits per field" (the number found in the IHDR chunk) and bits per component/sample/channel (which is the same as bits per field except for colormapped pixels, which have 8 bits per component regardless of the number of bits per field). ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 12:03:10 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id MAA20810 for ; Sun, 29 Sep 1996 12:03:09 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA29378 for png-list-outgoing; Sun, 29 Sep 1996 12:03:24 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA29370 for ; Sun, 29 Sep 1996 12:03:20 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id NAA00874; Sun, 29 Sep 1996 13:02:54 -0400 (EDT) To: PNG List cc: jeremy@vms.huji.ac.il Subject: Re: PNG vs GIF Image sizes (again) In-reply-to: Your message of Sun, 29 Sep 1996 10:17:59 -0500 (CDT) Date: Sun, 29 Sep 1996 13:02:54 -0400 Message-ID: <872.844016574@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List "Kevin A. Mitchell" writes: > I was able to duplicate the problem in GIFConverter. It had nothing to do > with the libpng code; GIFConverter had its wires crossed at a higher level > and was saving a 24-bit full color image when the user had requested > an 8-bit image. Jeremy's results suggest that the author of GraphicConverter made the same mistake. Would someone notify him too? regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 12:21:59 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id MAA20905 for ; Sun, 29 Sep 1996 12:21:58 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA29615 for png-list-outgoing; Sun, 29 Sep 1996 12:21:55 -0500 Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA29610 for ; Sun, 29 Sep 1996 12:21:50 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.7.5/8.7.3) with ESMTP id NAA00908 for ; Sun, 29 Sep 1996 13:21:26 -0400 (EDT) To: PNG List Subject: Re: New chunk registration procedure 199609245 In-reply-to: Your message of Sun, 29 Sep 96 7:24:48 EDT <9609290724.aa20589@THOR.ARL.MIL> Date: Sun, 29 Sep 1996 13:21:25 -0400 Message-ID: <906.844017685@sss.pgh.pa.us> From: Tom Lane Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List Glenn writes: > Based on the test vote, I suggest at least 5 NO votes to formally reject. > Otherwise, a chunk gets banished with nobody explaining why. The two > requirements (10 YES to approve, 5 NO to reject) can be replaced > with a single requirement (a quorum of 15 voters--or 12, or whatever we > think we can muster). This isn't well phrased. If I read this literally, a 10:0 YES vote would not pass because we didn't have a quorum. Clearly, not having enough interest to get 10 people to pay attention and vote YES could be a problem. I think that's the real issue behind the concern several have expressed that 10 YES is too high a threshold. And so it may be --- since we have not yet run even one real vote to completion, we have no idea how many people will normally take the time to participate. > That leaves the question of what to do when the > quorum fails; I would suggest extending the voting period 1 week at a time > until we get one. If getting enough people to pay attention is indeed a problem, this approach will make it worse --- we will have votes dragging on indefinitely until 15 voters can be found. The point of a voting proposal was to ensure closure of the debate one way or another within a reasonably short amount of time. If a chunk fails for lack of interest, that's too bad; but I feel strongly that it should *fail* for lack of interest, not *pass* for lack of it. Glenn's proposal seems to imply that a chunk will pass if fewer than 5 people can be found to vote NO. I don't think that's a wise default. In short: I think the previous rules are fine; at least, we don't have enough experience to conclude that they aren't. A test vote that only a couple of people have so far taken seriously doesn't prove anything. regards, tom lane ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 17:39:53 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id RAA22485 for ; Sun, 29 Sep 1996 17:39:52 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA03154 for png-list-outgoing; Sun, 29 Sep 1996 17:39:12 -0500 Received: from epfl2 (epfl2.epflbalto.org [192.188.199.6]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id RAA03149 for ; Sun, 29 Sep 1996 17:39:08 -0500 Received: by epfl2 (5.0/SMI-SVR4) id AA07888; Sun, 29 Sep 1996 18:37:12 -0400 Date: Sun, 29 Sep 1996 18:37:12 -0400 (EDT) From: Glenn Randers-Pehrson To: PNG List Subject: Re: New chunk registration procedure 199609245 In-Reply-To: <906.844017685@sss.pgh.pa.us> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List On Sun, 29 Sep 1996, Tom Lane wrote: > Glenn writes: > > Based on the test vote, I suggest at least 5 NO votes to formally reject. > > Otherwise, a chunk gets banished with nobody explaining why. The two > > requirements (10 YES to approve, 5 NO to reject) can be replaced > > with a single requirement (a quorum of 15 voters--or 12, or whatever we > > think we can muster). > > This isn't well phrased. If I read this literally, a 10:0 YES vote would > not pass because we didn't have a quorum. Yes, I realized that; you'd need a 15-0 vote if there were no NO (or ABSTAIN?) votes (dRNG passes with 1 YES, 0 NO, and 14 ABSTAIN.....). > > If getting enough people to pay attention is indeed a problem, this > approach will make it worse --- we will have votes dragging on > indefinitely until 15 voters can be found. The point of a voting proposal > was to ensure closure of the debate one way or another within a reasonably > short amount of time. That is true. But a call for votes that results in an insufficient number of YES votes and no NO votes isn't really closure, either. > > If a chunk fails for lack of interest, that's too bad; but I feel strongly > that it should *fail* for lack of interest, not *pass* for lack of it. > Glenn's proposal seems to imply that a chunk will pass if fewer than 5 > people can be found to vote NO. I don't think that's a wise default. I said nothing of the sort. I am distinguishing between "rejected" and "failed to pass due to failure to achieve a quorum". A "rejected" chunk is subject to the proscriptions against bringing up a revote. If we were to change the rules to use the quorum, that ought to draw some NO votes out of the woodwork. > > In short: I think the previous rules are fine; at least, we don't have > enough experience to conclude that they aren't. A test vote that only > a couple of people have so far taken seriously doesn't prove anything. Well, it proved that some people have a hard time following the rigid formatting rules. Andreas never got it right; it took me several tries, and, as Dave M. pointed out, the notation "draft-spec-root" is not a true representation of "draft-spec-root.txt". ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 18:08:51 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id SAA22651 for ; Sun, 29 Sep 1996 18:08:50 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA03442 for png-list-outgoing; Sun, 29 Sep 1996 18:09:02 -0500 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id SAA03437 for ; Sun, 29 Sep 1996 18:09:00 -0500 Date: Sun, 29 Sep 96 19:08:30 EDT From: Glenn Randers-Pehrson ARL-WMRD-TED-TIB To: PNG List Subject: Re: "Component bit depth" Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9609291908.aa22682@THOR.ARL.MIL> Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List } }There are a couple of minor editorial issues, like capitalisation of }headers and the lack of a heading in section 12, which have been brought }to W3C's attention during the course of the review, and these should be }dealt with at the same time. } }I am working on this as we speak. Are you changing the capitals in section 4, or changing the lowercase letters in the other sections? I would prefer to change section 4, as in 4.1 Critical chunks 4.1.1 IHDR Image header And leave all other sections, including section 6, alone 6.1 Filter type 0: None ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Sun Sep 29 23:12:26 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id XAA24966 for ; Sun, 29 Sep 1996 23:12:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA06436 for png-list-outgoing; Sun, 29 Sep 1996 23:12:25 -0500 Received: from grolsch.cs.ubc.ca (grolsch.cs.ubc.ca [142.103.6.9]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id XAA06430 for ; Sun, 29 Sep 1996 23:12:18 -0500 Received: from [198.162.38.159] (davem.home.cs.ubc.ca [198.162.38.159]) by grolsch.cs.ubc.ca (8.6.12/8.6.9) with SMTP id VAA09872 for ; Sun, 29 Sep 1996 21:11:39 -0700 X-Sender: davem@mail.cs.ubc.ca Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 29 Sep 1996 21:11:40 -0700 To: PNG List From: davem@cs.ubc.ca (Dave Martindale) Subject: Re: PNG vs GIF Image sizes (again) Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List You wrote: >2) Gamma: My goal is to have GIFConverter carry around gamma values >on images internally, only modify the actual data when necessary: either >when writing to the screen, or when saving to a format that assumes a >fixed gamma. Accurate display of PNG files will come when I get the >correct-on-the-fly-while-drawing code written. If you have any questions about the gamma-handling stuff, feel free to ask me. I wrote most of the gamma-related pseudocode in the spec, and the "what is gamma" tutorial in the appendix. Not only that, but I have a couple of Macs, so I want a PNG-handling program that handles gamma correctly for my own use! Dave ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-png-list@dworkin.wustl.edu Mon Sep 30 15:40:07 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.6/8.7.3) with SMTP id PAA04328 for ; Mon, 30 Sep 1996 15:40:06 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA19817 for png-list-outgoing; Mon, 30 Sep 1996 15:39:39 -0500 Received: from mail.calweb.com (mail.calweb.com [165.90.138.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA19808 for ; Mon, 30 Sep 1996 15:39:34 -0500 Received: from web1.calweb.com (root@web1.calweb.com [165.90.138.10]) by mail.calweb.com (8.7.6/8.7.3) with ESMTP id NAA04087 for ; Mon, 30 Sep 1996 13:31:23 -0700 (PDT) Received: (from lcrocker@localhost) by web1.calweb.com (8.7.6/8.7.3) id NAA23438 for png-list@dworkin.wustl.edu; Mon, 30 Sep 1996 13:31:22 -0700 (PDT) Message-Id: <199609302031.NAA23438@web1.calweb.com> Subject: Re: VOTE on dRNG To: png-list@dworkin.wustl.edu Date: Mon, 30 Sep 1996 13:31:22 -0700 (PDT) From: "Lee Daniel Crocker" In-Reply-To: <9609282309.aa18369@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WMRD-TED-TIB" at Sep 28, 96 11:09:28 pm Organization: Piclab (http://www.piclab.com/) X-Mailer: ELM [version 2.4 PL25 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-png-list@dworkin.wustl.edu Precedence: bulk Reply-To: PNG List > I mean it wouldn't count if we go by the strict formatting rules. Lee, > did your automatic ballot box detect his vote? Yes, and several other non-votes. Next try... (This isn't Ford; in the software biz, quality is job 1.01a). ------------------------------------------------------------ To find out more about the mailing list server, send mail to png-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body.