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 atdispx * 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?

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 andinterpolation 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.

can we stuff this and the kernel selection into a helper function so that they do not get out-of-sync?

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.

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.

• Fromhttps://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".

'antialiased' is meant to be the same for bothinterpolation andinterpolation_stage keyword arguments. The analogy is with most viewers, which have an "antialiased" toggle, regardless of whether the image is actually up or downsampled.

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.

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).

Well, 'antialiased' is pretty new forinterpolation. We could keep it, but add 'auto' and make that the default for bothinterpolation andinterpolation_stage. A bit of doc rewriting...

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.

Can you do a figure reference/test comparison test here instead with these two axes?