Orthanc different versions with CornerstoneJS

Google Groups archive
1

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.

2

Hi Paul,

The /file route has not changed between 1.5.8 and 1.10. From your dumps, it seems you are missing the DICOM header.

So I’m as clueless as you on this … I would start investigating by accessing the /file routes with curl calling Orthanc directly (not nginx) …

Best regards,

Alain.

3

Hi Alain,

Thank you so much for looking at this. Coincidentally just as your message arrived, I found the problem and of course it was not related to Orthanc but my code.

Your suggestion was a good one and was the approach I used, comparing the result of using curl with my upload code, checking the metadata, and by adding checksums at different stages in my upload code I found that I had indeed corrupted the DICOM.

So all along, the message from CornerstoneJS was appropriate, Orthanc was working as expected and I was looking for problems in the wrong place. What confused me was that the corrupted instance could still be displayed by the Orthanc Web Viewer. Gah!

Best wishes,
Paul