Viewing 16-bit images over WADO

[Igor Orlovsky]

Greetings,

I am looking for feedback regarding the following issue:
DICOM standard (PS 3.18) states that WADO should encode DICOM images
using JPEG lossy 8-bit compression if "image/jpeg" MIME type is
requested.
What if this is a 16-bit image? I can see the following options:
1. Image quantization. However the classic approaches require using a
custom palette that is not supported by JPEG Lossy. Besides for common
medical images, especially grayscale, the subtle differences between
grades are very often meaningful and reducing color depth may make
them unusable.
2. Rejection of the request unless "application/dicom" MIME is
specified. Safe but not especially user-friendly.
3. Delivering an image as 16-bit, for example JPEG Lossless, in hope
that the browser on user's site has a plug-in for its displaying. But
that would be direct violation of the standard.

Which of those options would be "the least evil" in your opinion? Does
anyone knows additional options?

I'd appreciate any feedback.

Thanks

[Bill Wallace]

I believe that most WADO implementations apply the same window level/
modality/presentation type LUT transform process that is applied when
displaying the image. You can explicitly specify this by specifying
the window level/width or a presentation LUT, but the default is to
compute a window width of the available pixel range, and a center of
the middle of that range. (rounded up if required).

If what you want is the original image, then either fetching it as
DICOM, or using the full contentType format specified for HTTP would
be possible (depending on support). For example:
http://localhost/wado2/?requestType=WADO&studyUID=1.1&seriesUID=1.1.1&objectUID=1.1.1&contentType=image/jpeg,image/jpls,image/jpll

would request an image in any of the 3 specified formats: jpeg (8
bit), jpeg ls (8, 12 or 16 bit), jpeg lossless (8,12,16). Then, the
WADO service can decide the optimal format. I don't know about other
implementations, but the open source implementation in the Xero sub-
project of dcm4che will choose the format the image is already in if
available, or the first version, avoiding all decompression/
recompression steps server side if possible. That version also
supports image/jp8 and image/jp12 for non-window levelled 8 and 12 bit
JPEG (as well as both gif and png formats). The transform applied is
a rescale/slope to entirely fill the output size based on the pixel
range incoming. Not all implementations will support anything except
image/jpeg, and even fewer support the comma-separated syntax
specified in the http standard.

Thanks,
Bill.