Loading 4D DICOM dataset on PACS - DICOM

This is a discussion on Loading 4D DICOM dataset on PACS - DICOM ; 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 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Loading 4D DICOM dataset on PACS

  1. Loading 4D DICOM dataset on PACS

    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.


  2. Re: Loading 4D DICOM dataset on PACS


    > 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?


  3. Re: Loading 4D DICOM dataset on PACS

    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.


    eric.goodall@gmail.com wrote:
    > > 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?



  4. Re: Loading 4D DICOM dataset on PACS

    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

    hyperjiver@yahoo.com wrote:
    > 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.
    >
    >
    > eric.goodall@gmail.com wrote:
    >>> 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?

    >


  5. Re: Loading 4D DICOM dataset on PACS

    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.

    David Clunie wrote:
    > 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
    >
    > hyperjiver@yahoo.com wrote:
    > > 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.
    > >
    > >
    > > eric.goodall@gmail.com wrote:
    > >>> 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?

    > >



  6. Re: Loading 4D DICOM dataset on PACS

    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

    hyperjiver@yahoo.com wrote:
    > 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.
    >
    > David Clunie wrote:
    > > 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
    > >
    > > hyperjiver@yahoo.com wrote:
    > > > 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.
    > > >
    > > >
    > > > eric.goodall@gmail.com wrote:
    > > >>> 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?
    > > >



+ Reply to Thread