Understanding DICOM-Read write MRI images - DICOM

This is a discussion on Understanding DICOM-Read write MRI images - DICOM ; Hi.. I am trying to understand the DICOM format to enable me to read and write RAW DICOM files (RAW- K-space dicom files in MRI) in MATLAB or C++. (I know there is dicomread in Matlab but it for some ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Understanding DICOM-Read write MRI images

  1. Understanding DICOM-Read write MRI images

    Hi..
    I am trying to understand the DICOM format to enable me to read and
    write RAW DICOM files (RAW- K-space dicom files in MRI) in MATLAB or
    C++. (I know there is dicomread in Matlab but it for some reason
    doesn't read the raw dicom files. The images are not compressed ones-I
    checked the header)

    Can any one help me in getting the right material, one that doesn't
    give a lot of irrelavant information about DICOM image transfer
    protocol stuff, but goes straight to the point of understanding the
    FILE FORMAT OF DICOM images.
    >From what I gathered so far from my search and reading is that it

    changes from modality to modality..based the the data elements defined.
    So I am specifically looking for an MRI image DICOM example to
    demonstrate how to read and Write a sample MRI image.

    Thanks in advance.
    Jaladhar.


  2. Re: Understanding DICOM-Read write MRI images

    jaladhar@gmail.com wrote:
    > Hi..
    > I am trying to understand the DICOM format to enable me to read and
    > write RAW DICOM files (RAW- K-space dicom files in MRI) in MATLAB or
    > C++. (I know there is dicomread in Matlab but it for some reason
    > doesn't read the raw dicom files.


    MATLAB Dicom Reader breaks on a lot of 'Dicom images'.

    The images are not compressed ones-I
    > checked the header)
    >


    I'm affraid RAW DICOM files are, of course 'Dicom Files', but *not*
    Dicom images.
    (in a so called 'Dicom file', you can have 'Structured Reports', or 'pdf
    docs', or 'Wave forms', and so on.)


    > Can any one help me in getting the right material, one that doesn't
    > give a lot of irrelavant information about DICOM image transfer
    > protocol stuff, but goes straight to the point of understanding the
    > FILE FORMAT OF DICOM images.


    Could you have a look at
    http://www.creatis.univ-lyon1.fr/Public/Gdcm

    gdcm is an open source library to read Dicom images. It comes with a
    PrintFile program, that prints all the elements of the file header,
    and a vtmgdcmViewer, that displays the image, and a ReWrite program (it
    works on 150 images from different sources).

    If they break, could you send me one or your 'Raw Dicom file', in order
    to help me to fix 'gdcm' library.

    Thx

    Jean-Pierre Roux


    >>From what I gathered so far from my search and reading is that it

    > changes from modality to modality..based the the data elements defined.
    > So I am specifically looking for an MRI image DICOM example to
    > demonstrate how to read and Write a sample MRI image.
    >
    > Thanks in advance.
    > Jaladhar.
    >


  3. Re: Understanding DICOM-Read write MRI images

    jaladhar@gmail.com wrote:
    > Hi..
    > I am trying to understand the DICOM format to enable me to read and
    > write RAW DICOM files (RAW- K-space dicom files in MRI) in MATLAB or
    > C++. (I know there is dicomread in Matlab but it for some reason
    > doesn't read the raw dicom files.


    MATLAB Dicom Reader breaks on a lot of 'Dicom images'.

    The images are not compressed ones-I
    > checked the header)
    >


    I'm affraid RAW DICOM files are, of course 'Dicom Files', but *not*
    Dicom images.
    (in a so called 'Dicom file', you can have 'Structured Reports', or 'pdf
    docs', or 'Wave forms', and so on.)


    > Can any one help me in getting the right material, one that doesn't
    > give a lot of irrelavant information about DICOM image transfer
    > protocol stuff, but goes straight to the point of understanding the
    > FILE FORMAT OF DICOM images.


    Could you have a look at
    http://www.creatis.univ-lyon1.fr/Public/Gdcm

    gdcm is an open source library to read Dicom images. It comes with a
    PrintFile program, that prints all the elements of the file header,
    and a vtmgdcmViewer, that displays the image, and a ReWrite program (it
    works on 150 images from different sources).

    If they break, could you send me one or your 'Raw Dicom file', in order
    to help me to fix 'gdcm' library.

    Thx

    Jean-Pierre Roux


    >>From what I gathered so far from my search and reading is that it

    > changes from modality to modality..based the the data elements defined.
    > So I am specifically looking for an MRI image DICOM example to
    > demonstrate how to read and Write a sample MRI image.
    >
    > Thanks in advance.
    > Jaladhar.
    >


  4. Re: Understanding DICOM-Read write MRI images



    jaladhar@gmail.com wrote:
    > Hi..
    > I am trying to understand the DICOM format to enable me to read and
    > write RAW DICOM files (RAW- K-space dicom files in MRI) in MATLAB or
    > C++. (I know there is dicomread in Matlab but it for some reason
    > doesn't read the raw dicom files... >



    DICOM Raw format is a way to put a standard DICOM wrapper around vendor
    proprietary data so that it can be stored into, searched for, and
    retrieved from a PACS (or equivalent) using standard DICOM network
    services. Even though the header is dicom standard, the payload data is
    proprietary; thus, the standard says nothing about how the data is
    formated.

    To get that information, you will have to consult vendor documentation
    or get information developed through reverse engineering.

    The manufacture, model, and version should be documented in the
    equipment module tags for the raw object you're trying to read. Dump
    the dicom headers of the file and post the contents of the attributes
    (0008,0070) - manufacture, (0008,1090) manufacture model, and
    (0018,1020) Software Version(s) to this group. With that information
    someone may be able answer your inquiry. Actually for best results post
    the whole dicom header (with patient identity information removed).


  5. Re: Understanding DICOM-Read write MRI images

    Thank you Roux and Eric.

    Eric,
    you confused me again..i was thinking that since i know the matrix
    size..i can subtract the matrix size*2bits from the file size and start
    reading the file from there in little endian format. I tried that and
    was sort of getting some result which looked like a K-space image. But
    didnt turn out to be true. That prompted me that I was on the right
    track..but you confused me again.

    Any suggestions?

    Thank you,
    Jaladhar.


  6. Re: Understanding DICOM-Read write MRI images

    jaladhar@gmail.com wrote:
    > Thank you Roux and Eric.
    >
    > Eric,
    > you confused me again..i was thinking that since i know the matrix
    > size..i can subtract the matrix size*2bits from the file size and start
    > reading the file from there in little endian format. I tried that and
    > was sort of getting some result which looked like a K-space image.


    It *looked* like a good idea.
    But ...
    'true' Dicom images may have 'trailing information', i.e. data *after*
    the pixels. If you want your program to work on any kind of Dicom Image,
    you just may not 'start from file end of the file'

    > But
    > didnt turn out to be true. That prompted me that I was on the right
    > track..but you confused me again.


    Moreover, raw data may have 'line headers', i.e. some 'human readable'
    information at the beginning of the *each* line.
    If the constructor dosn't want to give you these informations, you just
    have to try to *guess* them, reading 'hexedit' output.
    Jean-Pierre Roux
    >
    > Any suggestions?
    >
    > Thank you,
    > Jaladhar.
    >


  7. Re: Understanding DICOM-Read write MRI images

    Thanks again Mr. Roux,

    Did you mean that in a "raw" Dicom file, the pixel data is not all
    contiguous but has some meta-information in between the stored pixel
    data lines? In that case, my approach is doomed. I might have to take
    the hard approach of reading the file tag by tag. I just not mentally
    prepared to do that yet..... please let me know ur opinion .

    Also, what exactly does the StartOfPixelData -

    7FE0 0010 PixelData OWOB 1

    mean? Does it mean the pixel data starts at the address specified in
    the VL of this tag?. Actually, I have checked this...and there is an
    offset between the value specified in VL and the actual pixel data
    start. The offset varies from file to file (even for the same matrix
    size images).

    Please comment.

    Thank You,
    Jaladhar.

    Jean-Pierre Roux wrote:
    > jaladhar@gmail.com wrote:
    > > Thank you Roux and Eric.
    > >
    > > Eric,
    > > you confused me again..i was thinking that since i know the matrix
    > > size..i can subtract the matrix size*2bits from the file size and start
    > > reading the file from there in little endian format. I tried that and
    > > was sort of getting some result which looked like a K-space image.

    >
    > It *looked* like a good idea.
    > But ...
    > 'true' Dicom images may have 'trailing information', i.e. data *after*
    > the pixels. If you want your program to work on any kind of Dicom Image,
    > you just may not 'start from file end of the file'
    >
    > > But
    > > didnt turn out to be true. That prompted me that I was on the right
    > > track..but you confused me again.

    >
    > Moreover, raw data may have 'line headers', i.e. some 'human readable'
    > information at the beginning of the *each* line.
    > If the constructor dosn't want to give you these informations, you just
    > have to try to *guess* them, reading 'hexedit' output.
    > Jean-Pierre Roux
    > >
    > > Any suggestions?
    > >
    > > Thank you,
    > > Jaladhar.
    > >



  8. Re: Understanding DICOM-Read write MRI images

    jaladhar@gmail.com wrote:
    > Thanks again Mr. Roux,
    >
    > Did you mean that in a "raw" Dicom file, the pixel data is not all
    > contiguous but has some meta-information in between the stored pixel
    > data lines?


    Well...
    3 times in my life, I had to deal with so called 'raw data'.
    Once I 'discovered' there was a 128 human redable 'line header'.
    I just skipped it, and the PhD Student semmed to be happy with the data...

    2 times, I was unable to understand anything about the 'PixelData'
    structure.
    I just gave up :-(

    In that case, my approach is doomed. I might have to take
    > the hard approach of reading the file tag by tag. I just not mentally
    > prepared to do that yet.....


    Even if you were, that would be useless : 'tag by tag reading' would
    show you a lot of stuff you probabely don't care.
    One of the tags is 7FE0 0010, and it's still up to you to do want you
    want/can with it.
    Don't expect Dicom Header to give you any help ...

    JP

    please let me know ur opinion .
    >
    > Also, what exactly does the StartOfPixelData -
    >
    > 7FE0 0010 PixelData OWOB 1
    >
    > mean? Does it mean the pixel data starts at the address specified in
    > the VL of this tag?. Actually, I have checked this...and there is an
    > offset between the value specified in VL and the actual pixel data
    > start. The offset varies from file to file (even for the same matrix
    > size images).
    >
    > Please comment.
    >
    > Thank You,
    > Jaladhar.
    >
    > Jean-Pierre Roux wrote:
    >
    >>jaladhar@gmail.com wrote:
    >>
    >>>Thank you Roux and Eric.
    >>>
    >>>Eric,
    >>>you confused me again..i was thinking that since i know the matrix
    >>>size..i can subtract the matrix size*2bits from the file size and start
    >>>reading the file from there in little endian format. I tried that and
    >>>was sort of getting some result which looked like a K-space image.

    >>
    >>It *looked* like a good idea.
    >>But ...
    >>'true' Dicom images may have 'trailing information', i.e. data *after*
    >>the pixels. If you want your program to work on any kind of Dicom Image,
    >>you just may not 'start from file end of the file'
    >>
    >>
    >>>But
    >>>didnt turn out to be true. That prompted me that I was on the right
    >>>track..but you confused me again.

    >>
    >>Moreover, raw data may have 'line headers', i.e. some 'human readable'
    >>information at the beginning of the *each* line.
    >>If the constructor dosn't want to give you these informations, you just
    >>have to try to *guess* them, reading 'hexedit' output.
    >> Jean-Pierre Roux
    >>
    >>>Any suggestions?
    >>>
    >>>Thank you,
    >>>Jaladhar.
    >>>

    >
    >


+ Reply to Thread