DICOM implementation from scratch ? - DICOM

This is a discussion on DICOM implementation from scratch ? - DICOM ; Can somebody mention their experiences and pros & cons about implementing DICOM stack over and above the open source base foundation that is available from open source community Vs. approach for implementing from scratch ? Thanks for your time. - ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: DICOM implementation from scratch ?

  1. DICOM implementation from scratch ?

    Can somebody mention their experiences and pros & cons about
    implementing DICOM stack over and above the open source base foundation
    that is available from open source community Vs. approach for
    implementing from scratch ?

    Thanks for your time.

    - KA


  2. Re: DICOM implementation from scratch ?

    Unless the licensing issues give you or your management gas, I can see
    no reason to write your own. DICOM is such a huge standard (1400+
    pages) that reimplementing it from scratch would likely take several
    man years. What benefit would you gain by delaying your entry into the
    DICOM marketplace that long?

    -Kelly

    ideas2...@math.net wrote:
    > Can somebody mention their experiences and pros & cons about
    > implementing DICOM stack over and above the open source base

    foundation
    > that is available from open source community Vs. approach for
    > implementing from scratch ?
    >
    > Thanks for your time.
    >
    > - KA



  3. Re: DICOM implementation from scratch ?


    kellyatdentrix@gmail.com wrote:
    > Unless the licensing issues give you or your management gas, I can

    see
    > no reason to write your own.


    as far as the logics of modern software engineering says you should'nt
    go for implementing something from scratch especially when u can find
    it easily.

    well in some cases, especially when the costs are not feasible, I
    suggest, develop it and sell it for such low price that massive
    industries fail to compete with you.

    > DICOM is such a huge standard (1400+
    > pages) that reimplementing it from scratch would likely take several
    > man years.


    I dont know of several what you are doing with dicom, but for
    developing a pacs system which supports DICOM, it took us less than an
    year. Well it again varies as to what you want to do with the system.

    ok then,
    good luck.
    Rajesh Rapaka.


  4. Re: DICOM implementation from scratch ?

    I can't see any cons on building on top of existing open source
    software unless making a poor choice of such existing toolkits.

    As I can only talk from my own experience regarding this, I'd
    recommend, if you are going for C/C++ to check OFFIS toolkit and, as an
    option, the Mallinckrodt toolkit.

    Building one from scratch would be a huge waste of time as the above
    toolkits have been refined over a period of at least ten years.
    And, as Kelly pointed out, building a sound Dicom Toolkit is no way an
    easy task.

    HTH,
    Razvan


  5. Re: DICOM implementation from scratch ?

    Hi KA-


    > Can somebody mention their experiences and pros & cons
    > about implementing DICOM stack over


    Sure.

    I had to slam a image viewer into our our web portal. I had never
    heard of "DICOM" before 11/05. Of the Java tools I found, I either
    couldn't get them to work or didn't like them (very poor APIs).

    Knowing what I know now, I could probably hot wire something with the
    ImageJ [1] for thumbnails, some cruddy QueryRetrieve SCU and Storage
    SCU/SCP for finding and fetching images, and one of the lightweight
    applets for viewing.

    But then you'd be using 3 different libraries.

    Though I wouldn't recommend it, I'm glad I went my own way. Efficiency
    and code maintainability are important to me. My DICOM parser is truly
    streaming (no temporary buffers). I actually leverage the compiler [2]
    so that all of the VRs fit into a class hierarchy, for example class
    AbstractSyntax subclasses UID, and I have enums for all the defined
    values. Building up the dictionary and constants was a lot of work.
    The upside is no more data errors.

    Unless you're a masocist like me, or have a business case, you're
    better off hiring (or contracting) someone to do whatever customization
    work you need.


    Cheers, Jason Aaron Osgood / Seattle WA

    [1] ImageJ http://rsb.info.nih.gov/ij/

    [2] Overloading int considered harmful
    http://cafe.elharo.com/java/arguments/


  6. Re: DICOM implementation from scratch ?


    Rajesh.Rapaka wrote:
    > kellyatdentrix@gmail.com wrote:
    > > Unless the licensing issues give you or your management gas, I can

    > see
    > > no reason to write your own.

    >
    > as far as the logics of modern software engineering says you

    should'nt
    > go for implementing something from scratch especially when u can find
    > it easily.


    The logic of modern software engineering has nothing to do with the
    logic of management and risk assessment. Unfortuntately, they often
    collide.

    In my case, using GPL code was considered untenable because according
    to some interpretations of the GPL, we would then be required to
    release our entire source code under the GPL.

    Nobody in our management team wants to do that, unfortunately.

    > well in some cases, especially when the costs are not feasible, I
    > suggest, develop it and sell it for such low price that massive
    > industries fail to compete with you.


    I fail to see how this is related to the question, could you clarify?

    > > DICOM is such a huge standard (1400+
    > > pages) that reimplementing it from scratch would likely take

    several
    > > man years.

    >
    > I dont know of several what you are doing with dicom, but for
    > developing a pacs system which supports DICOM, it took us less than

    an
    > year. Well it again varies as to what you want to do with the system.


    To do a full implementation of DICOM would indeed take several man
    years. You could certainly hack together some partial implementation to
    support a piece of hardware, or a small set of IODs in a shorter
    period. But to implement EVERYTHING would be a huge job.

    -Kelly


  7. Re: DICOM implementation from scratch ?


    kellyatdentrix@gmail.com wrote:
    > > well in some cases, especially when the costs are not feasible, I
    > > suggest, develop it and sell it for such low price that massive
    > > industries fail to compete with you.

    >
    > I fail to see how this is related to the question, could you clarify?


    I was trying to figure out your possible cause for starting dicom from
    scratch !!

    > To do a full implementation of DICOM would indeed take several man
    > years. You could certainly hack together some partial implementation

    to
    > support a piece of hardware, or a small set of IODs in a shorter
    > period. But to implement EVERYTHING would be a huge job.


    I dont think so. !!


    - Rajesh Rapaka.


  8. Re: DICOM implementation from scratch ?

    >I dont think so. !!
    > Rajesh Rapaka.


    Why?

    Razvan


  9. Re: DICOM implementation from scratch ?

    My two cents ...

    1. The 2004 edition of the DICOM standard has more than 3000 pages!
    (plus a couple of approved supplements and correction proposals)

    2. It's quite unlikely that you'll ever implement the entire standard.
    This is usually neither required nor useful.

    Regards,
    Joerg Riesmeier

  10. Re: DICOM implementation from scratch ?

    Joerg Riesmeier wrote:
    > My two cents ...
    >
    > 1. The 2004 edition of the DICOM standard has more than 3000 pages!
    > (plus a couple of approved supplements and correction proposals)
    >
    > 2. It's quite unlikely that you'll ever implement the entire

    standard.
    > This is usually neither required nor useful.


    I'm implementing the entire standard, at least all of the IODs, Modules
    and Tags. I found that automatic code generation was easier if I did it
    all at once. Yeah CodeSmith!

    The hardest part was converting all 600 pages of Module tables from PDF
    into a spreadsheet.

    Now (or very soon) I can generate code that will read and write any
    subset of IODs. I didn't start from scratch, I started with a little
    package called YourDicom, but I ended up rewriting most of it because
    it was fairly buggy.

    -Kelly


  11. Re: DICOM implementation from scratch ?

    kellyatdentrix@gmail.com wrote:

    > I'm implementing the entire standard, at least all of the IODs,
    > Modules and Tags.


    These are only two parts (Part 3 and 6) out of 18 - so it's far from
    implementing the entire standard. As I wrote in my last posting:

    "It's quite unlikely that you'll ever implement the entire standard.
    This is usually neither required nor useful."

    I hope it's not clear what I was trying to say ...

    > The hardest part was converting all 600 pages of Module tables
    > from PDF into a spreadsheet.


    I agree, but this will become much easier as soon as the DICOM
    standard (at least Part 3 and 6) will be available in XML format.

    Regards,
    Joerg Riesmeier

  12. Re: DICOM implementation from scratch ?

    Joerg Riesmeier wrote:
    > kellyatdentrix@gmail.com wrote:
    > > I'm implementing the entire standard, at least all of the IODs,
    > > Modules and Tags.

    >
    > These are only two parts (Part 3 and 6) out of 18 - so it's far from
    > implementing the entire standard. As I wrote in my last posting:


    You are correct that it is not the entire standard. I'm not sure how
    much of the rest I'll eventually have to implement, but certainly the
    networking parts as well as the modality work lists are on my eventual
    list. I don't know if that constitutes the entire standard or not. I
    don't see doing the web stuff any time soon, so that's at least one
    thing I don't intend on implementing.

    > "It's quite unlikely that you'll ever implement the entire standard.
    > This is usually neither required nor useful."
    >
    > I hope it's not clear what I was trying to say ...


    :-)

    > > The hardest part was converting all 600 pages of Module tables
    > > from PDF into a spreadsheet.

    >
    > I agree, but this will become much easier as soon as the DICOM
    > standard (at least Part 3 and 6) will be available in XML format.


    If anyone is interested in my spreadsheets, I would be happy to share
    them, although they are certainly a work in progress re: accuracy. I
    looked at the XML stuff you mention, but it seemed somewhat incomplete.
    I am also excited that someone is interested in putting all that data
    in a database, where it belongs, rather than a PDF file that's not a
    very useful format for code generation or anything like that.

    -Kelly


  13. Re: DICOM implementation from scratch ?


    > The hardest part was converting all 600 pages of Module tables from PDF
    > into a spreadsheet.


    If you have access to a linux debian machine just install the xpdf-utils
    package. You'll have access to pdftotext which I use this way:

    pdftotext -f 9 -l 81 -raw -nopgbrk 04_06PU.PDF 04_06PU-3.txt

    This give a good start.

    But I agree having the dict in XML format would simply rocks !

    2 cents
    Mathieu

  14. Re: DICOM implementation from scratch ?

    On Mon, 02 May 2005 20:30:02 GMT, Mathieu Malaterre
    wrote:

    >
    >> The hardest part was converting all 600 pages of Module tables from PDF
    >> into a spreadsheet.

    >
    >If you have access to a linux debian machine just install the xpdf-utils
    >package. You'll have access to pdftotext which I use this way:
    >
    > pdftotext -f 9 -l 81 -raw -nopgbrk 04_06PU.PDF 04_06PU-3.txt
    >
    >This give a good start.
    >
    >But I agree having the dict in XML format would simply rocks !
    >
    >2 cents
    >Mathieu


    The new Acrobat (version 7) let you cut & paste directly from the PDF!

    Yves



  15. Re: DICOM implementation from scratch ?

    I cut and pasted from a Word version of the standard (actually DICOM 4)
    but it took many days to reduce it to a properly formatted spreadsheet.
    The biggest challenge was the merging of comment cells. It was truly a
    pain.

    The XML version will ROCK, when it's ready. I don't know who's really
    in charge of that... or what sort of endeavor it is (open source or
    what?) and whether they would accept input/help from others.

    -Kelly

    Yves Martel wrote:
    > On Mon, 02 May 2005 20:30:02 GMT, Mathieu Malaterre
    > wrote:
    >
    > >
    > >> The hardest part was converting all 600 pages of Module tables

    from PDF
    > >> into a spreadsheet.

    > >
    > >If you have access to a linux debian machine just install the

    xpdf-utils
    > >package. You'll have access to pdftotext which I use this way:
    > >
    > > pdftotext -f 9 -l 81 -raw -nopgbrk 04_06PU.PDF 04_06PU-3.txt
    > >
    > >This give a good start.
    > >
    > >But I agree having the dict in XML format would simply rocks !
    > >
    > >2 cents
    > >Mathieu

    >
    > The new Acrobat (version 7) let you cut & paste directly from the

    PDF!
    >
    > Yves



+ Reply to Thread