Private tags with group >7FE0 are not provided via REST API

General
1

Find the attached DICOM instance:
08137b37-f373-4931-958e-e89d5e78ff39.dcm (129.7 KB)
And using this private dictionary:

(8e05,"XEOS_Attributes",1000)	LO	ImagingCategory	1	PrivateTag
(8e05,"XEOS_Attributes",1001)	LO	ImagingType	1	PrivateTag
(8e05,"XEOS_Attributes",1002)	LO	PhantomType	1	PrivateTag
(8e05,"XEOS_Attributes",1003)	DS	RadionuclideActivityConcentration	1	PrivateTag
(8e05,"XEOS_Attributes",1004)	CS	ContainerOrientationSpecified	1	PrivateTag
(8e05,"XEOS_Attributes",1005)	CS	ContainerOrientationSymbology	4	PrivateTag
(8e05,"XEOS_Attributes",1006)	CS	ContainerOrientationDirection	4	PrivateTag

dcmdump is capable of properly displaying the right private attributes:

(0028,1053) DS [1.0]                                    #   4, 1 RescaleSlope
(0040,0280) ST (no value available)                     #   0, 0 CommentsOnThePerformedProcedureStep
(7fe0,0010) OB (PixelSequence #=2)                      # u/l, 1 PixelData
  (fffe,e000) pi 00\00\00\00                              #   4, 1 Item
  (fffe,e000) pi ff\d8\ff\e0\00\10\4a\46\49\46\00\01\01\00\00\01\00\01\00\00\ff\c3... # 131142, 1 Item
(fffe,e0dd) na (SequenceDelimitationItem)               #   0, 0 SequenceDelimitationItem
(8e05,0010) LO [XEOS_Attributes]                        #  16, 1 PrivateCreator
(8e05,1000) LO [acquisition]                            #  12, 1 ImagingCategory
(8e05,1001) LO [specimen]                               #   8, 1 ImagingType
(8e05,1004) CS [NO]                                     #   2, 1 ContainerOrientationSpecified
(8e05,1005) CS [LETTERX\CIRCLE\SQUARE\TRIANGLE]         #  30, 4 ContainerOrientationSymbology
(8e05,1006) CS [INFERIOR\LEFT\RIGHT\SUPERIOR]           #  28, 4 ContainerOrientationDirection

But when stored in an Orthanc instance (and correctly referring to the private dictionary file on "ExternalDictionaries", a call to /tags and /tags/?simplify does not display these private tags. Nevertheless, /content acknowledges the presence of such private tags. We could not find a valid way of retrieving the values of the private tags via the REST API.

We noticed that if we change the group to 0e05 then /tags and /tags/?simplify successfully provides the values.

Is this expected behavior by Orthanc? What is the reason?

Thank you!

2

Hello,

Yes, this is the expected behavior (in other words, this is a feature, not a bug).

The rationale here is that Orthanc tries to reduce as much as possible the accesses to its storage area. Indeed, such accesses can be expansive, both in terms of money and speed (think about a cloud storage such as AWS S3). To this end, Orthanc does its best to avoid reading after the pixel data tag (7FE0,0010), because pixel data represents the largest portion of a DICOM instance. Furthermore, most DICOM instances in the real world have their pixel data tag as their final tag.

This explains why the route /instances/{id}/tags stops its processing at (7FE0,0010). In your case, because your tags are stored after pixel data, they are not reported by this route.

I acknowledge that this can represent an issue when working with DICOM instances generated by manufacturers who use custom, private tags. However, higher speed and lower bandwidth is more important for most users.

To provide a solution in your context, I have just added a ?whole option to the route /instances/{id}/tags, which allows to get tags past pixel data, at the expanse of reading the full DICOM file from the storage area. Here is an example session using your DICOM file:

$ curl 'http://localhost:8042/instances/37ab62a9-ec978081-61085bab-febc13c7-c2e652ae/tags?short&whole'
{
   "0008,0005" : "ISO_IR 192",
   "0008,0008" : "ORIGINAL\\PRIMARY\\AXIAL",
   "0008,0016" : "1.2.840.10008.5.1.4.1.1.2",
   "0008,0018" : "1.2.276.0.7230010.3.1.4.8323329.2280.1717059859.484653",
   [...]
   "7fe0,0010" : null,
   "8e05,0010" : "XEOS_Attributes",
   "8e05,1000" : "acquisition",
   "8e05,1001" : "specimen",
   "8e05,1004" : "NO",
   "8e05,1005" : "LETTERX\\CIRCLE\\SQUARE\\TRIANGLE",
   "8e05,1006" : "INFERIOR\\LEFT\\RIGHT\\SUPERIOR"
}

This feature is implemented by the following changeset, that will be part of forthcoming release 1.12.4 of Orthanc: orthanc: f048683aa619

Kind Regards,
SĂ©bastien-

2 Likes
3

Hello SĂ©bastien,

Thank you very much for your detailed explanation and moreover for the work you have put for supporting this use case!

Kind regards,
Guillem.

1 Like