-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Don't interpolate images in RGB space #5490
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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 |
"aggravate"? You get a free beer from me at the next SciPy meeting! On Wed, Dec 2, 2015 at 1:38 PM, Michael Droettboom <notifications@github.com
|
Roget's says it's a synonym for "magnify". |
Yes, it works on so many levels. #wordsmith On Wed, Dec 2, 2015 at 1:43 PM, Michael Droettboom <notifications@github.com
|
shiny! |
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. |
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). |
The different filter kernels are essentially amount to weighted averages with different curves. |
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.
The text was updated successfully, but these errors were encountered: