Feature request: Controlled decimation for heatmap

[lwabeke]

I have a feature idea/request: When using heatmap to display images that are larger than the pixel area, the data gets decimated by the backend in order to fit into the display. This is fine if your interested in big features. However the data I frequently work with is small peaks against a large noisy background. If the data then gets automatically decimated, it ends up being luck whether the peak is sampled or discarded and it changes as the display window gets resized (physically resized and/or adding plot labels etc.). Thus ideally I want to be able to apply my own decimation to ensure that the peak is not discarded. I can think in other applications, if interested in minimums, the decimation would look different to ensure they are retained.

For a backend that generates an image file, I can try to work around this effect, by first doing my own decimation beforehand. However for an onscreen display, it becomes more problematic. Also if the backend allows pan and zoom, the decimated data is not what you want to display when the user starts zooming.

Thus my feature request would be a way to be able to apply a custom/controlled decimation to the data of a heatmap, with some sort of feedback/call back on viewport changes (only if using a backend with interactivity).

While at some level I feel this should be separate from a package like Plots, working on top of it, however I would still like to be able to have that as a subplot in a larger plot, where the others are not necessarily this type of decimated heatmap. I'm also not sure if the interactive feedback would be achievable if this functionality is in a library running on top of Plots. Is this where recipes come in?

Would something like this be useful to others?

Thoughts/suggestions? I guess I should post on discourse, however I'm unable to connect there the last 24 hours.

[pkofod]

I'm going to say this, because you're going to hear it very soon from someone else if I don't: go make a PR!

I know it seems harsh, so let me phrase it a bit differently. What you're asking for seems like a cool thing, but I think it's a bit of a niche feature. If we take a look at the list of issues, I think it's very unlikely that someone who doesn't really need it will be able to find time to implement this.

[lwabeke]

I should have been clearer, I'm all for creating the PR myself. (I already submitted a PR on JSON, which then rather evolved into the seperate Unmarshal package, so that doesn't phase me).

My questions are more: -In which package does it belong, or it a separate package, to not clutter Plots with code few other people are interested in? -Is it at all feasible? It seems the connection to Plotlyjs is exclusively/mostly a one-way connection. Does anyone definitely know if I can get info back from Plotlyjs on the user pan/zoom actions? Or do I need to go dig myself? -If Plots and Plotlyjs does not currently allow the user actions to flow back, would there be interest to adding support for that? Or will it again be added complexity to maintain and would be better in a separate package?

[timholy]

https://discourse.julialang.org/t/controlled-decimation-of-heatmaps/3060 has a suggestion for how to implement it. (Please note that cross posting is discouraged.)

[lwabeke]

Sorry for the cross-post, but after a month with no comments on the issue, I decided a discourse might be the more appropriate place, especially if this does not end up in Plots itself.

[mkborregaard]

I agree, I think the question on discourse is appropriate, I just wanted to keep the x-ref. Working with pan information from plotlyjs through Plots is not trivial! I think the best way (but this is just my opinion) is for this to go in a separate package, possibly bypassing Plots altogether and working directly with PlotlyJS. I think @timholy 's suggestion on Discourse sounds like a nice approach.

[timholy]

Ah, I didn't notice the date. You were well-justified in cross posting.