Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork8.1k
Rewrite of image infrastructure#5718
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Changes fromall commits
cf11aea3b7d1bbc9cae504a053020aa222a0793aa21384c7c9148c7f820479efad84c864e84ea0be04c0a8643f15df79f0b436f1adfbc39d9d3b468f9d85347b32cd86e60ebfdc66ed07cccfb35073f6e625e80ac778cfc9fe6658d61ac2ab3318fdffbbf05fbb55c834d6cc84c5a3bf944820883f4bc9d5030a455c1abbfe376c45266fde9285c3ae2b2bbeb8946834e43c8b8665697d21a6ed2d2a1266d3518a0b8d6930f43f68cd0e7e0e62832fe7d54d53e532e1cfad8d9e52c26f0469ab7b391f0889365c17f2f3759827d1f5be66debd521cdd6b22a5fff1d66da6c00bc9b2425File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading.Please reload this page.
Jump to
Uh oh!
There was an error while loading.Please reload this page.
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,8 @@ | ||
| Change in the ``draw_image`` backend API | ||
| ---------------------------------------- | ||
| The ``draw_image`` method implemented by backends has changed its interface. | ||
| This change is only relevant if the backend declares that it is able | ||
| to transform images by returning ``True`` from ``option_scale_image``. | ||
| See the ``draw_image`` docstring for more information. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| Improved image support | ||
| ---------------------- | ||
| Prior to version 2.0, matplotlib resampled images by first applying | ||
| the color map and then resizing the result. Since the resampling was | ||
| performed on the colored image, this introduced colors in the output | ||
| image that didn't actually exist in the color map. Now, images are | ||
| resampled first (and entirely in floating-point, if the input image is | ||
| floating-point), and then the color map is applied. | ||
| In order to make this important change, the image handling code was | ||
| almost entirely rewritten. As a side effect, image resampling uses | ||
| less memory and fewer datatype conversions than before. | ||
| The experimental private feature where one could "skew" an image by | ||
| setting the private member ``_image_skew_coordinate`` has been | ||
| removed. Instead, images will obey the transform of the axes on which | ||
| they are drawn. |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,6 +1,3 @@ | ||
| """ | ||
| For the backends that supports draw_image with optional affine | ||
| transform (e.g., agg, ps backend), the image of the output should | ||
| @@ -24,22 +21,15 @@ def get_image(): | ||
| return Z | ||
| if 1: | ||
| # image rotation | ||
| fig, ax1= plt.subplots(1,1) | ||
| Z = get_image() | ||
| im1 = ax1.imshow(Z, interpolation='none', | ||
Member There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. sigh... did we seriously have this private member documented in our examples? That kinda sends mixed messages to our users, doesn't it? MemberAuthor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. Yes, it does. Not much we can do except stop doing that going forward. On the up side, the experimental method is also completely redundant to the more flexible and consistent-with-everything-else transforms infrastructure, so this isn't a regression in terms of available functionality. | ||
| origin='lower', | ||
| extent=[-2, 4, -3, 2], clip_on=True) | ||
| trans_data2 = mtransforms.Affine2D().rotate_deg(30) + ax1.transData | ||
| im1.set_transform(trans_data2) | ||
| @@ -53,13 +43,3 @@ def imshow_affine(ax, z, *kl, **kwargs): | ||
| ax1.set_xlim(-3, 5) | ||
| ax1.set_ylim(-4, 4) | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -490,7 +490,7 @@ namespace agg | ||
| fg_ptr = (const value_type*)base_type::source().next_y(); | ||
| } | ||
| fg= color_type::downshift(fg,image_filter_shift); | ||
Member There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. Has this been fed back to Agg? MemberAuthor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. Yes, though I've received no response. | ||
| if(fg < 0) fg = 0; | ||
| if(fg > color_type::full_value()) fg = color_type::full_value(); | ||
| span->v = (value_type)fg; | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -171,14 +171,18 @@ def draw_image(self, gc, x, y, im): | ||
| # bbox - not currently used | ||
| if _debug: print('%s.%s()' % (self.__class__.__name__, _fn_name())) | ||
| if sys.byteorder == 'little': | ||
| im = im[:, :, (2, 1, 0, 3)] | ||
| else: | ||
| im = im[:, :, (3, 0, 1, 2)] | ||
Member There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. Do we need to check that image is RGBA (I am assuming that that is what the 4 bytes that are getting swapped around are for, right)? I am also going to assume that the swaps are correct. I have never been able to remember byte order stuff correctly. MemberAuthor There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others.Learn more. RGBA is always passed to draw_image (it's the responsibility of the other layers, not the backend, to make it so). This should be documented as well in I checked the swaps on both x86_64 and an old PPC Mac-running-Linux that I keep around to check byte order issues. Cairo is the only backend we have that requires ARGB in native byte order like this. | ||
| surface = cairo.ImageSurface.create_for_data( | ||
| memoryview(im.flatten()), cairo.FORMAT_ARGB32, im.shape[1], im.shape[0], | ||
| im.shape[1]*4) | ||
| ctx = gc.ctx | ||
| y = self.height - y -im.shape[0] | ||
| ctx.save() | ||
| ctx.set_source_surface(surface,float(x), float(y)) | ||
| if gc.get_alpha() != 1.0: | ||
| ctx.paint_with_alpha(gc.get_alpha()) | ||
| else: | ||
Uh oh!
There was an error while loading.Please reload this page.