On Thu, Mar 1, 2012 at 1:11 PM, C M <email@example.com>
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:
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
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
"line" here is my line of datapoints from elsewhere in my app.
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
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.