Querying for private elements without creator

[dgobbi]

Several of the command-line tools use the query functionality that is built in to vtkDICOMDirectory and vtkDICOMParser. If the query contains a private tag, the query must also contain a creator element for that tag. In order for the query to match a data set, the data set must contain the the same creator element and tag, but they may be at different locations as per the DICOM standard.

That is, if the query contains private tag gggg,xxee and creator gggg,00xx, these will be matched against private tag gggg,yyee and creator gggg,00yy in the data set, even if xx != yy.

This is all well and good, but many users try to query for private tags without the corresponding creator element, which does not work. Often, users aren't aware of what a creator element is. Following the "principle of least astonishment", there should be reasonable fallback behavior for queries that have private tags but lack the corresponding creator elements.

The desired behavior is as follows: if a private tag appears in a query,

1. if it has a creator element, it will be matched as per private tag rules
2. otherwise, it will be matched the same way that public tags are matched

[dgobbi]

There is another problem users might have with querying private tags: the "query" is stored as an explicit data set, so not only is the tag needed, but the VR is needed as well. Elements that don't have the same VR will compare false.

When a program like dicomtocsv receives an option like -k "0029,1108=SOM 5", it fails with message "Error: Unrecognized DICOM tag 0029,1108" because it does not know the VR (since it doesn't know what private dictionary the tag is defined for). To avoid this error, a user must give the VR as follows: -k "0029,1108:CS=SOM 5".

So, the user is unable to build a query for a private tag unless (a) the user knows the VR for the tab, or (b) the user knows the creator element, and furthermore, the vtk-dicom library knows the dictionary for that creator element.

I've considered setting the VR to UN if it is unknown. Then the query comparison could either (a) be done bit-for-bit or (b) the UN value could be interpreted according the the VR of the value it is being compared to. Unfortunately, this doesn't work well the query is set on the command line with "-k tag=value", since the "value" must necessarily be stored as text if the VR is unknown, but it may have to be compared to a non-text (e.g. US, SS, UL) value.

The VR could be set to UT if unknown, and the comparison code could be relaxed to allow type conversion (I already have code that matches a value of any VR to a string). It seems ugly to make an exception like this, however.

[dgobbi]

Here is a solution that would handle both the missing VR and missing creator issues. If "-k" gggg,eeee gives a tag with no creator or VR, the parser could be told to read the entire group gggg. Then the tool, rather than the parser, would be responsible for extracting the attribute from the data set and for performing the check.

The main advantage is that this does not require increasing the complexity of the parser. Instead, it involves adding a new library function that the command-line tools can call. Currently, when the tools build a query from the "-k" options, they build a taglist (vector of tag paths) and a query data set. So, "-k" would add private tags without creator or VR to the taglist, but not to the query. Then, when reporting the results, if any tag in the taglist is not in the query, then the aforementioned library function would be used.

Of course, for "-k tag=value" we would need somewhere to store the value as a string, since as stated above it would not be stored in the query data set.