From owner-mpng-list@dworkin.wustl.edu Tue Mar 5 12:29:09 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA11213 for ; Tue, 5 Mar 1996 12:29:08 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA23563 for mpng-list-outgoing; Tue, 5 Mar 1996 12:30:11 -0600 Received: from siesta.cs.wustl.edu (siesta.cs.wustl.edu [128.252.165.3]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id MAA23558 for ; Tue, 5 Mar 1996 12:30:08 -0600 Received: by siesta.cs.wustl.edu (5.x/ECL-A1.27) id AA07149; Tue, 5 Mar 1996 18:28:42 GMT Date: Tue, 5 Mar 1996 18:28:42 GMT From: amc@cs.wustl.edu (Adam M. Costello) Message-Id: <9603051828.AA07149@siesta.cs.wustl.edu> To: mpng-list@dworkin.wustl.edu Subject: welcome to mpng-list Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List mpng-list@dworkin.wustl.edu should be operational now. You may unsubscribe yourself by sending mail to mpng-list-request@dworkin.wustl.edu (NOT to mpng-list@dworkin.wustl.edu) with the message body "unsubscribe". If there are bugs, I won't be able to fix them until later tonight or tomorrow, so someone will have to take it upon himself to say, "Please stop using mpng-list until we hear from Adam again." AMC ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Tue Mar 5 13:15:32 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA11814 for ; Tue, 5 Mar 1996 13:15:31 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA24463 for mpng-list-outgoing; Tue, 5 Mar 1996 13:16:52 -0600 Received: from tide10.microsoft.com (tide10.microsoft.com [131.107.3.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA24457 for ; Tue, 5 Mar 1996 13:16:48 -0600 Received: by tide10.microsoft.com; id LAA02237; Tue, 5 Mar 1996 11:15:37 -0800 Received: from unknown(157.54.17.74) by tide10.microsoft.com via smap (g3.0.3) id xma002234; Tue, 5 Mar 96 11:15:18 -0800 Received: from xnet2 (xnet2.microsoft.com [157.54.17.205]) by imail2.microsoft.com (8.7.3/8.7.1) with SMTP id LAA15277 for ; Tue, 5 Mar 1996 11:18:59 -0800 (PST) X-Received: from cup-01-msg by xnet2 with receive; Tue, 5 Mar 1996 11:14:46 -0800 X-MSMail-Message-ID: E87C2FC0 X-MSMail-Conversation-ID: E87C2FC0 From: John Bowler To: mpng-list@dworkin.wustl.edu Date: Tue, 5 Mar 96 11:13:10 PST Subject: Re: multi-image format X-MsXMTID: cup-01-msg960305191506MTP[01.52.00]00000094-2270 Message-Id: cup-01-msg960305191506MTP[01.52.00]00000094-2270 Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Andrea writes:- | Actually, I think we need deltas in spite of having an alpha channel. What | if we want to do something like send the initial image (whatever the | contents) with full transparency, and then the delta frame, applied | repeatedly, would reduce the transparency until the image had no | transparency. It would make for an easy way to do fades, and would look | good too, since the image would fade into the current background, rather | than black or something. I think that constructing frames from groups of objects solves part of this problem - the background can have alpha as can the things on top. The result has the obvious composite alpha. The differencing between the objects which compose this "frame" and their ancestors can difference the alpha as well as the result of the pixel values - this forces use of a difference type algorithm but clearly works. There is a problem if you want transparency to be interpreted both as an image delta encoding and a pixel alpha value - in that case we need extra information in the PNG format. For true color this is a fifth one bit channel which says whether to replace the particular pixel or an encoding of the pixel values which allows pixels to be skipped. Palette images can clearly reserve a palette entry to mean "don't change me" (as opposed to "I am transparent" at the cost of one less "useful" entry in the palette. The "skip the pixels" encoding has been used before (it is defined, for example in the Windows bitmap RLE4 and RLE8 formats and this is, according to the comments in the Windows SDK, used in the AVI format for exactly this purpose). Of course this RLE form is a signficant addition to the PNG image formats - differencing and re-intepretation of transparency are clearly simple extensions, the RLE form is not a simple extension because the resultant IDAT set cannot be used to construct a rectangular pixel map (you can do this with the other forms even though the pixel map may contain "difference" values). John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Tue Mar 5 13:49:14 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA12044 for ; Tue, 5 Mar 1996 13:49:13 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA26477 for mpng-list-outgoing; Tue, 5 Mar 1996 13:49:59 -0600 Received: from tide10.microsoft.com (tide10.microsoft.com [131.107.3.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA26444 for ; Tue, 5 Mar 1996 13:49:51 -0600 Received: by tide10.microsoft.com; id LAA05350; Tue, 5 Mar 1996 11:48:41 -0800 Received: from unknown(157.54.17.74) by tide10.microsoft.com via smap (g3.0.3) id xmaa05347; Tue, 5 Mar 96 11:48:27 -0800 Received: from xnet2 (xnet2.microsoft.com [157.54.17.205]) by imail2.microsoft.com (8.7.3/8.7.1) with SMTP id LAA16970 for ; Tue, 5 Mar 1996 11:52:09 -0800 (PST) X-Received: from cup-01-msg by xnet2 with receive; Tue, 5 Mar 1996 11:47:56 -0800 X-MSMail-Message-ID: C5C2A90F X-MSMail-Conversation-ID: C5C2A90F From: John Bowler To: mpng-list@dworkin.wustl.edu Date: Tue, 5 Mar 96 11:46:40 PST Subject: Re: multi-image format X-MsXMTID: cup-01-msg960305194836MTP[01.52.00]00000094-2307 Message-Id: cup-01-msg960305194836MTP[01.52.00]00000094-2307 Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List | From: Peter da Silva | | Fading out again is hard, and opens up a whole new can of worms... it | brings up the question of what you do about moving/deleting sprites, | and requires that the display engine reconstitute the background. This | could be very hard to implement. The decoder is responsible for being able to reconstruct the background unless the stream says that the background will not be used again (in any subsequent events/objects). The decoder needs to know whether any given object will be used as the basis for difference (subtractive or other arithmetic) construction of a new object - in which case it must retain the data in its original (un-rendered) form) and whether the object is used in subsequent events or object definitions where new object just replaces pixels in the old. In the latter case the decoder need only retain the rendered form of the object. (I'm assuming "non-strict method 1" - i.e. an event may appear after an object to which it refers) When a object is composited from other objects a decoder has several options if the background is to be reused:- 1) Save the whole of the "background" object - essentially the whole current state of the frame. 2) Save the parts of the background which are overwritten. 3) Generate reverse deltas or some RLE information to allow the overwriting object to be removed. These may all sound like they have signficant overhead, but in reality they don't because the display code would almost always double-buffer the output anyway to avoid flickering on the screen (drawing a "sprite" is done offscreen then blt'ed back on). So long as MPNG does not force a particular implementation on the decoder and so long as encoders are encouraged to present information in a way which can be decoded efficiently there shouldn't be a problem. John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Wed Mar 6 20:03:05 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA02572 for ; Wed, 6 Mar 1996 20:03:04 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA25540 for mpng-list-outgoing; Wed, 6 Mar 1996 20:04:07 -0600 Received: from ellis.uchicago.edu (ellis.uchicago.edu [128.135.12.62]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA25535 for ; Wed, 6 Mar 1996 20:04:04 -0600 Received: (from roe2@localhost) by ellis.uchicago.edu (8.7.1/8.7.2) id UAA21805; Wed, 6 Mar 1996 20:02:24 -0600 (CST) Date: Wed, 6 Mar 1996 20:02:24 -0600 (CST) From: Cave Newt Message-Id: <199603070202.UAA21805@ellis.uchicago.edu> To: mpng-list@dworkin.wustl.edu Subject: Re: multi-image format Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Guys, please move this to mpng-list... > From: Peter da Silva > Subject: Re: multi-image format > To: png-list@dworkin.wustl.edu > Date: Wed, 6 Mar 1996 16:26:32 -0600 (CST) > > The hierachy is not for inheritance, merely to group a cluster of > > chunks - so we can have a PNG /object/ consisting of a cluster of PNG > > /chunks/. Otherwise, it would be hard to say which chunk applied to > > which PNG in the file. > > I called it HIER because it looks nice, and it allows hierarichacal > > (sp???) grouping of chunks - not inheritance! > Oh. I call that an "object". Hierarchical implies that you can have > objects inside objects... and I think we want to say flat out that's > not done. > I've been thinking about this business of making events and objects peers, > and there's two ways to go about that: > 1. Create an object that contains a bunch of events. > 2. Make each event an object. > I think that 1 is lower overhead and more versatile. Also, here's something > else... how about "anonymous" objects? To extend my permanent/temporary > definition, an "anonymous" object is simply the *next* object in the input > stream. The anonymous object header wouldn't have an object ID and > might possibly be missing other information. Events would generally > be anonymous objects: > ANON EVNT PUT ANON (at 0,0) > ANON PNGF > png chunks > IEND > It's not a HUGE savings, but would add up over: > SOBJ 1 > EVNT PUT 2 (at 0,0) > EOBJ > SOBJ 2 > PNGH > png chunks > IEND > EOBJ > (remember, there needs to be an END OF OBJECT chunk since PNG objects can > be incomplete. The idea is that with ANON (object 0?) there's always only > one "thing" after it, and since it's not referenced by anything it's > complete so you don't have to tag its end explicitly) > ------------------------------------------------------------ > To find out more about the mailing list server, send mail to > png-list-request@dworkin.wustl.edu > with the word "help" (and nothing else) in the message body. ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Thu Mar 7 08:49:54 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA01552 for ; Thu, 7 Mar 1996 08:49:52 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id EAA01053 for mpng-list-outgoing; Thu, 7 Mar 1996 04:16:48 -0600 Received: from tide03.microsoft.com (tide03.microsoft.com [131.107.3.13]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id EAA01045 for ; Thu, 7 Mar 1996 04:16:45 -0600 Received: by tide03.microsoft.com; id CAA14205; Thu, 7 Mar 1996 02:26:19 -0800 Received: from unknown(157.54.17.73) by tide03.microsoft.com via smap (g3.0.3) id xmaab3886; Thu, 7 Mar 96 02:26:07 -0800 Received: from xnet2 ([157.54.17.205]) by imail1.microsoft.com (8.7.3/8.7.1) with SMTP id MAA13749 for ; Wed, 6 Mar 1996 12:45:34 -0800 (PST) X-Received: from cup-01-msg by xnet2 with receive; Wed, 6 Mar 1996 12:41:01 -0800 X-MSMail-Message-ID: 9AC7A000 X-MSMail-Conversation-ID: 9AC7A000 From: John Bowler To: mpng-list@dworkin.wustl.edu Date: Wed, 6 Mar 96 12:39:36 PST Subject: Re: multi-image format X-MsXMTID: cup-01-msg960306204143MTP[01.52.00]00000094-3543 Message-Id: cup-01-msg960306204143MTP[01.52.00]00000094-3543 Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Aside: let's try to keep the MPNG discussions on the mpng-list and the PNG discussions on the png-list. This requires a little bit of editing of the email To: address for MPNG messages initially, but if enough of us do it the partition between the lists will occur automatically. | From: "Alaric B. Williams" | | The hierachy is not for inheritance, merely to group a cluster of | chunks - so we can have a PNG /object/ consisting of a cluster of PNG | /chunks/. Otherwise, it would be hard to say which chunk applied to | which PNG in the file. | I called it HIER because it looks nice, and it allows hierarichacal | (sp???) grouping of chunks - not inheritance! But your example did not include any hierarchical data within the object. Certainly for PNG objects I see no need - a PNG does not have groups of chunks and a PNG object in an MPNG is therefore just a list of chunks (some of which may refer to preceding objects). True, there is a dependency relationship between an object and the objects (or "partial objects") on which it depends but I see no good reason so far for additional structure (i.e. other than chunk structure) within the object. John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Thu Mar 7 08:49:56 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id IAA01556 for ; Thu, 7 Mar 1996 08:49:55 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id EAA00809 for mpng-list-outgoing; Thu, 7 Mar 1996 04:05:26 -0600 Received: from tide03.microsoft.com (tide03.microsoft.com [131.107.3.13]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id EAA00788 for ; Thu, 7 Mar 1996 04:05:20 -0600 Received: by tide03.microsoft.com; id CAA12044; Thu, 7 Mar 1996 02:14:54 -0800 Received: from unknown(157.54.17.73) by tide03.microsoft.com via smap (g3.0.3) id xmama1665; Thu, 7 Mar 96 02:14:06 -0800 Received: from xnet1 ([157.54.17.204]) by imail1.microsoft.com (8.7.3/8.7.1) with SMTP id PAA17700 for ; Wed, 6 Mar 1996 15:16:45 -0800 (PST) X-Received: from cup-01-msg by xnet1 with receive; Wed, 6 Mar 1996 15:12:16 -0800 X-MSMail-Message-ID: 7E39BBB2 X-MSMail-Conversation-ID: 7E39BBB2 From: John Bowler To: mpng-list@dworkin.wustl.edu Date: Wed, 6 Mar 96 15:10:53 PST Subject: Re: multi-image format X-MsXMTID: cup-01-msg960306231306MTP[01.52.00]00000094-3750 Message-Id: cup-01-msg960306231306MTP[01.52.00]00000094-3750 Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List | From: Peter da Silva | | 1. Create an object that contains a bunch of events. | 2. Make each event an object. | | I think that 1 is lower overhead and more versatile. This seems reasonable - you seem to be saying that an event is transitory (presumably they must be in the stream in the correct time order) and that the format can never say "goto eventN", so there are never references to events. This would seem to simplify the decoder. | Also, here's something | else... how about "anonymous" objects? To extend my permanent/temporary | definition, an "anonymous" object is simply the *next* object in the input | stream. The anonymous object header wouldn't have an object ID and | might possibly be missing other information. Events would generally | be anonymous objects: | | ANON EVNT PUT ANON (at 0,0) | ANON PNGF | png chunks | IEND | | It's not a HUGE savings, but would add up over: | | SOBJ 1 | EVNT PUT 2 (at 0,0) | EOBJ | SOBJ 2 | PNGH | png chunks | IEND | EOBJ | | (remember, there needs to be an END OF OBJECT chunk since PNG objects can | be incomplete. The idea is that with ANON (object 0?) there's always only | one "thing" after it, and since it's not referenced by anything it's | complete so you don't have to tag its end explicitly) Then I have to know what terminates an anonymous object. It seems correct to not wrap events in objects (I had not imagined that this would happen), but I want to be able to skip *any* object in the stream - I wouldn't like to see an MPNG stream which can't be decoded because it contains some data such that I cannot skip the data. Your use of IEND seems to imply that I have to know that PNGF is matched by IEND. This is like the "critical chunk" issue, but in a PNG there is no second level structure, so if I want to write a program like pngcheck I know that I can safely skip chunks which I don't understand (even critical ones). The second level of structure which we are proposing for MPNG means that a program which wants to do a structure check needs to be able to find the end of every object. If the sOBJ/eOBJ chunks are small the overhead should be minimal. John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Thu Mar 7 12:48:11 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA16674 for ; Thu, 7 Mar 1996 12:48:10 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA08606 for mpng-list-outgoing; Thu, 7 Mar 1996 12:49:17 -0600 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id MAA08599 for ; Thu, 7 Mar 1996 12:49:10 -0600 Date: Thu, 7 Mar 96 13:44:33 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: MPNG List Subject: Re: multi-image format Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9603071344.aa04437@THOR.ARL.MIL> Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List In reply to the message > From: Peter da Silva > Subject: Re: multi-image format > Date: Thu, 7 Mar 1996 12:05:56 -0600 (CST) [...] > > - I wouldn't like to see an MPNG stream which can't be decoded because > > it contains some data such that I cannot skip the data. Your use of > > IEND seems to imply that I have to know that PNGF is matched by IEND. > > Good point. Also, we're assuming that everything in the M*PNG file is a > png-style series of chunks. I think that's a valid assumption [...] I wrote earlier: > From: Glenn Randers-Pehrson ARL-WTD-TED-TIB > Subject: multi-image format name > [...] > PNJ "pinge" > [...] > PNJ "pinge" could be a wrapper for any JPEG's to be included > [...] What do you think of the concept of wrapping up a JPEG for use in an MPNG? This way the MPNG processor itself wouldn't have to worry about any sub-streams that aren't made up of png-like chunks. You could carry over a lot of stuff from PNG usefully, including gAMA, cHRM, tEXt, zTXt, tIME, pHYS, but probably not tRNS, bKGD, PLTE, and sBIT. Such files might even be useful in their own right, because you'd gain the signature and CRC checking and the possibility of gAMA and cHRM handling. The JDAT chunks in PNJ would be like IDAT's in PNG; i.e. a JPEG stream could be spread across a bunch of concatenated JDAT's. The default compression_type would be "uncompressed" (meaning no further compression beyond the JPEG compression itself), although I have come across an occasional JPEG that will compress 20% with gzip -9. Maybe "pinjay" sounds better than "pinge". ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Thu Mar 7 12:49:53 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id MAA16691 for ; Thu, 7 Mar 1996 12:49:52 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id MAA08049 for mpng-list-outgoing; Thu, 7 Mar 1996 12:07:37 -0600 Received: from Starbase.NeoSoft.COM (starbase.NeoSoft.COM [198.64.6.26]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id MAA08043 for ; Thu, 7 Mar 1996 12:07:31 -0600 Received: (from peter@localhost) by Starbase.NeoSoft.COM (8.7.4/8.7.4) id MAA06195 for mpng-list@dworkin.wustl.edu; Thu, 7 Mar 1996 12:05:56 -0600 (CST) From: Peter da Silva Message-Id: <199603071805.MAA06195@Starbase.NeoSoft.COM> Subject: Re: multi-image format To: mpng-list@dworkin.wustl.edu Date: Thu, 7 Mar 1996 12:05:56 -0600 (CST) In-Reply-To: cup-01-msg960306231306MTP[01.52.00]00000094-3750 from "John Bowler" at Mar 6, 96 03:10:53 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List > Then I have to know what terminates an anonymous object. True. > It seems > correct to not wrap events in objects (I had not imagined that this > would happen), but I want to be able to skip *any* object in the stream > - I wouldn't like to see an MPNG stream which can't be decoded because > it contains some data such that I cannot skip the data. Your use of > IEND seems to imply that I have to know that PNGF is matched by IEND. Good point. Also, we're assuming that everything in the M*PNG file is a png-style series of chunks. I think that's a valid assumption, but just in case what about an object-length in the object header? Alternatively you can simply say "no PNG-style file can contain sOBJ or eOBJ" and then the sOBJ for the next chunk is the end... and we don't need any eOBJ chunk at all. ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Thu Mar 7 13:07:41 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA17227 for ; Thu, 7 Mar 1996 13:07:41 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA09016 for mpng-list-outgoing; Thu, 7 Mar 1996 13:08:58 -0600 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA09011 for ; Thu, 7 Mar 1996 13:08:54 -0600 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id MAA16390; Thu, 7 Mar 1996 12:07:18 -0700 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199603071907.MAA16390@enel.ucalgary.ca> Subject: Re: multi-image format To: mpng-list@dworkin.wustl.edu Date: Thu, 7 Mar 1996 12:07:17 -0700 (MST) In-Reply-To: <199603071805.MAA06195@Starbase.NeoSoft.COM> from "Peter da Silva" at Mar 7, 96 12:05:56 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List You write: > Good point. Also, we're assuming that everything in the M*PNG file is a > png-style series of chunks. I think that's a valid assumption, but just > in case what about an object-length in the object header? Alternatively > you can simply say "no PNG-style file can contain sOBJ or eOBJ" and then > the sOBJ for the next chunk is the end... and we don't need any eOBJ > chunk at all. There are several issues here. If we require that each object header contains the object length, then we require that one knows the size of a PNG file before it is written. This requires buffering of the whole PNG file in memory before writing. Conversely, if we don't have an object length, we have to seek through each chunk in the stream, even if we know we are skipping them. This was never a problem in a simple PNG file, since we never knew whether the next block was important or not, so we had to check them all. In the end, I think it's best not to contain the size of an object in the sOBJ header (or whatever we have), since it will ruin the streaming on the write side of things. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Thu Mar 7 14:01:52 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id OAA17679 for ; Thu, 7 Mar 1996 14:01:51 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA09931 for mpng-list-outgoing; Thu, 7 Mar 1996 14:03:07 -0600 Received: from tide10.microsoft.com (tide10.microsoft.com [131.107.3.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id OAA09923 for ; Thu, 7 Mar 1996 14:03:01 -0600 Received: by tide10.microsoft.com; id MAA27123; Thu, 7 Mar 1996 12:02:03 -0800 Received: from unknown(157.54.17.74) by tide10.microsoft.com via smap (g3.0.3) id xma027112; Thu, 7 Mar 96 12:01:44 -0800 Received: from xnet2 (xnet2.microsoft.com [157.54.17.205]) by imail2.microsoft.com (8.7.3/8.7.1) with SMTP id MAA15125 for ; Thu, 7 Mar 1996 12:05:01 -0800 (PST) X-Received: from cup-01-msg by xnet2 with receive; Thu, 7 Mar 1996 12:00:44 -0800 X-MSMail-Message-ID: BFCDE8F8 X-MSMail-Conversation-ID: BFCDE8F8 X-MSMail-Fixed-Font: 0001 From: John Bowler To: mpng-list@dworkin.wustl.edu Date: Thu, 7 Mar 96 11:59:06 PST Subject: Re: multi-image format X-MsXMTID: cup-01-msg960307200027MTP[01.52.00]00000094-4589 Message-Id: cup-01-msg960307200027MTP[01.52.00]00000094-4589 Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List | From: Peter da Silva |Also, we're assuming that everything in the M*PNG file is a | png-style series of chunks. I think that's a valid assumption, but just | in case what about an object-length in the object header? I not sure that the object header and single events (not in objects) are necessarily valid chunks. On the other hand to be recognized the header must start with the length (4 - for the object ID/number, 0 for an anonymous object?) and the type ("sOBJ"), so maybe saving (just) a 4 byte CRC is not worth while. I believe that the sOBJ should be followed by a critical chunk which uniquely identifies the type of the object (e.g. IHDR for a complete PNG). To embed, for example, a JFIF stream I would expect to see the following 4 byte quantities in the stream:- 4 [ object *header* length] sOBJ [ "object starts here" ] 42 [ the number of this object ] [ sorry, I can't work this out in my head... ] length [ total length of JFIF stream i.e. original JFIF file length ] JFIF [ is this taken already? ] [ the JFIF data ] [ CRC for all the data ] Using this technique and a suitable critical chunk I can package any arbitrary data. | Alternatively | you can simply say "no PNG-style file can contain sOBJ or eOBJ" and then | the sOBJ for the next chunk is the end... and we don't need any eOBJ | chunk at all. This is a good idea - in my example above I know that I have seen all the data associated with the JFIF stream because I reach the end of the first (and only) chunk in the JFIF data and see "4, sOBJ" or, possible a chunk which marks the end of the file. On this basis I believe MPNG need reserve only 4 structuring chunks:- MHDR - the MPNG file header sOBJ - definition of an object sEVT - definition of an event (this could be an object, but I find Peter's idea of separate events more attractive). MEND - end of file Of course the file would have a non-PNG signature, so there is no chance of confusion, but still it seems attractive to attempt, at least initially, to allocate chunks from the same name space as PNG. John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Thu Mar 7 18:15:22 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA21291 for ; Thu, 7 Mar 1996 18:15:22 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA14644 for mpng-list-outgoing; Thu, 7 Mar 1996 18:16:24 -0600 Received: from Starbase.NeoSoft.COM (starbase.NeoSoft.COM [198.64.6.26]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA14639 for ; Thu, 7 Mar 1996 18:16:20 -0600 Received: (from peter@localhost) by Starbase.NeoSoft.COM (8.7.4/8.7.4) id SAA00172 for mpng-list@dworkin.wustl.edu; Thu, 7 Mar 1996 18:14:44 -0600 (CST) From: Peter da Silva Message-Id: <199603080014.SAA00172@Starbase.NeoSoft.COM> Subject: Re: multi-image format To: mpng-list@dworkin.wustl.edu Date: Thu, 7 Mar 1996 18:14:44 -0600 (CST) In-Reply-To: <9603071344.aa04437@THOR.ARL.MIL> from "Glenn Randers-Pehrson ARL-WTD-TED-TIB" at Mar 7, 96 01:44:33 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List > What do you think of the concept of wrapping up a JPEG for use > in an MPNG? If you want to have "foreign" objects they will definitely need to be wrapped somehow. Splotting the JPEG up into a bunch of JDAT chunks is doable, but would it buy you anything in this context over just wrapping it in a big "foreign object" chunk? After all, the individual frames in an animation are a minor part of the overall file, so there isn't as much incentive to split it further... ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Thu Mar 7 18:46:28 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id SAA21467 for ; Thu, 7 Mar 1996 18:46:27 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id SAA15041 for mpng-list-outgoing; Thu, 7 Mar 1996 18:47:53 -0600 Received: from tide10.microsoft.com (tide10.microsoft.com [131.107.3.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id SAA15034 for ; Thu, 7 Mar 1996 18:47:49 -0600 Received: by tide10.microsoft.com; id QAA15757; Thu, 7 Mar 1996 16:46:54 -0800 Received: from unknown(157.54.17.74) by tide10.microsoft.com via smap (g3.0.3) id xma015746; Thu, 7 Mar 96 16:46:27 -0800 Received: from xnet2 (xnet2.microsoft.com [157.54.17.205]) by imail2.microsoft.com (8.7.3/8.7.1) with SMTP id QAA25796 for ; Thu, 7 Mar 1996 16:49:41 -0800 (PST) X-Received: from cup-01-msg by xnet2 with receive; Thu, 7 Mar 1996 16:45:21 -0800 X-MSMail-Message-ID: 743578E7 X-MSMail-Conversation-ID: 743578E7 From: John Bowler To: mpng-list@dworkin.wustl.edu Date: Thu, 7 Mar 96 16:43:48 PST Subject: Interleaving objects (streams) in MPNG X-MsXMTID: cup-01-msg960308004507MTP[01.52.00]00000094-4954 Message-Id: cup-01-msg960308004507MTP[01.52.00]00000094-4954 Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List ... just a radical attempt to have a second subject line on this mailing list... Having heard the arguments from Peter and Adam I now accept the idea of never reusing an object ID (no great restriction, much easier for editing). One possible extension of this which might be useful is to allow a single object to be split - this might be necessary where there are several large independent objects, for example a background PNG or JPEG plus some sound. How about allowing single objects to be interleaved by terminating the object with a "to-be-continued" marker then inserting an object header later on with the same object ID? (This is close to something Peter suggested earlier, I think):- sOBJ cOBJ [continuation marker] sOBJ sOBJ So long as the interleaved objects can be rendered progressively (easy for sound, possible for images but maybe less useful) the overhead for the decoder is the maintenance of "state" from (potentially) several split objects. The advantage is that this is an obvious way of dealing with data which is not easily split up into separate objects - sound in particular. John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Thu Mar 7 19:59:34 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA21778 for ; Thu, 7 Mar 1996 19:59:34 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA15805 for mpng-list-outgoing; Thu, 7 Mar 1996 20:00:41 -0600 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA15800 for ; Thu, 7 Mar 1996 20:00:37 -0600 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id SAA18114; Thu, 7 Mar 1996 18:58:59 -0700 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199603080158.SAA18114@enel.ucalgary.ca> Subject: Re: Interleaving objects (streams) in MPNG To: mpng-list@dworkin.wustl.edu Date: Thu, 7 Mar 1996 18:58:58 -0700 (MST) In-Reply-To: cup-01-msg960308004507MTP[01.52.00]00000094-4954 from "John Bowler" at Mar 7, 96 04:43:48 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List John writes: > Having heard the arguments from Peter and Adam I now accept the idea of > never reusing an object ID (no great restriction, much easier for > editing). One possible extension of this which might be useful is to > allow a single object to be split - this might be necessary where there > are several large independent objects, for example a background PNG or > JPEG plus some sound. I was trying to get at this earlier by placing a stream ID in the chunk name, which would allow the interleaving of several streams. This amounts to the same thing. The benefits would be that a soundtrack, composed of a single audio stream for the whole length of the MNG file, for instance, could be split into chunks at a convenient size to be interleaved with incoming image data, or a second audio stream. We could even potentially split up PNG images for progressive display, but if there are lots of individual frames, I don't see any benefit of doing so. > sOBJ > > cOBJ [continuation marker] > sOBJ > > sOBJ > I presume that the lack of a "cOBJ" at the end of an object means that that object is complete. In this scenario, are the sOBJ synonymous with events (ie do I start playing the audio in OBJ as soon as I get it, or do I need to wait for an event)? If the sOBJ chunks have some timing info in them, then we can use this to skip chunks if we are seeking in the stream. I would suggest, if this isn't already something that we are taking for granted, that objects and/or events are stored in the stream in strictly increasing temporal order (ie it's not legal to say "object is used at time , object is used at time , and oh yeah, object is used at time "). -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Thu Mar 7 20:50:41 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id UAA22037 for ; Thu, 7 Mar 1996 20:50:40 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id UAA16663 for mpng-list-outgoing; Thu, 7 Mar 1996 20:52:11 -0600 Received: from Starbase.NeoSoft.COM (starbase.NeoSoft.COM [198.64.6.26]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id UAA16658 for ; Thu, 7 Mar 1996 20:52:07 -0600 Received: (from peter@localhost) by Starbase.NeoSoft.COM (8.7.4/8.7.4) id UAA10182 for mpng-list@dworkin.wustl.edu; Thu, 7 Mar 1996 20:50:30 -0600 (CST) From: Peter da Silva Message-Id: <199603080250.UAA10182@Starbase.NeoSoft.COM> Subject: Re: Interleaving objects (streams) in MPNG To: mpng-list@dworkin.wustl.edu Date: Thu, 7 Mar 1996 20:50:30 -0600 (CST) In-Reply-To: <199603080158.SAA18114@enel.ucalgary.ca> from "Andreas Dilger" at Mar 7, 96 06:58:58 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List > I was trying to get at this earlier by placing a stream ID in the chunk > name, which would allow the interleaving of several streams. This > amounts to the same thing. The benefits would be that a soundtrack, > composed of a single audio stream for the whole length of the MNG file, > for instance, could be split into chunks at a convenient size to be > interleaved with incoming image data, or a second audio stream. I would do this by splitting it up into multiple objects, otherwise you can't establish sequence points between the soundtrack and the animation. About the only place I can see doing this is to split up the opening background PNG so you can play sound while you're progressively displaying it and atill get the first phase of the display in quickly. You'd put in a little sound chunk timed so that it'd finish about the time the first frame completed at 1400cps, then the first phase, then more sound, more phases, and so on. > I would suggest, if this isn't already something that we are taking for > granted, that objects and/or events are stored in the stream in strictly > increasing temporal order (ie it's not legal to say "object is used > at time , object is used at time , and oh yeah, object is > used at time "). Events, yes. Objects, no. For example: EVENT at 0 display 1 at 0,0 OBJECT 1 background EVENT after 5 display 2 at 0,0 OBJECT 2 1/4 frame "cover" EVENT after 1 display 2 at 100,0 EVENT after 1 display 2 at 0,100 EVENT after 1 display 2 at 100,100 EVENT at 15 display 3 at 50,50 OBJECT 3 mandala in the middle EVENT at 30 display 2 at 100,0 EVENT at 35 display 2 at 0,0 EVENT at 40 display 2 at 100,100 EVENT at 45 display 2 at 0,100 ... ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Fri Mar 8 07:26:36 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id HAA25538 for ; Fri, 8 Mar 1996 07:26:35 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id HAA24300 for mpng-list-outgoing; Fri, 8 Mar 1996 07:27:40 -0600 Received: from thor.arl.mil (thor.arl.mil [128.63.9.21]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with SMTP id HAA24295 for ; Fri, 8 Mar 1996 07:27:36 -0600 Date: Fri, 8 Mar 96 8:24:22 EST From: Glenn Randers-Pehrson ARL-WTD-TED-TIB To: MPNG List Subject: Re: multi-image format Organization: U.S. Army Research Laboratory, APG, MD Message-ID: <9603080824.aa18174@THOR.ARL.MIL> Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List In reply to the message > From: Peter da Silva > Subject: Re: multi-image format > Date: Thu, 7 Mar 1996 18:14:44 -0600 (CST) > > What do you think of the concept of wrapping up a JPEG for use > > in an MPNG? > > If you want to have "foreign" objects they will definitely need to be > wrapped somehow. Splotting the JPEG up into a bunch of JDAT chunks > is doable, but would it buy you anything in this context over just > wrapping it in a big "foreign object" chunk? After all, the individual > frames in an animation are a minor part of the overall file, so there > isn't as much incentive to split it further... It allows one to check CRC and start processing rather than waiting for the entire image to come through before checking the CRC. Yes, it would be a "minor part" of a movie, but not necessarily a "minor part" of a screen layout with a couple of PNGs and JPEGS (JFIFs/PNJs) on it, or even of a movie where the JPEG is the background and the rest of the file is a couple of PNG sprites. ../glennrp ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Fri Mar 8 13:51:31 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id NAA01641 for ; Fri, 8 Mar 1996 13:51:28 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id NAA00797 for mpng-list-outgoing; Fri, 8 Mar 1996 13:51:24 -0600 Received: from tide03.microsoft.com (tide03.microsoft.com [131.107.3.13]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id NAA00785 for ; Fri, 8 Mar 1996 13:51:19 -0600 Received: by tide03.microsoft.com; id MAA01064; Fri, 8 Mar 1996 12:00:09 -0800 Received: from unknown(157.54.17.73) by tide03.microsoft.com via smap (g3.0.3) id xma001007; Fri, 8 Mar 96 11:59:51 -0800 Received: from xnet2 ([157.54.17.205]) by imail1.microsoft.com (8.7.3/8.7.1) with SMTP id LAA25727 for ; Fri, 8 Mar 1996 11:52:57 -0800 (PST) X-Received: from cup-01-msg by xnet2 with receive; Fri, 8 Mar 1996 11:48:19 -0800 X-MSMail-Message-ID: ECE7CC23 X-MSMail-Conversation-ID: ECE7CC23 From: John Bowler To: mpng-list@dworkin.wustl.edu Date: Fri, 8 Mar 96 11:47:04 PST Subject: Re: multi-image format X-MsXMTID: cup-01-msg960308194812MTP[01.52.00]00000094-5481 Message-Id: cup-01-msg960308194812MTP[01.52.00]00000094-5481 Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List | From: Glenn Randers-Pehrson ARL-WTD-TED-TIB | >[ comments on advantages of splitting large (non-PNG) objects] | | It allows one to check CRC and start processing rather than waiting | for the entire image to come through before checking the CRC. Knowing that an object is corrupted is important, but being able to check for this *before* starting decoding seems less desireable for an MPNG stream where the stream could be very long and transmission errors should be handled gracefully. In the case of JPEG the restart markers allow recovery from transmission problems within a single JPEG stream - so in this case a single object may still be usefully decoded even if technically corrupted. For sound - who cares? Glitches in the stream are something which the human audio system can handle, often without losing useful information. I guess that one argument for "chunking" data like JPEG (or PNG) data is that corruption of the headers used for decoding (as opposed to the data) may lead to embarassing behavior on the part of the decoding software. Corruption of the actual data *should* always be handled gracefully! John Bowler ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Fri Mar 8 15:04:17 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA03992 for ; Fri, 8 Mar 1996 15:04:16 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA02453 for mpng-list-outgoing; Fri, 8 Mar 1996 15:05:46 -0600 Received: from mail.phoenix.net (mail.phoenix.net [199.3.232.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA02441 for ; Fri, 8 Mar 1996 15:05:40 -0600 Received: from 199.3.232.2.phoenix.net (dial139.phoenix.net [205.241.121.153]) by mail.phoenix.net (8.6.12/8.6.12) with SMTP id PAA16167 for ; Fri, 8 Mar 1996 15:03:31 -0600 Message-Id: <199603082103.PAA16167@mail.phoenix.net> Comments: Authenticated sender is From: "Tim Wegner" To: mpng-list@dworkin.wustl.edu Date: Fri, 8 Mar 1996 15:03:57 -0600 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: proposal time Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Because this is a new list, it would be good for folks so inclined to post some new messages with sketches of their MPNG proposals or requirements lists for discussion. Some ideas may not have made it across from the PNG list. A few earlier messages might even be worth reposting. My own concerns are fairly minimalist but I'm open to more comprehensive ideas if they make sense. I want to see an architecture built of PNG-style chunks. I have a litmus test that any proposal, no matter how sophisticated, must support the simplest scenario of a series of PNGs or near PNGs handled with no fluff or complications or requirement for other information if it's not needed. I haven't fully appreciated all the discussion of various object/event approaches and would welcome a summary of one or more of these to get us re-started on this list. (I do have all the recent MPNG messages from the PNG list moved to a MPNG folder, and probably need to bite the bullet and re-read them all.) Tim ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Fri Mar 8 15:04:20 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id PAA03999 for ; Fri, 8 Mar 1996 15:04:19 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id PAA02454 for mpng-list-outgoing; Fri, 8 Mar 1996 15:05:47 -0600 Received: from mail.phoenix.net (mail.phoenix.net [199.3.232.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id PAA02446 for ; Fri, 8 Mar 1996 15:05:41 -0600 Received: from 199.3.232.2.phoenix.net (dial139.phoenix.net [205.241.121.153]) by mail.phoenix.net (8.6.12/8.6.12) with SMTP id PAA16171 for ; Fri, 8 Mar 1996 15:03:33 -0600 Message-Id: <199603082103.PAA16171@mail.phoenix.net> Comments: Authenticated sender is From: "Tim Wegner" To: mpng-list@dworkin.wustl.edu Date: Fri, 8 Mar 1996 15:03:57 -0600 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: multi-image format Priority: normal X-mailer: Pegasus Mail for Windows (v2.23) Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List > I guess that one argument for "chunking" data like JPEG (or PNG) data > is that corruption of the headers used for decoding (as opposed to the > data) may lead to embarassing behavior on the part of the decoding > software. Corruption of the actual data *should* always be handled gracefully! I agree with this in principle, but in the case of PNG, chunks already have CRCs and smart headers to detect corruption. Imbedding PNGs further inside other wrappers for security is overkill. Tim ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Fri Mar 8 17:36:02 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id RAA06923 for ; Fri, 8 Mar 1996 17:36:01 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id RAA05711 for mpng-list-outgoing; Fri, 8 Mar 1996 17:37:34 -0600 Received: from enel.ucalgary.ca (enel.ucalgary.ca [136.159.101.50]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id RAA05705 for ; Fri, 8 Mar 1996 17:37:24 -0600 Received: from munet-d.enel by enel.ucalgary.ca (SMI-8.6/ENEL-5) id QAA21674; Fri, 8 Mar 1996 16:35:42 -0700 From: adilger@enel.ucalgary.ca (Andreas Dilger) Message-Id: <199603082335.QAA21674@enel.ucalgary.ca> Subject: Re: proposal time To: mpng-list@dworkin.wustl.edu Date: Fri, 8 Mar 1996 16:35:41 -0700 (MST) In-Reply-To: <199603082103.PAA16167@mail.phoenix.net> from "Tim Wegner" at Mar 8, 96 03:03:57 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List Tim writes: > I want to see an architecture built of PNG-style chunks. I have a > litmus test that any proposal, no matter how sophisticated, must > support the simplest scenario of a series of PNGs or near PNGs > handled with no fluff or complications or requirement for other > information if it's not needed. I agree with Tim on this. While we shouldn't restrict ourselves too much while designing the format, we shouldn't impose complications that will hinder implementation or acceptance. Something as simple as a PNG chunk header plus a PNG without the PNG header should be legal. For simple decoders, it should be possible to have a reasonable result if the decoder simply displays the images as they arrive in the stream, without any requirements for real-time control or decoding. More complex decoders should try to keep up with any synchronizing tags in the stream. I think MNG should be first and foremost a multiple image format, with sound and synchronization capabilities. While I don't see it being a prevalent application, sound only MNG files could still be legal, or maybe there should be a requirement that even these contain a small "sound" image at the beginning, just to inform users they are sound-only files. I would also like to prevent streams that contain a large number of objects that need to be stored at the decoder for a long period of time. We will all agree that we will probably need to keep at least 2 frames at the maximum display size in memory at any given time, one being the most recent "background" or full screen image if needed, and the second being a frame buffer to be displayed next, which can be modified by overlays and sprites. --- what follows is a conglomeration of various suggestions as I see it --- We implicitly define object '0' as being the output frame buffer itself, which was read-only for speed reasons, and all image objects would be applied to object '0' to be displayed. This would allow optimizing many decoders to avoid storing extra frame buffers. We could also potentially define other output objects, like left/right audio, front/rear audio, second window or display, etc, via a single MHDR at the beginning, or more MHDRs in the stream. Incoming delta images, if we have such a thing, sprites, and sounds are usually be applied immediately against an existing object, which would be '0' if we wanted to display them, and maybe '1' and '2' for left and right audio if so declared. \213MNG\015\012\032\012 MHDR 0x0000 # MNG header < 8>sOBJ 0x0000 PNGI # composite against object 0, type PNG image < 13>IHDR #\ IDAT # > This is a complete, legal PNG file. < 0>IEND<> #/ < 8>sOBJ 0x0000 PNGI # composite against object 0, type PNG image < 13>IHDR #\ IDAT # > This is another PNG file to be displayed. < 0>IEND<> #/ < 0>MEND<> # marks end of MNG file Since the sOBJ object number is zero, we are compositing directly to the screen, and we don't need to save this object. That's it. Essentially, when referring to an existing object we have an implicit event which means "apply this object without delay, at 0,0 to the specified object". The PNG itself would have to contain an oFFs chunk to change its location relative to the origin. This is not a problem containing the location in the object, since it is a single use only object. Similarly, for audio, the incoming sound would be appended to any existsing sound, or immediately played if there is nothing currently being played. This would eliminate lots of events containing "apply this object now at the origin" for a movie, or "output this sound as soon as the last sound is done". There are several additional things required to make a more complex presentation. Objects with unique numbers are usually preceded by an event that refers to them and some existing object to apply to. Positive event numbers are used only once, and then destroyed, while negative events are stored until explicitly destroyed. Events contain timing and position information and work with at least one object already defined. Objects that are applied to outputs that we know we don't care about (ie sound for a display only application) can be skipped. One additional event is to copy an object to give it a new object number, so that the copy can be modified without changing the original object. In this application, the encoder is required to ensure that the decoder maintains valid copies of all the objects that it re-uses. The encoder is also required to ensure that a permanent object is destroyed when it is no longer needed. Having object '0' be the output frame buffer does not actually constrain the encoder's method of implementing the "display". It could still double buffer if desired, or progressively display objects as they arrive, or decode the whole sequence before displaying it, rather than apply it to an output object immediately. Cheers, Andreas. -- Andreas Dilger University of Calgary \"If a man ate a pound of pasta and (403) 220-8792 Micronet Research Group \ a pound of antipasto, would they Dept of Electrical & Computer Engineering \ cancel out, leaving him still http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Fri Mar 8 19:49:36 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id TAA07605 for ; Fri, 8 Mar 1996 19:49:35 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id TAA07209 for mpng-list-outgoing; Fri, 8 Mar 1996 19:51:02 -0600 Received: from Starbase.NeoSoft.COM (starbase.NeoSoft.COM [198.64.6.26]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id TAA07201 for ; Fri, 8 Mar 1996 19:50:59 -0600 Received: (from peter@localhost) by Starbase.NeoSoft.COM (8.7.4/8.7.4) id TAA18194 for mpng-list@dworkin.wustl.edu; Fri, 8 Mar 1996 19:49:17 -0600 (CST) From: Peter da Silva Message-Id: <199603090149.TAA18194@Starbase.NeoSoft.COM> Subject: Re: proposal time To: mpng-list@dworkin.wustl.edu Date: Fri, 8 Mar 1996 19:49:16 -0600 (CST) In-Reply-To: <199603082335.QAA21674@enel.ucalgary.ca> from "Andreas Dilger" at Mar 8, 96 04:35:41 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List > We implicitly define object '0' as being the output frame buffer > itself, which was read-only for speed reasons, and all image objects > would be applied to object '0' to be displayed. I don't understand what the point of specifying the object an image is to be "applied to" is. There's only one output field, and that's the bitmap specified by the width and height in the original header. So I'm not sure what you're trying to get at with your terminology. DO you mind if I attempt to translate? > \213MNG\015\012\032\012 > MHDR 0x0000 > # bounding box > # MNG header > < 8>sOBJ 0x0000 PNGI # temporary object (id=0), display immediately > < 13>IHDR #\ > IDAT # > This is a complete, legal PNG file. > < 0>IEND<> #/ > < 8>sOBJ 0x0000 PNGI # temporary object (id=0), display immediately > < 13>IHDR #\ > IDAT # > This is another PNG file to be displayed. > < 0>IEND<> #/ > < 0>MEND<> # marks end of MNG file The point of this is, here's the same file with timing information. \213MNG\015\012\032\012 MHDR 0x0000 # bounding box # maximum depth of any image # time (in msec) between event ticks. < 16>eVNT <0 > # event on next object < 0> # time is 0 < 0>< 0> # object-specific data (position 0,0) # This is the "default event" < 8>sOBJ 0x0000 PNGI # temporary object (id=0), display immediately < 13>IHDR #\ IDAT # > This is a complete, legal PNG file. < 0>IEND<> #/ < 16>eVNT <0 > # event on next object < 37> # time is +37 milliseconds < 0>< 0> # object-specific data (position 0,0) < 8>sOBJ 0x0000 PNGI # temporary object (id=0), display immediately < 13>IHDR #\ IDAT # > This is another PNG file to be displayed. < 0>IEND<> #/ < 0>MEND<> # marks end of MNG file Since the sOBJ object number is zero, we are displaying immediately screen, and we don't need to save this object. That's it. Essentially, when referring to an existing object we have an implicit event which means "apply this object without delay, all object specific information default values to the specified object". This saves 28 bytes per object. I don't see a good reason not to save those 28 bytes. You certainly need to be able to have a single-use object with timing information attached, which this business of creating a "composite object 0" special case doesn't let you do. Rather than having a special case, stay with the model we've sorta been spiraling in on of temporary and permanent objects, and create a "default event". ------------------------------------------------------------ To find out more about the mailing list server, send mail to mpng-list-request@dworkin.wustl.edu with the word "help" (and nothing else) in the message body. From owner-mpng-list@dworkin.wustl.edu Fri Mar 8 23:27:16 1996 Received: from dworkin.wustl.edu (dworkin.wustl.edu [128.252.169.2]) by swrinde.nde.swri.edu (8.7.4/8.7.1) with SMTP id XAA08637 for ; Fri, 8 Mar 1996 23:27:15 -0600 (CST) Received: (from daemon@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id XAA09237 for mpng-list-outgoing; Fri, 8 Mar 1996 23:28:47 -0600 Received: from tide10.microsoft.com (tide10.microsoft.com [131.107.3.20]) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) with ESMTP id XAA09232 for ; Fri, 8 Mar 1996 23:28:42 -0600 Received: by tide10.microsoft.com; id VAA27086; Fri, 8 Mar 1996 21:27:56 -0800 Received: from unknown(157.54.17.74) by tide10.microsoft.com via smap (g3.0.3) id xma027084; Fri, 8 Mar 96 21:27:51 -0800 Received: from xnet1 (xnet1.microsoft.com [157.54.17.204]) by imail2.microsoft.com (8.7.3/8.7.1) with SMTP id VAA08298 for ; Fri, 8 Mar 1996 21:30:52 -0800 (PST) X-Received: from cup-01-msg by xnet1 with receive; Fri, 8 Mar 1996 21:26:30 -0800 X-MSMail-Message-ID: 7C4DA36A X-MSMail-Conversation-ID: 7C4DA36A X-MSMail-Fixed-Font: 0001 From: John Bowler To: mpng-list@dworkin.wustl.edu Date: Fri, 8 Mar 96 21:25:08 PST Subject: Re: proposal time X-MsXMTID: cup-01-msg960309052626MTP[01.52.00]00000094-6085 Message-Id: cup-01-msg960309052626MTP[01.52.00]00000094-6085 Sender: owner-mpng-list@dworkin.wustl.edu Precedence: bulk Reply-To: MPNG List | From: Andreas | --- what follows is a conglomeration of various suggestions as I see it --- | | We implicitly define object '0' as being the output frame buffer | itself, which was read-only for speed reasons, and all image objects | would be applied to object '0' to be displayed. Unlike Peter I like the idea of having an implicit target and being able to save the 28 bytes for an event record per object, however I wasn't actually imagining that there would necessarily be an event per object - I had assumed that any number of "temporary" objects could follow an event and would be handled immediately (and then disposed of). This makes the saving less worth while - the simplest MPNG need only contain one event. | < 8>sOBJ 0x0000 PNGI # composite against object 0, type PNG image The PNGI is unecessary - the IHDR chunk immediately afterwards defines the object type, since the following data must be in chunk format itself there seems to be no advantage in having the type in the sOBJ. Viewing the "target" (frame, window, sound device, whatever) as an object is interesting - I had been imagining that the output targets were write-only and simply named in the events (in some way :-) Andreas's proposal only hinted at how such an output object might be defined using an MHDR:- | We could also potentially define other output objects, like | left/right audio, front/rear audio, second window or display, | etc, via a single MHDR at the beginning, or more MHDRs in the | stream. But then:- | MHDR 0x0000 | | # MNG header mHDR Where is, e.g. "WIND" for a window (pixel/image output), "MIDI" for a midi channel, "WAVE" for .wav data, etc. Note that I converted MHDR to mHDR - if you don't have support for this object (e.g. the correct CODEC) then it should be OK to skip it and all associated events/objects. So:- mHDR 1 WIND for a screen output device - depth seems inadvisable, X11 may support different depth windows on the screen at the same time, but I don't know of another API which does, and on the Mac a single window may change depth as it is dragged to another device... seems essential - unless we require some event which says "put window x on display" (to avoid displaying the window until it is "ready"). I'm not at all sure how to get the event handling to be both simple and sufficiently general. Probably an event contains a time relative to the last event an "output device" plus, optionally (for non-temporary objects) an object id and parameters:- 0x00000008 eVNT