matplotlib-devel Mailing List for matplotlib

Jae-Joon Lee wrote:
> What I have in my mind is to extend the "extent" keyword of the imshow
> and make it optionally take a tuple of 6 numbers, which are (x1,
> x_lrc, x2, y1, y_lrc, y2).
> x1, x2, y1, y2 are same as the original "extent", and the (x_lrc,
> y_lrc) represent the coordinate of the lower-right corner of the
> image.
> 
It's not clear to me if this proposal lets one specify any arbitrary 
affine transformation. Does it?
> Any thought?
> 
In general -- very nice. Thanks.
In specific, I think the way you have already implemented things is 
sufficient. I think if a user can write a little helper function (as in 
your demo) to avoid a dumbed-down API being part of MPL, that would be 
best. Anyone specifying their own affine transform is probably going to 
want a pretty precise level of control, anyway. (Of course if your 
extent keyword proposal is already a general purpose API, then please 
ignore this comment.)
-Andrew

I change the api to support an arbitrary affine transform. The current api is
 def draw_image(self, gc, x, y, im, dx=None, dy=None, transform=None):
dx, dy is the width and height of the image, i.e.,
The 4 edge points of the image will be
 (x, y), (x+dx, y), (x+dx, y+dy), (x, y+dy) after transformed by *transform*.
And if transform involves rotation or skew, the image should also be
rotated and skewed.
Attached is a small example to utilized this functionality.
Note that it only works with the ps-backend.
I personally don't have much use case for rotated or skewed images.
So, it would be great if others can suggest some user-space api.
What I have in my mind is to extend the "extent" keyword of the imshow
and make it optionally take a tuple of 6 numbers, which are (x1,
x_lrc, x2, y1, y_lrc, y2).
x1, x2, y1, y2 are same as the original "extent", and the (x_lrc,
y_lrc) represent the coordinate of the lower-right corner of the
image.
So, the imshow in the attached example will become somthing like
im = plt.imshow(Z, interpolation='nearest', cmap=cm.jet,
 origin='lower', extent=[-2, 3, 4, -3, -2, 2])
And, the transformation will be calculated internally by the Image class.
Any thought?
-JJ
On Wed, Dec 16, 2009 at 3:41 PM, Andrew Straw <str...@as...> wrote:
> Jae-Joon Lee wrote:
>>
>> On Wed, Dec 16, 2009 at 12:59 PM, Jouni K. Seppänen <jk...@ik...> wrote:
>>
>>>
>>> While the backend API is being changed, would it be similarly easy to
>>> support arbitrary affine transformations? It would make the API more
>>> symmetric, since many other draw_* methods take an affine
>>> transformation, and I guess at least the PS and PDF backends could
>>> easily support this.
>>>
>>>
>>
>> Yes, supporting arbitrary affine transform would not be difficult. On
>> the other hand, I'm not sure if that feature is practically useful,
>> assuming that other rasterizing backend won't implement it. I'll think
>> about it.
>
> I second the notion that affine transformations on images would be useful.
> There are a lot of things one can do with this, such as make
> pseudo-perspective projections of texture-mapped rectangles. This is exactly
> one of the things that I routinely do in Inkscape.
>
> I'm reasonably sure Cairo supports arbitrary affine transformations when
> drawing image data -- I don't know about Agg.
>
> -Andrew
>

On Wed, Dec 16, 2009 at 4:45 PM, Joey Wilson <dou...@gm...> wrote:
> Let me say why I think this feature is so essential. Anyone who is in
> research or academia knows that figures often need to be edited when a
> publication comes back from peer review. It's already happened to me many
> times, and I've learned that I absolutely have to save my figures for later
> editing to save myself a lot of time. Some people have argued that a script
> that generates the plots/figures should be saved, and that if you need to
> edit the figure, just re-run the script. The problem with this argument is
> that scientific plots often take hours, days, or even weeks of computation
> to generate. For example, generating a bit-error-rate curve in
> communications takes days. Therefore, always re-running from a script is
> just not practical.
Ignoring the issue of having saved matplotlib figures, I'd argue you
should separate the parts of the code that do computation from those
that do plotting into separate scripts. Is there anything keeping you
from saving all of the results from the computation into (for
instance) a NetCDF file? Then the plotting script can just read in
the file and do the plotting. This is exactly how my workflow is set
up. I'd be happy to address any concerns you see with doing things
this way.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

2009年12月16日 Joey Wilson <dou...@gm...>:
> Does anyone know the status of development for Matplotlib persistent figure
> saving? I would like to be able to save the figures from matplotlib in an
> editable form, without flattening down to an image file. The closest thing
> to this right now is the SVG output, but a native mpl format would be
> better. I need to be able to save the figure, so that later it can be
> loaded, edited, and re-saved. I know that this topic has been somewhat
> discussed in the past, but I believe it is desperately needed, so I thought
> I would bring it back up.
> Let me say why I think this feature is so essential. Anyone who is in
> research or academia knows that figures often need to be edited when a
> publication comes back from peer review. It's already happened to me many
> times, and I've learned that I absolutely have to save my figures for later
> editing to save myself a lot of time. Some people have argued that a script
> that generates the plots/figures should be saved, and that if you need to
> edit the figure, just re-run the script. The problem with this argument is
> that scientific plots often take hours, days, or even weeks of computation
> to generate. For example, generating a bit-error-rate curve in
> communications takes days. Therefore, always re-running from a script is
> just not practical.
> Now, I understand that resources are limited, so I would be willing to raise
> some money to get this feature added to Matplotlib. It's desperately needed
> by myself and many others in the community. I would really like to
> completely replace Matlab with Python,Scipy, and Matplotlib. MPL is an
> excellent tool, and it could be even more useful/professional with the
> addition of a figure save feature.
> Any thoughts?
Leaving entirely aside any question of persistence, do you find
matplotlib plots to be modifiable in the ways you want? I find for
anything beyond minor changes of axes, I end up rerunning my plotting
command anyway - for example, I suppose it's possible to change a line
on an existing plot from red to black, but I just rerun the plotting
command. What about adding/removing error bars? changing the number of
bins, range, or starting position of your histogram? plotting the
square root instead of the logarithm of the image values? removing
bogus data points (or adding back in points you I previously removed)?
It seems to me that all of these things require me to keep the
original data around.
Since that's the case, I usually generate my plots in one of two ways:
either I just write a script that runs the calculation and generates
the plot, or I write one script to generate the data and save it to
disk, and another to plot the data from disk. This is sometimes mildly
annoying when a script is just a bit slow, but not enough to warrant
saving the data to disk. In those cases if I must I can run the script
under ipython and modify the plot, then save out the modifications to
a script.
Now, if you want a very-low-effort way to save your data to disk, I
agree that would be valuable to have, but there are, in ascending
order of complexity and power, the native numpy data format, pyfits,
and pytables/pyhdf.
Anne