Re: APNG MIME type and extension

[John Bowler]

At 09:53 AM 3/16/2007 -0400, Glenn Randers-Pehrson wrote:
>This is an interesting proposal and in fact is how I made some of the
>early MNG demos that are on the MNG ftp site.  They contain one wide
>image that is viewed one piece at a time, like a film strip.

It's consistent with sTER.  It has the advantage that the fallback
displays all the information.  I find the idea that an older decoder
of APNG omits some information (all frames after the first) worrying.

Yes, it's a montage, but the montage displays the information.  That's
particularly valuable for animations which display instruction sequences.

The main negative I see is that that width/height of the montage is
significantly greater than that of the animation.  This problem exists
for sTER as well - when a sTER image is viewed through a stereo viewer
it is half the width of the PNG (in pixels).  That makes page layout
pretty difficult.

Still, it seems more philosophically compatible with PNG than APNG.

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

[glennrp-2]

At 01:39 PM 3/16/2007 -0700, John Bowler wrote:

>At 09:53 AM 3/16/2007 -0400, Glenn Randers-Pehrson wrote:
>>This is an interesting proposal and in fact is how I made some of the
>>early MNG demos that are on the MNG ftp site.  They contain one wide
>>image that is viewed one piece at a time, like a film strip.
>
>It's consistent with sTER.  It has the advantage that the fallback
>displays all the information.  I find the idea that an older decoder
>of APNG omits some information (all frames after the first) worrying.
>
>Yes, it's a montage, but the montage displays the information.  That's
>particularly valuable for animations which display instruction sequences.

You have misinterpreted the suggestion.  The montage, which is contained
in the APNG fDAt chunks, is larger than the main image.  You don't see
all of it in the fallback situation, only whatever is in the IDAT chunks.

Here's an APNG according to this suggestion:

seq   chunk
none  IHDR
none  aCTl
none  IDAT  image data for frame 0
none  IDAT  more of frame 0
0000  fDAt  image data for the montage
0001  fDAt  more of the montage
0002  fDAt  still more
0003  fCTl  frame control data for frame 1
0004  fCTl  frame control data for frame 2
...
N+2   fCTl  frame control data for frame N
none  IEND

Hmmm, we shouldn't really recommend lowercase L in chunk names; it looks
too much like the digit 1.  How about aCTr and fCTr instead?

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]

From: Adeluc
>>Unfortunately, I already proposed something like that few months ago and
it
>was rejected even for discussion because the big image is not 1 image but
>many images and applications not supporting the aCTL and fCTL chunk will
>display a huge image looking like garbage.  At least an application not
>supporting the aCTL and fCTL chunk can edit all the frames in this format.

I think Adeluc means:

From: Adeluc
Sent: Thursday, November 18, 2004 9:54 AM
To: png-list@...
Subject: [png-list] CFD: Will you consider adding animation support to
existing PNG format?

Also separately posted (immediately before) with the subject line:

[png-list] Quick opinion poll

The only comment seemed to be from Matthias B., to the effect that it was
more difficult to implement and has a less useful fallback.

Still, it seems to at least address the fundamental problems of APNG -
the fallback is clearly lack-of-support, not a bug, and information is
not lost.

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

[glennrp-2]

At 02:16 PM 3/16/2007 -0700, John Bowler wrote:
>From: Adeluc
>>>Unfortunately, I already proposed something like that few months ago and
>it
>>was rejected even for discussion because the big image is not 1 image but
>>many images and applications not supporting the aCTL and fCTL chunk will
>>display a huge image looking like garbage.

Right, but I've modified his suggestion to be more like the existing
APNG proposal in terms of the fall-back image.

Looking at this

seq   chunk
none  IHDR
none  aCTl
none  IDAT  image data for frame 0 (not displayed in animation)
none  IDAT  more of frame 0        (not displayed in animation)
0000  fDAt  image data for the montage
0001  fDAt  more of the montage
0002  fDAt  still more
0003  fCTl  frame control data for frame 1
0004  fCTl  frame control data for frame 2
...
N+2   fCTl  frame control data for frame N
none  IEND

makes me realize that we could relax the ordering requirement of
fCTl versus fDAt.  The only real requirement is that the fCTl
chunks remain in order with respect to the other fCTl chunks
and that the fDAt chunks remain in order.  So they could have
individual sequences, like this (with a pre-IDAT fCTL chunk this
time, just for variety, and aCTl -> aCTr and fCTl -> fCTr):


seq   chunk
none  IHDR
none  aCTr
0000  fCTr  frame control for frame 0
none  IDAT  image data for frame 0 (always displayed)
none  IDAT  more of frame 0        (always displayed)
0000  fDAt  image data for the montage
0001  fDAt  more of the montage
0002  fDAt  still more
0001  fCTr  frame control data for frame 1
0002  fCTr  frame control data for frame 2
...
N+1   fCTr  frame control data for frame N
none  IEND


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

[Vladimir Vukicevic-3]

Glenn Randers-Pehrson wrote:

> At 02:16 PM 3/16/2007 -0700, John Bowler wrote:
>> From: Adeluc
>>>> Unfortunately, I already proposed something like that few months ago and
>> it
>>> was rejected even for discussion because the big image is not 1 image but
>>> many images and applications not supporting the aCTL and fCTL chunk will
>>> display a huge image looking like garbage.
>
> Right, but I've modified his suggestion to be more like the existing
> APNG proposal in terms of the fall-back image.

I don't see the point of using a montage -- all you're doing is
basically requiring that decoders be able to decode an image of
potentially very large dimensions.  The main ("philosophical")
objections to APNG still remain, so it solves nothing from that point.

If a non-APNG aware tool tries to manipulate an APNG image as if it was
a single-frame PNG, it will be a single-frame PNG for all intents and
purposes to it; if the APNG chunks are removed, reordered, whatever, I
don't see the problem -- it's a tool explicitly designed for
manipulating the image, so the user will (hopefully) see that something
unexpected is happening.  Whether a montage is used or separate images
are used, it doesn't really modify this; the user still can't edit the
animation data in a non-APNG-aware application.

So there's really no advantage to using a montage image, and it adds
additional complexity and requirements to both encoders and decoders.

     - Vlad

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

[John Bowler]

This is an attempt to produce a mimimal sTER style definition of a film
strip contained in a single PNG image.  It is derived from Adeluc's original
(2004) suggestion.

Unlike Adeluc's most recent suggestion it draws on the capabilities of
AGIF, not APNG, and it meets all of those capabilities which are expressed
in APNG.  It is much, much, simpler than APNG and a lot simpler than AGIF
too.

John Bowler <jbowler@...>

4. mPNG montage/animation description chunk

Overview

   The MPNG chunk describes how to interpret a PNG image as a montage of
   sub-images to be displayed in sequence.  MPNG is able to fully represent
   an animated GIF image except that the animated GIF capability to use
   multiple palettes, allowing more than 256 colours in a palette mapped
   image, is not supported.  Applications needing to support this should use
   a single 24 bit RGB PNG image instead.

   If the mPNG chunk appears it indicates that the PNG image can be split
   into sub-images which might then be displayed by a multi-frame capable
   application.  Applications may chose to perform this transformation
   under user control or may chose to automatically display the individual
   frames.  It is always valid to display the single, montage, image as
   defined by the PNG specification.

   The mPNG chunk shall appear before the first IDAT.

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    sub_frame    28 bytes         First sub-frame

  Each frame is composed of one or more sub-frames which are combined
  together to form a frame of size (total_width, total_height).  This frame
  may then be displayed by an mPNG capable decoder.  Each frame contents
  before any sub-frames are added are transparent throughout (alpha 0).

  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 sub-frame data identifies a rectangle (x,y,width,height) in the PNG
   image containing pixels of the sub-frame.  This rectangle is composited
   on the frame at top left position (x_offset, y_offset).  Any part of the
   sub-frame outside the PNG image is to be treated as transparent.  Any
part
   of the sub-frame which extends outside the frame is to be ignored.

   Composition is to be performed by alpha composition taking account of
   any pixels in the frame defined by previous sub-frames.  Notice that
   this may result in pixels with partial alpha (neither 0 nor 1), the
composition
   must take this into account and is expected to interpret the color space
   chunks (in particular gAMA) correctly when doing this.

   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.

4.2 Convertion of AGIF animations

   An Animated GIF (AGIF) animation may be trivially converted to an mPNG
   animation by rendering each AGIF frame in turn in an image buffer equal
   in width to the GIF width and equal in height to the GIF height times the
   number of frames.

   The sub-frame information generated for an AGIF then consists simply of
   the position of each frame and the GIF delay time.  A converter should
take
   care to convert low GIF frame delay information to the actual delays
   implemented by AGIF decoders, since a 0 delay in AGIF indicates a minimum
   delay whereas in an mPNG sub-frame it indicates sub-frame composition.

   A more efficient convertion may be obtained by identifying frame
backgrounds
   within the AGIF frame sequence and storing these separately in the PNG so
that
   they may be reused.  Frame backgrounds can be recognized from the
disposal
   method in an AGIF graphics control extension:

   0  Behaves as 1
   1  Do not dispose.  The qualified GIF sub-image is the final sub-frame in
      an mPNG frame.  It also defines a background for the next sub-image.
   2  Restore to background.  The region under the AGIF sub-image is set to
      transparent, or to a standard colour (depending on the AGIF header).
      This is the start of a background description for this area of the
      mPNG frame.
   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.

   A high quality converter will, at least, handle the information
explicitly
   recorded in the AGIF disposal methods.  It may also deduce further
   optimization of the AGIF by identifying repeated use of sub-images.

   


-------------------------------------------------------------------------
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 03:13 PM 3/16/2007 -0700, you wrote:

>Glenn Randers-Pehrson wrote:
>> At 02:16 PM 3/16/2007 -0700, John Bowler wrote:
>>> From: Adeluc
>>>>> Unfortunately, I already proposed something like that few months ago and
>>> it
>>>> was rejected even for discussion because the big image is not 1 image but
>>>> many images and applications not supporting the aCTL and fCTL chunk will
>>>> display a huge image looking like garbage.
>>
>> Right, but I've modified his suggestion to be more like the existing
>> APNG proposal in terms of the fall-back image.
>
>I don't see the point of using a montage -- all you're doing is
>basically requiring that decoders be able to decode an image of
>potentially very large dimensions.

There are two main advantages of the montage.  One is the improved
compressibility and the other, very important, is the availability
of MNG's "reusable objects" without all the complexity of maintaining
objects.  The MNG "mayflower demo" could be accomplished this way, in a
few kbytes versus a few hundred kbytes as a current-proposal APNG.

A deficiency which I overlooked is that streaming capability is lost.
There is a way around that but it introduces some complexity.  We'd
have to allow multiple montages, each preceded by 1 or more fCTr
chunks.  In this case we'd have to use the single shared sequence
because the order of fCTr versus fDAt would have to be preserved.
At one end of the spectrum there would be the efficient one-montage
thing, with all of the fCTr chunks in a group preceding the fDAt
chunks, and at the other end would be one fCTr per frame, just as
in the existing proposal, but with the extra source_x_offset, source_y_offset
variables in the fCTr chunks and the extra source_width, source_height in
aCTr (it would be a little more complex if we allow the montages to have
different dimensions from each other but I don't see a need for that; just
require authors to pad the final one).

> The main ("philosophical")
>objections to APNG still remain, so it solves nothing from that point.

True, this suggestion has nothing to do with those.  Except that minimizing
filesize is part of the PNG philosophy too.

>If a non-APNG aware tool tries to manipulate an APNG image as if it was
>a single-frame PNG, it will be a single-frame PNG for all intents and
>purposes to it; if the APNG chunks are removed, reordered, whatever, I
>don't see the problem -- it's a tool explicitly designed for
>manipulating the image, so the user will (hopefully) see that something
>unexpected is happening.  Whether a montage is used or separate images
>are used, it doesn't really modify this; the user still can't edit the
>animation data in a non-APNG-aware application.

Right, those issues are the same whether we use montages or individual
frames.

>
>So there's really no advantage to using a montage image, and it adds
>additional complexity and requirements to both encoders and decoders.

It does add some complexity to decoders, agreed.  It wouldn't add any
complexity to encoders, if we allow single-image frames (which I think
we must, to preserve streamability).

Here's the example again, this time with multiple montages:

seq   chunk
none  IHDR
none  aCTr
0000  fCTr  frame control for frame 0
none  IDAT  image data for frame 0 (always displayed)
none  IDAT  more of frame 0        (always displayed)
0001  fCTr  frame control data for frame 1 (cropped from first montage)
0002  fCTr  frame control data for frame 2 (cropped from first montage)
0003  fDAt  image data for the first montage
0004  fDAt  more of the first montage
0005  fDAt  still more
0006  fCTr  frame control data for frame 3 (cropped from 2nd montage)
0007  fCTr  frame control data for frame 4 (cropped from 2nd montage)
0008  fCTr  frame control data for frame 5 (cropped from 2nd montage)
0009  fDAt  image data for the 2nd montage
0010  fDAt  more of the 2nd montage
0010  fDAt  still more
none  IEND

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

[glennrp-2]

At 03:34 PM 3/16/2007 -0700, John Bowler wrote:
>This is an attempt to produce a mimimal sTER style definition of a film
>strip contained in a single PNG image.

The main problem with this, and with the original suggestion, is that the
fallback image is too big.

Glenn

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

[glennrp-2]

At 06:54 PM 3/16/2007 -0400, Glenn Randers-Pehrson wrote:
>At 03:34 PM 3/16/2007 -0700, John Bowler wrote:
>>This is an attempt to produce a mimimal sTER style definition of a film
>>strip contained in a single PNG image.
>
>The main problem with this, and with the original suggestion, is that the
>fallback image is too big.

Oh, and, like my single-montage suggestion, it's not streamable.

Is streamability a requirement for APNG?  I think we might as well
try for it if it doesn't add complexity.

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]

From: Glenn Randers-Pehrson
>>From: Adeluc
>>>Unfortunately, I already proposed something like that few months ago and
>>>it
>>>was rejected even for discussion because the big image is not 1 image but

>>>many images and applications not supporting the aCTL and fCTL chunk will
>>>display a huge image looking like garbage.
>
>Right, but I've modified his suggestion to be more like the existing
>APNG proposal in terms of the fall-back image.

Yes, but the montage is the solution.

Because the montage is displayed by an existing decoder no information is
lost.  This removes a lot, maybe all, of the justification for not
supporting
multiple images.  The solution is already proved in sTER - i.e. we voted
that through even though the PNG has two sub-images.

Here's a list of at least some of the advantages:

1) Animations can't be displayed without a time line, but the montage is
displayed, so in principle the information is all there.
2) The non-display of the animation looks like a bug.  But when the montage
is displayed it is clearly not a bug - it's lack of support for the
animation.
3) The entire image data is visible to an editor and re-encoding operations
work (e.g. changing the gAMA, or colour type) because they change all
the image data.  (Indeed in my mPNG proposal the chunk might even be made
safe-to-copy because it keeps working under any transformation except true
image editing operations.)
4) It's a simple additive change on top of libpng - it doesn't require extra
support to read and decode fDAt chunks.

Indeed, my mPNG proposal is, I think:

1) Unambiguous.
2) Contains a description of how to convert AGIF.
3) Has no error conditions (regardless of what happens to the rest of the
PNG)
4) Consists of just 857 words.

Whereas the 20060314 version of APNG is:

1) Underspecified.
2) Contains no information about AGIF convertion.
3) Has at best ambiguous error handling.
4) Already amounts to 1994 words.

In fact if I take out the AGIF convertion stuff the mPNG spec is just 560
words.

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

[John Bowler]

From: Glenn Randers-Pehrson
>The main problem with this, and with the original suggestion, is that the
>fallback image is too big.

That's not a problem.  That's still part of the solution.  Yes the image
gets squeezed because the physical size makes the pixels very small, and
that may make it unviewable within a document, but I see that as a
consequence
of making a change which is not backward compatible.  It's obvious what
is happening.

>Oh, and, like my single-montage suggestion, it's not streamable.

Well, all of these proposals permit incremental display.  In the montage
case that means incremental rendering of the IDAT - in my proposal
all the sub-frame data is already present, so the decoder knows when
it has enough to display the next frame.  Similarly in the other
proposals.

True streamability means 'generation on the fly' and that means that
the number and content of the frames are not known at the start.  You
made APNG streamable in this sense by permitting num_frames to be 0.

Personally I think MNG is streamable, it was designed to be streamable
and is more than adequate.  So far as I am aware streaming GIF is not
a big feature of any application at present, but I might be wrong...

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

[glennrp-2]

At 04:14 PM 3/16/2007 -0700, John Bowler wrote:
>From: Glenn Randers-Pehrson
>>The main problem with this, and with the original suggestion, is that the
>>fallback image is too big.
>
>That's not a problem.  That's still part of the solution.  Yes the image
>gets squeezed because the physical size makes the pixels very small

I was thinking it would always be too big; I forgot about the possibility
of < img src=mpng.png, width=WWW, height=HHH > that will squeeze it
down on web pages, and change the aspect ratio, I suppose, if the mPNG
is a wide film-strip arrangement rather than a contact-print arrangement.

All in all, except for the streamability issue, I think your counter
proposal is quite attractive.  I would *not* object to calling such
a file a PNG and image/png, although I think video/png would also
be appropriate.

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

[glennrp-2]

At 03:34 PM 3/16/2007 -0700, John Bowler wrote:

>This is an attempt to produce a mimimal sTER style definition of a film
>strip contained in a single PNG image.  It is derived from Adeluc's original
>(2004) suggestion.
>
>Unlike Adeluc's most recent suggestion it draws on the capabilities of
>AGIF, not APNG, and it meets all of those capabilities which are expressed
>in APNG.  It is much, much, simpler than APNG and a lot simpler than AGIF
>too.
>
>John Bowler <jbowler@...>

Some (insignificant) comments are embedded below.

Glenn

>4. mPNG montage/animation description chunk
>
>Overview
>
>   The MPNG chunk describes how to interpret a PNG image as a montage of
>   sub-images to be displayed in sequence.  MPNG is able to fully represent
>   an animated GIF image except that the animated GIF capability to use
>   multiple palettes, allowing more than 256 colours in a palette mapped
>   image, is not supported.  Applications needing to support this should use
>   a single 24 bit RGB PNG image instead.

    It also provides the capability of reusing images or portions of an
    image which is a capability beyond those of AGIF.

>
>   If the mPNG chunk appears it indicates that the PNG image can be split
>   into sub-images which might then be displayed by a multi-frame capable
>   application.  Applications may chose to perform this transformation
>   under user control or may chose to automatically display the individual
>   frames.  It is always valid to display the single, montage, image as
>   defined by the PNG specification.
>
>   The mPNG chunk shall appear before the first IDAT.
>
>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    sub_frame    28 bytes         First sub-frame
>
>  Each frame is composed of one or more sub-frames which are combined
>  together to form a frame of size (total_width, total_height).  This frame
>  may then be displayed by an mPNG capable decoder.  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.

>
>  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 sub-frame data identifies a rectangle (x,y,width,height) in the PNG
>   image containing pixels of the sub-frame.  This rectangle is composited
>   on the frame at top left position (x_offset, y_offset).  Any part of the
>   sub-frame outside the PNG image is to be treated as transparent.  Any
>   part
>   of the sub-frame which extends outside the frame is to be ignored.
>
>   Composition is to be performed by alpha composition taking account of
>   any pixels in the frame defined by previous sub-frames.  Notice that
>   this may result in pixels with partial alpha (neither 0 nor 1), the
>   composition
>   must take this into account and is expected to interpret the color space
>   chunks (in particular gAMA) correctly when doing this.
>
>   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.
>
>4.2 Convertion of AGIF animations
>
>   An Animated GIF (AGIF) animation may be trivially converted to an mPNG
>   animation by rendering each AGIF frame in turn in an image buffer equal
>   in width to the GIF width and equal in height to the GIF height times the
>   number of frames.
>
>   The sub-frame information generated for an AGIF then consists simply of
>   the position of each frame and the GIF delay time.  A converter should
>   take
>   care to convert low GIF frame delay information to the actual delays
>   implemented by AGIF decoders, since a 0 delay in AGIF indicates a minimum
>   delay whereas in an mPNG sub-frame it indicates sub-frame composition.
>
>   A more efficient convertion may be obtained by identifying frame

    convertion -> conversion, throughout document

>   backgrounds
>   within the AGIF frame sequence and storing these separately in the PNG so
>   that
>   they may be reused.  Frame backgrounds can be recognized from the
>   disposal
>   method in an AGIF graphics control extension:
>
>   0  Behaves as 1
>   1  Do not dispose.  The qualified GIF sub-image is the final sub-frame in
>      an mPNG frame.  It also defines a background for the next sub-image.
>   2  Restore to background.  The region under the AGIF sub-image is set to
>      transparent, or to a standard colour (depending on the AGIF header).
>      This is the start of a background description for this area of the
>      mPNG frame.
>   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.

>   A high quality converter will, at least, handle the information
>   explicitly
>   recorded in the AGIF disposal methods.  It may also deduce further
>   optimization of the AGIF by identifying repeated use of sub-images.
>
>

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

[Vladimir Vukicevic-3]

John Bowler wrote:

> From: Glenn Randers-Pehrson
>>> From: Adeluc
>>>> Unfortunately, I already proposed something like that few months ago and
>>>> it
>>>> was rejected even for discussion because the big image is not 1 image but
>
>>>> many images and applications not supporting the aCTL and fCTL chunk will
>>>> display a huge image looking like garbage.
>> Right, but I've modified his suggestion to be more like the existing
>> APNG proposal in terms of the fall-back image.
>
> Yes, but the montage is the solution.
>
> Because the montage is displayed by an existing decoder no information is
> lost.  This removes a lot, maybe all, of the justification for not
> supporting
> multiple images.  The solution is already proved in sTER - i.e. we voted
> that through even though the PNG has two sub-images.

The montage may be displayed, but it's not meaningful in any useful way.
  If there is a meaningful way to convey the contents of the animation
to the user, the APNG static frame fallback can take care of that.

The ability to stream is pretty important, as is simplicity of
implementation.  While using a montage could result in higher
compression ratios, I think it's not worth having that to lose the
ability to stream.  If multiple montages are allowed, then we're back to
something that looks essentially like APNG, but with referencing of
subrects of previous montage images; that would be an additional feature
on top of APNG that allows for a smaller file for some types of
animations at the expense of encoder and decoder complexity.

I'm really hoping to hear any further specific technical (i.e.
non-philosophical or spiritual) issues with the APNG spec as it stands
today, instead of drastic changes or entirely new specs; otherwise we'll
continue to move forward with the implementation.  I will take a look at
the AGIF conversion issues and ambiguous error handling issues in the
next few days.

    - Vlad

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

[glennrp-2]

At 04:56 PM 3/16/2007 -0700, Vladimir Vukicevic wrote:

>The montage may be displayed, but it's not meaningful in any useful way.

So we must not only fool IE into displaying *something* instead of
a broken-image icon, but we must fool it into displaying
*something meaningful*.  I think that is a new requirement.  Also
we lose the ability to generate an independent fallback still image,
but I thought that was just a nice feature, not a requirement.

>The ability to stream is pretty important,

OK, although it's debatable whether streaming anigif are around.

>as is simplicity of
>implementation.

mPNG is clearly simpler.  There are no shared PLTE, no new interactions
between existing ancillary chunks and mPNG, no sequencing issues.

>While using a montage could result in higher
>compression ratios, I think it's not worth having that to lose the
>ability to stream.

Higher being potentially 1000:1 or more as opposed to APNG with no
more than single-frame PNG compression.  And even dumb editors that
simply do a blind conversion will probably get 60 percent of the
filesize achieved by APNG.

If multiple montages are allowed, then we're back to
>something that looks essentially like APNG, but with referencing of
>subrects of previous montage images; that would be an additional feature
>on top of APNG that allows for a smaller file for some types of
>animations at the expense of encoder and decoder complexity.

Right.  But we aren't allowing multiple montages.   I think it's the
absence of any other IDAT or IDAT-like chunks (i.e., fDAt) that makes
this one not a violation of the PNG spec.  It would still violate
the RFC "image" definition when it is placed on a web page and expected
to be animated.  Then use "video/png".

>
>I'm really hoping to hear any further specific technical (i.e.
>non-philosophical or spiritual) issues with the APNG spec as it stands
>today, instead of drastic changes or entirely new specs; otherwise we'll
>continue to move forward with the implementation.  I will take a look at
>the AGIF conversion issues and ambiguous error handling issues in the
>next few days.

I think the only technical issue not resolved in the voting proposal
dated 20070315 is the zero-time-delay issue.  I don't remember if we
have heard from you about that.  I think Stuart wants to interpret
0/100 and 0/0 both as 1/100.   I am in favor of interpreting 0/100
as 0 and 0/0 as 1/100. I would also like to add the multiple-montage
feature, but if you won't accept that, OK.  Leaving it out will make
APNG less of a MNG-killer.

You seem to be in a hurry but Stuart wanted us to delay the vote for some
indeterminate amount of time.

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

[glennrp-2]

At 08:18 PM 3/16/2007 -0400, Glenn Randers-Pehrson wrote:
>Right.  But we aren't allowing multiple montages.

Sorry, I meant we aren't allowing them in the Adeluc-Bowler "mPNG"
proposal.  I am advocating allowing them in APNG.

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]

On Fri, 16 Mar 2007 16:56:37 -0700, Vladimir Vukicevic wrote:

>continue to move forward with the implementation.  I will take a look at
>the AGIF conversion issues and ambiguous error handling issues in the
>next few days.

There is one conversion issue in the current APNG spec.  If you have not
read my posts last week, please look through these:
http://sourceforge.net/mailarchive/message.php?msg_id=38368921
http://sourceforge.net/mailarchive/message.php?msg_id=38370344

--
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 09:28 AM 3/17/2007 +0900, Nozomu Katoo wrote:

>On Fri, 16 Mar 2007 16:56:37 -0700, Vladimir Vukicevic wrote:
>
>>continue to move forward with the implementation.  I will take a look at
>>the AGIF conversion issues and ambiguous error handling issues in the
>>next few days.
>
>There is one conversion issue in the current APNG spec.  If you have not
>read my posts last week, please look through these:
>http://sourceforge.net/mailarchive/message.php?msg_id=38368921
>http://sourceforge.net/mailarchive/message.php?msg_id=38370344

The main image must be padded with transparent pixels to fill out the
desired width and height.  The GIF converter will have sufficient
information to do this from the logical screen size found in the
GIF header.  I checked your example GIF and indeed it does have the
full dimensions in the header.

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]

On Fri, 16 Mar 2007 20:41:55 -0400, Glenn Randers-Pehrson wrote:

>The main image must be padded with transparent pixels to fill out the
>desired width and height.  The GIF converter will have sufficient
>information to do this from the logical screen size found in the
>GIF header.  I checked your example GIF and indeed it does have the
>full dimensions in the header.

I wanted to satisfy the need for concatenating PNGs into one PNG on the
web server, so I was developing such a script.  I expected it could
be done easily if the logical screen size of APNG could be determined
by parameters other than the dimension from IHDR (i.e., frame 0).

--
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:27 AM 3/17/2007 +0900, Nozomu Katoo wrote:

>On Fri, 16 Mar 2007 20:41:55 -0400, Glenn Randers-Pehrson wrote:
>
>>The main image must be padded with transparent pixels to fill out the
>>desired width and height.  The GIF converter will have sufficient
>>information to do this from the logical screen size found in the
>>GIF header.  I checked your example GIF and indeed it does have the
>>full dimensions in the header.
>
>I wanted to satisfy the need for concatenating PNGs into one PNG on the
>web server, so I was developing such a script.  I expected it could
>be done easily if the logical screen size of APNG could be determined
>by parameters other than the dimension from IHDR (i.e., frame 0).

The dimensions in IHDR are pretty easy to find.  You don't need a PNG
chunk decoder.  Just look for the two 4-byte numbers at the
appropriate offset from the beginning of the file.

    signature    length    "IHDR"   width   height
     8 bytes    4 bytes   4 bytes   4 bytes 4 bytes

Glenn

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

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