From owner-mpng-list@dworkin.wustl.edu Wed Jul 1 18:04:31 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id SAA10417 for ; Wed, 1 Jul 1998 18:04:30 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA25946 for mpng-list-outgoing; Wed, 1 Jul 1998 18:07:51 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA25941 for ; Wed, 1 Jul 1998 18:07:48 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id TAA29618; Wed, 1 Jul 1998 19:02:34 -0400 Message-Id: <1.5.4.32.19980701225844.0092c418@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 01 Jul 1998 18:58:44 -0400 To: mpng-list@dworkin.wustl.edu From: Glenn Randers-Pehrson Subject: MNG Draft 43 (19980630) Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List I have uploaded MNG Draft 43 in the usual formats. There's little difference from Draft 42 (19971230). Fixed a few typos, added another optional index entry to the SAVE chunk, added a reference to the W3C SMIL recommendation. ftp://swrinde.nde.swri.edu/pub/mng/documents draft-mng-19980630.txt.gz draft-mng-19980630.html draft-mng-19980630.ps.gz There are no changes that would invalidate any of the existing sample files. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Wed Jul 1 19:43:02 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id TAA10885 for ; Wed, 1 Jul 1998 19:42:56 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA26922 for mpng-list-outgoing; Wed, 1 Jul 1998 19:47:47 -0500 Received: from email7.starnetinc.com (email7.starnetinc.com [204.178.185.113]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA26917 for ; Wed, 1 Jul 1998 19:47:43 -0500 Received: from ravicomp.net (02-095.001.popsite.net [207.227.180.95]) by email7.starnetinc.com (8.8.8/8.8.2) with SMTP id AAA07323 for ; Thu, 2 Jul 1998 00:42:30 GMT Message-ID: <359AD5E4.1A50@starnetinc.com> Date: Wed, 01 Jul 1998 19:35:48 -0500 From: rsingh Organization: owner X-Mailer: Mozilla 3.0Gold (Win95; U) MIME-Version: 1.0 To: MPNG List Subject: Re: MNG Draft 43 (19980630) References: <1.5.4.32.19980701225844.0092c418@netgsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Glenn, Just a note so you don't think no one is listening. I am working on MNG, I am write now learning and reading and researching the basics of PNG so I understand MNG in full context. RS > > I have uploaded MNG Draft 43 in the usual formats. There's > little difference from Draft 42 (19971230). Fixed a few > typos, added another optional index entry to the SAVE chunk, > added a reference to the W3C SMIL recommendation. > > ftp://swrinde.nde.swri.edu/pub/mng/documents > draft-mng-19980630.txt.gz > draft-mng-19980630.html > draft-mng-19980630.ps.gz > > There are no changes that would invalidate any of the existing > sample files. > > Glenn > > -- > Send the message body "help" to mpng-list-request@dworkin.wustl.edu -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Thu Jul 2 08:14:42 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id IAA14900 for ; Thu, 2 Jul 1998 08:14:37 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA03897 for mpng-list-outgoing; Thu, 2 Jul 1998 08:19:23 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id IAA03892 for ; Thu, 2 Jul 1998 08:19:19 -0500 Received: (qmail 25126 invoked from network); 2 Jul 1998 13:13:09 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 2 Jul 1998 13:13:09 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id GAA11844 for ; Thu, 2 Jul 1998 06:14:00 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id GAA10448 for mpng-list@dworkin.wustl.edu; Thu, 2 Jul 1998 06:14:42 -0700 Date: Thu, 2 Jul 1998 06:14:42 -0700 Message-Id: <199807021314.GAA10448@bolt.sonic.net> From: Greg Roelofs To: mpng-list@dworkin.wustl.edu Subject: Re: MNG Draft 43 (19980630) Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List > Just a note so you don't think no one is listening. I am working > on MNG, I am write now learning and reading and researching the > basics of PNG so I understand MNG in full context. Note that I've been quietly adding MNG chunks to pngcheck; it doesn't do a very good job of *checking* them, per se, but it does list most of them correctly (including indicating what they're doing). I'll continue adding chunks as the mood strikes... Greg -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Sun Jul 5 16:45:09 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id QAA05042 for ; Sun, 5 Jul 1998 16:45:08 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA14707 for mpng-list-outgoing; Sun, 5 Jul 1998 16:48:59 -0500 Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA14702 for ; Sun, 5 Jul 1998 16:48:54 -0500 Received: from gerard1 (dc2-isdn917.dial.xs4all.nl [194.109.151.149]) by smtp1.xs4all.nl (8.8.8/8.8.8) with SMTP id XAA07873 for ; Sun, 5 Jul 1998 23:43:18 +0200 (CEST) Message-Id: <199807052143.XAA07873@smtp1.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@dworkin.wustl.edu Date: Sun, 5 Jul 1998 23:49:54 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: MNG format X-Confirm-Reading-To: "Gerard Juyn" X-pmrqc: 1 Priority: normal X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Concerning the MNG format and the sample files found at ftp://swrinde.nde.swri.edu/pub/mng/images I have a few questions. I am working on a PNG/MNG viewer as part of my HTML-editor and I found a few peculiarities with the samples: clondemo_d40 - the clipping bounds for the progressively displayed clones are 1 bit short which results in a striped image. also the last FRAM chunk clears the entire image again with the BACK color. (same for collage_d40) this last problem cannot be circumvented in my idea because it would aversely effect the backflag image. I'm not sure on this point so any help is appreciated. ie_d40 - the animation seems to jump at the endstage. perhaps one or two of the animation frames are missing or identical to their predecessor? again I'm not sure on this... Another thing I found was that some images contain filter-type=1 in the IHDR chunk. According the PNG-specs this is not allowed. I assume that this was done to simply ignore the filtering making the files a bit smaller by not adding a filter-byte to each scanline. Also I'm not sure on how to process SAVE and SEEK chunks. As there is no sample either it is a bit hard to understand the purpose. A little schematic with some explanation might get me on the right track. I'd appreciate any answer at all, as it seems there are currently not a lot of people working on this image-format; at least I haven't found any programs incorporating MNG. If you do know of any can you let me know as well. Thank you so much in advance. Gerard Juyn (gjuyn@xs4all.nl) PS. the program I'm working on can be found at http://www.3-t.com/3-T/products/mngi/Download.html It is designed for Win95/WinNT and is still very much in beta development so a few things definitely do not work: - transparancy - delta-images - SAVE, SEEK, PROM and some other minor chunks - true progressive display (interlacing does not display as such) - dithering for 256-color displays With some support it could probably be turned into a little editor as well... -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Sun Jul 5 20:16:27 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id UAA05645 for ; Sun, 5 Jul 1998 20:16:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA15985 for mpng-list-outgoing; Sun, 5 Jul 1998 20:21:29 -0500 Received: from email7.starnetinc.com (email7.starnetinc.com [204.178.185.113]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA15980 for ; Sun, 5 Jul 1998 20:21:23 -0500 Received: from ravicomp.net (07-126.001.popsite.net [207.227.181.126]) by email7.starnetinc.com (8.8.8/8.8.2) with SMTP id BAA18727 for ; Mon, 6 Jul 1998 01:15:28 GMT Message-ID: <35A024C9.4E78@starnetinc.com> Date: Sun, 05 Jul 1998 20:13:45 -0500 From: rsingh Organization: owner X-Mailer: Mozilla 3.0Gold (Win95; U) MIME-Version: 1.0 To: MPNG List Subject: Re: MNG format References: <199807052143.XAA07873@smtp1.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Gerard, > Another thing I found was that some images contain filter-type=1 in I read the spec again if this is true , it should not be valid from what I can tell. > Also I'm not sure on how to process SAVE and SEEK chunks. As there is > no sample either it is a bit hard to understand the purpose. A little > schematic with some explanation might get me on the right track. Same probelm here I have not got to that portion yet but I should be there in a couple of weeks. RS -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Mon Jul 6 23:46:34 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id XAA29751 for ; Mon, 6 Jul 1998 23:46:34 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA03249 for mpng-list-outgoing; Mon, 6 Jul 1998 23:51:08 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id XAA03244 for ; Mon, 6 Jul 1998 23:51:04 -0500 Received: (qmail 27605 invoked from network); 7 Jul 1998 04:44:39 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 7 Jul 1998 04:44:39 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id VAA19205; Mon, 6 Jul 1998 21:45:21 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id VAA14674; Mon, 6 Jul 1998 21:46:28 -0700 Date: Mon, 6 Jul 1998 21:46:28 -0700 Message-Id: <199807070446.VAA14674@bolt.sonic.net> From: Greg Roelofs To: gjuyn@xs4all.nl Subject: Re: MNG format Cc: mpng-list@dworkin.wustl.edu Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Gerard Juyn (gjuyn@xs4all.nl) wrote: > Also I'm not sure on how to process SAVE and SEEK chunks. As there is > no sample either it is a bit hard to understand the purpose. A little > schematic with some explanation might get me on the right track. The idea is fairly similar to the PostScript stack and gsave/grestore commands, except that there's only one "stack slot" or checkpoint. SAVE pushes the current state onto the "stack"; SEEK restores it. > I'd appreciate any answer at all, as it seems there are currently not > a lot of people working on this image-format; at least I haven't > found any programs incorporating MNG. If you do know of any can you > let me know as well. I've just added a new page: http://www.cdrom.com/pub/png/mngapps.html . Currently four are listed (including yours :-) ). Glenn, does/did ARL viewpng do MNGs, too? -- Greg Roelofs newt@pobox.com http://pobox.com/~newt/ Newtware, PNG Group, Info-ZIP, Philips Multimedia Center, ... -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Tue Jul 7 07:55:14 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id HAA09221 for ; Tue, 7 Jul 1998 07:55:14 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA07048 for mpng-list-outgoing; Tue, 7 Jul 1998 08:00:43 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA07043 for ; Tue, 7 Jul 1998 08:00:38 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id IAA05517; Tue, 7 Jul 1998 08:54:44 -0400 Message-Id: <1.5.4.32.19980707125052.00eb38d8@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Jul 1998 08:50:52 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG format Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 11:49 PM 7/5/98 +0100, you wrote: >Concerning the MNG format and the sample files >Another thing I found was that some images contain filter-type=1 in >the IHDR chunk. According the PNG-specs this is not allowed. I assume >that this was done to simply ignore the filtering making the files a >bit smaller by not adding a filter-byte to each scanline. Oops, that was a mistake on my part. I was experimenting with removing the filter bytes and somehow the experimental files found their way into the MNGs. I never noticed it because ARL viewpng was also set up to recognize filter_type 1 (no filter bytes, as you discovered). I will try to create replacement files soon. From the very beginning I've thought that such a variation would be worth while, since for paletted images filter_type "none" is almost always the right choice. I had been toying with making filter_type 1 (no filter bytes) a part of the specification for PNG datastreams that appear in MNG datastreams. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Tue Jul 7 08:27:40 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id IAA09919 for ; Tue, 7 Jul 1998 08:27:40 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA07379 for mpng-list-outgoing; Tue, 7 Jul 1998 08:33:15 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA07374 for ; Tue, 7 Jul 1998 08:33:10 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id JAA06457; Tue, 7 Jul 1998 09:27:25 -0400 Message-Id: <1.5.4.32.19980707132332.00ed67cc@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Jul 1998 09:23:32 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG format Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 09:46 PM 7/6/98 -0700, Greg wrote: >I've just added a new page: http://www.cdrom.com/pub/png/mngapps.html . >Currently four are listed (including yours :-) ). Glenn, does/did ARL >viewpng do MNGs, too? Yes. It still has some flaws -- doesn't handle sub-8-bit grayscales right, doesn't have the MNG PAST chunk implemented. I haven't done any work on viewpng since I retired from ARL last year. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Tue Jul 7 09:13:12 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id JAA11224 for ; Tue, 7 Jul 1998 09:13:11 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA07730 for mpng-list-outgoing; Tue, 7 Jul 1998 09:18:30 -0500 Received: from email7.starnetinc.com (email7.starnetinc.com [204.178.185.113]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA07725 for ; Tue, 7 Jul 1998 09:18:24 -0500 Received: from ravicomp.net (05-034.001.popsite.net [207.227.181.34]) by email7.starnetinc.com (8.8.8/8.8.2) with SMTP id OAA05861 for ; Tue, 7 Jul 1998 14:12:38 GMT Message-ID: <35A22C5B.1EB7@starnetinc.com> Date: Tue, 07 Jul 1998 09:10:35 -0500 From: rsingh Organization: owner X-Mailer: Mozilla 3.0Gold (Win95; U) MIME-Version: 1.0 To: MPNG List Subject: Re: MNG format References: <1.5.4.32.19980707125052.00eb38d8@netgsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Glenn Randers-Pehrson wrote: > bytes, as you discovered). I will try to create replacement > files soon. From the very beginning I've thought that such a > variation would be worth while, since for paletted images > filter_type "none" is almost always the right choice. I had > been toying with making filter_type 1 (no filter bytes) a part > of the specification for PNG datastreams that appear in MNG So is this in or out in the specification ? RS -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Tue Jul 7 10:37:26 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id KAA13651 for ; Tue, 7 Jul 1998 10:37:26 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA08374 for mpng-list-outgoing; Tue, 7 Jul 1998 10:42:19 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id KAA08369 for ; Tue, 7 Jul 1998 10:42:16 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id LAA12381; Tue, 7 Jul 1998 11:36:31 -0400 Message-Id: <1.5.4.32.19980707153239.00ec3404@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Jul 1998 11:32:39 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG format Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 09:10 AM 7/7/98 -0500, you wrote: >Glenn Randers-Pehrson wrote: >> bytes, as you discovered). I will try to create replacement >> files soon. From the very beginning I've thought that such a >> variation would be worth while, since for paletted images >> filter_type "none" is almost always the right choice. I had >> been toying with making filter_type 1 (no filter bytes) a part >> of the specification for PNG datastreams that appear in MNG > >So is this in or out in the specification ? Out, for now. There's no real good way to include it without the risk of people extracting such PNGs from MNG datastreams without restoring the filter bytes. Also the payoff isn't very large, a few dozen bytes in some cases that I tried. I haven't done enough testing to say for sure what the average savings would be. Also there are ways of compensating: If one arranges the palette to put the most-frequently-used pixel in the "0" position, the "0" filter bytes usually get compressed down to almost nothing. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Sat Jul 11 06:51:37 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id GAA27077 for ; Sat, 11 Jul 1998 06:51:37 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id GAA05173 for mpng-list-outgoing; Sat, 11 Jul 1998 06:56:07 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id GAA05168 for ; Sat, 11 Jul 1998 06:56:04 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id HAA13485; Sat, 11 Jul 1998 07:49:57 -0400 Message-Id: <1.5.4.32.19980711114603.00edb0a8@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 11 Jul 1998 07:46:03 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG format Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 11:49 PM 7/5/98 +0100, Gerard wrote: >I am working on a PNG/MNG viewer as part of my HTML-editor and I >found a few peculiarities with the samples: > >clondemo_d40 - the clipping bounds for the progressively displayed >clones are 1 bit short >Another thing I found was that some images contain filter-type=1 I've uploaded clondemo_d43.mng - fixed clipping bounds backflag_d43.mng - fixed "mandatory" bytes mayflower_d43.mng - fixed filter_type=1 ms_d43.mng - fixed filter_type=1, reworked to be smaller ie_d43.mng - fixed filter_type-1, reworked to be smaller 16million_d43.mng - changed loop indices and image_height (_d40 only shows the top 1024 lines) Thanks, Gerard, for the careful analysis of the files. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Sat Jul 11 13:31:31 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id NAA04671 for ; Sat, 11 Jul 1998 13:31:31 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA07923 for mpng-list-outgoing; Sat, 11 Jul 1998 13:37:02 -0500 Received: from email7.starnetinc.com (email7.starnetinc.com [204.178.185.113]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA07918 for ; Sat, 11 Jul 1998 13:36:59 -0500 Received: from ravicomp.net (04-219.001.popsite.net [207.227.180.219]) by email7.starnetinc.com (8.8.8/8.8.2) with SMTP id SAA28074 for ; Sat, 11 Jul 1998 18:30:53 GMT Message-ID: <35A7AEAA.7BE9@starnetinc.com> Date: Sat, 11 Jul 1998 13:27:54 -0500 From: rsingh Organization: owner X-Mailer: Mozilla 3.0Gold (Win95; U) MIME-Version: 1.0 To: MPNG List Subject: Re: MNG format References: <1.5.4.32.19980711114603.00edb0a8@netgsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Glenn, Question in the below example: The "SAVE ,SHOW 1 8" are not expressly needed are they ? I know that it is a good idea in this sample to do it but the rules of the decoder and encoder alreay make the animation run through 1-8 so if a user wanted omit these they could correct ? RS \212 M N G \r \n ^z \n # MNG signature. MHDR 256 300 # Width and height. 30 # 30 ticks per second. tERm 2 0 120 10 # When done, repeat from SAVE 10 times FRAM 4 0 2 0 0 0 30 # set framing_mode=4 (because the # images are opaque and we don't # need to clear the display between # frames) and the frame_duration to # 1 second. DEFI 1 IHDR ... IDAT ... IEND # Eight PNG datastreams DEFI 2 IHDR ... IDAT ... IEND # are read and stored as DEFI 3 IHDR ... IDAT ... IEND # abstract images, and DEFI 4 IHDR ... IDAT ... IEND # are displayed as they DEFI 5 IHDR ... IDAT ... IEND # are read. DEFI 6 IHDR ... IDAT ... IEND DEFI 7 IHDR ... IDAT ... IEND DEFI 8 IHDR ... IDAT ... IEND SAVE SHOW 1 8 MEND -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Sat Jul 11 14:05:27 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id OAA05342 for ; Sat, 11 Jul 1998 14:05:26 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA08271 for mpng-list-outgoing; Sat, 11 Jul 1998 14:11:21 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA08259 for ; Sat, 11 Jul 1998 14:11:15 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id PAA25276; Sat, 11 Jul 1998 15:05:06 -0400 Message-Id: <1.5.4.32.19980711190113.007172f4@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 11 Jul 1998 15:01:13 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG format Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 01:27 PM 7/11/98 -0500, you wrote: >Glenn, > >Question in the below example: >The "SAVE ,SHOW 1 8" are not expressly needed are they ? I know >that it is a good idea in this sample to do it but the rules of >the decoder and encoder alreay make the animation run through 1-8 so >if a user wanted omit these they could correct ? If you left them out, then the viewer would have to decode the images each time around the loop, but you'd still see the same result. The SAVE, SHOW chunks are there to demonstrate the most efficient method. Also, if you don't use SAVE, SHOW, then all the objects could be set up with DEFI 0. Of course, if the images are very large, it will take a lot of memory with the SAVE, SHOW method compared to the display-and-forget method. G > >RS > > >\212 M N G \r \n ^z \n # MNG signature. >MHDR 256 300 # Width and height. > 30 # 30 ticks per second. >tERm 2 0 120 10 # When done, repeat from SAVE 10 times >FRAM 4 0 2 0 0 0 30 # set framing_mode=4 (because the > # images are opaque and we don't > # need to clear the display between > # frames) and the frame_duration to > # 1 second. > >DEFI 1 IHDR ... IDAT ... IEND # Eight PNG datastreams >DEFI 2 IHDR ... IDAT ... IEND # are read and stored as >DEFI 3 IHDR ... IDAT ... IEND # abstract images, and >DEFI 4 IHDR ... IDAT ... IEND # are displayed as they >DEFI 5 IHDR ... IDAT ... IEND # are read. >DEFI 6 IHDR ... IDAT ... IEND >DEFI 7 IHDR ... IDAT ... IEND >DEFI 8 IHDR ... IDAT ... IEND > >SAVE >SHOW 1 8 > >MEND > >-- >Send the message body "help" to mpng-list-request@dworkin.wustl.edu > > -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Sat Jul 11 17:17:00 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id RAA08977 for ; Sat, 11 Jul 1998 17:17:00 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA10727 for mpng-list-outgoing; Sat, 11 Jul 1998 17:22:40 -0500 Received: from email7.starnetinc.com (email7.starnetinc.com [204.178.185.113]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA10721 for ; Sat, 11 Jul 1998 17:22:36 -0500 Received: from ravicomp.net (06-069.001.popsite.net [207.227.181.69]) by email7.starnetinc.com (8.8.8/8.8.2) with SMTP id WAA05371 for ; Sat, 11 Jul 1998 22:16:29 GMT Message-ID: <35A7E37D.2840@starnetinc.com> Date: Sat, 11 Jul 1998 17:13:17 -0500 From: rsingh Organization: owner X-Mailer: Mozilla 3.0Gold (Win95; U) MIME-Version: 1.0 To: MPNG List Subject: Re: MNG format References: <1.5.4.32.19980711190113.007172f4@netgsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Glenn, > The SAVE, SHOW chunks are there to demonstrate the most > efficient method. > > Also, if you don't use SAVE, SHOW, then all the objects could > be set up with DEFI 0. > > Of course, if the images are very large, it will take a lot of > memory with the SAVE, SHOW method compared to the display-and-forget > method. > You hit on my main concern and point. I think it is impratical for a whole set of animations to use the "Save/Seek." What it means is that I will have to store a different frame buffer for each object. I understand when you are talking about "efficient" playback but that is efficient in terms of CPU not memory. This is just going to take time to design. The specification is so massive that I plan on concentrating on a small subset at a time. I don't plan on giving up but there are just portions of MNG I don't see currently an efficient method to implement. Thankyou for all your help, I know you are not getting anything out of this and it is very commendable that you take the time to answer my annoying questions. RS -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Sat Jul 11 18:00:51 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id SAA09794 for ; Sat, 11 Jul 1998 18:00:51 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA11031 for mpng-list-outgoing; Sat, 11 Jul 1998 18:06:54 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA11026 for ; Sat, 11 Jul 1998 18:06:51 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id TAA31507; Sat, 11 Jul 1998 19:00:41 -0400 Message-Id: <1.5.4.32.19980711225649.00ecf414@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 11 Jul 1998 18:56:49 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG format Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 05:13 PM 7/11/98 -0500, you wrote: >Glenn, > >> The SAVE, SHOW chunks are there to demonstrate the most >> efficient method. >> >> Also, if you don't use SAVE, SHOW, then all the objects could >> be set up with DEFI 0. >> >> Of course, if the images are very large, it will take a lot of >> memory with the SAVE, SHOW method compared to the display-and-forget >> method. >> > >You hit on my main concern and point. I think it is impratical >for a whole set of animations to use the "Save/Seek." What it means >is that I will have to store a different frame buffer for each object. >I understand when you are talking about "efficient" playback but that >is efficient in terms of CPU not memory. I see a major use of MNG is to replace GIF for all those annoying animated banners on web pages. It's debatable whether such things should be written for memory or CPU efficiency. When you compare a typical 400x80 banner, which would need about a meg to store 10 frames in 24-bit color, with the about 300k zlib buffers and other memory needed to decode it each time around, and considering how cheap memory is, you wonder which will place the greater load on a typical system. The main problem is that it is the MNG author who decides which path to take, not the end user. The end user does have a choice of how to store objects, though, as frame buffers or as encoded PNGs which could be kept in memory or in files. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Sat Jul 11 22:41:43 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id WAA14872 for ; Sat, 11 Jul 1998 22:41:43 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id WAA12789 for mpng-list-outgoing; Sat, 11 Jul 1998 22:47:34 -0500 Received: from dfw-ix7.ix.netcom.com (dfw-ix7.ix.netcom.com [206.214.98.7]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id WAA12784 for ; Sat, 11 Jul 1998 22:47:31 -0500 Received: (from smap@localhost) by dfw-ix7.ix.netcom.com (8.8.4/8.8.4) id WAA10456 for ; Sat, 11 Jul 1998 22:41:18 -0500 (CDT) Received: from sji-ca1-122.ix.netcom.com(209.109.232.122) by dfw-ix7.ix.netcom.com via smap (V1.3) id rma010443; Sat Jul 11 22:41:09 1998 Message-Id: <3.0.5.32.19980711204347.00937cb0@popd.ix.netcom.com> X-Sender: jcbowler@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sat, 11 Jul 1998 20:43:47 -0700 To: MPNG List From: John Bowler Subject: Re: MNG format In-Reply-To: <1.5.4.32.19980711225649.00ecf414@netgsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 18:56 11/07/98 -0400, Glenn Randers-Pehrson wrote: >I see a major use of MNG is to replace GIF for all those annoying >animated banners on web pages. It's debatable whether such things >should be written for memory or CPU efficiency. When you compare >a typical 400x80 banner, which would need about a meg to store 10 >frames in 24-bit color, with the about 300k zlib buffers and other >memory needed to decode it each time around, and considering how >cheap memory is, you wonder which will place the greater load on >a typical system. That 300k is for *deflate* I believe - a MNG player should never need to deflate. To quote zconf.h (Zlib 1.1.2): /* The memory requirements for deflate are (in bytes): (1 << (windowBits+2)) + (1 << (memLevel+9)) that is: 128K for windowBits=15 + 128K for memLevel = 8 (default values) plus a few kilobytes for small objects. For example, if you want to reduce the default memory requirements from 256K to 128K, compile with make CFLAGS="-O -DMAX_WBITS=14 -DMAX_MEM_LEVEL=7" Of course this will generally degrade compression (there's no free lunch). The memory requirements for inflate are (in bytes) 1 << windowBits that is, 32K for windowBits=15 (default value) plus a few kilobytes for small objects. */ Well, even at 24bit a 400x800 banner is only 96k bytes uncompressed. The chances are that the animated sections in a MNG will be <16k uncompressed - this is the point at which the author will probably reduce the "windowBits" parameter to deflateInit2 to avoid some (quite a lot) of the memory which would otherwise be allocated with the default (15). The problem here is that this really doesn't help the player unless the player is prepared to do more work than a simple use of Zlib. This is because there is no guarantee that the author really did do the sensible thing, so the player cannot simply call inflateInit2 with the appropriate "windowBits" parameter. (For the details see the code in inflate_blocks_new which calls ZALLOC to allocate s->window - this unconditionally allocates the buffer size implied by the windowBits parameter to inflateInit2.) What a well written decoder might do is read the "method" byte from the head of the LZ stream and use this to control the window size - the method byte records the four bits of information needed to determine the window size used in the deflate algorithm. I'm not sure that this actually helps any though - MNG doesn't require parallel Zlib invocations (i.e. you only have to decompress one thing at once), so the memory requirement is determined by the largest "windowBits" value in any compressed element and this is likely to be 15 for any non-trivial animation. (Hum, but they're all trivial...) John Bowler -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Sun Jul 12 00:45:54 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id AAA17300 for ; Sun, 12 Jul 1998 00:45:53 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA13725 for mpng-list-outgoing; Sun, 12 Jul 1998 00:51:34 -0500 Received: from toronto.planeteer.com (toronto.planeteer.com [204.50.42.7]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id AAA13720 for ; Sun, 12 Jul 1998 00:51:30 -0500 Received: from win95 (to2p4.planeteer.com [204.50.42.69]) by toronto.planeteer.com (8.8.7/8.8.7) with ESMTP id BAA07116 for ; Sun, 12 Jul 1998 01:45:18 -0400 (EDT) Message-Id: <199807120545.BAA07116@toronto.planeteer.com> From: "Eric McGillicuddy" To: "MPNG List" Subject: Re: MNG format Date: Sun, 12 Jul 1998 01:48:10 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1157 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List > From: Glenn Randers-Pehrson > > I see a major use of MNG is to replace GIF for all those annoying > animated banners on web pages. It's debatable whether such things I don't think this a realistic expectation. MNG is far more complex than GIF89a and is not compatible with existing PNG decoders in the 4.x browsers, these two strikes will likely keep the format out of the mainstream for the foreseeable future. I see MNG as a vendorless alternative to AVI and QuickTime, although PNG slide shows seem to be the major usage. That being said, I am trying to implement C++ classes for MNG, PNG-F and my own Delta-PNG to compare the various advantages and disadvantages. Just critical chunks will be implemented for the proof of concept. I'll make it available as soon as I can, late summer seeming to be most likely. -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Sun Jul 12 10:00:49 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id KAA28019 for ; Sun, 12 Jul 1998 10:00:48 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA17125 for mpng-list-outgoing; Sun, 12 Jul 1998 10:06:07 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id KAA17120 for ; Sun, 12 Jul 1998 10:06:04 -0500 Received: (qmail 32363 invoked from network); 12 Jul 1998 14:59:20 -0000 Received: from unknown (HELO sub.sonic.net) (root@208.201.224.8) by marine.sonic.net with SMTP; 12 Jul 1998 14:59:20 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id HAA12335 for ; Sun, 12 Jul 1998 07:59:52 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id IAA12255 for mpng-list@dworkin.wustl.edu; Sun, 12 Jul 1998 08:01:27 -0700 Date: Sun, 12 Jul 1998 08:01:27 -0700 Message-Id: <199807121501.IAA12255@bolt.sonic.net> From: Greg Roelofs To: mpng-list@dworkin.wustl.edu Subject: Re: MNG format Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Some items I've noticed in MNG Drafts 42 and 43 (as part of my ongoing pngcheck extensions): - PROM: it appears that you cannot promote bit depth without promoting the color type? (else the "cases" are incomplete) - SEEK: why is a trailing null byte allowed? this is different from all other MNG and PNG chunks with variable-length text - SHOW: show_mode=7: missing end quote: "do_not_show=1. Greg -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Sun Jul 12 11:57:09 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id LAA28563 for ; Sun, 12 Jul 1998 11:57:08 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA17960 for mpng-list-outgoing; Sun, 12 Jul 1998 12:03:06 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA17955 for ; Sun, 12 Jul 1998 12:03:03 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id MAA22962; Sun, 12 Jul 1998 12:56:49 -0400 Message-Id: <1.5.4.32.19980712165255.0094988c@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 12 Jul 1998 12:52:55 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG format Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 08:01 AM 7/12/98 -0700, you wrote: >Some items I've noticed in MNG Drafts 42 and 43 (as part of my ongoing >pngcheck extensions): > > - PROM: it appears that you cannot promote bit depth without promoting > the color type? (else the "cases" are incomplete) That's an oversight. Obviously the case "color_type unchanged" is missing. The last case should be: Color_type unchanged Only the sample depth is changed. The new sample depth must be larger than the old one. > > - SEEK: why is a trailing null byte allowed? this is different from all > other MNG and PNG chunks with variable-length text "Keywords" are always followed by NULL byte elsewhere. It's a concession to software that might use a write_keyword() function that checks for illegal characters, etc., and emits a NULL at the end. I don't think there's any harm in allowing it. > > - SHOW: show_mode=7: missing end quote: "do_not_show=1. I thought I fixed that. I'll fix it again. If I remember. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Sun Jul 12 13:41:31 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id NAA29208 for ; Sun, 12 Jul 1998 13:41:30 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA18777 for mpng-list-outgoing; Sun, 12 Jul 1998 13:47:24 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id NAA18771 for ; Sun, 12 Jul 1998 13:47:21 -0500 Received: (qmail 3857 invoked from network); 12 Jul 1998 18:40:36 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 12 Jul 1998 18:40:36 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id LAA20578 for ; Sun, 12 Jul 1998 11:41:08 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id LAA18552 for mpng-list@dworkin.wustl.edu; Sun, 12 Jul 1998 11:42:44 -0700 Date: Sun, 12 Jul 1998 11:42:44 -0700 Message-Id: <199807121842.LAA18552@bolt.sonic.net> From: Greg Roelofs To: mpng-list@dworkin.wustl.edu Subject: Re: MNG format Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List >> - SEEK: why is a trailing null byte allowed? this is different from all >> other MNG and PNG chunks with variable-length text > "Keywords" are always followed by NULL byte elsewhere. It's a concession > to software that might use a write_keyword() function that checks > for illegal characters, etc., and emits a NULL at the end. I don't > think there's any harm in allowing it. "Keyword" is a fairly arbitrary label. Why don't you allow a trailing NULL in SAVE? Why not in FRAM or eXPI? DBYK appears to prohibit trailing NULLs but isn't explicit about it; nEED seemed to prohibit it at first reading but apparently doesn't. NULLs aren't allowed at the end of PNG tEXt, either. I think you should pick a convention and be consistent about it--preferably eliminating any bytes that aren't necessary, which was a general theme in the design of PNG and seems to be the case in MNG as well. Your hypothetical write_keyword() function is a fairly weak excuse, IMHO--it would be trivial for the calling function either to write the NULLs itself or to signal write_keyword() when a NULL is necessary. Also note that some of the names/keywords/other text have no length limits. That sort of thing should be specified one way or the other, too (e.g., "0-79" or "1-79" or "1 or more characters"). >> - SHOW: show_mode=7: missing end quote: "do_not_show=1. > I thought I fixed that. I'll fix it again. If I remember. I may have reported it already but forgotten to strike it from my notes. I forget things, too... Greg -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Sun Jul 12 17:30:23 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id RAA00256 for ; Sun, 12 Jul 1998 17:30:22 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA20604 for mpng-list-outgoing; Sun, 12 Jul 1998 17:36:24 -0500 Received: from email7.starnetinc.com (email7.starnetinc.com [204.178.185.113]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA20599 for ; Sun, 12 Jul 1998 17:36:15 -0500 Received: from ravicomp.net (02-102.001.popsite.net [207.227.180.102]) by email7.starnetinc.com (8.8.8/8.8.2) with SMTP id WAA10839 for ; Sun, 12 Jul 1998 22:29:58 GMT Message-ID: <35A93822.71BD@starnetinc.com> Date: Sun, 12 Jul 1998 17:26:42 -0500 From: rsingh Organization: owner X-Mailer: Mozilla 3.0Gold (Win95; U) MIME-Version: 1.0 To: MPNG List Subject: Re: MNG format References: <1.5.4.32.19980712165255.0094988c@netgsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Question, For Each IDAT in a MNG whether it be in a Delta-PNG or not, is it true that the encoder will Create a ZLIB instance Decode the IDAT and Kill the ZLIB, or does it make more sense to Use the same ZLIB instance to encode all the IDAT blocks. Wouldn't compression improve if each IDAT was compressed with the same ZLIB instance ? RS -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Sun Jul 12 20:37:24 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id UAA00935 for ; Sun, 12 Jul 1998 20:37:23 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA21707 for mpng-list-outgoing; Sun, 12 Jul 1998 20:43:17 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA21702 for ; Sun, 12 Jul 1998 20:43:14 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id VAA07818; Sun, 12 Jul 1998 21:36:50 -0400 Message-Id: <1.5.4.32.19980713013258.00eee20c@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 12 Jul 1998 21:32:58 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG format Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 05:26 PM 7/12/98 -0500, you wrote: >Question, > >For Each IDAT in a MNG whether it be in a Delta-PNG or not, is it >true that the encoder will Create a ZLIB instance Decode the IDAT >and Kill the ZLIB, or does it make more sense to Use the same ZLIB >instance to encode all the IDAT blocks. Wouldn't compression improve >if each IDAT was compressed with the same ZLIB instance ? Compression would probably improve but maintenance of such an arrangement would be a nightmare (When you CLON an object several times, for example, you'd have to store the zlib dictionary for each copy of the object). One way to get the benefit of a single zlib instance is demonstrated in the ms_d43.mng and ie_d43.mng samples. The individual frames are pasted together in one long "filmstrip" that is encoded as a single PNG, which is pulled through the visible area with a LOOP containing a MOVE and SHOW chunk. In ms_d43.mng, the visible area is the entire frame, while in ie_d43.mng it's just a 25x25 square near the right side. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Sun Jul 12 20:49:23 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id UAA00987 for ; Sun, 12 Jul 1998 20:49:23 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA21789 for mpng-list-outgoing; Sun, 12 Jul 1998 20:55:33 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA21784 for ; Sun, 12 Jul 1998 20:55:30 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id VAA08367; Sun, 12 Jul 1998 21:49:13 -0400 Message-Id: <1.5.4.32.19980713014520.00ed0d28@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 12 Jul 1998 21:45:20 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG format Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 11:42 AM 7/12/98 -0700, you wrote: >>> - SEEK: why is a trailing null byte allowed? this is different from all > Why don't you allow a trailing NULL >in SAVE? Why not in FRAM or eXPI? DBYK appears to prohibit trailing NULLs >but isn't explicit about it; nEED seemed to prohibit it at first reading >but apparently doesn't. NULLs aren't allowed at the end of PNG tEXt, either. > >I think you should pick a convention and be consistent about it--preferably >eliminating any bytes that aren't necessary, which was a general theme in >the design of PNG and seems to be the case in MNG as well. Your hypothetical >write_keyword() function is a fairly weak excuse, IMHO >Also note that some of the names/keywords/other text have no length limits. >That sort of thing should be specified one way or the other, too (e.g., >"0-79" or "1-79" or "1 or more characters"). OK OK, I'll scrub the document and make them all consistent. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Mon Jul 13 08:56:26 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id IAA04737 for ; Mon, 13 Jul 1998 08:56:26 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id JAA27924 for mpng-list-outgoing; Mon, 13 Jul 1998 09:01:49 -0500 Received: from email7.starnetinc.com (email7.starnetinc.com [204.178.185.113]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id JAA27919 for ; Mon, 13 Jul 1998 09:01:46 -0500 Received: from ravicomp.net (01-034.001.popsite.net [207.227.180.34]) by email7.starnetinc.com (8.8.8/8.8.2) with SMTP id NAA07679 for ; Mon, 13 Jul 1998 13:55:27 GMT Message-ID: <35AA1102.2D5B@starnetinc.com> Date: Mon, 13 Jul 1998 08:52:02 -0500 From: rsingh Organization: owner X-Mailer: Mozilla 3.0Gold (Win95; U) MIME-Version: 1.0 To: MPNG List Subject: Re: MNG format References: <1.5.4.32.19980713014520.00ed0d28@netgsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List I don't know what the process is but I can suggest that for IPLT or another chunk we create a Palette chunk that has an skip count. So Say I have an animation and on 12th frame the palette changes in indexes 232, why should I have waste file space with 231 entries. This is how palettes are handled in Autodesk FLC. If this can't be officially sanctioned by the spec could we add it to the ancillary chunks ? RS -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Mon Jul 13 10:01:14 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id KAA05378 for ; Mon, 13 Jul 1998 10:01:13 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA28558 for mpng-list-outgoing; Mon, 13 Jul 1998 10:02:49 -0500 Received: from tiu.arl.mil (tiu.arl.mil [128.63.9.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id KAA28553 for ; Mon, 13 Jul 1998 10:02:43 -0500 Received: from taylor.arl.mil by TIU.ARL.MIL id aa01250; 13 Jul 98 10:50 EDT Message-ID: <35AA1EB6.12F797E0@alumni.rpi.edu> Date: Mon, 13 Jul 1998 10:50:30 -0400 From: Glenn Randers-Pehrson X-Mailer: Mozilla 4.04 [en] (X11; U; IRIX 5.3 IP20) MIME-Version: 1.0 To: MPNG List Subject: Re: MNG format References: <1.5.4.32.19980713014520.00ed0d28@netgsi.com> <35AA1102.2D5B@starnetinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List rsingh wrote: > > I don't know what the process is but I can suggest that for > IPLT or another chunk we create a Palette chunk that has an > skip count. So Say I have an animation and on 12th frame the > palette changes in indexes 232, why should I have waste file > space with 231 entries. This is how palettes are handled in > Autodesk FLC. If this can't be officially sanctioned by the > spec could we add it to the ancillary chunks ? > > RS > Is there a good reason for not putting that color earlier in the PLTE, in the first place? I think it would have to be a critical chunk rather than ancillary. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Mon Jul 13 10:58:03 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id KAA05965 for ; Mon, 13 Jul 1998 10:58:03 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA29379 for mpng-list-outgoing; Mon, 13 Jul 1998 11:02:11 -0500 Received: from email7.starnetinc.com (email7.starnetinc.com [204.178.185.113]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA29374 for ; Mon, 13 Jul 1998 11:02:06 -0500 Received: from ravicomp.net (02-074.001.popsite.net [207.227.180.74]) by email7.starnetinc.com (8.8.8/8.8.2) with SMTP id PAA14036 for ; Mon, 13 Jul 1998 15:55:42 GMT Message-ID: <35AA2D35.1C81@starnetinc.com> Date: Mon, 13 Jul 1998 10:52:21 -0500 From: rsingh Organization: owner X-Mailer: Mozilla 3.0Gold (Win95; U) MIME-Version: 1.0 To: MPNG List Subject: Re: MNG format References: <1.5.4.32.19980713014520.00ed0d28@netgsi.com> <35AA1102.2D5B@starnetinc.com> <35AA1EB6.12F797E0@alumni.rpi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Glenn, > Is there a good reason for not putting that color earlier in > the PLTE, in the first place? While it is true we could put the entry earlier in the palette to help this MNG, say we had a lot of data files and this color only appeared in this MNG. Any time there is a fixed palette like in a game which will have a possible palette animation in some subrange this is a needed feature. RS -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Mon Jul 13 12:01:10 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id MAA06554 for ; Mon, 13 Jul 1998 12:01:09 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA29981 for mpng-list-outgoing; Mon, 13 Jul 1998 12:07:03 -0500 Received: from tiu.arl.mil (tiu.arl.mil [128.63.9.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id MAA29976 for ; Mon, 13 Jul 1998 12:07:00 -0500 Received: from taylor.arl.mil by TIU.ARL.MIL id aa03286; 13 Jul 98 12:59 EDT Message-ID: <35AA3CFD.535C2EED@alumni.rpi.edu> Date: Mon, 13 Jul 1998 12:59:42 -0400 From: Glenn Randers-Pehrson X-Mailer: Mozilla 4.04 [en] (X11; U; IRIX 5.3 IP20) MIME-Version: 1.0 To: MPNG List Subject: Re: MNG format References: <1.5.4.32.19980713014520.00ed0d28@netgsi.com> <35AA1102.2D5B@starnetinc.com> <35AA1EB6.12F797E0@alumni.rpi.edu> <35AA2D35.1C81@starnetinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List rsingh wrote: > Glenn, > > > Is there a good reason for not putting that color earlier in > > the PLTE, in the first place? > > While it is true we could put the entry earlier in the palette to help > this MNG, say we had a lot of data files and this color only appeared in > this MNG. Any time there is a fixed palette like in a game which will > have a possible palette animation in some subrange this is a needed > feature. OK, I'll see if there's a way to accomodate this without adding too much complexity. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Mon Jul 13 13:20:35 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id NAA07865 for ; Mon, 13 Jul 1998 13:20:34 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA01216 for mpng-list-outgoing; Mon, 13 Jul 1998 13:26:33 -0500 Received: from email7.starnetinc.com (email7.starnetinc.com [204.178.185.113]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA01209 for ; Mon, 13 Jul 1998 13:26:28 -0500 Received: from ravicomp.net (03-136.001.popsite.net [207.227.180.136]) by email7.starnetinc.com (8.8.8/8.8.2) with SMTP id SAA21990 for ; Mon, 13 Jul 1998 18:20:04 GMT Message-ID: <35AA4F09.7C6C@starnetinc.com> Date: Mon, 13 Jul 1998 13:16:41 -0500 From: rsingh Organization: owner X-Mailer: Mozilla 3.0Gold (Win95; U) MIME-Version: 1.0 To: MPNG List Subject: Re: MNG format References: <1.5.4.32.19980713014520.00ed0d28@netgsi.com> <35AA1102.2D5B@starnetinc.com> <35AA1EB6.12F797E0@alumni.rpi.edu> <35AA2D35.1C81@starnetinc.com> <35AA3CFD.535C2EED@alumni.rpi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Glenn, > OK, I'll see if there's a way to accomodate this without adding > too much complexity. If you don't mind I would suggest we adopt what is done in AutoDesk FLC/FLI's. WORD PacketCount; = How Many Packets Follow Each Packet is defined as [SKIP BYTE][TOTAL INDEXES to CHANGE BYTE][RGB ] so for instance: 2 // 2 Packets Total 2,1,0,0,0 //Skip 2 Colors Change 1 to 0,0,0 4,1,255,255,255 // Skip 4 Indexes from last and change 1 index //to 255,255,255 Ravi -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Mon Jul 13 14:07:22 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id OAA08921 for ; Mon, 13 Jul 1998 14:07:21 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA02120 for mpng-list-outgoing; Mon, 13 Jul 1998 14:12:28 -0500 Received: from tiu.arl.mil (tiu.arl.mil [128.63.9.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA02114 for ; Mon, 13 Jul 1998 14:12:25 -0500 Received: from taylor.arl.mil by TIU.ARL.MIL id aa05623; 13 Jul 98 15:05 EDT Message-ID: <35AA5A68.85711018@alumni.rpi.edu> Date: Mon, 13 Jul 1998 15:05:13 -0400 From: Glenn Randers-Pehrson X-Mailer: Mozilla 4.04 [en] (X11; U; IRIX 5.3 IP20) MIME-Version: 1.0 To: MPNG List Subject: Re: MNG format References: <1.5.4.32.19980713014520.00ed0d28@netgsi.com> <35AA1102.2D5B@starnetinc.com> <35AA1EB6.12F797E0@alumni.rpi.edu> <35AA2D35.1C81@starnetinc.com> <35AA3CFD.535C2EED@alumni.rpi.edu> <35AA4F09.7C6C@starnetinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List rsingh wrote: > > Glenn, > > > OK, I'll see if there's a way to accomodate this without adding > > too much complexity. > > If you don't mind I would suggest we adopt what is done in AutoDesk > FLC/FLI's. > > WORD PacketCount; = How Many Packets Follow > Each Packet is defined as > [SKIP BYTE][TOTAL INDEXES to CHANGE BYTE][RGB ] > > so for instance: > 2 // 2 Packets Total > 2,1,0,0,0 //Skip 2 Colors Change 1 to 0,0,0 > 4,1,255,255,255 // Skip 4 Indexes from last and change 1 > index //to 255,255,255 INDEX R G B would be simpler. So for your example, 2 0 0 0 # change entry 2 to 0 0 0 7 255 255 255 # change entry 7 to 255 255 255 It's only less efficient when you are changing a series of 3 or more consecutive entries. We don't need a "total packets" byte because we can just work until we reach the end of data. FIRST LAST R G B is another possibility. It's just as efficient as SKIP NUM_TO_CHANGE R G B ... but I think it's easier to read and implement correctly. 2 2 0 0 0 7 7 255 255 255 Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Mon Jul 13 15:15:07 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id PAA10452 for ; Mon, 13 Jul 1998 15:15:06 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA03051 for mpng-list-outgoing; Mon, 13 Jul 1998 15:20:57 -0500 Received: from email7.starnetinc.com (email7.starnetinc.com [204.178.185.113]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA03046 for ; Mon, 13 Jul 1998 15:20:54 -0500 Received: from ravicomp.net (06-092.001.popsite.net [207.227.181.92]) by email7.starnetinc.com (8.8.8/8.8.2) with SMTP id UAA28583 for ; Mon, 13 Jul 1998 20:14:29 GMT Message-ID: <35AA69D6.2203@starnetinc.com> Date: Mon, 13 Jul 1998 15:11:02 -0500 From: rsingh Organization: owner X-Mailer: Mozilla 3.0Gold (Win95; U) MIME-Version: 1.0 To: MPNG List Subject: Re: MNG format References: <1.5.4.32.19980713014520.00ed0d28@netgsi.com> <35AA1102.2D5B@starnetinc.com> <35AA1EB6.12F797E0@alumni.rpi.edu> <35AA2D35.1C81@starnetinc.com> <35AA3CFD.535C2EED@alumni.rpi.edu> <35AA4F09.7C6C@starnetinc.com> <35AA5A68.85711018@alumni.rpi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Glenn, > FIRST LAST R G B is another possibility. It's just as efficient > as SKIP NUM_TO_CHANGE R G B ... but I think it's easier to read and > implement correctly. Yes that seems great. RS -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Mon Jul 13 17:36:29 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id RAA13450 for ; Mon, 13 Jul 1998 17:36:23 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA05162 for mpng-list-outgoing; Mon, 13 Jul 1998 17:42:21 -0500 Received: from email7.starnetinc.com (email7.starnetinc.com [204.178.185.113]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA05155 for ; Mon, 13 Jul 1998 17:42:17 -0500 Received: from ravicomp.net (03-137.001.popsite.net [207.227.180.137]) by email7.starnetinc.com (8.8.8/8.8.2) with SMTP id WAA06119 for ; Mon, 13 Jul 1998 22:35:55 GMT Message-ID: <35AA8AFF.2039@starnetinc.com> Date: Mon, 13 Jul 1998 17:32:31 -0500 From: rsingh Organization: owner X-Mailer: Mozilla 3.0Gold (Win95; U) MIME-Version: 1.0 To: MPNG List Subject: Re: MNG format References: <1.5.4.32.19980713014520.00ed0d28@netgsi.com> <35AA1102.2D5B@starnetinc.com> <35AA1EB6.12F797E0@alumni.rpi.edu> <35AA2D35.1C81@starnetinc.com> <35AA3CFD.535C2EED@alumni.rpi.edu> <35AA4F09.7C6C@starnetinc.com> <35AA5A68.85711018@alumni.rpi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Glenn, Can I propose we call it the DPLT chunk of Differential Palette ? RS > > rsingh wrote: > > > > Glenn, > > > > > OK, I'll see if there's a way to accomodate this without adding > > > too much complexity. > > > > If you don't mind I would suggest we adopt what is done in AutoDesk > > FLC/FLI's. > > > > WORD PacketCount; = How Many Packets Follow > > Each Packet is defined as > > [SKIP BYTE][TOTAL INDEXES to CHANGE BYTE][RGB ] > > > > so for instance: > > 2 // 2 Packets Total > > 2,1,0,0,0 //Skip 2 Colors Change 1 to 0,0,0 > > 4,1,255,255,255 // Skip 4 Indexes from last and change 1 > > index //to 255,255,255 > > INDEX R G B would be simpler. So for your example, > > 2 0 0 0 # change entry 2 to 0 0 0 > 7 255 255 255 # change entry 7 to 255 255 255 > > It's only less efficient when you are changing a series > of 3 or more consecutive entries. We don't need a "total packets" > byte because we can just work until we reach the end of data. > > FIRST LAST R G B is another possibility. It's just as efficient > as SKIP NUM_TO_CHANGE R G B ... but I think it's easier to read and > implement correctly. > > 2 2 0 0 0 > 7 7 255 255 255 > > Glenn > > -- > Send the message body "help" to mpng-list-request@dworkin.wustl.edu -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Mon Jul 13 19:05:13 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id TAA14025 for ; Mon, 13 Jul 1998 19:05:13 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA06020 for mpng-list-outgoing; Mon, 13 Jul 1998 19:11:07 -0500 Received: from toronto.planeteer.com (toronto.planeteer.com [204.50.42.7]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA06015 for ; Mon, 13 Jul 1998 19:11:04 -0500 Received: from win95 (to1p12.planeteer.com [204.50.42.45]) by toronto.planeteer.com (8.8.7/8.8.7) with ESMTP id UAA24381 for ; Mon, 13 Jul 1998 20:04:38 -0400 (EDT) Message-Id: <199807140004.UAA24381@toronto.planeteer.com> From: "Eric McGillicuddy" To: "MPNG List" Subject: Re: MNG format Date: Mon, 13 Jul 1998 20:07:34 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1157 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List > From: rsingh > > I don't know what the process is but I can suggest that for > IPLT or another chunk we create a Palette chunk that has an > skip count. So Say I have an animation and on 12th frame the > palette changes in indexes 232, why should I have waste file > space with 231 entries. This is how palettes are handled in > Autodesk FLC. If this can't be officially sanctioned by the > spec could we add it to the ancillary chunks ? I would say that this would be a pretty rare occurence. An optimized encoder would keep its changing values low in the palette table to prevent this from happening often. I can see the possibility if Palette animation occurs often within the stream with many different values being altered at different times, but I can't imagine this being a major concern on modern computers. On my Apple II I could see this where the 3200 colour mode had a different palette for each scanline, but this would be a hardware dependent decoder concern. What would be the effect of an IPLT type? It would occasionally save a few bytes, but would cost code in the encoder and decoder. If it were in an ancillary chunk, it could be ignored. What effect would this have? Would the image be unviewable, degraded somewhat or just not as interesting? -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Mon Jul 13 19:51:29 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id TAA14198 for ; Mon, 13 Jul 1998 19:51:29 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA06412 for mpng-list-outgoing; Mon, 13 Jul 1998 19:57:44 -0500 Received: from email7.starnetinc.com (email7.starnetinc.com [204.178.185.113]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA06407 for ; Mon, 13 Jul 1998 19:57:40 -0500 Received: from ravicomp.net (06-061.001.popsite.net [207.227.181.61]) by email7.starnetinc.com (8.8.8/8.8.2) with SMTP id AAA13255 for ; Tue, 14 Jul 1998 00:51:17 GMT Message-ID: <35AAAAB5.3A74@starnetinc.com> Date: Mon, 13 Jul 1998 19:47:49 -0500 From: rsingh Organization: owner X-Mailer: Mozilla 3.0Gold (Win95; U) MIME-Version: 1.0 To: MPNG List Subject: Re: MNG format References: <199807140004.UAA24381@toronto.planeteer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List > I would say that this would be a pretty rare occurence. > different times, but I can't imagine this being a major concern on > > modern computers. You are thinking that the MNG has whole and sole control of the system. The question is not about what should happen with an optimizing encoder, it deals with the practical matters of having the animation work together in application with a fixed palette. RS -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Mon Jul 13 19:57:36 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id TAA14211 for ; Mon, 13 Jul 1998 19:57:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA06472 for mpng-list-outgoing; Mon, 13 Jul 1998 20:03:51 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA06467 for ; Mon, 13 Jul 1998 20:03:48 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id UAA17977; Mon, 13 Jul 1998 20:57:27 -0400 Message-Id: <1.5.4.32.19980714005331.00edee6c@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Jul 1998 20:53:31 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG format Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 05:32 PM 7/13/98 -0500, you wrote: >Glenn, > >Can I propose we call it the DPLT chunk of Differential Palette ? Or PPLT (Partial Palette -- sounds like a dental appliance) We can eliminate IPLT, because it only saves two bytes over the equivalent PPLT chunk. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Mon Jul 13 20:16:36 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id UAA14309 for ; Mon, 13 Jul 1998 20:16:35 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA06666 for mpng-list-outgoing; Mon, 13 Jul 1998 20:21:39 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA06661 for ; Mon, 13 Jul 1998 20:21:35 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id VAA18689; Mon, 13 Jul 1998 21:15:12 -0400 Message-Id: <1.5.4.32.19980714011117.00edee58@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Jul 1998 21:11:17 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG format Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 08:07 PM 7/13/98 -0400, Eric wrote: > >What would be the effect of an IPLT type? It would >occasionally save a few bytes, but would cost code in the encoder and >decoder. If it were in an ancillary chunk, it could be ignored. What effect >would this have? Would the image be unviewable, degraded somewhat or just >not as interesting? The difference in the amount of code would be miniscule. And there will be savings of code in the optimizers that won't have to bother with putting the changed colors early in the palette. If it were an ancillary chunk, colors would be displayed wrong. If it's blinking text, so much the better, unless the palette that's displayed happens to be the one with the text written in the background color. So it would be degraded, not as interesting, maybe unviewable, and maybe improved if you ignored the chunk. I think that on average (first-last-(r,g,b)*)* might save a little space over the present IPLT's (r,g,b)* especially when you consider that palette entry 0 is likely to be the transparent color and won't be changed. If we do include PPLT we should also abolish IPLT in the name of conserving the number of chunks. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Mon Jul 13 20:53:30 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id UAA14420 for ; Mon, 13 Jul 1998 20:53:30 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA06931 for mpng-list-outgoing; Mon, 13 Jul 1998 20:59:32 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA06926 for ; Mon, 13 Jul 1998 20:59:24 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id VAA20360; Mon, 13 Jul 1998 21:52:19 -0400 Message-Id: <1.5.4.32.19980714014824.00ed46f4@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Jul 1998 21:48:24 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Proposed PPLT chunk for MNG Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 09:11 PM 7/13/98 -0400, you wrote: >If we do include PPLT we should also abolish IPLT in the name of >conserving the number of chunks. By the way, IPLT did not allow the palette to be extended. I think we can remove that restriction, and say that if PPLT has any entries that are beyond the end of the parent PLTE, the palette must be extended by the decoder, just as it must when it receives a full PLTE chunk that has more entries than the parent PLTE. This would be nice when a new blob of color appears in the image; we could just use PPLT to append the new color to the end of the PLTE. In Draft 44, we'd have to write a whole new PLTE. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Tue Jul 14 07:53:05 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id HAA17377 for ; Tue, 14 Jul 1998 07:53:05 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA13626 for mpng-list-outgoing; Tue, 14 Jul 1998 07:58:25 -0500 Received: from email7.starnetinc.com (email7.starnetinc.com [204.178.185.113]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id HAA13620 for ; Tue, 14 Jul 1998 07:58:19 -0500 Received: from ravicomp.net (05-042.001.popsite.net [207.227.181.42]) by email7.starnetinc.com (8.8.8/8.8.2) with SMTP id MAA05490 for ; Tue, 14 Jul 1998 12:51:55 GMT Message-ID: <35AB5395.63D1@starnetinc.com> Date: Tue, 14 Jul 1998 07:48:21 -0500 From: rsingh Organization: owner X-Mailer: Mozilla 3.0Gold (Win95; U) MIME-Version: 1.0 To: MPNG List Subject: Re: Proposed PPLT chunk for MNG References: <1.5.4.32.19980714014824.00ed46f4@netgsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Glenn, > By the way, IPLT did not allow the palette to be extended. I think > we can remove that restriction, and say that if PPLT has any entries > that are beyond the end of the parent PLTE, the palette must be This sounds good to me. RS -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Tue Jul 14 11:21:19 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id LAA19557 for ; Tue, 14 Jul 1998 11:21:18 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA16107 for mpng-list-outgoing; Tue, 14 Jul 1998 11:26:25 -0500 Received: from toronto.planeteer.com (toronto.planeteer.com [204.50.42.7]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id LAA16102 for ; Tue, 14 Jul 1998 11:26:22 -0500 Received: from win95 (to1p7.planeteer.com [204.50.42.40]) by toronto.planeteer.com (8.8.7/8.8.7) with ESMTP id MAA27469 for ; Tue, 14 Jul 1998 12:19:56 -0400 (EDT) Message-Id: <199807141619.MAA27469@toronto.planeteer.com> From: "Eric McGillicuddy" To: "MPNG List" Subject: Re: Proposed PPLT chunk for MNG Date: Tue, 14 Jul 1998 12:22:55 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1157 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List > From: Glenn Randers-Pehrson > > By the way, IPLT did not allow the palette to be extended. I think > we can remove that restriction, and say that if PPLT has any entries > that are beyond the end of the parent PLTE, the palette must be > extended by the decoder, just as it must when it receives a full > PLTE chunk that has more entries than the parent PLTE. This would > be nice when a new blob of color appears in the image; we > could just use PPLT to append the new color to the end of the PLTE. > In Draft 44, we'd have to write a whole new PLTE. Works for me, however would this extend the palette beyond the maximum index or up to but not beyond? Since there are rules in place to promote images within the stream, I don't see any practical difficulty except that PNG does not support greater than 8 bit indexing. I have been wondering about a 16 bit palette for a while, why wasn't it included in the original PNG spec? -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Tue Jul 14 12:10:20 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id MAA19925 for ; Tue, 14 Jul 1998 12:10:20 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA16683 for mpng-list-outgoing; Tue, 14 Jul 1998 12:16:23 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA16677 for ; Tue, 14 Jul 1998 12:16:19 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id NAA13504; Tue, 14 Jul 1998 13:09:54 -0400 Message-Id: <1.5.4.32.19980714170559.00edf524@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Jul 1998 13:05:59 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: Proposed PPLT chunk for MNG Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 12:22 PM 7/14/98 -0400, you wrote: >> From: Glenn Randers-Pehrson >> >> By the way, IPLT did not allow the palette to be extended. I think >> we can remove that restriction, and say that if PPLT has any entries >> that are beyond the end of the parent PLTE, the palette must be >> extended by the decoder, just as it must when it receives a full >> PLTE chunk that has more entries than the parent PLTE. This would >> be nice when a new blob of color appears in the image; we >> could just use PPLT to append the new color to the end of the PLTE. >> In Draft 44, we'd have to write a whole new PLTE. I meant Draft 43... > >Works for me, however would this extend the palette beyond the maximum >index or up to but not beyond? It isn't legal to extend the palette beyond what's allowed by the sample_depth, or beyond 256 entries in the case of optional palettes. I've added a comment in Draft 44 to make that clear. >Since there are rules in place to promote >images within the stream, I don't see any practical difficulty except that >PNG does not support greater than 8 bit indexing. I have been wondering >about a 16 bit palette for a while, why wasn't it included in the original >PNG spec? You can achieve the effect with the faLS chunk that was proposed but did not pass the registration vote. But don't expect a lot of viewers to recognize it as a private chunk. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Tue Jul 14 13:10:30 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id NAA20421 for ; Tue, 14 Jul 1998 13:10:29 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA17410 for mpng-list-outgoing; Tue, 14 Jul 1998 13:16:28 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id NAA17405 for ; Tue, 14 Jul 1998 13:16:24 -0500 Received: (qmail 3629 invoked from network); 14 Jul 1998 18:09:31 -0000 Received: from unknown (HELO sub.sonic.net) (root@208.201.224.8) by marine.sonic.net with SMTP; 14 Jul 1998 18:09:31 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id LAA04999 for ; Tue, 14 Jul 1998 11:09:59 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id LAA13654 for mpng-list@dworkin.wustl.edu; Tue, 14 Jul 1998 11:11:46 -0700 Date: Tue, 14 Jul 1998 11:11:46 -0700 Message-Id: <199807141811.LAA13654@bolt.sonic.net> From: Greg Roelofs To: mpng-list@dworkin.wustl.edu Subject: Re: Proposed PPLT chunk for MNG Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List >>Since there are rules in place to promote >>images within the stream, I don't see any practical difficulty except that >>PNG does not support greater than 8 bit indexing. I have been wondering >>about a 16 bit palette for a while, why wasn't it included in the original >>PNG spec? Because for most images it's a waste of time, space and effort. For the extra 50% hit you take in extra IDAT bytes (RGB), you not only get a reasonable expectation that filtering will actually work (and make up much of the 50%), you also avoid the up-to-192K wastage of the palette itself. A 12-bit palette might have made sense, but then the index size doesn't fit in cleanly with PNG's other allowed depths. > You can achieve the effect with the faLS chunk that was proposed but > did not pass the registration vote. But don't expect a lot of viewers > to recognize it as a private chunk. You could probably also hack something crude with sPLT and 16-bit grayscale, but only your app would understand what to do with the combination. Greg -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Tue Jul 14 13:53:12 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id NAA20761 for ; Tue, 14 Jul 1998 13:53:12 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA17934 for mpng-list-outgoing; Tue, 14 Jul 1998 13:59:20 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA17928 for ; Tue, 14 Jul 1998 13:59:16 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id OAA17321; Tue, 14 Jul 1998 14:52:50 -0400 Message-Id: <1.5.4.32.19980714184855.00ed63ac@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Jul 1998 14:48:55 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: sPLT vs. faLS Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 11:11 AM 7/14/98 -0700, Greg wrote: >>[Glenn wrote] >> You can achieve the effect with the faLS chunk that was proposed but >> did not pass the registration vote. But don't expect a lot of viewers >> to recognize it as a private chunk. > >You could probably also hack something crude with sPLT and 16-bit grayscale, >but only your app would understand what to do with the combination. What a terrible suggestion. Why not stick with faLS, which was designed to do exactly what he wants, instead of overloading an existing registered chunk with some other confusing meaning? Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Tue Jul 14 14:17:12 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id OAA20994 for ; Tue, 14 Jul 1998 14:17:11 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA18204 for mpng-list-outgoing; Tue, 14 Jul 1998 14:22:52 -0500 Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id OAA18199 for ; Tue, 14 Jul 1998 14:22:44 -0500 Received: (qmail 6192 invoked from network); 14 Jul 1998 19:15:51 -0000 Received: from unknown (HELO sub.sonic.net) (208.201.224.8) by marine.sonic.net with SMTP; 14 Jul 1998 19:15:51 -0000 Received: from bolt.sonic.net (roelofs@bolt [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id MAA23323 for ; Tue, 14 Jul 1998 12:16:19 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id MAA17466 for mpng-list@dworkin.wustl.edu; Tue, 14 Jul 1998 12:18:06 -0700 Date: Tue, 14 Jul 1998 12:18:06 -0700 Message-Id: <199807141918.MAA17466@bolt.sonic.net> From: Greg Roelofs To: mpng-list@dworkin.wustl.edu Subject: Re: sPLT vs. faLS Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List >>You could probably also hack something crude with sPLT and 16-bit grayscale, >>but only your app would understand what to do with the combination. > What a terrible suggestion. Why not stick with faLS, which was designed > to do exactly what he wants, instead of overloading an existing registered > chunk with some other confusing meaning? Who said anything about overloading? sPLT is an officially approved chunk (faLS isn't); it was designed for 16-bit palettes; it's fully allowed in grayscale images with non-gray palette entries; and the specification is completely silent on how an application should in- terpret a colored sPLT in a grayscale image. I'm simply suggesting one logical way to do so (i.e., gray value = palette index) in the absence of any other useful information. It's up to the user to decide whether using an unregistered private chunk is a better idea than using an approved (though still unregistered) public chunk in an undocumented way. Greg -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Tue Jul 14 15:19:07 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id PAA21587 for ; Tue, 14 Jul 1998 15:19:07 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA18978 for mpng-list-outgoing; Tue, 14 Jul 1998 15:24:31 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA18973 for ; Tue, 14 Jul 1998 15:24:18 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id QAA20620; Tue, 14 Jul 1998 16:17:06 -0400 Message-Id: <1.5.4.32.19980714201312.00ed3dd8@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Jul 1998 16:13:12 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: sPLT vs. faLS Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 12:18 PM 7/14/98 -0700, you wrote: >>>You could probably also hack something crude with sPLT and 16-bit grayscale, >>>but only your app would understand what to do with the combination. > >> What a terrible suggestion. Why not stick with faLS, which was designed >> to do exactly what he wants, instead of overloading an existing registered >> chunk with some other confusing meaning? > >Who said anything about overloading? sPLT is an officially approved >chunk (faLS isn't); it was designed for 16-bit palettes; it's fully >allowed in grayscale images with non-gray palette entries; and the >specification is completely silent on how an application should in- >terpret a colored sPLT in a grayscale image. I'm simply suggesting >one logical way to do so (i.e., gray value = palette index) in the >absence of any other useful information. But that's quite at odds with the stated purpose of the chunk: To suggest a reduced palette to be used when the display is not capable of displaying the full range of colors present in the image. Also, all entries must be present, six bytes apiece, while faLT has eight-byte entries (IIRC) but allows interpolation between skipped entries. >It's up to the user to decide whether using an unregistered private >chunk is a better idea than using an approved (though still unregistered) >public chunk in an undocumented way. Either way, applications outside the author's control won't know what to do. Using sPLT as you suggest could confuse them into doing something peculiar, while using faLT would just cause them to ignore the chunk and display the grayscale. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Wed Jul 22 16:43:42 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id QAA09727 for ; Wed, 22 Jul 1998 16:43:41 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA22658 for mpng-list-outgoing; Wed, 22 Jul 1998 16:47:18 -0500 Received: from toronto.planeteer.com (toronto.planeteer.com [204.50.42.7]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA22650 for ; Wed, 22 Jul 1998 16:47:14 -0500 Received: from win95 (to2p0.planeteer.com [204.50.42.65]) by toronto.planeteer.com (8.8.7/8.8.7) with ESMTP id RAA10640 for ; Wed, 22 Jul 1998 17:39:59 -0400 (EDT) Message-Id: <199807222139.RAA10640@toronto.planeteer.com> From: "Eric McGillicuddy" To: "MPNG List" Subject: BACK chunk Date: Wed, 22 Jul 1998 17:43:21 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1157 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List The critical BACK chunk serves a similar function to the ancillary chunk bKGD. Is the promotion truly necessary? If so, what about increasing its utility by allowing a tiled pattern to be defined: 1 byte: Height 1 byte: Width 1 byte: Origin 0: base image origin 1: current FRAM origin Height x Width RGB triplets A single colour pattern would be 1 1 0 R G B, not much bigger than the existing def. The height and width are limited to prevent insanely large, uncompressed, images to be used as backgrounds instead of as base images. -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Thu Jul 23 00:50:59 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id AAA21005 for ; Thu, 23 Jul 1998 00:50:58 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id AAA00446 for mpng-list-outgoing; Thu, 23 Jul 1998 00:55:59 -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 AAA00441 for ; Thu, 23 Jul 1998 00:55:55 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by wugate.wustl.edu (8.8.8/8.8.5) with ESMTP id AAA00892 for ; Thu, 23 Jul 1998 00:09:29 -0500 (CDT) Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id XAA30221; Wed, 22 Jul 1998 23:02:22 -0400 Message-Id: <1.5.4.32.19980723025824.00954f4c@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 22 Jul 1998 22:58:24 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: MNG PAST chunk, was BACK chunk Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 05:43 PM 7/22/98 -0400, Eric wrote: >The critical BACK chunk serves a similar function to the ancillary chunk >bKGD. Is the promotion truly necessary? If so, what about increasing its >utility by allowing a tiled pattern to be defined: > >1 byte: Height >1 byte: Width >1 byte: Origin > 0: base image origin > 1: current FRAM origin >Height x Width RGB triplets > >A single colour pattern would be 1 1 0 R G B, not much bigger than the >existing def. > >The height and width are limited to prevent insanely large, uncompressed, >images to be used as backgrounds instead of as base images. But even small tiles, say 32x32, would be insanely large (3kb) compared to png-compressed tiles. Therefore I'm not in favor of this suggestion. What about adding a "tiled" orientation, or maybe several "tiled" orientations to the PAST chunk? 10: tile with upright copies 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11: tile with four copies, (1)upright, (2) flipped left-right, (3) flipped up-down, and (4) flipped both ways arrange in a 2x2 matrix 1 2 1 2 1 2 3 4 3 4 3 4 1 2 1 2 1 2 12: tile with two copies, (1) upright and (2) flipped left-right 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 13: tile with two copies, (1) upright and (2) upside-down 1 1 1 1 1 1 1 2 2 2 2 2 2 2 1 1 1 1 1 1 1 Once you've PASTed a destination object that has the same dimensions as the frame, just slap it down first as the background. The target_x and target_y give the location of the top left corner of the top left tile, and the others get their locations from the tiling operation. The clipping boundaries apply to the whole assembly. Example 11 would become MHDR ... DEFI 1 IHDR 128 64 ... PLTE ... IEND DEFI 2 BASI 1024 768 ... IEND PAST 2 0 0 0 1 0 10 0 0 0 0 0 1024 0 768 MEND Do you think there would be enough of a demand for this to justify the additional (not very much) complexity in the PAST chunk? Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Thu Jul 23 19:08:31 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id TAA07326 for ; Thu, 23 Jul 1998 19:08:30 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA10397 for mpng-list-outgoing; Thu, 23 Jul 1998 19:15:11 -0500 Received: from toronto.planeteer.com (toronto.planeteer.com [204.50.42.7]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA10392 for ; Thu, 23 Jul 1998 19:15:08 -0500 Received: from win95 (to1p7.planeteer.com [204.50.42.40]) by toronto.planeteer.com (8.8.7/8.8.7) with ESMTP id UAA12325 for ; Thu, 23 Jul 1998 20:07:50 -0400 (EDT) Message-Id: <199807240007.UAA12325@toronto.planeteer.com> From: "Eric McGillicuddy" To: "MPNG List" Subject: Re: MNG PAST chunk, was BACK chunk Date: Thu, 23 Jul 1998 20:11:15 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1157 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List > From: Glenn Randers-Pehrson > > What about adding a "tiled" orientation, or maybe several "tiled" > orientations to the PAST chunk? > I think of PAST as implying foreground objects. Although laying down the background tiles first does give the same effect as a background, it isn't as intuitive as using BACK. Really it comes down to a philosophical decision rather than a technical one. Speaking of philosophical decisions, I still feel there are too many critical chunks, although only BACK and CLIP I see realisitically being demoted. That being said, I think the spec is ready for prime time. It seems to fulfill its design criteria from every angle (except maybe multisourcing streams, but hey) and it seems to do so in a robust manner. Recent comments have dealt with details, no really major revisions have been suggested, so what do you think? -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Fri Jul 24 04:32:35 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id EAA10375 for ; Fri, 24 Jul 1998 04:32:34 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id EAA14462 for mpng-list-outgoing; Fri, 24 Jul 1998 04:38:46 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id EAA14457 for ; Fri, 24 Jul 1998 04:38:43 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id FAA09780; Fri, 24 Jul 1998 05:31:19 -0400 Message-Id: <1.5.4.32.19980724092721.00f15e34@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Jul 1998 05:27:21 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG PAST chunk, was BACK chunk Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 08:11 PM 7/23/98 -0400, you wrote: >> From: Glenn Randers-Pehrson >> >> What about adding a "tiled" orientation, or maybe several "tiled" >> orientations to the PAST chunk? >> >I think of PAST as implying foreground objects. Although laying down the >background tiles first does give the same effect as a background, it isn't >as intuitive as using BACK. Really it comes down to a philosophical >decision rather than a technical one. There is a technical issue of economy (of file size). Tiles expressed as PNGs are bound to be smaller than uncompressed ones, except for very small tiles, say 16x16 or smaller. Also, using an actual object as the background allows the possibility of an app to do a screen grab, create an object from that, and use it as the MNG background. It does mean that each FRAM will have to include a "SHOW 1" chunk to display the background object, while it's automatic with the BACK chunk. Now there's a thought: Modify the BACK chunk so that if it has 6 or 7 bytes it is interpreted as currently written, but if it has 2 or 3 bytes, it is interpreted as 2 bytes: background_object object to be displayed as the background of each frame, clipped to frame boundaries. If the dimensions of the object are smaller than the frame, use the object as a tile for filling the frame. Like background color, only used when framing_mode is 1, 2, or 3. 1 byte: 0: background object is mandatory 1: background object is advisory Can be omitted, in which case it is advisory. > >Speaking of philosophical decisions, I still feel there are too many >critical chunks, although only BACK and CLIP I see realisitically being >demoted. We tried BACK both ways and ended up deciding it had to be critical, in order to prevent it from being moved around. I don't think CLIP could be ignored. The main thing is to get all the critical chunks defined now rather than having to add some later. >That being said, I think the spec is ready for prime time. It >seems to fulfill its design criteria from every angle (except maybe >multisourcing streams, but hey) and it seems to do so in a robust manner. >Recent comments have dealt with details, no really major revisions have >been suggested, so what do you think? Still awaiting some alpha implementation work besides my own. I've recently gotten some good feedback from Gerard Juhn along that line. It's good to have another pair of eyes looking at the spec. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Fri Jul 24 04:47:50 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id EAA10441 for ; Fri, 24 Jul 1998 04:47:50 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id EAA14578 for mpng-list-outgoing; Fri, 24 Jul 1998 04:55:03 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id EAA14573 for ; Fri, 24 Jul 1998 04:55:01 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id FAA10012; Fri, 24 Jul 1998 05:47:42 -0400 Message-Id: <1.5.4.32.19980724094344.00f0ff30@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Jul 1998 05:43:44 -0400 To: mpng-list@dworkin.wustl.edu From: Glenn Randers-Pehrson Subject: Re: MNG PAST chunk, was BACK chunk Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List I wrote: object to be displayed as the background of each frame, clipped to frame boundaries. If the dimensions of the object are smaller than the frame, use the object as a tile for filling the frame. Like background color, only used when framing_mode is 1, 2, or 3. Forget that part about tiling. Leave it to the author to create an object of the correct size, which could possibly be a tiling made with the PAST chunk. object to be displayed as the background of each frame, when framing_mode is 1, 2, or 3. The object is clipped and positioned exactly as if it had been explicitly displayed by means of a SHOW chunk. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Fri Jul 24 05:27:05 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.8.8/8.8.5) with SMTP id FAA10644 for ; Fri, 24 Jul 1998 05:27:04 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id FAA14849 for mpng-list-outgoing; Fri, 24 Jul 1998 05:34:14 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id FAA14844 for ; Fri, 24 Jul 1998 05:34:12 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id GAA10649; Fri, 24 Jul 1998 06:26:53 -0400 Message-Id: <1.5.4.32.19980724102255.00f0d424@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Jul 1998 06:22:55 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG PAST chunk, was BACK chunk Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 05:43 AM 7/24/98 -0400, I wrote: > Forget that part about tiling. Leave it to the > author to create an object of the correct size, which > could possibly be a tiling made with the PAST chunk. > > object to be displayed as the background of > each frame, when framing_mode is 1, 2, or 3. > The object is clipped and positioned exactly > as if it had been explicitly displayed by > means of a SHOW chunk. > > Glenn Having said this, now it seems to me that even when we have a background_object, we still need the background color in case the background_object doesn't fill the frame. So instead of defining the background_object when the chunk length is 2 or 3, we'll need to define it when chunk length is 9: 2 bytes: red 2 bytes: green 2 bytes: blue 1 byte: mandatory (can be omitted if background_object is also omitted) 2 bytes: background_object (can be omitted) Glenn Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Tue Jul 28 16:28:59 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id QAA08312 for ; Tue, 28 Jul 1998 16:28:58 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA20232 for mpng-list-outgoing; Tue, 28 Jul 1998 16:20:18 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id QAA20227 for ; Tue, 28 Jul 1998 16:20:14 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id RAA08488; Tue, 28 Jul 1998 17:16:48 -0400 Message-Id: <1.5.4.32.19980728211248.00f3b420@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Jul 1998 17:12:48 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: MNG PPLT chunk and PNJ Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List I've received a suggestion that the proposed PPLT chunk be made "loop-able" like many of the other chunks. The first byte would be a "delta-type", in which 0 means the samples are absolute and 1 means they are deltas from the prior contents of the palette entry. Only one such byte would be included, which would apply to all groups of entries in the PPLT chunk. Incidentally, there seems now to be no reason to specify that only one PPLT chunk can appear in a Delta-PNG stream. Also, it's suggested that we add new delta_types to the DHDR, delta_type = 6 meaning that all of the pixels in the specified block are to be replaced with a single specified value (index, gray_sample, gray_alpha, rgb, or rgba), and delta_type = 7 that means all of the pixels in the specified block are to be incremented by the specified value(s), modulo 2^sample_depth. This would restore the capability that we had in the abandoned "fADE" chunk, and would allow some interesting loopable color changes, such as pulsating (rather than blinking) hearts, stars, and the like. I don't particularly like making big technical changes now, especially removing existing chunks like IPLT, but the spec isn't really frozen yet, and the suggestions are coming from people who are actually writing MNG decoders, so they have a bit more credibility than suggestions from bystanders. I'm going to incorporate these suggestions in the next draft, along with a PNJ spec (I don't think PNP is actually ever going to materialize, and wavelet technology seems to be mostly hot air for now). For those who have forgotten, I proposed PNJ a couple of years ago. This had been put on hold, awaiting something from pnp-list. A PNJ is a JHDR, plus a JPEG stream wrapped in PNG-style JDAT chunks, plus an optional alpha channel encoded in IDATs as if it were a grayscale image, plus all of the ancillary PNG chunks, followed by IEND. We would allow JDATs and IDATs to be interleaved. Tentatively, JHDR would contain width height jpeg_type 8: grayscale IJG jpeg-6b 10: color IJG jpeg-6b 12: grayscale IJG jpeg-6b plus alpha 14: color IJG jpeg-6b plus alpha progression 0: nonprogressive 1: progressive alpha_compression_type 0: zlib deflate alpha_bit_depth alpha_filter_type anything else? We will not allow the PNJ to be loaded as a concrete object, to avoid problems with people trying to use not-very-well defined pixels as the source for further composition. Debatable is whether to add Pegasus-arithmetic as a jpeg_type (or set of jpeg_types), pending sufficient testing by this group. jpeg_type values are chosen to make it simpler for MNG decoders to use existing PNG software; it can be interpreted as a color_type in which bit 3 is 0 for PNG and 1 for PNJ. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Tue Jul 28 18:50:52 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id SAA09468 for ; Tue, 28 Jul 1998 18:50:51 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA22908 for mpng-list-outgoing; Tue, 28 Jul 1998 18:49:56 -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 SAA22899 for ; Tue, 28 Jul 1998 18:49:43 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id TAA06606 for ; Tue, 28 Jul 1998 19:49:35 -0400 (EDT) To: MPNG List Subject: Re: MNG PPLT chunk and PNJ In-reply-to: Your message of Tue, 28 Jul 1998 17:12:48 -0400 <1.5.4.32.19980728211248.00f3b420@netgsi.com> Date: Tue, 28 Jul 1998 19:49:34 -0400 Message-ID: <6604.901669774@sss.pgh.pa.us> From: Tom Lane Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Glenn Randers-Pehrson writes: > Tentatively, JHDR would contain > jpeg_type > 8: grayscale IJG jpeg-6b > 10: color IJG jpeg-6b > 12: grayscale IJG jpeg-6b plus alpha > 14: color IJG jpeg-6b plus alpha > progression > 0: nonprogressive > 1: progressive This is a fairly simplistic representation of the possibilities for JPEG files. If you decide to invent PNJ you'd probably want a bunch more verbiage nailing down issues like allowed sampling ratios, whether noninterleaved baseline files are permitted, etc. I have some old notes for an RFC (that never happened) which might help. > Debatable is whether to add Pegasus-arithmetic as a > jpeg_type (or set of jpeg_types), pending sufficient testing > by this group. What's the intellectual-property status of that method? Is there an openly available specification (let alone code)? regards, tom lane organizer, Independent JPEG Group -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Tue Jul 28 20:52:42 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id UAA09993 for ; Tue, 28 Jul 1998 20:52:42 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA24090 for mpng-list-outgoing; Tue, 28 Jul 1998 20:52:41 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA24085 for ; Tue, 28 Jul 1998 20:52:38 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id VAA19603; Tue, 28 Jul 1998 21:52:27 -0400 Message-Id: <1.5.4.32.19980729014827.00f1f3b4@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Jul 1998 21:48:27 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG PPLT chunk and PNJ Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List tom wrote >This is a fairly simplistic representation of the possibilities >for JPEG files. If you decide to invent PNJ you'd probably want >a bunch more verbiage nailing down issues like allowed sampling ratios, >whether noninterleaved baseline files are permitted, etc. I have >some old notes for an RFC (that never happened) which might help. Right, the devil is in the "etc." and I will definitely need your help in nailing down details. Guess I need to break down and buy a copy of Pennebaker and Mitchell pretty soon. I do recall that there was to be a trilogy of RFC's -- PNG, JPEG, and a "best graphics practice". As far as what's allowed, I'd prefer to allow whatever can be read properly with your "djpeg" or at least whatever can be written with "cjpeg", because that's probably how PNJ's would be made. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Wed Jul 29 10:23:52 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id KAA02010 for ; Wed, 29 Jul 1998 10:23:51 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id KAA02251 for mpng-list-outgoing; Wed, 29 Jul 1998 10:21:27 -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 KAA02246 for ; Wed, 29 Jul 1998 10:21:22 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA07566 for ; Wed, 29 Jul 1998 11:21:10 -0400 (EDT) To: MPNG List Subject: Re: MNG PPLT chunk and PNJ In-reply-to: Your message of Tue, 28 Jul 1998 21:48:27 -0400 <1.5.4.32.19980729014827.00f1f3b4@netgsi.com> Date: Wed, 29 Jul 1998 11:21:09 -0400 Message-ID: <7564.901725669@sss.pgh.pa.us> From: Tom Lane Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Glenn Randers-Pehrson writes: > As far as what's allowed, I'd prefer to allow whatever > can be read properly with your "djpeg" or at least whatever can be > written with "cjpeg", because that's probably how PNJ's would be made. cjpeg/djpeg support a rather wider subset of the JPEG spec than most other implementations I'm familiar with. But it's still a subset. I would rather see PNJ using a "lowest common denominator" approach, so that practically any common decoder could be used (at least for baseline-JPEG-based PNJs). This issue opens up the whole question of MPNG subsets and whether you expect every implementation to be able to read any MPNG file. MPNG is already going to be fairly complex, and I'm disturbed by the notion that you are going to throw progressive JPEG decoding into the required feature set... regards, tom lane -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Wed Jul 29 11:20:11 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id LAA02442 for ; Wed, 29 Jul 1998 11:20:10 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id LAA03375 for mpng-list-outgoing; Wed, 29 Jul 1998 11:18:42 -0500 Received: from tiu.arl.mil (tiu.arl.mil [128.63.9.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id LAA03368 for ; Wed, 29 Jul 1998 11:18:33 -0500 Received: from taylor.arl.mil by TIU.ARL.MIL id aa27799; 29 Jul 98 12:17 EDT Message-ID: <35BF4B36.F3E7F5A2@alumni.rpi.edu> Date: Wed, 29 Jul 1998 12:17:58 -0400 From: Glenn Randers-Pehrson X-Mailer: Mozilla 4.04 [en] (X11; U; IRIX 5.3 IP20) MIME-Version: 1.0 To: MPNG List Subject: Re: MNG PPLT chunk and PNJ References: <7564.901725669@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Tom Lane wrote: > This issue opens up the whole question of MPNG subsets and whether > you expect every implementation to be able to read any MPNG file. > MPNG is already going to be fairly complex, and I'm disturbed by > the notion that you are going to throw progressive JPEG decoding > into the required feature set... Well, we can debate about that. I expect decoders to be able to *read* all MNG files, but I suppose people could write one that just creates an empty object with width*height when it encounters a progressive JPEG, and take their lumps when other people evaluate their software. Their app will immediatly know that it's got a progressive JPEG, from the JHDR chunk. If they do decode the image, they can choose whether to display it progressively or not, just as with Adam-7 interlaced PNGs. I think people will expect a progressive lossy capability to go along with the interlaced lossless capability, and might start heaping the same sort of abuse that PNG gets for not having an animation capability, if we don't supply it. The existence of IJG code is going to help application writers out quite a lot. I forgot whether you can #ifdef out the progressive capability and what is the savings in code size and complexity of you do (will have a look tonight). Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Wed Jul 29 14:18:46 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id OAA01551 for ; Wed, 29 Jul 1998 14:18:45 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA06771 for mpng-list-outgoing; Wed, 29 Jul 1998 14:15:40 -0500 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA06766 for ; Wed, 29 Jul 1998 14:15:35 -0500 Received: by INET-IMC-05 with Internet Mail Service (5.5.2328.0) id ; Wed, 29 Jul 1998 12:15:24 -0700 Message-ID: <71F299426E8CCF11B05600805F6809DF022ADDC0@cup-01-msg.dns.microsoft.com> From: John Bowler To: MPNG List Subject: RE: MNG PPLT chunk and PNJ Date: Wed, 29 Jul 1998 12:15:22 -0700 X-Mailer: Internet Mail Service (5.5.2328.0) Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List From: Tom Lane [mailto:tgl@sss.pgh.pa.us] >cjpeg/djpeg support a rather wider subset of the JPEG spec than most >other implementations I'm familiar with. But it's still a subset. >I would rather see PNJ using a "lowest common denominator" approach, >so that practically any common decoder could be used (at least for >baseline-JPEG-based PNJs). But how low. A reasonable minimal subset is 8 bit samples, 1 to 4 channels matching the PNG non-palette color types (grey, grey-alpha, rgb, rgba), no sub-sampling. This has the advantage of avoiding the color space convertions at the cost of lower compression (no sub-sampling on color, so that immediately doubles the input data size.) Certainly having progressive in there is bad - it has a large buffer overhead and, since PNJ elements are likely to be large in themselves, this is going to be a big hit on decoder requirements. Possible extensions are to share the Huffman tables and so on. I don't see any justification for using things like the JFIF APP0 marker - that information should be in a MNG chunk. Given alpha support it might even be reasonable to restrict PNJ elements to be a multiple of 8 in size. John Bowler -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Wed Jul 29 15:24:10 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id PAA02022 for ; Wed, 29 Jul 1998 15:24:09 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA08034 for mpng-list-outgoing; Wed, 29 Jul 1998 15:22: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 PAA08028 for ; Wed, 29 Jul 1998 15:22:12 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id QAA08358 for ; Wed, 29 Jul 1998 16:21:52 -0400 (EDT) To: MPNG List Subject: Re: MNG PPLT chunk and PNJ In-reply-to: Your message of Wed, 29 Jul 1998 12:17:58 -0400 <35BF4B36.F3E7F5A2@alumni.rpi.edu> Date: Wed, 29 Jul 1998 16:21:52 -0400 Message-ID: <8356.901743712@sss.pgh.pa.us> From: Tom Lane Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Glenn Randers-Pehrson writes: > The existence of IJG code is going to help application writers > out quite a lot. I forgot whether you can #ifdef out the > progressive capability and what is the savings in code size > and complexity of you do (will have a look tonight). You can #ifdef it out. I forget what the code size differential is. A bigger issue though is data workspace --- you need a full-image DCT-coefficient buffer to encode or decode a progressive JPEG, but not when handling a baseline file. The workspace involved is typically the same size as the uncompressed 24-bit RGB data (but can be twice that size if no subsampling is used). Of course, MPNG is already fairly memory-intensive, but that doesn't mean we shouldn't worry about the resources needed by a decoder. regards, tom lane -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Wed Jul 29 16:17:19 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id QAA02475 for ; Wed, 29 Jul 1998 16:17:18 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id QAA08591 for mpng-list-outgoing; Wed, 29 Jul 1998 16:15:59 -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 QAA08585 for ; Wed, 29 Jul 1998 16:15:48 -0500 Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id RAA08554 for ; Wed, 29 Jul 1998 17:15:34 -0400 (EDT) To: MPNG List Subject: Re: MNG PPLT chunk and PNJ In-reply-to: Your message of Wed, 29 Jul 1998 12:15:22 -0700 <71F299426E8CCF11B05600805F6809DF022ADDC0@cup-01-msg.dns.microsoft.com> Date: Wed, 29 Jul 1998 17:15:34 -0400 Message-ID: <8552.901746934@sss.pgh.pa.us> From: Tom Lane Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List John Bowler writes: > But how low. A reasonable minimal subset is 8 bit samples, 1 to 4 channels > matching the PNG non-palette color types (grey, grey-alpha, rgb, rgba), no > sub-sampling. I thought this was going to be a subset of standard usage? Alpha is not part of any widely used JPEG implementation, and there are very good reasons why not (see the JPEG FAQ, item 12). I would resist any effort to standardize on alpha inside the JPEG data, as opposed to outside in the style Glenn proposed. Unsubsampled RGB inside JPEG is also not standard usage. The compression hit compared to YCbCr is much more than two-to-one even when you compare to unsubsampled YCbCr, because you have to compress all three components of RGB at luminance quality or something near it. There is a reason why people take the trouble to convert to YCbCr. Most of the non-IJG codecs that I know of don't even have an option to deal with RGB compressed data. I'd go for something like baseline JPEG [that includes the 8-bit restriction], grayscale or YCbCr data only, JFIF component alignment and sample-range conventions, limited set of allowed subsampling ratios (1:1, 2:1, 2:2, maybe 1:2 for the digicam crowd), no multiscan images, no DNL markers, maybe a couple other things that I've forgotten offhand. This is pretty close to the universally portable subset of JPEG. Progressive, if permitted, would allow the progressive Huffman process (and hence multiple scans) but would not lift any of the other restrictions. > Possible extensions are to share the Huffman tables and so on. I don't see > any justification for using things like the JFIF APP0 marker - that > information should be in a MNG chunk. A JFIF marker would be useless but harmless. Considering that people are likely to make these things by wrapping PNJ overhead around existing JPEG files, any prohibition of JFIF-compatible overhead stuff would be honored mostly in the breach anyway. I'd suggest recommending that PNJ decoders ignore any COM or APPn markers in the JPEG data, but we should not try to prohibit them. I'm not sure whether allowing shared tables would be worth the trouble or not. The IJG code can cope with such things but I think it might be a hassle with other implementations. > Given alpha support it might even be > reasonable to restrict PNJ elements to be a multiple of 8 in size. Nah, what for? You expect people to go in and strip out the edge-condition-handling code? It wouldn't be any material code savings. More to the point, the most credible defense for this whole feature is that apps supporting MPNG are likely to have a JPEG decoder in there somewhere anyway. They can't strip out features needed for general- purpose JPEG support unless they want to have two sets of JPEG code. I think there's value in restricting PNJ to the smallest widely supported subset of JPEG, but not to less than that. regards, tom lane organizer, Independent JPEG Group -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Wed Jul 29 17:48:21 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id RAA03105 for ; Wed, 29 Jul 1998 17:48:20 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA09646 for mpng-list-outgoing; Wed, 29 Jul 1998 17:46:30 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA09640 for ; Wed, 29 Jul 1998 17:46:27 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id SAA26854; Wed, 29 Jul 1998 18:46:13 -0400 Message-Id: <1.5.4.32.19980729224212.00f1c4b8@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Jul 1998 18:42:12 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG PPLT chunk and PNJ Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 05:15 PM 7/29/98 -0400, you wrote: >John Bowler writes: >> But how low. A reasonable minimal subset is 8 bit samples, 1 to 4 channels >> matching the PNG non-palette color types (grey, grey-alpha, rgb, rgba), no >> sub-sampling. > >I thought this was going to be a subset of standard usage? I assume the four types enumerated are PNJ types, not types of JDAT data, which is either grey or color. We don't want to end up with something in the JDATs that *cannot* be read by djpeg. >I'd go for something like baseline JPEG [that includes the 8-bit >restriction], grayscale or YCbCr data only, JFIF component alignment and >sample-range conventions, limited set of allowed subsampling ratios >(1:1, 2:1, 2:2, maybe 1:2 for the digicam crowd), no multiscan images, >no DNL markers, maybe a couple other things that I've forgotten offhand. >This is pretty close to the universally portable subset of JPEG. > >Progressive, if permitted, would allow the progressive Huffman process >(and hence multiple scans) but would not lift any of the other >restrictions. Progressive, if permitted, is going to be interesting to implement in conjunction with alpha. I can see how interleaved alpha and baseline jpeg would work nicely together; just send down 8 rows of alpha and 8 rows of jpeg at a time. But I think the progressive would need to have the whole of alpha on hand before it starts with the image data -- or would it make sense for the entire alpha be interleaved with the first jpeg pass, for the decoder to be able to use it effectively? >I'd suggest recommending that PNJ >decoders ignore any COM or APPn markers in the JPEG data, but we should >not try to prohibit them. I would assume that we should strongly recommend (but not require) that commments be brought out and converted to tEXt/zTXt chunks (and that they be converted back in any PNJ->JPEG conversions). >I think there's value in restricting PNJ to the smallest widely >supported subset of JPEG, but not to less than that. Agreed. I'd still like to see that include progressive, but I could be persuaded that it's too complex. But it does seem to me that most image processing software is already going to include the capability of decoding them, so the burden wouldn't be something new. Keeping the decoded objects around won't be any different from keeping abstract PNGs, because we are declaring that such objects must be abstract ones (as I recall, looking forward to PNP/PNJ was a major reason for making the abstract/concrete distinction in the first place). Gamma, iCCP, cHRM, and whatnot would apply to the raw RGB or grayscale image data, not the transformed YCbCr data. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Wed Jul 29 20:18:14 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id UAA03647 for ; Wed, 29 Jul 1998 20:18:13 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA11191 for mpng-list-outgoing; Wed, 29 Jul 1998 20:16:47 -0500 Received: from toronto.planeteer.com (toronto.planeteer.com [204.50.42.7]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA11186 for ; Wed, 29 Jul 1998 20:16:44 -0500 Received: from win95 (to2p4.planeteer.com [204.50.42.69]) by toronto.planeteer.com (8.8.7/8.8.7) with ESMTP id VAA20512 for ; Wed, 29 Jul 1998 21:16:29 -0400 (EDT) Message-Id: <199807300116.VAA20512@toronto.planeteer.com> From: "Eric McGillicuddy" To: "MPNG List" Subject: Re: MNG PPLT chunk and PNJ Date: Wed, 29 Jul 1998 21:20:09 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1157 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List > From: Glenn Randers-Pehrson > > or rgba), and delta_type = 7 that means all > of the pixels in the specified block are to be incremented > by the specified value(s), modulo 2^sample_depth. This would > restore the capability that we had in the abandoned "fADE" > chunk, and would allow some interesting loopable color > changes, such as pulsating (rather than blinking) hearts, > stars, and the like. > Do you mean decrement? I pictured doing fades by increasing cheap transparency. I see fades as scene transitioning transforms, but pulsating images make a lot of sense. Would the increment be by 1 or by a value passed in a data field? With a signed value, fade to white or to black can be implemented. -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Thu Jul 30 02:37:26 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id CAA05084 for ; Thu, 30 Jul 1998 02:37:26 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id CAA13709 for mpng-list-outgoing; Thu, 30 Jul 1998 02:36:56 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id CAA13704 for ; Thu, 30 Jul 1998 02:36:53 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id DAA10032; Thu, 30 Jul 1998 03:36:37 -0400 Message-Id: <1.5.4.32.19980730073237.00f197a0@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Jul 1998 03:32:37 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG PPLT chunk and PNJ Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 09:20 PM 7/29/98 -0400, you wrote: >> From: Glenn Randers-Pehrson >> >> or rgba), and delta_type = 7 that means all >> of the pixels in the specified block are to be incremented >> by the specified value(s), modulo 2^sample_depth. This would >> restore the capability that we had in the abandoned "fADE" >> chunk, and would allow some interesting loopable color >> changes, such as pulsating (rather than blinking) hearts, >> stars, and the like. >> >Do you mean decrement? You can decrement by adding a large value. e.g. sample_depth = 8, add 255 to each sample, mod 256, will actually decrement each pixel by 1. > >I pictured doing fades by increasing cheap transparency. We don't have a "loop-able" delta-tRNS directive, though, so you'd have to have a series of Delta-PNGs with replacement tRNS chunks. > I see fades as >scene transitioning transforms, but pulsating images make a lot of sense. >Would the increment be by 1 or by a value passed in a data field? With a >signed value, fade to white or to black can be implemented. By specified value. We use unsigned values but "adding modulo 2^sample_depth" gives the same end result as subtracting. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Thu Jul 30 08:45:14 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id IAA06636 for ; Thu, 30 Jul 1998 08:45:14 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id IAA00577 for mpng-list-outgoing; Thu, 30 Jul 1998 08:40:57 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id IAA00572 for ; Thu, 30 Jul 1998 08:40:47 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id JAA16829; Thu, 30 Jul 1998 09:40:26 -0400 Message-Id: <1.5.4.32.19980730133625.00f234b0@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Jul 1998 09:36:25 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG PPLT chunk Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 05:12 PM 7/28/98 -0400, I wrote: >Also, it's suggested that we add new delta_types to the >DHDR, delta_type = 6 meaning that all of the pixels in >the specified block are to be replaced with a single >specified value (index, gray_sample, gray_alpha, rgb, >or rgba), and delta_type = 7 that means all >of the pixels in the specified block are to be incremented >by the specified value(s), modulo 2^sample_depth. This would >restore the capability that we had in the abandoned "fADE" >chunk, and would allow some interesting loopable color >changes, such as pulsating (rather than blinking) hearts, >stars, and the like. Looking at this idea in the light of day.... It has all the problems of the abandoned "fADE" chunk. While it would work fine for doing transitions with opaque images, as soon as we try to do it with a transparent one, we get in trouble trying to make black stay black and white stay white. By the time we take care of all that, these two delta_types will probably become 4 or 6 new types, and still might give surprising results. The safe way to accomplish this stuff is as demonstrated in Example 9, which leaves it to the image author to get it right. It's unfortunately not quite as economical in file size because you need one instance of a mask, encoded as if it were a grayscale PNG. But in the event of a mask that contains the same value in every pixel, which is what would be accomplished by those proposed delta_types, the compressed mask won't be very big -- a 64x64 mask with all samples identical compresses to 100 bytes; a 512x512 mask compresses to 856 bytes. I don't think that savings, given the probable rarity of use, and given that there *is* already a way of accomplishing the task, is worth the additional complexity of the DHDR chunk. Now, another (very economical) way of attacking this would be to extend the PPLT chunk once again, to give it *four* samples per entry, which would be the existing R,G,B, plus an alpha that would go into the corresponding tRNS array. Or, better yet, make the transparency optional, by recognizing a few more cases of pplt_delta_type: 0: absolute RGB entries (3 bytes per entry) 1: delta RGB entries (3 bytes per entry) 2: absolute tRNS entries (1 byte per entry) 3: delta tRNS entries (1 byte per entry) 4: absolute RGBA entries (4 bytes per entry) 5: delta RGBA entries (4 bytes per entry) The only real complexity here is what to do if a tRNS array is implicitly created when one didn't exist in the parent object, or extended beyond the original length. We can forbid it or allow it -- I don't see a good reason for forbidding it, as long as the spec explains what to do (fill in any undefined new entries with 255). So, for example, if you have a 10-color indexed-color image in which color 0 is transparent, you can "fade in" the image with MHDR ... DEFI 1 0 1 IHDR ... PLTE ... tRNS 0 0 0 0 0 0 0 0 0 0 IDAT ... IEND LOOP 0 0 5 # fade in DHDR 1 1 5 PPLT 5 1 10 51 51 51 51 51 51 51 51 51 IEND ENDL 0 # tRNS array now contains 0 255 255 ... 255 LOOP 0 0 5 # fade out DHDR 1 1 5 PPLT 5 1 10 204 204 204 204 204 204 204 204 204 IEND ENDL 0 MEND Obviously this scheme only works for indexed-color images. If you want to fade a full RGBA image, you would have to use the method shown in Example 9 of the MNG spec. Still another solution would be to invent a PTRN chunk (Partial tRNS), but I think I like the combined PPLT better. The example above would read exactly the same, except having "PTRN 1" instead of "PPLT 5". Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Thu Jul 30 12:20:28 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id MAA08324 for ; Thu, 30 Jul 1998 12:20:27 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA02985 for mpng-list-outgoing; Thu, 30 Jul 1998 12:20:03 -0500 Received: from tiu.arl.mil (tiu.arl.mil [128.63.9.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id MAA02978 for ; Thu, 30 Jul 1998 12:19:54 -0500 Received: from taylor.arl.mil by TIU.ARL.MIL id aa15392; 30 Jul 98 13:15 EDT Message-ID: <35C0AA16.D0D043D8@alumni.rpi.edu> Date: Thu, 30 Jul 1998 13:15:02 -0400 From: Glenn Randers-Pehrson X-Mailer: Mozilla 4.04 [en] (X11; U; IRIX 5.3 IP20) MIME-Version: 1.0 To: MPNG List Subject: Re: MNG PPLT chunk References: <1.5.4.32.19980730133625.00f234b0@netgsi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List I wrote: > 0: absolute RGB entries (3 bytes per entry) > 1: delta RGB entries (3 bytes per entry) > 2: absolute tRNS entries (1 byte per entry) > 3: delta tRNS entries (1 byte per entry) > 4: absolute RGBA entries (4 bytes per entry) > 5: delta RGBA entries (4 bytes per entry) > > So, for example, if you have a 10-color indexed-color > image in which color 0 is transparent, you can "fade in" > the image with > > MHDR ... > DHDR 1 1 5 Oops, I was rearranging the proposal and forgot to keep the example in sync. The "5" should read "3", in both DHDR chunks. Sorry. Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Fri Jul 31 16:01:32 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id QAA24821 for ; Fri, 31 Jul 1998 16:01:31 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA18933 for mpng-list-outgoing; Fri, 31 Jul 1998 15:58:34 -0500 Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.6.53]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA18928 for ; Fri, 31 Jul 1998 15:58:29 -0500 Received: from gerard1 (dc2-isdn522.dial.xs4all.nl [194.109.150.10]) by smtp3.xs4all.nl (8.8.8/8.8.8) with SMTP id WAA24317 for ; Fri, 31 Jul 1998 22:58:05 +0200 (CEST) Message-Id: <199807312058.WAA24317@smtp3.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@dworkin.wustl.edu Date: Fri, 31 Jul 1998 22:55:58 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: MNG PPLT chunk X-Confirm-Reading-To: "Gerard Juyn" X-pmrqc: 1 Priority: normal In-reply-to: <1.5.4.32.19980730133625.00f234b0@netgsi.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Hi Glenn, > Now, another (very economical) way of attacking this would be > to extend the PPLT chunk once again, to give it *four* samples > per entry, which would be the existing R,G,B, plus > an alpha that would go into the corresponding tRNS array. > Or, better yet, make the transparency optional, by recognizing > a few more cases of pplt_delta_type: > > 0: absolute RGB entries (3 bytes per entry) > 1: delta RGB entries (3 bytes per entry) > 2: absolute tRNS entries (1 byte per entry) > 3: delta tRNS entries (1 byte per entry) > 4: absolute RGBA entries (4 bytes per entry) > 5: delta RGBA entries (4 bytes per entry) Sounds good to me. This makes the whole thing very flexible. > The only real complexity here is what to do if a tRNS array > is implicitly created when one didn't exist in the parent > object, or extended beyond the original length. We can forbid > it or allow it -- I don't see a good reason for forbidding it, > as long as the spec explains what to do (fill in any undefined > new entries with 255). No tRNS or extend -> just create/extend it with opaque values. It doesn't make the internal representation any more difficult as it should already be prepared to handle a regular tRNS. > Still another solution would be to invent a PTRN chunk > (Partial tRNS), but I think I like the combined PPLT > better. The example above would read exactly the same, > except having "PTRN 1" instead of "PPLT 5". The combination inside a new PPLT keeps things simplified to just one more chunk. Naturally it should only be allowed for target-objects that already contain a PLTE. Btw, I've got permission to use the sample-images so I'll be uploading the final version of my viewer this weekend. I already sneaked in the PPLT type=0&1 support with a little sample image. Gerard (gjuyn@xs4all.nl) -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu From owner-mpng-list@dworkin.wustl.edu Fri Jul 31 18:39:00 1998 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.9.1/8.9.1) with SMTP id SAA25610 for ; Fri, 31 Jul 1998 18:39:00 -0500 (CDT) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA21362 for mpng-list-outgoing; Fri, 31 Jul 1998 18:39:15 -0500 Received: from grok.netgsi.com (grok.netgsi.com [192.55.203.19]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA21357 for ; Fri, 31 Jul 1998 18:39:11 -0500 Received: by NetGSI.com (8.8.7/-A/UX-AMR-1.0) id TAA13792; Fri, 31 Jul 1998 19:38:45 -0400 Message-Id: <1.5.4.32.19980731233445.00f27af8@netgsi.com> X-Sender: glennrp@netgsi.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 31 Jul 1998 19:34:45 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG PPLT chunk Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List At 10:55 PM 7/31/98 +0100, you wrote: >Hi Glenn, > I already >sneaked in the PPLT type=0&1 support with a little sample image. Good! Notice that the syntax didn't change when I added the rest. I hope to have Draft 44 ready tonight. #:-) Glenn -- Send the message body "help" to mpng-list-request@dworkin.wustl.edu