僅提供參考和學習，代碼僅為了指明個思路，轉載請注明出處。
要檢視此系統更多的圖像處理功能請參考：
在此之前，此系統是結合DICOM的WADO标準，在浏覽器裡通過javascript操作傳回的JPG圖檔。這種伺服器端解析，用戶端展現的方式，對實作圖像的移動、縮放、旋轉、測量等圖像操作能夠實作實時的互動。但這種方式存在着幾個弊端：
1.擷取圖像上的CT值(鈣化值)資訊的時候，要頻繁的和伺服器進行互動。
2.調整圖像的窗寬窗位或者對圖像進行反色，也要和伺服器進行頻繁的互動。
3.對圖像進行測量（長方形測量，橢圓測量等）隻能擷取到面值和周長的簡單的資訊，這對于醫生的診斷沒多大的用處，實際運用中需要知道所測量的區域的最大值、最小值、方內插補點、均值等測量資訊。
以上的缺點歸結為一點：即本地沒有處理像素資訊的操作。但是HTML5對于像素級處理的能力已經支援得很好，完成可以實作用戶端對像素資訊的操作。是以為了解決以上問題最近對系統做了一次比較大的更新。即用戶端端直接操作DICOM的像素資料進行JS端圖像的生成以及JS端實作窗寬窗位的調整。
擷取dicom中的像素資料,可考慮以下兩種方式：
A：伺服器端直接以位元組流的方式傳回DICOM檔案，用戶端用JS來接收位元組流，并負責解析DICOM中的圖像資料，這種方式不僅要根據DICOM的傳輸文法(0002,0010)Transfer
Syntax UID，還要根據 (0028,0002)Samples per pixel、(0028,0004)Photometric
Interpretation,(0028,0010)Rows,(0028,0011)Columns,(0028,0100)Bits
Allocated,(0028,0103)Pixel
Representation等标簽來确定像素資料的結構，複雜點的可能還會用到查找表來查找((0028,0004)Photometric
Interpretation的值等于==PALETTE COLOR)。對于非壓縮的顯示VR或者是隐形VR，(0028,0004)Photometric
Interpretation等于MONOCHROME1或者MONOCHROME2來說JS解析出像素資料确實很友善，但是DICOM檔案各式各樣，要寫出包羅給種傳輸文法以及各種像素結構的JS檔案确實很費勁。還要考慮到多幀動态圖像，如果多針圖像很大整個檔案下載下傳下來解析估計浏覽器會徹底奔潰。是以覺得這種方式不太可行。(雖然這過程中實作了顯示VR的DICOM檔案的JS解析，但是中途考慮到複雜性和難度還是放棄了)。
B：從伺服器端擷取DICOM檔案的像素數組，既然目前基于C/S模式的PACS已經相當成熟，各式各樣的第三方開源的dicom解析工具如DCMTK,DCM4CHE,MDCM,OPENDICOM等也相當的多，用開源的DICOM解析工具擷取到像素資料也相當的友善。是以在伺服器擷取到像素資料傳回給JS端，讓JS端直接操作像素資料來生成要顯示的圖像。對于多幀圖像也可以按需按幀的從伺服器下載下傳像素資料。
言歸正傳，目前此系統是基于第二種方式來實作。需要特别注意的是：做窗寬窗位調整的時候要先做Hounsfield 值的轉換。
HU[i] =
pixel_val[i]*rescaleSlope+ rescaleIntercept。窗寬窗位的調整使用了線性的window-leveling算法針對CT/MR等圖像，或者是非線性的gamma算法針對DX圖像(即當windowWidth比較大的時候要考慮非線性的gamma算法，因為線性算法中每windowWidth/255個原始密度會壓縮成一個顯示灰階，windowWidth很大的時候損失可能會很大)
如下代碼展示JS端如何用背景擷取到的像素資料生成圖像。其中用到了查找表的概念。
滑鼠調整窗寬窗位的時候JS端生成圖像+繪制圖形的速度。
1.512 X 512大小的CT圖像調整窗寬窗位速度
2.512 X 512大小的彩色CT圖像調整窗寬窗位速度
3.512 x 512大小的MR圖像調整窗寬窗位速度
4.2057 X 1347大小的CR圖像調整窗寬窗位速度
5.有了像素資訊後就可以在用戶端實時的擷取到CT值了。
6:有了像素資訊後測量也可以擷取到測量區域的最大值、最小值、方內插補點、均值等測量資訊了
進測試，調整窗寬窗位時HTML5上繪制圖形的時間還是很快的,總的繪制時間在10毫秒的數量級，而且發現繪制時間還可以變少，這繪制時間包括了圖像邊角上的文字資訊，但是HTML5繪制文字的資訊效率明顯比繪制圖像的效率要底，是以不必每次重新整理都繪制文本資訊，可以加以參數控制在圖像切換或者調窗寬窗位的時候也就是文本資訊變化的時候才繪制文字資訊。關于圖像的生成時間，發現圖像的生成時間和圖像的寬X高成正比，圖像越大所需時間越長，對于CT/MR等圖像時間大概在幾十個毫秒級。對于2057X1347的CR圖像時間大概在400毫秒級，對于2000X3000多的DX圖像生成圖像的時間就有點卡頓了，要1秒-2秒左右。。。這速度還得想辦法優化有木有。。。。。還有對于DX圖像調整窗寬窗位雖然使用了gamma算法，但是出來的圖像，我總感覺得沒有用第三方工具比如RadiAnt上看見的光滑，噪聲有點大。是以在沒得到更好的解決方案前，目前DX的圖像隻能特殊化即保留原來的方式在伺服器端直接生成JPG讓用戶端直接繪制，希望會DICOM圖像算法的大神們看到此文章後能給小弟我一點關于DX調窗寬窗位的意見，是不是還要用到别的算法啥的？。先謝謝了。