WADO evolution

1
WADO evolution

• Multipart ?
• JPIP ?
• Or Web Services?
• With help from Emmanuel Cordonnier (ETIAM) -
  Thanks to him

2
Why a WADO evolution ?

• Lot of request to support multipart for
  series/study retrieve
• Some would like to see WADO supporting JPIP (part
  of JPEG 2000)

3
Multipart (1)

• IHE XDS
• Multipart is neither understood nor well accepted
  by the vendors even its a part of XDS (the same
  document could be  single-file" or "multi-files"
  and in this case "multipart).
• The "XML guys" would like to do everything
  embedded into XML. They think that a complex
  document is a big file (unique XML) with a lot of
  binary documents inside.
• As example given, scanned PDF documents converted
  as CDA, the full XML approach was chosen vs.
  multipart.

4
Multipart (2)

• Retrieving several images from a series/study
  could be done with two processes
• Using (present HTTP GET based) WADO and KOS
• the server publishes a "manifest" (DICOM Key
  Object Selection) get by the web client" (as
  DICOM using WADO)
• the client builds queries using WADO (for DICOM
  objects or Jpeg images) from the references to
  DICOM objects contained in KOS, image by image or
  as a set" to display it together. This approach
  was retained for IHE XDS-I profile.
• KOS retrieval as HTML (XML?) using WADO would
  allow to have WADO links directly accessible but
  image per image.
• Evolution of WADO to Web Services
• The communication is no longer in HTTP Get but
  uses HTTP POST SOAP that means web services,
  using the MTOM/XOP as transport mode for the
  answer.
• It is too early to define it, but in one or two
  years, following the approach used in IHE XDS

5
Multipart (3)

• The initially considered solution (an unique UID
  possible and retrieval of a set of images" using
  multipart - that means all in DICOM or all in
  JPEG) could be rejected by the vendors because
  actual browsers do not support the multipart. It
  may change in the future.
• Despite the fact that with IE, if one put a
  multipart - related or mixed - with several jpeg
  images inside using the right file extension, one
  obtains the images on line (like digital photos
  sent by mail).

6
JPIP (1)

• The JPIP large supremacy (vs. multiple exchange
  of JPEG images) in the present implementation
  context is not yet technically proved, despite
  several trials.
• JPIP is based on JPEG 2000 (vs. JPEG).
• The place where JPIP use is particularly
  justified is pathology WSI (100.000 x 50.000
  images to 4 Go compressed) and DICOM has not
  selected the JPIP approach (vs. JPEG tiles), yet.

7
JPIP (2)

• Lot of vendors are implementing gizmos like
  "web JPIP jpeg2000", most are doing it using
  proprietary stuffs without really using the
  pure DICOM Jpeg 2000 format.
• One of the most important differences between
  jpeg and jpeg 2000 is that it exists basic jpeg
  codec on client PC or Mac but not for jpeg 2000
  and so the codec shall be incorporated in the
  workstation software. Its the same for JPIP.

8
JPIP (3)

• WADO allows to do progressive display in jpeg
  using an "intelligent" client (like JPIP)
  controlling the image size and the displayed
  region.
• The most important difference vs. JPIP is that
  the entire displayed image is send when JPIP
  allows to send only the difference IF THE SERVER
  KEEP TRACK OF THE "CONTEXT" for this specific
  terminal.

9
JPIP (4)

• WADO allows also to retrieve the DICOM images and
  to choose the transfer syntax.
• So it is possible to do it for a WADOJPIP
• Retrieve the image in DICOM (contentTypeapplicati
  on2FdicomtransferSyntax1.2.840.10008.1.2.4.94
  or 95).
• Open the JPIP session on the basis of information
  read in the "image" containing the JPIP URL in
  place of pixels.
• So it is possible to do WADOJPIP without any
  WADO specs evolution

10
Recommendation

• The DICOM and ISO joint group can publish an
  "implementation guide" on the subject but there
  is not clear reason to revisit the ISO 17432
  standard, yet.
• Add the multipart option now can be quite
  controversial and put trouble in WADO which is
  more and more adopted by vendors.
• At the opposite, a WADO evolution could be
  considered next year or in 2 or 3 years
• implementing the web services
• including the frequently requested function for
  whole series or study retrieval.