Orthanc Dicom Web does not return tag 0028,3002

Google Groups archive
1

Hi Author,
I am reporting that my Orthanc (1.9.7) does not show up the dicom tag 0028,3002 from wado-rs response. I attached the dicom file. Below is my configuration of dicomweb. Can you please help to identify if this is a bug or not ? Thanks in advance

“DicomWeb” : {
“Enable” : true, // Whether DICOMweb support is enabled
“Root” : “/wado-rs/”, // Root URI of the DICOMweb API (for QIDO-RS, STOW-RS and WADO-RS)
//“Root” : “/dicom-web/”, // Root URI of the DICOMweb API (for QIDO-RS, STOW-RS and WADO-RS)
“EnableWado” : true, // Whether WADO-URI (previously known as WADO) support is enabled
“WadoRoot” : “/wado”, // Root URI of the WADO-URI (aka. WADO) API
“Ssl” : false, // Whether HTTPS should be used for subsequent WADO-RS requests
“QidoCaseSensitive” : true, // For QIDO-RS server, whether search is case sensitive (since release 0.5)
“Host” : “localhost”, // Hard-codes the name of the host for subsequent WADO-RS requests (deprecated)
“StudiesMetadata” : “MainDicomTags”, // How study-level metadata is retrieved (since release 1.1, cf. section below)
//“SeriesMetadata” : “Full”, // How series-level metadata is retrieved (since release 1.1, cf. section below)
“SeriesMetadata” : “MainDicomTags”, // How series-level metadata is retrieved (since release 1.1, cf. section below)

}

This is the curl that I used:
curl localhost:8042/wado-rs/studies/123.29504904546855.1759306394197888/series/1.2.840.113564.1921680219.202303030803516685/instances/1.2.840.113564.1921680219.202303030803516686.2203801020003/metadata

The dicom file can be downloaded from : https://drive.google.com/file/d/1iXpUcYUtKFbEvJFvHVRhW8TTXBCYQhKC/view?usp=sharing

2

Hi Tran,

I confirm I could reproduce your issue and this seems to be a bug. I have created an issue with that.

Best regards,

Alain

3

Hi Alain,
Thanks a lot for your promt reply. In addtion to my above question, it would be nice if Orthanc can support LUT Data (0028, 3006) also in wado-rs query like this

Screenshot from 2023-03-14 16-42-15.png

4

Hi,
Here are my findings on the issue, I tried to debug to this file FromeDcmtkBridge.cpp , in static function ApplyVisitorToLeaf. Seems like Orthanc does not handle the case of EVR_xs and EVR_lt (which this thread mentioned )
I tried a work around by recasting the EVR_xs to EVR_US and EVR_lt to EVR_OW. DicomWeb can see the tags. Of course, this is not an ideal solution, but for ones who get this bug in their viewer, they can think of recasting solution.

00283010": {
“Value”: [
{
“00283002”: {
“Value”: [
4096,
0,
12
],
“vr”: “US”
},
“00283006”: {
“BulkDataURI”: “http://localhost/wado-rs/studies/123.29504904546855.1759306394197888/series/1.2.840.113564.1921680219.202303030803516685/instances/1.2.840.113564.1921680219.202303030803516686.2203801020003/bulk/00283010/1/00283006”,
“vr”: “OW”
}
}
],
“vr”: “SQ”
},

These are lines I added to the static function

static bool ApplyVisitorToLeaf(DcmElement& element,
ITagVisitor& visitor,
const std::vector& parentTags,
const std::vector<size_t>& parentIndexes,
const DicomTag& tag,
Encoding encoding,
bool hasCodeExtensions)
{
// TODO - Merge this function, that is more recent, with ConvertLeafElement()

assert(element.isLeaf());

DcmEVR evr = element.getTag().getEVR();

if (evr == EVR_xs) {
evr = EVR_US;
}

if (evr == EVR_lt) {
evr = EVR_OW;
}

5

Hi Tran,

I have implemented your proposed fix: https://hg.orthanc-server.com/orthanc/rev/f9ab3aec3bed

It is indeed not an ideal solution but it is a “best guess” that should generally improve things (DCMTK toolkit is doing the same kind of assumption: https://forum.dcmtk.org/viewtopic.php?t=932)

Thanks and best regards,

Alain.