WADO-RS returns incorrect content type

[hackermd]

Describe the bug According to PS3.18, WADO-RS should by default return resources requested with media type application/dicom using Explicit VR Little Endian transfer syntax 1.2.840.10008.1.2.1 if no transfer syntax is specified in the accept header: http://dicom.nema.org/medical/dicom/current/output/chtml/part18/chapter_6.html#table_6.1.1.8-2

However, dcm4chee-arc-light version 5.15.0 returns resources using the transfer syntax with which the instances were stored.

Unfortunately, the transfer syntax can not be specified explicitly in version 15.0 due to #1715. Therefore, I cannot test this behavior.

Expected behavior WADO-RS should return resources requested with media type application/dicom using Explicit VR Little Endian transfer syntax 1.2.840.10008.1.2.1 (if no transfer syntax is specified in the accept header) and decompress bulk data if necessary.

[gunterze]

Not reproducible with 5.15.0:

$ storescu -cDCM4CHEE@localhost:11112 ~/testdata/IMAGES/JPLL/CT1_JPLL 
:
09:45:47,970 INFO  - STORESCU->DCM4CHEE(1) << 1:C-STORE-RQ[pcid=7, prior=0
  cuid=1.2.840.10008.5.1.4.1.1.2 - CT Image Storage
  iuid=1.3.6.1.4.1.5962.1.1.1.1.4.20040826185059.5457 - ?
  tsuid=1.2.840.10008.1.2.4.70 - JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1])]

$ wadors --url http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457
09:46:01,538 INFO  - > GET http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457
09:46:01,539 INFO  - > Accept: null
09:46:02,353 INFO  - < Content-Length: -1
09:46:02,353 INFO  - < HTTP/1.1 Response: 200 OK
09:46:02,353 INFO  - < Transfer-Encoding: null
09:46:02,354 INFO  - < ETag: "-719878629"
09:46:02,354 INFO  - < Last-Modified: Sat, 22 Dec 2018 08:45:48 GMT
09:46:02,354 INFO  - < Content-Type: multipart/related;start="<5cd62eaa-14a8-4646-b2c3-645d99672061@resteasy-multipart>";type="application/dicom"; boundary=9ad125c8-ec81-45a6-bc69-58f5b5376a4c
09:46:02,354 INFO  - < Date: Sat, 22 Dec 2018 08:46:02 GMT
09:46:02,360 INFO  - Extract Part #1{content-id=[<5cd62eaa-14a8-4646-b2c3-645d99672061@resteasy-multipart>], content-type=[application/dicom]}

$ dcmdump part0.dcm | grep Transfer
246: (0002,0010) UI #20 [1.2.840.10008.1.2.1] TransferSyntaxUID

[hackermd]

@gunterze Thanks for looking into it. I can't reproduce the issue with these data sets either. However, I still encounter the issue with some CT Image data sets. Unfortunately, I can't share these data sets for testing.

The original data sets are stored in PS3.10 files on disk with transfer syntax 1.2.840.10008.1.2.4.70 (JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1])). When I store the data sets in the archive via STOW-RS and then retrieve them back via WADO-RS using media type application/dicom (without specifying any transfer syntax in the dcm-parameters), the data sets are returned in the same transfer syntax 1.2.840.10008.1.2.4.70 (JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1])) instead of the expected transfer syntax 1.2.840.10008.1.2.1 (Explicit VR Little Endian).

I am running the archive (version 15.5.0) in Docker containers as described in the wiki (Docker image dcm4che/dcm4chee-arc-psql:5.15.0-secure).

The original files may not be fully compliant with the standard. Shown below are the DICOM File Meta Information Group Elements for the original file as well as the file that I stored in the archive and retrieved back (output of the file_meta attribute of pydicom.Dataset instances of the original and retrieved file):

Original file:

(0002, 0000) File Meta Information Group Length  UL: 64
(0002, 0002) Media Storage SOP Class UID         UI: CT Image Storage
(0002, 0010) Transfer Syntax UID                 UI: JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1])

Retrieved file:

(0002, 0000) File Meta Information Group Length  UL: 180
(0002, 0001) File Meta Information Version       OB: b'\x00\x01'
(0002, 0002) Media Storage SOP Class UID         UI: CT Image Storage
(0002, 0003) Media Storage SOP Instance UID      UI: XXX
(0002, 0010) Transfer Syntax UID                 UI: JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1])
(0002, 0012) Implementation Class UID            UI: 1.2.40.0.13.1.3
(0002, 0013) Implementation Version Name         SH: 'dcm4che-5.15.0'

These are the corresponding server log messages:

Storage via STOW-RS:

2018-12-23 17:07:38,597 WARN  [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-23) RESTEASY002142: Multiple resource methods match request "POST /aets/DCM4CHEE/rs/studies". Selecting one. Matching methods: [public void org.dcm4chee.arc.stow.StowRS.storeInstancesJSON(javax.ws.rs.container.AsyncResponse,java.io.InputStream) throws java.lang.Exception, public void org.dcm4chee.arc.stow.StowRS.storeInstancesXML(javax.ws.rs.container.AsyncResponse,java.io.InputStream) throws java.lang.Exception]
2018-12-23 17:07:38,597 INFO  [org.dcm4chee.arc.stow.StowRS] (default task-23) Process POST /dcm4chee-arc/aets/DCM4CHEE/rs/studies from null@172.2.0.8
2018-12-23 17:07:38,597 INFO  [org.dcm4chee.arc.stow.StowRS] (default task-23) storeInstances: Extract Part #1{content-type=[application/dicom]}
2018-12-23 17:07:38,607 INFO  [org.dcm4chee.arc.store.impl.StoreServiceEJB] (default task-29) null@172.2.0.8->DCM4CHEE: Create Instance[pk=XXX, uid=XXX, class=1.2.840.10008.5.1.4.1.1.2, no=35]
2018-12-23 17:07:38,608 INFO  [org.dcm4chee.arc.store.impl.StoreServiceEJB] (default task-29) null@172.2.0.8->DCM4CHEE: Create Location[pk=XXX, systemID=fs1, path=XXX, tsuid=1.2.840.10008.1.2.4.70, size=174066, status=OK, objectType=DICOM_FILE]

Retrieval via WADO-RS:

2018-12-26 12:42:50,953 INFO  [org.dcm4chee.arc.wado.WadoRS] (default task-244) Process GET /dcm4chee-arc/aets/DCM4CHEE/rs/studies/XXX/series/XXX/instances/XXX from null@172.2.0.8
2018-12-26 12:42:50,955 INFO  [org.dcm4chee.arc.wado.WadoRS] (default task-244) retrieveInstance: 1 Matches