Loading 4D DICOM dataset on PACS

[hyper...@yahoo.com]

Hi,

I saved the DICOM files received from the scanner as binary data and
then processed them and then converted these files into DICOM files
using IDL. When I push the DICOM files to PACS, all 3D data sets are
fine. I can view them clearly.

I have a 4D data sets (512x512x7x60). I can convert them into DICOM
files and when I push them to PACS, I can only see the 1st seven
slices. The total number of slices for that series is 7 instead of 420
slices. However, I can view all 420 slices on the other DICOM viewers
like Acculite, ImageJ, DICOM Works and MRIcro.

I checked all the header information. I could not find the reason. Can
anybody tell me what header information should I change to make it a 4D
data on PACS.

Thanks,
HJ.

[eric.g...@gmail.com]

> I have a 4D data sets (512x512x7x60). I can convert them into DICOM
> files and when I push them to PACS, I can only see the 1st seven
> slices. The total number of slices for that series is 7 instead of 420
> slices. However, I can view all 420 slices on the other DICOM viewers
> like Acculite, ImageJ, DICOM Works and MRIcro.

What are your four dimensions? 512x512 looks pretty obvious rows and
colums (e.g. X and Y) but 7x60? Are you talking about raw acquisition
data which is reconstructed into 60 time steps, each time step
consisting of 420 * 512x512 image slices?

Really more to the point, what modality, DICOM SOP Class, and PACS are
you talking about? Based on your subsequent discussion of 420 slices,
one presumes talking about CT or MR. When processing and converting to
DICOM the device would likely break apart into individual image slice
objects (unless you know they are in fact using one of the newer
enhanced CT or enhanced MR multiframe objects). This would explain
why external applications correctly receive and recombine the
individual images into the expected data organization. On the other
hand if your "PACS" is a machine/workstation associated with device
itself, perhaps it is not actually turning the raw data into DICOM
images and is instead sending one large proprietary file? Perhaps you
are running into a maximum size or index problem in that format?

[hyper...@yahoo.com]

It is MR data set of size 512x512x7x60 (x,y,z,timepoints). I have few
images in 3D format (512x512x7) which was also converted into DICOM
images after processing the raw data. They are viewed clearly with no
problem on PACS. I am not sure what header information might be very
critical for 4D dataset to be viewed on PACS. There are 420 images in
DICOM format and I can view them on all other DICOM readers but PACS
shows only 7 of them. When I push 420 images to PACS, it says all 420
was sent but PACS receives the first 7 only.

Can anybody suggest some DICOM tags that are critical for 4D data sets.

Thanks,
HJ.

[David Clunie]

Hi

Sorting out the "dimensions" of a set of DICOM images is in
general a non-trivial problem, but is largely a question of
conforming to patterns of spatial and timing information that
the receiver can make sense of retrospectively.

For example, do all the images at different times but the same
location in space have the same value for Image Position (Patient)
and Image Orientation (Patient) ? They should.

Do all the images acquired at or close to the same time have the
same or similar Acquisition Time value, sufficiently different
from the Acquisition Time of other images ? It is in general
quite hard for the receiver to sort out what belongs in the
same "time slot" when there are small differences in time
that don't matter and larger differences that do, if you get
my meaning.

Some receivers are just not capable of this sort of re-sorting,
and just sort by Instance Number or spatial position alone;
others expect the separate "time slots" to be in separate
series. Others pay more attention to Content (Image) Time
rather than Acquisition Time, though they probably shouldn't.

These are some of the reasons that the new enhanced family of
MR image objects are multi-frame, have unambiguous timing
information, and have explicit dimensions. The sooner folks
start to use these instead, and the sooner PACS vendors
support them, the better.

Can you put these on an ftp site somewhere that I can take a
look at them ? It is possible that you have just left out
something or made a simple error if you reconstructed them
yourself, or used some research tool to do it. I can make
a site available to you if you do not have one.

David

[hyper...@yahoo.com]

Can you please provide me with a site where I can upload the images. I
verified the Image position, Image orientation, acquisition time and
also Instance IDs. I am not able to think of any other header
information.

Thanks a lot for your time,
Akhila.

[Mathieu Malaterre]

What David is saying is that your DataSet might be fine for one system,
but not for another. Looking at your case I could bet this is a DWI/DTI
aquisition, do you know ? If so then I have seen to different protocol:
PMS and GEMS. PMS will do the 7 aquisition at the exact same position
(incrementing the Instance Number) for the tensor component then move
on to the next position. Therefore you can order the Series by
InstanceNumber and take let say the 3d image every 7 images to
reconstruct a volume of one component of your tensor images. On the
other hand GEMS is doing the contrary. If you order all the slices
using the Instance Number you pretty much sorted all your subvolumes
sequencially...

2 cents
Mathieu