CODEWITHSUNDEEP
canvasdicom
alhad
alhad

Reputation: 31

DICOM image viewing on Web app

I need to know if DICOM image needs to be shown on Browser, which approach should be followed? My Image server is some where else on cloud. need to access the dicom image, paint in canvas, if user edits then upload the edited image to server. Need to have good performance as well, as DICOM images are very huge in size(~1gb) Which is the best way to do this?

Upvotes: 2

Views: 1802

Answers (3)

Sean Doyle
Sean Doyle

Reputation: 358

DICOM wasn't really designed for this use case. It's not only that DICOM images aren't usually modified by users (although that's true). When you change the pixel data it may make sense to change the image's identifiers (the SOPInstanceUID) and you should change the image's type indicate that it's now a derived image.

If you're modifying pixel data it's probably safest to create a new image since DICOM images are typically medical images which are part of a patient's medical record. They should not be modified. What if (for example) there were images of tumors on the original that were removed because there was a pending lawsuit for the radiologist who had missed these in the initial diagnosis?

If you're not doing medical image processing.. you should avoid DICOM. It's a wonderful protocol within its intended use but it's not really meant as a general distributed image editing protocol.

The only medical images that I know of that approach 1GB are pathology images. For that purpose you might consider JPIP for viewing the images (this is even in the DICOM spec). But that doesn't help with the editing portion because JPIP is for consuming images, not incrementally modifying them.

Upvotes: 2

Steve Wranovsky
Steve Wranovsky

Reputation: 5713

As ruslik mentioned, the size and nature of DICOM images makes this a tough technical problem. there are a couple of methods that people in the industry are using to build web viewers:

  • Client technology such as Flash, Silverlight, or Active X (in the old days) is used to make a client that can do most of the image manipulation itself. The client receives the images from the server, and then does some amount of manipulation on the client of the images. Things like window leveling ad annotations are done on the client.
  • A zero footprint client is used, where server side rendering is done, and simple JPEG images are sent to the client on demand as the user interacts with the images. The client is all done in Javascript and/or HTML5 and can run on any browser.
  • A combination of the first two, where a client technology such as Flash or Silverlight is used, but server side rendering is also done to simplify the client. JPEG or PNG images are sent to the client.

I'd think more than likely you'd choose one of these solutions. One final note, this would make a great question for the new Healthcare IT Stack Exchange site when it goes to beta.

Upvotes: 1

ruslik
ruslik

Reputation: 14870

1) DICOM images aren't usually modified by users. (maybe annotations or window/center values), but it's different.

2) Most DICOM images are ~1Mb, so yours are very special. I doubt that most standard viewers would load them.

3) No display is able to show 1Gb at a time, so it's enough to send a small-resolution version of image (max 1mpx), and just send updates for zoomed areas.

Given all this, you'll have to explain better your question.

Upvotes: 2

Related Questions