#12827: Expand Animation class to accept more graphics types
-----------------------------------------+----------------------------------
Reporter: niles | Owner: jason, was
Type: enhancement | Status: new
Priority: major | Milestone: sage-5.0
Component: graphics | Resolution:
Keywords: animate, graphics, 3D | Work issues: docstrings, testing,
think about img protocol
Report Upstream: N/A | Reviewers:
Authors: Niles Johnson | Merged in:
Dependencies: | Stopgaps:
-----------------------------------------+----------------------------------
Comment (by nbruin):
Replying to [comment:4 niles]:
> ...
> Maybe this is the wrong way to go about it though, since the `save()`
and `show()` methods of the resulting `Image` object would re-save the
image to a file, wasting a lot of time. `Image` also has the capability
to read an image from a stream or a buffer, but I don't know how to create
such things from Sage's graphics objects.
Well, in some cases this would be the best thing we have available. In the
case of 3D, for instance, the rendering is done with the external program
`tachyon`, which get a scene description in a file and saves a bitmap into
another file. So in that case, going through an Image object for animate
is very wasteful.
Googling shows that `matplotlib` can be used to produce the bitmap in-
memory and directly feed into Image. Incidentally, if those files are
written in `/tmp` (or any `tmpfs` filesystem), the files likely never hit
disk. They'll just live in memory-based buffers.
> A more rudimentary compromise might be to have a method which saves the
image and returns the system path to the image:
>
> {{{
> def img(self, filename, *args, **kwds):
> self.save(filename=filename, *args, **kwds)
> return filename
> }}}
I personally like the rule that routines used for their side-effect do not
return a value. Especially when you have to specify the filename anyway,
it doesn't really make sense to return it. A "success" return value could
work, but raising an exception on failure is more pythonic.
> At this stage, I've given three different possible `img` methods, and I
can see now how each one establishes a different protocol. Since this
ticket is probably not the right place to try to establish a protocol, I
think I'll try to use a different name. I'm really having a hard time
warming up to the term "bitmap" though. Wikipedia explains to me that it
is essentially correct, although the image types we would use by default,
like JPG, PNG, TIFF, are ''compressed'' bitmap images. What do you think
of `save_image` instead?
I think it's an improvement over "save", because to me "save" indicates a
reversible operation (via "load"). In the case here, the bitmap is a
different kind of object from which the original object cannot be
reconstructed. I think save_as_image is even clearer, but it's also longer
and has more underscores.
In general, people would differentiate "bitmap" and "vector graphics"
formats inside "image" formats (i.e., jpg, png versus pdf, ps, svg,
disregarding that the latter can also contain bitmap information). On the
application side, GIMP versus Inkscape or Photoshop versus
Acrobat/Illustrator.
For 3D scenes we currently have no way of creating vector graphics
representations, although those would be quite useful for producing print-
quality schematics. matplotlib can create excellent vector graphics as
well as bitmaps.
If `save_as_image` supports a format specifier (and/or derives a default
from inspecting the filename for known extensions) that also supports
"eps, svg, inkscape" then I think it's a very good name. Not all object
have to support all formats of course. If you are going to categorically
restrict to bitmap formats (compressed or not), I think sage_as_bitmap is
better.
Look at how matplotlib solves this problem. Staying compatible with them
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12827#comment:5>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
