Opening this bug for discussion/feedback regarding the Animated PNG spec. The latest version is available at: http://www.vlad1.com/~vladimir/projects/apng/AnimatedPNG.html
I think the APNG specification should address were it violates (and therefore probably updates) the PNG specification. It should also refer to the PNG specification. (Can you make the document validate as HTML, by the way.)
Hardware: PC → All
I'd think it is more useful that the fields of the fRAm chunk's offsets (x_offset and y_offset) are "signed int" than "unsigned int".
15 years ago
Copying important comments from bug 257197: Glenn Randers-Pehrson: To avoid violating the PNG spec, aPNG should have its own signature bytes (Just change "P" to "A") and header chunk (AHDR could be the same as your proposed "aNIm" chunk, plus canvas width and height). See clause 5.2 of the ISO PNG spec which promises that a PNG file contains only a single image. firstname.lastname@example.org: Doing so would make APNG images unreadable by non-APNG-aware browsers, and would severely hamper any adoption of the format; currently, the format can be trivially read by the widely-used libpng library. The PNG spec states that a PNG file contains only a single image; from the point of of view of any compliant decoder, this is still true -- anything after the IEND should simply be ignored. That said, we do violate 15.2.1 (c), making the complete APNG streams non-conformant, but still parseable. Test to see what will happen if I try to include examples of HTML in a forthcoming comment: A paragraph begins with <p>.
Test of line breaking (line 1). Test of line breaking (line 2).
Test of line breaking (line 1). Test of line breaking (line 2).
Test of line breaking (line 1) with reference to bug 257197. Test of line breaking (line 2).
Test of line breaking (line 1) with reference to bug 257197. Test of line breaking (line 2), different browser.
Copying important comments from bug 257197 (second attempt). Glenn Randers-Pehrson: To avoid violating the PNG spec, aPNG should have its own signature bytes (Just change "P" to "A") and header chunk (AHDR could be the same as your proposed "aNIm" chunk, plus canvas width and height). See clause 5.2 of the ISO PNG spec which promises that a PNG file contains only a single image. email@example.com: Doing so would make APNG images unreadable by non-APNG-aware browsers, and would severely hamper any adoption of the format; currently, the format can be trivially read by the widely-used libpng library. The PNG spec states that a PNG file contains only a single image; from the point of of view of any compliant decoder, this is still true -- anything after the IEND should simply be ignored. That said, we do violate 15.2.1 (c), making the complete APNG streams non-conformant, but still parseable.
Argh! Please don't use real bugs/issues to test formatting... apparently bugzilla is not the best place for this type of discussion, though it seemed to be appropriate at first. Mailing list coming soon.
Re comment #2: yes, offsets should be signed ints as they are in MNG. It allows scrolling and the like.
The proposal contains this statement: If a frAm chunk appears in frame 0, it must come after the anIm chunk. This cannot be enforced on PNG editors. See Clause 14.3.2 of the ISO PNG spec. "... it is never valid to assume that a specific ancillary chunk occurs with any particular positioning relative to other ancillary chunks." You can deal with this by changing the proposal to say that, although the anIm chunk normally precedes the frAm chunk, decoders must be prepared to encounter the frAm chunk ahead of the anIm chunk in frame 0. However, I prefer using an AHDR chunk instead, which is guaranteed to be first.
Sorry about all the line-breaking tests. I don't know what went wrong the first time I tried to copy those comments, and I haven't been able to reproduce it. Back to the topic at hand... Overloading the type image/png to mean both still images and animations would be a source of confusion that PNG aimed deliberately to avoid. Providing fallbacks for new browser features can be done explicitly, rather than by creating invalid files that happen to be handled in certain ways by certain implementations. HTML provides <object> for this purpose: <object data="foo.apng" type="video/apng"> <img data="foo.png"> </object> All old browsers will simply render foo.png, while any browser new enough to support APNG is surely new enough to support <object>, so it will render foo.apng. This is a cleaner solution and allows the fallback image to be something other than the first frame. I expect that in most cases the last frame would be a more suitable fallback than the first frame, but the ideal fallback might be something else entirely (possibly involving parts of many frames). However, once we give APNG its own media type, we might as well give it its own signature, as Glenn suggested, and move anIm before the first IHDR and make it critical and add the overall dimensions. At that point, it starts looking an awful lot like a subset of MNG (just slightly more complex than MNG-VLC, which doesn't allow timing changes). Consider a subset of MNG in which the only non-PNG chunks allowed are MHDR, MEND, DEFI, and FRAM, where the last two are further constrained as follows: DEFI can be used only to change the placement of subsequent images; it must contain <0,0,0,Xoffset,Yoffset>. FRAM can be used only to change the delay after subsequent images or to provide a name for the next image; it must contain <0,name,0,0,(1|2),0,0,0,delay> or just <0,name>. The choice of 1 or 2 in the fifth field determines whether the delay applies only to the next image or to all upcoming images (until the next FRAM). The name applies only to the next image. I think this MNG subset would provide the same functionality as APNG, with the advantage of being readable by any existing MNG decoder. I imagine that a decoder for this MNG subset could be implemented using libpng plus a little extra code, about the same amount of extra code that APNG requires. The subset could still have its own media type distinct from video/mng, so that browsers that support the subset but not full MNG can use the type attribute of <object> to determine whether to attempt the animation or go straight to the fallback. By the way, I prefer MNG's method of expressing frame delays in user-defined ticks rather than milliseconds as in the APNG draft. The standard NTSC frame rate is 30000/1001 frames per second, which implies that one frame delay is not an integral number of milliseconds (or microseconds or nanoseconds). One frame delay can be expressed as 1001 ticks of a 30 kHz clock, which can be expressed in MNG.
First, see bug 257197 comment 11. How much more work is it to add the GIF-style disposal methods? Without that, the APNG spec fails its own "providing a spec suitable for the most common usage of animated images on the internet." Besides normal frame disposal use, any serious animated GIF editor optimizes images when saving using frame disposal methods. Many APNG images are likely to be much larger than their equivalent MNG images if all pixels are duplicated in every frame.
Perhaps you missed that the spec was at version 0.2.. Frame disposal methods will be added in the near future. There are reserved bytes for it and can be added whenever without breaking the format.
Typo in section 3.2.2: "spcified" in second sentence should be "specified".
How is it with transparancy? will it add to each other or will every new frame start from scrach? and if it's the first senario, how then to make the whole image transparent again?
(In reply to comment #11) > This cannot be enforced on PNG editors. See Clause 14.3.2 of the ISO PNG > spec. "... it is never valid to assume that a specific ancillary chunk > occurs with any particular positioning relative to other ancillary chunks." > > You can deal with this by changing the proposal to say that, although > the anIm chunk normally precedes the frAm chunk, decoders must be > prepared to encounter the frAm chunk ahead of the anIm chunk in frame 0. Good point. Updated the spec to reflect that; there really isn't a good reason to restrict the ordering of the two chunks.
Re comment 14: Sorry, I missed 3.2.1. Another major feature of MNG is JNG. Adding support for JPEG to APNG would effectively allow both transparent JPEG and animated JPEG images. Is there any consideration for this, since it is outside of the specific purpose of the format, but could have great utiliy? If handled from the beginning, there shouldn't be the issue of two JPEG libraries, etc. Though, I can see the complexity level could increase substantially, considering JNG has its own spec.
JNG is outside the scope of APNG and should be looked at seperately.
(In reply to comment #18) > Re comment 14: Sorry, I missed 3.2.1. > > Another major feature of MNG is JNG. Adding support for JPEG to APNG would > effectively allow both transparent JPEG and animated JPEG images. Is there any > consideration for this, since it is outside of the specific purpose of the > format, but could have great utiliy? If handled from the beginning, there > shouldn't be the issue of two JPEG libraries, etc. Though, I can see the > complexity level could increase substantially, considering JNG has its own spec. Indeed, as you say, the complexity level would increase substantially. As stated, APNG is a simple extension to the PNG spec; adding in support for JNG/JPEG/transparent JPEG/etc. falls far wide of the goal of remaining simple. JNG support won't be in APNG.
The proposal should say whether or not the subsequent PNG datastreams must have the same depth, color type, etc., as the first frame or if they can be any valid PNG. The proposal should say what should happen when the number of frames actually present is different from the number specified in the anIm chunk. You could specify the behavior or you could say the decoder can decide. Re: comment #13. Adding the gif disposal methods is pretty simple, except for "restore to previous". I recommend forgetting about trying to implement that because it led us into much of the complexity of MNG.
(In reply to comment #21) > The proposal should say whether or not the subsequent PNG datastreams must have > the same depth, color type, etc., as the first frame or if they can be any > valid PNG. In theory, I see no reason to not let frames consist of any PNG; however, doing so means that we'd have to go through extra work to support "inheriting" data from the first frame. I think we could do that through an extra bitmask field in the frAm chunk, specifying which data to copy over from the first frame. > The proposal should say what should happen when the number of frames actually > present is different from the number specified in the anIm chunk. You could > specify the behavior or you could say the decoder can decide. Ah, I forgot to put that in there. My plan was to specify that any missing frames are just ignored (and the animation treated as if it had the smaller number of frames). Also, any frames that have errors while decoding should also be thrown out; any frames beyond the number specified in the anIm should be ignored. I'll include all this in the spec. > Re: comment #13. Adding the gif disposal methods is pretty simple, except for > "restore to previous". I recommend forgetting about trying to implement that > because it led us into much of the complexity of MNG. Restore to Previous seems to me one of the more interesting/useful disposal methods, though; it's the only one also that can't be supported directly through through compositing. I'm thinking if we do support it, we might explicitly flag in the frAm chunk which frame would be the "previous" for any subsequent Restore to Previous commands. It seems also to be the most useful one from an optimization point of view; i'll have to think a bit about how best to support it. It might turn out not to be worth the hassle, as you suggest.
This statement, evidently from pavlov, appears in slashdot: We are changing the format of APNG so that all the frames live inside of a single IHDR/END. This should resolve any problems you might have. v0.3 of the spec (should be out tomorrow) will have these changes. Please be careful not to violate the PNG spec. Changing PNG into a multi-image format might be a trivial thing for PNG readers but it'd be a real mess for PNG editors if such files get deployed widely.
(In reply to comment #23) > This statement, evidently from pavlov, appears in slashdot: > > We are changing the format of APNG so that all the frames live inside of a > single IHDR/END. This should resolve any problems you might have. v0.3 of the > spec (should be out tomorrow) will have these changes. > > Please be careful not to violate the PNG spec. Changing PNG into a multi-image > format might be a trivial thing for PNG readers but it'd be a real mess for > PNG editors if such files get deployed widely. Part of the reason we're changing things around is to end up being more compliant with the spec. Our current idea is to just add another chunk type with some header bits (frame #, offset, and so on) and then data for a particular frame (IDAT data). However, supporting this might require patches to libpng, which is something we're trying to avoid. Another idea is embed a full IHDR..IDAT..IEND stream within the chunk's data; this would make both decoding and encoding much simpler, at the expense of being rather gross. I'm hoping we can make the first approach workable.
A mailing list for discussion of the APNG spec has been set up -- http://mail.mozilla.org/listinfo/apng
Version 0.3 hides the subsequent frames inside ancillary chunks inside the first PNG image: PNG signature IHDR anIm PLTE IDAT afRa IHDR PLTE IDAT IEND afRa IHDR PLTE IDAT IDAT IEND more afRa chunks IEND This clearly violates the PNG specification Clause 5.2 which says that the png signature indicates that the remainder of the datastream contains a single PNG image. NOT: a single PNG image and maybe more hidden PNG images. Also the PNG group will never approve a chunk that embeds other chunks. In a PNG datastream all chunks are supposed to be visible at the top level (maybe unstated in the ISO PNG spec though). Please go back to version 0.2 and simply change the signature and file extension. You are welcome to change them to the MNG signature and extension, if the result looks enough like a new low-complexity MNG profile (perhaps like what Adam described in comment #12).
(In reply to comment #26) > Version 0.3 hides the subsequent frames inside ancillary chunks inside the first > PNG image: > [...] > > This clearly violates the PNG specification Clause 5.2 which says that > the png signature indicates that the remainder of the datastream contains > a single PNG image. NOT: a single PNG image and maybe more hidden PNG images. Then we're reading the spec differently. The datastream in every way is a fully valid PNG 1.2 image. The afRa chunks are are pure blobs of data, and need not be understood by applications that support straight PNG, as per section 12.11.1. It is only when an application supports the APNG spec do they have any meaning; at which point the stream becomes an APNG stream, and it contains more than a single PNG image. > Also the PNG group will never approve a chunk that > embeds other chunks. In a PNG datastream all chunks are supposed to be > visible at the top level (maybe unstated in the ISO PNG spec though). That's fine, this is an APNG data stream that happens to be backwards compatible with PNG. > Please go back to version 0.2 and simply change the signature and file > extension. You are welcome to change them to the MNG signature and > extension, if the result looks enough like a new low-complexity MNG > profile (perhaps like what Adam described in comment #12). I think we've stated it before.. this isn't an acceptable solution. MNG as a specification is overly complex, providing a huge number of features that there are zero real-world use cases for. Also, its adoption was severely hampered by designing the overcomplicated format first and then picking and choosing which bits to include in simpler versions later, rather than focusing on the most core aspects that there is demand for (animation) and leaving the rest for future extensions. The large number of "standard" profiles for MNG is an impossible situation for content authors, who need just -one- standard. And finally, the lack of backwards compatability with PNG, thus demanding an uptake of an entirely new format is the final straw.
What part of "a single PNG image" do you not understand? >The afRa chunks are are pure blobs of data, and need not >be understood by applications that support straight PNG, as per section 12.11.1. >It is only when an application supports the APNG spec do they have any meaning; That would be OK for a purely private development but in this case surely you intend to deploy the format world wide. You'd be doing the same thing to PNG that Netscape did to GIF, which was an awful mistake IMHO.
I think doing to PNG what Netscape did to GIF is exactly the point here, no?
Please note that the text explaining the PNG signature in 5.2 uses the word *indicate*. This is just about vague enough IMO as to allow APNG to be a valid extension of PNG, as long as the final spec meets all the other criteria. Now if the spec had said *specifies*, that would be the end of it.
Re comment #30, the spec says "specifies" in Clause 1, Scope. This International Standard specifies a datastream and an asssociated file format, Portable Network Graphics (PNG, pronounced "ping"), for a lossless, portable, compressed individual computer graphics image transmitted across the Internet.
Yes it does. 'This International Standard specifies a datastream and an associated file format...' That is - if you want to be a valid PNG, then you must follow each and every rule set out below. 'Rule' 5.2, is vague enough however, that APNG falls within it. I'm quite sure the spirit/intention of the spec is against multiple-images/APNG. But the spec itself DOES allows APNG. Bending!=Breaking
Mozilla set itself up to be a champion of spec compliance. It should be neither bending nor breaking specs.
I don't think we should be worrying about things like the wording in the original spec. APNG is a very good idea and should be done exactly like animated GIF so that you at least see the first frame and do not require any object tag nonsense. I would definately add support for APNG to http://freeimage.sourceforge.net/ once its settled how the chunks will be used. I would like to see APNG incorporated into the official PNG spec and I see no reason the original PNG spec shouldn't be changed to eliminate any nonsense dictating only one image per file.
The PNG group is discussing possible spec changes now that would eliminate the prohibition on multiple images. I don't know how it will turn out. We will also discuss registration of the aPNG chunks when they have been fully designed.
> Mozilla set itself up to be a champion of spec compliance. It should be > neither bending nor breaking specs. Specs are means to ends, not ends in themselves. The ends Mozilla wants are interoperation, backward and forward compatibility, and incremental innovation on the real web, not on a dream-web where IE doesn't dominate and stagnate the market for web content. /be
Is there going to be any more progress on this?
Greg: There was a lot of discussion on the png-list about it. We voted on whether to allow animations into PNG and the proposal failed. We also voted on whether to forbid them, and that proposal failed, too, so it's not clear cut. We developed a few technical improvements but they haven't shown up in the APNG proposal yet. There was an interesting counter-proposal to convey the animation in a GIF89 instead of in a PNG, with the semitransparent PNG images being carried inside one or more GIF89 "Application extensions".
(In reply to comment #38) > Greg: There was a lot of discussion on the png-list about it. We voted on > whether to allow animations into PNG and the proposal failed. We also voted on > whether to forbid them, and that proposal failed, too, so it's not clear cut. IMVHO you should proceed even if the support from png-list is not exactly enthusiastic. > We developed a few technical improvements but they haven't shown up in the APNG > proposal yet. Where are those improvements and/or when the proposal will be updated? > There was an interesting counter-proposal to convey the animation > in a GIF89 instead of in a PNG, with the semitransparent PNG images being > carried inside one or more GIF89 "Application extensions". This means that the static backward-compatible image will be limited to binary transparency? If so I do not like it very much.
The backward-compatible image would be a GIF animation with binary transparency, as opposed to a static PNG in the APNG proposal. Note that IE will not necessarily in the forseeable future get the transparency nor the color-matching-with-background of the static PNG right, while it would do an aniGIF properly.
IE 7 will support PNG alpha transparency.
Right. Gamma-handling is still wrong in IE-7b, though.
Has there been any progress on this matter since the last update of the specification?
in comment #34 its said that apng should done as the animated GIF, but this is BREAKING the png... even today, many years after the animated gif, there are MANY programs that cant display the animated gifs, and so, many people dont know that they arent seeing all the info... they dont have ANY way to see the difference between normal gif and animated gif. doing this to png is repeating the same mistake and hijacking the png format. the world isnt just mozilla, nor even just the web. there are many use for images and so png and apng must have different extensions. a program that is apng capable will recognize the extension, a png only program will not show the image and so the user will know that isnt using the right program to see the image. hijacking the png with the excuses that seeing half the information is better than dont see anything is stupid, programs that are apng capable can see it, those that arent shouldnt. see the mess that is the .avi and all the different encodings (i know, diffrent story) ... now put the png, apng, mng, jpg and avi all in the same extensions and all program being able to see the first frame... it would be hell for the user
Updated URL for proposed spec.
The following proposed changes to the aPNG-0.4 chunk specifications eliminate the undesireable "chunk hierarchy". All chunks would be at the top level and consequently would be available to standard PNG chunk editors, PNG file dumpers, etc, and there would not be a problem of computing the chunk CRC twice. fCTL: o For any subsequent frames, the 'fCTL' chunk must follow any IDAT or aDAT chunks from previous frames and must precede the aDAT chunks to which it pertains. Format: byte 0 chunk_sequence_number (unsigned int in network byte order) Sequence number of the animation chunk, starting from 0. All fCTL and aDAT chunks share the same numbered sequence. There must be no gaps in the sequence. The purpose of the chunk sequence numbers is to detect and/or repair any reordering of chunks that may have been done by an aPNG-unaware editor. (The remainder of the format is the same as in the 0.4 proposal, but with all offsets increased by 4; i.e., the frame sequence_number starts at byte 4.) aDAT: Format: byte 0 chunk_sequence_number (unsigned int in network byte order) Sequence number of the animation chunk, starting from 0. All fCTL and aDAT chunks share the same numbered sequence. bytes 4-N: identical content to an IDAT chunk. The contents of those aDAT chunks (minus the sequence numbers) found between any two fCTL chunks, when concatenated similar to the treatment of PNG IDAT chunks, make up the image data for a PNG frame. fEND: no longer required. Each set of aDAT chunks comprising a frame is terminated by the occurrence of an fCTL chunk or by the IEND chunk.
On second thought we should probably keep the fEND chunk but only use it to terminate the final frame. fEND would also need a frame_sequence_number field. This way aPNG-aware decoders would not have to weed through the fallback PNG looking for the IEND chunk or for more aPNG chunks, if the fallback were at the end of the datastream.
Hmm, my memory's fuzzy.. I think one of the main reasons why we didn't do all toplevel chunks (I think we had them originally?) was that we were convinced on the mailing list that any time any PNG app touched an apng, they would randomly shuffle all the unknown chunks around and spit them out in any order they pleased. I never understood why this was a problem, because those apps didn't understand apng to begin with, so it shouldn't be a surprise that an apng doesn't survive manipulation by them (and I also didn't believe that they really would do this random shuffling). Other than that, would decoders that don't understand apng be confused by the extra IDAT chunks? Adjacent IDAT chunks must be consecutive in the first (PNG) frame in the datastream, and then would be broken by a fCTL/etc., and then followed by more IDATs... I can see PNG decoders potentially being unhappy about this.
The chunk_sequence_number takes care of the random shuffling. Yes apps would be confused by extra IDAT chunks. But in my proposal they are called aDAT chunks. Maybe "fDAT" would be better: fDAT <chunk_seq_no> <data segment identical to the data segment of an IDAT>
Vladimir says, "it shouldn't be a surprise that an apng doesn't survive manipulation by them (and I also didn't believe that they really would do this random shuffling)." In fact they are much more likely to discard them than shuffle them, whether the chunks are according to the APNG-0.4 spec or my recent proposal. What could help a lot in that regard is to give them copy-safe names (aCTl, fCTl, fDAt, fENd). Then they would be preserved but might get shuffled, and the chunk sequence numbers could be used to detect the shuffling.
Regarding copy safety: we cannot simply give the chunks copy-safe names without actually making them copy-safe. Fortunately that is easy. An editor might make the animation chunks invalid by changing either the IHDR values or the PLTE values. Changing the IDAT contents without changing either IHDR or PLTE would not invalidate the animation chunks. So all of the animation chunks can be made copy-safe by including two 4-byte fields in the aCTl chunk: the CRC's from the IHDR and PLTE chunks. An APNG decoder would then check those CRCs to be sure the IHDR and PLTE haven't been messed with. (if there's no PLTE, that field would contain 0).
Just to clarify comment #51: This suggestion is to add two fields to the acTL chunk, that make the animation chunks copy-safe. Decoders can assume that if these fields do not match the corresponding fields in the main image, unsafe changes have been made and the animation chunks should be discarded. 1. The animation chunk names are changed to acTl, fcTl, and fdAt, to indicate that they are copy-safe chunks. 2. The `acTl` chunk contains: byte 0 num_frames ... 4 num_iterations ... 8 IHDR CRC (unsigned int) CRC of the IHDR chunk. 12 PLTE CRC (unsigned int) CRC of the PLTE chunk. Must contain zero if the PLTE chunk is not present or is a "suggested palette". `num_frames` indicates ... `num_iterations` indicates ... Decoders can compare the IHDR CRC and PLTE CRC fields with the corresponding CRC values from the main image, to detect whether the IHDR data or PLTE data has changed. If so, the acTl and remaining animation chunks should be rejected with an error report.
Someone has updated http://wiki.mozilla.org/APNG_Specification to version 0.6. This version incorporates the suggestion described in comment #52. Excellent. Now let's try to eliminate the chunk hierarchy.
Suggested change to APNG spec version 0.6. This removes the "chunk hierarchy" by putting the `fcTl` and `feNd` chunks at the top level instead of enclosing them in the `fdAt` chunk, and it allows the image data to span multiple `fdAt` chunks, similar to the PNG `IDAT` chunk. It's debatable whether `feNd` would still be necessary. Replace < chunks, known as frame 0. Subsequent frames are encoded in `fdAt` < chunks, containing information about placement and rendering of a frame < in `fcTl` chunks, as well as frame data encoded as normal PNG streams. with > chunks, known as frame 0. Subsequent frames are encoded in > `fcTl`, `fdAt`, and `feNd` chunks. Replace < IDAT chunks of the frame to which it applies, specifically: with > data chunks of the frame to which it applies, specifically: Replace < For any subsequent frames, the `fcTl` chunk must be first in the data < part of the `fdAt` chunk. with > For any subsequent frames, the `fcTl` chunk must appear before the > first `fdAt` chunk of the frame to which it applies. Replace < 0 sequence_number (unsigned int) Sequence number of the < 4 x_offset (unsigned int) X position at which to < 8 y_offset (unsigned int) Y position at which to render this < 12 delay_num (unsigned short) Frame delay fraction numerator < 14 delay_den (unsigned short) Frame delay fraction < 16 render_op (byte) Type of with > 0 chunk_sequence_number (unsigned int) Sequence number of the > animation chunk (`fcTl`, `fdAt`, `feNd`), > starting from 0 > 4 frame_sequence_number (unsigned int) Sequence number of the > 8 x_offset (unsigned int) X position at which to > 12 y_offset (unsigned int) Y position at which to render this > 16 delay_num (unsigned short) Frame delay fraction numerator > 18 delay_den (unsigned short) Frame delay fraction > 20 render_op (byte) Type of Replace < The `sequence_number` shall begin with 0 for the first `fdAt` in the with > The `chunk_sequence_number` shall begin with 0 for the first `fcTl` in the > PNG stream, and increase by one with each subsequent `fcTl`, `fdAt`, and > `feNd` chunk. > The `frame_sequence_number` shall begin with 0 for the first `fcTl` in the Replace < `fdAt`: The Frame Data Chunk The `fdAt` chunk contains one frame < for the animation. Any `fdAt` chunks must follow any `IDAT` chunks. All with > `fdAt`: The Frame Data Chunk The `fdAt` chunk contains all or part of > the image data for one frame > for the animation. Any `fdAt` chunks must follow any `IDAT` chunks, and > they must follow the `fcTl` chunk for the frame. All Replace < receive an APNG stream with missing or out of order `fdAt` chunks, it with > receive an APNG stream with missing or out of order `fcTl`, `fdAt`, or `feNd` > chunks, it Replace < byte 0 `fcTl` chunk 29 bytes `fcTl` chunk for this frame < 29 `IDAT` chunks X bytes Frame data for this frame 29+X < `feND` chunk 12 bytes `feND` chunk to mark the end of the < frame data < < Each of the chunks contained in the data section of the `fdAt` must < follow all the rules in section 5 of the PNG specification, except 5.6 < Chunk Ordering. The order of chunks within the `fdAt` is fixed. The < frame data within the `fdAt` consists of a series of `IDAT` chunks, < following the rules from section 11.2.4 of the PNG Specification. The < `feND` is an ancillary, zero-length data field chunk, used to mark the < end of the frame data. The `feND` chunk is a mandatory last chunk in < the data part of the `fdAt` chunk. Only one `feND` per `fdAt` is with > byte 0 chunk_sequence_number 4 bytes sequence number for this chunk > byte 4 X bytes similar content to the data segment of a PNG `IDAT` chunk > > The frame data between the `fcTl` and `feNd` chunks consists of a series > of `fdAt` chunks. The data within each `fdAt` following the > chunk_sequence_number, is the same as the data segment of a PNG `IDAT` > chunk. When the chunk_sequence_numbers are removed, and the > remaining data from the `fdAt` chunks is concatenated, the result is the > complete compressed datastream for the frame. > > `feNd`: The Frame End chunk > byte 0 chunk_sequence_number (unsigned int, 4 bytes) > > `feNd` is an ancillary chunk, used to mark the > end of the frame data. The `feNd` chunk is a mandatory last chunk following > the final `fdAt` chunk of each frame. Only one `feNd` per frame is Replace < or ancillary chunks before the first IDAT in the file. Note: both the < container chunk (`fdAt`) and every chunk within (`fcTl`, `IDAT`s, < `feND`) must specify the length of its own data field and the CRC over < its own chunk name + chunk data as required by section 5.3 of the PNG < Specification. with > or ancillary chunks before the first IDAT in the file.
Is removing the chunk hierarchy really necessary? I understand that it creates an additional implementation burden, however keeping it also might improve compatibility with existing PNG decoders -- this was brought up on the list when we first discussed it, as our first draft had all the chunks as top level chunks. On the flip side, keeping the chunk hierarchy might allow for greater code reuse by just performing recursive parsing of a chunked data stream by the decoder. Andrew has said that eliminating the chunk hierarchy would be very difficult with his current implementation, though I have not looked in detail at the libpng portions of the patch. Glenn, do you have any suggestions there as far as the difficulty of doing that approach?
The trouble with the hierarchy is that existing PNG editors will only see the top-level chunks, while without the hierarchy they would be able to manipulate the individual chunks within each frame. Also, with the hierarchy, the outer frame container chunk is potentially very large. It would probably have been easier to write the decoder if the hierarchy weren't there, but Andrew has already invested the effort, so at this time the difficulty would be in removing it. I don't see any "recursive parsing" there, just some code to keep track of two running CRC calculations at once.
Just to clarify: right now the CRC calculations are only done twice when writing a superchunk. The CRC is only calculated once when reading, regardless of the circumstances (normal APNG decode or 'ignorant' decode).
(In reply to comment #57, #55) > The CRC is only calculated once when reading Right. I don't consider it much of a speed issue, but it is a complexity issue. > Andrew has said that eliminating the chunk hierarchy would be very difficult Evidence that it's complex. Simplifying will be worth the effort, in my opinion. Once that's done I think the spec will be ready for a call-for-vote on the PNG list.
Sorry, we've already been through the whole vote mess on the PNG list. I don't think we'll be going through that again. Nothing has changed that would change how the votes turned out last time.
As a non-libpng-based PNG implementor (http://sixlegs.com/software/png/) I thought I'd add another data point. In my case adding APNG support would be much easier if the chunks were all top-level. There are already hooks to process private chunks and there is no easy way to "recurse" into the internal chunk processor without modifying the public API. (FWIW I would be interested in adding APNG support) I also thing the size of the container chunk could be a problem--IDATs are chunkable in the first place for a reason.
(In reply to comment #59) > Sorry, we've already been through the whole vote mess on the PNG list. I don't > think we'll be going through that again. Nothing has changed that would change > how the votes turned out last time. Sure it has, there's a complete implementation this time. Honestly, I always liked the toplevel chunks approach, which is why it was in the first spec to begin with. Enough people complained and I didn't feel strongly enough about it to try to push back, which was apparently a mistake. Having the chunks in the toplevel would certainly make for a much cleaner and more straightforward spec.
(In reply to comment #61) > Honestly, I always liked the toplevel chunks approach, which is why it was in > the first spec to begin with. Enough people complained and I didn't feel > strongly enough about it to try to push back, which was apparently a mistake. The key difference now being that they are private chunks (e.g. fdAt) from a non-APNG-aware decoder's point of view and can be safely ignored. That was part of my objection, at least. I agree that things are different since the last vote: spec improvements, a working impl, no traction on MNG support, etc. I, for one, can envision voting for this spec, as opposed to previous ones (especially if chunks are moved to the top level), and I think it would be in everyone's interest to come to a consensus.
(In reply to comment #47) > On second thought we should probably keep the fEND chunk but only use it to > terminate the final frame. fEND would also need a frame_sequence_number field. > This way aPNG-aware decoders would not have to weed through the fallback PNG > looking for the IEND chunk or for more aPNG chunks, if the fallback were at the > end of the datastream. I was mixed up when I wrote that. I had forgotten that the fallback chunk is of course always at the beginning of the datastream. There seems to be little reason to keep the feNd chunk, then, because the end-of-frame will be marked either by the fcTl from the next frame or by the main IEND chunk.
I think APNG is an important extension. How about registering APNG-related chunks as public ones. http://www.w3.org/TR/PNG/#4Concepts.Registration It seems to me that private chunks are originally for applications' internal use. http://www.w3.org/TR/PNG/#12Use-of-private-chunks
The 0.6 proposal says, "The frame must be rendered within the region defined by the `x_offset` and `y_offset` from the `fcTl`, and the width and height from this frame's `IHDR`." There is only one `IHDR`, which applies to the main PNG image and all of the aPNG frames. Should the `fcTl` chunk contain a width and height, in case the animation covers only a portion of the frame?
(In reply to comment #58) > Once that's done I think the spec will be ready for a call-for-vote > on the PNG list. That's done. If people on the PNG list approve APNG, I think it'll be a happy ending.
Technically it looks sound now. Here are a few editorial nits in version 0.7: Change "PNG_COLOR_TYPE_PALETTE" to "3 (indexed-color)" throughout the proposal, to use PNG spec terminology. Change "Chuck" to "Chunk" to fix a simple typo. Change "is not desired or explicitly disabled by the user" to "is not desired or is explicitly disabled by the user", to clarify the scope of "not". Change "BLEND_FLAG" to "APNG_RENDER_OP_BLEND_FLAG"
Also change "SKIP_FRAME" to "AP_RENDER_OP_SKIP_FRAME". The use of "set" in the paragraph about "render_op" seems confusing. I recommend changing "Bits 5 through 7 are reserved and must be set to 0." to "Bits 5 through 7 are reserved and must be 0." and later "If this flag is not set" to "If this flag is 0" and "If this flag is set" to "If this flag is not 0".
I've added preliminary support for 0.7 to my Java PNG decoder: http://javapng.sf.net/ The spec is pretty good and a complete implementation added only 7K to the decoder (base PNG decoder is 30K). My suggestions: - Clarify that the sequence numbers must start at zero and may not skip values. - Clarify that at least one frame data chunk is required for every frame except frame 0. - The definitions for "unsigned int", etc., should be harmonized with the PNG spec ones. In particular unsigned int values should be limited to 31-bits. - Add a restriction that the width and height of each frame must be greater than zero (PNG spec already requires this of frame 0). - Decide whether a frame with a region outside of the frame 0 canvas are either clipped or an error and put it in the spec. Saying it "may be treated as an error" is not good for interoperability. I am happy to just make it an error, period. - It is clear to me that the dispose op portion of the render op is treated as a 3-bit unsigned int (the top bit currently unused), but apparently there is some confusion because the libpng patch and sample images do not. Not sure if the spec needs to be clarified--I think this is just a bug with the patch. - The section about the order of the fcTl and fdAt chunks after the IDAT doesn't seem quite right to me. The point of the sequence numbers is that ordering mistakes can be corrected. I think the text should say something like encoders must output chunks in the given order, and if a decoder finds the chunks in a different order it may ignore them or (optionally) try to correct using the sequence numbers.
> The definitions for "unsigned int", etc., should be harmonized with the PNG > spec ones. In particular unsigned int values should be limited to 31-bits. This will happen automatically if APNG gets incorporated in the PNG extension document. > Decide whether a frame with a region outside of the frame 0 canvas are either > clipped or an error and put it in the spec. Yes. Implementors can decide to clip anyhow, but the spec should be clear. Also there should be some explanation of how the APNG chunks work together with the PNG oFFs and pHYs chunks. I think oFFs applies to the canvas, and pHYs, if it is being used, must apply to the APNG pixels and the APNG offsets.
The proposal says: * For the second frame, the fCTl chunk must appear immediately after the IDAT chunks from the first frame and immediately before the fdAt chunks for the second frame. This seems overly restrictive. I would remove the first "immediately" to allow ancillary chunks such as tEXt to appear between the last IDAT and the next fCTl chunk. Then (as the proposal already does) require the remaining APNG chunks to be consecutive.
A Call for Discussion of APNG has been issued on firstname.lastname@example.org The basis for discussion is this document: ftp://ftp.simplesystems.org/pub/png-group/documents/png-apng-proposal-20070307 which was derived from APNG-0.7, converted to plain text, and most of the changes in comments 67, 68, and 69 applied. The discussion period is two weeks unless extended due to substantive changes in the proposal, followed by a two-week voting period by the PNG group.
All of the changes requested in comments 67-69 have been added to the spec, except the following: - There is no need to say that every frame must have at least on fdAt because I don't think it's possible to have an image with a non-0 size that has no frame data at all. - The flags haven't been changed.
In the proposal to the PNG group I expanded the second paragraph of the fdAt chunk specification: Each frame must contain at least one fDAt chunk. There may be multiple fDAt chunks for any one frame; if so, they shall appear consecutively with no other intervening chunks. The compressed datastream is then the concatenation of the contents of the data fields of all the fDAt chunks within a frame. When decompressed, the datastream is a complete PNG image, including the filter byte at the beginning of each scanline. If the main image is interlaced, so are the remaining frames.
>If the main image is interlaced, so are the remaining frames. More completely, It utilizes the same bit depth, color type, compression method, filter method, interlace method, and palette (if any) as the main image.
The spec has been updated to be in sync with png-apng-proposal-20070309.txt which looks good to me. There are no major changes.
This bug was uncovered during the png-list discussion. The proposal says: If the color type of the image is 3 (indexed-color) the `acTl` chunk must appear after the `PLTE` chunk. This is more restrictive than the PNG spec allows for copy-safe chunks. We can only require that it precede the first IDAT chunk. This means that decoders will have to delay checking the PLTE_crc until both the PLTE and acTl chunk have been decoded, instead of checking for PLTE and aCTL being out of order.
Glenn: I'm not sure why there is lots of APNG related spec stuff going on on the png list and not here. We didn't actually call for a vote... Would be nice to get things settled here before we do!
I don't think you'd want the PNG Group discussion to occur here. Last time, in Sept 2004, they generated about 2Mb of messages. There are about 80 messages so far this time around. We haven't called for a vote either (although one would normally occur after the discussion has settled for two weeks), and could delay it as long as you like. The current status of our thinking is in the proposal at ftp://ftp.simplesystems.org/pub/png-group/documents/png-apng-proposal-20070314.txt
The option at the end of section 4.2 to allow the baseline PNG data to form a static alternative image (rather than frame 0) should be mentioned explicitly in the Overview as an alternative to "any PNG decoder should be able to decode the first frame of an APNG and treat it as a normal single-frame PNG." ie. it should say something like "Any PNG decoder can interpret an APNG as a normal single-frame PNG; publishers may provide an alternative static representation or use the first frame for this purpose." Indeed there are other places where this option is omitted, such as under Chunk Sequence Numbers and the first bullet points in 4.2.
"The APNG chunks shall be ignored by a decoder unless the displaying application has explicit information independent of the PNG data stream that the data stream might be an animation, not a static image. This explicit information can be conveyed by file extension (.mng or .gif), by MIME type (video/png), or by placing the PNG on a web page where animations are expected." Look, that's totally ridiculous. You're mandating that the graphic should be either animated or static depending on context alone. That is utterly alien across operating systems, software, APIs, protocols and so on. Contextual information, even if it is supplied, is very often thrown away. Doing so is safe for all image and video formats I am aware of. Just don't go there. APNGs should be detected and animated if the software supports it, but contextual cues such as MIME type and file extension should be preserved where possible. Similarly, you can't just recycle a file extension from MNG or GIF just because those are animated, and expect operating systems and software to just use magic or filesystem metadata to derive correct associations. It needs a different file extension (ideally .apng but on some platforms you would be limited to three character extensions, so perhaps .pna?). Windows, and Mac OS X all use file extensions exclusively now to look up MIME types, icons and associations. Freedesktop.org allows magic but implementations generally use extensions.
i totally agree that no one should try to recycle extensions, all that this creates is confusion and frustration. i dont know any modern platforms that are still limited to 3 letter extensions, so .apng seens the rigth choice. if really required a 3 letter extension, i vote for .ang (sort of "animated network graphic").
> The APNG chunks shall be ignored by a decoder unless the displaying > application has explicit information independent of the PNG data > stream that the data stream might be an animation, not a static image. > This explicit information can be conveyed by file extension (.mng > or .gif), by MIME type (video/png), or by placing the PNG on a > web page where animations are expected. We aren't going to take this change to the spec. It would be much more useful for you to post your proposed changes separately from the actual spec (on the wiki) that we are working from. Mixing them in to "your" proposal makes it too difficult to see what stuff you're trying to add.
>> The APNG chunks shall be ignored by a decoder unless the displaying >> application has explicit information independent of the PNG data >> stream that the data stream might be an animation, not a static image. >> This explicit information can be conveyed by file extension (.mng >> or .gif), by MIME type (video/png), or by placing the PNG on a >> web page where animations are expected. > >We aren't going to take this change to the spec. We need a paragraph along these lines before the PNG group would approve it. The examples shown all seem to be capable of fooling existing browsers into accepting the datastream and showing the static main image. Agreed that using .gif extension is somewhat silly but some see it as no worse than hijacking the .png extension. But .mng and video/x-mng don't seem that silly and they do apparently work. More experimenting is in order.
>Similarly, you can't just recycle a file extension from MNG or GIF With respect to the .mng extension it isn't "recycling" but is a legitimate use, specifically provided for in the MNG spec. By definition, any standalone PNG (and that would included a PNG with APNG chunks) is also a MNG.
I've updated the PNG Group's proposal document to version 20070315 ftp://ftp.simplesystems.org/pub/png-group/documents/png-apng-proposal-20070315.txt Removed the paragraph about when the APNG chunks should be ignored, because the paragraph was unacceptable to the proponents. Added a paragraph about MIME type and extension, suggesting the use of video/x-mng and *.mng Elaborated on frame 0 (from IDAT or implicitly black/transparent, depending on whether fCTl appears ahead of IDAT), as suggested in comment #80.
(In reply to comment #59) > think we'll be going through that again. Nothing has changed that would change > how the votes turned out last time. No, Now both of Stuart and Vladimir are eligible to vote when the voting begins. You have two ballots. The votes in September 2004 were to determine whether to allow animations or not, but the current proposal on the png-list is whether to approve APNG itself or not. If the PNG group approves APNG as an extension, public chunks can be used for APNG implementation, which is guaranteed not to conflict with other applications. And the APNG features will be maintained as part of libpng. I would like both of you to try and vote on the coming vote. It is not too late to ship APNG as Mozilla's original feature after/if the proposal is rejected.
Recycling video/x-mng and image/png may prevent user agents negotiating animation formats correctly with the HTTP Accept: header. We would need a distinct MIME type to allow UAs to explicitly advertise their support for APNG but not MNG.
Do any embedded devices have three-letter extension restrictions? I don't know whether it's a good idea to recommend a four-letter extension, even if it is almost universally supported. The benefit isn't that great and it would mess things up if restrictions do apply anywhere. Putting this issue to one side, my suggestion for the MIME subsection would be along these lines: The suggested MIME type for APNG is "video/apng" and the recommended filename extension is ".apng". Authors MAY supply APNG streams with the "image/png" MIME type, for backwards-compatibility with APNG-unaware software. Alternatively, authors MAY supply APNG streams with the "video/x-mng" MIME type, for backwards-compatibility with MNG-compliant software. Other compatibility requirements might be met through content negotiation where it is available. APNG-aware software SHOULD use an ".apng" extension when deriving filenames for APNG files, regardless of the source MIME information.
> The suggested MIME type for APNG is "video/apng" video/x-png would also be appropriate. > Authors MAY supply APNG streams with the "image/png" MIME type This breaks the RFC definition of "image". Yes we know conveying an animated gif as image/gif already breaks the RFC but we're not trying to emulate gif. Take a careful look at: http://www.rfc-editor.org/rfc/rfc2046.txt, page 4 and the definitions of types "image" and "video". AGIF using image/gif is in direct, clear, unambiguous contravention of this standard. So would APNG using image/png. Following your logic, any new format is going to have to hijack an existing extension and MIME type for the sake of uptake.
Whoops, I mean following the APNG proponents' logic.
I agree. But as long as we recommended a correct MIME type, there are relevant precedents both in AGIF being served as image/gif and application/xhtml+xml being served as text/html. I don't think you can infer anything functional from the image/* top-level media type as it stands, so there's probably minimal risk of incompatibility, if we do decide to offer that suggestion.
> But as long as we recommended a correct MIME type, there are relevant > precedents both in AGIF being served as image/gif The image/gif situation just means that no one was minding the store on behalf of GIF. It doesn't make it correct. IANA was supposed to mind the store on behalf of "image" but they dropped the ball.
I guess actually IANA promulgated the rules and Netscape dropped the ball or chose to ignore the rules. Hmmm.
I'm fine if we want to suggest that people use video/png but I'm against using a different file extension and any sort of wording that implies that image/png won't work.
Stuart: then explain this: A windows user have a normal png and a apng file with the same extension and the same "first" frame. when opening the file in a program that dont support apng (all right now), how will he know what file is what (other than size, probably)? how does the user know that they arent seeing all the "picture". There is no advantage in opening the apng as png!! yes, it MAY look like it worked, but that isnt true, the first frame could be equal in the png and apng, but they could be different, say the png is the last frame from the apng, the first one being white/transparent for example. for using apng in themes, the extensions doesnt matter, for using in the web pages its better to fail and make the user load a plugin than make him think that all is fine and all is seeing is a incomplete view of the page. relaying in the in the webdesigner to solve this problem is ignoring the problem, we all see how the animated gifs are used today, they dont care... in the same way, with a different file extension, they could put a link to load the needed plugin giving the same extension for different formats (even if compatible) is like giving the .txt to all kinds of text files, no matter the real content and hope that the user load then in a "viewer" capable of guessing all the different file formats/rules/whatever.
Because the one picture is called dog.png and the other dog-funny-animated.png. It seems an uninteresting theoretical discussion to me. As far as I’m concerned, there is no reason why the same container could not be used to store both still images, video, sound, or video+sound. It’s all ‘multimedia’, and the distinction that is made so frequently (also in the MIME types) just seems overly complicating to me, and they should never have done it. The AVI file format can contain all these, separately and independently, and yet it’s all supposedly video/x-msvideo. I think it’s a great idea, and there’s nothing wrong with using the .png extension. It’s just like gifs versus animated gifs, the same technology, just a ‘new version of the same thing with more capabilities’, nobody cares, and they did not make APNG ‘backwards compatible’ for nothing. “giving the same extension for different formats (even if compatible) is like giving the .txt to all kinds of text files, no matter the real content and hope that the user load then in a "viewer" capable of guessing all the different file formats/rules/whatever.” Now say that same sentence again, but use ".xml" instead of ".txt". Suddenly it does not seem so strange anymore! You do not need a new extension for a file format everytime its functionality gets extended, even if older viewers are not capable of viewing it entirely. The .pdf file format is in use for ages, even though nowadays it can contain a lot more than it could originally, knowing Adobe probably even video. They never changed the extension. To give a good example of when using a new file extension *does* make sense (somewhat): With the latest Microsoft’s Word, it uses a different file extension (.docx) than previously (.doc) because the underlying technology is different, they now use their Open XML format. ~Grauw
(In reply to comment #97) > Because the one picture is called dog.png and the other dog-funny-animated.png. That doesn't happen in practice. Too much software is designed to just exchange file extensions. Besides, users may well want to use different applications to open PNG and APNG. They may have a powerful tool for editing PNGs which doesn't do animation, and a powerful tool for creating animations that isn't great for editing individual frames. > It seems an uninteresting theoretical discussion to me. As far as I’m > concerned, there is no reason why the same container could not be used to store > both still images, video, sound, or video+sound. It’s all ‘multimedia’, > and the distinction that is made so frequently (also in the MIME types) just > seems overly complicating to me, and they should never have done it. The AVI > file format can contain all these, separately and independently, and yet it’s > all supposedly video/x-msvideo. Yes, and AVI doesn't work very well. There is no negotiation; you simply accept a file and then work out whether you have codecs. There is no way to use a different plugin for audio only streams than for video streams. > I think it’s a great idea, and there’s nothing wrong with using the .png > extension. It’s just like gifs versus animated gifs, the same technology, > just a ‘new version of the same thing with more capabilities’, nobody > cares, and they did not make APNG ‘backwards compatible’ for nothing. I think at a philosophical level we should try to avoid looking at it like GIF. APNG isn't "future PNG" or "PNG 2". It's a new format. It just /happens/ to be a valid PNG stream too, something which eases compatibility. For example, OpenDocument files are valid JAR files, and JAR files are in fact valid ZIP files. But they all have different MIME types. > “giving the same extension for different formats (even if compatible) is like > giving the .txt to all kinds of text files, no matter the real content and hope > that the user load then in a "viewer" capable of guessing all the different > file formats/rules/whatever.” > > Now say that same sentence again, but use ".xml" instead of ".txt". Suddenly it > does not seem so strange anymore! XSL uses .xsl, SVG uses .svg, RDF generally uses .rdf, XHTML often uses .xhtml, RSS uses .rss, Atom uses .atom. The .xml extension is useful when mixing XML from within different namespaces. But XML is an entirely different case anyway, as reflected by the MIME types for most of those including the suffix "+xml". PNG is not a container format for structured data, it's an extensible single-image graphics format. > You do not need a new extension for a file format everytime its functionality > gets extended, even if older viewers are not capable of viewing it entirely. > The .pdf file format is in use for ages, even though nowadays it can contain a > lot more than it could originally, knowing Adobe probably even video. They > never changed the extension. My guess is that Adobe Reader, on encountering a PDF version it doesn't recognise, pops up a window saying "Do you want to download the latest version of Adobe Reader?" I guarantee it doesn't just display the first page of the PDF and silently ignore the fact that there might be more pages. > To give a good example of when using a new file extension *does* make sense > (somewhat): With the latest Microsoft’s Word, it uses a different file > extension (.docx) than previously (.doc) because the underlying technology is > different, they now use their Open XML format. The fact that a .doc document might conform to any of a half a dozen forward-incompatible versions is a huge annoyance to users of older Word versions.
(In reply to comment #98) > I think at a philosophical level we should try to avoid looking at it like GIF. > APNG isn't "future PNG" or "PNG 2". It's a new format. But why should it be? It could also be PNG 2 (albeit not named so). Major new feature: animation. And who says it is not, really? It is an extension to PNG, and even if it will not get approval of the official PNG Group, that doesn’t make it any less an extension to PNG and not a new format. > It just /happens/ to be > a valid PNG stream too, something which eases compatibility. For example, > OpenDocument files are valid JAR files, and JAR files are in fact valid ZIP > files. But they all have different MIME types. Because OpenDocument isn’t designed to be backwards compatible with JAR or ZIP files, they have a totally different application domain, it would not make sense. And I’m sure I don’t need to tell you that. APNG is in the *same* application domain as PNG, that is, a compressed image file format, with the addition of the ability to show sequence of images using a timer. > XSL uses .xsl, SVG uses .svg, RDF generally uses .rdf, XHTML often uses .xhtml, > RSS uses .rss, Atom uses .atom. The .xml extension is useful when mixing XML > from within different namespaces. But XML is an entirely different case anyway, > as reflected by the MIME types for most of those including the suffix "+xml". > PNG is not a container format for structured data, it's an extensible > single-image graphics format. Because those are different formats which have significantly different purposes it makes sense, just like Open XML is also zipped XML files like OpenDocument, but that doesn’t make them remotely compatible. But for example, there are a fair number of documents out on the web which have an .xhtml extension but also contain SVG. The extension doesn’t really have to say anything about the exact nature of the content, as long as it can be interpreted by the user agents (and maybe partially by older user agents). (Btw, RSS feeds definitely don’t use .rss, there’s tons out there with .xml extensions, an ‘XML’ icon even became a popular means to refer to RSS.) My point was that aside from those well-known formats, there are also plenty of examples of XML files that are used as e.g. application configuration files, that do not all need separate extensions because they are read correctly by their software, and a generic XML editor is a perfectly fine editor in case something needs to be fixed, even though it does not have software-specific features. Which is usually one important reason why applications use XML in the first place and not some binary format. > > You do not need a new extension for a file format everytime its functionality > > gets extended, even if older viewers are not capable of viewing it entirely. > > The .pdf file format is in use for ages, even though nowadays it can contain a > > lot more than it could originally, knowing Adobe probably even video. They > > never changed the extension. > > My guess is that Adobe Reader, on encountering a PDF version it doesn't > recognise, pops up a window saying "Do you want to download the latest version > of Adobe Reader?" I guarantee it doesn't just display the first page of the PDF > and silently ignore the fact that there might be more pages. Actually, I think you can say no, and it will then not show the elements that aren’t supported (because there’s plenty of deployments of Acrobat Reader in locations where users do not have the necessary rights to install software). There is no reason to not show the entire document as much as it can. Just like say missing support for the <abbr> tag in a browser would not cause the entire webpage not to be displayed. The file format is designed in a backwards compatible way (just like APNG), which allows you to do just that. > > To give a good example of when using a new file extension *does* make sense > > (somewhat): With the latest Microsoft’s Word, it uses a different file > > extension (.docx) than previously (.doc) because the underlying technology is > > different, they now use their Open XML format. > > The fact that a .doc document might conform to any of a half a dozen > forward-incompatible versions is a huge annoyance to users of older Word > versions. Yes, but at least they can open and read it, maybe with a messed-up layout, but the important notice of that important client you can still read. That’s better than *not* being able to open and read it. Which is what APNG does too, it allows you to view an author-selected frame that represents the animation in case the user agent does not support APNG but only PNG. Using a different MIME type and extension will make this impossible, because it will not be recognised by older browsers/viewers anymore, which will kill the whole reason and effort for APNG to be backwards compatible in the first place. But anyway, I suppose this discussion is pointless as I don’t see Mozilla going to give up this very important feature of APNG. So, final comment on this matter from me :). ~Grauw
Some of the early MNG demos that are on the MNG ftp site contain one wide image that is viewed one piece at a time, like a film strip. APNG could be redesigned to use this type of arrangement, thereby salvaging some of MNG's advantages (reusable objects, better compressibility). Instead of having a bunch of APNG frames following IDAT, only have one, that contains all of the pictures in a larger composite image. Then follow with a stream of fCTl chunks that pick out a piece of the composite and lay it out on the output buffer. The only change to fCTl would be the addition of source_x_offset and source_y_offset parameters. Even if the author doesn't take advantage of reusable pictures, the file would be probably 60% of the size of a regular APNG with separate images because of the better deflate performance. I think the only major argument against this change would be the fact that it does not work with Andrew's existing implementation. I think it could be made to work, though, without a lot of effort.
You'd also have to convey the dimensions of the large image. I guess those could go in the aCTl chunk. I don't think there would be any other spec changes needed to implement this suggestion.
The proposal currently says If the the value of the numerator is 0 the decoder should render the next frame as quickly as possible, though viewers may impose a reasonable lower bound on the delay. I'm not terribly satisfied with this. I think there was some discussion of zero time delay previously but I don't remember if it was resolved. My question is, if the numerator is 0, then is the decoder allowed to (or supposed to) combine the frame with the next frame and display both at once, as in MNG? Is zero time a reasonable lower bound?
I would take it to mean it works as GIFs do which is that most browsers impose a 100ms delay between frames... mostly because of bad editors and history people who put 0 expect things to be ~100ms. Might be less important for APNG since there are no editors yet.
For the sake of lazy editors I would not mind leaving 0/0 to mean 1/100, as stated in the proposal, but if the editor has put in the effort to define a denominator==something, then let's interpret 0/something as 0.
(In reply to comment #98) first, png is a image, apng is a movie, just like the mime type tells you. Image viewers and movies players are totally different, a image viewer can even play movies, and a movie player can view images, but a good image views is always alot better than a movie player, and vice-versa. if apng is trying to be png2, then give it a different extension to tell that. trying to fake that its a v1.0 png without alerting the user that is missing things is wrong. the avi format is a mess for the user, if a avi fail to load, you dont know which codec you are missing... but at least it do something, it fails, allowing the user(or app) to try to fetch the missing codec. With apng is worst, it will not fail, it will look like it worked and silently lose the remaining info. my main problem is precisely the lost of information without the user knowing nothing about it This could be workaround by small but, IMHO, useful thing: the apng file would have in the first frame in one of the corners the letter "a" in a grey/semi-transparent color. A apng player could remove it if they want, but a nom-apng viewer will show the first frame, and so the small letter in the corner, allowing both that that apng doesnt fail, but also allowing the user to see that its not a image, but a video. Using the same extension would be fine in this case, there is a easy way to see that the file is a apng file. Only very small apng files would not have space for the "a", but _probably_ the lost of information where is little important.
With my eyesight I'd never see it. Nor would I see it in the upper right corner. So let's require them to put a letter in each of the 4 corners, "a", "p", "n", and "g". Anyway, people can do what's in the stickman demo on Andrew's web site, which is much better. It reprimands the user and tells him to complain to his browser supplier about the lack of APNG support.
the warn is good theory, but doesnt work to relay on then to solve all...if they show in the web, they will show up in email, peoples computer and others things... if i receive a apng in a cell phone i will not get any warning and not understand that i'm not seeing all the "picture"
I'm not sure what APNG is trying to do. Is there a spec for this spec? I'd like to know what the scope of APNG is. Then I'd like to know a rationale for why that is the extent of the scope, with reference to the overlap with MNG. I'd also like to know about more specific goals. Satisfying a brief is software engineering; creating something from scratch is a hack, and I'm not in favour of hacks being promoted as web standards (even if it's happened (a lot) in the past).
The "Overview" section of the proposal seems to explain that. There isn't really a whole lot to say other than it has to be simple compared to MNG. Follow the "URL" link at the top of the bug report.
The wiki has been updated to version 0.8 It says: When [the fCTl chunk] is not present for frame 0, frame 0 is a transparent black frame (all pixels are RGBA(0,0,0,0)) and the IDAT chunks are ignored. Discussion on the PNG list has suggested that this should be clarified. Please add after this sentence "In this case frame 0 does not introduce a frame delay and it is not counted in num_frames." The proposal says: `num_frames` indicates the total number of frames in the animation. 0 is not a valid value. This means that APNG is not streamable. In another message Vlad has said that streamability is important. I don't know if it is important or not. Anigif can theoretically be streamed (never-ending, like a webcam output) but I've never seen one.
The "BIG IMPORTANT NOTE" in the 0.8 proposal should also tell what happens if the PNG group disapproves the request. In that case the current chunk names (acTl, fcTl, and fdAt) will become the permanent chunk names.
(In reply to comment #111) > The wiki has been updated to version 0.8 There is still a paragraph about SKIP_FRAME that should be removed. > The proposal says: > `num_frames` indicates the total number of frames in the animation. 0 is not a > valid value. > > This means that APNG is not streamable. In another message Vlad has said that > streamability is important. I don't know if it is important or not. Anigif > can theoretically be streamed (never-ending, like a webcam output) but I've > never seen one. Streamability can also refer to being able to progressively display frames while reading the APNG from front to back (i.e. non-random access). I doubt that never-ending APNGs were what people had in mind. Just to be clear, I would prefer that num_frames always refers to the exact number of fcTl chunks.
(In reply to comment #113) > Streamability can also refer to being able to progressively display frames > while reading the APNG from front to back (i.e. non-random access). I doubt > that never-ending APNGs were what people had in mind. Just to be clear, I would > prefer that num_frames always refers to the exact number of fcTl chunks. Yes, this is what I meant by streamability. Never-ending APNGs (webcam-type streams) aren't interesting I don't think, because they would cause many problems.
Wouldn’t it be a relatively small change? APNGs are presumably rendered incrementally as data comes in (if it does so slower than the animation), just like is now the case for GIF, right? Only thing that needs to be taken care of is that frames which have been played have to be discarded... Which might conflict with looping. So you could specify that the value 0 is used to indicate that the length is unspecified, in which case looping may not be used. Well, it isn’t that important. But would be nice to have, I think. ~Grauw
I think I agree with some of the people on the PNG list and that we should get rid of the CRC checks and mark the chunks as not safe-to-copy. For tools that edit APNGs as single-image PNGs I'm fine with them throwing away the rest of the animation. Applications will slowly become APNG-aware so it won't be a big deal.
(In reply to comment #116) > I think I agree with some of the people on the PNG list and that we should get > rid of the CRC checks and mark the chunks as not safe-to-copy. OK. The purpose of the CRC checks was to make the image data a little less fragile, but as has been pointed out on the list, the image data is going to get lost anyway by general purpose image editors, and the CRC checking doesn't find all possibilities where an editor could mess things up and the animation chunks *should* be discarded.
Chris Nokleberg suggested breaking render_op out in to dispose_op and blend_op for the following reasons: > - bitfields are very uncommon in other PNG chunks > - now that the skip flag is gone, the field only hold two values > - it's more confusing for implementors > - it makes adding new dispose_ops and blend_ops impossible (unlikely, but still) > - all just to save one byte I think these are all legit points and is something we can easily adjust for 0.10. He suggests: > I would just break the two values into separate bytes: > byte dispose_op (0 = none, 1 = background, 2 = previous) > byte blend_op (0 = source, 1 = over)
The current spec says: "APNG_RENDER_OP_BLEND_FLAG must be 0 for frame 0." (Frame 0 is the fcTL before the IDAT, if it exists) This is to ensure that each iteration of the animation will be the same. However, it is not sufficient. There needs to be another restriction: "dispose_op must not be APNG_RENDER_OP_DISPOSE_PREVIOUS for frame 0." Otherwise pixel data from the last frame can reappear after the first frame of subsequent iterations.
(In reply to comment #88) > Recycling video/x-mng and image/png may prevent user agents negotiating > animation formats correctly with the HTTP Accept: header. > > We would need a distinct MIME type to allow UAs to explicitly advertise their > support for APNG but not MNG. > We need a distinct MIME type to allow UAs to explicitly advertise their support for PNG but not APNG. Recycling image/png does not help with that. video/x-mng is the correct MIME type for APNG. It is a true subset of MNG. IE7 does the right thing with it: displays the static PNG image in an APNG.
(In reply to comment #120) > We need a distinct MIME type to allow UAs to explicitly advertise their > support for PNG but not APNG. Recycling image/png does not help with that. Indeed. So, this means: Accept: image/png "I only support regular PNG images." Accept: image/png, video/x-mng "I support both APNG animations and PNG images." However, this does not require that the APNG entity itself cannot be sent as image/png. Only that content negotiation must be done with the correct header. Thus, for Content-Type the meanings are slightly different: Content-Type: image/png "This is a PNG image (but it might be an APNG, in which case it MAY be animated.)" Content-Type: video/x-mng "This is an APNG animation, and SHOULD only be shown if APNG is supported." Why would "image/png" mean "or an APNG, which MUST NOT be animated"? It seems illogical to provide an entity with extra information and use the MIME type to specify that this information is to be discarded. Surely, it is being sent as image/, but videos (sent as video/) also contain audio - does this mean the audio should, by the rules, be stripped out? Yes, normally video is thought of as something "bigger" than audio, so that seems silly. But since there is only one media type, it seems to follow that it is the primary type, in a situation where audio, video, and image content all exist in a single entity (not a multipart one.) My interpretation, if naive, does seem to fit the "Definition of a Top-Level Media Type" quite well, actually. Whatever IE7 does, the reality is that existing versions of Firefox that don't support APNG or MNG don't provide this behavior... and backwards compatibility isn't something meant only for IE. -[Unknown]
We will not be using */*mng* for anything APNG related. APNGs do not begin with MNG as MNG files do they begin with PNG, so we will use image/png and/or video/png (video/x-png?)
video/x-png is OK. video/png has not been approved or even applied for.
I went ahead and revved the spec to 0.10 with the render op split in to dispose and blend op. I also changed the values of the dispose ops
(In reply to comment #121) > Why would "image/png" mean "or an APNG, which MUST NOT be animated"? It seems > illogical to provide an entity with extra information and use the MIME type to > specify that this information is to be discarded. > > Surely, it is being sent as image/, but videos (sent as video/) also contain > audio - does this mean the audio should, by the rules, be stripped out? > > Yes, normally video is thought of as something "bigger" than audio, so that > seems silly. But since there is only one media type, it seems to follow that > it is the primary type, in a situation where audio, video, and image content > all exist in a single entity (not a multipart one.) Read the RFC-2046. It explicitly allows audio in "video" datastreams: 4.4. Video Media Type A media type of "video" indicates that the body contains a time- varying-picture image, possibly with color and coordinated sound. The term 'video' is used in its most generic sense, rather than with reference to any particular technology or format, and is not meant to preclude subtypes such as animated drawings encoded compactly. The subtype "mpeg" refers to video coded according to the MPEG standard [MPEG]. Note that although in general this document strongly discourages the mixing of multiple media in a single body, it is recognized that many so-called video formats include a representation for synchronized audio, and this is explicitly permitted for subtypes of "video". Media type "image" has no such extensions.
APNG version 0.10 says * APNG_DISPOSE_OP_BACKGROUND: the frame's region is to be cleared to the background color. If no bKGD chunk is specified, the result is fully transparent black (r, g, b, and a all 0). When a bKGD chunk *is* present, is alpha all zero? I think that is what was intended.
(In reply to comment #125) > Note that although in general this document strongly discourages the > mixing of multiple media in a single body, it is recognized that many > so-called video formats include a representation for synchronized > audio, and this is explicitly permitted for subtypes of "video". > > Media type "image" has no such extensions. They wording of the paragraph, namely the use of "recognized", "in general", does not seem to lend toward the interpretation that this allowance is to be permitted only for this very narrow case. That said, the word "strongly" does lend toward it being fairly narrow still. It sounds much more like, "we think it's a bad idea to put multiple types of media in one file, but we realize most video has audio and so we don't want sticklers trying to say mpegs can't be under the video media type." Indeed, it is discouraged but that doesn't preclude the possibility of it being the right way to deal with the type. And again, it still seems logical that - in this discouraged case of multiple types of media in a single entity body - the media type should be the primary applicable media type. -[Unknown]
There's a suggestion on the PNG list that the "delay_den" be moved to the acTL chunk. It doesn't need to change from frame to frame. The wiki proposal says The `fcTL` chunk corresponding to the default image has additional restrictions, if it exists: * The `x_offset` and `y_offset` fields must be 0. * The `width` and `height` fields must equal the corresponding fields from the `IHDR` chunk. * `blend_op` must be APNG_BLEND_OP_SOURCE * `dispose_op` must not be APNG_DISPOSE_OP_PREVIOUS This doesn't cover all cases. I think it should say The first `fcTL` chunk has these restrictions: * `blend_op` must be APNG_BLEND_OP_SOURCE * `dispose_op` must not be APNG_DISPOSE_OP_PREVIOUS The `fcTL` chunk corresponding to the default image has additional restrictions, if it exists: * The `x_offset` and `y_offset` fields must be 0. * The `width` and `height` fields must equal the corresponding fields from the `IHDR` chunk.
(In reply to comment #128) > There's a suggestion on the PNG list that the "delay_den" be moved to the > acTL chunk. It doesn't need to change from frame to frame. I wouldn't object. > The `fcTL` chunk corresponding to the default image has additional > restrictions, if it exists: > * The `x_offset` and `y_offset` fields must be 0. > * The `width` and `height` fields must equal the corresponding > fields from the `IHDR` chunk. > * `blend_op` must be APNG_BLEND_OP_SOURCE > * `dispose_op` must not be APNG_DISPOSE_OP_PREVIOUS > > This doesn't cover all cases. The paragraph which follows says "if a `fcTL` chunk does not precede `IDAT`, the default image is not part of the animation, and the output buffer must be completely initialized to fully transparent black at the beginning of each iteration." I think it does cover all cases. If the output buffer is cleared, it doesn't matter what the blend_op or dispose_op of the first `fcTL` chunk is--the effect will be the same (BLEND is same as SOURCE, PREVIOUS is same as BACKGROUND). Changing it as you suggest will still work, of course, but if it is not necessary then less restrictions == better. That was the thinking, anyway.
It might help avoid confusion to change "num_iterations" to "num_plays". To a mathematician, "iterations" does not include the first time around a loop. You solve a function once, then iterate so many times. "num_repeats" would have the same problem.
(In reply to comment #128) > There's a suggestion on the PNG list that the "delay_den" be moved to the > acTL chunk. It doesn't need to change from frame to frame. Is that not a substantive change that resets the discussion clock? (In reply to comment #130) > It might help avoid confusion to change "num_iterations" to "num_plays". I agree.
(In reply to comment #131) > (In reply to comment #128) > > There's a suggestion on the PNG list that the "delay_den" be moved to the > > acTL chunk. It doesn't need to change from frame to frame. > > Is that not a substantive change that resets the discussion clock? Yes.
(In reply to comment #128) > There's a suggestion on the PNG list that the "delay_den" be moved to the > acTL chunk. It doesn't need to change from frame to frame. > I would like to keep the ability to have per-frame delays. I've certainly seen it used in interesting ways in animated gifs.
The proposal is to keep per-frame delays. The frame delay is (delay_num/delay_den) where delay_num is in the fcTL chunk and delay_den is in the acTL chunk. This saves two bytes per frame. Not a big savings, but hey.
I think it's very nice that a few people are taking APNG forward, but there are some concerns and there's a lot to be said to work out this problem to everyone's best interest. The one thing that bothers me is that despite all the arguments, APNG really does break (or at least bend) the PNG spec and breaks the "image" MIME type. However, better proposals that don't break the specs are being worked out by the PNG group as we speak. It would really help if all the folks that are so much in favor of 32-bit RGBA animations would participate in the discussion. Not only will it show the comradery between two open-source projects but it will also keep us from handing more ammo to the beast in Redmond by showing that we can work out our differences. I have already dropped the MNG debacle and am quite happily looking forward to the proposed image extension in the distant future (if it ever happens, but that's not the discussion here). The proponents for MNG have been told to shut up or take participation, so here I am offering some help. I have already written several GUI tools that write MNG files, and they could easily be modified to write a new "animated" / "multi-image" PNG format once that makes it into the official spec. And I could have that ready within 2 to 4 weeks after the official spec has been modified. It would certainly benefit all of the people who are screaming for 32-bit RGBA animations. The only thing I am asking in return is that these people (who haven't already) signup to the PNG-discussion list as that is the ONLY place where extensive modifications to the PNG spec are handled, voted on and solidified. Also in having you all there, it would help your case in the voting system. Yes, I am sorry, it is a democratic system, but that has enabled the PNG group to create a world standard which achieved official ISO/IEC status! I hope you all agree, and hopefully some of Mozilla drivers are listening in here as well, that it would be best if we could all agree on the same format. Having competing formats would certainly not benefit anyone at all, and it could even endanger the stable but still somewhat flaky reputation the PNG format holds after all the work the PNG group has put in in the past 12 years.
There is something that I really don't like here. Mozilla is already pushing APNG with Gecko 1.9 alpha 3 and invites people to create such content. The implementation of apng seems to be done as a modification of the embedded libpng, which also means that if apng doesn't make its way to the official libpng, it will remain a maintainance hell for linux distributors... this situation sucks pretty hard.
Current APNG content is being written with private chunk names, so if APNG is approved the files will have to be converted. If a different format is approved, or if APNG is modified before approval, they will still have to be converted, so it wouldn't make much difference to authors, except for the persons creating conversion tools. I don't have any problem with test content being created. That's a good thing. I would have been quite unhappy if Mozilla had jumped the gun and started using public chunk names now, but they are doing it the right way. Linux distributers can use the embedded libpng instead of the shared one, to avoid most of the maintenance hell.
(In reply to comment #137) > Linux distributers can use the embedded libpng instead of the shared one, > to avoid most of the maintenance hell. That is exactly the kind of maintenance hell we are avoiding by using *shared* libraries, especially security-wise.
Today's version of the proposal says: `num_frames` indicates the total number of frames in the animation. This must equal the number of `fcTL` chunks. 0 is not a valid value. 1 is a valid value for a single-frame APNG. Even if the default image is not part of the animation it is still counted in num_frames. If this value does not equal the actual number of frames it should be treated as an error. This was just added: "Even if the default image is not part of the animation it is still counted in num_frames." That is inconsistent with the second sentence! "This must equal the number of `fcTL` chunks." I think the latter sentence is adequate, and the new one just adds confusion. Please take it out again.
I'm pretty sure the Mozilla implementation counts the hidden frame in num_frames but I think having num_frames equal to the number of frames that should be visible might make the spec more clear. Chris, can you please comment on this issue? Is your implementation affected?
I think you are right about the current Mozilla patch counting the default image as a frame regardless of whether it is shown or not. My implementation treats it the other way, and throws an exception if num_frames is too large. In practice this only affects images with a skipped default image, of which your stickman sample is the only known example :-) Hopefully a fix for either implementation is pretty easy, so I'd like to choose the solution which makes for the clearest spec. In my mind this would be to remove the latest sentence and go back to requiring num_frames to equal the number of fcTL chunks (which is also the number of frames actually shown).
I've made several new APNGs with GIF Movie Gear that skip the first frame. It works quite well. I agree with Chris on what num_frames should be.
What happens if the PNG is interlaced, and the frame_delay runs out before all passes have been displayed? Should the spec recommend a behavior? For that matter, what if it is not interlaced and time runs out when you've only got the top half of the image displayed?
FAILED ftp://ftp.simplesystems.org/pub/png-group/documents/ png-apng-proposal-20070405a.txt The PNG group's voting has closed on the APNG proposal. There were 8 YES votes, 10 NO votes, no abstentions, and no ineligble votes cast. The proposal has failed and the APNG chunks are not registered.
Could you write a short summary on what grounds the majority voted no? ~Grauw
PNG is a single-image format.
Is it possible to get a slightly more in-depth summary, or even a record of the arguments? Or is the point merely to try to (fruitlessly) stall APNG?
for the record, GIF was single image only until 89a. Someone might want to correct the gent who said 87a was animated as well.
This is not an attempt to stall APNG. APNG just doesn't cut it at the moment. Various alternatives are being discussed in public sight. Unfortunately it seems that (most of) the APNG proponents do not want to discuss anything that isn't APNG to start with. You simply cannot change a public standard by having a technical implementation if it doesn't agree with the people who put a lot of effort into building that standard. FWIW I have put up a page to list the various proposals and their most obvious pro's and con's: http://gjuyn.xs4all.nl/pnganim.html I again urge everyone that has an invested need for a simple PNG animation format to take part in the ongoing discussion so we can all come up with a solid solution that all parties can agree with.
It is possible that several NO votes would have been YES if it had been agreed to use video/x-png and a different file extension than *.png. I don't know why the proponents would not agree to this. Others would only vote YES if the PNG file signature were not used, but I can understand why that is unacceptable to the proponents.
(In reply to comment #151) > It is possible that several NO votes would have been YES if it had been agreed > to use video/x-png and a different file extension than *.png. I don't know why > the proponents would not agree to this. Others would only vote YES if the PNG > file signature were not used, but I can understand why that is unacceptable to > the proponents. Do you really not understand? In that case, the files would NOT be rendered by existing implementations, and therefore would invalidate one of the core ideas, namely that it can be used by authors even when there is one popular implementation (for example, IE) that does not implement it. Without this, users would be presented with a broken-image icon, which is not ‘graceful’ degradation. ~Grauw
Evidently you have not tried using a different extension and video/x-png. We have and they work with existing browsers.
Oh right. You know why that is? Because browsers ignore MIME types for the <img> tag. Let’s encourage THAT practice instead :). ~Grauw
Asking people to use a proper MIME type is a good practice, no matter whether browsers ignore them or observe them (and keep up to date). Using an improper MIME type because no one keeps up to date is not so good.
If graceful degradation for compatibility is a goal of the specification (which it is), the specification should allow for the file format to be served with the PNG MIME type (which isn’t so strange at all because it uses the PNG file format). You could however, I suppose, formulate it as being a ‘secondary’ allowed MIME type, with the primary being ‘video/x-png’. ~Grauw
The degradation isn't all that graceful. You get a static image instead of an animation. Of what use is a throbber that doesn't throb? PIG (PNG-in-GIF) is much better in that respect. You get a low-quality animation as the fallback.
(In reply to comment #154) > ...browsers ignore MIME types for the > <img> tag. Let’s encourage THAT practice instead :). We don't have to encourage that practice. We simply observe that virtually all browsers behave that way now, and therefore there is no need to mislabel animations with an image/something media type. When each browser's next version cleans up its act and starts paying more respect to the media type, it can at the same time add an entry to its media type map so that PNG-like animations are passed to the same handler as PNG images (if full support for PNG-like animations has not yet been implemented). You appear to be trying to use a principled argument as trump card in a debate between two competing un-principled pragmatic proposals. If we're going to be fully principled, we have to acknowledge that putting an animation in a PNG datastream would directly contradict the PNG spec, and tagging an animation as image/anything would directly contradict the MIME spec. Case closed. If you want to argue for abusing the PNG signature, media type, and file extension, by applying them to animations, don't bother trying to use a principled argument, because it won't beat the principled argument of the preceding paragraph. You need to use a pragmatic argument. For example, one can argue that an animation format that can reuse lots of existing PNG code, and which will automatically be displayed as a single still frame in existing browsers, would be useful, because the principled way of doing fallback (the OBJECT element) doesn't actually work in practice. This argument provides some motivation for abusing the PNG signature, but provides no motivation for abusing the media type nor the file extension. On the other hand, there is a pragmatic argument for using different media types and file extensions for animations versus still images: It avoids confusing users, and helps software invoke the best handler for a given file. Without these distinguishing tags, animation files are likely to be passed through image editors that silently drop the animation data, and users are likely to be confused and frustrated by the drastically different capabilities of various applications that claim to support PNG.
I’m not saying it’s better from a principled point of view per se, I’m just saying that the PNG people apparantly don’t want to ‘compromise’ their standard by allowing animated PNGs to be served as image/png, but are fine when it concerns abusing other standards. That’s kinda hypocritical. Furthermore, it’s not as if allowing a secondary MIME type for compatibility reasons is without precedent. If you look at XHTML 1.0’s section 5, it also allows XHTML to be served as text/html if the markup is written in a backwards-compatible manner. Given that the format is DESIGNED to provide a fall-back to UAs that do not implement it, allowing it to be served as image/png does make a lot of sense. In fact, if it did not, that would make the spec inconsistent with itself. You should choose. Either just don’t go through the effort to get graceful degradation, OR specify the format so that it actually CAN do graceful degradation. But don’t do something ****. ~Grauw
(In reply to comment #159) > I’m not saying it’s better from a principled point of view per se, I’m > just saying that the PNG people apparantly don’t want to ‘compromise’ > their standard by allowing animated PNGs to be served as image/png, but are > fine when it concerns abusing other standards. That’s kinda hypocritical. Wow. Can you explain that a little further? There are two proposals by the PNG group that integrate animation capabilities into a PNG-formatted file. One allows the use of mimetype image/png and extension .png, but encourages users to make the distinction between still and animated images so it is a lot more consistent to the rest of the world. And exactly how is the PNG group proposing to abuse another standard? If you are referring to PNG-in-GIF than please explain how simply extending an animated format with higher-quality pixel-info is abusing that format? It would certainly help this whole discussion if a fixed set of explicit requirements was presented here. What exactly is this animation format to achieve? a) it has to be simple (yes) b) it has to have 8-bit alpha channel possibilities and 24-bit RGB (yes) c) it has to provide a decent fallback image in browsers (yes) d) it has to provide a decent fallback image in image viewers (???) e) it has to provide a decent fallback image in image editors (???) f) the fallback in image editors should not destroy the animation (???) g) the fallback should clearly indicate to the user that (s)he is missing something (???) h) etc...
It seems to me that you have already recognised that is "abusing." You said "Abuse the GIF format. No-one really cares". http://article.gmane.org/gmane.comp.graphics.png.general/1285 I do not understand why some of the PNG group encourage using GIF. It is stated "PNG was designed to be the successor to the once-popular GIF format" on the PNG home site, and PNG 1.2 says "the initial motivation for developing PNG was to replace GIF." By adding a feature like APNG to PNG, the initial motivation will be completed.
MNG was designed to be the successor to aniGIF. It was rejected by mozilla. So be it. Now we are looking for something else. For various reasons, APNG is not it. Both the MPNG/aNIM proposal (which adds animation to PNG) and the PNG-in-GIF proposals seem to meet all the (unstated) requirements and don't break specifications.
I've posted some suggestions for more precise wording at http://philip.html5.org/docs/apng/changes.html (Warning: the 'display selector' on that page causes trunk builds to freeze, seemingly like bug 387058.)
Thanks for the feedback Philip. I took some of the changes from your page, but not all of them. Specifically: - I left 'must' alone, there's no reason to replace it with 'shall' - "APNG-aware PNG editors should attempt to restore them to correct order using the sequence numbers." Why do you feel it's not always unambiguous how to do this? - I feel some of the convertions from 'should' to 'must' and the other way around are wrong or not needed
(In reply to comment #164) > - I left 'must' alone, there's no reason to replace it with 'shall' If "must" is preferred, the "shall"s in the Terminology section should be changed to "must" so that the document is consistent within itself. (Then it'd be inconsistent with the PNG spec's language, but I think internal consistency is more important.) > - "APNG-aware PNG editors should attempt to restore them to correct order using > the sequence numbers." > Why do you feel it's not always unambiguous how to do this? If you have: chunk sequence_number IDAT - fcTL 0 fdAT 1 fcTL 2 fdAT 3 fcTL 0 fdAT 1 it's not clear whether the third frame is a duplicate of the first frame or whether it is a whole new frame with incorrect sequence numbers. I read the spec's "out-of-order APNG chunks" as meaning any APNG chunks which do not have correct sequence numbers, rather than limited to a shuffling of the numbers (with no gaps or duplicates), so it includes cases like the one above, and so there's not always a clear unambiguous way to repair the APNG. > - I feel some of the convertions from 'should' to 'must' and the other way > around are wrong or not needed (I don't see any should<->must changes on the wiki - I don't know if you haven't finished updating it yet, but I'll assume for now that you disagree with all the conversions.) "Should" should be used when "there may exist valid reasons in particular circumstances to ignore a particular item" [RFC 2119]. Many of the uses of "should" in APNG, like: * "the animation should come to rest on the final frame at the end of the last play" * "`dispose_op` specifies how the output buffer should be changed at the end of the delay" * "If the first `fcTL` chunk uses a `dispose_op` of APNG_DISPOSE_OP_PREVIOUS it should be treated as APNG_DISPOSE_OP_BACKGROUND" * "If `blend_op` is APNG_BLEND_OP_OVER the frame should be composited onto the output buffer based on its alpha" are describing fundamental parts of how animations are encoded in APNGs. A decoder cannot ignore those particular items and still be a correct APNG decoder, so they should be "must" requirements to ensure interoperability. Some of the other uses of "should": * "any PNG decoder should be able to ignore the APNG-specific chunks and display a single image" * "The default image should be appropriately padded with fully transparent pixels if extra space will be needed for later frames" are not requirements on APNG implementations, or are not "actually required for interoperation or to limit behavior which has potential for causing harm" , so they shouldn't use keywords like "should" or "must" at all. (For cases like "If this value [num_frames] does not equal the actual number of frames it should be treated as an error", I'm not certain whether it should be "should" or "must". But that doesn't really matter, since error-handling is a "should" anyway.)
The pngext reference should point to ftp://ftp.simplesystems.org/pub/png/documents/ which is at the official PNG ftp site. The copy at pmt.sf.net is just a convenience oopy that happens to be out of date.
I have some test cases at http://philip.html5.org/tests/apng/tests.html which try to cover the interesting features (though I may have missed some bits and got some bits wrong - I wouldn't mind suggestions!) A few issues with the spec: * It's not explicit that there must be no more than one acTL chunk in the file. * Must the number of pixels in the fdAT's image data match the fcTL's width*height? What happens when it doesn't? This seems to be undefined for IDAT in normal PNG, as far as I can see. FF3 and Opera 9.5 appear to fill in the bottom of the region with transparent pixels if there's too little data, and cut off the bottom if there's too much. * There are no requirements on error handling (it's only "strongly recommended"), and neither FF nor Opera currently follows the suggestion - FF refuses to display the image at all, and Opera displays the animation up to the point of the error. That will make it harder to extend APNG in the future, since APNG1.5 images will not have consistent or useful fallback in APNG1.0 web browsers (and will be worse than the current APNG fallback in plain PNG decoders). The error handling should be a requirement, so it's easier to complain that implementations with different error handling are buggy. I would suggest something like "APNG viewers must detect invalid APNG streams. When an error is encountered, they must discard all subsequent frames, stop the animation, and revert to displaying the default image." (APNG editors, and decoders used in contexts other than displaying the animation, can still do error recovery or die with a fatal error or whatever they want - it's just the animation viewers that should be required to handle errors this way, to avoid some probable backward-compatibility problems in the future.)
It would be great to eventually include your tests cases as part of an automated Mozilla test suite (eg, see bug 386651, bug 375733).
I am trying to find explicit instructions (specifications) for what to do about CRCs. recalculate them on changed chunks? leave unchanged? delete them? ignore them? It is also deeply unclear what should be done for PLTE and all ancillary chunks. Should they be included with IDAT in the default image and rely on inheritance for effect on the fdAT chunks? or what?
If you change the contents of a chunk you must recalculate a new CRC for that chunk, if you want the modified datastream to be a valid PNG. See ISO PNG spec, Clause 5.3. PLTE and ancillary chunk data is inherited from the default image by all subsequent images. See the paragraph about the fdAT chunk in the APNG spec, which includes this: "Each frame inherits every property specified by any critical or ancillary chunks before the first `IDAT` in the file, except the width and height, which come from the `fcTL` chunk."
I don't think there's any more to do here.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
QA Contact: joe → imagelib
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.