Browsing all articles from May, 2010

Just how fast are browsers nowadays anyway?

Posted Posted by Martin P in Development     Comments No comments
May
6

At least for page rendering, Chrome is pretty quick. iPhone/iPad users are out of luck.

Javascript benchmarks

Posted Posted by Martin P in Development     Comments No comments
May
5

It come as no surprise, but this is illuminating.

Window/Levelling in a browser – CANVAS or server-trips?

Posted Posted by Martin P in Development, PACS General     Comments 3 comments
May
3

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.