You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently interpolate images by mapping the raw data into RGB, then interpolate that RGB (using any number of algorithms) to produce the final result. This can result in colors that don't actually appear in the colormap to be in the final result.
We should instead change the order of operations so that the interpolation happens on the raw data (in floating-point space), then the image is color mapped.
All that's left, then, is the Python side of things, and #5602 offers some guidance as to where to insert the floating-point interpolation operations. Ideally, the matplotlib._image.Image class on the C++ side should go away. It predates Numpy when we needed a class just to store the image data. Now, a Numpy array will do, and it would be better to just have functions on the C++ side for interpolation and coloring.
"aggravate"? You get a free beer from me at the next SciPy meeting!
On Wed, Dec 2, 2015 at 1:38 PM, Michael Droettboom <[email protected]
wrote:
I think I have the Agg part of this figured out. See mdboom/aggravate
All that's left, then, is the Python side of things, and #5602 #5602 offers some guidance
as to where to insert the floating-point interpolation operations. Ideally,
the matplotlib._image.Image class on the C++ side should go away. It
predates Numpy when we needed a class just to store the image data. Now, a
Numpy array will do, and it would be better to just have functions on the
C++ side for interpolation and coloring.
—
Reply to this email directly or view it on GitHub #5490 (comment)
.
One advantage of rewriting the image interpolation as a purely functional interface is that it was really easy to add OpenMP support to take advantage of multiple cores.
Activity
mdboom commentedon Dec 2, 2015
I think I have the Agg part of this figured out. See http://github.com/mdboom/aggravate
All that's left, then, is the Python side of things, and #5602 offers some guidance as to where to insert the floating-point interpolation operations. Ideally, the
matplotlib._image.Imageclass on the C++ side should go away. It predates Numpy when we needed a class just to store the image data. Now, a Numpy array will do, and it would be better to just have functions on the C++ side for interpolation and coloring.WeatherGod commentedon Dec 2, 2015
"aggravate"? You get a free beer from me at the next SciPy meeting!
On Wed, Dec 2, 2015 at 1:38 PM, Michael Droettboom <[email protected]
mdboom commentedon Dec 2, 2015
Roget's says it's a synonym for "magnify".
WeatherGod commentedon Dec 2, 2015
Yes, it works on so many levels. #wordsmith
On Wed, Dec 2, 2015 at 1:43 PM, Michael Droettboom <[email protected]
tacaswell commentedon Dec 3, 2015
shiny!
mdboom commentedon Dec 3, 2015
One advantage of rewriting the image interpolation as a purely functional interface is that it was really easy to add OpenMP support to take advantage of multiple cores.
tacaswell commentedon Dec 3, 2015
It is not obviously to me which of those interplotaions is 'average all of the values that fall under this much larger pixel' (ex, coarse graining).
mdboom commentedon Dec 3, 2015
The different filter kernels are essentially amount to weighted averages with different curves.