You can subscribe to this list here.
2005 |
Jan
(12) |
Feb
(24) |
Mar
(12) |
Apr
(12) |
May
(1) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
(5) |
Oct
(13) |
Nov
(1) |
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(1) |
Feb
(15) |
Mar
(80) |
Apr
(34) |
May
(13) |
Jun
|
Jul
|
Aug
(3) |
Sep
(11) |
Oct
(2) |
Nov
|
Dec
(3) |
2007 |
Jan
(2) |
Feb
(3) |
Mar
(375) |
Apr
(341) |
May
(133) |
Jun
(14) |
Jul
(11) |
Aug
(1) |
Sep
(60) |
Oct
(16) |
Nov
(3) |
Dec
(1) |
2008 |
Jan
|
Feb
(1) |
Mar
(23) |
Apr
(35) |
May
(51) |
Jun
(64) |
Jul
(21) |
Aug
(50) |
Sep
(46) |
Oct
(15) |
Nov
(1) |
Dec
(9) |
2009 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
(21) |
May
(4) |
Jun
(8) |
Jul
(3) |
Aug
|
Sep
(4) |
Oct
(19) |
Nov
(4) |
Dec
(4) |
2010 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(4) |
Sep
|
Oct
(11) |
Nov
|
Dec
(8) |
2011 |
Jan
(4) |
Feb
(1) |
Mar
(41) |
Apr
(6) |
May
(1) |
Jun
(5) |
Jul
|
Aug
|
Sep
(10) |
Oct
|
Nov
(2) |
Dec
(2) |
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(19) |
2013 |
Jan
|
Feb
(4) |
Mar
|
Apr
(38) |
May
|
Jun
(26) |
Jul
(28) |
Aug
(1) |
Sep
(17) |
Oct
(10) |
Nov
(6) |
Dec
|
2014 |
Jan
|
Feb
(13) |
Mar
(2) |
Apr
(5) |
May
(2) |
Jun
|
Jul
(21) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2015 |
Jan
(23) |
Feb
(5) |
Mar
(1) |
Apr
|
May
(22) |
Jun
|
Jul
|
Aug
|
Sep
(28) |
Oct
(66) |
Nov
(7) |
Dec
(20) |
2016 |
Jan
(9) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(7) |
Dec
(20) |
2017 |
Jan
(328) |
Feb
(171) |
Mar
(95) |
Apr
(1) |
May
(22) |
Jun
(97) |
Jul
(18) |
Aug
|
Sep
(12) |
Oct
|
Nov
(1) |
Dec
(2) |
2018 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(6) |
May
|
Jun
(5) |
Jul
|
Aug
(7) |
Sep
(1) |
Oct
|
Nov
(3) |
Dec
|
2020 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Gerard J. <gj...@xs...> - 2007-04-29 12:26:13
|
YES PNG-in-GIF 20070414 ftp://ftp.simplesystems.org/pub/png-group/documents/ png-in-gif-proposal-20070414.txt Gerard Juyn <gj...@xs...> > the proposal is harmless - either people use it, in which case > application interoperability is aided by a common definition > endorsed by the PNG Group or they don't use it, in which > case, who cares? I couldn't agree more. Gerard |
From: Gerard J. <gj...@xs...> - 2007-04-29 11:22:53
|
> Here is a possibility for an animation format built on top of PNGs > with anIM chunks, that has a better fallback than anIM alone. > > 1. Use a different file signature. This frees us to put additional > chunks after IEND. Doesn't this kinda defeat the purpose of fallback alltogether? A different signature would have different extension and mime-type too, right? Why would someone change their code for this signature to support an animation format and then just display the still? > 2. The first PNG/JNG in the datastream contains the fallback image with > an anIM chunk. If the playlist is empty, the image isn't displayed. If > the datastream is fed to a PNG decoder, only this image is displayed. > > 3. Subsequent PNG/JNGs lack the file signature and can be single images > or montages, each with an anIM chunk to say how the images are to be > played. Typically there would be only one montage, but multiple > montages could be used to improve streamability (even to the point of an > endless stream). > > 4. There is no global chunk mechanism. Required chunks have to > occur in every montage. Use one large montage to minimize the > chunk count. > > 5. Playlists can only use the image or montage following the respective > anIM chunk. But it is tempting to say that the main PNG image is > available to all playlists. > > 6. PNG and JNG montages can both be present. I'm not sure I like the random images after IEND layout. If this is a new format then why not include an AHDR/AEND to start/end the whole lot. Reasons: a) include a total image-/frame-count; this with a single "num_plays" allows the decoder to decide whether some form of caching is needed or not, thus better implementation for "endless" streaming. b) have a single num_plays rather than a bunch; e.g. which one should be used now? Is each a repetition for the image it is contained in? If so, how to repeat the entire stream? c) indicate the level of transparency to be expected; with all the current formats and proposals a decoder can decide whether it needs full 32-bit canvas with alpha-channel or just a canvas with the color- components and binary transparency or no transparency at all. This is *GOOD* thing to know. d) ANIM chunk at the top-level; that way you can actually combine JNG with PNG, e.g. a full-color JNG backdrop with 1 or more PNG- sprites moving about. This is not possible in your current proposal as you can have either one or the other but not both. Gerard |
From: John B. <jb...@ac...> - 2007-04-29 07:09:53
|
From: Glenn Randers-Pehrson >From: jb...@ac...; PNG/MNG discussion list >> there are multiple PNG Application Extensions then my intention >>as that the last should be used (and the preceding ones are totally >>gnored, since they have no side effects.) >OK. I think something should be said, but as you suggest, not an error >condition but just the fact that decoders must ignore all but the final >one. Of course, they don't know they have to ignore it until the >next one comes along, so "ignore" is probably not the right word. "discard", >maybe. Yes, something like that. It's clear that only one can be used and it's clear that multiple extensions before a single Image Descriptor are (therefore) either pointless or an error or both, but the wording should say what to do to avoid different decoders doing different things. John Bowler <jb...@ac...> |
From: John B. <jb...@ac...> - 2007-04-29 03:14:50
|
YES PNG-in-GIF 20070414 ftp://ftp.simplesystems.org/pub/png-group/documents/ png-in-gif-proposal-20070414.txt John Bowler <jb...@ac...> I think this is a minimalist formalisation of how to embed PNG within GIF. In so far as I understand the requirements I've seen stated for improved GIF animations it meets those requirements. (I'm thinking, in particular, of the need for 24bit data and the need to have a full alpha channel to allow the animation to be used over backgrounds of differing colours.) Quite apart from that, the proposal is harmless - either people use it, in which case application interoperability is aided by a common definition endorsed by the PNG Group or they don't use it, in which case, who cares? |
From: Glenn Randers-P. <gl...@co...> - 2007-04-29 03:13:13
|
At 07:39 PM 4/28/2007 -0700, you wrote: >From: Glenn Randers-Pehrson >> Only one PNG Image Extension is permitted to precede any Image >> Descriptor. > >I didn't think this was necessary - I worded the original to handle this >error condition by saying that the display only occurs at the Image >Descriptor. If there is a preceding PNG Application Extension that gets >used, if there are multiple PNG Application Extensions then my intention >was that the last should be used (and the preceding ones are totally >ignored, since they have no side effects.) OK. I think something should be said, but as you suggest, not an error condition but just the fact that decoders must ignore all but the final one. Of course, they don't know they have to ignore it until the next one comes along, so "ignore" is probably not the right word. "discard", maybe. Glenn |
From: John B. <jb...@ac...> - 2007-04-29 02:50:12
|
From: Glenn Randers-Pehrson >No comments from anyone about the suggestion to add a constant-alpha >byte to the playlist entries? It's holding up the call-for-vote for now. I went back and looked at the Win32 AlphaBlend function and, IMO, it is both broken and useless, unfortunately that's kinda irrelevant for the suggestion. AlphaBlend is broken because it does not linearise the component values before performing the blend (take a look at the math in the documentation which consistently uses 255.0 maxima - we *know* these are sRGB values in Windows!) That means AlphaBlend can't be used to implement any even vaguely conformant PNG alpha blending - the errors are simply too large (25%). The 'constant alpha' stuff in AlphaBlend is, I believe, opportunistic feature creation on behalf of the original author of the function. It has a very specific purpose; to fade in or fade out an overlay (the uConstantAlpha in AlphaBlend adds to the alpha in the base image). Fade in/out, however, is only one effect which might be used in an animation and my opinion is that it has no more validity than any other RGBA transform. Such transforms use a 5x5 matrix to transform a single pixel RGBA1 value into some other value. They can be used for fade in/out, for something like blue screening (transform colour into alpha), sepia toning, effects like the PowerPoint "washout" effect (add white, reduce range), contrast/brightness. I think these are not KISS and adding an 8 bit value to every tile structure achieves only one of these effects (fade in/out). Worse it would require considerable specification; for example, how does the alpha compose with the existing alpha channel, what about 16 bit alpha channels? I say no. John Bowler <jb...@ac...> |
From: John B. <jb...@ac...> - 2007-04-29 02:43:03
|
From: Glenn Randers-Pehrson > Only one PNG Image Extension is permitted to precede any Image > Descriptor. I didn't think this was necessary - I worded the original to handle this error condition by saying that the display only occurs at the Image Descriptor. If there is a preceding PNG Application Extension that gets used, if there are multiple PNG Application Extensions then my intention was that the last should be used (and the preceding ones are totally ignored, since they have no side effects.) John Bowler <jb...@ac...> |
From: Glenn Randers-P. <gl...@co...> - 2007-04-28 23:53:28
|
At 07:40 PM 4/28/2007 -0400, Glenn Randers-Pehrson wrote: > >Call for Discussion > >JNG-in-GIF 20070428 I forgot to mention that the first chunk after JHDR could be JDAA. This is a minor editorial change. Glenn |
From: Glenn Randers-P. <gl...@co...> - 2007-04-28 23:40:22
|
Call for Discussion JNG-in-GIF 20070428 ftp://ftp.simplesystems.org/pub/png-group/documents jng-in-gif-proposal-20070428.txt Glenn Randers-Pehrson <glennrp at comcast.net> |
From: Glenn Randers-P. <gl...@co...> - 2007-04-28 23:37:21
|
Call for Discussion JNG-in-GIF 20070428 ftp://ftp.simplesystems.org/pub/png-group/documents jng-in-gif-proposal-20070428.txt Glenn Randers-Pehrson <glennrp at comcast.net> This proposal depends upon the PNG-in-GIF proposal now being voted upon. I'll only call for a vote on this one if the PNG-in-GIF proposal is approved. Glenn |
From: Glenn Randers-P. <gl...@co...> - 2007-04-28 23:14:03
|
Here is an editorial change, just clarifying something that should already be obvious: Insert the following just prior to paragraph "g": Only one PNG Image Extension is permitted to precede any Image Descriptor. |
From: Glenn Randers-P. <gl...@co...> - 2007-04-28 22:34:40
|
At 09:22 PM 4/28/2007 +0200, you wrote: >I would also like to suggest an extra byte in the header part of the >anIM chunk to indicate whether these opaque values are present in >each tile-structure or not. I think most animations would be built >without them, so it would be useful to save the extra byte per tile. After compression of a lot of 255's, it's a lot less than a byte per tile. How about an "all offsets are zero" flag as well, and maybe an "all delays are the same" flag? anIM starts to look like the MNG FRAM chunk. Glenn |
From: Gerard J. <gj...@xs...> - 2007-04-28 21:04:16
|
> Is anyone working on demonstration PNG-in-GIF supporting software? Only in thought. Lacking the actual time to do it right now. Gerard |
From: Gerard J. <gj...@xs...> - 2007-04-28 19:26:43
|
> No comments from anyone about the suggestion to add a constant-alpha > byte to the playlist entries? It's holding up the call-for-vote for > now. My initial thought was "no", because of the direct link to an OS- function which makes it platform-dependant. But the calculation is fairly simply to execute. A well-written decoder would hopefully check the extreme cases 0 and 255 and simplify the calculation per pixel. That check is per tile, so definitely worth the little extra effort. I would also like to suggest an extra byte in the header part of the anIM chunk to indicate whether these opaque values are present in each tile-structure or not. I think most animations would be built without them, so it would be useful to save the extra byte per tile. Gerard |
From: Glenn Randers-P. <gl...@co...> - 2007-04-28 15:53:32
|
Here is a possibility for an animation format built on top of PNGs with anIM chunks, that has a better fallback than anIM alone. 1. Use a different file signature. This frees us to put additional chunks after IEND. 2. The first PNG/JNG in the datastream contains the fallback image with an anIM chunk. If the playlist is empty, the image isn't displayed. If the datastream is fed to a PNG decoder, only this image is displayed. 3. Subsequent PNG/JNGs lack the file signature and can be single images or montages, each with an anIM chunk to say how the images are to be played. Typically there would be only one montage, but multiple montages could be used to improve streamability (even to the point of an endless stream). 4. There is no global chunk mechanism. Required chunks have to occur in every montage. Use one large montage to minimize the chunk count. 5. Playlists can only use the image or montage following the respective anIM chunk. But it is tempting to say that the main PNG image is available to all playlists. 6. PNG and JNG montages can both be present. Glenn |
From: Glenn Randers-P. <gl...@co...> - 2007-04-28 10:00:33
|
YES PNG-in-GIF 20070414 ftp://ftp.simplesystems.org/pub/png-group/documents/ png-in-gif-proposal-20070414.txt Glenn Randers-Pehrson <glennrp at comcast.net> |
From: Glenn Randers-P. <gl...@co...> - 2007-04-28 09:55:37
|
Call for Vote PNG-in-GIF 20070414 ftp://ftp.simplesystems.org/pub/png-group/documents/ png-in-gif-proposal-20070414.txt Glenn Randers-Pehrson <glennrp at comcast.net> The voting period begins upon receipt of this message at lists.sf.net and ends exactly two weeks thereafter. You can vote YES, NO, or ABSTAIN, if you have posted a message to png...@cc..., png...@cc..., png...@li..., or png...@li... at least 180 days prior to the end of the voting period. To vote, post a message to png...@li... with the first 5 lines of this message to png-list. Change the first line to YES, NO, or ABSTAIN. Change the fifth line to your name and/or e-mail address. Include a summary of your vote in the subject line, e.g. VOTE YES: PNG-in-GIF 20070414 Threshold for passing is (yes / no >= 2) && (yes - no >= 5) If you change your mind during the voting period you can cast another vote. Only the latest vote from any individual will be counted. Please do not submit your vote in a message with subject beginning with "Re:", because that makes it difficult to distinguish actual votes from discussions about people's votes. |
From: Glenn Randers-P. <gl...@co...> - 2007-04-28 09:43:13
|
No comments from anyone about the suggestion to add a constant-alpha byte to the playlist entries? It's holding up the call-for-vote for now. Glenn |
From: Sarreq T. <sa...@gm...> - 2007-04-28 06:58:35
|
It sounds like an excellent plan to me. As long as we're talking a theoretical 2.0 spec, I'd like to also suggest the possibility of HDR color modes (12, 16, and 32 bits/channel at least) to keep up with the future On 4/27/07, Gerard Juyn <gj...@xs...> wrote: > > Dear all, > > (sorry for the long message I am about to write...) > > Several things have made me think of a different approach. We have > a lot of very intelligent people here with varying technical expertise in > the computer graphics arena, and not just encoder/decoder > implementations. But somehow we can't find agreement on how to > extend the existing PNG format for "simple" animations. > > Ok, here's the pitch.... what about combining our efforts for a PNG2 > format? > > Please hear me out before jumping to conclusions! PNG2 would not > just be PNG + some bits, but it would encompass the family of PNG- > like formats. So it would include PNG, JNG and MNG and a new > "simple" animation-like thingy which we might as well call ANG (not > related to Adam's proposal btw!). I know there would definitely people against this, but simplifying the number of extensions would be a good thing, to reduce user confusion PNG2 = static image, with or w/o alpha channel, compressed in any way available to the format MNG2, APNG, ANG2 or PNGA (I say PNGA myself) = animated image, with or w/o alpha channel, compressed in any way available to the format PNG2 could have multiple compression-schemes, so the age-old > compression_method byte could finally have the meaning it was once > written for. E.g. 0=deflate, 1=LZMA, 2=LZW, 3=??? > Also the JNG2 component could allow J2K streams. ANG (or ANG2 > for naming similarity) could be based on the ANIM proposal, but > embedding the aNIM info inside the header-chunk, which could be > AHDR (I had already been thinking of proposing something like this in > addition to the current proposal). MNG2 would be the old MNG but > allowing the new compression schemes. " E.g. 0=deflate, 1=LZMA, 2=LZW, 3=??? " I would think to start with: 0=bog standard current deflate 1=LZMA 2=LZW 3=JPEG 4=JP2K 5= Any other ideas? All of them would require backwards compatibility with their > predecessor, which would not be difficult because the predecessor of > each is a "simpler" form of the new variant. > > All of them would have new signature-bytes, a new extension and > possibly a new mime-type, allthough the old mime-type might suffice. > That's up for discussion. > > Obviously all of this is not compatible with current implementations. So > PNG2 would face the same (possibly/probably long) adoption-cycle > as PNG did. Let's say 5-10 years. However a reference > implementation could be ready within a few weeks or a few months at > the most, because all of it has been done to some extent already. Just > combining some new (de)compression-mechanisms and allowing the > new signatures. libmng already appears to be a perfect testbed for > these new things and having looked at the LZMA SDK it looks a > breeze to implement (LZW most likely too; as for J2K there is the > Jasper lib, but I have yet to look at it). > > Yes, it does not solve the apparent "immediate" problem of a > backwards implementation compatible "simple" PNG animation > format. But from the current proposals we could pick the least harmful > for the adoption of a future PNG2 format, but that would satisfy the > intermediate gap. If we pick wisely, converting from this to the new > PNG2 family should be as easy as possible. > > As Greg pointed out, we have a number of anniverseries coming up > and perhaps it *is* time to start thinking about a PNG2 format. > > As I see it the PNG2 family would have 4 siblings. No > encoder/decoder would be required to support all of them. Just for a > MNG2 implementation it would obviously be a peace of cake. But > single image software could pick out PNG2 (+ optionally JNG2), and > implementations requiring simple animation could adopt ANG2 if > MNG2 was too heavy for their purpose. > > I'm not sure if all of this is making things easier or not, but *now* > seems to be as good a time as any to give it some thought anyway. > > It would definitely be worthwhile if we could bring other parties (think > Microsoft, Opera, KDE, Adobe, JASC, etc, etc, etc....) into the fray. > We have had people from there on the list. In fact one of them > worked for MS and got me in contact with them for a while. This > could've led to MNG being embedded inside Windows and thus > available to IE automatically. Unfortunately a certain situation > changed and the whole idea got buried. > > But anyway.... what's everyone idea about this? > > > Gerard > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > png-mng-misc mailing list > png...@li... > https://lists.sourceforge.net/lists/listinfo/png-mng-misc > |
From: Glenn Randers-P. <gl...@co...> - 2007-04-27 17:01:21
|
Is anyone working on demonstration PNG-in-GIF supporting software? I'm looking at ImageMagick/GraphicsMagick and discovered that they don't presently preserve GIF application extensions other than the NETSCAPE LOOP extension. It looks easy to fix, though, so that the extensions would survive editing and round-trip conversions to MNG, MIFF, and other multi-image formats that preserve profiles and back to GIF. Next problem is how to manage two animation streams in one file. It looks as though it could be done in IM/GM by handling it as just one animation stream, with one of the alternate set of images contained in an associated profile for each frame (i.e., what you get with the simple extension-preserving feature described above). There would have to be a conversion utility to swap one or the other in as the main set of images to be displayed or edited and the other out as a set of profiles. |
From: Glenn Randers-P. <gl...@co...> - 2007-04-27 16:23:28
|
At 11:01 AM 4/27/2007 -0400, you wrote: >Glenn Randers-Pehrson a écrit : >>> However, all of this requires implementors to >>> be able to decode not only PNG but also GIF; in addition, it requires >>> them to basically intertwingle their support for the two formats. >> >> Like Andrew's Firefox patch? APNG seems to require a lot of intertwingling >> as well. >> >It does not. The only part of the patch required for Firefox supporting >APNG was the libpng patch + nsPNGDecoder. Other changes creeped in as >'nice to have'-s. I mistook the changes to src/imgContainer.* as intertwingling. Also the changes to GIF2.* but I see now that those have nothing to do with APNG. |
From: Andrew S. <asm...@le...> - 2007-04-27 15:02:09
|
Glenn Randers-Pehrson a écrit : >> However, all of this requires implementors to >> be able to decode not only PNG but also GIF; in addition, it requires >> them to basically intertwingle their support for the two formats. > > Like Andrew's Firefox patch? APNG seems to require a lot of intertwingling > as well. > It does not. The only part of the patch required for Firefox supporting APNG was the libpng patch + nsPNGDecoder. Other changes creeped in as 'nice to have'-s. Andrew |
From: Glenn Randers-P. <gl...@co...> - 2007-04-27 14:41:38
|
I still don't understand exactly what is wrong with PIG, for use as a simple web animation format. At 04:11 PM 4/26/2007 -0700, Vladimir Vukicevic wrote: >I know that the PNG-in-GIF proposal was brought up before, and it's >being discussed again. I can't help but feel that this is a >manifestation of "hey, GIF is a crappy and abused format, let's stick >more junk in there because noone cares" because that's felt to be >philosophically better than marring the pure PNG format. That's >unfortunate; the reason why I'm against PNG-in-GIF is precisely because >of GIF. GIF as a format sucks for many reasons; Don't some of those reasons carry over into APNG? >embedding PNG data >inside GIF just makes the situation much worse. > >The fallback to a GIF animation is certainly a plus; but it can also be >a minus in other situations (consider wanting the fallback to be a >static full RGBA image). Why would you want that? You are trying to convey an animation. What good is a throbber that doesn't throb? >However, all of this requires implementors to >be able to decode not only PNG but also GIF; in addition, it requires >them to basically intertwingle their support for the two formats. Like Andrew's Firefox patch? APNG seems to require a lot of intertwingling as well. >This >seems like a pretty serious issue for implementors, whether for encoders >or decoders. Right, but it doesn't seem to favor APNG over PIG much. >The reason PNG was chosen was because there was a natural way to extend >it to provide the simple animation abilities that we were looking for, GIF already has the simple animation ability you were looking for. Glenn |
From: Glenn Randers-P. <gl...@co...> - 2007-04-27 14:24:58
|
At 09:09 AM 4/27/2007 -0400, Glenn Randers-Pehrson wrote: >At 04:11 PM 4/26/2007 -0700, Vladimir Vukicevic wrote: >>I'm not really sure where to go from here; > >You could: > > 1. Give up on using the PNG signature. Use \214ANG\c\n^z\n >instead. If you must have fallback, then consider PNG-in-GIF. > > 2. Use critical chunk names ACTL and FCTL. No more need for >sequence numbering. The only purpose for the ancillary chunk usage >was to hide the animation in a PNG. With a new ANG signature you >don't need to hide it. > > 3. Use IDAT instead of FDAT, without sequence numbering. > > 4. Consider allowing montages with multiple FCTL. This gives you >the power of mpNG/aNIM. At one extreme you have a single image per >IDAT stream, like APNG, and at the other extreme you have all of the >images in a single IDAT stream, like aNIM. Revising this proposal slightly: 3. Use FDAT instead of fdAT, without sequence numbering. 4. Consider allowing montages with multiple FCTL except for the first (fallback) image. This gives... A minimal APNG reader would have to recognize the new signature, recognize and ignore the ACTL, FCTL, and FDAT chunks, and display the fallback image. A full APNG reader would decode ACTL, FCTL, and FDAT, and display the animation. |
From: Glenn Randers-P. <gl...@co...> - 2007-04-27 13:08:13
|
At 04:11 PM 4/26/2007 -0700, Vladimir Vukicevic wrote: >I'm not really sure where to go from here; You could: 1. Give up on using the PNG signature. Use \214ANG\c\n^z\n instead. If you must have fallback, then consider PNG-in-GIF. 2. Use critical chunk names ACTL and FCTL. No more need for sequence numbering. The only purpose for the ancillary chunk usage was to hide the animation in a PNG. With a new ANG signature you don't need to hide it. 3. Use IDAT instead of FDAT, without sequence numbering. 4. Consider allowing montages with multiple FCTL. This gives you the power of mpNG/aNIM. At one extreme you have a single image per IDAT stream, like APNG, and at the other extreme you have all of the images in a single IDAT stream, like aNIM. |