On Thu, Mar 1, 2012 at 1:11 PM, C M <cmpyt...@gmail.com> wrote:
>
> Yeah, there are better ways to do that, somewhat. The problem with the
>> proposed solution is that it relies on non-public APIs, which are can be
>> subject to change without deprecation. Instead, I would have created the
>> figimage object with a particular transform object that would have placed
>> it at the appropriate data points.
>
>
> Maybe your or someone from this list can help me understand more about
> this. So, if I take the code that I have adapted to my purposes, there are
> questions I have about it:
>
> # constants
> dpi = 72; imageSize = (32,32)
> # read in our png file
> im = image.imread('redX_10.png')
>
> So far, so good--just setting the dpi and getting the image.
>
> fig = self.figure
> ax = self.subplot
> ax.get_frame().set_alpha(0)
>
>
>
Does the current version of Matplotlib require the frame be set to fully
> transparent? I need a white canvas, so I think I'd rather not do that.
>
>
I think this is technically because of the use of figimage. Any axes that
are created would get plotted above the figimage. I suppose one could
manually set the zorder to a high enough number to make sure it stays on
top.
> # translate point positions to pixel positions
> # figimage needs pixels not points
> line = self.line_collections_list[0][0]
>
> "line" here is my line of datapoints from elsewhere in my app.
>
> line._transform_path()
> path, affine =
> line._transformed_path.get_transformed_points_and_affine()
> path = affine.transform_path(path)
>
> I have no understanding of the purpose of the previous three lines. Can
> someone give me a quick explanation?
>
>
The transforms framework translates coordinates from one system to
another. There are multiple coordinate systems within a mpl figure. data,
axes and figure are the three main "reference frames". I think the first
line is effectively useless (but due to caching has no impact on
performance). The second line would translate the coordinates stored in
"line" into figure-relative coordinates, and also provide a special object
for doing affine transformations. The point of that step, IIUC, is to do a
special handling of curves (either the line data itself has curves, or the
coordinate tranformation has curves). Consider the case of drawing a
straight line from a Lat/Lon coordinate on a map to another Lat/Lon
coordinate (so, there are only two points in "line"). Now, that line may
not be straight depending upon the map projection used, so the final line
may need many more points to represent it correctly in a transformed
projection. Again, I am not an expert here, so it is quite likely that I
mixed something up.
> for pixelPoint in path.vertices:
> # place image at point, centering it
>
> fig.figimage(im,pixelPoint[0]+80,pixelPoint[1]+180,origin="upper")
>
> This is just a way to put the image somewhere on my canvas to see it, so
> these offsets are just for this exercise.
>
> I should state that if I do it this way, the images appear on the canvas
> but are NOT repositioned in data coordinates (and they should be)--which is
> probably just Ben's point, right?
>
>
Right. It should be technically feasible to just simply tell figimage to
use a different transformation object, but this might have implications
elsewhere. I am very hazy in this part of mpl.
Cheers!
Ben Root
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
