Re: APNG MIME type and extension
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 | Next > |
 |
Re: PNG montage images
by Adeluc
::
Rate this Message:
> The main problem with this, and with the original suggestion, is that the
> fallback image is too big. If you have an animation rectangle of 240x60 pixels with 100 frames with no optimization, the encoder can create a big image of 240x6000 or 480x3000 or 720x2040 or 960x1500 or 1200x1200..... But with frame composition, you can re-use multiple sprites and move them, make a block of text scrolling up, moving the complete background (larger than the animation rectangle) of animation and many more effect with absolutely no extra image data cost except for the fCTr chunks. So a 240x60 pixels with 100 frames will not necessary be a 1200x1200 image unless each frame are completely different and full size. In this last case I really do not know why to use APNG instead of mpeg. Ah yeah...for the alpha channel! _________ / Adeluc / ¯¯¯¯¯¯¯¯¯ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG montage images
by glennrp-2
::
Rate this Message:
At 09:59 PM 3/16/2007 -0400, Adeluc wrote:
>> The main problem with this, and with the original suggestion, is that the >> fallback image is too big. > >If you have an animation rectangle of 240x60 pixels with 100 frames with no >optimization, the encoder can create a big image of 240x6000 or 480x3000 or >720x2040 or 960x1500 or 1200x1200..... > >But with frame composition, you can re-use multiple sprites and move them, >make a block of text scrolling up, moving the complete background (larger >than the animation rectangle) of animation and many more effect with >absolutely no extra image data cost except for the fCTr chunks. > >So a 240x60 pixels with 100 frames will not necessary be a 1200x1200 image >unless each frame are completely different and full size. In this last case Right, a typical advertising banner might be 260x60 with a 240x60 background and two 20x20 sprites and 20x20 of wasted space. And the fallback image wouldn't look too bad; it would just show the two sprites sitting idle along the right side. Compression would be about 100:1 times the normal ratio in compressing the background. Offset somewhat by the 2800 bytes of uncompressed frame control data. Should we compress that? Nah. This argument applies to both the multiple-montage APNG and the adeluc-bowler mPNG. Glenn ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
|
|
|
APNG, mPNG, and pngcrush
by glennrp-2
::
Rate this Message:
I just gave a bit of thought to what it would take to make pngcrush,
which is a PNG editor, work with APNG and mPNG proposals. For APNG, I'd have to write code to collect the fDAt chunks, remove the sequence numbers and concatenate the data into zlib datastreams, then handle those datastreams in the same manner as pngcrush now handles the IDAT datastreams. That would require a modified libpng, because pngcrush uses libpng to convert the IDATs into pixel scanlines. Bottom line: Probably two or three days' work. Whether APNG uses single images or multiple montages makes no difference to pngcrush. For mPNG, I'd have to do nothing at all. The current pngcrush will handle the main image as it usually does, and it will preserve the mPNG chunk as an unknown chunk. Since it is copy-unsafe, I'd have to override the automatic discarding, but pngcrush already provides for preserving copy-unsafe chunks under user control. Bottom line: No work. Also, it would be trivial to modify pngcrush to inject an mPNG chunk into a regular PNG that happens to contain a montage. Conclusion: obviously mPNG is less complex from the supporting tools viewpoint. Glenn ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: APNG, mPNG, and pngcrush
by glennrp-2
::
Rate this Message:
At 11:28 PM 3/16/2007 -0400, I wrote:
>That would require a modified libpng, which exists thanks to Andrew Smith; the patch for libpng is on bugzilla. But even with that, it would take 2-3 days to make pngcrush accommodate APNG. Also note that pngcrush as it exists now can crush an APNG but it would only recompress the IDATs and ignore the fDAts. I don't consider that to be successfully pngcrushing the file, though. Glenn ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
mPNG issues
by glennrp-2
::
Rate this Message:
At 03:34 PM 3/16/2007 -0700, John Bowler wrote:
> > byte > 0 x (unsigned int) left of sub-frame pixels > 4 y (unsigned int) top of sub-frame pixels > 8 width (unsigned int) width of sub-frame pixels > 12 height (unsigned int) height of sub-frame pixels > 16 x_offset (unsigned int) left of sub-frame destination > 20 y_offset (unsigned int) right of sub-frame destination > 24 delay_num (unsigned short) Frame delay numerator > 26 delay_den (unsigned short) Frame delay denominator x_offset and y_offset should be signed. We could consider making x and y signed as well, but that's not as important and I don't recommend it. Consider any sprite that comes in from the side of the frame or exits, or anything that scrolls. You want to start from off the frame and end up off the frame. When you are off the top or left, you need negative offset values. Glenn ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: mPNG issues
by glennrp-2
::
Rate this Message:
At 11:58 PM 3/16/2007 -0400, Glenn Randers-Pehrson wrote:
>At 03:34 PM 3/16/2007 -0700, John Bowler wrote: >> >> byte >> 0 x (unsigned int) left of sub-frame pixels >> 4 y (unsigned int) top of sub-frame pixels >> 8 width (unsigned int) width of sub-frame pixels >> 12 height (unsigned int) height of sub-frame pixels >> 16 x_offset (unsigned int) left of sub-frame destination >> 20 y_offset (unsigned int) right of sub-frame destination >> 24 delay_num (unsigned short) Frame delay numerator >> 26 delay_den (unsigned short) Frame delay denominator This frame data list should be optionally compressed. It's potentially fairly long, maybe 600 frames to move a sprite from one side to the other and back. The 4-byte numbers are typically small, only occupying the rightmost 1 or 2 bytes of each field, so there are lots of 0's. Typically most of the numbers will not be varying. So those 600*28 bytes will probably compress down to very little. We should do this the same as in iTXt, using a 1-byte compression flag, 0 meaning uncompressed and 1 meaning compressed and a compression method flag, 0 meaning "deflate". The "total_width" and "total_height" parameters should be ahead of these and the compressed datastream, so simple applications can find them without having to "inflate" the chunk data. byte 0 total_width (unsigned int) Width of frames 4 total_height (unsigned int) Height of frames 8 compression flag (byte) 0: uncompressed; 1: compressed 9 compression method (byte) 0: deflate 10 sub_frame 28 bytes First sub-frame I realize this isn't quite KISS but I think forcing people to leave the frame table uncompressed will annoy them. I know it would annoy me. Glenn ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: mPNG issues
by Adeluc
::
Rate this Message:
> At 03:34 PM 3/16/2007 -0700, John Bowler wrote:
>> >> byte >> 0 x (unsigned int) left of sub-frame pixels >> 4 y (unsigned int) top of sub-frame pixels >> 8 width (unsigned int) width of sub-frame pixels >> 12 height (unsigned int) height of sub-frame pixels >> 16 x_offset (unsigned int) left of sub-frame destination >> 20 y_offset (unsigned int) right of sub-frame destination >> 24 delay_num (unsigned short) Frame delay numerator >> 26 delay_den (unsigned short) Frame delay denominator > > x_offset and y_offset should be signed. We could consider making > x and y signed as well, but that's not as important and I don't > recommend it. Consider any sprite that comes in from the side of the > frame or exits, or anything that scrolls. You want to start from off > the frame and end up off the frame. When you are off the top or left, > you need negative offset values. While creating/modifying an animation it is easier to indicate negative x_offset or y_offset but you can do the same by ajusting x, y, width and height appropriately and keeping the offsets unsigned. Personnaly I prefer signed offsets so editor programs will be more flexible to edit animation like setting the position of a sprite from frame to frame. It is also very easy to program the decoder to recalculate the x, y, width and height to only draw the visible portion of a sprite. _________ / Adeluc / ¯¯¯¯¯¯¯¯¯ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG montage images
by John Bowler
::
Rate this Message:
From: Glenn Randers-Pehrson
>Offset somewhat by the 2800 bytes of uncompressed >frame control data. Should we compress that? Nah. mPNZ, in which the sub-frame information is compressed using zlib :-) The overhead is actually quite a lot more that you estimate - 28 bytes to put the background up, then 28 for each sprite. On the other hand neither AGIF nor APNG can do multiple sprites per frame, so the sprites have to be combined. I'm not sure; 56 bytes (1 sprite) per frame is a lot. In APNG a frame is 37 bytes. As you say, that is a lot too. Still, reducing either is possible at the cost of technial complexity and, in mPNG, simple zlib compression may be sufficient. John Bowler <jbowler@...> ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG montage images
by John Bowler
::
Rate this Message:
From: Glenn Randers-Pehrson
>From: John Bowler >> Each frame contents >> before any sub-frames are added are transparent throughout (alpha 0). > > and RGB either (0,0,0) or, if bKGD is present, the color specified > in the bKGD chunk. If the decoder performs alpha composition when the frame is displayed it doesn't matter (because multiplying any component by an alpha of 0 gives 0). If it does not the the frame could be composed entirely without alpha and it should be initialised to the background, as specified in the PNG spec (the background need not come from the bKGD chunk if the decoder knows a better value.) I'm wary of getting into the post-multiplied/pre-multiplied debate here. So far as I can see composition to an intermediate post-multiplied surface is poorly defined (very poorly) when both source and destination have an alpha of 0, because it seems impossible to deduce a correct RGB triple for the destination, unless both source and destination have the same value. Anyway, all the proposals have this problem (and it is a real problem.) >> 3 Restore to previous. The region under the AGIF sub-image will be >> restored. Since each sub-image is a complete frame this means that >> the entire background of this mPNG frame (possibly built from >> several sub-images) is to be reused in the next mPNG frame. > >This gets a bit messy if different sub-frames of a frame have different >dispose flags, and if the GIF sub-images (and therefore the mPNG subimages) >overlap. I think the algorithm is fairly straight forward - actually I think it's the one I gave before but correctly taking into account the AGIF sub-image sizes. The result (the mPNG) may be larger than the AGIF in extreme cases, but I would be very surprised if there were a significant number of those in practice. The fact that mPNG doesn't require a 'save' operation is one of the things which makes it simpler than both AGIF and APNG. Introducing a 'make this the background' sub-frame operation, which causes each frame to be initialised to that background, avoids the need to repeat the background on each frame without requiring a 'save'. Still I think this complexity would be unnecessary in practice. John Bowler <jbowler@...> ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG montage images
by glennrp-2
::
Rate this Message:
Just so I have this right: MPNG does not have any "dispose" operations per se. All the stuff you wrote, using up maybe half of your words, is directed to authors telling them how to write an MPNG that makes the same sequence of visible frames as an AGIF with a properly-operating dispose would. Glenn ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG montage images
by glennrp-2
::
Rate this Message:
At 11:06 PM 3/16/2007 -0700, John Bowler wrote:
>The overhead is actually quite a lot more that you estimate - >28 bytes to put the background up, then 28 for each sprite. >On the other hand neither AGIF nor APNG can do multiple sprites >per frame, so the sprites have to be combined. > >I'm not sure; 56 bytes (1 sprite) per frame is a lot. In >APNG a frame is 37 bytes. As you say, that is a lot too. In APNG a frame is 37 bytes *plus* image data. In MPNG it is only the 56 bytes, after the first time the background and sprite have been shown. APNG with montages could achieve the "sprite" effect but that has already been rejected by the APNG proponents as too complex. Glenn ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG montage images
by glennrp-2
::
Rate this Message:
At 11:43 PM 3/16/2007 -0700, John Bowler wrote:
>So far as I can see composition to an intermediate post-multiplied surface >is poorly defined (very poorly) when both source and destination have an >alpha of 0, because it seems impossible to deduce a correct RGB triple for >the destination, unless both source and destination have the same value. If there isn't a school solution to that situation we can define the proper behavior. I think it would be to simply leave the destination triple as is and ignore the source triple. Applications will probably do that naturally, if they are special-casing a source alpha of 0. Glenn ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG montage images
by Adeluc
::
Rate this Message:
>4.1 Chunk structure
> > The mPNG chunk contains 8 bytes giving the width and height of the > frames > in the sub-images followed by one or MORE 28 byte sub-frame > descriptions: > > byte > 0 total_width (unsigned int) Width of frames > 4 total_height (unsigned int) Height of frames > 8 compression flag (byte) 0: uncompressed; 1: compressed > 9 compression method (byte) 0: deflate > 10 sub_frame 28 bytes First sub-frame You have forgotten the num_iterations (unsigned int) --> Number of times to loop this mPNG. 0 indicates infinite looping. We may also specify that total_width needs to follow sTER rules when sTER is present. That brings another another condition for mPNG + sTER to respect the sTER specs. For stereo animation, the big image width (containing all sub-images) needs to follow sTER rules even if this width is not use by sTER. That may result in useless padding pixels but in the case total_width needs some padding pixels, those do not need to be draw so less image data is required. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG montage images
by John Bowler
::
Rate this Message:
From: Adeluc
>You have forgotten the num_iterations (unsigned int) --> Number of times to >loop this mPNG. 0 indicates infinite looping. Ah, you are correct. I thought an infinite delay was sufficient but that only allows for 1 or infinite iterations. I think also the stuff about sub-frames at the end compositing back onto the beginning is needless complexity, so change: - The first sub-frame with delay_num greater than 0 marks the end of the - frame. The decoder should display the frame after handling this - sub-frame and leave the frame displayed for delay_num/delay_den seconds. - If delay_den is 0 when delay_num is greater than 0 the decoder should - not advance to the next frame automatically. After the last sub-frame - the decoder should continue processing with the first sub-frame. - Notice that this may cause extra composition under the first frame - after the decoder loops back to the beginning. To: + The first sub-frame with delay_num greater than 0 marks the end of the + frame. The decoder should display the frame after handling this + sub-frame and leave the frame displayed for delay_num/delay_den seconds. + If delay_den is 0 when delay_num is greater than 0 the decoder should + not advance to the next frame automatically. After the last sub-frame + the decoder must start from the beginning again for a total of + num_iterations times, or for ever if num_iterations is 0. + + If the sub-frame sequence terminates with a 0 delay_num sub-frame then + the decoder shall still treat this as a frame, however the frame shall + not be displayed until after the last iteration. It's slightly easier to skip the 'zero delay' frame at the end rather than try to composite into the under the first frame. By specifying things this way each loop through the iteration is independent of the previous loop - incidentally I think that is the intention in APNG, but it wasn't clearly stated. With mPNG every frame (even) is independent of every other one - they are trivial to edit individually. In APNG every frame potentially depends on every preceding frame, and breaking this dependency typically involves duplicating pixel data in the APNG. >We may also specify that total_width needs to follow sTER rules when sTER >is present. > >That brings another another condition for mPNG + sTER to respect the sTER >specs. For stereo animation, the big image width (containing all >sub-images) needs to follow sTER rules even if this width is not use by >sTER. That may result in useless padding pixels but in the case total_width >needs some padding pixels, those do not need to be draw so less image data >is required. That is correct, and I think it follows logically from the two specifications. What's less clear is how to make a stereo animation - unlike APNG the differences in width between IHDR and the mPNG frame lead to confusion. The following adds quite a lot to the complexity (simplifications gratefully accepted), fortunately it can be ignored by every decoder except those with stereo capability: 4.3 Interation with sTER If a sTER chunk is present the whole image may be interpreted according to the sTER chunk rules. The encoder may write a set of stereo sub-frames into the image data spaced according to the sTER specification. The mPNG sub-frame sequence is defined to contain only the right eye image sequence (on the left of the full image). Should a decoder wish to recover the left eye sequence the sub-images may be found in the corresponding position on the main image given by the sTER chunk rules. In the event that the mPNG sub-frame sequence uses pixels from the left eye sub-image the decoder shall use the same image for the left eye sequence. In the even that a sub-frame spans the right/left sub-image boundary the left eye image simply extends beyond the right of the main image and is therefore treated as transparent. This latter condition is probably an error and a decoder or editor may chose to treat it as such. John Bowler <jbowler@...> ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG montage images
by John Bowler
::
Rate this Message:
From: Glenn Randers-Pehrson [mailto:glennrp@...]
>Just so I have this right: > >MPNG does not have any "dispose" operations per se. Correct. It also doesn't have 'save', neither the implicit form in APNG/AGIF nor the explicit form in MNG. >All the stuff you wrote, using up maybe half of your words, is >directed to authors telling them how to write an MPNG that makes >the same sequence of visible frames as an AGIF with a >properly-operating dispose would. Correct, the whole of '4.2' at the end. That section should not be a part of the PNG spec - it relies on my correct interpretation of AGIF (AGIF is not documented anywhere) and is irrelevant to how an mPNG chunk is encoded, decoded or editted. It's actually better written into a program I think. John Bowler <jbowler@...> ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG montage images
by glennrp-2
::
Rate this Message:
At 09:29 AM 3/17/2007 -0700, John Bowler wrote:
>From: Adeluc >>You have forgotten the num_iterations (unsigned int) --> Number of times to > >>loop this mPNG. 0 indicates infinite looping. > >Ah, you are correct. I thought an infinite delay was sufficient but that >only allows for 1 or infinite iterations. I think also the stuff about >sub-frames at the end compositing back onto the beginning is needless >complexity, so change: > >- The first sub-frame with delay_num greater than 0 marks the end of the >- frame. The decoder should display the frame after handling this >- sub-frame and leave the frame displayed for delay_num/delay_den seconds. >- If delay_den is 0 when delay_num is greater than 0 the decoder should >- not advance to the next frame automatically. After the last sub-frame >- the decoder should continue processing with the first sub-frame. >- Notice that this may cause extra composition under the first frame >- after the decoder loops back to the beginning. > >To: > >+ The first sub-frame with delay_num greater than 0 marks the end of the >+ frame. The decoder should display the frame after handling this >+ sub-frame and leave the frame displayed for delay_num/delay_den seconds. >+ If delay_den is 0 when delay_num is greater than 0 the decoder should >+ not advance to the next frame automatically. After the last sub-frame >+ the decoder must start from the beginning again for a total of >+ num_iterations times, or for ever if num_iterations is 0. >+ >+ If the sub-frame sequence terminates with a 0 delay_num sub-frame then If the final sub-frame sequence... >+ the decoder shall still treat this as a frame, however the frame shall >+ not be displayed until after the last iteration. > >It's slightly easier to skip the 'zero delay' frame at the end rather than >try to composite into the under the first frame. By specifying things this >way each loop through the iteration is independent of the previous loop - >incidentally I think that is the intention in APNG, but it wasn't clearly >stated. > >With mPNG every frame (even) is independent of every other one - they are >trivial to edit individually. In APNG every frame potentially depends on >every preceding frame, and breaking this dependency typically involves >duplicating pixel data in the APNG. > >>We may also specify that total_width needs to follow sTER rules when sTER >>is present. >> >>That brings another another condition for mPNG + sTER to respect the sTER >>specs. For stereo animation, the big image width (containing all >>sub-images) needs to follow sTER rules even if this width is not use by >>sTER. That may result in useless padding pixels but in the case >total_width >>needs some padding pixels, those do not need to be draw so less image data >>is required. > >That is correct, and I think it follows logically from the two >specifications. > >What's less clear is how to make a stereo animation - unlike APNG the >differences in width between IHDR and the mPNG frame lead to confusion. >The following adds quite a lot to the complexity (simplifications >gratefully accepted), fortunately it can be ignored by every decoder >except those with stereo capability: > >4.3 Interation with sTER > >If a sTER chunk is present the whole image may be interpreted according to >the >sTER chunk rules. The encoder may write a set of stereo sub-frames into the >image data spaced according to the sTER specification. The mPNG sub-frame >sequence is defined to contain only the right eye image sequence (on the >left >of the full image). I'd rather not make a special rule. Instead, the image author is reponsible for writing the playlist such that each frame has a left-eye image and a right-eye image properly positioned. Decoders that recognize and find a sTER chunk can assume that the main image is a stereo pair (of contact sheets) and each extracted frame is a stereo pair adhering to the sTER chunk rules. Main image (cross-fused) R1 R2 R3 P L1 L2 L3 R4 R5 R6 P L4 L5 L6 R7 R8 R9 P L7 L8 L9 Animation (cross-fused) R1 p L1 R2 p L2 ... R9 p L9 Where Rn are the right-eye images, Ln the left-eye images, P the padding computed for the main image, and p the padding for the animation frames. This is not as efficient as a special rule where only the left-eye image appears in the playlist, but these will be rare enough that in the grand scheme of things it won't matter. It is simpler because there is nothing special for the decoder to consider. It just follows the playlist as usual. >Should a decoder wish to recover the left eye sequence >the sub-images may be found in the corresponding position on the main image >given by the sTER chunk rules. > >In the event that the mPNG sub-frame sequence uses pixels from the left eye >sub-image the decoder shall use the same image for the left eye sequence. >In the >even that a sub-frame spans the right/left sub-image boundary the left eye >image simply extends beyond the right of the main image and is therefore >treated >as transparent. This latter condition is probably an error and a decoder or >editor may chose to treat it as such. > >John Bowler <jbowler@...> > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG montage images
by John Bowler
::
Rate this Message:
From: Glenn Randers-Pehrson [mailto:glennrp@...]
>At 11:43 PM 3/16/2007 -0700, John Bowler wrote: >>So far as I can see composition to an intermediate post-multiplied surface >>is poorly defined (very poorly) when both source and destination have an >>alpha of 0 > >If there isn't a school solution to that situation we can define the >proper behavior. I think it would be to simply leave the destination >triple as is and ignore the source triple. Applications will probably >do that naturally, if they are special-casing a source alpha of 0. They special case dest_alpha==0.0 because that is the most common case, then they special case source_alpha==0.0 I believe the math is as follows, but other people on this list have much more experience than me: C - component (R, G or B) Cs source/sprite, Cd destination/frame buffer A - alpha As source/sprite, Ad destination/frame buffer Ad is initially 0 (before any sub-frames are composited), Cd is determined by the application to be an appropriate background value. Cd is actually irrelevant if the app alpha composites onto the device and Ad is 0. Ad' := Ad*(1-As) + As Ad * (1-As) As Cd' := Cd * ----------- + Cs * --- Ad' Ad' This reduces for As==0, Ad!=0 (transparent source/sprite) to: Ad' := Ad Cd' := Cd And for As!=0, Ad==0 (initial, transparent, frame) to: Ad' := As Cd' := Cs When As==0 *and* Ad==0 Ad' will be zero but Cd' will be between Cd and Cs (inclusive). The correct choice will, I think, always be one of the extremes. If the decoder handles alpha by compositing onto a background value then it should use Cd, but in that case it can skip the complexities above by not having alpha in the frame - just initialise to the background. If the decoder handles alpha by simply ignoring it, or, maybe, if it dithers the alpha channel, then it should probably use Cs, because that was appropriate for the source/sprite. Personally I would just use a pre-multiplied buffer and dither the alpha channel - so I'd punt the division until I got to a point where I has to deal with 0<alpha<1 (and then I'd do it with a lookup table - +/-10% is plenty accurate enough.) In fact using post-multiplied alpha components in an image pipeline is fundamentally flawed. Processing operations work on pre-multiplied components. Take a look at the above equations, they calculate the pre-multiplied result then divide out to get post-multiplied, horrible. John Bowler <jbowler@...> ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG montage images
by John Bowler
::
Rate this Message:
From: Glenn Randers-Pehrson
>I'd rather not make a special rule. [for sTER handling] I agree. It means that a non-sTER aware decoder displays a stereo animation, whereas with my rule it displayed just the right eye half, but, thinking about it again, a stereo display is probably better. >This is not as efficient as a special rule where only the >left-eye image appears in the playlist, but these will be >rare enough that in the grand scheme of things it won't matter. >It is simpler because there is nothing special for the decoder >to consider. It just follows the playlist as usual. Right, it's simpler for everyone. John Bowler <jbowler@...> ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
|
|
Re: PNG montage images
by Willem van Schaik
::
Rate this Message:
>
> 4. mPNG montage/animation description chunk > John, I'm still wrestling a lot with the text of your spec. For example: you talk already about differences with animated GIF, before you even have explained the terms montage, image, sub-image, frame, sub-frame. But text is easier to fix than a wrong format. :-) To clearify for me, can you explain: If I have a 640x480 image with 5 frames, so with a "total size" of 3200x480, what will today's non-MPNG-aware application display: a) the top-left 640x480 of the "total image" b) the full 3200x480, as in a film-strip c) some garbage Thx, Willem ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ png-mng-misc mailing list png-mng-misc@... https://lists.sourceforge.net/lists/listinfo/png-mng-misc |
Some parts of this message have been removed.
Learn more about Nabble's | < Prev | 1 - 2 - 3 - 4 | Next > |
| Free embeddable forum powered by Nabble | Forum Help |
