Regenerate Instance Number (0020,0013) for the whole study

[NTJ]

Hello,

I'm facing a problem with the images generated by an RF system. Instance Number (0020,0013) generated by the modality deviates from DICOM standard, causing errors in the viewing/processing stations. Is it possible to regenerate Instance Number (0020,0013) for the whole study in one shot, instead of editing each image manually? Kindly advice.

[Simon Doran]

Hi NTJ,

  What algorithm do you plan to allocate the Instance Number from other information that is present in the input DICOM files? Is there other information still present in the DICOM tags that you do have that will enable you to do this?

  Best wishes,

Simon

[NTJ]

Hi Simon,

Thank you for the reply. 

I'm thinking of allocating Instance Number (0020,0013) from Acquisition Number (0020,0012) but not sure what algorithm would be ideal. For example if there are 25 Instance Numbers(0020,0013) under 1 Acquisition Number(0020,0012), I'm wondering if it would be possible to generate Instance Number as a relation of  Acquisition Number, something like:

First Instance Number = (Acquisition Number x 1000) + 1 

Second Instance Number = (Acquisition Number x 1000) + 2

Third Instance Number = (Acquisition Number x 1000) + 3

and so on

Best Regards

TJ

[David Maffitt]

Hi TJ,

What is the nature of the improperly encoded Instance Numbers?  It may be possible to map the bad values to something more appropriate using DicomEdit.

The algorithm you propose is not possible in DicomBrowser/DicomEdit because there currently is no notion of incrementing a counter by instance encounter. Perhaps the Clinical Trial Processor has such capability? https://mircwiki.rsna.org/index.php?title=CTP-The_RSNA_Clinical_Trial_Processor.

What is your intended purpose for Item Number?  Item Number is an unreliable attribute in practice.  The DICOM standard does not guarantee that it is unique in a series or even populated.  The only guaranteed unique instance attribute per series is SOPInstanceUID.  If you need an attribute that orders the instances in a series, this is usually done by stepping through the Image Position attribute (0020,0032) for the instances in the series.

It may be possible to extend DicomEdit a bit to accomplish what you need if I understand your use case better.  Any extensions would be to DicomEdit 6 which you could use from the command line.  DicomBrowser needs a bigger overhaul to be able to bump its use of DicomEdit from version 4 to 6 before you could take advantage of it in DicomBrowser.

Dave 

[NTJ]

Hi Dave,

Thank you for the response. My problem is described below :

It looks like the Modality is creating Instance Numbers with reference to Acquisition Number.

e.g. (0020,0012)Acquisition Number 00000001 has 5 images with 10 digit (0020,0013)Instance Numbers  0001000000001, 0001000000002, 0001000000003 and so on.

This is fine and the processing stations doesn't have any issue with it UNTIL the Acquisition Number reaches 00000022. Because at that time, the corresponding Instance Numbers would be 0002200000001, 0002200000003, 0002200000003 and so on. Here the problem is that the Integer Value of the tag (0020,0013) violates the DICOM standard by exceeding the limit of the Integer Value specs 2147483647 i.e (<= (2^31) -1)and the workstations fail to display the entire study. I'm looking for any means to overcome this issue, any suggestion would be highly appreciated.

Best Regards

TJ

[David Maffitt]

Hi TJ,

Would removing the portion of the instance number that is from the acquisition number work? I am puzzled by your character counts.  You say acquisition number is 10 digits but you show 13 character strings. The actual character counts matter in what follows.

Create a dicomedit script file with contents:

(0020,0013) := substring[ (0020,0013), 9, 13]

This says replace the instance-number string with characters 9 through 12 (counting from 0) from the instance-number string.  This should result in instance numbers like 0001, 0002, 0003, etc.

Then open the files in DicomBrowser,

Select 'Edit -> Apply Script...

Select the dicomedit script in the file chooser,

Apply the script,

Then save the modified dicom files.

This preserves the original ordering and removes the redundant portion of the string that causes the integer value to overflow.

More info about DicomEdit can be found here. https://wiki.xnat.org/display/XTOOLS/DicomEdit.

Note that DicomBrowser is currently stuck at DicomEdit version 4.

Dave

[NTJ]

Hi Dave,

Thank you for your inputs and sorry for the confusion regarding character count, I was under the impression that leading zeros doesn't count. 

I tried the script but it was not doing anything for a very long time with a message "reading values" at the bottom left corner. When I tried to save the modified images, it displayed an error popup "Export failed,  Error: 93 objects could not be exported,  String index Out Of Bounds Exception: String index out of range: 13". 

Then I checked the values of (0020,0013) and realized that the first 4 images had 8 characters only but the remaining images had 12 characters. So I'm wondering whether this would be the cause of the error? I've attached screenshots for your reference.

Best Regards

TJ

[NTJ]

Hi Dave,

Just wanted to update you that downloaded the latest version of DicomEdit and the script works perfectly in DicomEdit, thus solving my problem. 

Many thanks for your kind support.

Best Regards

TJ

[Maffitt, David]

Glad it worked out!
Dave

________________________________
The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.