API: add antialiased to interpolation-stage in image #28061
Conversation
90b823e to
0c5adf9
Compare
6ad31ab to
73269ae
Compare
galleries/examples/images_contours_and_fields/image_antialiasing.py
Outdated
Show resolved
Hide resolved
| if (dispx < 3) or (dispy < 3): | ||
| interpolation_stage = 'rgba' | ||
| else: | ||
| interpolation_stage = 'data' |
There was a problem hiding this comment.
I'm not sure there's a really sane default in the (pathological) case of an image being stretched along x and squeezed along y, but I'd have thought that the "neutral" solution would be to set the cutoff at dispx * dispy < 1 (or < 3)? i.e. rgba if there's fewer total pixels at the end than at the beginning, data, if there's more?
There was a problem hiding this comment.
I'm erring on the side of using 'rgba' if any down-sampling is occurring - 'rgba' works exactly the same as 'data' if there is up-sampling and interpolation is 'nearest', which is the default. The only issue with 'rgba' happens when the user wants to smooth upsampled pixels, and specifies 'sinc' or 'bilinear' (etc) smoothing. Given that, I'm willing to ask such users to definitively specify 'data' if they are on the cusp of downsampling and getting weird artifacts.
There was a problem hiding this comment.
can we stuff this and the kernel selection into a helper function so that they do not get out-of-sync?
There was a problem hiding this comment.
Yeah, I tried that but the kernel selection is buried at a different level in the code (in _resample) with different ways of getting the data and figure size, so I took the easy way out and quasi repeated the logic here. I think a reasonable follow up is simplifying _resample and this part of the code base.
73269ae to
2679f98
Compare
|
As briefly mentioned during the call, perhaps the option could be named in a way that does not preclude the future addition of an interpolation_stage="norm" ("normed", i.e. post-normalized data) option, and thus also of interpolation_stage="norm" when upsampling / "rgba" when downsampling. For example the mixed options could be named |
|
I don't think that is a problem. However we still need a default, and I think using 'antialiased', the same as the interpolation keyword default, makes sense. Would it be a problem for that to by synonymous with 'up:data;down:rgba' if we wanted to offer that? |
|
I guess the question is whether we'd be happy to change the meaning of "antialiased" to mean "up:norm,down:rgba" (which I consider a saner default) once "norm" comes in? |
|
Oh, I see, sorry didn't catch on to that. Thats always an interesting question if one interpolates linearly or in log space. In my field, people sometimes interpolate in log space, and then say incorrect things about the (arithmetic) mean. Though I agree that there are aesthetic reasons to interpolate in log space depending on the problem. If we were to add a norm stage of interpolation, as a default, I would tend to err on the side of simple averaging (eg |
OK; I guess this is not going to make it to 3.9(?) (If it does, let's just go with "antialiasing" for now and explicitly mark this name as experimental (...but default) and reserve the right to change it later.) |
galleries/examples/images_contours_and_fields/image_antialiasing.py
Outdated
Show resolved
Hide resolved
galleries/examples/images_contours_and_fields/image_antialiasing.py
Outdated
Show resolved
Hide resolved
galleries/examples/images_contours_and_fields/image_antialiasing.py
Outdated
Show resolved
Hide resolved
galleries/examples/images_contours_and_fields/image_antialiasing.py
Outdated
Show resolved
Hide resolved
galleries/examples/images_contours_and_fields/image_antialiasing.py
Outdated
Show resolved
Hide resolved
galleries/examples/images_contours_and_fields/image_antialiasing.py
Outdated
Show resolved
Hide resolved
eefc329 to
6791fb1
Compare
|
If possible, I'd like to get this in before moving on to the next tasks, (fixing the float scaling) and adding a "norm" interpolation_stage. Working off these changes will be easier than adding those features, going back to these changes and rebasing. The only drawback is that there may be a bit of test image churn, but I think it will be minimal. |
d4cd758 to
afbdfd2
Compare
lib/matplotlib/axes/_axes.py
Outdated
| is carried out on the data provided by the user. If 'rgba', the | ||
| interpolation is carried out after the colormapping has been | ||
| applied (visual interpolation). | ||
| interpolation_stage : {'antialiased', 'data', 'rgba'}, default: 'antialiased' |
There was a problem hiding this comment.
| interpolation_stage : {'antialiased', 'data', 'rgba'}, default: 'antialiased' | |
| interpolation_stage : {'antialiased', 'data', 'rgba'}, default: :rc:`interpolation_stage` |
lib/matplotlib/axes/_axes.py
Outdated
| interpolation_stage : {'antialiased', 'data', 'rgba'}, default: 'antialiased' | ||
| If 'data', interpolation is carried out on the data provided by the user. | ||
| If 'rgba', the interpolation is carried out in RGBA-space after the | ||
| color-mapping has been applied (visual interpolation). If 'antialiased', |
There was a problem hiding this comment.
Is 'antialiased' the correct name?
-
The other two options 'data' and 'rgba' refer to types of data in the processing pipeline. In contrast 'antialiased' is an effect.
-
From https://en.wikipedia.org/wiki/Spatial_anti-aliasing:
In digital signal processing, spatial anti-aliasing is a technique for minimizing the distortion artifacts (aliasing) when representing a high-resolution image at a lower resolution.
In my understanding anti-aliasing is only connected to downsampling. It's thus surprising that a mode 'antialiased' tries to
cover down-sampling and up-sampling.
Suggestion: Simply use 'auto', which hints at "use the best (from existing modes 'data', 'rgba') for the given context".
There was a problem hiding this comment.
'antialiased' is meant to be the same for both interpolation and interpolation_stage keyword arguments. The analogy is with most viewers, which have an "antialiased" toggle, regardless of whether the image is actually up or downsampled.
There was a problem hiding this comment.
I see. But still the name does not speak to me. I recommend to get some opinions from core devs. If they are fine with the name, I'll give in.
There was a problem hiding this comment.
I think the trap were are in here is that for the interpolation kernel we went with "antialiased" (maybe "auto" would have been better there, but I think the case is less good there than here (as it only considers 2 of many possible. Either way, that is out the door and we should not change it). That leaves us with the choice between:
- use a better name here ("auto") but have the difference between the two which makes it rougher for users
- use a less-good name ("antialaised") but better coherence for users
I come down on the side of "use the same name" when looking at the aggregate (even if though I think locally "auto" is better).
There was a problem hiding this comment.
Well, 'antialiased' is pretty new for interpolation. We could keep it, but add 'auto' and make that the default for both interpolation and interpolation_stage. A bit of doc rewriting...
There was a problem hiding this comment.
I think "auto" would be better for both as it implies some magic selection is going on for the user to determine what is best. I agree, it seems like we coudl point "antialiased" -> "auto" if a user inputs "antialiased" and just rewrite the docs to make everything show "auto" now.
| axs[0].set_title("interpolation='antialiased', stage='rgba'") | ||
| axs[0].imshow(np.triu(img), cmap=cm, norm=norm, interpolation_stage='rgba') | ||
|
|
||
| # Should be same as previous |
There was a problem hiding this comment.
Can you do a figure reference/test comparison test here instead with these two axes?
2e22643 to
d0e3ce8
Compare
|
OK, changed the default from 'antialiased' to 'auto' Also changed interpolation default to 'auto' from 'antialiased'. Kept 'antialiased' for back compatibility, but should behave exactly as 'auto'. |
imshow used to default to interpolating in data space. That makes sense for up-sampled images, but fails in odd ways for down-sampled images. Here we introduce a new default value for *interpolation_stage* 'antialiased', which changes the interpolation stage to 'rgba' if the data is downsampled or upsampled less than a factor of three. Apply suggestions from code review Co-authored-by: Thomas A Caswell <tcaswell@gmail.com>
Co-authored-by: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
bd64bfc to
45fac07
Compare
|
Thanks for putting in the work to make these changes, @jklymak! |
|
Thanks for the help - the is a relatively big change, but hopefully will not cause too much blowback and reduce bug reports for weird under sampled images... |
|
Thank you everyone! |
UPDATE: 6 July 2024:
This PR changes the default interpolation_stage in imshow (and friends) to 'auto'.
It now also changes the default interpolation from 'antialiased' to 'auto'.
'auto' follows interpolation 'auto' in behaving differently if the image is upsampled by more than a factor of three or if it is weakly upsampled or downsampled. If upsampled, interpolation_stage will happen at the data stage, like the previous default. If downsampled, interpolation_stage has been changed to happen at the RGBA stage.
When upsampling and using a smoother on the pixels, interpolation in RGBA space leads to non-sensical colors, and was the original motivation behind #5718. Hence upsampling continues to happen in data space as has been the default since 2.0
Conversely, downsampling should have an anti-aliasing filter applied, but this leads to all sorts of strange effects if applied at the data stage (eg, #21167, and many other fixes since #5718 went in). The new behaviour is to sidestep all these issues and do the interpolation in RGBA space if downsampling.
See the much longer description at https://output.circle-artifacts.com/output/job/edd10dae-2a13-48cf-af33-dca97ed402eb/artifacts/0/doc/build/html/gallery/images_contours_and_fields/image_antialiasing.html#sphx-glr-gallery-images-contours-and-fields-image-antialiasing-py