Firstly, I think Orthanc is great - thank you! Secondly, I’m no DICOM expert, but I’m trying to learn.
I have a web app which uses CornerstoneJS configured to display a DICOM instance from Orthanc, using the cornerstoneWADOImageLoader library. I’ve configured this to fetch an instance via the REST API call and using this URL:
wadouri:https://my.server/orthanc/instances/163c43b7-84e6ed46-8f0a18e8-20b7893b-96a070e2/file
(Orthanc is hosted behind Nginx, and the ‘orthanc’ in the URL above represents a reverse proxy in the Nginx site config. I’m doing this to avoid CORS problems.)
My query is: if I run this on Ubuntu 20.04, which has Orthanc 1.5.8, this does not work, and I get an error back from Cornerstone saying
“dicomParser.readPart10Header: DICM prefix not found at location 132 - this is not a valid DICOM P10 file”
If I run the same code on Ubuntu 22.04 which has Orthanc 1.10.0, it works as expected.
I don’t see anything in the Orthanc REST docs to say that this API call has changed or to expect a different result, but clearly I’m getting a different result.
If I download the instance data from both server versions and save to a file, I can open the image in a viewer such as Weasis.
If I dump the DICOM tags using the dcm4che ‘dcmdump’ utility, they both look like DICOM images but certainly the tags are not the same:
The file from Orthanc 1.10 that works has tags that start like this:
0: [0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
132: (0002,0000) UL #4 [178] FileMetaInformationGroupLength
144: (0002,0001) OB #2 [0\1] FileMetaInformationVersion
158: (0002,0002) UI #26 [1.2.840.10008.5.1.4.1.1.4] MediaStorageSOPClassUID
192: (0002,0003) UI #46 [1.3.12.2.1107.5.2.5.11090.5.0.5823690860022483] Media
246: (0002,0010) UI #20 [1.2.840.10008.1.2.1] TransferSyntaxUID
274: (0002,0012) UI #18 [1.2.40.0.13.1.1.1] ImplementationClassUID
300: (0002,0013) SH #14 [dcm4che-1.4.29] ImplementationVersionName
322: (0008,0005) CS #10 [ISO_IR 100] SpecificCharacterSet
340: (0008,0008) CS #36 [ORIGINAL\PRIMARY\M\HEADER_CORRECTED] ImageType
384: (0008,0016) UI #26 [1.2.840.10008.5.1.4.1.1.4] SOPClassUID
418: (0008,0018) UI #46 [1.3.12.2.1107.5.2.5.11090.5.0.5823690860022483] SOPIn
472: (0008,0020) DA #8 [20040305] StudyDate
488: (0008,0021) DA #8 [20040305] SeriesDate
504: (0008,0022) DA #8 [20040305] AcquisitionDate
520: (0008,0023) DA #8 [20040305] ContentDate
The file from Orthanc 1.5.8 that does not work has tags that start like this:
0: (0008,0005) CS #10 [ISO_IR 100] SpecificCharacterSet
18: (0008,0008) CS #36 [ORIGINAL\PRIMARY\M\HEADER_CORRECTED] ImageType
62: (0008,0016) UI #26 [1.2.840.10008.5.1.4.1.1.4] SOPClassUID
96: (0008,0018) UI #46 [1.3.12.2.1107.5.2.5.11090.5.0.5823661031981777] SOPIns
150: (0008,0020) DA #8 [20040305] StudyDate
166: (0008,0021) DA #8 [20040305] SeriesDate
182: (0008,0022) DA #8 [20040305] AcquisitionDate
198: (0008,0023) DA #8 [20040305] ContentDate
Presumably the quick solution is just to upgrade to newer Orthanc, but I’m curious to learn why there is this difference, what I’m doing wrong and if I can can get around this difference in the Cornerstone loader so I am not restricted to specific versions of Orthanc.
Has anyone had any success with CornerstoneJS and Orthanc using this REST call that could help me?
Thank you for any tips, pointers or suggestions.