HTML5灰度图像处理练习3：图像数据传输

前面已经试过，用HTML5来进行一般医学图像的显示（Rendering）已经不是问题。那么，接下来就是如何把图像数据传输到浏览器端。

在传统的PACS中，不管是HTTP GET（如WADO）或Streaming（如JPIP），都需要在浏览器端安装一个插件，HTML5是否提供了一些可替代的方法呢？我们首先想到是Web Socket API和File API。但遗憾的是File API主要针对本地文件的读写。Web Socket API传输二进制数据的标准也还没有定型，更谈不上浏览器的支持。而我们当然不能接受用base64把二进制数据文本化之后再进行传输，尽管有些丑陋的协议，比如IHE的XDS，仍然允许用这样的方式在Web Service中传输各种医疗文档（也许国外的网络带宽确实允许吧）。

其实，WEB（或HTTP）并非一个完全为了文本传输而定义的协议。从浏览器刚刚诞生开始，就能够下载各种图片（比如JPEG和BMP等），而且大多数现代浏览器都使用了多线程的方式下载这些图像，使得网页能够更快地打开。既然现在Web Socket API不好用，何不把我们需要的图像数据传输，寄宿在这种早已非常成熟的通道上呢？

几个星期前，已经想到了这种做法，但一直在忙别的事，最近终于有空来验证一下这个想法了。其实道理很简单（当然也有点笨）：一般Web页面使用的BMP，大多都是些24位的彩色图片，RGB各占1个字节。我们就把16位医学图像的像素写到R和G里面，B暂且留空，这时如果直接放在img或canvas里面按照24位来显示，肯定是一幅很奇怪的图像。然后再利用canvas的象素处理功能，把R和G取出来，当作灰度值，进行窗口调节后，再回写到canvas里面。虽然这种做法远非完美，但至少现在看来，是完全可行的。

首先，我在MESA的测试工具包中找了一张重建过的核磁片，512*512尺寸，16位灰度。然后，下载了大名鼎鼎的PACS专家JB Wang多年前用MFC写的一个DICOM转BMP的代码（在google上用“DICOM to BMP”就能够搜到，文件名叫DcmBmpconversion.Rar）。把代码编译之后，按照核磁片中原先设定好的窗宽窗位，输出了一个8位BMP文件。大师写的代码确实很容易读懂，本来以为需要修改很多，不料只需屏蔽几行代码，再增加一行和修改一行代码，就能够把从DICOM文件中读出的16位灰度写到24位BMP的R和G中。出来的图像确实有点怪，不了解的人可能还会以为是故意加的伪彩。

然后，在前面一个HTML5练习的基础上，做一些修改。主要是增加下面两个函数，一个是把异步加载到的那副怪怪的BMP用context.drawImage()画到canvas上，另一个立即用context.getImageData()把R和G的值取出，填充到原先的像素矩阵中。然后，就可以调用原来的方法来调窗和显示了。需要注意的是，一些浏览器对canvas中显示的图像的源（这里的“源”是HTML5的术语）进行了安全性方面的控制，直接在本地磁盘打开HTML页面（由于是未知源）时可能取不到其中的像素数据，因此可以放到一个Web服务器上打开。

function initBmpImage(){
	var img = new Image();
	img.src = 'MR1S1IM1_0001_24bit.BMP';
	img.onload = function(){
		icontext.drawImage(img,0,0);
		initPatternDataWithBmpImage();
		loadImage();
	};
}
		
function initPatternDataWithBmpImage()
{
	//var strlog = ';
	var imgData = icontext.getImageData(0,0,icanvasWidth,icanvasHeight);
	for(y=0;y<imgData.height;y++){
		for(x=0;x<imgData.width;x++){
			var i = (y*imgData.width+x)*4;
			var r = imgData.data[i];
			var g = imgData.data[i+1];
			var v = g*0xFF + r;
			setPatternData(x,y,v);
			//strlog += r + ' ' + g + ' | ';
		}
	}
	//var divLog = document.getElementById('divLog');
	//divLog.innerHTML = strlog;
}

如下图所示，最后显示出来的效果，跟先前用JB Wang的代码生成的8位BMP相比，几乎是完全一样的。

应用的发展永远快过标准的发展。在新标准没有出来之前，用老标准似乎也可以拼凑出一些解决方案。

相信不久的将来，随着Web Socket API的发展，我们将能够用更加聪明和更加环保的方式来传输图像数据。加上HTML5的普及程度越来越高，基于Web Socket传输医学图像的协议最终也会写入DICOM。而一些在HTML5方面跟得比较紧的厂商或者机构，可能也会因为最早向DICOM委员会提出基于Web Socket传输医学图像协议（尽管其中的规定可能非常简单）的建议，而收获一些小小的名利。