support images with reversed axes

[aplavin]

Description

The whole pipeline almost-supported them already, here I just make a few minor fixes where the assumption of increasing values was baked in.

Major update to #3989 following recent image/heatmap changes.

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist

• Added unit tests for new algorithms, conversion methods, etc.

[aplavin]

Don't really understand the reference images process, but tried locally – now displays correctly for all three backends. Like this:

[ffreyer]

I fixed heatmap conversions, squashed the two refimages and added surface as well:

Also did a quick grep search for to_linspace in the Makie repo - it's only used in conversions.jl. So these changes shouldn't affect any odd code somewhere else. Within conversions.jl it also affects a PointBased conversion, but I think that's fine. Specifically ::Interval, ::Interval, ::Matrix can now flip x/y if you supply reverse intervals.

[ffreyer]

transform_func seems to work fine with this too. Briefly checked with p.transformation.transform_func[] = -

[jkrumbiegel]

Why do the corners look wonky here?

[ffreyer]

Because that "cell" is bigger:

img = [
  2 0 0 3; 
  0 0 0 0; 
  1 1 0 0; 
  1 1 0 4
]

[ffreyer]

Oh the corners - that's just FXAA doing its thing. It happens in other plots too

[jkrumbiegel]

Hm but why is it so asymmetrical? I would expect all corners of one cell to show the same aliasing artifacts, but for example the top-right corner goes up and the top-left down.

[ffreyer]

I think that's more your image viewer playing tricks on you? Both the top right and bottom left have AA mixing cyan + white and cyan + purple. They are a bit different because the image is not symmetric, but not fundamentally.

[jkrumbiegel]

Why does the green tile have pixels in row 3 at the top right (this must mean it intersects those pixels with its fragment) but not at the top left (where it doesn't even have fully opaque pixels in row 4)? That must mean the whole fragment is crooked, no? Shouldn't the green part be a perfect rectangle?

[SimonDanisch]

Oh, this is a regression from the plot attribute refactor I think, we always had fxaa=false for heatmap/image!

[ffreyer]

Oh, this is a regression from the plot attribute refactor I think, we always had fxaa=false for heatmap/image!

This is happening for the surface example

Why does the green tile have pixels in row 3 at the top right (this must mean it intersects those pixels with its fragment) but not at the top left (where it doesn't even have fully opaque pixels in row 4)? That must mean the whole fragment is crooked, no? Shouldn't the green part be a perfect rectangle?

I can't tell you what the FXAA shader actually does (some sort of search based on luminosity gradients), but I think that's just a consequence of how much of on color is in the surrounding region. The first green pixel in the top right has 5 white and 4 green fragments in a 3x3, so it'll tend to white. The last green pixel to the right has 3 white, 4 green and 2 purple, so it'll tend to green.

[SimonDanisch]

This is happening for the surface example

I just checked, you just dont see it because of tightlimits but heatmap/image actually have fxaa=true as a default now ...
Probably should be addressed in another PR.

[ffreyer]

It might also have some blurring with fxaa = false because the mesh of the background poly does not have fxaa = false