dicom order

[michaelf500]

Hi

I'm using images from a GE scanner, just to see how it works. The scanner exports dicom Images as individual 2D slices. The resolute program looks to be reading them ok, but the slices seem to be sorted purely by filename. However, the slice ordering of my dicoms is not consistent ( dicom0001 may be slice 15, dicom0002 is slice 89 etc)

Because the slice ordering of the dicoms is not the same across the two echoes, I got an error message Description: itk::ERROR: ResoluteImageFilter(0x2beadd0): Inputs do not occupy the same physical space! I named the files to have consistent filenames according to the slice number, which did then run without displayed errors.

However, I had numbered them as 1 (top of head) to 120 neck, and found that resolute created an upside down image, with resulting terrible spatial normalisation / segmentation.

Having renamed the files again to go from 1 (neck) to 120 top of head, the image is the right way round, and the result does look sensible

I think this non sequential dicom is not unusual, so ideally, the code would be altered to sort the dicom slices according to their z axis location before further processing.

Best wishes

Michael

[bathomas]

Hi Michael,

I've tweaked the code to sort based on Image number (0x0020,0x0013). The code is on the dicom-sort branch. Can you try this out? If the images are still upside down, then we'll either need to sort on the physical slice location or add a z-flip switch.

Kind regards,

Ben

[KrisThielemans]

I'm 99% sure the Dicom standard for PET says that they should be sorted on ImageIndex. The coordinates fo the slices are then determined by the cross-product of the 2 ImageOrientationPatient vectors if memory serves me right.

Of course, I don't know if the GE MRAC files follow the PET DICOM standard, but this particular thing might be common to other modalities.

[michaelf500]

Thanks

The dicom-sort branch does now sort the images, but the head is upside down.

I'm happy to test any further modifications, but I'm not sure if I'll be doing anything useful with the code, since the GE MRAC are not particularly compatible with the resolute scheme - There is: 1) a standard MRAC which has dual echo ~ 1 & 2 ms , 2) the 'zero te' MRAC which has only one echo , and is at a different resolution and slice coverage to the standard MRAC

plotting the joint histogram, as far as I can tell, the bone does not look as neatly separated from the rest of the tissue as it appears on the Siemens, so I think it would be a bit of effort to get it to work nicely. I'm open to persuasion though.

The standard AC method for the head is going to be updated with the next software release (whenever that happens), so will be interesting to see what that is like.