Heatmap content is flipped vertically

Bug Report

Issue: (Bug description goes here) When plotting data in the Heatmap the data is flipped vertically.

Reproducing: (What do others have to do to reproduce the bug?) You can see this even in the plots in the Cookbook Heatmap examples. The “coldest” point should be at (0,0) but it is on the max Y row and the “hottest” point should be on the max Y row but it is on the min Y row in the plot.

It appears this is happening in the “Update” function. The 2D data is flattened into a 1D array. Later in that routine the Rectangle is defined with the upper left corner set at 0,0. I believe the flattened data is then used to populate that Rectangle from that upper left corner down. In playing with this is I added the line of code shown below at the end of the Update function and I get the expected results. I am not sure if there is a more elegant/efficient way to solve this.

// a code sample may improve communication
BmpHeatmap.RotateFlip(RotateFlipType.RotateNoneFlipY);

System Details

• ScottPlot Version: 4.1.123?
• Operating System: (Windows 10.)
• Application Type: (console)
• .NET Version: (.NET 6.0)

[vtozarks]

Here is an example OxyPlot I got from a colleague (plot for data at (+/-1, +/-1). In a discussion with a couple engineers in my office several flagged that the other tools are centering each square on the raw data coordinate and raised some concern that the ScotPlott example was effectively building in a (0.5, 0.5) offset that is not present in the raw data. All agreed that if coordinates are shown on the axis then they should align with the raw data to prevent inaccurate conclusions from the plot no matter which way the data is plotted (starting at upper left or lower left).

[swharden]

Thanks for reaching out @vtozarks! The fix @bclehmann offered in #1866 looks great and I’m merging it in now.

Regarding simpler ways to do this in ScottPlot5, I don’t even think we need to note it in #1028. Now that the heatmap module has been running in the wild for a long time I think we have a better idea than when we started about what parts people find intuitive vs. unintuitive/surprising, and could probably design a new API around the 99% use case, and not worry about breaking changes. The time isn’t quite right to dive into that yet, but I look forward to hopefully working on it soon!