From owner-mpng-list@ccrc.wustl.edu Sat May 1 15:16:29 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id PAA06128; Sat, 1 May 1999 15:16:28 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id PAA03250 for mpng-list-out-eY3f3Qzu; Sat, 1 May 1999 15:10:54 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from golden.argonet.co.uk (golden.argonet.co.uk [194.131.104.13]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with SMTP id PAA03246 for ; Sat, 1 May 1999 15:10:52 -0500 (CDT) Received: from usern077.uk.uudial.com (argonet.co.uk) [193.149.81.110] by golden.argonet.co.uk with smtp (Exim 1.82 #3) id 10dg63-0003AO-00; Sat, 1 May 1999 21:10:48 +0100 MIME-Version: 1.0 From: Tanner Family To: mpng-list@ccrc.wustl.edu Date: Sat, 01 May 1999 19:40:38 +0100 Subject: VOTE on MNG-0.95 (YES) Message-ID: <48fb82930attehtann@argonet.co.uk> User-Agent: Pluto/1.11f (RISC-OS/3.7) Content-Type: text/plain Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List YES MNG-0.95 19990425 ftp://swrinde.nde.swri.edu/pub/mng/documents/ mng-0.95-19990425-pdg.html Tom Tanner Love from us all -- The Tanner Family email: T, T, E and H Tann(er), who use Argonet, a UK Company, to supply their internet access [anti spam!] web page: http://www.argonet.co.uk/users/ttehtann Warning: Here be random taglines! ... Outlaw junk mail, and save the trees! -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Sat May 1 20:10:40 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id UAA09746; Sat, 1 May 1999 20:10:39 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id UAA08444 for mpng-list-out-eY3f3Qzu; Sat, 1 May 1999 20:06:03 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from u29.CS.Berkeley.EDU (u29.CS.Berkeley.EDU [128.32.44.153]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id UAA08440 for ; Sat, 1 May 1999 20:06:01 -0500 (CDT) Received: (from amc@localhost) by u29.CS.Berkeley.EDU (8.8.3/8.8.2) id SAA08150 for mpng-list@ccrc.wustl.edu; Sat, 1 May 1999 18:05:59 -0700 (PDT) Received: from echo.sound.net ([205.242.192.21]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with SMTP id RAA05510 for ; Sat, 1 May 1999 17:22:07 -0500 (CDT) Received: (qmail 2194 invoked from network); 1 May 1999 22:04:59 -0000 Received: from mrvandy.unlimitedpotential.com (HELO mrvandy) (209.153.92.26) by echo.sound.net with SMTP; 1 May 1999 22:04:59 -0000 Message-ID: <000401be9420$ff53d120$1a5c99d1@mrvandy.sound.net> From: "Mike Reed" To: "MPNG List" Subject: VOTE on MNG-0.95 (YES) Date: Sat, 1 May 1999 17:21:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List YES MNG-0.95 19990425 ftp://swrinde.nde.swri.edu/pub/mng/documents/ mng-0.95-19990425-pdg.html Mike Reed I can't wait for MNG to put a sizable dent in Unisys royalties. Animated GIF has held us captive long enough. Thanks to everyone involved. -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Sat May 1 20:10:47 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id UAA09761; Sat, 1 May 1999 20:10:47 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id UAA08450 for mpng-list-out-eY3f3Qzu; Sat, 1 May 1999 20:06:10 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from u29.CS.Berkeley.EDU (u29.CS.Berkeley.EDU [128.32.44.153]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id UAA08446 for ; Sat, 1 May 1999 20:06:09 -0500 (CDT) Received: (from amc@localhost) by u29.CS.Berkeley.EDU (8.8.3/8.8.2) id SAA08157 for mpng-list@ccrc.wustl.edu; Sat, 1 May 1999 18:06:09 -0700 (PDT) Received: from echo.sound.net ([205.242.192.21]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with SMTP id RAA05837 for ; Sat, 1 May 1999 17:34:48 -0500 (CDT) Received: (qmail 4240 invoked from network); 1 May 1999 22:17:40 -0000 Received: from mrvandy.unlimitedpotential.com (HELO mrvandy) (209.153.92.26) by echo.sound.net with SMTP; 1 May 1999 22:17:40 -0000 Message-ID: <001901be9422$c5021700$1a5c99d1@mrvandy.sound.net> From: "Mike Reed" To: "MPNG List" Subject: Re: MNG-PNG Question Date: Sat, 1 May 1999 17:34:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List I have informed LeadTools to the near frozen state of MNG and they assure me that the next release of LeadTools will support MNG. I bet it will not support the full MNG spec but perhaps at least one or more of the lite specs. I can't imagine them have the resources to do a full implementation on the first round. LeadTools has been plagued by the Unisys license challenge for many years and seem eager to offer other options to the developers who use their tools. I have had several messages back and forth with Gabe and made sure he knew how to get his hands on the correct spec. I am personally crossing my fingers that LeadTools implements great support for MNG. I desperately need it for my system. I refuse to pay the unfair Unisys fees for animated GIF usage on our new network. Mike Reed Director of Research and Development Unlimited Potential, Inc. All Minds Network Project http://www.allminds.com original message: --------------------------- Mike, Thank you for your information. LEADTOOLS is going to add support for animated PNG in version 11 of LEADTOOLS. Version all is due to release around the end of May. I will keep you posted. Thanks, Gabriel Smith LEAD Technologies Gabe@LEADTOOLS.com 704-372-9681 voice 704-372-8116 fax www.LEADTOOLS.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Sun May 2 02:25:13 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id CAA14436; Sun, 2 May 1999 02:25:12 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id CAA14534 for mpng-list-out-eY3f3Qzu; Sun, 2 May 1999 02:20:37 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.6.53]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id CAA14530 for ; Sun, 2 May 1999 02:20:36 -0500 (CDT) Received: from gerard1 (dc2-isdn995.dial.xs4all.nl [194.109.151.227]) by smtp3.xs4all.nl (8.8.8/8.8.8) with SMTP id JAA18897 for ; Sun, 2 May 1999 09:20:35 +0200 (CEST) Message-Id: <199905020720.JAA18897@smtp3.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@ccrc.wustl.edu Date: Sun, 2 May 1999 09:23:49 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: MNG-PNG Question In-reply-to: <001901be9422$c5021700$1a5c99d1@mrvandy.sound.net> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List > From: "Mike Reed" > Date: Sat, 1 May 1999 17:34:25 -0500 > ..(snip) > > I have had several messages back and forth with Gabe and made sure he knew > how to get his hands on the correct spec. I am personally crossing my > fingers that LeadTools implements great support for MNG. That's good news. You may also tell him that there's plenty of people on the list willing to offer advice on any problems they may encounter during development. On a sidenote; perhaps it's starting to get time for a mpng-implement list? Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Sun May 2 12:42:04 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id MAA21862; Sun, 2 May 1999 12:42:03 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id MAA24967 for mpng-list-out-eY3f3Qzu; Sun, 2 May 1999 12:37:26 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from u29.CS.Berkeley.EDU (u29.CS.Berkeley.EDU [128.32.44.153]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id MAA24963 for ; Sun, 2 May 1999 12:37:24 -0500 (CDT) Received: (from amc@localhost) by u29.CS.Berkeley.EDU (8.8.3/8.8.2) id KAA10344; Sun, 2 May 1999 10:37:22 -0700 (PDT) Date: Sun, 2 May 1999 17:37:22 +0000 From: amc@cs.berkeley.edu (Adam M. Costello) To: MPNG List Subject: Re: MNG-PNG Question Message-ID: <19990502173722.C7376@u29.CS.Berkeley.EDU> References: <001901be9422$c5021700$1a5c99d1@mrvandy.sound.net> <199905020720.JAA18897@smtp3.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199905020720.JAA18897@smtp3.xs4all.nl> Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List "Gerard Juyn" wrote: > On a sidenote; perhaps it's starting to get time for a mpng-implement > list? It looks like we may be heading in that direction, but I recommend waiting until there are a significant number of messages being posted about implementations, and a significant number of people who are interested in MNG but not in those messages. And by the way, we'd have to decide whether we wanted mng-implement (no "p"), for discussions of implementations of MNG, or mpng-implement, for discussions of implementations of all multi-image cousins of PNG. :) AMC -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Sun May 2 13:43:54 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id NAA22587; Sun, 2 May 1999 13:43:53 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id NAA25987 for mpng-list-out-eY3f3Qzu; Sun, 2 May 1999 13:39:28 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.6.53]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id NAA25983 for ; Sun, 2 May 1999 13:39:27 -0500 (CDT) Received: from gerard1 (dc2-isdn885.dial.xs4all.nl [194.109.151.117]) by smtp3.xs4all.nl (8.8.8/8.8.8) with SMTP id UAA27801 for ; Sun, 2 May 1999 20:39:27 +0200 (CEST) Message-Id: <199905021839.UAA27801@smtp3.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@ccrc.wustl.edu Date: Sun, 2 May 1999 20:42:46 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: MNG-PNG Question In-reply-to: <19990502173722.C7376@u29.CS.Berkeley.EDU> References: <199905020720.JAA18897@smtp3.xs4all.nl> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List > Date: Sun, 2 May 1999 17:37:22 +0000 > From: amc@cs.berkeley.edu (Adam M. Costello) Adam, > > On a sidenote; perhaps it's starting to get time for a mpng-implement > > list? > > It looks like we may be heading in that direction, but I recommend > waiting until there are a significant number of messages being posted > about implementations, and a significant number of people who are > interested in MNG but not in those messages. Sure. You're absolutely right. I was just thinking aloud. The current workload on the list doesn't really indicate the need yet to split it up ;-( > discussions of implementations of all multi-image cousins of PNG. :) Are there any others beside MNG ? There was a discussion on multi-spectral image storage, but I think that's "sort of" covered by the proposal for an additional chunk in MNG. And the M in MNG implies multi-image, doesn't it? The argument between MNG-xxxx or MPNG-xxxx can also be extended to MPNG-LIST itself. As a programmer I'd say we'd go for MNG-xxxx, but heck, what do I know..... (And I can see the amount of problems that may cause, unless the list-mechanism can handle dual-naming during a transition phase) Anyway, I don't think it's worth too much work, unless you feel the need. Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Sun May 2 15:01:26 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id PAA23491; Sun, 2 May 1999 15:01:25 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id OAA28115 for mpng-list-out-eY3f3Qzu; Sun, 2 May 1999 14:56:56 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from u29.CS.Berkeley.EDU (u29.CS.Berkeley.EDU [128.32.44.153]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id OAA28111 for ; Sun, 2 May 1999 14:56:55 -0500 (CDT) Received: (from amc@localhost) by u29.CS.Berkeley.EDU (8.8.3/8.8.2) id MAA10885; Sun, 2 May 1999 12:56:54 -0700 (PDT) Date: Sun, 2 May 1999 19:56:53 +0000 From: amc@cs.berkeley.edu (Adam M. Costello) To: MPNG List Subject: Re: MNG-PNG Question Message-ID: <19990502195653.E7376@u29.CS.Berkeley.EDU> References: <199905020720.JAA18897@smtp3.xs4all.nl> <19990502173722.C7376@u29.CS.Berkeley.EDU> <199905021839.UAA27801@smtp3.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199905021839.UAA27801@smtp3.xs4all.nl> Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List "Gerard Juyn" wrote: > > discussions of implementations of all multi-image cousins of PNG. :) > > Are there any others beside MNG ? When mpng-list was created, we hadn't decided what the multi-image format would be called, or exactly what it would do. We discussed a lot of different ideas. Two or three years ago there were two other proposals besides MNG, with working names ARG and DOH. I was maintaining the latter, but got too busy to continue. I was searching for the right balance between versatility and complexity, but I stopped before I found it. Some of the ideas from DOH were incorporated into MNG. If you're curious, the last DOH draft (and companion IDS draft) are available from: http://www.cs.berkeley.edu/~amc/png/ (near the bottom). And of course, all messages ever posted to mpng-list are archived, if you want to go wading through them. :) AMC -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Sun May 2 17:04:03 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id RAA24927; Sun, 2 May 1999 17:04:03 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id QAA03651 for mpng-list-out-eY3f3Qzu; Sun, 2 May 1999 16:59:15 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.6.53]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id QAA03647 for ; Sun, 2 May 1999 16:59:13 -0500 (CDT) Received: from gerard1 (dc2-isdn554.dial.xs4all.nl [194.109.150.42]) by smtp3.xs4all.nl (8.8.8/8.8.8) with SMTP id XAA09416 for ; Sun, 2 May 1999 23:59:12 +0200 (CEST) Message-Id: <199905022159.XAA09416@smtp3.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@ccrc.wustl.edu Date: Mon, 3 May 1999 00:02:34 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: MNG-PNG Question In-reply-to: <19990502195653.E7376@u29.CS.Berkeley.EDU> References: <199905021839.UAA27801@smtp3.xs4all.nl> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List > Date: Sun, 2 May 1999 19:56:53 +0000 > From: amc@cs.berkeley.edu (Adam M. Costello) > When mpng-list was created, we hadn't decided what the multi-image > format would be called, or exactly what it would do. We discussed > a lot of different ideas. Two or three years ago there were two > other proposals besides MNG, with working names ARG and DOH. I was > maintaining the latter, but got too busy to continue. I was searching > for the right balance between versatility and complexity, but I stopped > before I found it. Some of the ideas from DOH were incorporated into > MNG. It seems to me a lot of the ideas (and terminology) of DOH (and IDS) have been incorporated into MNG. And your balance-struggle has come along with it.... :-) I didn't check the archives, but I can actually imagine the original discussions. But as you state yourself this info hasn't been updated for a while. So I guess the question of "more" multi-image cousins of PNG depends on your willingness to pick them up again. IMHO it seems a little late as most of it is already in MNG. Any nice ideas that are not yet incorporated could better be introduced into MNG at some point, than to have another competitor on the side. Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Wed May 5 06:17:58 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id GAA18024; Wed, 5 May 1999 06:17:57 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id GAA28752 for mpng-list-out-eY3f3Qzu; Wed, 5 May 1999 06:12:34 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id GAA28748 for ; Wed, 5 May 1999 06:12:33 -0500 (CDT) Received: from glennrp.netgsi.com (p1-36.netgsi.com [209.150.125.36]) by mail.netgsi.com (Postfix) with SMTP id C1CBA18804 for ; Wed, 05 May 1999 07:11:08 -0400 (EDT) Message-Id: <1.5.4.32.19990505111050.00cc75e4@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, 05 May 1999 07:10:50 -0400 To: mpng-list@ccrc.wustl.edu From: Glenn Randers-Pehrson Subject: MNG-LC-0.95 draft 63 sample files Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List I've made a few MNG-LC files (mostly updated versions of prior examples) and uploaded them to ftp://swrinde.nde.swri.edu/pub/mng/images/ *-LC-d63.mng The usflag-lc-d63.mng example is new; it's a converted GIF that uses the "restore-to-background" disposal method and has a transparent background. Some of them are larger than they need to be because they don't use the global PLTE even though it would be appropriate, they don't necessarily use the most efficient colortypes, and they've got "Software" and other zTXt chunks in each frame. None of that matters for beta work, but don't use it to compare attainable sizes (mngcrush isn't done yet). Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 7 07:53:32 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id HAA05612; Fri, 7 May 1999 07:53:31 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id HAA11509 for mpng-list-out-eY3f3Qzu; Fri, 7 May 1999 07:47:56 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id HAA11505 for ; Fri, 7 May 1999 07:47:55 -0500 (CDT) Received: from glennrp.netgsi.com (p1-36.netgsi.com [209.150.125.36]) by mail.netgsi.com (Postfix) with SMTP id 5EBCA18819; Fri, 07 May 1999 08:47:51 -0400 (EDT) Message-Id: <1.5.4.32.19990507124732.016b8954@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, 07 May 1999 08:47:32 -0400 To: mpng-list@ccrc.wustl.edu From: Glenn Randers-Pehrson Subject: [ANNOUNCE] MNG-LC support in ImageMagick-4.2.4 Cc: cristy@mystic.es.dupont.com Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List ImageMagick version 4.2.4 was released last night. It is based on libpng-1.0.3 and the X Window System, and now includes complete MNG-LC support according to MNG-0.95 draft 63, 19950425. It's copyright but free, and source code is available. Please report any bugs in the MNG support to me with a "cc" to John Cristy Get ImageMagick from ftp://ftp.wizards.dupont.com/pub/ImageMagick or one of its mirrors. Expect frequent updates (the version number only changes approximately monthly, so you need to look at the timestamp of the file when you visit the site; also check the "beta" directory). The ImageMagick "convert" program will convert animated GIFs except for those using "disposal=restore-to-previous" (which also get converted but the "restore" isn't done). Full conversion of those will require a full MNG implementation or some extra work in the encoder to insert extra layers to restore the pixels explicitly (which would result in a MNG-LC file); I haven't decided yet which way to proceed. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Sat May 8 15:34:17 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id PAA03016; Sat, 8 May 1999 15:34:17 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id PAA03201 for mpng-list-out-eY3f3Qzu; Sat, 8 May 1999 15:20:48 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mc-qout4.whowhere.com (mc-qout4.whowhere.com [209.185.123.18]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with SMTP id PAA03197 for ; Sat, 8 May 1999 15:20:46 -0500 (CDT) Received: from Unknown/Local ([?.?.?.?]) by my-dejanews.com; Sat May 8 13:20:40 1999 To: "MPNG List" Date: Sat, 08 May 1999 13:20:40 -0700 From: "Richard W. Franzen" Message-ID: Mime-Version: 1.0 X-Sent-Mail: on X-Mailer: MailCity Service Subject: Re: VOTE on MNG-0.95 (YES) X-Sender-Ip: 12.77.194.189 Organization: Deja News Mail (http://www.my-dejanews.com:80) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List YES MNG-0.95 19990425 ftp://swrinde.nde.swri.edu/pub/mng/documents/mng-0.95-19990425-pdg.html Rich Franzen -- -- Rich -- http://home.att.net/~rocq/pngBase.html -- -----== Sent via Deja News, The Discussion Network ==----- http://www.dejanews.com/ Easy access to 50,000+ discussion forums -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Sun May 9 10:41:50 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id KAA17348; Sun, 9 May 1999 10:41:49 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id KAA24210 for mpng-list-out-eY3f3Qzu; Sun, 9 May 1999 10:33:16 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id KAA24206 for ; Sun, 9 May 1999 10:33:11 -0500 (CDT) Received: from w3.org (root@localhost [127.0.0.1]) by tux.w3.org (8.8.7/8.8.7) with ESMTP id LAA04052; Sun, 9 May 1999 11:33:04 -0400 Message-ID: <3735A946.12C6F98D@w3.org> Date: Sun, 09 May 1999 17:27:02 +0200 From: Chris Lilley X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpng-list@ccrc.wustl.edu Subject: VOTE on MNG-0.95 (YES) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List YES MNG-0.95 19990425 ftp://swrinde.nde.swri.edu/pub/mng/documents/ mng-0.95-19990425-pdg.html Chris Lilley sorry - was travelling, limited and intermittent connectivity. -- Chris -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Thu May 13 07:38:40 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id HAA08290; Thu, 13 May 1999 07:38:39 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id HAA14542 for mpng-list-out-eY3f3Qzu; Thu, 13 May 1999 07:32:52 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id HAA14534 for ; Thu, 13 May 1999 07:32:49 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id NAA23757 for ; Thu, 13 May 1999 13:32:40 +0100 (BST) Date: Thu, 13 May 1999 13:31:46 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Looping forever Message-ID: X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List What is the correct "Iteration max" for a TERM chunk to specify loop forever? I assume 0x7FFFFFFF, but I note that ImageMagick converts a GIF that loops forever to a MNG with "Iteration max"=0. -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Thu May 13 10:24:49 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id KAA11004; Thu, 13 May 1999 10:24:48 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id KAA17916 for mpng-list-out-eY3f3Qzu; Thu, 13 May 1999 10:20:24 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id KAA17909 for ; Thu, 13 May 1999 10:20:21 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id QAA25679 for ; Thu, 13 May 1999 16:20:19 +0100 (BST) Date: Thu, 13 May 1999 16:19:33 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: CLON showing an image Message-ID: <2329e149%kbracey@kbracey.acorn.co.uk> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List Section 4.3.5 says "the CLON chunk need not be followed by a SHOW chunk, if do_not_show=0 in the CLON chunk," but section 4.3.2 fails to list decoding a CLON chunk as an event that can trigger the display of an image. Is it section 4.3.2 that is in error? -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Thu May 13 10:40:10 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id KAA11281; Thu, 13 May 1999 10:40:10 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id KAA18394 for mpng-list-out-eY3f3Qzu; Thu, 13 May 1999 10:35:37 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id KAA18390 for ; Thu, 13 May 1999 10:35:35 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id QAA25784 for ; Thu, 13 May 1999 16:35:33 +0100 (BST) Date: Thu, 13 May 1999 16:34:44 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Framing mode 1 and varying delays Message-ID: X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List I'm having trouble getting to grips with frame delays, and when they happen. All the examples I've seen imply that to display one image for 1 tick, then a second image for 2 ticks, you should write FRAM 1 "" 2 0 0 0 1 FRAM 1 "" 2 0 0 0 2 However, 4.3.2 seems to say that frame delays occur before each image, and that "when the decoder is ready to perform a display update, it must check the framing mode, to decide ... whether it needs to wait for the interframe delay to elapse before continuing." This seems to clearly say that the framing mode in the FRAM chunk applies to the next image, but the examples show that the delay needs to apply to the image _after_ the next image. In this example, when the decoder is about to display the second image, it has to know to wait for 1 tick, not the 2 ticks that it saw in the last FRAM chunk. Help! -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Thu May 13 14:02:52 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id OAA14728; Thu, 13 May 1999 14:02:51 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id NAA22585 for mpng-list-out-eY3f3Qzu; Thu, 13 May 1999 13:58:22 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id NAA22581 for ; Thu, 13 May 1999 13:58:19 -0500 (CDT) Received: from gerard1 (dc2-isdn877.dial.xs4all.nl [194.109.151.109]) by smtp1.xs4all.nl (8.8.8/8.8.8) with SMTP id UAA23708 for ; Thu, 13 May 1999 20:58:18 +0200 (CEST) Message-Id: <199905131858.UAA23708@smtp1.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@ccrc.wustl.edu Date: Thu, 13 May 1999 21:01:22 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: CLON showing an image In-reply-to: <2329e149%kbracey@kbracey.acorn.co.uk> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List > Date: Thu, 13 May 1999 16:19:33 +0100 > From: Kevin Bracey Hi Kevin, > Section 4.3.5 says "the CLON chunk need not be followed by a SHOW chunk, > if do_not_show=0 in the CLON chunk," but section 4.3.2 fails to list > decoding a CLON chunk as an event that can trigger the display of an image. > > Is it section 4.3.2 that is in error? No. In my opinion the remark should be scratched from 4.3.5. It's the only place listing this decoding behavior. It's not just 4.3.2 that misses this. Other parts of the doc also explain when a decoder is supposed to display an object. Anyway, MNGeye doesn't display the object after it's CLON'ed, even when do_not_show=0. > What is the correct "Iteration max" for a TERM chunk to specify loop > forever? I assume 0x7FFFFFFF, but I note that ImageMagick converts a > GIF that loops forever to a MNG with "Iteration max"=0. It's 0x7FFFFFFF for the iteration_max in a LOOP. It's a good assumption that's the same for TERM, although the spec should mention it. > I'm having trouble getting to grips with frame delays, and when they > happen. All the examples I've seen imply that to display one image > for 1 tick, then a second image for 2 ticks, you should write > ...(snip)... > This seems to clearly say that the framing mode in the FRAM chunk > applies to the next image, but the examples show that the delay > needs to apply to the image _after_ the next image. In this example, > when the decoder is about to display the second image, it has to > know to wait for 1 tick, not the 2 ticks that it saw in the last > FRAM chunk. What the spec is trying to say is that the delay of 1 sec. should be between the start of displaying the first image until the start of displaying the second, unless you invent a system that can display an image in 0.0 seconds. It doesn't exactly sound like that though. We've been discussing this quite a lot in the recent past. And I guess it's still not clear enough. What I've done in MNGeye is to use a Windows timer. I set it just before I start displaying an image, and I delay processing after displaying the image, until the timer gives an alert. Hope this help a bit. Regards, Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Thu May 13 22:13:30 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id WAA21124; Thu, 13 May 1999 22:13:29 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id WAA02356 for mpng-list-out-eY3f3Qzu; Thu, 13 May 1999 22:13:13 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id WAA02352 for ; Thu, 13 May 1999 22:13:12 -0500 (CDT) Received: from glennrp.netgsi.com (p1-44.netgsi.com [209.150.125.44]) by mail.netgsi.com (Postfix) with SMTP id B17C618823 for ; Thu, 13 May 1999 23:13:10 -0400 (EDT) Message-Id: <1.5.4.32.19990514031249.016df6c4@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, 13 May 1999 23:12:49 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: Framing mode 1 and varying delays Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 04:34 PM 5/13/99 +0100, you wrote: >I'm having trouble getting to grips with frame delays, and when they >happen. All the examples I've seen imply that to display one image for 1 >tick, then a second image for 2 ticks, you should write > > FRAM 1 "" 2 0 0 0 1 > > FRAM 1 "" 2 0 0 0 2 > Right. > >However, 4.3.2 seems to say that frame delays occur before each image, and >that "when the decoder is ready to perform a display update, it must check >the framing mode, to decide ... whether it needs to wait for the interframe >delay to elapse before continuing." > >This seems to clearly say that the framing mode in the FRAM chunk applies to >the next image, but the examples show that the delay needs to apply to the >image _after_ the next image. In this example, when the decoder is about to >display the second image, it has to know to wait for 1 tick, not the 2 ticks >that it saw in the last FRAM chunk. Right. # IFD is unspecified at this point (let's say it's 5) FRAM 1 "" 2 0 0 0 1 # wait for 5 ticks to elapse, set IFD=1 FRAM 1 "" 2 0 0 0 2 # wait for 1 tick, set IFD=2 # wait for 2 ticks Thus, whatever was on screen before the first image will be displayed for 5 ticks, then the first image for 1 tick, then the second for two ticks, then whatever follows. You can think of it as a "duration" instead of a "delay" if you like. It is the amount of time you want the _next_ image to endure, and it is the amount of time to delay before starting the image _after_ the next image. An easier-to-understand way, which I think we considered at one point, would be to put the duration information after the image data: DURA 1 DUR 2 but we rejected that because a slow decoder would be receiving the timing information too late to act upon it. With the FRAM method, it knows how long it's got, and could for example only show the first several passes of an Adam7 interlacing and then bail out and go on to the next image, when it recognizes that it hasn't enough time to make a full-resolution display before the allotted time will have elapsed. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Thu May 13 22:18:54 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id WAA21183; Thu, 13 May 1999 22:18:53 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id WAA02534 for mpng-list-out-eY3f3Qzu; Thu, 13 May 1999 22:18:51 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id WAA02528 for ; Thu, 13 May 1999 22:18:50 -0500 (CDT) Received: from glennrp.netgsi.com (p1-44.netgsi.com [209.150.125.44]) by mail.netgsi.com (Postfix) with SMTP id 929DD18823 for ; Thu, 13 May 1999 23:18:48 -0400 (EDT) Message-Id: <1.5.4.32.19990514031828.016dbcfc@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, 13 May 1999 23:18:28 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: CLON showing an image Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 04:19 PM 5/13/99 +0100, you wrote: >Section 4.3.5 says "the CLON chunk need not be followed by a SHOW chunk, >if do_not_show=0 in the CLON chunk," but section 4.3.2 fails to list >decoding a CLON chunk as an event that can trigger the display of an image. > >Is it section 4.3.2 that is in error? Yes, CLON should be included in the list. The events listed are those which, when expanded, are the equivalent of explicitly embedding an image in the datastream. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Thu May 13 22:56:28 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id WAA21620; Thu, 13 May 1999 22:56:27 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id WAA03371 for mpng-list-out-eY3f3Qzu; Thu, 13 May 1999 22:56:24 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id WAA03367 for ; Thu, 13 May 1999 22:56:23 -0500 (CDT) Received: from glennrp.netgsi.com (p1-44.netgsi.com [209.150.125.44]) by mail.netgsi.com (Postfix) with SMTP id 40A9C18823 for ; Thu, 13 May 1999 23:56:02 -0400 (EDT) Message-Id: <1.5.4.32.19990514035541.016d4690@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, 13 May 1999 23:55:41 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: Looping forever Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 01:31 PM 5/13/99 +0100, you wrote: >What is the correct "Iteration max" for a TERM chunk to specify loop >forever? I assume 0x7FFFFFFF, but I note that ImageMagick converts a GIF >that loops forever to a MNG with "Iteration max"=0. It should be 0x7FFFFFFF. I'll fix that in my next patch to ImageMagick which I haven't uploaded it yet because I'm having some unrelated problems with understanding the linked-list mechanism in ImageMagick. (The next patch includes LOOP, CLIP, and MOVE, which seems to be a useful subset beyond MNG-LC but short of full MNG; after that I'll tackle the PAST chunk). BTW, is the NETSCAPE encoding of "loops forever" documented anywhere? I have several books but they all say you can specify the number of loops to be none, forever, or a specific number. None of them actually come out and say what is the encoding of "forever" but I am guessing it is 0; however IANAGG (I am not a GIF guru). It's not easy to tell if ImageMagick is decoding it properly because it always loops all animations forever. But upon examining the code, I think it interprets "NETSCAPE LOOP iterations=0" to mean "do not loop". Also appears to interpret *any* application extension as a NETSCAPE LOOP extension, so I'll fix that as well. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 14 00:10:49 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id AAA22483; Fri, 14 May 1999 00:10:49 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id AAA04741 for mpng-list-out-eY3f3Qzu; Fri, 14 May 1999 00:10:44 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from u29.CS.Berkeley.EDU (u29.CS.Berkeley.EDU [128.32.44.153]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id AAA04737 for ; Fri, 14 May 1999 00:10:41 -0500 (CDT) Received: (from amc@localhost) by u29.CS.Berkeley.EDU (8.8.3/8.8.2) id WAA14261; Thu, 13 May 1999 22:10:39 -0700 (PDT) Date: Fri, 14 May 1999 05:10:38 +0000 From: amc@cs.berkeley.edu (Adam M. Costello) To: MPNG List Subject: Re: Looping forever Message-ID: <19990514051038.B12028@u29.CS.Berkeley.EDU> References: <1.5.4.32.19990514035541.016d4690@netgsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <1.5.4.32.19990514035541.016d4690@netgsi.com> Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List Glenn Randers-Pehrson wrote: > BTW, is the NETSCAPE encoding of "loops forever" documented anywhere? I've never seen any official documentation, but here's one source that says 0 means loop forever: Taken from http://www.ctr.columbia.edu/~dzhong/mr_report.html It would be silly for 0 to mean do not loop, because that's what 1 means. AMC -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 14 00:18:02 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id AAA22575; Fri, 14 May 1999 00:18:01 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id AAA04914 for mpng-list-out-eY3f3Qzu; Fri, 14 May 1999 00:17:58 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id AAA04910 for ; Fri, 14 May 1999 00:17:57 -0500 (CDT) Received: from glennrp.netgsi.com (p1-44.netgsi.com [209.150.125.44]) by mail.netgsi.com (Postfix) with SMTP id D96371882D for ; Fri, 14 May 1999 01:17:54 -0400 (EDT) Message-Id: <1.5.4.32.19990514051733.016da22c@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, 14 May 1999 01:17:33 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: CLON showing an image Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 09:01 PM 5/13/99 +0100, Gerard wrote: >> Section 4.3.5 says "the CLON chunk need not be followed by a SHOW chunk, >> if do_not_show=0 in the CLON chunk," but section 4.3.2 fails to list >> decoding a CLON chunk as an event that can trigger the display of an image. >> >> Is it section 4.3.2 that is in error? > >No. In my opinion the remark should be scratched from 4.3.5. It's the >only place listing this decoding behavior. It's not just 4.3.2 that >misses this. Other parts of the doc also explain when a decoder is >supposed to display an object. The statement in 4.3.5 is explicit and is what I intended. Otherwise we wouldn't have needed the "do_not_show" field in the CLON chunk. To delete the statement would be to change the spec. CLON should be treated the same way as the rest of the "shorthand" ways of embedding an image. Agreed, it's omitted from various other places, and those need to be fixed/clarified: In the introduction, Layer definitions, A layer is ... -An image that is generated in reponse to a SHOW *or CLON* directive. In the terminology, layer, A layer can be ... in response to a SHOW *or CLON* directive,... In 3.2, Object Attributes, Potential visibility, "on-the-fly" as it is being decoded *or cloned* In 4.2.6, CLON specification, add "The resulting image is displayed immediately if its "do_not_show" flag is zero." In 4.3.2, FRAM specification, events that trigger a display, Decoding a SHOW *or CLON* chunk, when it.... In Example 6, change "CLON 1 2 0 0 1" to "CLON 1 2 0 1 0" and add "SHOW 2 2 3" after the CLON chunk. In Example 7, change "CLON 2 3 0 0 1" to "CLON 2 3 0 1 0" In Example 9, change "CLON 1 2 1" to "CLON 1 2" (In Examples 6 and 7, the "abstract/concrete" flag is botched, too, due to a change in the CLON spec a while ago that didn't get reflected in the examples). Examples 4 and 11 seem to be using CLON correctly and don't depend on the interpretation of do_not_show; in Example 4 the objects are invisible, and in Example 11 they are offscreen. >Anyway, MNGeye doesn't display the object after it's CLON'ed, even >when do_not_show=0. ARL viewpng would display it. But the clondemo.mng sample file has do_not_show=1 for all of its clones, so it doesn't really test the feature. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 14 01:20:34 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id BAA23446; Fri, 14 May 1999 01:20:33 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id BAA05921 for mpng-list-out-eY3f3Qzu; Fri, 14 May 1999 01:20:27 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id BAA05917 for ; Fri, 14 May 1999 01:20:26 -0500 (CDT) Received: from gerard1 (dc2-isdn515.dial.xs4all.nl [194.109.150.3]) by smtp1.xs4all.nl (8.8.8/8.8.8) with SMTP id IAA11577 for ; Fri, 14 May 1999 08:20:26 +0200 (CEST) Message-Id: <199905140620.IAA11577@smtp1.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@ccrc.wustl.edu Date: Fri, 14 May 1999 08:23:36 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: CLON showing an image In-reply-to: <1.5.4.32.19990514051733.016da22c@netgsi.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List > Date: Fri, 14 May 1999 01:17:33 -0400 > From: Glenn Randers-Pehrson > >No. In my opinion the remark should be scratched from 4.3.5. It's the > >only place listing this decoding behavior. It's not just 4.3.2 that > >misses this. Other parts of the doc also explain when a decoder is > >supposed to display an object. > > The statement in 4.3.5 is explicit and is what I intended. Otherwise > we wouldn't have needed the "do_not_show" field in the CLON chunk. > To delete the statement would be to change the spec. CLON should > be treated the same way as the rest of the "shorthand" ways of > embedding an image. > ... (snip) ... Oke. The directive missing from the CLON description in 4.2.6 was the incentive for me. As was fixing one spot against quite a few. But you make your point that it's actually a feature, and more in line with SHOW. > >Anyway, MNGeye doesn't display the object after it's CLON'ed, even > >when do_not_show=0. > > ARL viewpng would display it. But the clondemo.mng sample file > has do_not_show=1 for all of its clones, so it doesn't really test > the feature. I'll fix MNGeye then. Still working on the next version, and it's not a hard thing to fix. Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 14 03:57:37 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id DAA25859; Fri, 14 May 1999 03:57:36 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id DAA08598 for mpng-list-out-eY3f3Qzu; Fri, 14 May 1999 03:57:25 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id DAA08594 for ; Fri, 14 May 1999 03:57:23 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id JAA03558 for ; Fri, 14 May 1999 09:57:22 +0100 (BST) Date: Fri, 14 May 1999 09:56:19 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Re: Looping forever Message-ID: In-Reply-To: <1.5.4.32.19990514035541.016d4690@netgsi.com> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List In message <1.5.4.32.19990514035541.016d4690@netgsi.com> Glenn Randers-Pehrson wrote: > > BTW, is the NETSCAPE encoding of "loops forever" documented anywhere? > I have several books but they all say you can specify the number of > loops to be none, forever, or a specific number. None of them actually > come out and say what is the encoding of "forever" but I am guessing > it is 0; however IANAGG (I am not a GIF guru). > I did once find the official Netscape document when I was working on Browse, but I'm buggered if I can find it now. Basically, the first byte of the subblock says whether it loops (0 = no, 1 = yes), and the second two bytes say how many times to repeat it (0 = infinite). Note that this means that if it says "NETSCAPE 2.0 1 3" it will play four times, not three times. By the way, it seems strange that the MNG spec is so wishy-washy over whether TERM support is required, while it is the only way to loop an animation in MNG-LC or MNG-VLC, so it is arguably a more fundamental chunk than LOOP. Presumably this is because general TERM support requires implementation of random access to SEEK. -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 14 04:36:51 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id EAA26236; Fri, 14 May 1999 04:36:50 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id EAA09668 for mpng-list-out-eY3f3Qzu; Fri, 14 May 1999 04:36:46 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id EAA09664 for ; Fri, 14 May 1999 04:36:44 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id KAA03999 for ; Fri, 14 May 1999 10:36:43 +0100 (BST) Date: Fri, 14 May 1999 10:35:45 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Re: Framing mode 1 and varying delays Message-ID: <7a8e2249%kbracey@kbracey.acorn.co.uk> In-Reply-To: <1.5.4.32.19990514031249.016df6c4@netgsi.com> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List In message <1.5.4.32.19990514031249.016df6c4@netgsi.com> Glenn Randers-Pehrson wrote: > > # IFD is unspecified at this point (let's say it's 5) > FRAM 1 "" 2 0 0 0 1 > # wait for 5 ticks to elapse, set IFD=1 > > FRAM 1 "" 2 0 0 0 2 > # wait for 1 tick, set IFD=2 > > # wait for 2 ticks > > > Thus, whatever was on screen before the first image will be displayed > for 5 ticks, then the first image for 1 tick, then the second for > two ticks, then whatever follows. > > You can think of it as a "duration" instead of a "delay" if you like. > It is the amount of time you want the _next_ image to endure, and it > is the amount of time to delay before starting the image _after_ the > next image. > Okay, I think I've got it. The FRAM chunk says "here's how you tell when _this_ frame ends, and here's how long the _next_ frame needs to be displayed for". -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 14 07:26:20 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id HAA27666; Fri, 14 May 1999 07:26:19 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id HAA12447 for mpng-list-out-eY3f3Qzu; Fri, 14 May 1999 07:26:13 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id HAA12443 for ; Fri, 14 May 1999 07:26:12 -0500 (CDT) Received: from glennrp.netgsi.com (p1-35.netgsi.com [209.150.125.35]) by mail.netgsi.com (Postfix) with SMTP id AF7EE1881A for ; Fri, 14 May 1999 08:26:11 -0400 (EDT) Message-Id: <1.5.4.32.19990514122550.016d9598@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, 14 May 1999 08:25:50 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: Looping forever Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 09:56 AM 5/14/99 +0100, you wrote: >I did once find the official Netscape document when I was working on >Browse, but I'm buggered if I can find it now. > >Basically, the first byte of the subblock says whether it loops (0 = no, >1 = yes), and the second two bytes say how many times to repeat it >(0 = infinite). Note that this means that if it says "NETSCAPE 2.0 1 3" >it will play four times, not three times. TERM 3 100 3 should also play 4 times because the field means "number of times to repeat". Repeating 1 time means to play the animation once and repeat it once. That's why we don't use 1 to mean "no loop". That's different from LOOP, where repeat_count=1 means play the loop once. "Repeat_count" is a misnomer in the LOOP chunk spec and should really be called "nominal_iteration_count" or something. > >By the way, it seems strange that the MNG spec is so wishy-washy over >whether TERM support is required, while it is the only way to loop an >animation in MNG-LC or MNG-VLC, so it is arguably a more fundamental >chunk than LOOP. MNG isn't just for animations. TERM is less "fundamental" than LOOP because it's never used to construct a frame, so you can always get a proper display of all the frames while ignoring TERM. So TERM is always ignorable. But certainly a GIF to MNG converter needs to translate the NETSCAPE LOOP into TERM, and MNG editors need to preserve TERM. >Presumably this is because general TERM support requires >implementation of random access to SEEK. Partly for that reason, but also because TERM was designed to be safely ignorable. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 14 09:21:58 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id JAA29188; Fri, 14 May 1999 09:21:58 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id JAA14442 for mpng-list-out-eY3f3Qzu; Fri, 14 May 1999 09:21:11 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id JAA14438 for ; Fri, 14 May 1999 09:20:57 -0500 (CDT) 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 KAA15100 for ; Fri, 14 May 1999 10:20:57 -0400 (EDT) To: MPNG List Subject: Re: Framing mode 1 and varying delays In-reply-to: Your message of Thu, 13 May 1999 23:12:49 -0400 <1.5.4.32.19990514031249.016df6c4@netgsi.com> Date: Fri, 14 May 1999 10:20:56 -0400 Message-ID: <15098.926691656@sss.pgh.pa.us> From: Tom Lane Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List Glenn Randers-Pehrson writes: > ... we rejected that because a slow decoder would be receiving the > timing information too late to act upon it. With the FRAM method, > it knows how long it's got, and could for example only show the first > several passes of an Adam7 interlacing and then bail out and go on > to the next image, when it recognizes that it hasn't enough time > to make a full-resolution display before the allotted time will > have elapsed. Perhaps this reasoning should be mentioned in the rationale? It would help people internalize which delay goes into which FRAM. regards, tom lane -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 14 09:34:02 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id JAA29380; Fri, 14 May 1999 09:34:02 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id JAA14570 for mpng-list-out-eY3f3Qzu; Fri, 14 May 1999 09:29:39 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id JAA14566 for ; Fri, 14 May 1999 09:29:32 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id PAA08564 for ; Fri, 14 May 1999 15:27:02 +0100 (BST) Date: Fri, 14 May 1999 15:26:41 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: MOVE/CLIP frozen objects Message-ID: <2a311d249%kbracey@kbracey.acorn.co.uk> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List Is the correct response to an attempt to MOVE or CLIP a frozen object to ignore it? The semantics of MOVE and CLIP would imply that it shouldn't be an error. -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 14 10:08:47 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id KAA00004; Fri, 14 May 1999 10:08:46 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id KAA15317 for mpng-list-out-eY3f3Qzu; Fri, 14 May 1999 10:08:42 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id KAA15313 for ; Fri, 14 May 1999 10:08:41 -0500 (CDT) Received: from glennrp.netgsi.com (p1-35.netgsi.com [209.150.125.35]) by mail.netgsi.com (Postfix) with SMTP id 2D79118803 for ; Fri, 14 May 1999 11:08:36 -0400 (EDT) Message-Id: <1.5.4.32.19990514150819.016df69c@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, 14 May 1999 11:08:19 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MOVE/CLIP frozen objects Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 03:26 PM 5/14/99 +0100, Kevin wrote: >Is the correct response to an attempt to MOVE or CLIP a frozen object to >ignore it? The semantics of MOVE and CLIP would imply that it shouldn't be an >error. A frozen object is one whose object attributes set [which includes the location and clipping info] and whose object buffer are not allowed to be discarded, replaced, or modified. Authors can make a clone of the frozen object and then move that around to their heart's content. Decoders can however MOVE or CLIP a nonfrozen object even when its object buffer is frozen. The question of whether to treat the attempt as an error or to simply ignore it is a good one, and the spec is ambiguous about it. I think it would make more sense to treat them the same way as nonexistent objects in the range, namely to ignore the attempt without raising a fuss. The spec could be reworded It is not an error for the CLIP [MOVE] chunk to name a frozen object or an object that has not previously been defined. In such cases, nothing is done to the object. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 14 10:17:35 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id KAA00167; Fri, 14 May 1999 10:17:34 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id KAA15396 for mpng-list-out-eY3f3Qzu; Fri, 14 May 1999 10:17:26 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id KAA15392 for ; Fri, 14 May 1999 10:17:24 -0500 (CDT) Received: from glennrp.netgsi.com (p1-35.netgsi.com [209.150.125.35]) by mail.netgsi.com (Postfix) with SMTP id 3DA3518810 for ; Fri, 14 May 1999 11:16:55 -0400 (EDT) Message-Id: <1.5.4.32.19990514151635.016d6288@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, 14 May 1999 11:16:35 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MOVE/CLIP frozen objects Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 03:26 PM 5/14/99 +0100, you wrote: >Is the correct response to an attempt to MOVE or CLIP a frozen object to >ignore it? The semantics of MOVE and CLIP would imply that it shouldn't be an >error. By the way, for ImageMagick, I had written code a couple of days ago to ignore the attempt. For ARL Viewpng, I had written code over 2 years ago to treat such an attempt as an error, but that was before the MOVE/CLIP syntax had been expanded to operate on a range of objects rather than a single object. With the range-of-objects syntax, it makes more sense to allow ignorable objects (frozen or undefined) within the range. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 14 10:21:51 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id KAA00252; Fri, 14 May 1999 10:21:51 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id KAA15534 for mpng-list-out-eY3f3Qzu; Fri, 14 May 1999 10:21:46 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from echo.sound.net ([205.242.192.21]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with SMTP id KAA15530 for ; Fri, 14 May 1999 10:21:45 -0500 (CDT) Received: (qmail 112 invoked from network); 14 May 1999 15:00:54 -0000 Received: from mrvandy.unlimitedpotential.com (HELO mrvandy) (209.153.92.26) by echo.sound.net with SMTP; 14 May 1999 15:00:54 -0000 Message-ID: <004101be9e1d$73fc3020$1a5c99d1@sound.net> From: "Mike Reed" To: "MPNG List" Subject: Is MNG frozen? Date: Fri, 14 May 1999 10:21:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0810.800 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List Is MNG officially frozen now? Seems the voting was all Yes and a couple Abstains. Just looking for official word and for the spec to be renamed to 1.0. Mike Reed Director of Research and Development Unlimited Potential, Inc. All Minds Network Project http://www.allminds.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 14 10:46:51 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id KAA00609; Fri, 14 May 1999 10:46:50 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id KAA15933 for mpng-list-out-eY3f3Qzu; Fri, 14 May 1999 10:46:33 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id KAA15929 for ; Fri, 14 May 1999 10:46:30 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id QAA09538 for ; Fri, 14 May 1999 16:46:28 +0100 (BST) Date: Fri, 14 May 1999 16:45:27 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: SHOW a frozen object Message-ID: <496724249%kbracey@kbracey.acorn.co.uk> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List Yes, me again. What about SHOWing a frozen object? For show modes 0 to 5, the correct behaviour would appear to be to ignore any attempts to change do_not_show for a frozen object, and to display the image (or not) on the basis of the unmodified flag. In other words, act as if show_mode was 2 for any frozen images encountered. For modes 6 and 7, behaviour seems somewhat harder to specify, particularly when there are frozen images in the cycle with do_not_show = 0, which would seem to force the display of more than one layer. Sorry to start stirring things up after the spec is frozen, but it was only the freeze that actually induced me to start a serious attempt to implement it :( -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 14 11:14:22 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id LAA01046; Fri, 14 May 1999 11:14:21 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id LAA16422 for mpng-list-out-eY3f3Qzu; Fri, 14 May 1999 11:14:18 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA16418 for ; Fri, 14 May 1999 11:14:17 -0500 (CDT) Received: from glennrp.netgsi.com (p1-35.netgsi.com [209.150.125.35]) by mail.netgsi.com (Postfix) with SMTP id 2829118804 for ; Fri, 14 May 1999 12:14:16 -0400 (EDT) Message-Id: <1.5.4.32.19990514161356.016d4778@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, 14 May 1999 12:13:56 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: Is MNG frozen? Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 10:21 AM 5/14/99 -0500, you wrote: >Is MNG officially frozen now? Seems the voting was all Yes and a couple >Abstains. Just looking for official word and for the spec to be renamed to >1.0. Yes, the vote on the design freeze passed by about 12 affirmative, no negative, one abstain, and one ineligible affirmative vote. We'll call it 1.0 once some beta implementation is done. Hopefully not in the too far distant future. MNG-LC and MNG-VLC worked out OK in ImageMagick, but I'm still working on upgrading to full MNG. I hope some others have started work on independent implementations so we can iron out any remaining ambiguities. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 14 11:56:45 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id LAA01725; Fri, 14 May 1999 11:56:44 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id LAA17238 for mpng-list-out-eY3f3Qzu; Fri, 14 May 1999 11:56:35 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA17234 for ; Fri, 14 May 1999 11:56:21 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id RAA10733 for ; Fri, 14 May 1999 17:56:18 +0100 (BST) Date: Fri, 14 May 1999 17:55:10 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: DEFI followed by MOVE Message-ID: <43c92a249%kbracey@kbracey.acorn.co.uk> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List The penultimate paragraph of 4.2.1 seems to be somewhat confused between the set of attributes that forms the default attribute set for subsequent embedded images, and the attribute sets of already defined images. It appears to say that MOVE, CLIP and SHOW can change the default attribute set, but this is surely not the case. Or is it that the default attribute set is not stored separately as such, but is the current attribute set of the last embedded object? Thus in DEFI 2 SHOW 3 MOVE 2 by 200,0 MOVE 3 by 100,0 SHOW 3 the second embedded image would replace the first embedded image, and would be 200 pixels to the right, not in the original position. Actually, that description can't be quite right as image 2 wouldn't come into existence at the DEFI chunk, but at the subsequent embedded image. Hence the current DEFI values must be stored separately until the object comes into existence. Hmm. -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 14 14:00:07 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id OAA03564; Fri, 14 May 1999 14:00:06 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id NAA19713 for mpng-list-out-eY3f3Qzu; Fri, 14 May 1999 13:59:46 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id NAA19709 for ; Fri, 14 May 1999 13:59:45 -0500 (CDT) Received: from glennrp.netgsi.com (p1-35.netgsi.com [209.150.125.35]) by mail.netgsi.com (Postfix) with SMTP id 442A318802 for ; Fri, 14 May 1999 14:59:43 -0400 (EDT) Message-Id: <1.5.4.32.19990514185923.016d6678@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, 14 May 1999 14:59:23 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: DEFI followed by MOVE Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 05:55 PM 5/14/99 +0100, you wrote: >The penultimate paragraph of 4.2.1 seems to be somewhat confused between >the set of attributes that forms the default attribute set for subsequent >embedded images, and the attribute sets of already defined images. > >It appears to say that MOVE, CLIP and SHOW can change the default attribute >set, but this is surely not the case. > >Or is it that the default attribute set is not stored separately as such, but >is the current attribute set of the last embedded object? Yes. The default set is used to restore object 0 after its IEND, and to restore other objects when SEEK or DISC occurs. > >Thus in > DEFI 2 > > SHOW 3 > MOVE 2 by 200,0 > MOVE 3 by 100,0 > > SHOW 3 > >the second embedded image would replace the first embedded image, and >would be 200 pixels to the right, not in the original position. Yes, and it would have object_id 2. > >Actually, that description can't be quite right as image 2 wouldn't come >into existence at the DEFI chunk, but at the subsequent embedded >image. Hence the current DEFI values must be stored separately until the >object comes into existence. You can store them in the regular place, but avoid applying deltas to them until the object comes into existence. It already exists, and has the pixels from the first embedded image. But the following wouldn't work DEFI 2 DEFI 3 MOVE 3 by 100,0 The MOVE 3 chunk should be ignored, because no object 3 exists (even if it had existed before this point in the datastream, it would be destroyed by the DEFI 3 chunk). I'm not sure why this needs to be so, but that's what is written in the spec. It might be a little nicer not to have that restriction, so both of these would work, although the move-after-embedded-image version (which works) looks a little cleaner than the move-before-embedded image (which doesn't). DEFI 1 LOOP MOVE 1 delta x,y # does not work CLIP 1 delta L,R,T,B ENDL DEFI 1 LOOP MOVE 1 delta x,y # works CLIP 1 delta L,R,T,B >Hmm. Hmmm. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 14 14:32:46 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id OAA03987; Fri, 14 May 1999 14:32:46 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id OAA20282 for mpng-list-out-eY3f3Qzu; Fri, 14 May 1999 14:32:42 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id OAA20278 for ; Fri, 14 May 1999 14:32:41 -0500 (CDT) Received: from glennrp.netgsi.com (p1-35.netgsi.com [209.150.125.35]) by mail.netgsi.com (Postfix) with SMTP id C6B0D18802 for ; Fri, 14 May 1999 15:32:40 -0400 (EDT) Message-Id: <1.5.4.32.19990514193220.016eb114@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, 14 May 1999 15:32:20 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: SHOW a frozen object Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 04:45 PM 5/14/99 +0100, you wrote: >Yes, me again. > >What about SHOWing a frozen object? For show modes 0 to 5, the correct >behaviour would appear to be to ignore any attempts to change do_not_show for >a frozen object, and to display the image (or not) on the basis of the >unmodified flag. In other words, act as if show_mode was 2 for any frozen >images encountered. That looks right. > >For modes 6 and 7, behaviour seems somewhat harder to specify, particularly >when there are frozen images in the cycle with do_not_show = 0, which would >seem to force the display of more than one layer. Clearly these modes are meant to be used with nonfrozen objects, but we do need to say what happens when there are frozen objects in the cycle. A reasonable, deterministic way of handling it would be to search for the "next object that exists, is viewable, and is not frozen", and emit a single layer containing that object. There's little extra coding involved; in the construction of a reduced working set of objects you eliminate all frozen objects along with the non-existent and non-viewable ones. > >Sorry to start stirring things up after the spec is frozen, but it was >only the freeze that actually induced me to start a serious attempt to >implement it :( That's OK. I'm glad to see you putting in the effort. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 14 15:23:23 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id PAA04722; Fri, 14 May 1999 15:23:23 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id PAA21447 for mpng-list-out-eY3f3Qzu; Fri, 14 May 1999 15:23:17 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from u29.CS.Berkeley.EDU (u29.CS.Berkeley.EDU [128.32.44.153]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id PAA21443 for ; Fri, 14 May 1999 15:23:14 -0500 (CDT) Received: (from amc@localhost) by u29.CS.Berkeley.EDU (8.8.3/8.8.2) id NAA16256; Fri, 14 May 1999 13:23:12 -0700 (PDT) Date: Fri, 14 May 1999 20:23:11 +0000 From: amc@cs.berkeley.edu (Adam M. Costello) To: MPNG List Subject: Re: Framing mode 1 and varying delays Message-ID: <19990514202310.A16012@u29.CS.Berkeley.EDU> References: <1.5.4.32.19990514031249.016df6c4@netgsi.com> <15098.926691656@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <15098.926691656@sss.pgh.pa.us> Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List Glenn Randers-Pehrson wrote: > With the FRAM method, it knows how long it's got, and could for > example only show the first several passes of an Adam7 interlacing and > then bail out and go on to the next image, when it recognizes that > it hasn't enough time to make a full-resolution display before the > allotted time will have elapsed. Tom Lane wrote: > Perhaps this reasoning should be mentioned in the rationale? I think it would be odd for an animation frame to be rendered in passes, since ideally it should appear instantaneously. It's also a bit odd for an encoder to be putting interlaced images into an animation in the first place, because animations are usually in short supply of compute cycles or I/O bandwidth, and interlacing uses more of both. But one could imagine that a frame takes too long to decode for other reasons, like if it's composed of a hundred images. But that still doesn't explain why the duration appears at the beginning of the frame. For that, we need to distinguish between two basic styles of decoders. Here's how I imagine a "good" decoder working: It decodes the stream a little bit ahead of where it needs to be. Usually, whenever it finishes decoding and assembling a frame (I don't remember the official terminology--I mean what a cartoon animator would call a frame), that frame is still not scheduled to appear until sometime in the future. So it stashes that constructed image somewhere, and at the appointed time begins painting it onto the display, but while it's waiting, it's decoding the next frame. I think this is what's known as "double-buffering", although the decoder is free to decode as far ahead as it likes, not just one frame ahead. (But for a decoder that interacts with the user, it probably doesn't want to decode too far ahead, because that effectively delays all the user input events.) For a decoder that works this way, it doesn't matter whether the frame's duration appears at the beginning of the chunks that define it or at the end. If we need to "bail out" of decoding a complex frame, it's because the frame's *start-time* has arrived before we were ready, not because it's *end-time* has arrived. So we require knowledge of the previous frame's duration, but not the this frame's. The other style of decoder does not decode frames before displaying them, but instead decodes them directly onto the display. In this case, we bail out if a frame's *end-time* arrives before we're ready, which requires knowledge of the frame's duration while we are decoding it. Although this won't look as nice, it's easier to implement and requires less data copying, enabling animations to be played on machines with slower I/O. (A really sophisticated decoder could even switch between double-buffering and direct-display while playing an animation, depending on variations in stream complexity and machine load.) So in a nutshell, the rationale is: There are two basic styles of playing animations, double-buffering and decoding directly to the display, and knowing a frame's duration ahead of time is useful for the latter. AMC -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Sat May 15 06:43:07 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id GAA13550; Sat, 15 May 1999 06:43:06 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id GAA09192 for mpng-list-out-eY3f3Qzu; Sat, 15 May 1999 06:42:56 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id GAA09188 for ; Sat, 15 May 1999 06:42:55 -0500 (CDT) Received: from glennrp.netgsi.com (p1-35.netgsi.com [209.150.125.35]) by mail.netgsi.com (Postfix) with SMTP id 300221880B for ; Sat, 15 May 1999 07:42:49 -0400 (EDT) Message-Id: <1.5.4.32.19990515114228.00cdebb8@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, 15 May 1999 07:42:28 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: Is MNG frozen? Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List >At 10:21 AM 5/14/99 -0500, you wrote: >>Is MNG officially frozen now? Seems the voting was all Yes and a couple >>Abstains. Just looking for official word and for the spec to be renamed to >>1.0. We have "frozen" the design as well as we can with the limited amount of testing that's been done so far. "Frozen" does not mean there will be no changes. It means that - Clarifications can be made - Inconsistencies and ambiguities discovered in the spec will be resolved - Incompatible changes will be avoided if possible - Technical changes to the spec will require a vote, even when they are backward compatible. - New features will require a vote Based on recent discussion of MOVE/CLIP appearing between the DEFI and the , I forsee a possible desireable change that would allow that, but I won't make a spec change without discussion and vote. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Sat May 15 16:37:26 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id QAA18721; Sat, 15 May 1999 16:37:25 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id QAA18738 for mpng-list-out-eY3f3Qzu; Sat, 15 May 1999 16:36:32 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id QAA18734 for ; Sat, 15 May 1999 16:36:30 -0500 (CDT) Received: from gerard1 (dc2-isdn995.dial.xs4all.nl [194.109.151.227]) by smtp1.xs4all.nl (8.8.8/8.8.8) with SMTP id XAA13262; Sat, 15 May 1999 23:36:21 +0200 (CEST) Message-Id: <199905152136.XAA13262@smtp1.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@ccrc.wustl.edu Date: Sat, 15 May 1999 23:39:29 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: MNGeye next release CC: Steven Johnson X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List Hi all, I fixed a few things in MNGeye and added some stuff. The latest version is available at http://www.3-t.com/3-T/products/mngi/Download.html Here's a summary of the changes: Added support for iTXt (*1) Added support for sRGB (default gamma -> 0.45455) Added support for TERM Added support for prVW (also reads pRVW) (*2) Added "security" for display of plain texts from chunks Fixed support for opening multiple files through file-association Fixed support for global PLTE and empty PLTE in PNG-object Fixed support for global tRNS Fixed support for CLON (do_not_show=0) Fixed background restore processing Fixed error writing script with ICCP Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 17 03:56:13 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id DAA08293; Mon, 17 May 1999 03:56:12 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id DAA23844 for mpng-list-out-eY3f3Qzu; Mon, 17 May 1999 03:51:04 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id DAA23840 for ; Mon, 17 May 1999 03:50:58 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id JAA21667 for ; Mon, 17 May 1999 09:50:48 +0100 (BST) Date: Mon, 17 May 1999 09:49:17 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Re: DEFI followed by MOVE Message-ID: <15cf89349%kbracey@kbracey.acorn.co.uk> In-Reply-To: <1.5.4.32.19990514185923.016d6678@netgsi.com> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List In message <1.5.4.32.19990514185923.016d6678@netgsi.com> Glenn Randers-Pehrson wrote: > > > >Actually, that description can't be quite right as image 2 wouldn't come > >into existence at the DEFI chunk, but at the subsequent embedded > >image. Hence the current DEFI values must be stored separately until the > >object comes into existence. > > You can store them in the regular place, but avoid applying deltas to > them until the object comes into existence. So it could be implemented such that DEFI does bring in to existence an incomplete, non-viewable object? I think that would complicate my implementation, having yet another type of object around that has special rules. > > It already exists, and has the pixels from the first embedded image. > But the following wouldn't work > > DEFI 2 > > DEFI 3 > MOVE 3 by 100,0 > > > The MOVE 3 chunk should be ignored, because no object 3 exists (even > if it had existed before this point in the datastream, it would be > destroyed by the DEFI 3 chunk). There is a spec contradiction on that point - the end of 4.2.1 says that a DEFI for an existing object changes its attributes, but doesn't affect its object buffer. Hows about this for a bit of pseudocode: handle_DEFI() { if (object_id already exists) { update attributes of object_id saved_DEFI.object_id = object_id } else { saved_DEFI = DEFI } } handle_image() { if (saved_DEFI.object_id exists) { replace object buffer of object_id (don't touch attributes) } else { create object saved_DEFI.object_id with attributes \ stored in saved_DEFI } } handle_DISC() { for each object in list { discard(object_id) } } discard(object_id) { junk the object and buffer if (saved_DEFI.object_id = object_id) reset saved_DEFI } I think that covers all the required behaviour, except that it favours the last paragraph of 4.2.1 over the statement about DEFI in 3.2. That allows DEFI to act as a combined MOVE/CLIP operation for existing images. Note that this definition assumes that there is a "make_concrete" flag in the object attributes that stores whether the next definition of that image should be concrete, in addition to the concrete flag in the object _buffer_ giving its current concreteness. -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 17 03:58:20 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id DAA08324; Mon, 17 May 1999 03:58:19 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id DAA23858 for mpng-list-out-eY3f3Qzu; Mon, 17 May 1999 03:53:57 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id DAA23854 for ; Mon, 17 May 1999 03:53:54 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id JAA21683 for ; Mon, 17 May 1999 09:53:52 +0100 (BST) Date: Mon, 17 May 1999 09:52:57 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Re: SHOW a frozen object Message-ID: <5a258a349%kbracey@kbracey.acorn.co.uk> In-Reply-To: <1.5.4.32.19990514193220.016eb114@netgsi.com> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List In message <1.5.4.32.19990514193220.016eb114@netgsi.com> Glenn Randers-Pehrson wrote: > > > > For modes 6 and 7, behaviour seems somewhat harder to specify, > > particularly when there are frozen images in the cycle with do_not_show = > > 0, which would seem to force the display of more than one layer. > > Clearly these modes are meant to be used with nonfrozen objects, but > we do need to say what happens when there are frozen objects in > the cycle. > > A reasonable, deterministic way of handling it would be to search > for the "next object that exists, is viewable, and is not frozen", > and emit a single layer containing that object. There's little > extra coding involved; in the construction of a reduced working set of > objects you eliminate all frozen objects along with the non-existent > and non-viewable ones. Seems logical. -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 17 04:03:39 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id EAA08384; Mon, 17 May 1999 04:03:38 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id DAA24037 for mpng-list-out-eY3f3Qzu; Mon, 17 May 1999 03:59:15 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id DAA23985 for ; Mon, 17 May 1999 03:58:59 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id JAA21740 for ; Mon, 17 May 1999 09:58:54 +0100 (BST) Date: Mon, 17 May 1999 09:57:47 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: PAST 0 Message-ID: X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List What _does_ it mean to PAST onto object 0? Section 4.2.8 says something about composite-over only, but how can you composite onto a non-existent object? Is it just a fancy way of drawing to the screen? -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 17 04:16:29 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id EAA08509; Mon, 17 May 1999 04:16:28 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id EAA24714 for mpng-list-out-eY3f3Qzu; Mon, 17 May 1999 04:12:05 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id EAA24710 for ; Mon, 17 May 1999 04:12:03 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id KAA21821 for ; Mon, 17 May 1999 10:12:01 +0100 (BST) Date: Mon, 17 May 1999 10:11:24 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Re: SHOW a frozen object Message-ID: <95d58b349%kbracey@kbracey.acorn.co.uk> In-Reply-To: <1.5.4.32.19990514193220.016eb114@netgsi.com> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List In message <1.5.4.32.19990514193220.016eb114@netgsi.com> Glenn Randers-Pehrson wrote: > > A reasonable, deterministic way of handling it would be to search > for the "next object that exists, is viewable, and is not frozen", > and emit a single layer containing that object. There's little > extra coding involved; in the construction of a reduced working set of > objects you eliminate all frozen objects along with the non-existent > and non-viewable ones. What about non-viewable objects? The way 4.3.5 reads at the moment, it says that SHOW 0-5 are allowed to change the do_not_show flag of non-viewable objects, but it just won't actually show them. On the other hand, 4.2.5 says that you can't define a non-viewable object with do_not_show=0, and SHOW 6-7 can't affect non-viewable objects. Would it be better to say that SHOW never affects non-viewable objects? -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 17 05:35:07 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id FAA09188; Mon, 17 May 1999 05:35:07 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id FAA25990 for mpng-list-out-eY3f3Qzu; Mon, 17 May 1999 05:30:42 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id FAA25986 for ; Mon, 17 May 1999 05:30:41 -0500 (CDT) Received: from glennrp.netgsi.com (p1-31.netgsi.com [209.150.125.31]) by mail.netgsi.com (Postfix) with SMTP id B798318827 for ; Mon, 17 May 1999 06:30:30 -0400 (EDT) Message-Id: <1.5.4.32.19990517103009.016dd4b8@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, 17 May 1999 06:30:09 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: PAST 0 Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 09:57 AM 5/17/99 +0100, you wrote: >What _does_ it mean to PAST onto object 0? > >Section 4.2.8 says something about composite-over only, but how can you >composite onto a non-existent object? Is it just a fancy way of drawing to >the screen? Yes, that's what it is. If you aren't using the tiling or flipping features, you might as well just send the images directly to the output instead of passing them through PAST, if the target is object 0. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 17 05:53:08 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id FAA09337; Mon, 17 May 1999 05:53:08 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id FAA26308 for mpng-list-out-eY3f3Qzu; Mon, 17 May 1999 05:48:45 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id FAA26304 for ; Mon, 17 May 1999 05:48:43 -0500 (CDT) Received: from glennrp.netgsi.com (p1-31.netgsi.com [209.150.125.31]) by mail.netgsi.com (Postfix) with SMTP id 34FD018827 for ; Mon, 17 May 1999 06:48:42 -0400 (EDT) Message-Id: <1.5.4.32.19990517104821.016e2f58@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, 17 May 1999 06:48:21 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: SHOW a frozen object Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 10:11 AM 5/17/99 +0100, you wrote: >In message <1.5.4.32.19990514193220.016eb114@netgsi.com> > Glenn Randers-Pehrson wrote: > >> >> A reasonable, deterministic way of handling it would be to search >> for the "next object that exists, is viewable, and is not frozen", >> and emit a single layer containing that object. There's little >> extra coding involved; in the construction of a reduced working set of >> objects you eliminate all frozen objects along with the non-existent >> and non-viewable ones. > >What about non-viewable objects? The way 4.3.5 reads at the moment, it says >that SHOW 0-5 are allowed to change the do_not_show flag of non-viewable >objects, but it just won't actually show them. On the other hand, 4.2.5 says >that you can't define a non-viewable object with do_not_show=0, and SHOW >6-7 can't affect non-viewable objects. Would it be better to say that SHOW >never affects non-viewable objects? I don't think so. The last sentence of 4.3.5 prevents apps from trying to display a nonviewable object as a result of a SHOW directive. The following would be useful, though: MHDR ... DEFI 1 BASI ... IEND SHOW 1 1 3 DHDR ... IEND # update object 1 and display it on-the-fly MEND Glenn. -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 17 07:19:04 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id HAA10151; Mon, 17 May 1999 07:19:04 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id HAA27550 for mpng-list-out-eY3f3Qzu; Mon, 17 May 1999 07:14:39 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id HAA27546 for ; Mon, 17 May 1999 07:14:36 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id NAA24256 for ; Mon, 17 May 1999 13:14:35 +0100 (BST) Date: Mon, 17 May 1999 13:14:03 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Re: SHOW a frozen object Message-ID: In-Reply-To: <1.5.4.32.19990517104821.016e2f58@netgsi.com> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List In message <1.5.4.32.19990517104821.016e2f58@netgsi.com> Glenn Randers-Pehrson wrote: > At 10:11 AM 5/17/99 +0100, you wrote: > >In message <1.5.4.32.19990514193220.016eb114@netgsi.com> > > Glenn Randers-Pehrson wrote: > > > >> > >> A reasonable, deterministic way of handling it would be to search > >> for the "next object that exists, is viewable, and is not frozen", > >> and emit a single layer containing that object. There's little > >> extra coding involved; in the construction of a reduced working set of > >> objects you eliminate all frozen objects along with the non-existent > >> and non-viewable ones. > > > >What about non-viewable objects? The way 4.3.5 reads at the moment, it says > >that SHOW 0-5 are allowed to change the do_not_show flag of non-viewable > >objects, but it just won't actually show them. On the other hand, 4.2.5 says > >that you can't define a non-viewable object with do_not_show=0, and SHOW > >6-7 can't affect non-viewable objects. Would it be better to say that SHOW > >never affects non-viewable objects? > > I don't think so. The last sentence of 4.3.5 prevents apps from trying > to display a nonviewable object as a result of a SHOW directive. The > following would be useful, though: > > MHDR ... > DEFI 1 > BASI ... IEND > SHOW 1 1 3 > DHDR ... IEND # update object 1 and display it on-the-fly > MEND > Hmph. That makes my do_not_show updating logic more complicated. Never mind. Anyway, if you can do that, why not just allow BASI to mark the object with do_not_show = 0 to start with, if there's nothing wrong with having non-viewable, potentially visible objects in existence: MHDR ... DEFI 1 BASI ... IEND DHDR ... IEND # update object 1 and display it on-the-fly MEND Note also that the spec implies that MHDR ... DEFI 1 BASI ... IEND CLON 1 2 DHDR ... IEND # update object 2 and display it on-the-fly MEND would be legal. If BASI definitely can't have do_not_show = 0 for a non-viewable object, it would be logical to apply the same restriction to CLON. -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 17 08:31:50 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id IAA11014; Mon, 17 May 1999 08:31:49 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id IAA28755 for mpng-list-out-eY3f3Qzu; Mon, 17 May 1999 08:27:18 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id IAA28751 for ; Mon, 17 May 1999 08:27:16 -0500 (CDT) Received: from glennrp.netgsi.com (p1-31.netgsi.com [209.150.125.31]) by mail.netgsi.com (Postfix) with SMTP id 5A57E18827 for ; Mon, 17 May 1999 09:27:14 -0400 (EDT) Message-Id: <1.5.4.32.19990517132654.00cdba28@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, 17 May 1999 09:26:54 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: DEFI followed by MOVE Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 09:49 AM 5/17/99 +0100, you wrote: >In message <1.5.4.32.19990514185923.016d6678@netgsi.com> > Glenn Randers-Pehrson wrote: > >> > >> >Actually, that description can't be quite right as image 2 wouldn't come >> >into existence at the DEFI chunk, but at the subsequent embedded >> >image. Hence the current DEFI values must be stored separately until the >> >object comes into existence. >> >> You can store them in the regular place, but avoid applying deltas to >> them until the object comes into existence. > >So it could be implemented such that DEFI does bring in to existence an >incomplete, non-viewable object? I think that would complicate my >implementation, having yet another type of object around that has special >rules. > >> >> It already exists, and has the pixels from the first embedded image. >> But the following wouldn't work >> >> DEFI 2 >> >> DEFI 3 >> MOVE 3 by 100,0 >> >> >> The MOVE 3 chunk should be ignored, because no object 3 exists (even >> if it had existed before this point in the datastream, it would be >> destroyed by the DEFI 3 chunk). > >There is a spec contradiction on that point - the end of 4.2.1 says that >a DEFI for an existing object changes its attributes, but doesn't affect >its object buffer. Yikes. There certainly is a contradiction, about the status of the object buffer between the DEFI and the . > >Hows about this for a bit of pseudocode: > > handle_DEFI() > { > if (object_id already exists) > { > update attributes of object_id > saved_DEFI.object_id = object_id > } > else > { > saved_DEFI = DEFI > } > } > > handle_image() > { > if (saved_DEFI.object_id exists) > { > replace object buffer of object_id > (don't touch attributes) > } > else > { > create object saved_DEFI.object_id with attributes \ > stored in saved_DEFI > } > } > > handle_DISC() > { > for each object in list > { > discard(object_id) > } > } > > discard(object_id) > { > junk the object and buffer This should be: junk the object decrement the buffer's reference count if reference count == 0, junk the buffer > if (saved_DEFI.object_id = object_id) > reset saved_DEFI > } > >I think that covers all the required behaviour, except that it favours >the last paragraph of 4.2.1 over the statement about DEFI in 3.2. >That allows DEFI to act as a combined MOVE/CLIP operation for existing >images. Except that DEFI isn't "loopable" because the locations and clipping boundaries are absolute. After a bit of recent work with ImageMagick, and converting some complex streams to MNG-LC, I think it would be useful to allow MOVE/CLIP to occur between DEFI and , even when working with object 0. Such a change would require a vote, and I was dubious about submitting the proposal. But now it's obvious that that part of the spec is flawed and needs to be fixed anyway, so perhaps this change should be worked in as well. In effect, the changes would be: 3.2, under "Object exists", add: o (Object 0 always exists). 3.2, under "Object does not exist" delete the two last list items. 3.3, change the second sentence to read The contents of an object buffer can be *replaced by processing another embedded image, or* modified by processing an image delta or a PAST chunk. 3.3, final sentence should be changed to When an object is discarded, and the object buffer that it points to has a nonzero reference count, that reference count is decremented, and the object buffer is also discarded if the resulting reference count is zero. [This change should be made regardless of the outcome of this proposal, since it adds a sanity check in case a DISC, SEEK, or MEND chunk occurs after a DEFI chunk and before the corresponding ]. 4.2.1 Delete "When object_id = 0, the DEFI chunk values are discarded after the object's IEND chunk is processed." Replace the final paragraph with If an object_id is an identifier that already exists when a DEFI chunk appears: o If the object buffer's reference count is nonzero, the object buffer's reference count is decremented and the buffer is discarded if the resulting reference count is zero; o The object attribute set is replaced. Note that if the object has partial clones, the clones will also be affected. 4.3.3 and 4.3.4 First_object and Last_object, change "nonzero unsigned" to "unsigned" 6, third paragraph, first sentence Change "object" to "object that has an object buffer" [this change should be made regardless of the outcome of this proposal] Consequences of this proposal: o There is a change in the appearance of certain MNG-0.95-compliant datastreams, namely those that set the object attribute set for object 0 and then expect the attribute set to revert to default values for subsequent objects. o MOVE/CLIP/CLON can appear between DEFI and . o Object 0 can be moved and clipped with the MOVE/CLIP chunks (actually simplifies the MOVE/CLIP chunk processing because decoders don't have to watch for object 0 and treat it as an error): DEFI 0 LOOP 0 10 MOVE 0 0 1 0 ENDL 0 o Object 0 still never has an object buffer (or never makes it available to subsequent chunks, if the decoder found it convenient to create one). The pseudocode would become: handle_MHDR() { ... object_id = 0 create object 0 with default attributes and no buffer ... } handle_DEFI() { if (object_id already exists) { discard object_id // could be 0 update object attributes set } else create object object_id with default attributes and no buffer } handle_image() { if (object_buffer[object_id] exists) { replace object buffer of object_id (don't touch attributes) } else { create object_buffer[object_id] (don't touch attributes except for the buffer pointer) } } handle_DISC() { for each object_id in list // never 0 { discard(object_id) } } discard(object_id) { if object buffer reference count > 0 decrement the buffer's reference count if reference count == 0 junk the buffer if object_id != 0) { junk the object attributes exists[object_id] = False } else reset the object attributes to default values } -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 17 08:53:14 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id IAA11262; Mon, 17 May 1999 08:53:13 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id IAA29258 for mpng-list-out-eY3f3Qzu; Mon, 17 May 1999 08:48:47 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id IAA29253 for ; Mon, 17 May 1999 08:48:46 -0500 (CDT) Received: from glennrp.netgsi.com (p1-31.netgsi.com [209.150.125.31]) by mail.netgsi.com (Postfix) with SMTP id B80BF18806 for ; Mon, 17 May 1999 09:48:45 -0400 (EDT) Message-Id: <1.5.4.32.19990517134824.016de330@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, 17 May 1999 09:48:24 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: SHOW a frozen object Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 01:14 PM 5/17/99 +0100, you wrote: > >If BASI definitely can't have do_not_show = 0 for a >non-viewable object, it would be logical to apply the same restriction to >CLON. This all looks reasonable, but it's a spec change that would have to be voted: o BASI: fourth from last paragraph, last two sentences would become When viewable=1, the resulting image, after the pixels are filled in, must be a legal PNG image. If viewable=1 and do_not_show=0, a viewer is expected to display it immediately, as if it were decoding a PNG datastream. o CLON: Add a sentence to the effect that if viewable=1 and do_not_show-1, display the image immediately. o SHOW: delete the final paragraph. Change the next-to-last paragraph to read "...not previously defined or is nonviewable. In such cases, nothing is done to the object." Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 17 11:41:05 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id LAA13771; Mon, 17 May 1999 11:41:04 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id LAA05268 for mpng-list-out-eY3f3Qzu; Mon, 17 May 1999 11:40:52 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA05263 for ; Mon, 17 May 1999 11:40:49 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id RAA27623 for ; Mon, 17 May 1999 17:40:17 +0100 (BST) Date: Mon, 17 May 1999 17:40:00 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: gAMA and sRGB Message-ID: X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List Should the following be allowed? I can't see that it's explicitly disallowed. MHDR gAMA 100000 # Image shown with gamma 1 sRGB 0 # gAMA and sRGB both now in force? # PNG spec says ignore gAMA... # Image shown with gamma 0.45455 (simple decoder) sRGB # sRGB nullified - gAMA still in force # Image shown with gamma 1 MEND The answer I'm looking for is, of course, that this is a heinous crime and is completely and utterly illegal. Please :) -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 17 14:08:32 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id OAA15955; Mon, 17 May 1999 14:08:31 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id OAA13479 for mpng-list-out-eY3f3Qzu; Mon, 17 May 1999 14:08:15 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.6.53]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id OAA13464 for ; Mon, 17 May 1999 14:08:12 -0500 (CDT) Received: from gerard1 (dc2-isdn2363.dial.xs4all.nl [194.109.157.59]) by smtp3.xs4all.nl (8.8.8/8.8.8) with SMTP id VAA17628 for ; Mon, 17 May 1999 21:08:11 +0200 (CEST) Message-Id: <199905171908.VAA17628@smtp3.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@ccrc.wustl.edu Date: Mon, 17 May 1999 21:11:46 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: DEFI followed by MOVE In-reply-to: <1.5.4.32.19990517132654.00cdba28@netgsi.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List Hi guys, Just budding into the conversation. What I do in MNGeye is to create an object (with an empty buffer) as soon as DEFI is processed. Then whenever an image passes along I stuff it into the object-buffer. So MOVE and CLIP can occur on the object before it actually is a filled object, because they change parameters in the object, not the object-buffer. It gets screwy though if a SHOW would occur before the image, but the code would just display the empty buffer (eg. a big NOP). One thing I need to do is separate the object-buffer from the object. Yes, I know, that should've happened years ago, but it's not as straightforward, and I need to dig into the code again. The last changes I made were a bit superficial. I'll save it for the next major overhaul. Regards, Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 17 14:08:32 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id OAA15956; Mon, 17 May 1999 14:08:31 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id OAA13480 for mpng-list-out-eY3f3Qzu; Mon, 17 May 1999 14:08:15 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.6.53]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id OAA13466 for ; Mon, 17 May 1999 14:08:12 -0500 (CDT) Received: from gerard1 (dc2-isdn2363.dial.xs4all.nl [194.109.157.59]) by smtp3.xs4all.nl (8.8.8/8.8.8) with SMTP id VAA17635 for ; Mon, 17 May 1999 21:08:12 +0200 (CEST) Message-Id: <199905171908.VAA17635@smtp3.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@ccrc.wustl.edu Date: Mon, 17 May 1999 21:11:46 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: SHOW a frozen object In-reply-to: <1.5.4.32.19990517134824.016de330@netgsi.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List > Date: Mon, 17 May 1999 09:48:24 -0400 > From: Glenn Randers-Pehrson > o BASI: fourth from last paragraph, last two sentences would become > > When viewable=1, the resulting image, after the pixels are filled > in, must be a legal PNG image. If viewable=1 and do_not_show=0, a > viewer is expected to display it immediately, as if it were decoding > a PNG datastream. > > o CLON: Add a sentence to the effect that if viewable=1 and > do_not_show-1, display the image immediately. do_not_show=0 I presume. > o SHOW: delete the final paragraph. Change the next-to-last > paragraph to read "...not previously defined or is nonviewable. > In such cases, nothing is done to the object." I can agree with the spec changes beforehand, but they will require a vote, like you said. I don't think many will oppose though. I'm just not sure how far Ravi is, and if this cuts into his beef. Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 17 14:08:32 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id OAA15957; Mon, 17 May 1999 14:08:31 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id OAA13478 for mpng-list-out-eY3f3Qzu; Mon, 17 May 1999 14:08:15 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.6.53]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id OAA13465 for ; Mon, 17 May 1999 14:08:12 -0500 (CDT) Received: from gerard1 (dc2-isdn2363.dial.xs4all.nl [194.109.157.59]) by smtp3.xs4all.nl (8.8.8/8.8.8) with SMTP id VAA17624 for ; Mon, 17 May 1999 21:08:10 +0200 (CEST) Message-Id: <199905171908.VAA17624@smtp3.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@ccrc.wustl.edu Date: Mon, 17 May 1999 21:11:45 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: gAMA and sRGB In-reply-to: X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List > Date: Mon, 17 May 1999 17:40:00 +0100 > From: Kevin Bracey > Should the following be allowed? I can't see that it's explicitly disallowed. > > MHDR > gAMA 100000 > # Image shown with gamma 1 > sRGB 0 # gAMA and sRGB both now in force? > # PNG spec says ignore gAMA... > # Image shown with gamma 0.45455 (simple decoder) > sRGB # sRGB nullified - gAMA still in force > # Image shown with gamma 1 > MEND sRGB can't be nullified. But the following can and will occur: MHDR gAMA 100000 # Image shown with gamma 1 gAMA 200000 # Image shown with gamma 2 gAMA 100000 # Image shown with gamma 1 MEND > The answer I'm looking for is, of course, that this is a heinous crime and > is completely and utterly illegal. Please :) It gets even worse, as it's not illegal to have multiple iCCP's in a MNG. So each image could have it's own color-space! Hideous for animations, so a recommendation has been made (9.1), but it's not illegal! Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 17 16:01:54 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id QAA17820; Mon, 17 May 1999 16:01:54 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id QAA19439 for mpng-list-out-eY3f3Qzu; Mon, 17 May 1999 16:01:42 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id QAA19435 for ; Mon, 17 May 1999 16:01:41 -0500 (CDT) Received: from glennrp.netgsi.com (p1-25.netgsi.com [209.150.125.25]) by mail.netgsi.com (Postfix) with SMTP id BD4B918803 for ; Mon, 17 May 1999 17:01:40 -0400 (EDT) Message-Id: <1.5.4.32.19990517210118.016e9534@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, 17 May 1999 17:01:18 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: gAMA and sRGB Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 05:40 PM 5/17/99 +0100, you wrote: >Should the following be allowed? I can't see that it's explicitly disallowed. > > MHDR > gAMA 100000 > # Image shown with gamma 1 > sRGB 0 # gAMA and sRGB both now in force? > # PNG spec says ignore gAMA... > # Image shown with gamma 0.45455 (simple decoder) > sRGB # sRGB nullified - gAMA still in force > # Image shown with gamma 1 > MEND > >The answer I'm looking for is, of course, that this is a heinous crime and >is completely and utterly illegal. Please :) It looks perfectly legal, if heinous. I think your comments give the correct interpretations and I don't think there's any ambiguity. Glenn Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 17 16:06:43 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id QAA17907; Mon, 17 May 1999 16:06:43 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id QAA19663 for mpng-list-out-eY3f3Qzu; Mon, 17 May 1999 16:06:40 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id QAA19658 for ; Mon, 17 May 1999 16:06:39 -0500 (CDT) Received: from glennrp.netgsi.com (p1-25.netgsi.com [209.150.125.25]) by mail.netgsi.com (Postfix) with SMTP id 16CBA18808 for ; Mon, 17 May 1999 17:06:34 -0400 (EDT) Message-Id: <1.5.4.32.19990517210612.016e950c@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, 17 May 1999 17:06:12 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: DEFI followed by MOVE Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 09:11 PM 5/17/99 +0100, you wrote: >Hi guys, > >Just budding into the conversation. What I do in MNGeye is to create >an object (with an empty buffer) as soon as DEFI is processed. Then >whenever an image passes along I stuff it into the object-buffer. So >MOVE and CLIP can occur on the object before it actually is a filled >object, because they change parameters in the object, not the >object-buffer. That's not according to spec. But I think you and I discussed this a few months ago and decided to go along these lines; I forgot to update the draft. Right now I have my copy of ImageMagick set up to go either way, with an #ifdef. Only two or three lines of code are actually affected. >One thing I need to do is separate the object-buffer from the object. Right, partial clones won't work without it. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 17 16:07:56 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id QAA17934; Mon, 17 May 1999 16:07:55 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id QAA19713 for mpng-list-out-eY3f3Qzu; Mon, 17 May 1999 16:07:52 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id QAA19708 for ; Mon, 17 May 1999 16:07:51 -0500 (CDT) Received: from glennrp.netgsi.com (p1-25.netgsi.com [209.150.125.25]) by mail.netgsi.com (Postfix) with SMTP id 8B2E018803 for ; Mon, 17 May 1999 17:07:51 -0400 (EDT) Message-Id: <1.5.4.32.19990517210729.016ea6d8@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, 17 May 1999 17:07:29 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: SHOW a frozen object Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 09:11 PM 5/17/99 +0100, you wrote: >> o CLON: Add a sentence to the effect that if viewable=1 and >> do_not_show-1, display the image immediately. > >do_not_show=0 I presume. Yes Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 17 16:19:44 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id QAA18070; Mon, 17 May 1999 16:19:43 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id QAA20436 for mpng-list-out-eY3f3Qzu; Mon, 17 May 1999 16:19:39 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id QAA20431 for ; Mon, 17 May 1999 16:19:38 -0500 (CDT) Received: from glennrp.netgsi.com (p1-25.netgsi.com [209.150.125.25]) by mail.netgsi.com (Postfix) with SMTP id 2AF7218803 for ; Mon, 17 May 1999 17:19:37 -0400 (EDT) Message-Id: <1.5.4.32.19990517211916.016f14a4@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, 17 May 1999 17:19:16 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: gAMA and sRGB Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 09:11 PM 5/17/99 +0100, you wrote: >sRGB can't be nullified. It can. See paragraph 4.5.5 Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Tue May 18 02:22:12 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id CAA23371; Tue, 18 May 1999 02:17:52 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id BAA18009 for mpng-list-out-eY3f3Qzu; Tue, 18 May 1999 01:49:24 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.6.53]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id BAA18005 for ; Tue, 18 May 1999 01:49:22 -0500 (CDT) Received: from gerard1 (dc2-isdn517.dial.xs4all.nl [194.109.150.5]) by smtp3.xs4all.nl (8.8.8/8.8.8) with SMTP id IAA14491 for ; Tue, 18 May 1999 08:49:22 +0200 (CEST) Message-Id: <199905180649.IAA14491@smtp3.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@ccrc.wustl.edu Date: Tue, 18 May 1999 08:53:05 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: gAMA and sRGB In-reply-to: <1.5.4.32.19990517211916.016f14a4@netgsi.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List > Date: Mon, 17 May 1999 17:19:16 -0400 > From: Glenn Randers-Pehrson > >sRGB can't be nullified. > > It can. See paragraph 4.5.5 Ah, so sorry, you're absolutely right. Forgot about that one. Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Tue May 18 03:25:37 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id DAA23917; Tue, 18 May 1999 03:25:36 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id DAA22509 for mpng-list-out-eY3f3Qzu; Tue, 18 May 1999 03:25:29 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id DAA22504 for ; Tue, 18 May 1999 03:25:27 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id JAA03356 for ; Tue, 18 May 1999 09:25:25 +0100 (BST) Date: Tue, 18 May 1999 09:25:00 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Re: gAMA and sRGB Message-ID: <356cb449%kbracey@kbracey.acorn.co.uk> In-Reply-To: <1.5.4.32.19990517210118.016e9534@netgsi.com> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List In message <1.5.4.32.19990517210118.016e9534@netgsi.com> Glenn Randers-Pehrson wrote: > At 05:40 PM 5/17/99 +0100, you wrote: > >Should the following be allowed? I can't see that it's explicitly disallowed. > > > > MHDR > > gAMA 100000 > > # Image shown with gamma 1 > > sRGB 0 # gAMA and sRGB both now in force? > > # PNG spec says ignore gAMA... > > # Image shown with gamma 0.45455 (simple decoder) > > sRGB # sRGB nullified - gAMA still in force > > # Image shown with gamma 1 > > MEND > > > >The answer I'm looking for is, of course, that this is a heinous crime and > >is completely and utterly illegal. Please :) > > It looks perfectly legal, if heinous. I think your comments give > the correct interpretations and I don't think there's any ambiguity. > I agree. I thought about this overnight, and it's the only possible interpretation of the spec. I asked because my first attempt at implementation read something like handle_gAMA() { /* All error checking omitted :) */ if (length == 4) default gamma = gAMA value else default gamma = our chosen default } handle_sRGB() { if (length == 1) default gamma = 0.45455 else default gamma = our chosen default } I then realised that this wasn't good enough, and I'd have to store both the current sRGB and gAMA settings separately. -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Tue May 18 03:36:38 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id DAA24016; Tue, 18 May 1999 03:36:38 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id DAA23041 for mpng-list-out-eY3f3Qzu; Tue, 18 May 1999 03:36:35 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id DAA23036 for ; Tue, 18 May 1999 03:36:33 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id JAA03484 for ; Tue, 18 May 1999 09:36:32 +0100 (BST) Date: Tue, 18 May 1999 09:36:23 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Re: DEFI followed by MOVE Message-ID: In-Reply-To: <1.5.4.32.19990517132654.00cdba28@netgsi.com> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List In message <1.5.4.32.19990517132654.00cdba28@netgsi.com> Glenn Randers-Pehrson wrote: > 3.2, under "Object exists", add: Don't you need to add that DEFI makes object n exist? > 4.2.1 > > > Note that if the object > has partial clones, the clones will also be affected. Oooh, tricky. I think that's a unique case where a clone has to know who the other clones are. How about this one? MHDR DEFI 1 SAVE TERM 3 SEEK MOVE 1 by 200 200 SHOW 1 MEND -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Tue May 18 04:11:29 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id EAA24272; Tue, 18 May 1999 04:11:29 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id EAA25214 for mpng-list-out-eY3f3Qzu; Tue, 18 May 1999 04:10:52 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id EAA25209 for ; Tue, 18 May 1999 04:10:50 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id KAA04049 for ; Tue, 18 May 1999 10:10:48 +0100 (BST) Date: Tue, 18 May 1999 10:10:25 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Re: gAMA and sRGB Message-ID: <7b94f449%kbracey@kbracey.acorn.co.uk> In-Reply-To: <1.5.4.32.19990517210118.016e9534@netgsi.com> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List In message <1.5.4.32.19990517210118.016e9534@netgsi.com> Glenn Randers-Pehrson wrote: > > It looks perfectly legal, if heinous. I think your comments give > the correct interpretations and I don't think there's any ambiguity. > What about this example? MHDR PLTE (4 entries) tRNS (6 entries) IHDR (type 3) PLTE (5 entries) IDAT IEND MEND Is this okay, because the global PLTE and tRNS never get used? Or is it an immediate error at the MNG level to have tRNS with more entries than PLTE? I imagine it's the former. Further along that vein, this is presumably legal too: MHDR PLTE (4 entries) gAMA 0.5 IHDR (type 3) PLTE (null) IDAT IEND MEND because the gAMA will automatically insert itself at the right place in the embedded image, and it's not a MNG restriction that gAMA appear before PLTE. -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Tue May 18 06:09:27 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id GAA24923; Tue, 18 May 1999 06:09:27 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id GAA00571 for mpng-list-out-eY3f3Qzu; Tue, 18 May 1999 06:08:18 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id GAA00566 for ; Tue, 18 May 1999 06:08:17 -0500 (CDT) Received: from glennrp.netgsi.com (p1-4.netgsi.com [209.150.125.4]) by mail.netgsi.com (Postfix) with SMTP id 6EAAC1881E for ; Tue, 18 May 1999 07:08:16 -0400 (EDT) Message-Id: <1.5.4.32.19990518110754.016e3144@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, 18 May 1999 07:07:54 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: DEFI followed by MOVE Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 09:36 AM 5/18/99 +0100, you wrote: >In message <1.5.4.32.19990517132654.00cdba28@netgsi.com> > Glenn Randers-Pehrson wrote: > >> 3.2, under "Object exists", add: > >Don't you need to add that DEFI makes object n exist? Yes. > >> 4.2.1 >> > >> >> Note that if the object >> has partial clones, the clones will also be affected. > >Oooh, tricky. I think that's a unique case where a clone has to know who the >other clones are. The object buffers of the other clones are affected (because they are sharing the object buffer) but the object attributes aren't. The clone only has to know how many other clones there are (through the reference count). The "Note" just means that the clones will naturally be affected because they are sharing the same object buffer. > >How about this one? > > MHDR > DEFI 1 > SAVE > TERM 3 > SEEK > > MOVE 1 by 200 200 > SHOW 1 > MEND You can't MOVE a frozen object, so the MOVE is illegal. Changing its object buffer must be illegal also: It is not permitted, at any point beyond the SAVE chunk, to modify or discard any object that was defined ahead of the SAVE chunk (that would include modifying the buffer pointer or the contents of the object buffer to which it points). Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Tue May 18 06:13:41 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id GAA24965; Tue, 18 May 1999 06:13:41 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id GAA00868 for mpng-list-out-eY3f3Qzu; Tue, 18 May 1999 06:13:38 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id GAA00863 for ; Tue, 18 May 1999 06:13:37 -0500 (CDT) Received: from gerard1 (dc2-isdn2331.dial.xs4all.nl [194.109.157.27]) by smtp1.xs4all.nl (8.8.8/8.8.8) with SMTP id NAA28077 for ; Tue, 18 May 1999 13:13:36 +0200 (CEST) Message-Id: <199905181113.NAA28077@smtp1.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@ccrc.wustl.edu Date: Tue, 18 May 1999 13:17:19 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: DEFI followed by MOVE In-reply-to: References: <1.5.4.32.19990517132654.00cdba28@netgsi.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List > Date: Tue, 18 May 1999 09:36:23 +0100 > From: Kevin Bracey > > Note that if the object > > has partial clones, the clones will also be affected. > > Oooh, tricky. I think that's a unique case where a clone has to know who the > other clones are. Not necessarily. The DEFI object's point to the same object-buffer. The data in the object-buffer is changed so the DEFI object's now point to different data. If, by changing the object-buffer, you read discard the buffer and create a new one, then you have a problem, as the pointers become invalid. Best way to handle this is to have an object-buffer that contains the reference-count and a pointer to the actual buffer-data (besides obvious other handy details from the IHDR). > How about this one? > > MHDR > DEFI 1 > SAVE > TERM 3 > SEEK > > MOVE 1 by 200 200 > SHOW 1 > MEND That would be an illegal example IMHO. SAVE (and SEEK) are very deliberate borders. Object's, LOOP's and the like cannot extend beyond them. The only chunk that allows processing around these is the TERM chunk. Also, the SAVE in your sample "freezes" object 1. The object-buffer of a frozen object cannot be discarded or changed. (See 2. Terminology). Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Tue May 18 06:13:45 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id GAA24980; Tue, 18 May 1999 06:13:45 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id GAA00877 for mpng-list-out-eY3f3Qzu; Tue, 18 May 1999 06:13:43 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id GAA00872 for ; Tue, 18 May 1999 06:13:41 -0500 (CDT) Received: from gerard1 (dc2-isdn2331.dial.xs4all.nl [194.109.157.27]) by smtp1.xs4all.nl (8.8.8/8.8.8) with SMTP id NAA28083 for ; Tue, 18 May 1999 13:13:37 +0200 (CEST) Message-Id: <199905181113.NAA28083@smtp1.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@ccrc.wustl.edu Date: Tue, 18 May 1999 13:17:19 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: gAMA and sRGB In-reply-to: <7b94f449%kbracey@kbracey.acorn.co.uk> References: <1.5.4.32.19990517210118.016e9534@netgsi.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List > Date: Tue, 18 May 1999 10:10:25 +0100 > From: Kevin Bracey > What about this example? > > MHDR > PLTE (4 entries) > tRNS (6 entries) > IHDR (type 3) > PLTE (5 entries) > IDAT > IEND > MEND > > Is this okay, because the global PLTE and tRNS never get used? Or is it an > immediate error at the MNG level to have tRNS with more entries than PLTE? I > imagine it's the former. The MNG spec doesn't state it's an immediate error. They would be if they are used inside an image, according the PNG spec. The sample above doesn't use them, so theoratically not an error. A bit useless though. (In MNGeye I don't treat more entries in tRNS than PLTE as an error; I always create an array of 256 entries (prefilled with value 255), and fill in the entries from tRNS as far as they are supplied.) > Further along that vein, this is presumably legal > too: > > MHDR > PLTE (4 entries) > gAMA 0.5 > IHDR (type 3) > PLTE (null) > IDAT > IEND > MEND > > because the gAMA will automatically insert itself at the right place in the > embedded image, and it's not a MNG restriction that gAMA appear before PLTE. Correct. Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Tue May 18 06:38:06 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id GAA25152; Tue, 18 May 1999 06:38:06 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id GAA01952 for mpng-list-out-eY3f3Qzu; Tue, 18 May 1999 06:38:03 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id GAA01947 for ; Tue, 18 May 1999 06:38:01 -0500 (CDT) Received: from glennrp.netgsi.com (p1-4.netgsi.com [209.150.125.4]) by mail.netgsi.com (Postfix) with SMTP id 59F3A18801 for ; Tue, 18 May 1999 07:38:00 -0400 (EDT) Message-Id: <1.5.4.32.19990518113738.00cecbe0@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, 18 May 1999 07:37:38 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: gAMA and sRGB Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 10:10 AM 5/18/99 +0100, you wrote: >What about this example? > > MHDR > PLTE (4 entries) > tRNS (6 entries) > IHDR (type 3) > PLTE (5 entries) > IDAT > IEND > MEND > >Is this okay, because the global PLTE and tRNS never get used? Or is it an >immediate error at the MNG level to have tRNS with more entries than PLTE? I >imagine it's the former. I suppose it's the former. But it would be an error within a PNG that had an empty PLTE and no tRNS chunk, because then it would be inheriting a tRNS that's too long. Decoders can be kinder, though. ImageMagick will attempt to display something in such a case, or even when the global PLTE is not present. It initializes its global palette with 256 entries of {i,i,i}, and then fills in when it receives a global PLTE. The global palette is therefore always long enough. But that is beyond what the spec requires, and MNG *editors* should be more stringent. > Further along that vein, this is presumably legal >too: > > MHDR > PLTE (4 entries) > gAMA 0.5 > IHDR (type 3) > PLTE (null) > IDAT > IEND > MEND > >because the gAMA will automatically insert itself at the right place in the >embedded image, and it's not a MNG restriction that gAMA appear before PLTE. Yes. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Tue May 18 07:00:28 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id HAA25297; Tue, 18 May 1999 07:00:27 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id HAA02960 for mpng-list-out-eY3f3Qzu; Tue, 18 May 1999 07:00:23 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id HAA02955 for ; Tue, 18 May 1999 07:00:21 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id NAA06423 for ; Tue, 18 May 1999 13:00:19 +0100 (BST) Date: Tue, 18 May 1999 12:59:16 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Re: DEFI followed by MOVE Message-ID: In-Reply-To: <1.5.4.32.19990518110754.016e3144@netgsi.com> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List In message <1.5.4.32.19990518110754.016e3144@netgsi.com> Glenn Randers-Pehrson wrote: > > > >> 4.2.1 > >> > > > >> > >> Note that if the object > >> has partial clones, the clones will also be affected. > > > >Oooh, tricky. I think that's a unique case where a clone has to know who the > >other clones are. > > The object buffers of the other clones are affected (because they > are sharing the object buffer) but the object attributes aren't. The > clone only has to know how many other clones there are (through the > reference count). The "Note" just means that the clones will > naturally be affected because they are sharing the same object buffer. > Oh. But we'd said that DEFI only affects the object attributes - in which case clones aren't affected at all. They _will_ be affected when/if a new image comes along though. -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Tue May 18 07:07:32 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id HAA25341; Tue, 18 May 1999 07:07:31 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id HAA03311 for mpng-list-out-eY3f3Qzu; Tue, 18 May 1999 07:07:29 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id HAA03306 for ; Tue, 18 May 1999 07:07:25 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id NAA06519 for ; Tue, 18 May 1999 13:07:23 +0100 (BST) Date: Tue, 18 May 1999 13:07:16 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Re: gAMA and sRGB Message-ID: <80c51f449%kbracey@kbracey.acorn.co.uk> In-Reply-To: <199905181113.NAA28083@smtp1.xs4all.nl> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List In message <199905181113.NAA28083@smtp1.xs4all.nl> "Gerard Juyn" wrote: > > (In MNGeye I don't treat more entries in tRNS than PLTE as an error; > I always create an array of 256 entries (prefilled with value 255), > and fill in the entries from tRNS as far as they are supplied.) I've always been somewhat wary about not reporting errors - it just increases the prevalence of broken files. I know, for example, that MNGeye will produce broken files that it will accept itself, but my decoder won't. You haven't spotted the broken files because your decoder is "coping" with the error. As soon as some major programs start coping with certain conditions silently, other programs then have to do with the same thing because users complain "well, it works on Bloggs MNGWare 3.14", and you end up with whole reams of "unwritten specification" about the handling of things that are officially illegal. The only test most people perform on files is seeing if a few programs (or maybe only one) will load it. People don't read specs. My decoder is going to refuse to process on any grounds it can, because it is a new format, and there shouldn't be any widespread broken implementations yet. Maybe we can nip it in the bud. I'll e-mail you separately with bug reports for MNGeye when I've collated them properly. -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Tue May 18 07:39:37 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id HAA25605; Tue, 18 May 1999 07:39:36 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id HAA04776 for mpng-list-out-eY3f3Qzu; Tue, 18 May 1999 07:39:22 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id HAA04771 for ; Tue, 18 May 1999 07:39:21 -0500 (CDT) Received: from glennrp.netgsi.com (p1-4.netgsi.com [209.150.125.4]) by mail.netgsi.com (Postfix) with SMTP id 591C518801 for ; Tue, 18 May 1999 08:39:20 -0400 (EDT) Message-Id: <1.5.4.32.19990518123858.016f7f60@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, 18 May 1999 08:38:58 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: DEFI followed by MOVE Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 09:36 AM 5/18/99 +0100, you wrote: >In message <1.5.4.32.19990517132654.00cdba28@netgsi.com> > Glenn Randers-Pehrson wrote: > >> 3.2, under "Object exists", add: > >Don't you need to add that DEFI makes object n exist? Yes. By the way, I think it'll be helpful to add another object attribute, "viewable" (we already have "viewable" as a flag in the object buffer), to help describe the state of affairs when processing chunks that intervene between the DEFI and the . 3.2 Object attributes Object is viewable An object is viewable if it has a viewable object buffer. It is nonviewable if it has a nonviewable object buffer or if its object buffer has not yet been received. Any attempt to display a nonviewable object must be ignored. A nonviewable object becomes viewable immediately when the decoder receives a viewable object buffer or an image delta that makes it viewable, and if the object is potentially visible it can be displayed on-the-fly while its object buffer is decoded or updated. 3.3 Object buffers change the heading "Object is viewable" to "Object buffer is viewable" and delete the first two sentences. In fact, I had been carrying a "viewable" object attribute in addition to a "viewable" flag in the object buffer all along in ARL viewpng and plan to do the same in ImageMagick. This isn't a spec change but another way of describing how decoders can operate. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Tue May 18 09:07:38 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id JAA26501; Tue, 18 May 1999 09:07:38 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id JAA09210 for mpng-list-out-eY3f3Qzu; Tue, 18 May 1999 09:07:31 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id JAA09200 for ; Tue, 18 May 1999 09:07:30 -0500 (CDT) Received: from glennrp.netgsi.com (p1-4.netgsi.com [209.150.125.4]) by mail.netgsi.com (Postfix) with SMTP id EC4ED18803 for ; Tue, 18 May 1999 10:07:29 -0400 (EDT) Message-Id: <1.5.4.32.19990518140707.017015b0@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, 18 May 1999 10:07:07 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: gAMA and sRGB Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 01:07 PM 5/18/99 +0100, you wrote: >In message <199905181113.NAA28083@smtp1.xs4all.nl> > "Gerard Juyn" wrote: >As soon as some major programs start coping with certain conditions silently, >other programs then have to do with the same thing because users complain >"well, it works on Bloggs MNGWare 3.14", >My decoder is going to refuse to process on any grounds it can, because it is >a new format, and there shouldn't be any widespread broken implementations >yet. Maybe we can nip it in the bud. I'll try to make sure that my applications display a warning whenever they "cope" with errors. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Tue May 18 09:20:58 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id JAA26663; Tue, 18 May 1999 09:20:58 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id JAA09950 for mpng-list-out-eY3f3Qzu; Tue, 18 May 1999 09:20:55 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id JAA09945 for ; Tue, 18 May 1999 09:20:53 -0500 (CDT) 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 KAA19165 for ; Tue, 18 May 1999 10:20:50 -0400 (EDT) To: MPNG List Subject: error detection (was Re: gAMA and sRGB) In-reply-to: Your message of Tue, 18 May 1999 13:07:16 +0100 <80c51f449%kbracey@kbracey.acorn.co.uk> Date: Tue, 18 May 1999 10:20:50 -0400 Message-ID: <19163.927037250@sss.pgh.pa.us> From: Tom Lane Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List Kevin Bracey writes: > As soon as some major programs start coping with certain conditions silently, > other programs then have to do with the same thing because users complain > "well, it works on Bloggs MNGWare 3.14", and you end up with whole reams of > "unwritten specification" about the handling of things that are officially > illegal. The only test most people perform on files is seeing if a few > programs (or maybe only one) will load it. People don't read specs. A big ME TOO on that one. I believe that part of the reason that JPEG is fairly cross-implementation-compatible these days is that libjpeg has never been willing to silently swallow encoder errors. (It does try to recover from errors in the compressed data, but the effects of those are usually obvious to the eye anyway.) Any detectable problem in the JPEG markers gets you at least a warning message. At this point, since there's no installed base of broken MNG encoders, we'll be doing ourselves a favor if we make the decoders as strict as possible. Think of your decoder as a debugging tool that helps catch encoder errors... regards, tom lane organizer, Independent JPEG Group -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Tue May 18 11:29:30 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id LAA28085; Tue, 18 May 1999 11:29:30 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id LAA17208 for mpng-list-out-eY3f3Qzu; Tue, 18 May 1999 11:29:19 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with SMTP id LAA17203 for ; Tue, 18 May 1999 11:29:16 -0500 (CDT) Received: (qmail 9838 invoked from network); 18 May 1999 16:29:16 -0000 Received: from sub.sonic.net (208.201.224.8) by marine.sonic.net with SMTP; 18 May 1999 16:29:16 -0000 Received: from bolt.sonic.net (roelofs@bolt.sonic.net [208.201.224.36]) by sub.sonic.net (8.8.8/8.8.5) with ESMTP id JAA28284; Tue, 18 May 1999 09:29:15 -0700 X-envelope-info: Received: (from roelofs@localhost) by bolt.sonic.net (8.8.8/8.7.3) id JAA12510; Tue, 18 May 1999 09:29:15 -0700 Date: Tue, 18 May 1999 09:29:15 -0700 Message-Id: <199905181629.JAA12510@bolt.sonic.net> From: Greg Roelofs To: holi@psynet.net Subject: Re: MNG question Cc: mpng-list@dworkin.wustl.edu Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List Oli, > I'm a fellow supporter of PNG and MNG... btw the "PNG Portable > Network Graphic" button at the bottom of your page is a GIF :o) I know > it's more supported than PNG at the moment... just thought it was > ironic. It's both PNG and GIF. Broken browsers display the GIF version. > Anyway, I was playing around Animation Shop included in PSP5 and > noticed that the default Animation Shop format is MNG. Is it the same > MNG than the one with PNG? Sure is. > And would you happen to know how is it > possible to "enable" the MNG optimization in the Optimization Wizard? > Mine stays gray all the time, even when I save the file as MNG first. I don't think that's possible yet, but you'd have to ask JASC to be certain. MNG was not yet frozen at the time PSP 5.0 was released (in fact, it's only been frozen for a few days), so they were probably waiting until things settled completely before attempting to implement "optimization." There's also been a paucity of full-featured MNG viewers until quite recently. -- Greg Roelofs newt@pobox.com http://pobox.com/~newt/ Newtware, PNG Group, Info-ZIP, Philips Research, ... -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Tue May 18 11:49:16 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id LAA28320; Tue, 18 May 1999 11:49:15 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id LAA18911 for mpng-list-out-eY3f3Qzu; Tue, 18 May 1999 11:49:11 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from exchange-server.prgmng ([207.109.13.10]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA18904 for ; Tue, 18 May 1999 11:49:07 -0500 (CDT) Received: by EXCHANGE_SERVER with Internet Mail Service (5.5.2448.0) id ; Tue, 18 May 1999 11:50:59 -0500 Message-ID: From: Joe Fromm To: mpng-list@dworkin.wustl.edu Subject: FW: MNG question Date: Tue, 18 May 1999 11:50:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List The MNG support in Animation Shop is only partial. Essentially, we support those chunks necessary for us to store GIF animations, but at 24 bit color with an alpha channel. When we created version 1 of AS we had good intentions about doing a full blown MNG reader/writer, but then the schedule overtook us, so it has remained a fairly constrained subset. Joe Fromm Senior Software Engineer Jasc Software, Inc. jfromm@jasc.com -----Original Message----- From: Greg Roelofs [mailto:newt@pobox.com] Sent: Tuesday, May 18, 1999 11:29 AM To: holi@psynet.net Cc: mpng-list@dworkin.wustl.edu Subject: Re: MNG question Oli, > I'm a fellow supporter of PNG and MNG... btw the "PNG Portable > Network Graphic" button at the bottom of your page is a GIF :o) I know > it's more supported than PNG at the moment... just thought it was > ironic. It's both PNG and GIF. Broken browsers display the GIF version. > Anyway, I was playing around Animation Shop included in PSP5 and > noticed that the default Animation Shop format is MNG. Is it the same > MNG than the one with PNG? Sure is. > And would you happen to know how is it > possible to "enable" the MNG optimization in the Optimization Wizard? > Mine stays gray all the time, even when I save the file as MNG first. I don't think that's possible yet, but you'd have to ask JASC to be certain. MNG was not yet frozen at the time PSP 5.0 was released (in fact, it's only been frozen for a few days), so they were probably waiting until things settled completely before attempting to implement "optimization." There's also been a paucity of full-featured MNG viewers until quite recently. -- Greg Roelofs newt@pobox.com http://pobox.com/~newt/ Newtware, PNG Group, Info-ZIP, Philips Research, ... -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Wed May 19 01:11:49 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id BAA09802; Wed, 19 May 1999 01:11:49 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id BAA07439 for mpng-list-out-eY3f3Qzu; Wed, 19 May 1999 01:11:35 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id BAA07426 for ; Wed, 19 May 1999 01:11:33 -0500 (CDT) Received: from gerard1 (dc2-isdn873.dial.xs4all.nl [194.109.151.105]) by smtp1.xs4all.nl (8.8.8/8.8.8) with SMTP id IAA02489 for ; Wed, 19 May 1999 08:11:33 +0200 (CEST) Message-Id: <199905190611.IAA02489@smtp1.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@ccrc.wustl.edu Date: Wed, 19 May 1999 08:15:28 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: gAMA and sRGB In-reply-to: <80c51f449%kbracey@kbracey.acorn.co.uk> References: <199905181113.NAA28083@smtp1.xs4all.nl> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List > Date: Tue, 18 May 1999 13:07:16 +0100 > From: Kevin Bracey > > (In MNGeye I don't treat more entries in tRNS than PLTE as an error; > > I always create an array of 256 entries (prefilled with value 255), > > and fill in the entries from tRNS as far as they are supplied.) > > I've always been somewhat wary about not reporting errors - it just increases > the prevalence of broken files. I know, for example, that MNGeye will produce > broken files that it will accept itself, but my decoder won't. You haven't > spotted the broken files because your decoder is "coping" with the error. Yes, I agree too. But if you'd look at the development of MNGeye, it's not very surprising. I needed to create a program that could create it's own test-images. So what came out, in a (very) short period of time, is a MNG-viewer that's more of a development tool for other MNG-decoders/-encoders. I did incorporate as many checks as possible. Eg. Richard Franzen (whatever happened to pn6???) had some test-images (PNG) at a point that didn't work. They had 0x0d/0x0A appended to the end of the stream. Looked fine in Netscape (?!?!? One for you, Greg!) but MNGeye rejected them with "bad chunkcode". I'll be happy to have a look at your bug-list whenever you're ready. And tend to these stricter rules as well. At first I wanted to answer that it should be the encoder's job to enforce such behavior, but like someone mentioned "How to test an encoder?". It's a good decoder's job to try and salvage as much as possible, but make a note of irregularities in some way or another. I'll probably add a severity-level to the checks in MNGeye, and (based on that) let the user decide to continue or abort processing after encountering a glitch in the input-stream. Regards, Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Wed May 19 01:11:49 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id BAA09803; Wed, 19 May 1999 01:11:49 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id BAA07438 for mpng-list-out-eY3f3Qzu; Wed, 19 May 1999 01:11:34 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id BAA07424 for ; Wed, 19 May 1999 01:11:33 -0500 (CDT) Received: from gerard1 (dc2-isdn873.dial.xs4all.nl [194.109.151.105]) by smtp1.xs4all.nl (8.8.8/8.8.8) with SMTP id IAA02486 for ; Wed, 19 May 1999 08:11:32 +0200 (CEST) Message-Id: <199905190611.IAA02486@smtp1.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@ccrc.wustl.edu Date: Wed, 19 May 1999 08:15:28 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: DEFI followed by MOVE In-reply-to: References: <1.5.4.32.19990518110754.016e3144@netgsi.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List > Date: Tue, 18 May 1999 12:59:16 +0100 > From: Kevin Bracey > > >> Note that if the object > > >> has partial clones, the clones will also be affected. > > > > > >Oooh, tricky. I think that's a unique case where a clone has to know who the > > >other clones are. > > > > The object buffers of the other clones are affected (because they > > are sharing the object buffer) but the object attributes aren't. The > > clone only has to know how many other clones there are (through the > > reference count). The "Note" just means that the clones will > > naturally be affected because they are sharing the same object buffer. > > > > Oh. But we'd said that DEFI only affects the object attributes - in which > case clones aren't affected at all. They _will_ be affected when/if a new > image comes along though. Correct, Except that last paragraph in 4.2.1 addresses what happens if an embedded image comes along. It makes perfectly sense in the context. Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Wed May 19 04:44:13 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id EAA12383; Wed, 19 May 1999 04:44:13 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id EAA18057 for mpng-list-out-eY3f3Qzu; Wed, 19 May 1999 04:43:37 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id EAA18051 for ; Wed, 19 May 1999 04:43:34 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id KAA19439 for ; Wed, 19 May 1999 10:43:33 +0100 (BST) Date: Wed, 19 May 1999 10:15:36 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Slight technical glitch Message-ID: <3ce493449%kbracey@kbracey.acorn.co.uk> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List Well, I've just inadvertantly deleted all my MNG stuff. At least it was only about half a week's work, I suppose. I'll have to see about recreating my MNGeye bug list too. Ho hum. -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Wed May 19 06:11:17 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id GAA13311; Wed, 19 May 1999 06:11:17 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id GAA22019 for mpng-list-out-eY3f3Qzu; Wed, 19 May 1999 06:11:13 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id GAA22015 for ; Wed, 19 May 1999 06:11:12 -0500 (CDT) Received: from glennrp.netgsi.com (p1-4.netgsi.com [209.150.125.4]) by mail.netgsi.com (Postfix) with SMTP id CF08F18805 for ; Wed, 19 May 1999 07:11:11 -0400 (EDT) Message-Id: <1.5.4.32.19990519111048.016f66c4@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, 19 May 1999 07:10:48 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: Slight technical glitch Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 10:15 AM 5/19/99 +0100, you wrote: >Well, I've just inadvertantly deleted all my MNG stuff. At least it was only >about half a week's work, I suppose. Acorns don't have a "yesterday" directory? Too bad. But it's nice that there will be still one more MNG beta test. Consider the half-week (that's about 50 hours, right?) as an alpha. Thanks for all your work anyway, because it gave some food for thought about DEFI, etc. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Wed May 19 14:39:12 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id OAA18329; Wed, 19 May 1999 14:39:12 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id OAA20159 for mpng-list-out-eY3f3Qzu; Wed, 19 May 1999 14:32:15 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.6.53]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id OAA20150 for ; Wed, 19 May 1999 14:32:13 -0500 (CDT) Received: from gerard1 (dc2-isdn2314.dial.xs4all.nl [194.109.157.10]) by smtp3.xs4all.nl (8.8.8/8.8.8) with SMTP id VAA19110 for ; Wed, 19 May 1999 21:32:12 +0200 (CEST) Message-Id: <199905191932.VAA19110@smtp3.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@ccrc.wustl.edu Date: Wed, 19 May 1999 21:35:30 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Slight technical glitch In-reply-to: <3ce493449%kbracey@kbracey.acorn.co.uk> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List > Date: Wed, 19 May 1999 10:15:36 +0100 > From: Kevin Bracey > Well, I've just inadvertantly deleted all my MNG stuff. At least it was only > about half a week's work, I suppose. > > I'll have to see about recreating my MNGeye bug list too. Amazing! I've had a similar problem while developing MNGeye. The disk I was working on was full, and when I saved the major PNG/MNG unit, Delphi didn't squeek, until I wanted to recompile, and found that half the unit had vanished into thin air. As it goes without saying my last backup was about a week old..... Hope there's no curse on MNG..... Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Wed May 19 15:07:46 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id PAA18894; Wed, 19 May 1999 15:07:45 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id PAA22072 for mpng-list-out-eY3f3Qzu; Wed, 19 May 1999 15:07:41 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from echo.sound.net ([205.242.192.21]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with SMTP id PAA22067 for ; Wed, 19 May 1999 15:07:40 -0500 (CDT) Received: (qmail 23083 invoked from network); 19 May 1999 19:43:33 -0000 Received: from mrvandy.unlimitedpotential.com (HELO mrvandy) (209.153.92.26) by echo.sound.net with SMTP; 19 May 1999 19:43:33 -0000 Message-ID: <005b01bea232$d302e780$1a5c99d1@sound.net> From: "Mike Reed" To: "MPNG List" Subject: Re: Slight technical glitch Date: Wed, 19 May 1999 15:04:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0810.800 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List Trust me, Unisys has hired every voodoo doctor and witch on the planet to hex MNG :) Just think happy thoughts and reflect those spells back onto Unisys. May the force be with you! Mike Reed Director of Research and Development Unlimited Potential, Inc. All Minds Network Project http://www.allminds.com ----- Original Message ----- From: Gerard Juyn To: Sent: Wednesday, May 19, 1999 3:35 PM Subject: Re: Slight technical glitch >> Date: Wed, 19 May 1999 10:15:36 +0100 >> From: Kevin Bracey > >> Well, I've just inadvertantly deleted all my MNG stuff. At least it was only >> about half a week's work, I suppose. >> >> I'll have to see about recreating my MNGeye bug list too. > >Amazing! I've had a similar problem while developing MNGeye. >The disk I was working on was full, and when I saved the major >PNG/MNG unit, Delphi didn't squeek, until I wanted to recompile, and >found that half the unit had vanished into thin air. As it goes >without saying my last backup was about a week old..... > >Hope there's no curse on MNG..... > > >Gerard (gjuyn@xs4all.nl) >http://www.3-t.com > >-- >Send the message body "help" to mpng-list-request@ccrc.wustl.edu > -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Wed May 19 20:59:34 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id UAA24082; Wed, 19 May 1999 20:59:34 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id UAA10019 for mpng-list-out-eY3f3Qzu; Wed, 19 May 1999 20:59:22 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mc-qout4.whowhere.com (mc-qout4.whowhere.com [209.185.123.18]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with SMTP id UAA10014 for ; Wed, 19 May 1999 20:59:21 -0500 (CDT) Received: from Unknown/Local ([?.?.?.?]) by my-dejanews.com; Wed May 19 18:59:17 1999 To: "MPNG List" Date: Wed, 19 May 1999 18:59:17 -0700 From: "Richard W. Franzen" Message-ID: Mime-Version: 1.0 X-Sent-Mail: on X-Mailer: MailCity Service Subject: Re: pn6 X-Sender-Ip: 12.77.195.184 Organization: Deja News Mail (http://www.my-dejanews.com:80) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List Gerard, The pn6 development is still alive, but it's been dormant while I've struggled thru some "day-job" work as well as an ongoing family problem. It's been hard to keep focused on extracurricular stuff. I'll let you know when pn6 has progressed to the point that there is something to test. The stupid at the end of the PNG files was (is still?) a problem with AT&T Worldnet. When I transferred files via its HTML upload mechanism, it would append to everything. It didn't garble (like ftp ASCII mode would have), but it did add the two-character suffix. Since then, I've re-uploaded all the binaries via binary ftp mode, and I think everything there is clean. I guess this might be a reason for not being totally militaristic in the Quest of MNG Purity. Sometimes there can be errors in images that have nothing to do with the image generator. Glenn's compromise of displaying what it can display, but bitching about errors, seems reasonable. (If I were doing an image display program, I wouldn't try to anticipate and fix every possible problem, but I would fix "easy" stuff, such as extra characters at the end of the file. I'd handle harder stuff with a clean exit from the display thread. In either case, the user should be informed so the author (or poster) can be notified that there is a problem.) -- -- Rich -- http://home.att.net/~rocq/png16.html -- http://home.att.net/~rocq/pngLibrary.html (PNG Gallery) -- On Wed, 19 May 1999 08:15:28 Gerard Juyn wrote: > >I did incorporate as many checks as possible. Eg. Richard Franzen >(whatever happened to pn6???) had some test-images (PNG) at a point >that didn't work. They had 0x0d/0x0A appended to the end of the >stream. Looked fine in Netscape (?!?!? One for you, Greg!) but MNGeye >rejected them with "bad chunkcode". > > >Regards, > >Gerard (gjuyn@xs4all.nl) >http://www.3-t.com -----== Sent via Deja News, The Discussion Network ==----- http://www.dejanews.com/ Easy access to 50,000+ discussion forums -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Thu May 20 01:23:01 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id BAA27342; Thu, 20 May 1999 01:23:00 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id BAA22370 for mpng-list-out-eY3f3Qzu; Thu, 20 May 1999 01:22:39 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.6.53]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id BAA22365 for ; Thu, 20 May 1999 01:22:38 -0500 (CDT) Received: from gerard1 (dc2-isdn2318.dial.xs4all.nl [194.109.157.14]) by smtp3.xs4all.nl (8.8.8/8.8.8) with SMTP id IAA26551 for ; Thu, 20 May 1999 08:22:37 +0200 (CEST) Message-Id: <199905200622.IAA26551@smtp3.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@ccrc.wustl.edu Date: Thu, 20 May 1999 08:26:02 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: pn6 In-reply-to: X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List > Date: Wed, 19 May 1999 18:59:17 -0700 > From: "Richard W. Franzen" > Gerard, > > ... (snip)... > > I guess this might be a reason for not being totally > militaristic in the Quest of MNG Purity. Sometimes > there can be errors in images that have nothing to do > with the image generator. Glenn's compromise of > displaying what it can display, but bitching about > errors, seems reasonable. (If I were doing an image > display program, I wouldn't try to anticipate and fix > every possible problem, but I would fix "easy" > stuff, such as extra characters at the end of the > file. I'd handle harder stuff with a clean exit from > the display thread. In either case, the user should > be informed so the author (or poster) can be notified > that there is a problem.) That's my intention for a next release. Errors get a severity-code which defines whether or not the user can choose to continue, or if the program aborts it's attempt with a descriptive error-message. (Eg. "W"=warning, "E"=error, or something alike) Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Thu May 20 07:17:08 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id HAA01625; Thu, 20 May 1999 07:17:07 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id HAA09288 for mpng-list-out-eY3f3Qzu; Thu, 20 May 1999 07:15:59 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id HAA09284 for ; Thu, 20 May 1999 07:15:58 -0500 (CDT) Received: from glennrp.netgsi.com (p1-23.netgsi.com [209.150.125.23]) by mail.netgsi.com (Postfix) with SMTP id 65ECF18802 for ; Thu, 20 May 1999 08:15:55 -0400 (EDT) Message-Id: <1.5.4.32.19990520121533.00ced05c@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, 20 May 1999 08:15:33 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: MNG LOOP caching Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List The "user-discretion" and other discretionary LOOPs were established at MNG draft 36, 19970219. Prior to that, there was a "loop_effect" flag that could be used to guarantee that each iteration of the loop would produce the same sequence of images. Is it safe for a decoder to assume that, when termination_condition is nonzero, each iteration of the loop will produce the same sequence of images? This is a valuable piece of information. Recently Adam stated that there are two types of decoders, namely simple ones and double-buffered ones. But there is a third, which decodes the entire stream and assembles a playlist. ImageMagick works that way, and that's the way I was working with MNG when I first got started, playing them on an Abekas frame buffer. It's nice to know that the sequence of images can be cached rather than dumping the same sequence of images over and over again. As I read the current MNG spec, the termination_condition field should be nonzero only when the parent objects do not get modified by the loop (or at least they are left in the same condition upon exiting the loop). But it's also possible to say that it's "safe to change the number of loop iterations" even when the parent objects do get modified but are not used later on in the datastream. The latter type of "safe" loops would not necessarily produce the same set of images each time around the loop. Even if the assumption that "discretionary loops" are safe-to-cache, is always good, that isn't an entirely satisfactory solution, because usually the deterministic loops are going to be safe-to-cache as well. You could convey the information by using a nondeterministic termination code with iteration_max == iteration_min == repeat_count, but who would do that? One possible solution to this would be to add a safe-to-cache bit to the termination_condition field: 0 or omitted: deterministic, not safe-to-cache 1: decoder discretion, not safe-to-cache 2: user discretion, not safe-to-cache 3: external signal, not safe-to-cache 4: deterministic, safe-to-cache 5: decoder discretion, safe-to-cache 6: user discretion, safe-to-cache 7: external signal, safe-to-cache It would really be preferable for 0-3 to be safe-to-cache and 4-7 to be not-safe-to-cache, so deterministic-safe-to-cache would be the default, but that wouldn't be backward compatible with MNG-0.95. Incidentally, the loop created by TERM is naturally safe-to-cache, and ImageMagick does cache that one. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Thu May 20 13:34:04 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id NAA08215; Thu, 20 May 1999 13:34:04 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id NAA29497 for mpng-list-out-eY3f3Qzu; Thu, 20 May 1999 13:33:57 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.6.53]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id NAA29493 for ; Thu, 20 May 1999 13:33:55 -0500 (CDT) Received: from gerard1 (dc2-isdn2256.dial.xs4all.nl [194.109.156.208]) by smtp3.xs4all.nl (8.8.8/8.8.8) with SMTP id UAA21748 for ; Thu, 20 May 1999 20:33:54 +0200 (CEST) Message-Id: <199905201833.UAA21748@smtp3.xs4all.nl> Comments: Authenticated sender is From: "Gerard Juyn" To: mpng-list@ccrc.wustl.edu Date: Thu, 20 May 1999 20:37:26 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: MNG LOOP caching In-reply-to: <1.5.4.32.19990520121533.00ced05c@netgsi.com> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List > Date: Thu, 20 May 1999 08:15:33 -0400 > From: Glenn Randers-Pehrson > Incidentally, the loop created by TERM is naturally safe-to-cache, > and ImageMagick does cache that one. Safe? What about a headline banner of say 2048 pixels, that scrolls slowly accross a 640-pixel image-window (using MOVE&SHOW). That would require a heap of cache.... Gerard (gjuyn@xs4all.nl) http://www.3-t.com -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 21 04:58:37 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id EAA20765; Fri, 21 May 1999 04:58:37 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id EAA15844 for mpng-list-out-eY3f3Qzu; Fri, 21 May 1999 04:57:59 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id EAA15839 for ; Fri, 21 May 1999 04:57:57 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id KAA16725 for ; Fri, 21 May 1999 10:57:55 +0100 (BST) Date: Fri, 21 May 1999 10:57:02 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Re: MNG LOOP caching Message-ID: <555b9f549%kbracey@kbracey.acorn.co.uk> In-Reply-To: <1.5.4.32.19990520121533.00ced05c@netgsi.com> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List In message <1.5.4.32.19990520121533.00ced05c@netgsi.com> Glenn Randers-Pehrson wrote: > > Incidentally, the loop created by TERM is naturally safe-to-cache, > and ImageMagick does cache that one. > I don't think it is, you know. Example (albeit pretty contrived): MHDR DEFI 1 abstract IHDR ... # very slightly opaque image IEND SAVE TERM 3 500 times SEEK SHOW 1 MEND I'd agree that it's safe if immediately after MHDR. (Spec notes: if not before SEEK, TERM must follow MHDR immediately (4.3.6). cf 4.5.3 "nEED ... preferably immediately after MHDR" - how about "very shortly after the MHDR chunk". 15.13 & 15.14 - both write BACK before TERM.) -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 21 07:03:07 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id HAA22017; Fri, 21 May 1999 07:03:06 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id GAA21230 for mpng-list-out-eY3f3Qzu; Fri, 21 May 1999 06:55:58 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id GAA21226 for ; Fri, 21 May 1999 06:55:57 -0500 (CDT) Received: from glennrp.netgsi.com (p1-12.netgsi.com [209.150.125.12]) by mail.netgsi.com (Postfix) with SMTP id 014CF1880B for ; Fri, 21 May 1999 07:55:56 -0400 (EDT) Message-Id: <1.5.4.32.19990521115534.016f3fe4@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, 21 May 1999 07:55:34 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG LOOP caching Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 10:57 AM 5/21/99 +0100, you wrote: >In message <1.5.4.32.19990520121533.00ced05c@netgsi.com> > Glenn Randers-Pehrson wrote: > >> >> Incidentally, the loop created by TERM is naturally safe-to-cache, >> and ImageMagick does cache that one. >> > >I don't think it is, you know. > >Example (albeit pretty contrived): > > MHDR > DEFI 1 abstract > IHDR > ... # very slightly opaque image > IEND > SAVE > TERM 3 500 times > SEEK > SHOW 1 > MEND > >I'd agree that it's safe if immediately after MHDR. Hmmm. That's violating the spirit, if not the letter, of the SAVE/SEEK mechanism. The original idea, seemingly lost somewhere along the line, was that the SEEK chunk marked a point at which the remaining stream depends on nothing other than what appears before SAVE. In this example, it depends on the modifications to contents of the output buffer that were done in the previous segment (conceptually, after unrolling TERM, there are 500 segments). I interpret "information" in "Applications must not use any information" in 4.4.2 to include any modifications of the output buffer. We don't want to impose a requirement to *restore* the output buffer, but we should explicitly state a requirement not to *depend* on prior changes to the contents of the output buffer, when a SEEK chunk is found. Incidentally, would the example work any differently if TERM were at the beginning, and SAVE/SEEK weren't present? That would be legal regardless of this armwaving about SAVE/SEEK. It looks to me as though it would still just keep making the image more and more opaque, whether or not the application were caching the frames. But if "restarting the animation" in TERM implies "restore the background to its original condition, then replay the animation from here", then either way would produce the (I suppose) intended result. >cf 4.5.3 "nEED ... preferably immediately after MHDR" - how about "very >shortly after the MHDR chunk". Yes, that's better. > >15.13 & 15.14 - both write BACK before TERM.) Will fix. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 21 07:40:49 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id HAA22312; Fri, 21 May 1999 07:40:48 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id HAA22999 for mpng-list-out-eY3f3Qzu; Fri, 21 May 1999 07:33:45 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id HAA22994 for ; Fri, 21 May 1999 07:33:43 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id NAA19100 for ; Fri, 21 May 1999 13:33:43 +0100 (BST) Date: Fri, 21 May 1999 13:33:33 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Re: MNG LOOP caching Message-ID: <78afad549%kbracey@kbracey.acorn.co.uk> In-Reply-To: <1.5.4.32.19990521115534.016f3fe4@netgsi.com> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List In message <1.5.4.32.19990521115534.016f3fe4@netgsi.com> Glenn Randers-Pehrson wrote: > At 10:57 AM 5/21/99 +0100, you wrote: > >In message <1.5.4.32.19990520121533.00ced05c@netgsi.com> > > Glenn Randers-Pehrson wrote: > > > >> > >> Incidentally, the loop created by TERM is naturally safe-to-cache, > >> and ImageMagick does cache that one. > >> > > > >I don't think it is, you know. > > > >Example (albeit pretty contrived): > > > > MHDR > > DEFI 1 abstract > > IHDR > > ... # very slightly opaque image > > IEND > > SAVE > > TERM 3 500 times > > SEEK > > SHOW 1 > > MEND > > > >I'd agree that it's safe if immediately after MHDR. > > Hmmm. That's violating the spirit, if not the letter, of the SAVE/SEEK > mechanism. The original idea, seemingly lost somewhere along the line, > was that the SEEK chunk marked a point at which the remaining stream > depends on nothing other than what appears before SAVE. In this > example, it depends on the modifications to contents of the output buffer > that were done in the previous segment (conceptually, after unrolling > TERM, there are 500 segments). > > I interpret "information" in "Applications must not use any > information" in 4.4.2 to include any modifications of the output buffer. > > We don't want to impose a requirement to *restore* the output buffer, > but we should explicitly state a requirement not to *depend* on prior > changes to the contents of the output buffer, when a SEEK chunk is found. So you'd basically be making it a requirement that the first frame after a SEEK must completely cover the previous frame - ie have a background layer or fill the output buffer with opaque data. Hmmm. Not sure about that. I add a statement that on resuming a SEEK chunk after a random access or rewinding to TERM, the contents of the frame buffer are undefined. That would allow caching viewers to work in that case, and would force image authors to be careful. > > Incidentally, would the example work any differently if TERM were at the > beginning, and SAVE/SEEK weren't present? That would be legal regardless > of this armwaving about SAVE/SEEK. It looks to me as though it > would still just keep making the image more and more opaque, whether > or not the application were caching the frames. But if "restarting the > animation" in TERM implies "restore the background to its original > condition, then replay the animation from here", then either way would > produce the (I suppose) intended result. If the TERM is at the start, then you would be restarting the animation, including redrawing the initial background layer - so it wouldn't get any darker. I think. Maybe it should do that in this example too? Is that SHOW 1 the "first frame" in a repeat - if it is you would have to show the background layer anyway? How about on random access to any SEEK it is suggested that a background layer be inserted - ie it be treated as a "first frame". Players playing sequentially would not do this, so image authors would have to effectively take care to not rely on the object buffer at that point. -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 21 08:32:45 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id IAA22640; Fri, 21 May 1999 08:32:44 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id IAA25423 for mpng-list-out-eY3f3Qzu; Fri, 21 May 1999 08:25:40 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id IAA25419 for ; Fri, 21 May 1999 08:25:39 -0500 (CDT) Received: from glennrp.netgsi.com (p1-12.netgsi.com [209.150.125.12]) by mail.netgsi.com (Postfix) with SMTP id BCBF91881D for ; Fri, 21 May 1999 09:25:38 -0400 (EDT) Message-Id: <1.5.4.32.19990521132516.01714d50@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, 21 May 1999 09:25:16 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG LOOP caching Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 01:33 PM 5/21/99 +0100, you wrote: >So you'd basically be making it a requirement that the first frame after >a SEEK must completely cover the previous frame - ie have a background layer >or fill the output buffer with opaque data. Hmmm. Not sure about that. Not quite. It would have to cover any pixels that are disturbed by other segments. See 10.8, subframe clipping boundaries, which might need some additional wording about the effect of SEEK. There's already a requirement that decoders that jump or seek to a segment must insert a background layer (4.3.2; this requirement should be restated or at least crossreferenced in 4.4.2). The problem that viewers must address is when the BACK is missing, advisory, or defines a transparent image. > >I add a statement that on resuming a SEEK chunk after a random access or >rewinding to TERM, the contents of the frame buffer are undefined. That's accurate, if BACK doesn't cover all pixels that can be disturbed by any other segment. >That would >allow caching viewers to work in that case, and would force image authors to >be careful. [...] > >How about on random access to any SEEK it is suggested that a background >layer be inserted - ie it be treated as a "first frame". Players playing >sequentially would not do this, so image authors would have to effectively >take care to not rely on the object buffer at that point. It's in there, *required* not suggested (4.3.2); see above. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 21 08:43:12 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id IAA22741; Fri, 21 May 1999 08:43:11 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id IAA26439 for mpng-list-out-eY3f3Qzu; Fri, 21 May 1999 08:43:09 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id IAA26435 for ; Fri, 21 May 1999 08:43:08 -0500 (CDT) Received: from glennrp.netgsi.com (p1-12.netgsi.com [209.150.125.12]) by mail.netgsi.com (Postfix) with SMTP id 44FF71880F for ; Fri, 21 May 1999 09:43:06 -0400 (EDT) Message-Id: <1.5.4.32.19990521134245.00cf7e50@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, 21 May 1999 09:42:45 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG LOOP caching Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 08:37 PM 5/20/99 +0100, you wrote: >> Date: Thu, 20 May 1999 08:15:33 -0400 >> From: Glenn Randers-Pehrson > >> Incidentally, the loop created by TERM is naturally safe-to-cache, >> and ImageMagick does cache that one. > >Safe? What about a headline banner of say 2048 pixels, that scrolls >slowly accross a 640-pixel image-window (using MOVE&SHOW). >That would require a heap of cache.... So would any MNG with a non-cacheable infinite loop... The SGI running ImageMagick says [out of swap space, plonk] if there are too many large frames. A browser wouldn't want to use this cache-everything strategy. Any decoder that renders to a finite resource (pixmaps in memory, a sequence of PNG files, a DVD recorder, an ABEKAS frame buffer, or whatnot) will have trouble with large loops. It can look at the MHDR frame_count and decide to not even try, or to use a different strategy, if frame_count is too large. But do you think making the TERM loop non-cacheable would improve the situation? If it weren't, then the decoder would have to unroll TERM as well as the LOOPs. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 21 09:57:53 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id JAA23515; Fri, 21 May 1999 09:57:53 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id JAA00953 for mpng-list-out-eY3f3Qzu; Fri, 21 May 1999 09:57:35 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id JAA00948 for ; Fri, 21 May 1999 09:57:33 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id PAA20312 for ; Fri, 21 May 1999 15:57:18 +0100 (BST) Date: Fri, 21 May 1999 15:56:15 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Re: MNG LOOP caching Message-ID: <2cc0ba549%kbracey@kbracey.acorn.co.uk> In-Reply-To: <1.5.4.32.19990521132516.01714d50@netgsi.com> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List In message <1.5.4.32.19990521132516.01714d50@netgsi.com> Glenn Randers-Pehrson wrote: > There's already a requirement that decoders that jump or seek to > a segment must insert a background layer (4.3.2; this requirement > should be restated or at least crossreferenced in 4.4.2). The > problem that viewers must address is when the BACK is missing, > advisory, or defines a transparent image. > Is that a problem? I assumed that if BACK was advisory or transparent, you still had to come up with something solid as your background layer. If that's not the case, then this: MHDR FRAM 3 BACK image 2 mandatory DEFI 2 IHDR ... <20% opaque black> IEND DEFI 1 IHDR ... IEND LOOP 1 infinity MOVE 1 to 0 200 LOOP 2 200 SHOW 1 MOVE 1 by +1 0 ENDL 2 ENDL 1 MEND would result in a moving sprite leaving a ghosted fading trail on a black background. I don't think that's right - I'd interpret the spec as this being a sprite moving backwards and forwards on top of a dark rectangle superimposed on (say) the web page background. Each time you put in a background layer, you notionally put in your own (solid) background, then the BACK background. So the overall background layer is totally opaque, in as much as it obscures the previous frames - even if it cunningly matches the real background to make the MNG look transparent. > > It's in there, *required* not suggested (4.3.2); see above. > Am I being dim? I can't see this anywhere. Ah, just found it. Missed that totally before - it really should be mentioned in 4.4.2. -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 21 14:34:26 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id OAA27604; Fri, 21 May 1999 14:34:26 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id OAA16006 for mpng-list-out-eY3f3Qzu; Fri, 21 May 1999 14:34:13 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id OAA16001 for ; Fri, 21 May 1999 14:34:12 -0500 (CDT) Received: from glennrp.netgsi.com (p1-29.netgsi.com [209.150.125.29]) by mail.netgsi.com (Postfix) with SMTP id 366BA18803 for ; Fri, 21 May 1999 15:34:10 -0400 (EDT) Message-Id: <1.5.4.32.19990521193347.016efd98@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, 21 May 1999 15:33:47 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG LOOP caching Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 03:56 PM 5/21/99 +0100, you wrote: >In message <1.5.4.32.19990521132516.01714d50@netgsi.com> > Glenn Randers-Pehrson wrote: > >> There's already a requirement that decoders that jump or seek to >> a segment must insert a background layer (4.3.2; this requirement >> should be restated or at least crossreferenced in 4.4.2). The >> problem that viewers must address is when the BACK is missing, >> advisory, or defines a transparent image. >> > >Is that a problem? I assumed that if BACK was advisory or transparent, >you still had to come up with something solid as your background layer. >If that's not the case, then this: > > MHDR > FRAM 3 > BACK image 2 mandatory > DEFI 2 > IHDR > ... <20% opaque black> > IEND > DEFI 1 > IHDR > ... > IEND > LOOP 1 infinity > MOVE 1 to 0 200 > LOOP 2 200 > SHOW 1 > MOVE 1 by +1 0 > ENDL 2 > ENDL 1 > MEND > >would result in a moving sprite leaving a ghosted fading trail on a black >background. I don't think that's right - I'd interpret the spec as this being >a sprite moving backwards and forwards on top of a dark rectangle >superimposed on (say) the web page background. You do need to have a solid background, but you could capture the web page background at the start and use that as your MNG background, refreshing it as you go. Or if you are rendering offscreen you could end up with a transparent or alpha-translucent frame (an X pixmap, for example) that you then display against whatever you want. An example file with a sprite moving over a transparent background is "crows.mng" (also "crows.gif") at http://www.rpi.edu/~randeg/IM (I don't know the copyright status of crows.gif. The other two images there, flag.gif and opposum.png, are OK -- the flag.gif is from the whitehouse.gov site and oppossum.png is (C) Christopher Randers-Pehrson, 1995, permission granted to use freely for any purpose). The GIF has three crows (colour index 1) flying around over a rectangle, (colour index 0) with the background being colour index 0 and the transparent colour also being colour index 0. The palette has two entries, both (0,0,0). The disposal method is "restore-to-background", which I think is intended to mean "restore-to-transparent". Crows.mng is the result of using ImageMagick's "convert crows.gif crows.mng". ImageMagick is able to display the MNG by using its own background colour, which is a mid gray. It displays the GIF against whatever is behind the image, but it leaves trails of crows. NETSCAPE displays what the author apparently intended: three black crows flying around over the web page background, without leaving trails. I've mostly purged IE from my system so I don't know how it does with the page. >Each time you put in a background layer, you notionally put in your own >(solid) background, then the BACK background. So the overall background >layer is totally opaque, in as much as it obscures the previous frames - >even if it cunningly matches the real background to make the MNG look >transparent. By (solid) you mean opaque, right? Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Sun May 23 19:08:33 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id TAA02578; Sun, 23 May 1999 19:08:33 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id TAA18524 for mpng-list-out-eY3f3Qzu; Sun, 23 May 1999 19:07:37 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id TAA18515 for ; Sun, 23 May 1999 19:07:27 -0500 (CDT) Received: from glennrp.netgsi.com (p1-43.netgsi.com [209.150.125.43]) by mail.netgsi.com (Postfix) with SMTP id 909BD18809 for ; Sun, 23 May 1999 20:07:22 -0400 (EDT) Message-Id: <1.5.4.32.19990524000659.00cfde9c@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, 23 May 1999 20:06:59 -0400 To: mpng-list@ccrc.wustl.edu From: Glenn Randers-Pehrson Subject: ImageMagick 4.2.6 Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List If any of you are working with the MNG decoder in ImageMagick 4.2.6, please delete the "FreeMemory" statement immediately following the "if(strncmp(type,"MEND",4)==0)" statement. That chunk of memory hasn't been allocated yet. (Before anyone complains about my using strncmp, be assured that I've already changed over to !png_memcmp with a set of mng_NAME arrays, so the next update will work with all those EBCDIC implementations as well.) Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 24 03:53:08 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id DAA08601; Mon, 24 May 1999 03:53:08 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id DAA12911 for mpng-list-out-eY3f3Qzu; Mon, 24 May 1999 03:52:47 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id DAA12905 for ; Mon, 24 May 1999 03:52:44 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id JAA15905 for ; Mon, 24 May 1999 09:52:42 +0100 (BST) Date: Mon, 24 May 1999 09:51:56 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Re: MNG LOOP caching Message-ID: <4be724749%kbracey@kbracey.acorn.co.uk> In-Reply-To: <1.5.4.32.19990521193347.016efd98@netgsi.com> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List In message <1.5.4.32.19990521193347.016efd98@netgsi.com> Glenn Randers-Pehrson wrote: > At 03:56 PM 5/21/99 +0100, you wrote: > >In message <1.5.4.32.19990521132516.01714d50@netgsi.com> > > Glenn Randers-Pehrson wrote: > > > >> There's already a requirement that decoders that jump or seek to > >> a segment must insert a background layer (4.3.2; this requirement > >> should be restated or at least crossreferenced in 4.4.2). The > >> problem that viewers must address is when the BACK is missing, > >> advisory, or defines a transparent image. > >> > > > >Is that a problem? I assumed that if BACK was advisory or transparent, [snip example] > > You do need to have a solid background, but you could capture the > web page background at the start and use that as your MNG background, > refreshing it as you go. Or if you are rendering offscreen you > could end up with a transparent or alpha-translucent frame (an X > pixmap, for example) that you then display against whatever you want. > [snip explanation] Which is how I understood it, yes. So what exactly is the problem that viewers must address when seeking? It's nothing harder than the usual framing mode 3 clear, is it? -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 24 03:55:53 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id DAA08663; Mon, 24 May 1999 03:55:52 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id DAA13011 for mpng-list-out-eY3f3Qzu; Mon, 24 May 1999 03:55:50 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id DAA13006 for ; Mon, 24 May 1999 03:55:48 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id JAA15918 for ; Mon, 24 May 1999 09:55:47 +0100 (BST) Date: Mon, 24 May 1999 09:55:45 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Re: ImageMagick 4.2.6 Message-ID: <44125749%kbracey@kbracey.acorn.co.uk> In-Reply-To: <1.5.4.32.19990524000659.00cfde9c@netgsi.com> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List In message <1.5.4.32.19990524000659.00cfde9c@netgsi.com> Glenn Randers-Pehrson wrote: > If any of you are working with the MNG decoder in ImageMagick > 4.2.6, please delete the "FreeMemory" statement immediately > following the "if(strncmp(type,"MEND",4)==0)" statement. That > chunk of memory hasn't been allocated yet. > > (Before anyone complains about my using strncmp, be assured that > I've already changed over to !png_memcmp with a set of mng_NAME > arrays, so the next update will work with all those EBCDIC > implementations as well.) > I've always favoured conversion to the local character set immediately. Makes it easier: const char upper[26] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"; const char lower[26] = "abcdefghijklmnopqrstuvwxyz"; for (i=0; i<4; i++) { if (chunk_name[i] >= 0x41 && chunk_name[i] <= 0x5A) chunk_name[i] = upper[chunk_name[i]-0x41]; else if (chunk_name[i] >= 0x61 && chunk_name[i] <= 0x7A) chunk_name[i] = lower[chunk_name[i]-0x61]; else error("Invalid chunk name"); } or something along those lines. You can then proceed to strcmp and printf chunk names to your hearts content. -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 24 06:03:54 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id GAA09950; Mon, 24 May 1999 06:03:54 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id GAA19398 for mpng-list-out-eY3f3Qzu; Mon, 24 May 1999 06:03:40 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id GAA19393 for ; Mon, 24 May 1999 06:03:39 -0500 (CDT) Received: from glennrp.netgsi.com (p1-43.netgsi.com [209.150.125.43]) by mail.netgsi.com (Postfix) with SMTP id 9842A18801 for ; Mon, 24 May 1999 07:03:38 -0400 (EDT) Message-Id: <1.5.4.32.19990524110314.016ee310@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, 24 May 1999 07:03:14 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: MNG LOOP caching Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 09:51 AM 5/24/99 +0100, you wrote: >In message <1.5.4.32.19990521193347.016efd98@netgsi.com> > Glenn Randers-Pehrson wrote: > >> At 03:56 PM 5/21/99 +0100, you wrote: >> >In message <1.5.4.32.19990521132516.01714d50@netgsi.com> >> > Glenn Randers-Pehrson wrote: >> > >> >> There's already a requirement that decoders that jump or seek to >> >> a segment must insert a background layer (4.3.2; this requirement >> >> should be restated or at least crossreferenced in 4.4.2). The >> >> problem that viewers must address is when the BACK is missing, >> >> advisory, or defines a transparent image. >> >> >> > >> >Is that a problem? I assumed that if BACK was advisory or transparent, > >[snip example] > >> >> You do need to have a solid background, but you could capture the >> web page background at the start and use that as your MNG background, >> refreshing it as you go. Or if you are rendering offscreen you >> could end up with a transparent or alpha-translucent frame (an X >> pixmap, for example) that you then display against whatever you want. >> > >[snip explanation] > >Which is how I understood it, yes. So what exactly is the problem that >viewers must address when seeking? It's nothing harder than the usual >framing mode 3 clear, is it? Right, maybe it's not a "problem" but just something to think about. When a pixel isn't covered by anything in MNG, the application has to decide what to do with it. What should the following complete stream look like? MHDR 100 100 1 1 1 1 1 MEND ImageMagick 4.2.6 incorrectly rejects such a stream, but I've fixed that in the next version, to display a transparent rectangle with the "animate" command. What should single-image viewers do with it? They are supposed to display the first image found in the file. I'm still rejecting the file with ImageMagick's "display" single-image viewer. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Mon May 24 07:10:41 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id HAA10597; Mon, 24 May 1999 07:10:41 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id HAA22484 for mpng-list-out-eY3f3Qzu; Mon, 24 May 1999 07:10:15 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id HAA22479 for ; Mon, 24 May 1999 07:10:14 -0500 (CDT) Received: from glennrp.netgsi.com (p1-43.netgsi.com [209.150.125.43]) by mail.netgsi.com (Postfix) with SMTP id 3AE8118801 for ; Mon, 24 May 1999 08:10:13 -0400 (EDT) Message-Id: <1.5.4.32.19990524120950.00cee354@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, 24 May 1999 08:09:50 -0400 To: MPNG List From: Glenn Randers-Pehrson Subject: Re: ImageMagick 4.2.6 Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List At 09:55 AM 5/24/99 +0100, you wrote: >> (Before anyone complains about my using strncmp [...] >I've always favoured conversion to the local character set immediately. >Makes it easier: > >const char upper[26] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"; >const char lower[26] = "abcdefghijklmnopqrstuvwxyz"; > >for (i=0; i<4; i++) >{ > if (chunk_name[i] >= 0x41 && chunk_name[i] <= 0x5A) > chunk_name[i] = upper[chunk_name[i]-0x41]; > else if (chunk_name[i] >= 0x61 && chunk_name[i] <= 0x7A) > chunk_name[i] = lower[chunk_name[i]-0x61]; > else > error("Invalid chunk name"); >} Thanks, I'm using your code for printing out the chunknames when running in verbose mode. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Thu May 27 04:06:05 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id EAA18983; Thu, 27 May 1999 04:06:04 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id EAA05281 for mpng-list-out-eY3f3Qzu; Thu, 27 May 1999 04:04:50 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id EAA05271 for ; Thu, 27 May 1999 04:04:37 -0500 (CDT) Received: from kbracey (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id KAA05939 for ; Thu, 27 May 1999 10:04:27 +0100 (BST) Date: Thu, 27 May 1999 10:03:49 +0100 From: Kevin Bracey To: mpng-list@ccrc.wustl.edu Subject: Re: ImageMagick 4.2.6 Message-ID: In-Reply-To: <1.5.4.32.19990524120950.00cee354@netgsi.com> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List > >const char upper[26] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"; > >const char lower[26] = "abcdefghijklmnopqrstuvwxyz"; > > [snip] I've just had one thought - those two lines, while legal ISO C, will give warnings on my C compiler, and are actually invalid C++, if I recall correctly. (ISO C allows suppression of the terminating null from the string to fit it into the array). Remove the "26"s and it it will be fine. -- Kevin Bracey, Senior Software Engineer Acorn Computers Ltd Tel: +44 (0) 1223 725228 Acorn House, 645 Newmarket Road Fax: +44 (0) 1223 725328 Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/ -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Thu May 27 15:54:03 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id PAA01875; Thu, 27 May 1999 15:54:03 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id PAA11308 for mpng-list-out-eY3f3Qzu; Thu, 27 May 1999 15:53:38 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from arwen.cs.berkeley.edu (arwen.CS.Berkeley.EDU [128.32.33.72]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id PAA11303 for ; Thu, 27 May 1999 15:53:37 -0500 (CDT) Received: by arwen.cs.berkeley.edu via sendmail from stdin id (Debian Smail3.2.0.102) for mpng-list@ccrc.wustl.edu; Thu, 27 May 1999 20:53:37 +0000 (GMT) Received: from mc-qout4.whowhere.com (mc-qout4.whowhere.com [209.185.123.18]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with SMTP id HAA14004 for ; Thu, 27 May 1999 07:17:10 -0500 (CDT) Received: from Unknown/Local ([?.?.?.?]) by my-deja.com; Thu May 27 05:17:03 1999 To: "MPNG List" Date: Thu, 27 May 1999 05:17:03 -0700 From: "Richard W. Franzen" Message-ID: Mime-Version: 1.0 X-Sent-Mail: on X-Mailer: MailCity Service Subject: Re: ImageMagick 4.2.6 X-Sender-Ip: 12.77.194.159 Organization: deja.com Mail (http://www.my-deja.com:80) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List For cross-platform work, I usually make sure any permanent elements (globals, statics, const's, etc) take up mod4 in space. So another way to handle it is to have upper[28] and lower[28]. One reason for this is that, having examined assembler output over the years, permanent elements tend to get placed on mod4 boundaries anyway. This is especially true of data alignment within structures, but it is the tendency for individual element alignment as well. Of course, now that many cpu's are becoming 64-bit, perhaps rethinking my strategy and going to mod8 for everything... Naah, probably not. -- -- Rich -- http://home.att.net/~rocq/pngBase.html -- On Thu, 27 May 1999 10:03:49 Kevin Bracey wrote: >> >const char upper[26] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"; >> >const char lower[26] = "abcdefghijklmnopqrstuvwxyz"; >> > > >[snip] > >I've just had one thought - those two lines, while legal ISO C, will give >warnings on my C compiler, and are actually invalid C++, if I recall >correctly. (ISO C allows suppression of the terminating null from the string >to fit it into the array). > >Remove the "26"s and it it will be fine. > >-- >Kevin Bracey, Senior Software Engineer --== Sent via Deja.com http://www.deja.com/ ==-- Share what you know. Learn what you don't. -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu From owner-mpng-list@ccrc.wustl.edu Fri May 28 11:45:48 1999 Received: from ccrc.wustl.edu (cashew.ccrc.wustl.edu [128.252.169.100]) by swrinde.nde.swri.edu (8.9.3/8.9.3) with ESMTP id LAA21232; Fri, 28 May 1999 11:45:47 -0500 (CDT) Received: (from majordom@localhost) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) id LAA13472 for mpng-list-out-eY3f3Qzu; Fri, 28 May 1999 11:44:54 -0500 (CDT) X-Authentication-Warning: cashew.wustl.edu: majordom set sender to owner-mpng-list@ccrc.wustl.edu using -f Received: from mail.netgsi.com (grok.netgsi.com [192.55.203.19]) by ccrc.wustl.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA13462 for ; Fri, 28 May 1999 11:44:44 -0500 (CDT) Received: from glennrp.netgsi.com (p1-43.netgsi.com [209.150.125.43]) by mail.netgsi.com (Postfix) with SMTP id 7D78918828 for ; Fri, 28 May 1999 12:44:30 -0400 (EDT) Message-Id: <1.5.4.32.19990528164405.01708910@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, 28 May 1999 12:44:05 -0400 To: mpng-list@ccrc.wustl.edu From: Glenn Randers-Pehrson Subject: CFD: MNG-0.95a and 0.95b, 19990527 Sender: owner-mpng-list@ccrc.wustl.edu Precedence: bulk Reply-To: MPNG List I've uploaded a bunch of new files to ftp://swrinde.nde.swri.edu/pub/mng/documents (also installed at http://www.cdrom.com/pub/mng) The 0.95a series are an update from MNG-0.95 with editorial changes and clarifications that do not require a vote. The 0.95b series also includes the things that Kevin and I uncovered during our beta implementation work. Since these are technical changes to the spec, we will need to vote on these. There are no jng-0.95b or mng-vlc-0.95b documents because JNG and MNG-VLC weren't affected by the proposed changes. Essentially, the changes proposed are It is no longer illegal to present SHOW or CLON with a nonviewable object. In such cases, CLON makes a clone but does not display it, even when "do_not_show==visible", and SHOW simply ignores it. A "cacheable" bit has been added to the "termination_condition" byte of the LOOP chunk. Objects "come into existence" when the DEFI chunk is processed, instead of when its embedded image is processed. An object that has no object buffer is "nonviewable" until it receives one. Object 0 always exists, and can be the subject of MOVE and CLIP chunks. It is "nonviewable" except while processing its embedded image. Object 0 never becomes "frozen". Object 0 retains its object attributes, like any other object, instead of immediately resetting them to the defaults after the embedded image has been processed. Fields that are omitted from the DEFI chunk retain the values from the previous DEFI chunk with the same object_id, instead of being reset to default values. This is the call-for-discussion of the proposed MNG-0.95b changes. The normative reference is mng-0.95b-19990527-pdg.html; the other documents are just for convenience. Speaking of which, I also uploaded a series of *-update-0.95-to-0.95a.txt.gz and *-update-0.95a-to-0.95b.txt.gz files (context diffs), if you'd prefer to concentrate on the differences. It looks like a lot of changes, but in ImageMagick, the only real effect was to *remove* a few lines of code that handled the special case of object 0. I had to change the "paleo_d63.mng" file because it was depending on the attributes of object 0 being reset to the defaults, which causes one of the images to be placed in the wrong location. I think the changes are all good ones. The only real reason I can see for voting against them would be on the general principle that it's too late to make such changes, when we promised to freeze the design before we did any beta work. Glenn -- Send the message body "help" to mpng-list-request@ccrc.wustl.edu