Resolved: Heatmap transposes matrices

[mkborregaard]

I'm updating the worldclim example to 1.0 and fixing it, and ran into this issue:

Makie.heatmap(water[10])

Plots.heatmap(water[10])

(note that the matrix format in the example is a bit funky in both examples).

I have a strong feeling this is the source of the issues described in #137

[SimonDanisch]

Hm, that should be unrelated! I thought on master I made sure, that the values from the axis map to the right pixels... let me check!

[SimonDanisch]

(unrelated, because putting it on a mesh could yet have another messed up mapping -.-)

[mkborregaard]

This is on master btw

[SimonDanisch]

for

x = -0.1:0.1:4
y = range(-2, stop=6, length = length(x))
z = x .* y'
Makie.heatmap(x, y, z)

Makie is right, no?

[SimonDanisch]

brightest needs to be 4x*6y, and darkest 4x*-2y

[mkborregaard]

waitaminute - is Plots heatmap broken then? :-O

[mkborregaard]

Ah, no @SimonDanisch the x axis is the horizontal one, but you're using y as horizontal in your calculation. it should be z = x' .* y not z = x .* y'. And then you get

[SimonDanisch]

oh, subtle^^ guess i need to change the orientation yet another time :-D

[daschw]

I'm not sure but I think it's debatable, whether the x axis should correspond to the rows (Makie) or columns (Plots) of a matrix. Here's the behaviour for a simple matrix in different plotting packages:

julia> mat = [1 0; 2 0; 3 0]
3×2 Array{Int64,2}:
 1  0
 2  0
 3  0
julia> heatmap(mat)

Makie

Plots

PlotlyJS matches the Makie behaviour:

julia> heatmap(z = mat)

Python's Seaborn e.g. looks like this:

import numpy as np
import seaborn as sns
mat = np.matrix('1 0; 2 0; 3 0')
sns.heatmap(mat)

which is the same as Matplotlib's imshow:

import matplotlib.pyplot as plt
plt.imshow(mat)

I think both, Makie/PlotlyJS and and Matplotlib/Seaborn, make sense in their way:

• MPL/Seaborn show the image like the matrix would be written/printed (This however flips the y axis)
• Makie/PlotlyJS match the "first" (row) dimension with the "first" (x) axis. However, this makes it harder in my opinion to make the mental link between written/printed matrix and image.

I'm not sure if there is a "correct" way to do this, but I think the hybrid Plots implementation (match x axis with columns, but avoid y axis flipping) is not as clear and less preferable. What do you say?

[daschw]

There's definitely something wrong with the Makie example, though, considering the axes tick labels.

[mkborregaard]

I disagree. The call should be x, y, z, not e.g. y, x, z for the heatmap case in particular. The axes of all plots are x on the bottom and increasing towards the right, y going upwards, and IMHO it is confusing to make that different for this one particular plot call.

It also would make it much more difficult to e.g. plot scatter plot points / contours on top of a heatmap if the axes were non-traditional here (something I use all the time, e.g. for maps).

Also, Plots' implementation is not some hybrid implementation, it's the default in GR, in R and a number of other plotting packages.

[daschw]

It also would make it much more difficult to e.g. plot scatter plot points / contours on top of a heatmap if the axes were non-traditional here (something I use all the time, e.g. for maps).

Very good point.

[daschw]

I agree with you. The Plots implementation does make sense and heatmap should not behave any differently than contour here.

[mkborregaard]

@SimonDanisch , @daschw
I know I argued very strongly above. But actually I've reflected further on this, and I have to backpedal. I think you're right.

I still think x must correspond to x and y correspond to y, and values of x and y increase to the right and upwards. But that is also the case in the current Makie / PlotlyJS implementation. It's just a question of how you define the relationship.

Looking at Simon's and my example above:

x = -0.1:0.1:4
y = range(-2, stop=6, length = length(x))
z_makie = x .* y'
z_plots = x' .* y
z_makie[20, 10] == x[20] * y[10]
# true
z_plots[20, 10] == x[20] * y[10]
# false

I know this example doesn't prove anything, but just shows that the Makie interpretation is as intuitive as my first one, that x should be horizontal.

Also, I had to go back and check the claims I made about GR and Makie, and they are false.

R does the same as PlotlyJS/Makie:

While GR lives in a world of it's own:

Matlab, FWIW, does what matplotlib does.

So, my conclusion is that I've been suffering from Plots' Stockholm syndrome and not thinking this all the way through. And that we should close this issue and keep the Makie implementation as it is.

The second question then is - should we change Plots to align with Makie?