doubly entered DICOM tag - second entry not treated

[Paul Summers]

Hi, 

running DicomBrowser (1.5.2) on images exported from our PACS. 

(one slice one file).

On looking at the header information with imageJ afterwards, I found

 that the Patient ID 0010,0020 appeared twice in the listing

     the first had been treated, 

     the second had not been treated

going back to the images as they came off the PACS, imageJ shows the 

double entry of the patient ID was present.

DICOMBrowser on the results of the first run see only the treated first entry.

a way treat both both?

Paul

[Paul Summers]

Further pieces of information... 

The original image DICOM as reported by ImageJ includes:

0010,0020  Patient ID: CC11

0010,0030  Patient's Birth Date: 19520XXX

0010,0040  Patient's Sex: Z 

0010,0020  Patient ID: CC11

 

after running clear on 0010,0020 and 0010,0030 imageJ shows:

0010,0020  Patient ID:   

0010,0030  Patient's Birth Date: 

0010,0040  Patient's Sex: M 

0010,0020  >Patient ID: CC11

and DICOMBrowser shows a null entry for 0010,0020

If I run with delete 0010,0020 instead of clear, imageJ shows:

 

0010,0030  Patient's Birth Date: 

0010,0040  Patient's Sex: M 

0010,0020  >Patient ID: CC11

and DICOMBrowser doesn't show any 0010,0020 field in the result, 

[Paul Summers]

with MicroDicom it looks like the second patient ID has been nested inside another DICOM Field (type SQ)

(0010,1002) OtherPatientIDsSequence SQ 1 26

   (0010,0020) PatientID LO 1 10 CC11

the same sort of thing comes up for other items that get prefaced by > when 

I list in ImageJ after a run through DICOMBrowser. 

 (0008,1140) ReferencedImageSequence SQ 1 306

   (0008,1150) ReferencedSOPClassUID UI 1 26 1.2.840.10008.5.1.4.1.1.4 

Is there  a way to treat these nestings (apart from from clearing or deleting (0010,1002)) with DICOMBrowser?

On Monday, 19 June 2017 21:15:13 UTC+2, Paul Summers wrote: