Email Archive: png-mng-misc (read-only)

[png-mng-misc] VOTE FAILED: APNG 20070405a From: Glenn Randers-Pehrson <glennrp@co...> - 2007-04-20 17:27

FAILED APNG 20070405a ftp://ftp.simplesystems.org/pub/png-group/documents/ png-apng-proposal-20070405a.txt 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. Glenn

 

Thread View

Thread	Author	Date
[png-mng-misc] VOTE NO: APNG 20070405a	Adeluc <png@ad...>

[png-mng-misc] VOTE NO: APNG 20070405a From: Adeluc <png@ad...> - 2007-04-11 02:47 Attachments: Message as HTML      NO APNG 20070405a ftp://ftp.simplesystems.org/pub/png-group/documents/ png-apng-proposal-20070405a.txt Jean-Claude Hebert (Adeluc) <png@ad...> After I read the png-registration-20070406.txt file about voting rules I was no more sure if my vote was recorded or not so I decided to resend it just in case. In 4.2... "Any votes received prior to the call for votes (i.e. the first YES vote after the close of the discusson period) will not be counted."

[png-mng-misc] VOTE NO: APNG 20070405a From: Gerard Juyn <gjuyn@xs...> - 2007-04-11 08:59 NO APNG 20070405a ftp://ftp.simplesystems.org/pub/png-group/documents/ png-apng-proposal-20070405a.txt Gerard Juyn <gjuyn at xs4all.nl> I don't think this is currently the best solution. It may suit the purpose of the Mozilla crew, but it does violate the original intent and philosophy of the PNG spec, not to mention hijacking the .png extension and mime-type as stated by others as well. Sorry, but this just needs a lot more discussion and refinement before I can see it as a viable extension to PNG.

[png-mng-misc] VOTE NO: APNG 20070405a From: Willem van Schaik <willem.schaik@sh...> - 2007-04-11 17:58 NO APNG 20070405a ftp://ftp.simplesystems.org/pub/png-group/documents/ png-apng-proposal-20070405a.txt Willem van Schaik <willem@sc...> If the right animated PNG proposal comes along I would be all in favor for it. As long as that's not happening, I don't understand why software implementers (like Mozilla folks) don't simply adopt MNG.

[png-mng-misc] VOTE NO: APNG 20070405a From: Chris Lilley <chris@w3...> - 2007-04-12 07:54 NO APNG 20070405a ftp://ftp.simplesystems.org/pub/png-group/documents/ png-apng-proposal-20070405a.txt Chris Lilley <chris@w3.org> The current specification has several problems: I have some sympathy with producing an animated format that degrades to a static one, but it also abuses the PNG spec and the image/png Internet media type which will lead to confusion from users and confusion as to what a given authoring tool actually produces. As others have noted, reusing the PNG signature but using a different file extension and a video/* Internet Media type would be one way forward. I do like the idea of a fallback image which is not just the first frame, and which might not be used in the animation at all. I don't like hiding the additional images in discardable chunks, which is what happens when PNG is extended rather than defining a new PNG-family format. I would also prefer it to be possible to reuse an additional image by a more space-efficient manner than adding it to the file multiple times. The compositing operations are odd (compared to other specifications, which use Porter-Duff compositing an the painters algorithm), and under specified wrt transfer function (linear, or gamma corrected) and colorspace. There are references to the PNG specification, which don't resolve as the referenced items are not in the W3C and ISO standard PNG spec. It doesn't seem possible to build up a frame from reusable sprites, which seems like a basic requirement for an animated format. Mind you, I also miss the ability to mix JPEG components with PNG ones. -- Chris Lilley mailto:chris@w3.org Interaction Domain Leader Co-Chair, W3C SVG Working Group W3C Graphics Activity Lead Co-Chair, W3C Hypertext CG

Re: [png-mng-misc] APNG 20070405a (reusable objects) From: Glenn Randers-Pehrson <glennrp@co...> - 2007-04-12 10:43 At 09:54 AM 4/12/2007 +0200, Chris wrote: > I would also prefer it to be possible to reuse an additional image by a more > space-efficient manner than adding it to the file multiple times. >[...] >It doesn't seem possible to build up a frame from reusable sprites, which >seems like a basic requirement for an animated format. Just a little change to APNG to allow montages in the fdATs, with multiple fcTL per group of fdATs, was proposed a while back. Authors could choose to go for maximimum reuse by using only one large montage, like mPNG, or to maximize streamability by using only one image per fdAT, like the current APNG. When that proposal was rejected by the APNG proponents, we spun off mPNG. >Mind you, I also miss the ability to mix JPEG components with PNG ones. That's beyond the scope of APNG, but mPNG and of course MNG will do it. Glenn

Re: [png-mng-misc] APNG 20070405a (reusable objects) From: Gerard Juyn <gjuyn@xs...> - 2007-04-12 11:22 > >Mind you, I also miss the ability to mix JPEG components with PNG ones. > > That's beyond the scope of APNG, but mPNG and of course MNG will do it. mpNG chunk inside a JNG? I hadn't even thought of that yet... heheh It would need to be added to the JNG spec of course. As for MNG, I would definitely prefer to either disallow or ignore the chunk. Multiple animations inside an animation are simply a "timing" nightmare! Gerard

Re: [png-mng-misc] APNG 20070405a (mPNG/APNG in MNG) From: Glenn Randers-Pehrson <glennrp@co...> - 2007-04-12 11:33 At 01:18 PM 4/12/2007 +0200, you wrote: >As for MNG, I would definitely prefer to either disallow or ignore the >chunk. Multiple animations inside an animation are simply a "timing" >nightmare! We discussed that earlier and I think we concluded that mPNG, APNG, etc. should be handled normally in standalone PNGs and JNGs that happen to be labeled as *.mng, video/x-mng, but ignored in embedded ones. Anything beyond that would be impossible to keep track of. Glenn

[png-mng-misc] VOTE NO: APNG 20070405a From: Chaplain Nancy M. Randers-Pehrson <nancyrp@co...> - 2007-04-12 12:32 NO APNG 20070405a ftp://ftp.simplesystems.org/pub/png-group/documents/ png-apng-proposal-20070405a.txt Nancy M. Randers-Pehrson <nancyrp at comcast.net> I don't understand why PNG-in-GIF isn't being given more serious consideration. The animation fallback is better than APNG's still image fallback. I think APNG violates the PNG specification because it hides extra images inside. PNG is only supposed to be for still images! That might not matter much to web browsers, but it will confuse hundreds of other applications.

[png-mng-misc] VOTE NO: APNG 20070405a From: Cosmin Truta <cosmin@cs...> - 2007-04-19 13:46 NO APNG 20070405a ftp://ftp.simplesystems.org/pub/png-group/documents/ png-apng-proposal-20070405a.txt Cosmin Truta <cosmin@cs.toronto.edu> I would change my vote from NO to ABSTAIN if the proposed format would be a clean solution for providing simple animations, without breaching the design and philosophy behind the original PNG format. I would change my vote from ABSTAIN to YES if the proposed format would support JNG (at least as an optional component), or would otherwise provide means for substantial compression, especially in RGB(A) frames. *** I generally like the idea of a well-designed, well-compressed format for low-end animations, and I do appreciate conceptual simplicity. MNG might not have been the best animation format out there, but APNG is worse, even on the accounts where it is claimed to be better. Although APNG puts animation frames in ancillary chunks, animation is not metadata. The PNG file format is guaranteed to be a single-image format. It is not a multimedia container to put animations in. >From this point of view, PNG is not like GIF, which was multi-image from day one (GIF87a), but it is more like JFIF-JPEG. When Netscape devised animation controls to insert between GIF frames, that was a natural thing to do. But I find it ludicrous to store M-JPEG sequences or MPEG videos inside JPEG comments or inside MP3 (ID3) tags. Nobody does that. It naturally goes the other way around. Moreover, the proponents of APNG ostensibly fail to mention the hidden cost of "simplicity". When the MNG support was removed from Mozilla, there was a saving of about 200k of uncompressed executable code. I agree that the full MNG was unnecessarily complicated, but now I fear the day when I will be inundated with deflate-compressed RGBA banners. What then?! Will I have a "Disable RGBA animations" checkbox in the options dialog in Firefox?!! I like it when things are as simple as possible, but not when they are simpler than that. Compression and simplicity are at opposite ends, otherwise we would all use raw formats. Finding the best compromise is an art; unfortunately, APNG is nowhere near the state of the art. I don't see this kind of simplicity for the benefit of the web surfer, but rather for the benefit of the "Mozilla: Lean and Mean" ad campaign. In particular, the lack of JNG hurts both compression and losslessness. I can easily imagine an animation with a scenic background that came out of a digital camera. Or foreground objects composed from sources that only exist in JPEG form. Since the Discrete Cosine Transform is a transcendent function, there is no "lossless" conversion from JPEG to raw RGB or PNG. Anyone who has some background in compression knows that it is generally a bad idea to convert JPEG to PNG, and I would be sad to see APNG animations plagued by the enforcement of that idea. The only valid reason behind the peculiar design of APNG is to encourage adoption. But even that is a weak justification. The key to adoption is not to develop a format that is parasiting on the popularity of an existing one, but to develop a format that is worth adopting. If I were wrong, we would be surrounded by piggybacks. Fortunately, there are not too many popular piggyback formats out there. MP3-Pro, anyone? ;-) Best regards, Cosmin

[png-mng-misc] VOTE NO: APNG 20070405a From: Greg Roelofs <newt@po...> - 2007-04-19 17:27 NO APNG 20070405a ftp://ftp.simplesystems.org/pub/png-group/documents/ png-apng-proposal-20070405a.txt Greg Roelofs PNG is a single-image format. This was baked in from the very start--and for good reasons; the popular failure of MNG does not alter that fact. While I agree with everybody else that a simpler PNG-based animation format would have been a good idea (and may still be a good idea), APNG violates the standards of not just one but three international bodies--four if you count ISO and IEC as separate entities--along with the intent of the PNG group itself. For that reason alone I reject it. (The only approach I see that could reasonably lead to APNG validity would involve a separate PNG spec-change vote to explicitly allow multiple images, with APNG con- tingent on the approval of that change.) The abuse of the PNG format is even more egregious given its complete lack of necessity. As Gerard and others have pointed out, GIF would be an ideal format to extend in this way; it's already an animation format, fallbacks are trivial (and in some ways better than in APNG), and it's merely a de facto standard created by a single company that lost interest in it more than a decade ago: ideal fodder for further abuse. (It would not even be the first time the Mozilla crowd has abused it!) I also agree with John, Chris L, Cosmin and others on some of the specifics (blending, timing); specs are written for implementers, and any ambiguities or unnecessary complexities/incompatibilities should be addressed before approval, not after. (That much, at least, is fixable.) Not that any of this matters. It seemed clear from the start that Stuart and the gang had made up their minds to hack up PNG, and early criticism of that approach by the PNG group had no effect other than to send them off to their own area to continue to do so without the participation of the group. A year or two later they're back, looking for rubber-stamp approval. While I don't necessarily consider such procedural "irregularities" sufficient grounds to reject the proposal, they certainly don't predispose me to approve it, either. That's not how standards work (outside of ECMA, anyway). Greg

[png-mng-misc] Combining PNG and JNG in an animation From: Glenn Randers-Pehrson <glennrp@co...> - 2007-04-19 21:08 At 09:46 AM 4/19/2007 -0400, Cosmin wrote: > >I would change my vote from ABSTAIN to YES if the proposed format >would support JNG (at least as an optional component), or would >otherwise provide means for substantial compression, especially in >RGB(A) frames. > >*** >In particular, the lack of JNG hurts both compression and losslessness. >I can easily imagine an animation with a scenic background that came >out of a digital camera. Or foreground objects composed from sources >that only exist in JPEG form. MNG can do that. But it seems a lot to ask of a simple animation format, to be able to combine JNG and PNG images. It can't be done in MPNG/aNIM because that format relies on a single image to contain all of the animation frames. I suppose APNG and ANG could be expanded to include a different type of fDAT that conveys a JNG frame. Certainly it would be easy to enhance PNG-in-JNG with the capability; it would just require a different extension to contain a JNG. In the interest of KISS I'm not proposing that we do any of that, though, and just leave it to MNG. Glenn

Re: [png-mng-misc] Combining PNG and JNG in an animation From: John Bowler <jbowler@ac...> - 2007-04-20 01:23 From: Glenn Randers-Pehrson >It can't be done >in MPNG/aNIM because that format relies on a single image to contain >all of the animation frames. In principle an anIM chunk could be interpreted when found inside a JNG - indeed I thought that was what Gerard suggested (I might have got that wrong). In principle this allows a full RGBA sprite animation. In practice it won't work for two reasons, both caused by the fact that the JPEG quantisation causes information to spread across each 8x8 pixel block - in other words, after quantisation, every pixel in each block of 64 may gain data from every other pixel: 1) The encoder would have to ensure multiple tiles do not overlap a single 8x8 block. This is soluble. 2) The colour values in JNG are post-multiplied. This causes the colour of transparent pixels to bleed into opaque or partially transparent pixels. This produces unacceptable artefacts, I can see no practical solution. (This doesn't happen with pre-multipled colours, but I think other nasty things happen whereby the colour values may exceed the alpha value for a given pixel.) John Bowler <jbowler@ac...>

Re: [png-mng-misc] Combining PNG and JNG in an animation From: Glenn Randers-Pehrson <glennrp@co...> - 2007-04-20 03:28 At 06:20 PM 4/19/2007 -0700, John Bowler wrote: >From: Glenn Randers-Pehrson >>It can't be done >>in MPNG/aNIM because that format relies on a single image to contain >>all of the animation frames. > >In principle an anIM chunk could be interpreted when found inside a JNG >- indeed I thought that was what Gerard suggested (I might have got that >wrong). When I said "It can't be done" I was talking specifically about combining PNG and JNG in the same frame. mpNG/aNIM can't do that because there is only one image source, which is either PNG or JNG but not both. A single JNG with mpNG/aNIM chunk is OK (although there would be problems with bleeding and such that you mentioned). See the collage demo. Glenn

Re: [png-mng-misc] Combining PNG and JNG in an animation From: Glenn Randers-Pehrson <glennrp@co...> - 2007-04-20 10:32 FWIW (not much) I have added mayflower_q85.mjng and mayflower_q50.mjng to the MPNG demos. Mayflower, being a drawing not a natural image, is unsuitable for JPEG/JNG representation. The files are larger than the .mpng and artifacts are visible in both (only around the text in the _q85.mpng). The issues are essentially the same as when choosing between PNG and JPEG for representing a static image. I'm working on a more suitable demo, consisting of a photograph of a house with various sketches of a proposed deck addition overlaid on it. In this case the photo will look fine but the sketches will probably have artifacts. The author would have to decide whether the filesize savings (which is substantial) is a sufficient tradeoff for the artifacts. Glenn

Re: [png-mng-misc] Combining PNG and JNG in an animation From: Gerard Juyn <gjuyn@xs...> - 2007-04-20 14:19 Hi all, I've create an aNIM enhanced JNG which shows the use of sprites against a static JPEG-encoded backdrop. It is included with the mngview.zip download at the bottom of the page: http://gjuyn.xs4all.nl/pnganim.html The JNG is 33KB, which is just 3KB larger than the original backdrop.... Similar compression would simply not be possible in APNG, ANG or PNG-in-GIF !! Gerard

[png-mng-misc] VOTE FAILED: APNG 20070405a From: Glenn Randers-Pehrson <glennrp@co...> - 2007-04-20 17:27 FAILED APNG 20070405a ftp://ftp.simplesystems.org/pub/png-group/documents/ png-apng-proposal-20070405a.txt 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. Glenn

Re: [png-mng-misc] Combining PNG and JNG in an animation From: Glenn Randers-Pehrson <glennrp@co...> - 2007-04-20 19:33 At 06:20 PM 4/19/2007 -0700, John Bowler wrote: >From: Glenn Randers-Pehrson >>It can't be done >>in MPNG/aNIM because that format relies on a single image to contain >>all of the animation frames. > >In principle an anIM chunk could be interpreted when found inside a JNG >- indeed I thought that was what Gerard suggested (I might have got that >wrong). In principle this allows a full RGBA sprite animation. In >practice it won't work for two reasons, both caused by the fact that the >JPEG quantisation causes information to spread across each 8x8 pixel >block - in other words, after quantisation, every pixel in each block of >64 may gain data from every other pixel: > >1) The encoder would have to ensure multiple tiles do not overlap a >single 8x8 block. This is soluble. > >2) The colour values in JNG are post-multiplied. This causes the colour >of transparent pixels to bleed into opaque or partially transparent >pixels. This produces unacceptable artefacts, I can see no practical >solution. (This doesn't happen with pre-multipled colours, but I think >other nasty things happen whereby the colour values may exceed the alpha >value for a given pixel.) Do these objections apply to a typical use of mixed JNG/PNG, which would likely consist of a photo background with an overlay of computer drawings, e.g. a weather map with isobars, a satellite photo with military overlays, or a house with sketch of proposed addition? Should we propose a JNG-in-GIF GIF extension? It's pretty easy to generate the spec by just changing PNG to JNG in the existing PNG-in-GIF proposal. Glenn

Re: [png-mng-misc] Combining PNG and JNG in an animation From: John Bowler <jbowler@ac...> - 2007-04-21 23:14 From: Glenn Randers-Pehrson >At 06:20 PM 4/19/2007 -0700, John Bowler wrote: >>In principle this allows a full RGBA sprite animation. In >>practice it won't work for two reasons, both caused by the fact that the >>JPEG quantisation causes information to spread across each 8x8 pixel >>block - in other words, after quantisation, every pixel in each block of >>64 may gain data from every other pixel: >>[...] > >Do these objections apply to a typical use of mixed JNG/PNG, which would >likely consist of a photo background with an overlay of computer >drawings, e.g. a weather map with isobars, a satellite photo with >military overlays, or a house with sketch of proposed addition? No, there's no problem with those - the pixels with the partial alpha are losslessly encoded if the overlay is just PNG. It may be possible to make JNG sprites work too by doing something fairly tricky in the encoding to use pre-multiplied pixel values to compute the DCT terms then un-pre-multiply the DCT terms before quantisation. That would mean computing a DCT of the alpha channel too, but it does prevent any bleeding of colour from completely transparent pixels. If this is possible it certainly isn't simple! >Should we propose a JNG-in-GIF GIF extension? It's pretty easy to >generate the spec by just changing PNG to JNG in the existing >PNG-in-GIF proposal. That would work I think and is, as you say, very simple. The global chunk table (if permitted) might require some work. It's also possible to define JPEG-in-GIF but I don't think this group has the authority to do that. John Bowler <jbowler@ac...>

Re: [png-mng-misc] VOTE FAILED: APNG 20070405a From: Vladimir Vukicevic <vladimir@po...> - 2007-04-26 23:11 Glenn Randers-Pehrson wrote: > FAILED > APNG 20070405a > ftp://ftp.simplesystems.org/pub/png-group/documents/ > png-apng-proposal-20070405a.txt > > 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. It's unfortunate that full acceptance of the proposed usage of the chunks is required to register public chunks that may/will be used by multiple vendors. I haven't looked at many other similar standards, but I believe that for TIFF, all that's needed is a form submitted to Adobe. Combined with the requirement that there basically be twice as many YES votes as NO votes, this makes it unlikely that APNG will ever be accepted in any form by this group as long as some of APNG's original core goals are not violated -- or, worse yet, the APNG chunk names will not be able to be reserved for usage by multiple vendors, regardless of their purpose. This seems like a pretty serious failure of the voting system; the desire to avoid clashes in chunk naming is being directly tied to agreement in the usage of those chunks. I know that the PNG-in-GIF proposal was brought up before, and it's being discussed again. I can't help but feel that this is a manifestation of "hey, GIF is a crappy and abused format, let's stick more junk in there because noone cares" because that's felt to be philosophically better than marring the pure PNG format. That's unfortunate; the reason why I'm against PNG-in-GIF is precisely because of GIF. GIF as a format sucks for many reasons; embedding PNG data inside GIF just makes the situation much worse. The fallback to a GIF animation is certainly a plus; but it can also be a minus in other situations (consider wanting the fallback to be a static full RGBA image). However, all of this requires implementors to be able to decode not only PNG but also GIF; in addition, it requires them to basically intertwingle their support for the two formats. This seems like a pretty serious issue for implementors, whether for encoders or decoders. The reason PNG was chosen was because there was a natural way to extend it to provide the simple animation abilities that we were looking for, and because its core capabilities were exactly what we were interested in providing, along with simple animation. The majority of the objections listed in the NO votes center around the philosophical argument of PNG being a single-image format. I guess that's fine, but I have a hard time giving much credence to non-technical arguments. Many people have expressed their desire to see a completely new format, or the usage of MNG. IMO, adoption is not really being given the weight that it deserves as an argument for extending PNG; it's taken how many years for the dominant browser vendor to support PNG fully? Adam Costello's comments in his NO vote raise spec issues that should be discussed and fixed. Similarly, John Bowler's comments regarding the dispose operations need to be addressed as well, perhaps as Chris Nokleberg suggested. Maybe the solution is to provide explicit save-before-rendering-frame and restore-before-rendering-frame operations and get rid of the current combination of dispose operations. This should also be discussed. I'm not really sure where to go from here; I'd certainly like to hear feedback from others, including the implementors of browsers other than Mozilla. We certainly could finalize and publish the spec using the private chunk names as the official ones, or even just publish using capitalized public form and note that these chunk names are not officially registered or recognized. I'd like to see us come to some sort of consensus, though. There are pretty serious disagreements regarding: a) the use of the PNG signature; b) the fallback image type (single-image vs. montage); c) the definition of a "good" fallback image (the data loss issue); d) various feature additions/omissions (JNG/JPEG support, sprites, etc.). The first of these, the PNG signature issue, seems to be the most intractable issue. - Vlad

Re: [png-mng-misc] VOTE FAILED: APNG 20070405a From: Nozomu Katoo <png.ml@ts...> - 2007-04-26 23:59 Vladimir Vukicevic wrote: >I'm not really sure where to go from here; I'd certainly like to hear >feedback from others, including the implementors of browsers other than >Mozilla. We certainly could finalize and publish the spec using the >private chunk names as the official ones, or even just publish using >capitalized public form and note that these chunk names are not >officially registered or recognized. I'd like to see us come to some >sort of consensus, though. I'd suggest this solution again: >Paragraph 4 of the extensions document says: > >>4. Chunks Not Described Here >> >>The definitions of some public chunks are being maintained by groups >>other than the core PNG group. In general, these are chunks that are >>useful to more than one application (and thus are not private chunks), > >Could we not apply this solution to the three chunks of aCTl, fCTl, fDAt? -- Nozomu Katoo <png.ml@ts...>

Re: [png-mng-misc] VOTE FAILED: APNG 20070405a From: Adeluc <png@ad...> - 2007-04-27 00:32 > I'd suggest this solution again: >>Paragraph 4 of the extensions document says: >> >>>4. Chunks Not Described Here >>> >>>The definitions of some public chunks are being maintained by groups >>>other than the core PNG group. In general, these are chunks that are >>>useful to more than one application (and thus are not private chunks), >> >>Could we not apply this solution to the three chunks of aCTl, fCTl, fDAt? > > -- > Nozomu Katoo <png.ml@ts...> Some chunks may be maintained by groups other than the core PNG group but the chunks must be first approved by the core PNG group before they become public. aCTl, fCTl, fDAt chunks have been rejected by more than 55%. _________ / Adeluc / ¯¯¯¯¯¯¯¯¯

Re: [png-mng-misc] VOTE FAILED: APNG 20070405a From: Glenn Randers-Pehrson <glennrp@co...> - 2007-04-27 01:37 At 04:11 PM 4/26/2007 -0700, Vladimir Vukicevic wrote: >GIF as a format sucks for many reasons; embedding PNG data >inside GIF just makes the situation much worse. Embedding APNG inside PNG turns PNG into something very GIF-like. Glenn

Re: [png-mng-misc] aNIM Encoder - Decoder From: Adeluc <png@ad...> - 2007-04-27 02:46 April 26th, 2007, 22h17: Ok I just released version 1.1.0 of "PNG anIM chunk Encoder / Decoder". To get it visit http://adeluc.com/png_anim/ (source code included) I have fixed a major bug in the AlphaBlend() function. If you check the Demo_Transitions_TCA.png animation file you will agree like me that the "m_uchConstantAlpha" variable in the tile structure is a must. The left to right fade transition is totally incredible. (Check TileDescMaker.cpp to see the code that generates the transition text files.) I have no more time to make other animation samples until next week. I hope that will enough to postpone the vote and add the "m_uchConstantAlpha" variable to the aNIM specifications. I am planning to make next week some other stunning animations to promote aNIM and "m_uchConstantAlpha" variable. I hope until then you will agree to add the "m_uchConstantAlpha" variable to the aNIM specifications and postpone the vote in 2 weeks. If you are not yet convince my next animations will surely convince you. =) The great thing about aNIM is once you get all your tiles in one image, you can add alot of effects with very little file increase. _________ / Adeluc / ¯¯¯¯¯¯¯¯¯

[png-mng-misc] A new fresh idea From: Gerard Juyn <gjuyn@xs...> - 2007-04-27 11:26 Dear all, (sorry for the long message I am about to write...) Several things have made me think of a different approach. We have a lot of very intelligent people here with varying technical expertise in the computer graphics arena, and not just encoder/decoder implementations. But somehow we can't find agreement on how to extend the existing PNG format for "simple" animations. Ok, here's the pitch.... what about combining our efforts for a PNG2 format? Please hear me out before jumping to conclusions! PNG2 would not just be PNG + some bits, but it would encompass the family of PNG- like formats. So it would include PNG, JNG and MNG and a new "simple" animation-like thingy which we might as well call ANG (not related to Adam's proposal btw!). PNG2 could have multiple compression-schemes, so the age-old compression_method byte could finally have the meaning it was once written for. E.g. 0=deflate, 1=LZMA, 2=LZW, 3=??? Also the JNG2 component could allow J2K streams. ANG (or ANG2 for naming similarity) could be based on the ANIM proposal, but embedding the aNIM info inside the header-chunk, which could be AHDR (I had already been thinking of proposing something like this in addition to the current proposal). MNG2 would be the old MNG but allowing the new compression schemes. All of them would require backwards compatibility with their predecessor, which would not be difficult because the predecessor of each is a "simpler" form of the new variant. All of them would have new signature-bytes, a new extension and possibly a new mime-type, allthough the old mime-type might suffice. That's up for discussion. Obviously all of this is not compatible with current implementations. So PNG2 would face the same (possibly/probably long) adoption-cycle as PNG did. Let's say 5-10 years. However a reference implementation could be ready within a few weeks or a few months at the most, because all of it has been done to some extent already. Just combining some new (de)compression-mechanisms and allowing the new signatures. libmng already appears to be a perfect testbed for these new things and having looked at the LZMA SDK it looks a breeze to implement (LZW most likely too; as for J2K there is the Jasper lib, but I have yet to look at it). Yes, it does not solve the apparent "immediate" problem of a backwards implementation compatible "simple" PNG animation format. But from the current proposals we could pick the least harmful for the adoption of a future PNG2 format, but that would satisfy the intermediate gap. If we pick wisely, converting from this to the new PNG2 family should be as easy as possible. As Greg pointed out, we have a number of anniverseries coming up and perhaps it *is* time to start thinking about a PNG2 format. As I see it the PNG2 family would have 4 siblings. No encoder/decoder would be required to support all of them. Just for a MNG2 implementation it would obviously be a peace of cake. But single image software could pick out PNG2 (+ optionally JNG2), and implementations requiring simple animation could adopt ANG2 if MNG2 was too heavy for their purpose. I'm not sure if all of this is making things easier or not, but *now* seems to be as good a time as any to give it some thought anyway. It would definitely be worthwhile if we could bring other parties (think Microsoft, Opera, KDE, Adobe, JASC, etc, etc, etc....) into the fray. We have had people from there on the list. In fact one of them worked for MS and got me in contact with them for a while. This could've led to MNG being embedded inside Windows and thus available to IE automatically. Unfortunately a certain situation changed and the whole idea got buried. But anyway.... what's everyone idea about this? Gerard

Re: [png-mng-misc] VOTE FAILED: APNG 20070405a From: Glenn Randers-Pehrson <glennrp@co...> - 2007-04-27 13:08 At 04:11 PM 4/26/2007 -0700, Vladimir Vukicevic wrote: >I'm not really sure where to go from here; You could: 1. Give up on using the PNG signature. Use \214ANG\c\n^z\n instead. If you must have fallback, then consider PNG-in-GIF. 2. Use critical chunk names ACTL and FCTL. No more need for sequence numbering. The only purpose for the ancillary chunk usage was to hide the animation in a PNG. With a new ANG signature you don't need to hide it. 3. Use IDAT instead of FDAT, without sequence numbering. 4. Consider allowing montages with multiple FCTL. This gives you the power of mpNG/aNIM. At one extreme you have a single image per IDAT stream, like APNG, and at the other extreme you have all of the images in a single IDAT stream, like aNIM.

Re: [png-mng-misc] VOTE FAILED: APNG 20070405a From: Glenn Randers-Pehrson <glennrp@co...> - 2007-04-27 14:24 At 09:09 AM 4/27/2007 -0400, Glenn Randers-Pehrson wrote: >At 04:11 PM 4/26/2007 -0700, Vladimir Vukicevic wrote: >>I'm not really sure where to go from here; > >You could: > > 1. Give up on using the PNG signature. Use \214ANG\c\n^z\n >instead. If you must have fallback, then consider PNG-in-GIF. > > 2. Use critical chunk names ACTL and FCTL. No more need for >sequence numbering. The only purpose for the ancillary chunk usage >was to hide the animation in a PNG. With a new ANG signature you >don't need to hide it. > > 3. Use IDAT instead of FDAT, without sequence numbering. > > 4. Consider allowing montages with multiple FCTL. This gives you >the power of mpNG/aNIM. At one extreme you have a single image per >IDAT stream, like APNG, and at the other extreme you have all of the >images in a single IDAT stream, like aNIM. Revising this proposal slightly: 3. Use FDAT instead of fdAT, without sequence numbering. 4. Consider allowing montages with multiple FCTL except for the first (fallback) image. This gives... A minimal APNG reader would have to recognize the new signature, recognize and ignore the ACTL, FCTL, and FDAT chunks, and display the fallback image. A full APNG reader would decode ACTL, FCTL, and FDAT, and display the animation.

Re: [png-mng-misc] VOTE FAILED: APNG 20070405a From: Glenn Randers-Pehrson <glennrp@co...> - 2007-04-27 14:41 I still don't understand exactly what is wrong with PIG, for use as a simple web animation format. At 04:11 PM 4/26/2007 -0700, Vladimir Vukicevic wrote: >I know that the PNG-in-GIF proposal was brought up before, and it's >being discussed again. I can't help but feel that this is a >manifestation of "hey, GIF is a crappy and abused format, let's stick >more junk in there because noone cares" because that's felt to be >philosophically better than marring the pure PNG format. That's >unfortunate; the reason why I'm against PNG-in-GIF is precisely because >of GIF. GIF as a format sucks for many reasons; Don't some of those reasons carry over into APNG? >embedding PNG data >inside GIF just makes the situation much worse. > >The fallback to a GIF animation is certainly a plus; but it can also be >a minus in other situations (consider wanting the fallback to be a >static full RGBA image). Why would you want that? You are trying to convey an animation. What good is a throbber that doesn't throb? >However, all of this requires implementors to >be able to decode not only PNG but also GIF; in addition, it requires >them to basically intertwingle their support for the two formats. Like Andrew's Firefox patch? APNG seems to require a lot of intertwingling as well. >This >seems like a pretty serious issue for implementors, whether for encoders >or decoders. Right, but it doesn't seem to favor APNG over PIG much. >The reason PNG was chosen was because there was a natural way to extend >it to provide the simple animation abilities that we were looking for, GIF already has the simple animation ability you were looking for. Glenn

Re: [png-mng-misc] VOTE FAILED: APNG 20070405a From: Andrew Smith <asmith15@le...> - 2007-04-27 15:02 Glenn Randers-Pehrson a écrit : >> However, all of this requires implementors to >> be able to decode not only PNG but also GIF; in addition, it requires >> them to basically intertwingle their support for the two formats. > > Like Andrew's Firefox patch? APNG seems to require a lot of intertwingling > as well. > It does not. The only part of the patch required for Firefox supporting APNG was the libpng patch + nsPNGDecoder. Other changes creeped in as 'nice to have'-s. Andrew

Re: [png-mng-misc] VOTE FAILED: APNG 20070405a From: Glenn Randers-Pehrson <glennrp@co...> - 2007-04-27 16:23 At 11:01 AM 4/27/2007 -0400, you wrote: >Glenn Randers-Pehrson a écrit : >>> However, all of this requires implementors to >>> be able to decode not only PNG but also GIF; in addition, it requires >>> them to basically intertwingle their support for the two formats. >> >> Like Andrew's Firefox patch? APNG seems to require a lot of intertwingling >> as well. >> >It does not. The only part of the patch required for Firefox supporting >APNG was the libpng patch + nsPNGDecoder. Other changes creeped in as >'nice to have'-s. I mistook the changes to src/imgContainer.* as intertwingling. Also the changes to GIF2.* but I see now that those have nothing to do with APNG.

Re: [png-mng-misc] A new fresh idea From: Sarreq Teryx <sarreq@gm...> - 2007-04-28 06:58 Attachments: Message as HTML      It sounds like an excellent plan to me. As long as we're talking a theoretical 2.0 spec, I'd like to also suggest the possibility of HDR color modes (12, 16, and 32 bits/channel at least) to keep up with the future On 4/27/07, Gerard Juyn <gjuyn@xs...> wrote: > > Dear all, > > (sorry for the long message I am about to write...) > > Several things have made me think of a different approach. We have > a lot of very intelligent people here with varying technical expertise in > the computer graphics arena, and not just encoder/decoder > implementations. But somehow we can't find agreement on how to > extend the existing PNG format for "simple" animations. > > Ok, here's the pitch.... what about combining our efforts for a PNG2 > format? > > Please hear me out before jumping to conclusions! PNG2 would not > just be PNG + some bits, but it would encompass the family of PNG- > like formats. So it would include PNG, JNG and MNG and a new > "simple" animation-like thingy which we might as well call ANG (not > related to Adam's proposal btw!). I know there would definitely people against this, but simplifying the number of extensions would be a good thing, to reduce user confusion PNG2 = static image, with or w/o alpha channel, compressed in any way available to the format MNG2, APNG, ANG2 or PNGA (I say PNGA myself) = animated image, with or w/o alpha channel, compressed in any way available to the format PNG2 could have multiple compression-schemes, so the age-old > compression_method byte could finally have the meaning it was once > written for. E.g. 0=deflate, 1=LZMA, 2=LZW, 3=??? > Also the JNG2 component could allow J2K streams. ANG (or ANG2 > for naming similarity) could be based on the ANIM proposal, but > embedding the aNIM info inside the header-chunk, which could be > AHDR (I had already been thinking of proposing something like this in > addition to the current proposal). MNG2 would be the old MNG but > allowing the new compression schemes. " E.g. 0=deflate, 1=LZMA, 2=LZW, 3=??? " I would think to start with: 0=bog standard current deflate 1=LZMA 2=LZW 3=JPEG 4=JP2K 5= Any other ideas? All of them would require backwards compatibility with their > predecessor, which would not be difficult because the predecessor of > each is a "simpler" form of the new variant. > > All of them would have new signature-bytes, a new extension and > possibly a new mime-type, allthough the old mime-type might suffice. > That's up for discussion. > > Obviously all of this is not compatible with current implementations. So > PNG2 would face the same (possibly/probably long) adoption-cycle > as PNG did. Let's say 5-10 years. However a reference > implementation could be ready within a few weeks or a few months at > the most, because all of it has been done to some extent already. Just > combining some new (de)compression-mechanisms and allowing the > new signatures. libmng already appears to be a perfect testbed for > these new things and having looked at the LZMA SDK it looks a > breeze to implement (LZW most likely too; as for J2K there is the > Jasper lib, but I have yet to look at it). > > Yes, it does not solve the apparent "immediate" problem of a > backwards implementation compatible "simple" PNG animation > format. But from the current proposals we could pick the least harmful > for the adoption of a future PNG2 format, but that would satisfy the > intermediate gap. If we pick wisely, converting from this to the new > PNG2 family should be as easy as possible. > > As Greg pointed out, we have a number of anniverseries coming up > and perhaps it *is* time to start thinking about a PNG2 format. > > As I see it the PNG2 family would have 4 siblings. No > encoder/decoder would be required to support all of them. Just for a > MNG2 implementation it would obviously be a peace of cake. But > single image software could pick out PNG2 (+ optionally JNG2), and > implementations requiring simple animation could adopt ANG2 if > MNG2 was too heavy for their purpose. > > I'm not sure if all of this is making things easier or not, but *now* > seems to be as good a time as any to give it some thought anyway. > > It would definitely be worthwhile if we could bring other parties (think > Microsoft, Opera, KDE, Adobe, JASC, etc, etc, etc....) into the fray. > We have had people from there on the list. In fact one of them > worked for MS and got me in contact with them for a while. This > could've led to MNG being embedded inside Windows and thus > available to IE automatically. Unfortunately a certain situation > changed and the whole idea got buried. > > But anyway.... what's everyone idea about this? > > > Gerard > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > png-mng-misc mailing list > png-mng-misc@li... > https://lists.sourceforge.net/lists/listinfo/png-mng-misc >

Re: [png-mng-misc] aNIM Encoder - Decoder From: Glenn Randers-Pehrson <glennrp@co...> - 2007-04-28 09:43 No comments from anyone about the suggestion to add a constant-alpha byte to the playlist entries? It's holding up the call-for-vote for now. Glenn

Re: [png-mng-misc] aNIM Encoder - Decoder From: Gerard Juyn <gjuyn@xs...> - 2007-04-28 19:26 > No comments from anyone about the suggestion to add a constant-alpha > byte to the playlist entries? It's holding up the call-for-vote for > now. My initial thought was "no", because of the direct link to an OS- function which makes it platform-dependant. But the calculation is fairly simply to execute. A well-written decoder would hopefully check the extreme cases 0 and 255 and simplify the calculation per pixel. That check is per tile, so definitely worth the little extra effort. I would also like to suggest an extra byte in the header part of the anIM chunk to indicate whether these opaque values are present in each tile-structure or not. I think most animations would be built without them, so it would be useful to save the extra byte per tile. Gerard

Re: [png-mng-misc] aNIM Encoder - Decoder From: Glenn Randers-Pehrson <glennrp@co...> - 2007-04-28 22:34 At 09:22 PM 4/28/2007 +0200, you wrote: >I would also like to suggest an extra byte in the header part of the >anIM chunk to indicate whether these opaque values are present in >each tile-structure or not. I think most animations would be built >without them, so it would be useful to save the extra byte per tile. After compression of a lot of 255's, it's a lot less than a byte per tile. How about an "all offsets are zero" flag as well, and maybe an "all delays are the same" flag? anIM starts to look like the MNG FRAM chunk. Glenn

Re: [png-mng-misc] aNIM Encoder - Decoder From: John Bowler <jbowler@ac...> - 2007-04-29 02:50 From: Glenn Randers-Pehrson >No comments from anyone about the suggestion to add a constant-alpha >byte to the playlist entries? It's holding up the call-for-vote for now. I went back and looked at the Win32 AlphaBlend function and, IMO, it is both broken and useless, unfortunately that's kinda irrelevant for the suggestion. AlphaBlend is broken because it does not linearise the component values before performing the blend (take a look at the math in the documentation which consistently uses 255.0 maxima - we *know* these are sRGB values in Windows!) That means AlphaBlend can't be used to implement any even vaguely conformant PNG alpha blending - the errors are simply too large (25%). The 'constant alpha' stuff in AlphaBlend is, I believe, opportunistic feature creation on behalf of the original author of the function. It has a very specific purpose; to fade in or fade out an overlay (the uConstantAlpha in AlphaBlend adds to the alpha in the base image). Fade in/out, however, is only one effect which might be used in an animation and my opinion is that it has no more validity than any other RGBA transform. Such transforms use a 5x5 matrix to transform a single pixel RGBA1 value into some other value. They can be used for fade in/out, for something like blue screening (transform colour into alpha), sepia toning, effects like the PowerPoint "washout" effect (add white, reduce range), contrast/brightness. I think these are not KISS and adding an 8 bit value to every tile structure achieves only one of these effects (fade in/out). Worse it would require considerable specification; for example, how does the alpha compose with the existing alpha channel, what about 16 bit alpha channels? I say no. John Bowler <jbowler@ac...>

Re: [png-mng-misc] aNIM Encoder - Decoder From: Adeluc <png@ad...> - 2007-04-30 01:37 >> No comments from anyone about the suggestion to add a constant-alpha >> byte to the playlist entries? It's holding up the call-for-vote for >> now. > > My initial thought was "no", because of the direct link to an OS- > function which makes it platform-dependant. But the calculation is > fairly simply to execute. A well-written decoder would hopefully check > the extreme cases 0 and 255 and simplify the calculation per pixel. > That check is per tile, so definitely worth the little extra effort. > > I would also like to suggest an extra byte in the header part of the > anIM chunk to indicate whether these opaque values are present in > each tile-structure or not. I think most animations would be built > without them, so it would be useful to save the extra byte per tile. My suggestion of a constant-alpha byte in the tile structure is not linked with a Windows function. I simply had this idea after reading the specifications of a Windows function. The demo application I made available to show you the possibilities does not use any Windows functions but my own AlphaBlend() function that you can modify from the source code to make it supports gamma or whatever you want. As you can see it already coverts cases of 0 and 255 to speed up things. You can create a lot of animated fade in/out effects and not only a big rectangle fade in/out. You can also use the constant-alpha byte to create static or animated gradient background. I am back for my little trip to Montreal and I will do more animation samples Monday to show you more possible uses of that constant-alpha byte that compresses very well when not used and set to 255 (opaque). To get version 1.1.0 of "PNG anIM chunk Encoder / Decoder". visit http://adeluc.com/png_anim/ (source code included). _________ / Adeluc / ¯¯¯¯¯¯¯¯¯

Re: [png-mng-misc] aNIM Encoder - Decoder From: John Bowler <jbowler@ac...> - 2007-04-30 06:49 From: Adeluc >You can create a lot of animated fade in/out effects and not only a big >rectangle fade in/out. Fade in/out is widely used in animations, but then so are other things like morphing text banners in and out (well, they were last time I watched television.) It still seems to me that adding something like this is a major step - why stop there? Why not other transforms (spatial or colour?) So far as I can see a fade in or out can be easily accomplished at present by defining a tile which has the desired image pre-composed with a low alpha (say 20%). Displaying this tile repeatedly in the same place will fade it in (or out). At most this requires two copies of the tile (one with 20% alpha, one opaque), and, in practice, probably not even that. Since a fade in must take significant time I can't see that the computation overhead would be a problem. John Bowler <jbowler@ac...>

Re: [png-mng-misc] aNIM Encoder - Decoder From: Adeluc <png@ad...> - 2007-04-30 23:23 >>You can create a lot of animated fade in/out effects and not only a big > >>rectangle fade in/out. > > Fade in/out is widely used in animations, but then so are other things > like morphing text banners in and out (well, they were last time I > watched television.) It still seems to me that adding something like > this is a major step - why stop there? Why not other transforms > (spatial or colour?) Because we want to keep current anIM specifications KISS. The constant alpha byte does not add any complexity to the alpha blend formula already used to compose the buffer. But it adds a formidable plus value to the format. If our goal is to make a format widely supported we need to put meat around the bone while keeping it very easy to implement. Adding scaling, morphing and color cycle is no more KISS and adds a lot of programmation. The constant alpha byte is already integrated into anIM that uses the alpha channel for blending. I think your major concern is about the extra byte per tile. If it is only that then I propose to add a tile_struct_type byte into the header part of anIM with values: 0 == Array contains short tiles; 1 == Array contains tiles with constant alpha variable. The decoder only needs to support the second one since it can assume a constant alpha value of 255 for all short tile structures. That also opens the possibilities for future tile structure defintions. > So far as I can see a fade in or out can be easily accomplished at > present by defining a tile which has the desired image pre-composed with > a low alpha (say 20%). Displaying this tile repeatedly in the same > place will fade it in (or out). At most this requires two copies of the > tile (one with 20% alpha, one opaque), and, in practice, probably not > even that. Since a fade in must take significant time I can't see that > the computation overhead would be a problem. With 20% you will get a reduction of the color accuracy by 5 (instead of 256 levels of light you get only 50.) Your fadings will look horribly jaggy with big % value and the image data will at least double. And finally controlling your fading % is inconsistant: Blending 20% of a color --> 80% of actual buffer color + 20% of the new color 1st: +0.20color --> 0.80 x initial_black + 0.20color = 0.20color 2nd: +0.20color --> 0.80 x 0.20color + 0.20color = 0.36color 3rd: +0.20color --> 0.80 x 0.36color + 0.20color = 0.488color 4th: +0.20color --> 0.80 x 0.488color + 0.20color = 0.5904color 5th: +0.20color --> 0.80 x 0.5904color + 0.20color = 0.67232color More I experiment with the constant alpha, and more I can't imagine not having it in anIM. I am working on more powerful animation samples. I will post a link very soon when they will be ready. _________ / Adeluc / ¯¯¯¯¯¯¯¯¯

Re: [png-mng-misc] aNIM Encoder - Decoder From: Glenn Randers-Pehrson <glennrp@co...> - 2007-05-01 00:52 At 07:23 PM 4/30/2007 -0400, you wrote: >I think your major concern is about the extra byte per tile. Look at the "deck" demo at http://www.simplesystems.com/users/glennrp/mpng It does a "fade-in" with 8 steps, requiring a total of 45 entries in the playlist. With the constant-alpha field, it would take only 17 entries. However, many of the 45 entries are identical and the playlist compresses to 68 bytes, while the smaller playlist with different "constant-alpha" entries compresses to 115 bytes. Glenn

Re: [png-mng-misc] aNIM Encoder - Decoder From: John Bowler <jbowler@ac...> - 2007-05-01 05:37 From: Adeluc >Because we want to keep current anIM specifications KISS. The constant >alpha byte does not add any complexity to the alpha blend formula already=20 >used to compose the buffer. It adds enormous complexity. It forces an implementation to write its own alpha blend - that means it has to linearise and it has to be able to read the destination buffer. This is impossible in some environments. Consequently doing this one apparently simple thing makes anIM all but unimplementable in some environments. While it's not directly applicable to animations consider rendering a PNG with an alpha channel onto a printer. The printer surface is not readable, but if the printer interface supports PNG directly the rendering operation is possible. PNG support at the device level has been possible in Windows systems for almost ten years and a reasonable OS interface has been available for at least 5 (via GDI+). The device level interfaces, however, do not permit composition of additional alpha (so far as I know) or, indeed, any colour space transform which can't be expressed via an ICC profile. This is a classic example of the dangers of opportunistic feature creep - it looks simple if a particular implementation is assumed, but it unintentionally prevents other implementations. It certainly is *not* KISS - indeed it is the exact opposite, it's make-it-more-complex-because-the-problems-aren't-obvious. John Bowler <jbowler@ac...>

Re: [png-mng-misc] aNIM Encoder - Decoder From: Adeluc <png@ad...> - 2007-05-01 05:44 >>I think your major concern is about the extra byte per tile. > > Look at the "deck" demo at > http://www.simplesystems.com/users/glennrp/mpng > > It does a "fade-in" with 8 steps, requiring a total of 45 entries > in the playlist. With the constant-alpha field, it would take > only 17 entries. However, many of the 45 entries are identical > and the playlist compresses to 68 bytes, while the smaller playlist > with different "constant-alpha" entries compresses to 115 bytes. > > Glenn Here is my test: I made a 150 frames animation composed of 3855 tiles Complex fading effects with a lot of different constant alpha values (file size of 879,221 bytes) : 3855 tiles = 9187 bytes (compressed). Average of 2.383 bytes per tile. Same animation with saving a constant alpha value of 255 (file size of 871,224 bytes) : 3855 tiles = 1190 bytes (compressed). Average of 0.308 bytes per tile. Same animation without saving the constant alpha variables (file size of 871,198 bytes) : 3855 tiles = 1164 bytes (compressed). Average of 0.302 bytes per tile. Conclusion: The constant-alpha byte made no difference in file size. I find it unnecessary to complicated the anIM header with my suggested tile_struct_type byte variable to support two kind of tile structures. _________ / Adeluc / ¯¯¯¯¯¯¯¯¯

Re: [png-mng-misc] aNIM Encoder - Decoder From: Adeluc <png@ad...> - 2007-05-01 06:20 > It adds enormous complexity. It forces an implementation to write its > own alpha blend - that means it has to linearise and it has to be able > to read the destination buffer. This is impossible in some > environments. Consequently doing this one apparently simple thing makes > anIM all but unimplementable in some environments. If you want your decoder to support color correction or gamma you will need to write a custom alpha blend function anyway. A typical alpha blend function used the following simple formulas. (The source is pre-multiplied in these formulas.) It is when you blend the composed buffer with the canvas that you may use an OS dependent function. If you absolutely want to use an OS dependent alpha blend function during the composition process simply do it in two steps: Prepare a copy of the tile with SourceConstantAlpha then call the OS dependent alpha blend function. Src.Red = Src.Red * SourceConstantAlpha / 255.0; Src.Green = Src.Green * SourceConstantAlpha / 255.0; Src.Blue = Src.Blue * SourceConstantAlpha / 255.0; Src.Alpha = Src.Alpha * SourceConstantAlpha / 255.0; Dst.Red = Src.Red + (1 - Src.Alpha) * Dst.Red Dst.Green = Src.Green + (1 - Src.Alpha) * Dst.Green Dst.Blue = Src.Blue + (1 - Src.Alpha) * Dst.Blue Dst.Alpha = Src.Alpha + (1 - Src.Alpha) * Dst.Alpha > While it's not directly applicable to animations consider rendering a > PNG with an alpha channel onto a printer. The printer surface is not > readable, but if the printer interface supports PNG directly the > rendering operation is possible. PNG support at the device level has > been possible in Windows systems for almost ten years and a reasonable > OS interface has been available for at least 5 (via GDI+). The device > level interfaces, however, do not permit composition of additional alpha > (so far as I know) or, indeed, any colour space transform which can't be > expressed via an ICC profile. The SourceConstantAlpha is used during the process of the composition of the buffer that IS readable by the decoder (read the anIM specifications). If I am missing something light my lantern because I really not see any concrete situation where a SourceConstantAlpha cannot be implemented. _________ / Adeluc / ¯¯¯¯¯¯¯¯¯

Re: [png-mng-misc] aNIM Encoder - Decoder From: Glenn Randers-Pehrson <glennrp@co...> - 2007-05-01 11:04 At 10:33 PM 4/30/2007 -0700, John Bowler wrote: >From: Adeluc >>Because we want to keep current anIM specifications KISS. The constant > >>alpha byte does not add any complexity to the alpha blend formula >already >>used to compose the buffer. > >It adds enormous complexity. It forces an implementation to write its >own alpha blend - that means it has to linearise and it has to be able >to read the destination buffer. This is impossible in some >environments. Consequently doing this one apparently simple thing makes >anIM all but unimplementable in some environments. I don't think it adds *any* complexity other than a little bit of code to read the extra byte and apply the alpha to the tile. Once the tile has been recovered from the PNG image and the constant alpha applied, from there on it can be handled exactly as if the tile had had its own alpha per pixel. Glenn

Re: [png-mng-misc] aNIM Encoder - Decoder From: Adeluc <png@ad...> - 2007-05-01 13:01 > I don't think it adds *any* complexity other than a little bit of code > to read the extra byte and apply the alpha to the tile. Once the tile > has been recovered from the PNG image and the constant alpha applied, > from there on it can be handled exactly as if the tile had had its own > alpha per pixel. It is exactly what happened when I did my application. By the way, the reason I did not used the Windows AlphaBlend() function is because it only works with pre-multiplied source and the tiles in the IDAT are not. That is probably the case of many other OS dependent functions. (DirectX functions required premultiplied source.) Conclusion: Even without the Constant Alpha byte you will need to create a custom AlphaBlend() to support non and pre multiplied source. The composition process uses non-multiplied sources and the final blending of the buffer to the canvas uses the pre-multiplied composed buffer as the source. _________ / Adeluc / ¯¯¯¯¯¯¯¯¯

[png-mng-misc] anIM Tile_alpha From: Glenn Randers-Pehrson <glennrp@co...> - 2007-05-01 13:15 Addition to the proposal: 1) change "26" to "27" 3 places 2) add to tile structure 26 tile_alpha (unsigned byte) Alpha multiplier for tile 3) add new paragraph 3.7.6 and renumber subsequent paragraphs: 3.7.6 Tile Alpha The tile_alpha is a multiplier that the decoder applies to alpha value for each pixel of the tile before compositing it: combined_pixel_alpha(x,y) = pixel_alpha(x,y) * (tile_alpha / 255) The combined_pixel_alpha has the same bit depth as the pixel_alpha, except when the tile_alpha is not 255 and the pixel_alpha has less than 8 bits, in which case the result must have 8 bits. If the tile_alpha is 255, combined_pixel_alpha is simply pixel_alpha.

Re: [png-mng-misc] aNIM Encoder - Decoder From: Glenn Randers-Pehrson <glennrp@co...> - 2007-05-01 13:50 At 10:33 PM 4/30/2007 -0700, you wrote: >PNG support at the device level has >been possible in Windows systems for almost ten years and a reasonable >OS interface has been available for at least 5 (via GDI+). The device >level interfaces, however, do not permit composition of additional alpha >(so far as I know) or, indeed, any colour space transform which can't be >expressed via an ICC profile. I am not following this argument. It seems to me that the proposal is simply to adjust the PNG alpha before sending it along to the next step in the process. The device interface or whatever should not care whether it is receiving the alpha directly from the PNG decoding or whether the alpha has been adjusted somehow after decoding, such as via a tile_alpha multiplier. Glenn > >This is a classic example of the dangers of opportunistic feature creep >- it looks simple if a particular implementation is assumed, but it >unintentionally prevents other implementations. It certainly is *not* >KISS - indeed it is the exact opposite, it's >make-it-more-complex-because-the-problems-aren't-obvious. >

Re: [png-mng-misc] anIM Tile_alpha From: Glenn Randers-Pehrson <glennrp@co...> - 2007-05-01 14:07 At 09:15 AM 5/1/2007 -0400, I wrote: >The tile_alpha is a multiplier that the decoder applies to alpha value >for each pixel of the tile before compositing it: > > combined_pixel_alpha(x,y) = pixel_alpha(x,y) * (tile_alpha / 255) I guess that should be combined_pixel_alpha(x,y) = pixel_alpha(x,y) * (tile_alpha / 255.0) so the multiplier doesn't come out zero unexpectedly. Glenn

Re: [png-mng-misc] anIM Tile_alpha From: Gerard Juyn <gjuyn@xs...> - 2007-05-01 15:27 > I guess that should be > > combined_pixel_alpha(x,y) = pixel_alpha(x,y) * (tile_alpha / 255.0) > > so the multiplier doesn't come out zero unexpectedly. Is the situation (tile_alpha == 0) really useful? It's basically a no-op, right? So why not make the calculation: new_pixel_alpha(x,y) = ((pixel_alpha(x,y) * (tile_alpha + 1)) + 128) >> 8; Should we mention that the PNG image itself may not have any alpha- information defined, which means the tile_alpha simply creates a new alpha-layer for the image? I don't think this really complicates the proposal. It's an easy to implement feature with little overhead. Also in todays world it is quite common to apply a single opaqueness value to a blob of pixels. There are plenty of examples where this is used to partially hide application windows, blocks of HTML, etc, etc... It can even be applied to a still PNG image as well as an animation! Gerard

Re: [png-mng-misc] aNIM Encoder - Decoder From: John Bowler <jbowler@ac...> - 2007-05-01 15:43 From: Glenn Randers-Pehrson [mailto:glennrp@co...]=20 >I don't think it adds *any* complexity other than a little bit of code >to read the extra byte and apply the alpha to the tile. Once the tile >has been recovered from the PNG image and the constant alpha applied, >from there on it can be handled exactly as if the tile had had its own >alpha per pixel. It is not necessary to "recover the tile from the PNG image". These are basic operations of the bitmap supporting libraries I know about and are basic operations in SVG: 1) Load a PNG dataset (from a file or stream). 2) Blit a rectangular area of the loaded dataset either onto a device or into an intermediate bitmap. (2) includes alpha composition - a library which loads PNG (like, for example, GDI+ on Windows) has to support alpha. In other words most of the work of implementing anIM is in decoding the playlist, apart from that the it comes down to: png_image =3D load_png_data(png_file); frame =3D NULL; frame_list =3D NULL; for (tile =3D tile_info; tile =3D tile->next; tile !=3D NULL) { if (frame =3D=3D NULL) frame =3D create_bitmap(frame_width, frame_height); blit(png_image, tile->x, tile->y, tile->width, tile->height, tile->height, frame, tile->dest_x, tile->dest_y); if (tile->delay !=3D 0 && tile->next =3D=3D 0) { new_frame =3D malloc(sizeof *new_frame); new_frame->delay =3D tile->delay; new_frame->bitmap =3D frame; new_frame->prev =3D frame_list; frame_list =3D new_frame; } } Take a look at that! Most of the code is in handling the frame list (which the above code produces in the reverse order...) and, of course, the error handling which I left out and the tile_info reading (anIM chunk) which I left out! The work to blit an image is already supported in any reasonable graphics library, the functionality is required by any SVG decoder and many display devices have device-level alpha composition support (possibly broken) which can do the blit independently of the main CPU. Manipulating the information in the PNG image on a per-pixel basis requires, at minimum, setting up non-default parameters for the blit and may, in fact, require getting at the individual pixels and doing it yourself. That is not KISS. John Bowler <jbowler@ac...> =09

Re: [png-mng-misc] anIM Tile_alpha From: Adeluc <png@ad...> - 2007-05-01 15:47 > I guess that should be > > combined_pixel_alpha(x,y) = pixel_alpha(x,y) * (tile_alpha / 255.0) > > so the multiplier doesn't come out zero unexpectedly. To speed up things I always try to avoid floats when it is possible. So to avoid rounding to zero perform all the multiplications and keep the division for the end. combined_pixel_alpha(x,y) = (((pixel_alpha(x,y) * tile_alpha) + 127) / 255); > Is the situation (tile_alpha == 0) really useful? It's basically a no-op, > right? So why not make the calculation: A value of 0 is useful is you want to fade out an image up to the canvas alone while keeping the generation of tile descriptions simple. That lets you set a delay for a period where the animation is invisible. I used it with the spinning stereo pipe cube animation sample. I really do not like the idea of not supporting tile_alpha == 0 simply to write the formula differently. In my implementation of custom AlphaBlend() function I splitted it in 3 cases for fast calculation loops. tile_alpha == 0: nothing to do; tile_alpha == 255: no pre-calculation; tile_alpha == [1,254] do the pre-calculations before blending. _________ / Adeluc / ¯¯¯¯¯¯¯¯¯

Re: [png-mng-misc] aNIM Encoder - Decoder From: Adeluc <png@ad...> - 2007-05-01 15:53 > The work to blit an image is already supported in any reasonable > graphics library, the functionality is required by any SVG decoder and > many display devices have device-level alpha composition support > (possibly broken) which can do the blit independently of the main CPU. > > Manipulating the information in the PNG image on a per-pixel basis > requires, at minimum, setting up non-default parameters for the blit and > may, in fact, require getting at the individual pixels and doing it > yourself. In other words what you are saying is to make anIM specifications OS dependant to accomodate existing OS those have some poor implemented alphablend() functions. As I already wrote in previous e-mail, a lot of those OS dependant alphablend() functions require pre-multiplied source and they will simply not work anyway with the tiles in IDAT to compose the buffer. _________ / Adeluc / ¯¯¯¯¯¯¯¯¯

Re: [png-mng-misc] anIM Tile_alpha From: John Bowler <jbowler@ac...> - 2007-05-01 15:54 From: Glenn Randers-Pehrson >Addition to the proposal: Well, as of this moment I'll vote against anIM, after the two week discussion period is up. Like I said some time before about APNG, if we're going to invent a new animation format with extra capabilities this is not the way I'd want to see it done. As a minimum I would also add a 'clear' operation to set a rectangular region in the frame to RGBA(0,0,0,0) and 'save' and 'restore' operations. These can simply be added by changing each tile element to be variable length and adding an 'opcode'. Current values I can see to be a complete and more powerful superset of PiG, anIM and APNG are: 1) blit(rectangle, dest) - the current operation 2) display(delay) - marks the end of the frame 3) save - saves the current frame buffer in current state 4) restore - restores same 5) clear(rectangle colour) - sets rectangle to colour 6) loop(frame, times) 'loop' replaces the overall loop count, it causes the animation to loop back to the given frame the given number of times. These operations are all really simple to implement - save and restore just require a single copy of the current frame, clear is easy. *All* these things are easy - so why not do them? Still, I think I've just re-invented MNG in a new format, so I'd probably vote against this too. John Bowler <jbowler@ac...>

Re: [png-mng-misc] aNIM Encoder - Decoder From: John Bowler <jbowler@ac...> - 2007-05-01 16:05 From: Adeluc >In other words what you are saying is to make anIM specifications OS=20 >dependant to accomodate existing OS those have some poor implemented=20 >alphablend() functions. Eh, that is what *you* (Adeluc) are saying. You are saying (incorrectly BTW as you are using Windows) that, because your OS doesn't support PNG properly (it does) by handling the alpha correctly using the native support *you* have to write AlphaBlend. Therefore you are prepared to add functionality to anIM which will require everyone to write AlphaBlend. >As I already wrote in previous e-mail, a lot of those OS dependant=20 >alphablend() functions require pre-multiplied source and they will simply=20 >not work anyway with the tiles in IDAT to compose the buffer. Eh... if you have an operating system function which reads a PNG file and produces a native object (e.g. an in memory bitmap) which then can't be used in the operating system alpha blend you have a broken operating system. Using broken systems as justification for doing things which are easy if you have are writing the pixel level bit twiddlinig is simply wrong. I seem to remember having this argument before about the buffers in MNG, that's why we ended up with 'abstract' and 'concrete' buffers - the concrete ones support bit twiddling, but can't necessarily be implemented using native OS facilities. John Bowler <jbowler@ac...>

Re: [png-mng-misc] anIM Tile_alpha From: Adeluc <png@ad...> - 2007-05-01 22:34 > Like I said some time before about APNG, if we're going to invent a new > animation format with extra capabilities this is not the way I'd want to > see it done. As a minimum I would also add a 'clear' operation to set a > rectangular region in the frame to RGBA(0,0,0,0) and 'save' and > 'restore' operations. The beauty of actual anIM specifications is that it is extremely simple. It is so simple that we are creating our animation samples by using text script. Each frame are independant to each other removing all the complexity of creation. The add of the tile_alpha simply add more creative flexibility and make anIM more attractive for massive adoption without adding any extra decoding and understanding. The add of the tile_alpha was simply a wise choice to do since the current anIM implementation must support alpha channel blending anyway. > These can simply be added by changing each tile element to be variable > length and adding an 'opcode'. Current values I can see to be a > complete and more powerful superset of PiG, anIM and APNG are: > > 1) blit(rectangle, dest) - the current operation > 2) display(delay) - marks the end of the frame > 3) save - saves the current frame buffer in current state > 4) restore - restores same > 5) clear(rectangle colour) - sets rectangle to colour > 6) loop(frame, times) > > 'loop' replaces the overall loop count, it causes the animation to loop > back to the given frame the given number of times. What you are suggesting is, compared to the actual simple anIM specifications, a nightmare. I am already able to do everything you suggested above with only the cost of few extra tiles those compress very well. In the other hands, if we remove the tile_alpha, to do what the tile_alpha can accomplish we need to add more data in IDAT and those do not compress well and are significant in size. > These operations are all really simple to implement - save and restore > just require a single copy of the current frame, clear is easy. > > *All* these things are easy - so why not do them? Because the goal was to make anIM to be extremely simple to support and attractive? _________ / Adeluc / ¯¯¯¯¯¯¯¯¯

Re: [png-mng-misc] anIM Tile_alpha From: John Bowler <jbowler@ac...> - 2007-05-01 22:42 From: Adeluc >Because the goal was to make anIM to be extremely simple to support and >attractive? Well, it was, now you've added a nightmarish requirement for every decoder to be able to perform manipulations on the RGBA values of individual pixels in the tiles. =20 This is no longer KISS. John Bowler <jbowler@ac...>

Re: [png-mng-misc] anIM Tile_alpha From: Glenn Randers-Pehrson <glennrp@co...> - 2007-05-02 13:53 At 08:50 AM 5/1/2007 -0700, John Bowler wrote: >6) loop(frame, times) > >'loop' replaces the overall loop count, it causes the animation to loop >back to the given frame the given number of times. Can loops be nested? Glenn

Re: [png-mng-misc] anIM Tile_alpha From: John Bowler <jbowler@ac...> - 2007-05-02 16:41 From: Glenn Randers-Pehrson >Can loops be nested? Yes. I would disallow arbitrary 'goto'. John Bowler <jbowler@ac...>

Re: [png-mng-misc] anIM Tile_alpha From: Glenn Randers-Pehrson <glennrp@co...> - 2007-05-02 20:30 Your proposal still isn't a MNG replacement without some way of changing the amount of offset each time around the loop. Glenn

Re: [png-mng-misc] anIM Tile_alpha From: John Bowler <jbowler@ac...> - 2007-05-02 21:28 From: Glenn Randers-Pehrson >Your proposal still isn't a MNG replacement without some way >of changing the amount of offset each time around the loop. Indeed, and the save/restore interacts in potentially bad ways with the loop, and there is no suppport for delta PNG. I don't see any value in reconstructing the MNG design, it took a long time and, so far as I am concerned, has no major deficiencies. I don't see any value in constructing anything which is not minimal - either the minimal enhancement to GIF to meet stated requirements (PiG) or a minimal compact animation format with no extra oh-so-nice features (MPNG). John Bowler <jbowler@ac...>

Re: [png-mng-misc] anIM Tile_alpha From: Glenn Randers-Pehrson <glennrp@co...> - 2007-05-02 21:57 At 02:25 PM 5/2/2007 -0700, John Bowler wrote: >From: Glenn Randers-Pehrson >>Your proposal still isn't a MNG replacement without some way >>of changing the amount of offset each time around the loop. > >Indeed, and the save/restore interacts in potentially bad ways with the >loop, and there is no suppport for delta PNG. I don't see any value in >reconstructing the MNG design, it took a long time and, so far as I am >concerned, has no major deficiencies. I don't see any value in >constructing anything which is not minimal - either the minimal >enhancement to GIF to meet stated requirements (PiG) or a minimal >compact animation format with no extra oh-so-nice features (MPNG). I agree. I didn't appreciate the fact that anIM/MPNG as presently proposed (20070426) can be realized entirely with commonly available blit-type operations, until your recent explanation. It's not a stated goal, but maybe should be. Therefore, unless someone can come up with a channel-modification method that can be done with a blit-type operation, we should forget the alpha-multiplier idea, no matter how "nice-to-have" it is. My "deck" demo shows that the effect can be crudely achieved without it. Gerard, maybe your chart should have a line "realizable with BLIT". Glenn

Re: [png-mng-misc] anIM Tile_alpha From: Adeluc <png@ad...> - 2007-05-02 23:49 > I didn't appreciate the fact that anIM/MPNG as presently proposed > (20070426) > can be realized entirely with commonly available blit-type operations, > until your recent explanation. > > It's not a stated goal, but maybe should be. Therefore, unless > someone can come up with a channel-modification method that can be > done with a blit-type operation, we should forget the alpha-multiplier > idea, no matter how "nice-to-have" it is. My "deck" demo shows that > the effect can be crudely achieved without it. > > Gerard, maybe your chart should have a line "realizable with BLIT". Me also I did not like the fact that the tile_alpha cannot be applied with a blit operation. However, until you can point me a function that do alpha blend with a not alpha pre-multiplied tile image into the composed frame buffer, we will need to use a custom function anyway and then the support of the tile_alpha will add no overhead. A possible solution I found is to use a black rectangle of 1x1 since the AlphaBlend() function can stretch it: You set the black rectangle with an alpha channel set to (255 - tile_alpha), then alpha blend it over a copy of the tile image. You will get the correct RGB but you will need to fix the resulting alpha channel by substracting (255 - tile_alpha). After the RGBA( 0, 0, 0, (255 - tile_alpha) ) rectangle blended over the tile: Tile.Red = 0 + Tile.Red * (255 - (255 - tile_alpha)) / 255; Tile.Green = 0 + Tile.Green * (255 - (255 - tile_alpha)) / 255; Tile.Blue = 0 + Tile.Blue * (255 - (255 - tile_alpha)) / 255; Tile.Alpha = (255 - tile_alpha) + Tile.Alpha * (255 - (255 - tile_alpha)) / 255; After substracting (255 - tile_alpha) from resulting alpha channel: Tile.Red = Tile.Red * tile_alpha / 255; Tile.Green = Tile.Green * tile_alpha / 255; Tile.Blue = Tile.Blue * tile_alpha / 255; Tile.Alpha = Tile.Alpha * tile_alpha / 255; >From here the tile is now pre-multiplied so you can use typical AlphaBlend() function to place the tile over the composed frame buffer. Dst.Red = Tile.Red + (1 - Tile.Alpha) * Dst.Red Dst.Green = Tile.Green + (1 - Tile.Alpha) * Dst.Green Dst.Blue = Tile.Blue + (1 - Tile.Alpha) * Dst.Blue Dst.Alpha = Tile.Alpha + (1 - Tile.Alpha) * Dst.Alpha A possible optimization in Windows is to use DirectX and program a pixelshader to do all those calculations at hardware level. But I do not have the knowledges for that. Resume: Copy the tile into a temporary buffer. Set the black pixel rectangle alpha with (255 - tile_alpha). AlphaBlend() the black pixel rectangle over the temporary buffer. Fix the alpha channel of the temporary buffer by substracting (255 - tile_alpha). AlphaBlend() the temporary buffer over the frame buffer. _________ / Adeluc / ¯¯¯¯¯¯¯¯¯

Re: [png-mng-misc] anIM Tile_alpha From: John Bowler <jbowler@ac...> - 2007-05-03 00:16 From: Glenn Randers-Pehrson >Gerard, maybe your chart should have a line "realizable with BLIT". Perhaps someone knowledgeable can say what the current Linux graphics libraries can do. Here is a list of things which, while not absolute requirements for any of the current proposals, are things which MNG, anIM and APNG can use directly (plus [5] which none of the base proposals would use). I assume Mac has at least the Linux capabilities these days: 1) Create a surface (a writeable bitmap) with an alpha channel. Windows: supported in GDI+, not supported in any useful way in GDI. Linux etc: I don't know, wasn't possible last time I looked but is pretty much a requirement for any graphics IMO. 2) Render directly from PNG or JPEG data (i.e. blit from a PNG or JPEG without prior convertion to another format via user code). Windows: supported in GDI+, theoretically possible in GDI but no real support. Linux: Imlib supports this, I'm sure other libraries do. 3) Support for rendering bitmaps with an alpha channel (read support). Windows: fully supported in GDI+ (I believe one of the 'xxxHighQuality' interpolation modes has to be chosen to get linearisation of the components - I think the online documentation is wrong!), broken in GDI (non-linear) Linux: must be supported for SVG... 4) Support for rendering part of the source image. Windows: supported everywhere Linux: I think Imlib requires a 'crop_and_clone_image' call, fully supported in the base (X11) APIs and should be fully supported for SVG. 5) Support for ICC, cHRM, sRGB and gAMA color correction. Windows: fully supported Linux: ICC support is in an optional library which, IRC, requires unpacking of the bitmap first. Should be fully supported for SVG. 6) Support for arbitrary colour channel modification [5x5 matrix] Windows: GDI: no. GDI+: a matrix is supported but I believe it does not linearise the colours, so it is effectively broken (I might be wrong). Linux: Might be in SVG - I can no longer remember. GDI+ is just a layer on top of GDI which removes the need to deal with all the device dependence in GDI, so it works anywhere where GDI works. I don't consider APIs which only work on certain output devices to be a supported part of an Operating System, at least not in any useful sense. SVG is effectively an API equivalent to GDI+ or PostScript; in principle an SVG stream can be rendered to any output device. John Bowler <jbowler@ac...>

Re: [png-mng-misc] anIM Tile_alpha From: John Bowler <jbowler@ac...> - 2007-05-03 00:26 From: Adeluc >However, until you can point me a function that do alpha >blend with a not alpha pre-multiplied tile image into the composed frame >buffer SVG - you need to set up a clipping mask (rectangle) to define the source tile, but a PNG image is a valid SVG bitmap. GDI+ - Graphics::DrawImage, set InterpolationModeHighQualityBilinear on the Graphics and construct the Image using Bitmap::Bitmap(Istream*, true/*useICM*/) where the Istream contains the data of a PNG. The Graphics may be a bitmap with an alpha channel - just select the relevant pixel format (or you could use PNG I think) or you can just render to the device. I think that covers all the operating systems, doesn't it? John Bowler <jbowler@ac...>

Re: [png-mng-misc] anIM Tile_alpha From: Adeluc <png@ad...> - 2007-05-03 00:55 OOps! I was wrong in previous e-mail when I wrote: >From here the tile is now pre-multiplied so you can use typical >AlphaBlend() function to place the tile over the composed frame buffer. The tile image is still not pre-multiplied and AlphaBlend() cannot be used to blend the temporary tile buffer over the frame buffer. That brings me again to my first point. Find me a blending function that works with a not alpha pre-multiplied tile image and I will be happy to forget the extra oh-so-nice feature tile_alpha. _________ / Adeluc / ¯¯¯¯¯¯¯¯¯

Re: [png-mng-misc] anIM Tile_alpha From: Adeluc <png@ad...> - 2007-05-03 01:01 OOps! I was wrong in previous e-mail when I wrote: >From here the tile is now pre-multiplied so you can use typical >AlphaBlend() function to place the tile over the composed frame buffer. The tile image is still not pre-multiplied and AlphaBlend() cannot be used to blend the temporary tile buffer over the frame buffer. That brings me again to my first point. Find me a blending function that works with a not alpha pre-multiplied tile image and I will be happy to forget the extra oh-so-nice feature tile_alpha. _________ / Adeluc / ¯¯¯¯¯¯¯¯¯

Re: [png-mng-misc] anIM Tile_alpha From: Adeluc <png@ad...> - 2007-05-03 01:45 >>However, until you can point me a function that do alpha >>blend with a not alpha pre-multiplied tile image into the composed > frame >>buffer > > SVG - you need to set up a clipping mask (rectangle) to define the > source tile, but a PNG image is a valid SVG bitmap. > > GDI+ - Graphics::DrawImage, set InterpolationModeHighQualityBilinear on > the Graphics and construct the Image using Bitmap::Bitmap(Istream*, > true/*useICM*/) where the Istream contains the data of a PNG. The > Graphics may be a bitmap with an alpha channel - just select the > relevant pixel format (or you could use PNG I think) or you can just > render to the device. > > I think that covers all the operating systems, doesn't it? > > John Bowler <jbowler@ac...> Thanks for the clues. I have no idea how to configure the Istream *. I am a little tired tonigh but I will make some tests tomorrow to apply tile_alpha in one shot. (See Using a Color Matrix to Set Alpha Values in Images in GDI+) // Create a Bitmap object and load it with the texture image. Bitmap bitmap(L"Texture1.jpg"); Pen pen(Color(255, 0, 0, 0), 25); // Initialize the color matrix. // Notice the value 0.8 in row 4, column 4. ColorMatrix colorMatrix = {1.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 1.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 1.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 0.8f, 0.0f, 0.0f, 0.0f, 0.0f, 0.0f, 1.0f}; // Create an ImageAttributes object and set its color matrix. ImageAttributes imageAtt; imageAtt.SetColorMatrix(&colorMatrix, ColorMatrixFlagsDefault, ColorAdjustTypeBitmap); // First draw a wide black line. graphics.DrawLine(&pen, Point(10, 35), Point(200, 35)); // Now draw the semitransparent bitmap image. INT iWidth = bitmap.GetWidth(); INT iHeight = bitmap.GetHeight(); graphics.DrawImage( &bitmap, Rect(30, 0, iWidth, iHeight), // Destination rectangle 0, // Source rectangle X 0, // Source rectangle Y iWidth, // Source rectangle width iHeight, // Source rectangle height UnitPixel, &imageAtt); _________ / Adeluc / ¯¯¯¯¯¯¯¯¯

Re: [png-mng-misc] anIM Tile_alpha From: John Bowler <jbowler@ac...> - 2007-05-03 03:25 From:Adeluc >Thanks for the clues. I have no idea how to configure the Istream *. There should be a constructor for an IStream which takes an array of bytes - pass it the whole anIM PNG (my wonderful email editor corrects my intentional capitalisation of the "S"; look for IStream::IStream methods). Easier but less general (I missed this first time round): Bitmap( const WCHAR *filename, BOOL useIcm ); The data (the PNG image) has to be in a file. >(See Using a Color Matrix to Set Alpha Values in Images in GDI+) Yes, and the code you quote *should* compose the alpha into the image as it is drawn, but I'm betting that it does the calculation in the encoded colour space (i.e. without linearising it first). I might be wrong; the implementors were fully aware of how bad non-linear calculations are (at the time both Alvy Ray Smith and Jim Blinn worked for Microsoft). However I know that the base bicubic and bilinear scaling operations work in non-linear space (and are therefore incorrect) - I'm hoping that my memory is correct and that, despite the documentation, the "HighQuality" variants work in linear space (and, I hope, compose the alpha in linear space.) In SVG the approach is more clear for alpha composition (and less for image resampling, but that's a different battle). Selecting 'color-interpolation: linearRGB' forces the correct alpha composition. color-rendering should always be optimizeQuality - the speed option overrides the interpolation option. It's somewhat obfuscated in SVG how to render an image, I think it is via the feImage stuff, but I'm not sure, I might be missing something. John Bowler <jbowler@ac...>

Re: [png-mng-misc] anIM Tile_alpha From: Greg Roelofs <newt@po...> - 2007-05-04 01:21 >> I guess that should be >> >> combined_pixel_alpha(x,y) = pixel_alpha(x,y) * (tile_alpha / 255.0) >> >> so the multiplier doesn't come out zero unexpectedly. > To speed up things I always try to avoid floats when it is possible. > So to avoid rounding to zero perform all the multiplications and keep the > division for the end. > combined_pixel_alpha(x,y) = (((pixel_alpha(x,y) * tile_alpha) + 127) / 255); Or don't divide: numer = ((pixel_alpha(x,y) * tile_alpha) + 127); combined_pixel_alpha(x,y) = ((numer+1) + ((numer+1) >> 8)) >> 8; (which obviously can be simplified). Had the numerator already been calculated elsewhere, and if it were guaranteed not to exceed 65534, then the following approximation is exact and may save an instruction, depending on whether numer needs to be used again downstream: combined_pixel_alpha(x,y) = ((numer+1) + ( numer >> 8)) >> 8; It fails for numer == 65535, but that value never occurs for alpha calculations; the expression for numer above (including rounding) never exceeds 65152. The MMX equivalent is left as an exercise for the reader. ;-) Greg P.S. All of this will be familiar to old-timers, of course.

Re: [png-mng-misc] anIM Tile_alpha From: Glenn Randers-Pehrson <glennrp@co...> - 2007-05-04 01:42 At 06:21 PM 5/3/2007 -0700, Greg Roelofs wrote: > >The MMX equivalent is left as an exercise for the reader. ;-) A block method is left as an exercise... Glenn

Re: [png-mng-misc] anIM Tile_alpha From: Adeluc <png@ad...> - 2007-05-04 08:16 I just released "PNG anIM chunk Encoder / Decoder" application version 1.4.0 without anything else to just let you see the "Red Cyan Anaglyph Vortex.png" stereoscopic animation showing the use of the tile constant alpha variable. You need Red Cyan Anaglyph glasses in order to really enjoy the deep. (1024MB of RAM is required if you want to store frames in memory.) I still need to optimize few functions for speed and use Windows GDI+ Viewer: http://decotechsoftware.com/png_anim/pnganimencdec_v1_4_0.zip Animation: http://decotechsoftware.com/png_anim/red_cyan_anaglyph_vortex.zip _________ / Adeluc / ¯¯¯¯¯¯¯¯¯

Re: [png-mng-misc] anIM Tile_alpha From: Glenn Randers-Pehrson <glennrp@co...> - 2007-05-04 19:42 At 08:21 PM 5/2/2007 -0700, John Bowler wrote: Are we done beating this tile_alpha horse? Should we go ahead and vote on anIM without it? Glenn

Re: [png-mng-misc] anIM Tile_alpha From: Gerard Juyn <gjuyn@xs...> - 2007-05-04 20:26 > Are we done beating this tile_alpha horse? Should we go ahead and > vote on anIM without it? I'm happy to vote on it without tile_alpha. Adeluc, if you want this badly for your own apps, you can always create a anIA chunk which has as many alpha-values as there are tiles in the anIM chunk.... or less if the last are all 255.... anIA must appear before IDAT, but can appear before or after anIM. Gerard

Re: [png-mng-misc] anIM Tile_alpha From: Glenn Randers-Pehrson <glennrp@co...> - 2007-05-04 20:54 At 10:21 PM 5/4/2007 +0200, Gerard wrote: >Adeluc, if you want this badly for your own apps, you can always >create a anIA chunk which has as many alpha-values as there are >tiles in the anIM chunk.... or less if the last are all 255.... anIA must >appear before IDAT, but can appear before or after anIM. That looks like a pretty good idea to me. Glenn

Re: [png-mng-misc] anIM Tile_alpha From: Adeluc <png@ad...> - 2007-05-04 22:39 >> Are we done beating this tile_alpha horse? Should we go ahead and >> vote on anIM without it? > > I'm happy to vote on it without tile_alpha. > > Adeluc, if you want this badly for your own apps, you can always > create a anIA chunk which has as many alpha-values as there are > tiles in the anIM chunk.... or less if the last are all 255.... anIA must > appear before IDAT, but can appear before or after anIM. I do not need tile_alpha personnally. I suggested it only because it was a great feature offering many possibilities. Even if I did not understand exactly why you rejected it, I must admit that John the guru usually know what he is talking about. I wanted to test Windows GDI+ this weekend but you started the vote period. Even if I would find a solution for tile_alpha you will probably continue to complain about other OS not supporting it natively. I am just sad that the tile_alpha is dropped from the proposal. IMO it was a seller feature to motive people to adopt PNG aNIM instead of other formats. Now I only hope it will not become another unused format among others. _________ / Adeluc / ¯¯¯¯¯¯¯¯¯

Re: [png-mng-misc] anIM Tile_alpha From: Adeluc <png@ad...> - 2007-05-04 22:44 > Are we done beating this tile_alpha horse? Should we go ahead and > vote on anIM without it? > > Glenn I was not ready but I am also tired to be alone trying to find a solution for the tile_alpha. It is a little bit frustrating seeing you guys doing superb twists to fit complicated things in PNG format by violating all the specifications but it is too hard to dig to find a solution to support the tile_alpha and all the possibilities it brings. You missed the opportunity to create a great simple PNG anIM format. It will simply be a good simple format. Nothing to appeal people to adopt it more than another format available on planet WEB.. _________ / Adeluc / ¯¯¯¯¯¯¯¯¯

Re: [png-mng-misc] anIM Tile_alpha From: Glenn Randers-Pehrson <glennrp@co...> - 2007-05-04 23:01 At 06:45 PM 5/4/2007 -0400, Adeluc wrote: >You missed the opportunity to create a great simple PNG anIM format. We can continue to discuss Gerard's "anIA" suggestion. The opportunity isn't entirely lost. Maybe it will evolve into "anOP" and incorporate some of John's other ideas as well. Glenn

[png-mng-misc] Borrowing anIM for MNG From: Gerard Juyn <gjuyn@xs...> - 2007-05-04 23:31 > At 06:45 PM 5/4/2007 -0400, Adeluc wrote: > >You missed the opportunity to create a great simple PNG anIM format. > > We can continue to discuss Gerard's "anIA" suggestion. The opportunity > isn't entirely lost. Maybe it will evolve into "anOP" and incorporate > some of John's other ideas as well. Yep. And I'd like an anIM-like chunk for MNG as well. Conveying a lot of operations in a single chunk has many advantages and is very easy to implement within the MNG framework. It just translates to a bunch of FRAM/MOVE/CLIP/SHOW chunks. It should be a critical chunk; perhaps PLST for "playlist". It contains a 2-byte object_id to identify the stored object to "play" or object_id=0, which indicates the next embedded image is used to "play". However that still precludes mixing JPEG- and PNG-encoded objects to be mixed. So perhaps better to have an object_id per tile (either all zero to play the next embedded image, or all not-zero to play stored objects). The header-fields from anIM (except compression_method) are not needed. num_plays can be done through TERM or a LOOP/ENDL pair. The frame dimension and ticks are in MHDR. So it would just contain the tiles in compressed format according to the compression_method (0=deflate). The reason I'm thinking along these lines, is that my MNG-optimizer uses a filmstrip mostly. But the frames have to be similar in size to allow the necessary FRAM/MOVE/CLIP/SHOW chunks inside a LOOP/ENDL. If the frames are irregular in size (which is very likely for maximum optimization and thus smallest IDAT) the MNG needs to write out all the FRAM/MOVE/CLIP/SHOW chunks for each frame to display which becomes very costly. If this info is conveyed in a single compressed playlist MNG optimization reaches another level. Gerard