matplotlib-devel Mailing List for matplotlib

On Wed, Jul 13, 2011 at 1:58 PM, Benjamin Root <ben...@ou...> wrote:
>
> Most documentation work that seems to remain are Animation module (and I
> would love to find out if there is some way to embed a video using sphinx)
Just following up on this statement I have made. I did find an extension
module (MIT-licensed) that would allow one to embed YouTube video links in
the sphinx docs. Maybe we might want to create a matplotlib account on
youtube and make various animations available through that?
http://countergram.com/youtube-in-rst
Ben Root

On 07/14/2011 07:33 AM, Martin Teichmann wrote:
> Hello List,
> Hello Michael, Hello Jae-Joon,
>
> Michale wrote:
>> It looks like overriding "draw_unsampled_image" is the wrong thing to do
>> here, though.
> JJ wrote:
>> Overriding this behavior (which I guess is the case of you current ShearImage
>> implementation. Please correct me if I'm wrong) won't be acceptable.
>
> I don't know where to go from here. We could:
>
> - make make_image actually draw the image. This would be a break in
> the API.
> - introduce a new method (_draw_sampled_image seems like a good name)
> that does that. That indirectly changes the API since make_image won't
> be called anymore, overriding it doesn't make a difference anymore.
I think either of these is ok. make_image is not really in the public 
API anyway -- I know it doesn't have a preceding underscore, but I think 
this code may predate that convention. If you add _draw_sampled_image, 
I would remove make_image to eliminate confusion.
> - Rewrite matplotlib from scratch in Java (just kidding)
We generally, consider patches in first-come-first-serve order, so I 
would recommend taking whichever approach could be completed sooner ;)
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Hello List,
Hello Michael, Hello Jae-Joon,
Michale wrote:
> It looks like overriding "draw_unsampled_image" is the wrong thing to do
> here, though.
JJ wrote:
> Overriding this behavior (which I guess is the case of you current ShearImage
> implementation. Please correct me if I'm wrong) won't be acceptable.
I was (and am) aware of this problem, this is what I meant when I wrote
"I should have overridden make_image". That's exactly the point:
there are two ways to make the image: one using Agg and fancy interpolations,
the other one to use the backend and have the interpolation "none".
The former is done by make_image, the latter by _draw_unsampled_image.
It would have been correct for me to override make_image, unfortunately
this was not possible since make_image only makes the image, it is then
drawn by _AxesImageBase.draw, which unfortunately is not flexible enough,
as it does not allow for the image to be drawn elsewhere than the
origin of the axes, which is not necessarily what I want.
This is why I abused _draw_unsampled_image. I am aware that this is
an abuse, but my code was only inteded as demonstration code.
I don't know where to go from here. We could:
- make make_image actually draw the image. This would be a break in
the API.
- introduce a new method (_draw_sampled_image seems like a good name)
that does that. That indirectly changes the API since make_image won't
be called anymore, overriding it doesn't make a difference anymore.
- Rewrite matplotlib from scratch in Java (just kidding)
I'm looking forward to your ideas.
Greetings
Martin
-- 
Fachbereich Physik
Freie Universität Berlin
Arnimallee 14
14195 Berlin
+49 30 6392 1234