On my ever-increasing “gotta get finished” list, is a benchmark for performing window/levelling of DICOM images in a browser using the HTML 5 CANVAS element. I might drop it off altogether now there is a proof-of-concept up on youtube. One of the reasons I’ve dropped it down the priority list is that while it does do the job, it requires first a drop down to 8 bit jpeg from the original (generally 12 or even 16-bit). So really, its only half a job. The bottom line is, to perform this job properly, one of three things is required:
- Browser standards start supporting multi-byte grayscale jpegs. Not very likely. HTML5 has struggled to gain universal acceptance (and even now, not really in its entirety). Another step back to the table won’t be for a long time.
- Plugins. Over the last few years we’ve seen a significant increase in the variety of browsers out there and that is only likely to continue (even if Gecko/Webkit are at the core of most). Maintaining plug-ins for all would be a nightmare and certainly, a retrograde step.
- Trips back to the server. Personally this is, in my opinion, the most likely. It is necessary to minimise the size of the image being processed and transmitted – perhaps using heavy compression/resizing during the window/levelling operation.
For the short- to medium-term, I am leaning towards the concept of trips back to the server as the best option:
- Once a user has indicated (mousedown) that W/L is required, a very low resolution image is generated (server-side) from the full image. For a 2kx2k CR, for example, a image 256×256 is generated and displayed in the browser – either as a thumbnail/preview or overlaid on the original, full-res image. It would clearly be advantageous to have the low-res image cached in memory in some form.
- Each W/L action (mousemove) is performed on the low-res image and displayed in real-time.
- Once the user is happy with the settings (mouseup), the W/L is performed on the full-resolution image, and piped down to the browser.
An example of this (albeit not involving server-trips) is the volume rendering engine included in Osirix (ITK). When the view of the volume is rotated – it drops down to a low resolution under the view perspective is final, when it returns to full resolution. Clearly not as good as fully hardware-assisted rendering, but quite usable all the same.
3 Comments to “Window/Levelling in a browser – CANVAS or server-trips?”
Latest from the Blog:
- High Availability
- Lessons learned
- Open Source
- PACS General
- Project matters
- Martin Peacock on Virtual Servers and PACS
- Edward Mangiola on Virtual Servers and PACS
- Globalstorage on Business Continuity Planning in Health IT
- Martin P on Window/Levelling in a browser – CANVAS or server-trips?
- Martin P on 3D can be a dangerous game