Glad to announce my works this morning: A simple heatmap API based on HTML5 canvas.
The programming interface is rather simple now. To create such a heatmap, you just new a heatmap object by:
<canvas width="300" height="215" id="canv"></canvas>
heatmap = new HeatMap("canv");
Then read your dataset and push data into the heatmap:
heatmap.push(x, y, value);
At last, spread the data and get the canvas rendered:
heatmap.spread(); heatmap.render();
Now you got it.
For advanced usage, you can specify the resolution of heatmap by px:
heatmap = new HeatMap("canv", 2);
Large value will gain performance with low image quality.
Also, you can specify a value to define the attenuation value of each px.
heatmap.spread(5);
Finally, there is an option to use your own color schema for heatmap generation.
heatmap.render(function(value, maxValue){
var light = value / maxValue * 100;
return "hsl(20, 75%, "+light+"%)";
});
The parameters passed in are current pixel value and max value in whole context.
That’s all the toolkit. More functionality and options might be added in future. Grab it from my bitbucket page:
http://bitbucket.org/sunng/daily-coding/src/tip/canvas-heatmap/
There is a demo page which you can test the api by clicking canvas:
then click heatmap button!
This is the new year gift for my readers and my dear friends !
朦胧美……
数据之美，数据之美。。。
貌似图片再大一些性能很成问题……
这个算法复杂度和图片大小无关的，是点数n*半径平方r^2
还是会卡一下的，难免的，画栅格嘛
我倒是发现一个bug
汗，倒也不算太慢。是我改写成gwt在本地调试慢得无法忍受，编译以后还是很快的。
然后我用gwt-canvas还有一个问题，就是产生fillStyle的时候hsl表达式无效，改成rgba是可以的，不知道是什么原因。
对了，建议把衰减函数改成：
double value = data.get(s) / maxValue – Math.log1p(distance / maxRadius) / Math.log(2);
然后fillStyle就是”hsl(” + (1.0 – value) * 240 + “, 50%, 50%)”;
这样看上去衰减要舒服一些，然后maxRadius比step要好理解。
赞，好主意，我那个maxValue太恶心了
本来想给个context对象的，结果发现也没什么好给的
– Math.log1p(distance / maxRadius) / Math.log(2);
的意义是？
我知道原因了…… 如果用hsl，canvas背景透明的时候，不能正常表示…… 我都改成rgba吧……
我是在gwt里写的，就是log(1+x)，对了好像这么算值域还是不对，这样貌似才对：
(value/maxValue – Math.log1p(distance/radius) / Math.log(2) + 1) / 2;
这样才能落到[0,1)……
log1p()/log2是为了改变变化趋势，我是由gwt的源码里animation的实现为了使变化平滑改变了间隔频率想到的，不过效果貌似不是很明显……
这个衰减我本来也是想过类似transiton这种
http://doc.mootools.net/docs/core/Fx/Fx.Transitions
想把衰减方法留给用户自己定义（像colorschema那样）
后来没来得及做
gwt的Animation也是做了一个magic的插值
http://www.google.com/codesearch/p?hl=en#A1edwVHBClQ/user/src/com/google/gwt/animation/client/Animation.java&q=interpolate%20package:http://google-web-toolkit%5C.googlecode%5C.com&sa=N&cd=1&ct=rc&l=161
/**
* Interpolate the linear progress into a more natural easing function.
*
* Depending on the {@link Animation}, the return value of this method can be
* less than 0.0 or greater than 1.0.
*
* @param progress the linear progress, between 0.0 and 1.0
* @return the interpolated progress
*/
protected double interpolate(double progress) {
return (1 + Math.cos(Math.PI + progress * Math.PI)) / 2;
}
用Math.log(x) / Math.log(max)衰减梯度差就可以了
实在不爽的话，可以单独给rgb的每个值写函数控制区间与衰减，更精确并且可控。不过也麻烦，不好维护。以前写过：
http://www.baiduux.com/blog/2010/08/31/%E5%9F%BA%E4%BA%8Ecanvas%E7%9A%84%E7%83%AD%E5%8A%9B%E5%9B%BE%E7%BB%98%E5%88%B6%E6%96%B9%E6%B3%95/
我的这个版本 数值与颜色的映射函数 可以由用户指定的：
https://github.com/sunng87/heatcanvas
你怎么留言到这里了，这个是一年多前的了。。。
另外hue可以考虑(1-x)*250-260把蓝色包括进去。我用的是hsl((1-x)*250, 1, 0.85)
试验了几个发现对数拉伸还不如直接取0……
final double r = value/maxValue – distance/maxRadius;
return r > 0 ? r : 0;
我把canvas的heatmap挂到地图上了…… 重绘速度确实很慢，我在想可能是gwt内部的hashmap比原生js object慢的原因，spread之后的值数量比较多，差别就看出来了。
http://mapgwt.appspot.com
不错不错，我看到了
有必要看一下性能瓶颈在spread还是render，如果是在spread，可以在pan的时候直接translate那个坐标。如果是render就只好换浏览器了。
我昨天下班还在想把它做到OpenLayers里作为一个Layer，最近要评估一下看看可行性如何
应该是spread，pan的时候就是直接调整offset的，但是mouseup的时候会map panel调用commit机制，这时候所有图层都会重绘保证数据的一致性，就是在这个时候会卡一下。包括切换工具、打开关闭图层都会commit保证一致性，所以如果打开了heatmap这些时候都会卡一下。
现在看问题应该不是在HashMap，GWT1.5之后HashMap性能有极大的提高（http://development.lombardi.com/?p=797），render应该改没问题的，在gnome上绘制都比较慢的，就不知道在spread的哪个环节出问题了……
gwt确实是个好东西，java的开发效率比js高太多了，而且也可以用jsni直接调用raw js，或者通过jsni暴露出js api。如果需要有ext那样的完备效果，也有ext gwt这样的wrapper。
改了cache规则和渲染顺序，现在在chrome上速度基本可以接受了，ie上大约需要1分多钟
Pingback: HeatCanvas hits 1.0, and public available