Choice of DICOM libary - DICOM

This is a discussion on Choice of DICOM libary - DICOM ; I worked with DIICOM a number of years ago, and am now beginning to work with it again. When I last worked with it, I used the Merge libary and was quite happy with that. But the world has moved ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Choice of DICOM libary

  1. Choice of DICOM libary

    I worked with DIICOM a number of years ago, and am now beginning to
    work with it again. When I last worked with it, I used the Merge libary
    and was quite happy with that. But the world has moved on. What I will
    be doing now is working with Ultrasound IODs and creating a Modality
    Worklist SCU functionality under XP using Microsoft C++. Multithreading
    support (or at least a product that is thread safe) would be preferred.
    I would prefer a commercial product that has reasonable (or no) runtime
    costs. I am willing to work down at the attribute level, but do not
    feel that I must do so. As far as I can tell, we are not going to be
    likely to define private attributes. It is quite possible that we will
    grow to support structured reporting at some time in the (relatively
    distant) future, so I would like a company that has a track record of
    adding functionality to its library over time, but it need not
    currently support structured reporting. What are the best candidates
    for the kind of development I have in mind? TIA
    --Tom Clune


  2. Re: Choice of DICOM libary

    tclune@ieee.org wrote:
    > I worked with DIICOM a number of years ago, and am now beginning to
    > work with it again. When I last worked with it, I used the Merge libary
    > and was quite happy with that. But the world has moved on. What I will
    > be doing now is working with Ultrasound IODs and creating a Modality
    > Worklist SCU functionality under XP using Microsoft C++. Multithreading
    > support (or at least a product that is thread safe) would be preferred.
    > I would prefer a commercial product that has reasonable (or no) runtime
    > costs. I am willing to work down at the attribute level, but do not
    > feel that I must do so. As far as I can tell, we are not going to be
    > likely to define private attributes. It is quite possible that we will
    > grow to support structured reporting at some time in the (relatively
    > distant) future, so I would like a company that has a track record of
    > adding functionality to its library over time, but it need not
    > currently support structured reporting. What are the best candidates
    > for the kind of development I have in mind? TIA
    > --Tom Clune
    >



    I very much like the Offis Dicom Toolkit (DCMTK) for developing
    applications, however it does not meet your requirements as it is
    unfortunately not (very/completely) threadsafe
    (http://forum.dcmtk.org/viewtopic.php...9599ec5979bdfd).

    Jonathan



  3. Re: Choice of DICOM libary

    Since you asked...

    We believe that the commercial DCF toolkit from Laurel Bridge Software
    represents the best choice you could make for your DICOM development
    needs, its object-oriented architecture allows you to integrate DICOM
    functionality into your product without detailed knowledge of the
    protocol. We handle all the DICOM related issues, allowing you to
    concentrate on your own core knowledge and accelerating your DICOM
    integration. Compared to traditional toolkits, the DCF approach
    represents a new level of support for implementing DICOM using its
    modern object-oriented programming methodologies. Ours is the only
    toolkit that supports, C++, C#, and Java development on Windows, Linux,
    and Solaris platforms. The toolkit is sold per platform.

    Features:
    -------------
    In addition to the DICOM functionality, our framework represents
    significantly more than a typical DICOM library you may have reviewed;
    it also includes:
    + Logging and debugging facilities,
    + Web-based service/diagnostic interfaces,
    + An advanced component development environment that facilitates
    rapid application development, and
    + Configuration data management facilities.
    The DCF provides an opportunity for new devices or retrofits to
    incorporate DICOM using a modern, component-based, multi-threaded
    architecture. Choosing our DCF software can save you substantial
    programming effort and can accelerate your development schedule.

    Our tools provide unparalleled facilities for configuration, logging,
    and service. Our ability to filter the DICOM data stream in real-time
    by a variety of mechanisms provides ways to accommodate errant DICOM
    clients or servers in the field without recompiling your source code.

    For more information:
    ------------------------------
    I encourage you to take the opportunity to review our web-based
    description of the DCF and related applications at:
    http://www.laurelbridge.com/products
    You may download a copy of the current DCF Developers Guide directly
    from this link, see:
    http://laurelbridge.com/pdf/DCF-Developers-Guide.pdf

    I hope this is sufficient information to get you to look closer.
    -- Bronson Hokuf


  4. Re: Choice of DICOM libary

    Hi Bronson Hokuf,

    is you DICOM libs multithreaded or thread safe ?
    If I've good read the first post, this is the very important point, and
    I'm interesting on this point too.

    Regards,

    Samuel BURG


  5. Re: Choice of DICOM libary

    Hi,

    The DCF DICOM libraries are thread safe.

    --Steven K. Minner


  6. Re: Choice of DICOM libary

    Hi Tom,

    The MergeCOM-3 library is still available for you. I believe we worked
    together a few times in the past on issues with the library. As you
    know, the MergeCOM-3 library is thread safe and obviously available for
    32-bit and 64-bit Windows using Visual Studio. We also keep uptodate
    with the latest changes in standard.

    The MergeCOM-3 library is now sold and supported through the Cedara
    Software division of Merge Healthcare. Feel free to contact us if
    you're intersted.

    Steve

    tclune@ieee.org wrote:
    > I worked with DIICOM a number of years ago, and am now beginning to
    > work with it again. When I last worked with it, I used the Merge libary
    > and was quite happy with that. But the world has moved on. What I will
    > be doing now is working with Ultrasound IODs and creating a Modality
    > Worklist SCU functionality under XP using Microsoft C++. Multithreading
    > support (or at least a product that is thread safe) would be preferred.
    > I would prefer a commercial product that has reasonable (or no) runtime
    > costs. I am willing to work down at the attribute level, but do not
    > feel that I must do so. As far as I can tell, we are not going to be
    > likely to define private attributes. It is quite possible that we will
    > grow to support structured reporting at some time in the (relatively
    > distant) future, so I would like a company that has a track record of
    > adding functionality to its library over time, but it need not
    > currently support structured reporting. What are the best candidates
    > for the kind of development I have in mind? TIA
    > --Tom Clune



  7. Re: Choice of DICOM libary

    Consider ours
    http://www.mydicom.net


    wrote in message
    news:1137778413.299414.63950@f14g2000cwb.googlegro ups.com...
    >I worked with DIICOM a number of years ago, and am now beginning to
    > work with it again. When I last worked with it, I used the Merge libary
    > and was quite happy with that. But the world has moved on. What I will
    > be doing now is working with Ultrasound IODs and creating a Modality
    > Worklist SCU functionality under XP using Microsoft C++. Multithreading
    > support (or at least a product that is thread safe) would be preferred.
    > I would prefer a commercial product that has reasonable (or no) runtime
    > costs. I am willing to work down at the attribute level, but do not
    > feel that I must do so. As far as I can tell, we are not going to be
    > likely to define private attributes. It is quite possible that we will
    > grow to support structured reporting at some time in the (relatively
    > distant) future, so I would like a company that has a track record of
    > adding functionality to its library over time, but it need not
    > currently support structured reporting. What are the best candidates
    > for the kind of development I have in mind? TIA
    > --Tom Clune
    >
    >




+ Reply to Thread