How to save an animation
45 views
Skip to first unread message
martin....@gmx.net
Apr 14, 2015, 11:54:22 AM4/14/15
to sage-...@googlegroups.com
Hi!
This is a quick poll, triggered by comment 50 of ticket 7298 and also comment 17 of ticket 18176. How would you like to create and save an animation using Sage. Options (perhaps presented in a slightly biased way):
1. Create the animation object, then call the "save" method without any extra arguments, hope to see a download link in the browser or a file system path in the console, and hope the file looks OK using default settings.
2. Start as above, then open the file to view it, and begin adding or changing arguments to "save" till it looks OK. Which means re-downloading from browser, and / or re-loading in your viewer app if it doesn't do so automatically.
3. Use "show" instead of "save" for a preview, tweak arguments to that till I'm satisfied, then change the "show" to a "save".
4. Use "show", tweak till satisfied, then right-click in browser to save, or use "Save (copy) as..." in viewer application.
5. … (feel free to add further options you'd prefer over those presented here.)
The reason I'm asking this is because I feel that most people would prefer to follow approach 3 and 4. Which means everything you can do with "save" should be possible with "show" as well, with the possible exception of the target file name. In the comments pointed out above, Volker Braun was of a different opinion, arguing that "show" should simply show stuff, without too much "confusing" flexibility, while all the power to tweak stuff should only be available for "save". His rationale being the name of the method: if you want to save things at the end of the day, you should be calling "save" not "show".
I'd like to hear your input about which method you'd prefer.
I know I'm all for 4. and have been using that very often. If it's just me, I'll accept that, but somehow I feel that this usage scenario is so obvious that I'd be very surprised to be the only one employing it. Particularly since I've asked some colleagues and they's use the same approach if given these alternatives. @Volker, if you think I misrepresented some of the options, it happened without ill intentions. Please feel free to clarify.
Greetings,
Martin
This is a quick poll, triggered by comment 50 of ticket 7298 and also comment 17 of ticket 18176. How would you like to create and save an animation using Sage. Options (perhaps presented in a slightly biased way):
1. Create the animation object, then call the "save" method without any extra arguments, hope to see a download link in the browser or a file system path in the console, and hope the file looks OK using default settings.
2. Start as above, then open the file to view it, and begin adding or changing arguments to "save" till it looks OK. Which means re-downloading from browser, and / or re-loading in your viewer app if it doesn't do so automatically.
3. Use "show" instead of "save" for a preview, tweak arguments to that till I'm satisfied, then change the "show" to a "save".
4. Use "show", tweak till satisfied, then right-click in browser to save, or use "Save (copy) as..." in viewer application.
5. … (feel free to add further options you'd prefer over those presented here.)
The reason I'm asking this is because I feel that most people would prefer to follow approach 3 and 4. Which means everything you can do with "save" should be possible with "show" as well, with the possible exception of the target file name. In the comments pointed out above, Volker Braun was of a different opinion, arguing that "show" should simply show stuff, without too much "confusing" flexibility, while all the power to tweak stuff should only be available for "save". His rationale being the name of the method: if you want to save things at the end of the day, you should be calling "save" not "show".
I'd like to hear your input about which method you'd prefer.
I know I'm all for 4. and have been using that very often. If it's just me, I'll accept that, but somehow I feel that this usage scenario is so obvious that I'd be very surprised to be the only one employing it. Particularly since I've asked some colleagues and they's use the same approach if given these alternatives. @Volker, if you think I misrepresented some of the options, it happened without ill intentions. Please feel free to clarify.
Greetings,
Martin
William Stein
Apr 14, 2015, 12:11:01 PM4/14/15
to sage-devel
On Tue, Apr 14, 2015 at 8:54 AM, <martin....@gmx.net> wrote:
> Hi!
>
> This is a quick poll, triggered by comment 50 of ticket 7298 and also
> comment 17 of ticket 18176. How would you like to create and save an
> animation using Sage. Options (perhaps presented in a slightly biased way):
>
> 1. Create the animation object, then call the "save" method without any
> extra arguments, hope to see a download link in the browser or a file system
> path in the console, and hope the file looks OK using default settings.
> 2. Start as above, then open the file to view it, and begin adding or
> changing arguments to "save" till it looks OK. Which means re-downloading
> from browser, and / or re-loading in your viewer app if it doesn't do so
> automatically.
> 3. Use "show" instead of "save" for a preview, tweak arguments to that till
> I'm satisfied, then change the "show" to a "save".
> 4. Use "show", tweak till satisfied, then right-click in browser to save, or
> use "Save (copy) as..." in viewer application.
> 5. ... (feel free to add further options you'd prefer over those presented
> Hi!
>
> This is a quick poll, triggered by comment 50 of ticket 7298 and also
> comment 17 of ticket 18176. How would you like to create and save an
> animation using Sage. Options (perhaps presented in a slightly biased way):
>
> 1. Create the animation object, then call the "save" method without any
> extra arguments, hope to see a download link in the browser or a file system
> path in the console, and hope the file looks OK using default settings.
> 2. Start as above, then open the file to view it, and begin adding or
> changing arguments to "save" till it looks OK. Which means re-downloading
> from browser, and / or re-loading in your viewer app if it doesn't do so
> automatically.
> 3. Use "show" instead of "save" for a preview, tweak arguments to that till
> I'm satisfied, then change the "show" to a "save".
> 4. Use "show", tweak till satisfied, then right-click in browser to save, or
> use "Save (copy) as..." in viewer application.
> here.)
>
> The reason I'm asking this is because I feel that most people would prefer
> to follow approach 3 and 4. Which means everything you can do with "save"
> should be possible with "show" as well, with the possible exception of the
> target file name. In the comments pointed out above, Volker Braun was of a
> different opinion, arguing that "show" should simply show stuff, without too
> much "confusing" flexibility, while all the power to tweak stuff should only
> be available for "save". His rationale being the name of the method: if you
> want to save things at the end of the day, you should be calling "save" not
> "show".
>
> I'd like to hear your input about which method you'd prefer.
>
> I know I'm all for 4. and have been using that very often. If it's just me,
> I'll accept that, but somehow I feel that this usage scenario is so obvious
> that I'd be very surprised to be the only one employing it. Particularly
> since I've asked some colleagues and they's use the same approach if given
> these alternatives. @Volker, if you think I misrepresented some of the
> options, it happened without ill intentions. Please feel free to clarify.
I vote for 3, which is the situation with 2d graphics for the last *9
>
> The reason I'm asking this is because I feel that most people would prefer
> to follow approach 3 and 4. Which means everything you can do with "save"
> should be possible with "show" as well, with the possible exception of the
> target file name. In the comments pointed out above, Volker Braun was of a
> different opinion, arguing that "show" should simply show stuff, without too
> much "confusing" flexibility, while all the power to tweak stuff should only
> be available for "save". His rationale being the name of the method: if you
> want to save things at the end of the day, you should be calling "save" not
> "show".
>
> I'd like to hear your input about which method you'd prefer.
>
> I know I'm all for 4. and have been using that very often. If it's just me,
> I'll accept that, but somehow I feel that this usage scenario is so obvious
> that I'd be very surprised to be the only one employing it. Particularly
> since I've asked some colleagues and they's use the same approach if given
> these alternatives. @Volker, if you think I misrepresented some of the
> options, it happened without ill intentions. Please feel free to clarify.
years*, and isn't it the current situation with animations right now.
I'm not sure why you don't clearly say for this poll what the
current situation is, given that one has been able to save animations
for a long time...
I typically use show a lot to figure out the parameters of how I want
something shown, then I put the result in a script and change the show
to a save. I do this a lot. I did exactly this for hours yesterday:
https://github.com/williamstein/rh/blob/master/rh/code/code.sage
1. is the same as 3 with no useful functionality and would be useless to me.
2. what if there is no browser involved?
3. what it is right now, if I understand correctly.
4. what if there is no browser?
-- William
>
> Greetings,
> Martin
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
--
William (http://wstein.org)
martin....@gmx.net
Apr 14, 2015, 12:56:29 PM4/14/15
to sage-...@googlegroups.com
Thanks for your input!
On Tuesday, April 14, 2015 at 6:11:01 PM UTC+2, William wrote:
I vote for 3, which is the situation with 2d graphics for the last *9
years*, and isn't it the current situation with animations right now.
I'm not sure why you don't clearly say for this poll what the
current situation is, given that one has been able to save animations
for a long time...
The current situation is changing rapidly, so what's current now may not be current in ten minutes… The problem is not so much what "save" can do, but whether "show" gives you as much power as "save" does. The only reliable options are 1. and 2. while 3. and 4. are subject to discussion and change. Before ticket 17234 it was possible to pass arguments to "show" which were not available for "save". But the format-specific methods provided those options and even some more. Then that ticket introduced some IPython support and completely changed the way show got routed. A great concept on the whole, but it broke some options which just got restored by my patch for ticket 18176 which is one of those tickets triggering this discussion here. Furthermore, "save" lets one control the file format via the file name extension, so when I get video output in browser working (again) for ticket 7298 I'd like to offer some choice between formats for "show" as well. But Volker argued against a format control parameter, and removed file name parameters from several show methods which used to have them.
1. is the same as 3 with no useful functionality and would be useless to me.
2. what if there is no browser involved?
Then you'd overwrite the same file on disk and see whether that updates your viewer automatically or not.
3. what it is right now, if I understand correctly.
This option has not been usable between #17234 and #18176 if you were using a custom frame rate. And it's still not possible at all for proper video formats like Theora or WebM, and likely won't be until I get #7298 implemented my way, ready for inclusion and actually included this time around, because we currently have no in-browser preview for these and now format switch to "show".
4. what if there is no browser?
Then maybe my viewer application let's me save the temporary file to a different, more permanent location. Or I use ps to find out its command line, and copy the file name from there. Or I simply know where sage keeps its temporary files, and grab the most recent one from there. But I agree that the latter approaches become somewhat hackish, which is why I only included the “save copy as…” menu item from the viewer application as an alternative to the browser environment solution.
Volker Braun
Apr 14, 2015, 1:38:11 PM4/14/15
to sage-...@googlegroups.com
I'm happy to expose all kinds of options to show() and save() with the exception that:
* save requires a filename, and derives the output type from the filename
* show does not accept a filename, but has another way to control output type if there is more than one (the viewer=... argument in 3d-plots)
The bug in #18176 was precisely that save did not support some options that show did. The only difference in our approaches to fix it was that I didn't have the time to add extra options to save.
PS: I'm not terribly happy with using viewer=... in 2d/(2+1)d plots, a better keyword should be found IMHO. Though thats not really on topic.
William Stein
Apr 14, 2015, 2:55:58 PM4/14/15
to sage-devel
On Tue, Apr 14, 2015 at 10:38 AM, Volker Braun <vbrau...@gmail.com> wrote:
> I'm happy to expose all kinds of options to show() and save() with the
> exception that:
> * save requires a filename, and derives the output type from the filename
> * show does not accept a filename, but has another way to control output
> type if there is more than one (the viewer=... argument in 3d-plots)
> The bug in #18176 was precisely that save did not support some options that
> show did. The only difference in our approaches to fix it was that I didn't
> have the time to add extra options to save.
>
> PS: I'm not terribly happy with using viewer=... in 2d/(2+1)d plots, a
> better keyword should be found IMHO. Though thats not really on topic.
When I'm actually *working* and using thigns, I like actually using
> I'm happy to expose all kinds of options to show() and save() with the
> exception that:
> * save requires a filename, and derives the output type from the filename
> * show does not accept a filename, but has another way to control output
> type if there is more than one (the viewer=... argument in 3d-plots)
> The bug in #18176 was precisely that save did not support some options that
> show did. The only difference in our approaches to fix it was that I didn't
> have the time to add extra options to save.
>
> PS: I'm not terribly happy with using viewer=... in 2d/(2+1)d plots, a
> better keyword should be found IMHO. Though thats not really on topic.
the following horrible approach:
show(g, svg=True)
show(g, png=True)
show(g, threejs=True)
where svg=True means "use svg if possible", etc.
From an implementation perspective (and maybe others) it is ugly.
But from a pure usability perspective it is nice, since you only have
to remember *one* thing, the name of renderer and nothing else (e.g.,
is it viewer= or renderer= or what?).
If one did
show(g, svg=True, png=True)
for some reason, there would be some arbitrary and defined rule for
breaking ties.
-- William
>
>
> On Tuesday, April 14, 2015 at 5:54:22 PM UTC+2, martin....@gmx.net wrote:
>>
>> Hi!
>>
>> This is a quick poll, triggered by comment 50 of ticket 7298 and also
>> comment 17 of ticket 18176. How would you like to create and save an
>> animation using Sage. Options (perhaps presented in a slightly biased way):
>>
>> 1. Create the animation object, then call the "save" method without any
>> extra arguments, hope to see a download link in the browser or a file system
>> path in the console, and hope the file looks OK using default settings.
>> 2. Start as above, then open the file to view it, and begin adding or
>> changing arguments to "save" till it looks OK. Which means re-downloading
>> from browser, and / or re-loading in your viewer app if it doesn't do so
>> automatically.
>> 3. Use "show" instead of "save" for a preview, tweak arguments to that
>> till I'm satisfied, then change the "show" to a "save".
>> 4. Use "show", tweak till satisfied, then right-click in browser to save,
>> or use "Save (copy) as..." in viewer application.
>> here.)
>>
>> The reason I'm asking this is because I feel that most people would prefer
>> to follow approach 3 and 4. Which means everything you can do with "save"
>> should be possible with "show" as well, with the possible exception of the
>> target file name. In the comments pointed out above, Volker Braun was of a
>> different opinion, arguing that "show" should simply show stuff, without too
>> much "confusing" flexibility, while all the power to tweak stuff should only
>> be available for "save". His rationale being the name of the method: if you
>> want to save things at the end of the day, you should be calling "save" not
>> "show".
>>
>> I'd like to hear your input about which method you'd prefer.
>>
>> I know I'm all for 4. and have been using that very often. If it's just
>> me, I'll accept that, but somehow I feel that this usage scenario is so
>> obvious that I'd be very surprised to be the only one employing it.
>> Particularly since I've asked some colleagues and they's use the same
>> approach if given these alternatives. @Volker, if you think I misrepresented
>> some of the options, it happened without ill intentions. Please feel free to
>> clarify.
>>
>> Greetings,
>> Martin
>
>>
>> The reason I'm asking this is because I feel that most people would prefer
>> to follow approach 3 and 4. Which means everything you can do with "save"
>> should be possible with "show" as well, with the possible exception of the
>> target file name. In the comments pointed out above, Volker Braun was of a
>> different opinion, arguing that "show" should simply show stuff, without too
>> much "confusing" flexibility, while all the power to tweak stuff should only
>> be available for "save". His rationale being the name of the method: if you
>> want to save things at the end of the day, you should be calling "save" not
>> "show".
>>
>> I'd like to hear your input about which method you'd prefer.
>>
>> I know I'm all for 4. and have been using that very often. If it's just
>> me, I'll accept that, but somehow I feel that this usage scenario is so
>> obvious that I'd be very surprised to be the only one employing it.
>> Particularly since I've asked some colleagues and they's use the same
>> approach if given these alternatives. @Volker, if you think I misrepresented
>> some of the options, it happened without ill intentions. Please feel free to
>> clarify.
>>
>> Greetings,
>> Martin
>
Sébastien Labbé
Apr 14, 2015, 3:04:28 PM4/14/15
to sage-...@googlegroups.com
The option 3 is the one I like to use:
3. Use "show" instead of "save" for a preview, tweak arguments to that till I'm satisfied, then change the "show" to a "save".
Sébastien
Volker Braun
Apr 14, 2015, 3:21:22 PM4/14/15
to sage-...@googlegroups.com
On Tuesday, April 14, 2015 at 8:55:58 PM UTC+2, William wrote:
From an implementation perspective (and maybe others) it is ugly.
But from a pure usability perspective it is nice, since you only have
to remember *one* thing, the name of renderer and nothing else
Yes, good. In fact, I would like to go one step further. The output type control for "show" should be more about what the user wants to achieve, not the technical minutiae of file type that can achieve it. That is, "show" should be more about raster vs. vector graphics, lossy vs. lossless compressed, raytraced vs. rasterized, .... You shouldn't have to know the difference between animated gif and apng to use animate().show(). So in that sense the show() interface should be less detailed. Also, show() should ignore the specified format if it cannot be satisfied; If you don't have java then you'll get something else and not jmol.
Saving, on the other hand, is about creating files according to particular specs that you want to use elsewhere. So there you really need to know whether you want a gif or a png. And if we don't find the tools to generate webm on your system then trying to save as webm should be a hard error, and not save an animated gif instead.
martin....@gmx.net
Apr 14, 2015, 4:58:16 PM4/14/15
to sage-...@googlegroups.com
On Tuesday, April 14, 2015 at 9:21:22 PM UTC+2, Volker Braun wrote:
The output type control for "show" should be more about what the user wants to achieve, not the technical minutiae of file type that can achieve it. That is, "show" should be more about raster vs. vector graphics, lossy vs. lossless compressed, raytraced vs. rasterized, ....
I don't mind additional arguments with a higher level of abstraction. But if you want "show" as a preview to "save" (as in methods 3 and 4), then "show" should support all the options "save" does. So that when switching the method name we don't have to translate all the keyword arguments. I guess that when specific low-level format requirements are stated, then failing to satisfy them should be an error for the sake of simplicity and consistency, but on this point my opinion is not as strong as on supporting all "save" arguments for "show".
Volker Braun
Apr 14, 2015, 5:18:24 PM4/14/15
to sage-...@googlegroups.com
On Tuesday, April 14, 2015 at 10:58:16 PM UTC+2, martin....@gmx.net wrote:
I don't mind additional arguments with a higher level of abstraction. But if you want "show" as a preview to "save" (as in methods 3 and 4), then "show" should support all the options "save" does.
Typically your UI doesn't have viewers for all kinds of files that you might be able to produce, so it just can't. It might not even make sense, e.g. save() can also save python pickles. Why should show() have a switch to distinguish between gif87a and gif89a? They look the same. If for some reason only one of them can be shown by the UI then the right one should be picked automatically.
If you want to micromanage the output down to a level that makes no visual difference then IMHO you should just save the particular file that you want. With #17942 you could then even immediately display the file (assuming that the UI can) using graphics.save('filename.png').show()
Reply all
Reply to author
Forward
0 new messages