pylab image_masked is broken #6509

Activity

1. efiring

   added this to the 2.0 (style change major release)This milestone has been deleted milestone on May 31, 2016
2. efiring commented on May 31, 2016

   

   efiring

   on May 31, 2016

   Last edited by efiring

   MemberAuthor

   More actions

   attn: @mdboom
   For the first plot, the problem is that support for over and under values has been lost when image interpolation is anything other than 'none' or 'nearest'.

   cmap = get_cmap('viridis')
   cmap.set_over('c')
   cmap.set_under('r')
   fig, axs = subplots(ncols=3)
   axs[0].imshow(randn(20,20), vmin=-0.5, vmax=0.5, cmap=cmap, interpolation='bilinear')
   axs[1].imshow(randn(20,20), vmin=-0.5, vmax=0.5, cmap=cmap, interpolation='none')
   axs[2].imshow(randn(20,20), vmin=-0.5, vmax=0.5, cmap=cmap, interpolation='nearest')
3. efiring commented on May 31, 2016

   

   efiring

   on May 31, 2016

   MemberAuthor

   More actions

   For the second plot, BoundaryNorm is not broken, so it looks like the problem is that imshow is no longer recognizing the integer indexing into the colormap LUT.

   from matplotlib.colors import BoundaryNorm
   bn = BoundaryNorm([-1, -0.5, -0.2, 0, 0.2, 0.5, 1], ncolors=256, clip=False)
   xx = np.linspace(-2, 2, 100).reshape(10, 10)
   fig, (ax0, ax1) = subplots(ncols=2)
   ax0.pcolormesh(xx, norm=bn, cmap=cmap)
   ax1.imshow(xx, norm=bn, cmap=cmap)
4. efiring

   added

   status: confirmed bug

   Release criticalFor bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.

   on May 31, 2016
5. mdboom

   self-assigned this

   on Jun 1, 2016
6. tacaswell

   self-assigned this

   on Jun 14, 2016
7. tacaswell commented on Jun 14, 2016

   

   tacaswell

   on Jun 14, 2016

   Member

   More actions

   It seems that _image.resample is clipping everything to [0, 1], independent of input type (which is why we moved the normalization first to begin with). This causes 2 problems. The first is that the BoundaryNorm mappings all end up being 1 or 0 and second is it cuts off the over/under. I have made some progress on the second issue.

   

   which is generated off of the commit in #6581
8. mdboom commented on Jun 21, 2016

   

   mdboom

   on Jun 21, 2016

   Member

   More actions

   I think @tacaswell's solution in #6581 is actually pretty elegant and doesn't add much runtime overhead.
9. tacaswell commented on Jun 21, 2016

   

   tacaswell

   on Jun 21, 2016

   Member

   More actions

   It still completely fails on BoundaryNorm and NoNorm use cases though.
10. mdboom commented on Jun 21, 2016

    

    mdboom

    on Jun 21, 2016

    Member

    More actions

    Did you see my comment in #6581 about a fix for BoundaryNorm?
11. efiring commented on Jun 21, 2016

    

    efiring

    on Jun 21, 2016

    MemberAuthor

    More actions

    @mdboom, does image handling always go through _ImageBase._make_image()? If so, I think the integer indexing case can be handled by doing the colormapping immediately when the norm returns integers, and then proceeding as if an RGBA array had been supplied from the start. This seems to me to be in the spirit of the integer indexing.
    I can try implementing this later today, unless someone else would like to do so, or a flaw in the strategy becomes clear.
12. mdboom commented on Jun 21, 2016

    

    mdboom

    on Jun 21, 2016

    Member

    More actions

    If so, I think the integer indexing case can be handled by doing the colormapping immediately when the norm returns integers, and then proceeding as if an RGBA array had been supplied from the start. This seems to me to be in the spirit of the integer indexing.

    Doesn't that leaves us right back where we started? Interpolating in RGBA space and all of the incorrect results that that causes?
13. efiring commented on Jun 21, 2016

    

    efiring

    on Jun 21, 2016

    MemberAuthor

    More actions

    @mdboom, only in the case of integer colormap indexing, where interpolation other than none or nearest is not really appropriate anyway--so I don't see any real problem. It would be the same as the present case with RGBA input, right?
14. mdboom commented on Jun 21, 2016

    

    mdboom

    on Jun 21, 2016

    Member

    More actions

    I see your point. I'm sure there are some users that pass in integers representing continuous data anyway.

    Seems like a reasonable compromise -- if ints passed in, map to rgba first. If floats, interpolate then color map.
15. efiring commented on Jun 21, 2016

    

    efiring

    on Jun 21, 2016

    MemberAuthor

    More actions

    To be sure it is clear: what we are talking about is the dtype after application of the norm, so the integer case is encountered only when BoundaryNorm is used (on a floating point or integer array), or NoNorm on an integer array. In other words, this is the case where the user is saying "use exactly these colors that I specify by indexing into the LUT". One could even go so far as to warn when the requested interpolation is not "none" or "nearest" in such a case, but I think that would be overkill.
16. QuLogic commented on Jul 10, 2016

    

    QuLogic

    on Jul 10, 2016

    Member

    More actions

    I believe this was fixed by #6581.
17. QuLogic

    closed this as completedon Jul 10, 2016