Re: APNG MIME type and extension
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 | Next > |
 |
|
|
|
Re: APNG MIME type and extension
by Vladimir Vukicevic-3
::
Rate this Message:
Glenn Randers-Pehrson wrote:
> At 11:32 AM 3/15/2007 -0700, Vladimir Vukicevic wrote: >> Glenn Randers-Pehrson wrote: >> While using mng and >> video/x-mng would be technically valid (since a MNG decoder would be >> able to interpret at least the static PNG data), explicitly specifying >> that option in the spec seems like it would just lead to confusion. > > Stating the truth would just lead to confusion. Right. Doing it the > right way won't work. Right. Stating what truth? Saying "image/png" is as true as "video/x-mng", and leads to less confusion. Saying in the spec that APNGs may also be served as "video/x-png" would probably be fine, though I can't see any advantage in actually serving one as video/x-png. (Or, indeed, of actually sniffing deep enough into the stream to decide whether something is image/png or video/x-png.) - Vlad ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: APNG MIME type and extension
by glennrp-2
::
Rate this Message:
At 12:26 PM 3/15/2007 -0700, Vladimir Vukicevic wrote:
>Glenn Randers-Pehrson wrote: >Stating what truth? Saying "image/png" is as true as "video/x-mng" If the file contains an animation that the author expects the decoder to render as an animation, then "image/png" is a bald-faced lie. Twice. Once because "image" calls for still images, and once because "png" calls for still images. Now what we need to do is find some scheme that will fool IE without lying and breaking specifications. I'm trying to help with that. I'm suggesting video/x-mng because it's entirely truthful and spec-compliant. If it turns out that, as you say, the only way to fool IE is to break specs, then we'll consider that, but I suspect it would sway a few votes against the proposal. Glenn ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: APNG MIME type and extension
by Nozomu Katoo
::
Rate this Message:
On Thu, 15 Mar 2007 15:45:43 -0400, Glenn Randers-Pehrson wrote:
>If it turns out that, as you say, the only way to fool IE is to break >specs, then we'll consider that, but I suspect it would sway a few >votes against the proposal. I agree. If we can remove the factor that makes people not interested in APNG feel APNG breaks the PNG spec, they might simply ignore the proposal instead of opposing it strongly. -- N.Katoo <png.ml@...> ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
|
|
|
it is worse than incompatible
by Willem van Schaik
::
Rate this Message:
>
> It is an incompatible extension to PNG. > > It is worse than incompatible. > John, what happened?? I read probably 20 emails from you on all kinds of little details and suddenly there's this outburst which hints :) that you simply think this form of APNG simply sucks. OK lets take that a little step further: do you think that a simple animated PNG format is in general impossible within the constraints of the current PNG specification or do you just think that this way of implementing it is not the way to do it. My own personal opinion on APNG (item (c) is also the reason I've not contributed that much to the discussion) is: a) I really think there should be simple animation extension to PNG (and with the emphasis on "simple") b) it is uttermost important that it not only follows the existing spec, but that it is also in-line with the nature of the existing PNG format c) and for the rest I don't give rats on how it is done, developers will simple take the spec and implement it (or break it, if it isn't simple enough, see A :-) Willem ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: APNG MIME type and extension
by glennrp-2
::
Rate this Message:
At 10:45 PM 3/15/2007 -0700, John Bowler wrote:
>From: Vladimir Vukicevic >>APNG is a backwards-compatible extension to PNG, as was said > >It is not. > >It is an incompatible extension to PNG. > >It is an incompatible extension because an existing PNG application will not >even display anything remotely like the extension, let alone edit it. The >extension is an animation format, no existing PNG displaying application >displays PNGs as animations, even though many have the capability to display >animations. It is syntactically compatible but philosophically incompatible. It is designed so that APNG-unaware applications will be able to display *something*. It is philosophically incompatible because it really contains an animation, and the "png" signature and the "image" MIME category both promise that it contains a still image. The proponents of APNG are unwilling to face these facts. From the discussion that occurred in 2004 it is evident that some of this group are willing to ignore them. > >It is even worse than that. > >It is an incompatible extension done in an incompatible way. That is >because there are a set of rules for extending PNG such that existing >applications will not damage the extension data - even though they do not >understand it. APNG ignores this facility, the structure of APNG is such >that a non-APNG aware but completely correct application is able to damage >or totally change the APNG information in such a way that a naive APNG >implementation may be unable to reconstruct anything useful. I don't agree with this statement. The only thing that can happen is that an APNG-unaware application will put the chunks out of order, which can be detected by any APNG-aware application and fixed by an APNG-aware editor. > >A great many file formats have been extended in incompatible ways in the >past, but all the cases I know of this have involved release of "version 2" >of the file format. V1 and v2 formats are typically convertible with loss >of information from v2 to v1. Application authors typically go to great >lengths to ensure that users of "v2" do not accidentally send files to "v1" >application owners without the "v1" owners being very aware of their need to >upgrade. In this case "v2" is MNG. And APNG IMO is acceptable if conveyed inside a PNG inside a MNG. > >Backwards compatible extensions to file formats are really big deals. It is >extremely difficult to do. It is impossible to do, if the new format adds features that the spec promises aren't there. >It is much easier to just release a new version. >It is very hard to release a new application version which writes a new file >format which is backwards compatible with the *old* applications (so that >the old apps can edit the new file format with impunity.) > >APNG is not in the slightest backward compatible with PNG. It is PNG v2, >just like AGIF was GIF v2. Worse it has an almost comical similarity to >AGIF in that it seems to repeat some of the same errors in the same way. >For example like AGIF it fails to specify the precise handling of >inter-frame delay and it interprets the 'background' colour information in a >way incompatible with the base format. We can fix those technical problems. > >It is worse than incompatible. > The vote is going to be interesting, if we ever get to that point. Glenn ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: APNG MIME type and extension
by Adeluc
::
Rate this Message:
> From: Vladimir Vukicevic
>>APNG is a backwards-compatible extension to PNG, as was said > > It is not. {.....} See previous message for all article. > It is worse than incompatible. > > John Bowler I completely agree with John Bowler. Up to now I was following quietly the discussion about APNG and I really don't like what I am reading. This proposal is turning a very well done file format into a Babel tower. The only way to "better" respect the PNG specs is to have only 1 big image composed of many subimages. The aCTL chunk indicates the real size of the animation target rectangle and the loop count. Each followed fCTL chunk contains the usual stuff, a frame number and indicates the subrectangle containing the frame image from the big image. The fCTL chunks do not need to be in order. Subrectangles can have different sizes and overlap (if two frames are identical then they can share the same subrectangle), opening the possibility to create great animation effects with ridiculous small file size. Since all the fCTL chunks come before the IDAT, an infinite loop animation may begin immediately when first IDAT chunk is read so interlacing animation is also supported (animation detail quality increases over time). Unfortunately, I already proposed something like that few months ago and it was rejected even for discussion because the big image is not 1 image but many images and applications not supporting the aCTL and fCTL chunk will display a huge image looking like garbage. At least an application not supporting the aCTL and fCTL chunk can edit all the frames in this format. I will vote against a Babel tower for sure. I will NOT necessary vote for my own modifications proposal as well because I feel unconfortable with the idea of a huge garbage image displayed by old browsers. Why did you not simply create a new extension .pna? That will solve all the problems. _________ / Adeluc / ¯¯¯¯¯¯¯¯¯ Keep it simple and stupid! ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: it is worse than incompatible
by glennrp-2
::
Rate this Message:
At 11:37 PM 3/15/2007 -0800, Willem van Schaik wrote:
>> >> It is an incompatible extension to PNG. >> >> It is worse than incompatible. >> > >John, what happened?? I read probably 20 emails from you on all kinds of >little details and suddenly there's this outburst which hints :) that you >simply think this form of APNG simply sucks. Willem, you are missing some of the context if you aren't paying attention to bugzilla.mozilla.org, particularly bugs 18574, 257263, and 257197. I am trying to reserve my own opinions about APNG until the vote, and meanwhile trying to be as evenhanded and fair as possible. It's getting hard to do that. I have had to kill quite a few emails before sending lately. Glenn ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: APNG MIME type and extension
by glennrp-2
::
Rate this Message:
At 08:45 AM 3/16/2007 -0400, Adeluc wrote:
>> From: Vladimir Vukicevic >The only way to "better" respect the PNG specs is to have only 1 big image >composed of many subimages. The aCTL chunk indicates the real size of the >animation target rectangle and the loop count. Each followed fCTL chunk >contains the usual stuff, a frame number and indicates the subrectangle >containing the frame image from the big image. The fCTL chunks do not need >to be in order. Subrectangles can have different sizes and overlap (if two >frames are identical then they can share the same subrectangle), opening the >possibility to create great animation effects with ridiculous small file >size. Since all the fCTL chunks come before the IDAT, an infinite loop >animation may begin immediately when first IDAT chunk is read so interlacing >animation is also supported (animation detail quality increases over time). This is an interesting proposal and in fact is how I made some of the early MNG demos that are on the MNG ftp site. They contain one wide image that is viewed one piece at a time, like a film strip. This lets the deflate compressor take advantage of the frame-to-frame redundancy. If we were to define a PNG-2 with limited animation capability, I think it would have at least this capability. But it does not seem suitable for APNG because the fall-back frame would be a montage instead of a single picture (even though it is a single image) and would be too big. Glenn ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: APNG MIME type and extension
by glennrp-2
::
Rate this Message:
At 09:53 AM 3/16/2007 -0400, Glenn Randers-Pehrson wrote:
>This is an interesting proposal and in fact is how I made some of the >early MNG demos that are on the MNG ftp site. They contain one wide >image that is viewed one piece at a time, like a film strip. Also it's probably part of what Adam was trying to achieve in his competing proposal back in 2004. APNG could be redesigned to use this type of arrangement, thereby achieving 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 an APNG with separate fDAts for each image 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. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
APNG and zero delay
by glennrp-2
::
Rate this Message:
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? Glenn ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: it is worse than incompatible
by Bob Friesenhahn
::
Rate this Message:
On Thu, 15 Mar 2007, Willem van Schaik wrote:
>> >> It is an incompatible extension to PNG. >> >> It is worse than incompatible. >> > > John, what happened?? I read probably 20 emails from you on all kinds of > little details and suddenly there's this outburst which hints :) that you > simply think this form of APNG simply sucks. I hope that no one here is offended that I have been simply deleting all emails related to this aberrant "APNG" format which seems to be politically motivated. We already have PNG and MNG and between the two, any existing problem may be solved. Bob ====================================== Bob Friesenhahn bfriesen@..., http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: APNG and zero delay
by John Bowler
::
Rate this Message:
From: Glenn Randers-Pehrson
>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? No, it is as I said in a previous message: 1) If the inter-frame delay is *greater* than 0.03s then it is used. 2) Otherwise a delay of 0.1s is used (actually, it might be 0.2s) I haven't reverse engineered the code, but this is what the spec implies - it implies 'this is like AGIF' and that's what AGIF does. It is *not* possible to specify a zero delay - it's just like AGIF. Zero delay worked with GIF and >256 colour GIFs were possible, by superimposing frames with the extra colours beyond 256. After AGIF was implemented >256 colour GIF stopped working in Navigator. I believe bugs then rolled into IE, IE reverse engineered and implemented the same delays. The only mystery is exactly what the numbers are, but they are there, they are already implemented and they must be used. John Bowler <jbowler@...> ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: it is worse than incompatible
by John Bowler
::
Rate this Message:
From: Willem van Schaik
>From: John Bowler >>[I] simply think this form of APNG simply sucks. That's a fairly accurate summary. I thought that was obvious when I said: >>From: John Bowler >>Subject: [png-mng-misc] Animation in PNG >>> >>>The key problem seems to be that, despite what it says in the >>>ISO standard and despite the discussion on the PNG mailing lists, >>>the Mozilla Foundation (for want of a way of identifying the groups >>>in question) is prepared to add functionality to its applications >>>which will implement animation within an otherwise indistinguishable >>>PNG file. >>> >>>So my personal inclination, having seen this kind of thing before and >>>having seen the mess which results, is to approve a set of chunks >>>which meets the needs of the Mozilla Foundation and does minimum >>>damage to the ability of other applications to handle PNG >>>files/streams. I.e. a damage limitation approach, rather than simply >>>saying "This is wrong, reject it." From: Willem van Schaik >OK lets take that a little step further: do you think that a simple animated >PNG format is in general impossible within the constraints of the current >PNG specification I can't see a way of adding anything to PNG which changes the rendering in a non-trival way without changing the signature. My suggestion for APNG was, and is, to add stuff in such a way that it *does not* change the rendering - that is backward compatible with current PNG decoders. The animation data is there but it does not get rendered unless it appears in a non-single-image context (i.e. where a PNG cannot occur.) >or do you just think that this way of implementing it is >not the way to do it. In addition I think the proposal is seriously flawed for at least the following reasons: 1) Use of 'safe to copy' chunks. 2) Failure to specify the handling of low inter-frame delays. 3) Failure to specify how to actually render the frames (the intermediate buffer stuff). 4) Unnecessary complexity (extra fields in aCTl, fCTl, fDAt which duplicate information.) 5) No specification of error recovery. 6) No specification of the appropriate MIME types to use to indicate an animation. 7) Mistakes in specifying handling of the bKGD chunk which effectively mean that current PNG decoder handling and editor handling would have to be changed (bKGD would have to become 'safe to copy' for one thing.) 8) Attempts to add CRCs, implementing a whole new way of detecting changes to a PNG stream, which don't actually work. That's without even getting on to issues about how the basic functionality is actually specified. I.e. I'm not even looking at things which maybe could be done better, I'm just looking at things which are broken. BTW I haven't mentioned the CRC problem above yet. I was hoping it would just go away since it is related to (1)... John Bowler <jbowler@...> ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: APNG and zero delay
by glennrp-2
::
Rate this Message:
At 10:52 AM 3/16/2007 -0700, John Bowler wrote:
>From: Glenn Randers-Pehrson >>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? > >No, it is as I said in a previous message: > >1) If the inter-frame delay is *greater* than 0.03s then it is used. >2) Otherwise a delay of 0.1s is used (actually, it might be 0.2s) > >I haven't reverse engineered the code, but this is what the spec implies - >it implies 'this is like AGIF' and that's what AGIF does. A spec must "specify" not "imply" the correct behavior, or it isn't a spec. IMHO time_delay == 0 should mean 0. I know that there are AGIFs (really MGIFs) that attempt to display more than 256 colors by sending multiple tiles with different palettes, that are intended to be displayed all at once. Glenn ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: it is worse than incompatible
by glennrp-2
::
Rate this Message:
At 11:10 AM 3/16/2007 -0700, John Bowler wrote:
>In addition I think the proposal is seriously flawed for at least the >following reasons: > >1) Use of 'safe to copy' chunks. I have explained this before. Unsafe-to-copy would be worse, because the animation would be lost by most PNG editors. >2) Failure to specify the handling of low inter-frame delays. I agree. I think 0 should mean 0. >3) Failure to specify how to actually render the frames (the intermediate >buffer stuff). >4) Unnecessary complexity (extra fields in aCTl, fCTl, fDAt which >duplicate information.) The info in those chunks appears to be essential to me. >5) No specification of error recovery. I don't have an answer to that. >6) No specification of the appropriate MIME types to use to indicate >an animation. Pavlov has agreed to "video/x-png" or something similar. But he insists on the file extension *.png and using the PNG signature. >7) Mistakes in specifying handling of the bKGD chunk which effectively >mean that current PNG decoder handling and editor handling would have to >be changed (bKGD would have to become 'safe to copy' for one thing.) I don't think so. The current proposal doesn't even mention bKGD. >8) Attempts to add CRCs, implementing a whole new way of detecting >changes to a PNG stream, which don't actually work. I don't know what you think is wrong with this method, which is actually recommended in the PNG spec, last two paragraphs of Section 12.13, Chunk Naming Conventions, in the PDG spec (these paragraphs didn't survive the rearrangement of sections while converting to ISO as far as I can tell). Except for the unavoidable 1 out of 4G false positive on each CRC, which we already are living with, what is the problem? Glenn ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: APNG MIME type and extension
by John Bowler
::
Rate this Message:
From: Glenn Randers-Pehrson
>[APNG] is syntactically compatible but philosophically incompatible. >It is designed so that APNG-unaware applications will be able to >display *something*. Right. An analogous extension to another file format is the addition of "frames" in HTML 4. An HTML 4 web site contains two complete copies of the information - a frames one contained inside <frameset> and another one hidden from HTML 4 apps by <noframes> but shown by earlier apps which ignore all the new tags. My objection Vladimir's description of APNG as "backward compatible" is strictly to the use of "compatible" qualified by "backward". APNG is compatible with PNG in precisely the same way that HTML 4.0 (which required <frameset> support) is compatible with HTML 3.2 (which did not even document <frameset>). >The only thing that can happen is >that an APNG-unaware application will put the chunks out of order, which >can be detected by any APNG-aware application and fixed by an APNG-aware >editor. That's one thing which can happen but here are a set of other things which are valid changes, which are undetectable by an APNG aware application but which irreversibly prevent correct display of the animation frames: 1) Changes to gAMA, cHRM, sRGB with corresponding changes to the pixel data. 2) Removal or change of a bKGD chunk. 3) Any direct edit of the IDAT data - i.e. any change to the static image - which does not change the IHDR. (3) is a bit strange, but this is what it says in the PNG spec: "Ordinary image editors are not PNG editors because they usually discard all unrecognized information while reading in an image." So avoiding (3) requires: i) Every author of an editor which changes the information in the pixel data (as opposed to the encoding of that information) has to assume the editor is an "ordinary image editor", not a "png editor". ii) Every such author has to always discard all unrecognised information - not "usually" discard it. I might write a program which automatically puts an image watermark on an image. Personally I would tend to regard this as a "PNG editor" not an "ordinary image editor". Making the chunks "unsafe-to-copy" removes all these problems, leaving only the re-ordering problem. >We can fix those technical problems. Well, indeed we can. It's quite a lot of work though and I would still vote against even a well specified set of chunks if the spec didn't have words to ensure that the extension was only used in contexts where existing applications do not display a static image. John Bowler <jbowler@...> ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: APNG MIME type and extension
by glennrp-2
::
Rate this Message:
At 12:38 PM 3/16/2007 -0700, John Bowler wrote:
>That's one thing which can happen but here are a set of other things which >are valid changes, which are undetectable by an APNG aware application but >which irreversibly prevent correct display of the animation frames: > >1) Changes to gAMA, cHRM, sRGB with corresponding changes to the pixel >data. Right. >2) Removal or change of a bKGD chunk. I don't know. >3) Any direct edit of the IDAT data - i.e. any change to the static image - >which does not change the IHDR. That wouldn't damage the animation, although it might become a non sequitor if the first frame was changed from a duck to a chicken and the rest of the animation was still a duck. >(3) is a bit strange, but this is what it says in the PNG spec: > >"Ordinary image editors are not PNG editors because they usually discard >all unrecognized information while reading in an image." > >So avoiding (3) requires: > >i) Every author of an editor which changes the information in the pixel >data (as opposed to the encoding of that information) has to assume the >editor is an "ordinary image editor", not a "png editor". >ii) Every such author has to always discard all unrecognised information - >not "usually" discard it. Yes that is a problem but copy-safe versus copy-unsafe isn't relevant. They all get discarded. ImageMagick is an "ordinary image editor" and it discards some and keeps a few such as pHYs, gAMA, iCCP, oFFs, and various text chunks. PLTE and IDAT get rewritten. At the moment, APNG chunks would go into the dumpster, but if we approve APNG it will soon handle the datastream as a stream of scenes. > >I might write a program which automatically puts an image watermark >on an image. Personally I would tend to regard this as a "PNG editor" >not an "ordinary image editor". > >Making the chunks "unsafe-to-copy" removes all these problems, By removing the APNG chunks. >leaving >only the re-ordering problem. > >>We can fix those technical problems. > >Well, indeed we can. It's quite a lot of work though and I would still >vote against even a well specified set of chunks if the spec didn't have >words to ensure that the extension was only used in contexts where existing >applications do not display a static image. > >John Bowler <jbowler@...> > > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys-and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >png-mng-misc mailing list >png-mng-misc@... >https://lists.sourceforge.net/lists/listinfo/png-mng-misc > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: APNG MIME type and extension
by glennrp-2
::
Rate this Message:
At 12:38 PM 3/16/2007 -0700, John Bowler wrote:
>I would still >vote against even a well specified set of chunks if the spec didn't have >words to ensure that the extension was only used in contexts where existing >applications do not display a static image. OK. I did try to put your paragraph about that in the proposal but the APNG proponents vehemently refused to allow it, so I took it out again. I would still like to say something in there but right now cannot figure out how to write anything that would be acceptable to both sides. Glenn ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
| < Prev | 1 - 2 - 3 - 4 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
