Re: APNG MIME type and extension

[glennrp-2]

At 09:30 PM 3/17/2007 -0800, Willem van Schaik wrote:

>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

It would show "b".  In the case of an image being displayed on a
web page with proper "width" and "height" tags in the < img > it
would be scaled down to that width and height.  A web page author
should write the desired dimensions of the animation there rather
than the dimensions of the total image.  Also, the author
could construct the image as

    1 2 3
    4 5

instead of

    1 2 3 4 5

to get a better-looking fall-back display.

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

[Adeluc]

Draft mPNG chunk terms suggestion : Those are not perfect and need some fine
tuning.

ImageCollage :  Contains of all the ImagePieces used during the InterFrames
Montages to create every animation frames.  Saved in one or more IDAT
chunks.  To avoid errors by stereo decoder not supporting mPNG, the
ImageCollage's width needs to follow the sTER rules only when the sTER chunk
is present.  However, there is no restriction on ImagePieces' positions or
padding pixels' positions.

ImagePiece :  Image created from the ImageCollage by copying a rectangle of
ip_width  x  ip_height from position (ip_offsetX, ip_offsetY).  The
resulting rectangle must be contained inside ImageCollage.

InterFrame Montage :  Series of ImagePiece blend operations to draw a
InterFrame.  Each new InterFrames have their pixels initialized to
RGBA(0,0,0,0) before the first blend operation is done.

InterFrame :  Alpha pre-multiplied image created by an InterFrame Montage.
There is no background information in this image.

Sur-Frame :  Alpha pre-multiplied image created by the merge of an
InterFrame over the previous Sur-Frame.  There is no background information
in this image.

Frame :  Image with no alpha created by the merge of the Sur-Frame over the
Background.

The introduction of Sur-Frame is required for stereo animation with
transparency otherwise you will get erroneous display for certain stereo
display modes like Cross-fused, Parallel, RedCyan anaglyph.  Also my
intuition tells me that it may help with the InterFrame Montage disposal
problems.  That needs to be verify.




mPNG with sTER :

A stereo animation should simply consist of creating each stereo frame
(sur-frame) as an usual stereo image representing the right_image +
paddind_pixels + left_image ready to be send to the stereo decoder.  (Or
left + pad + right if the sTER chunk specifies this order).  There is no
need to put any additional restriction to the ImageCollage except for its
width.  If there is no stereo decoder the animation will be displayed as a
cross-eye (or parallel) stereo animation with an erroneous background under
the rightmost image if transparency is present.

The reason for each stereo frames to not contain any background data before
sent to the stereo decoder is because the background can be merged
differently depending of the the stereo display mode chosen by the user and
also the background pixels below left and right images must be cosited
during the merge.

The only issue I see is that you will need to pass a flag to the stereo
decoder to indicate if the stereo frame (sur-frame) is pre-multiplied or
not.  In the actual case of a static image it is not pre-mutiplied.  That is
the only modification I see up to now for actual stereo decoders.


-------------------------------------------------------------------------
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

[Adeluc]

Same e-mail as previous one except "Sur-Frame" renamed to "ForegroundFrame"
AND added some information about disposal methods.


Draft of mPNG chunk terms suggestion : Those are not perfect and need some
fine
tuning.

ImageCollage :  Contains of all the ImagePieces used during the InterFrames
Montages to create every animation frames.  Saved in one or more IDAT
chunks.  To avoid errors by stereo decoder not supporting mPNG, the
ImageCollage's width needs to follow the sTER rules only when the sTER chunk
is present.  However, there is no restriction on ImagePieces' positions or
padding pixels' positions.

ImagePiece :  Image created FROM the ImageCollage by copying a rectangle of
ip_width  x  ip_height from position (ip_offsetX, ip_offsetY).  The
resulting rectangle must be contained inside ImageCollage.

InterFrame Montage :  Series of ImagePiece blend operations to draw a
InterFrame.  Each new InterFrames have their pixels initialized to
RGBA(0,0,0,0) before the first blend operation is done.

InterFrame :  Alpha pre-multiplied image created by an InterFrame Montage.
There is no background information in this image.

ForegroundFrame :  Alpha pre-multiplied image created by the merge of an
InterFrame over the previous ForegroundFrame.  There is no background
information
in this image.

Frame :  Image with no alpha created by the merge of the ForegroundFrame
over the
Background.

The introduction of ForegroundFrame is required for stereo animation with
transparency otherwise you will get erroneous display for certain stereo
display modes like Cross-fused, Parallel, RedCyan anaglyph.  Also my
intuition tells me that it may help with the InterFrame Montage disposal
problems.  That needs to be verify.


========================================
Disposal methods apply to each ImagePiece blend operations separately but
instead of undoing blend operations you modify the ForegroundFrame by
redoing the series of ImagePiece blend operations on it according to their
disposal methods.

Disposal methods:
  Leave it -->  Draw the ImagePiece on the ForegroundFrame.
  Restore to previous -->  Draw nothing.
  Restore to background --> Draw a RGBA(0,0,0,0) rectangle on the
ForegroundFrame.
========================================

mPNG with sTER :

A stereo animation should simply consist of creating each stereo frame
(foregroundframe) as an usual stereo image representing the right_image +
paddind_pixels + left_image ready to be send to the stereo decoder.  (Or
left + pad + right if the sTER chunk specifies this order).  There is no
need to put any additional restriction to the ImageCollage except for its
width.  If there is no stereo decoder the animation will be displayed as a
cross-eye (or parallel) stereo animation with an erroneous background under
the rightmost image if transparency is present.

The reason for each stereo frames to not contain any background data before
sent to the stereo decoder is because the background can be merged
differently depending of the the stereo display mode chosen by the user and
also the background pixels below left and right images must be cosited
during the merge.

The only issue I see is that you will need to pass a flag to the stereo
decoder to indicate if the stereo frame (foregroundframe) is pre-multiplied
or
not.  In the actual case of a static image it is not pre-mutiplied.  That is
the only modification I see up to now for actual stereo decoders.

 _________
/   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

[glennrp-2]

At 01:28 PM 3/18/2007 -0400, Adeluc wrote:
>Same e-mail as previous one except "Sur-Frame" renamed to "ForegroundFrame"
>AND added some information about disposal methods.
>
>
>Draft of mPNG chunk terms suggestion : Those are not perfect and need some
>fine
>tuning.

I think it's a good idea to define our terminology well.  But I also
think that we should use simple familiar words if possible, or we run
the risk of making the proposal look more complex than it really is.

In my embedded comments below I suggest some other words that could
be used.  I'm not commenting on pre-multiplied alpha at this point but
am merely reproducing your text for context.

>
>ImageCollage :

Source Image, PNG Image, IDAT Image, or Main Image

>Contains of all the ImagePieces used during the InterFrames
>Montages to create every animation frames.  Saved in one or more IDAT
>chunks.  To avoid errors by stereo decoder not supporting mPNG, the
>ImageCollage's width needs to follow the sTER rules only when the sTER chunk
>is present.  However, there is no restriction on ImagePieces' positions or
>padding pixels' positions.
>
>ImagePiece :

Tile

>Image created FROM the ImageCollage by copying a rectangle of
>ip_width  x  ip_height from position (ip_offsetX, ip_offsetY).  The
>resulting rectangle must be contained inside ImageCollage.

Do we require it to be contained inside the Source Image as described,
or do we require the decoder to clip it if necessary to make it so?

>InterFrame Montage :  Series of ImagePiece blend operations to draw a
>InterFrame.  Each new InterFrames have their pixels initialized to
>RGBA(0,0,0,0) before the first blend operation is done.

I'm not sure this one is necessary.  We'll see.

>InterFrame :  Alpha pre-multiplied image created by an InterFrame Montage.
>There is no background information in this image.

Also maybe not needed.

>ForegroundFrame :  Alpha pre-multiplied image created by the merge of an
>InterFrame over the previous ForegroundFrame.  There is no background
>information
>in this image.

Output buffer, or maybe just Buffer.

>Frame :  Image with no alpha created by the merge of the ForegroundFrame
>over the
>Background.

Frame is OK

Background -> Canvas?

>
>The introduction of ForegroundFrame is required for stereo animation with
>transparency otherwise you will get erroneous display for certain stereo
>display modes like Cross-fused, Parallel, RedCyan anaglyph.  Also my
>intuition tells me that it may help with the InterFrame Montage disposal
>problems.  That needs to be verify.
>
>
>========================================
>Disposal methods apply to each ImagePiece blend operations separately but
>instead of undoing blend operations you modify the ForegroundFrame by
>redoing the series of ImagePiece blend operations on it according to their
>disposal methods.
>
>Disposal methods:
>  Leave it -->  Draw the ImagePiece on the ForegroundFrame.

                 Draw the Tile on the Buffer

>  Restore to previous -->  Draw nothing.
>  Restore to background --> Draw a RGBA(0,0,0,0) rectangle on the
>ForegroundFrame.

 Buffer

>========================================
>
>mPNG with sTER :
>
>A stereo animation should simply consist of creating each stereo frame
>(foregroundframe) as an usual stereo image representing the right_image +

 (buffer)

>paddind_pixels + left_image ready to be send to the stereo decoder.  (Or
>left + pad + right if the sTER chunk specifies this order).  There is no
>need to put any additional restriction to the ImageCollage except for its
                                                Source Image
>width.  If there is no stereo decoder the animation will be displayed as a
>cross-eye (or parallel) stereo animation with an erroneous background under
>the rightmost image if transparency is present.
>
>The reason for each stereo frames to not contain any background data before
>sent to the stereo decoder is because the background can be merged
>differently depending of the the stereo display mode chosen by the user and
>also the background pixels below left and right images must be cosited
>during the merge.

It seems that background would have to be a simple solid color or would
have to be a stereo pair of the same dimensions as the buffer, and when
viewed would appear to be at a reasonable distance from the eyes as
compared to the stereo image in the buffer.  It would be better to
provide such background explicitly rather than trying to use a background
from outside the scope of the PNG.

>
>The only issue I see is that you will need to pass a flag to the stereo
>decoder to indicate if the stereo frame (foregroundframe) is pre-multiplied
>or
>not.  In the actual case of a static image it is not pre-mutiplied.  That is
>the only modification I see up to now for actual stereo decoders.
>
> _________
>/   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
>

-------------------------------------------------------------------------
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

[Nozomu Katoo]

Vladimir Vukicevic wrote:

>The ability to stream is pretty important, as is simplicity of
>implementation.

If so, it may be not good to write the number of frames into aCTl at the
first.

How about using 0xffffffff of sequence_number in the fCTl chunk to know
the last frame, instead of removing the num_frames field of the aCTl?

--
N.Katoo <png.ml@...>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

[glennrp-2]

At 10:34 AM 3/19/2007 +0900, Nozomu Katoo wrote:
>Vladimir Vukicevic wrote:
>
>>The ability to stream is pretty important, as is simplicity of
>>implementation.
>
>If so, it may be not good to write the number of frames into aCTl at the
>first.

I think it was suggested earlier that 0 could mean unknown.  Truly unknown,
that is, not merely too lazy to figure it out.

>How about using 0xffffffff of sequence_number in the fCTl chunk to know
>the last frame, instead of removing the num_frames field of the aCTl?

Then there would be a gap between the next-to-last and last chunks.

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

[Nozomu Katoo]

Glenn Randers-Pehrson wrote:

>>How about using 0xffffffff of sequence_number in the fCTl chunk to know
>>the last frame, instead of removing the num_frames field of the aCTl?
>
>Then there would be a gap between the next-to-last and last chunks.

Sorry, I should have written "sequence_number in the last fDAt chunk of the
last frame."

--
N.Katoo <png.ml@...>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
png-mng-misc mailing list
png-mng-misc@...
https://lists.sourceforge.net/lists/listinfo/png-mng-misc

[glennrp-2]

At 11:25 AM 3/19/2007 +0900, Nozomu Katoo wrote:
>Glenn Randers-Pehrson wrote:
>
>>>How about using 0xffffffff of sequence_number in the fCTl chunk to know
>>>the last frame, instead of removing the num_frames field of the aCTl?
>>
>>Then there would be a gap between the next-to-last and last chunks.
>
>Sorry, I should have written "sequence_number in the last fDAt chunk of the
>last frame."

That's what I understood you to mean.  That would still create a gap.
You can say that 0xffffffff must be a special case to the decoder, but
then they wouldn't be able to detect a missing next-to-last chunk.

Anyhow we have been asked to stop making technical changes to the proposal.
That request is of course in itself counter to the PNG philosophy...
Meanwhile, further development of the mPNG chunk proposal is still welcome.

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

[John Bowler]

I believe there is a fundamental misunderstanding of what I was proposing in
here:

From: Adeluc
>ForegroundFrame :  Alpha pre-multiplied image created by the merge of an
>InterFrame over the previous ForegroundFrame.  There is no background
>information in this image.

No, I deliberately did not do this.  Each frame is independent of the
previous - the sub-frames (in my terminology) build the frame up from
scratch - from transparent.

Compositing over the previous frame creates something insufficient for AGIF
- that's because AGIF has a 'clear' operation (hidden in the dispose ops)
which is able to remove the previous frame contents as required.  Adding
this is the root source of the disposal method complexity in GIF.
Consequently the GIF disposal method complexity can be eliminated by not
allowing direct reuse of the previous frame.  As Glenn and I discussed this
has overhead in the mPNG chunk in my proposal but, unlike GIF, no overhead
in the IDAT (images) because they may be reused in mPNG (unlike GIF).

The disposal method obfuscation is the root cause of the AGIF 'save' - the
requirement that the decoder preserve the contents of the previous frame for
the next frame (as opposed to the base AGIF requirement that the previous
frame be saved for *this* frame.)  The disposal method is the single most
difficult to understand thing in GIF, it's really really worth avoiding...

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

[Adeluc]

>  A sub-frame is a sequence of 28 bytes:
>
>       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
>
>   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.
>
>   If composition of the next frame takes longer than delay_num/delay_den
> seconds
>   from the previous frame the decoder should display the next frame
> immediately.
>   This frame should, itself, be displayed for a duration given by its own
> delay.
>   That is to say a decoder should not catch up delays in preceding frames.

I do not understand what do you mean by :
   "If delay_den is 0 when delay_num is greater than 0 the decoder should
not advance to the next frame automatically.
What exactly will make the animation to advance?  User input?

I have read on GIF specs a very useful feature:
http://www.w3.org/Graphics/GIF/spec-gif89a.txt
v) User Input Flag - Indicates whether or not user input is
            expected before continuing. If the flag is set, processing will
            continue when user input is entered. The nature of the User
input
            is determined by the application (Carriage Return, Mouse Button
            Click, etc.).

            Values :    0 -   User input is not expected.
                            1 -   User input is expected.

            When a Delay Time is used and the User Input Flag is set,
            processing will continue when user input is received or when the
            delay time expires, whichever occurs first.

I find that feature a great idea to make step by step interactive animation.
If we decide to add this feature, instead of making the structure bigger for
rare case interactive animation,  maybe we should simply state that if
delay_num is < 0 then the animation will wait during (abs( delay_num ) /
delay_den) seconds for an user input before continuing automatically.


 _________
/   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

[John Bowler]

From: Adeluc
>I do not understand what do you mean by :
>   "If delay_den is 0 when delay_num is greater than 0 the decoder should
>not advance to the next frame automatically.

The delay is infinite (as the math would suggest).  I was trying to avoid
needing to specify whether the animation loops when I did this - an infinite
delay on the last frame stops looping.  As you pointed out that is
insufficient.

It does also match the GIF user input functionality, because in reality:

> When a Delay Time is used and the User Input Flag is set,
> processing will continue when user input is received or when the
> delay time expires, whichever occurs first.

This is what always happens with web browsers; they have some way (I am
told) to directly select GIF frames as a result of user button clicks on the
web page.

Something has to happen in the decoder if delay_den is 0, it seems to me
that an infinite delay is just easiest.  It may just be sufficient to say
"delay_den of 0 with delay_num greater than 0 indicates an infinite delay."

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