#16571: APNG (Animated PNG) for animations
-------------------------------------+-------------------------------------
Reporter: gagern | Owner:
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.3
Component: graphics | Resolution:
Keywords: | Merged in:
Authors: Martin von Gagern | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/gagern/ticket/16571 | f4a242733b301b813f316d8661485b77ad520ee7
Dependencies: #16570, #16645 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by gagern):
Replying to [comment:7 niles]:
> I'm slightly nervous about the long-term stability of the apng format
[…]
I'm less worried about stability and more worried about market share. If
one day MNG gets widely adopted, it might make APNG superfluous. But I
don't see that coming soon.
> * I would expect a method named `APngAssembler.frame` to return a frame.
Would `add_frame` or `append_frame` or something similar be a better name
for this?
Fine with me. I will include it in my next commit. I guess that in the
long run, I might also add a method which I'd have called `fallback` or
`still`, which can be used to set the fallback image to something other
than the first frame. Would you prefer `set_still` or `add_fallback` or
something like this?
> * Since the docstring of `APngAssembler.__init__` won't appear in the
manual, it might be more useful to move that information to the class
docstring.
Oh, I hadn't realized that. Sure, will move that.
> * most of the `APngAssembler` methods are missing doctests.
Mentioned that problem in comment:3. I can try to come up with some
doctests if you insist, but they'd be pretty ugly to read.
By the way, should I prepend a `_` to all my internal methods?
> * Not sure if it's part of this ticket, but I really think
[http://git.sagemath.org/sage.git/commit/?id=a60fe0b14aa4094c86c5efb387f9fd5a9706a218
converting a generator to a list when rendering frames] is a bad idea.
When there are lots of very large frames, this becomes becomes time and
memory intensive. What advantage do you see?
Quoting from the commit message of that commit: “The APNG pipeline
requires the number of frames up front”. I guess I could also save the
*number* of frames, instead of the frames themselves. Would you prefer
that? It would even be consistent with the doctest.
An inferior alternative would be copying what `graphics_array()` does:
{{{
frame_list = list(self._frames)
n = len(frame_list)
}}}
There you also have to maintain the list of all frames in memory, although
arguably only for the duration of the method call. What I consider even
more harmful, however, is the fact that the frames will be generated
multiple times. In my opinion, a generator should only be traversed once
for the workflow from construction to APNG output, and that one occurrence
should be when building the PNGs.
--
Ticket URL: <http://trac.sagemath.org/ticket/16571#comment:8>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
