Very cool. Looking at this annotator makes me wonder if they shouldnt accept a kwarg to configure the annotator behaviour or if the expectation is for the dev to overwrite these classes and customize them as they need.

In the above example, being able to configure the decay would be pretty important to make it useful outside of a demo. Ex: using a very long decay (like 8 hours) on a parking lot could show cars who use the parking illegally or the spots which are the most/least popular.

I can think of a tons of use for this but they would all require fine grain control over the behaviour of the heat map.

Thanks for response.
You can get annotator attribute heatmask. This ndarray consist info about counts of detections in every pixel.
I will try this on long video from road-parking.

Is'nt the 90 on this line used for the decay? (havnet had enough time to look over the whole thing)
https://github.com/kapter/supervision/blob/1324cda60080884d8c867dd44288aca285f5a250/supervision/annotators/core.py#L159C16-L159C44

Just giving access to this variable (as a float) would be an easy solution.

Hi @AlainPilon 👋🏻 wanna propose some changes? I will probably work on merging this annotator tomorrow. So if you have some ideas how to change implementation this is good time :)

@SkalskiP nothing I can personally fix in the next few days. A quick change would have been to move the decay value into the signature but I feel that if we start doing this, we will end up with 20 kwargs to control every aspect of the annotator.

A better solution would be to split the apparence of the annotator and its behaviour into 2 config objects but it is not something I can work on for a while. On the positive side, I do have to create a custom annotator for work which is going to use this pattern so, once I am done, I could retrofit the change in this one.

I think the main purpose of the annotator is to give a quick representation of the frequency of objects appearing in a particular part of the frame. It seems there is no need to complicate it.

I found this

May be later add option: track vs detection heat map?

To me, the example you showed is a mix of tracking the movement over a long duration + the heat map with a small decay. Visualization of a parking lot comes to mind and would be a great use case for this.

I agree that for a first version of the feature, a simple version could work. But since Supervision is a framework it has to be open to the multiple potential usage. This openness could be with configuration options OR by making it very easy to overwrite existing annotators.

I have nothing against the current version of the class, other than thinking the 90 value should be a well named constant or a params. Because right now it is a magic number and unless you run some maths, it is very hard to figure out ahead of time the behaviour of the heat value over time.

In our example heatmap based on tracks is not interesting.

iIn last commit 90 value added well named parameters.

Preview

I'm merging this later today! We are releasing supervision-0.16.0 tomorrow. 🔥

Merging! We need to update the docs. But I'll do it myself! 🔥 Thank you @kapter! 🙏🏻

Thank you, @SkalskiP, for your assessment.