Joining Forces

[Hesham Desouky]

Hello All,

 

I started work with mdcm 3 years ago to build Nebras Technology (www.nebrastech.com) DICOM SDK.

 

In that time mdcm was missing the following:

1- Image Manipulation (Loading, processing and rendering)

2- DICOM DIR implementaion

3- DICOM PRINT (SCP and SCU)

4- High level DICOM netwrok classes

 

So we decided to extend the work of mdcm as following:

 

Image Manipulation

 

So we started work to add missing features to SDK and started with Image Manipulation. I get use of the OFFIS open source DICOM library to ruse the algorithms with mdcm DICOM implementation and ended up with following:

1- Loading and Rendering of MONOCHROME/MONOCHROM2 images with 8,10,12 and 16 bit grey scale

2- Ability to extract and render overlay data from pixel bits (as illustrated in DICOM standard)

3- Applying LUT and VOILUT

4- Window/Level modification to the monochrome images

5- Loading and Rendering color images (PALETTECOLOR,RGB,YBRFULL,YBRFULL422,YBRPARTIAL422,YBR_ICT,YBR_RCT)

 

and the following is pending:

1- Converting non DICOM images to DICOM

2- Enhancing memory utilization when dealing with large compressed images (to avoid loading of large uncompressed image data in memory)

3- Enhancing the performance of loading and uncompressing multi-frame images

 

DICOM DIR Implementation

DICOM DIR functionality is totally implemented for creating DICOM DIR and reading DICOM DIR, but still missing the feature of including thumbnails (icons)

 

DICOM PRINT (SCP and SCU)

Not Implemented yet

 

Hight Level DICOM network classes

Added the following classes

1- DICOM Server: high level DICOM Server to receive DICOM association for the following:

 a- Connected

 b- Disconnected

 c- AssociationRequest

 d- AssociationReleased

 e- PreStoreRequest

 f- Store Request

 g- FindRequest

 h- MoveRequest

 i- EchoRequest

 j- ErrorReceived

 

2- DICOM Query: high level DICOM Query classes for Patient, Study, Series and Instance

 

Attached  class diagram of what currently we have.

 

 

We believe in the power of Open Source community and would like to share the enhancements we added to mdcm with the public to enhance, empower and extend the current work with fo-DICOM for .Net

 

So I was wondering whether it will be possible to join the forces and get use of what we have with what you are providing in fo-DICOM to end up with high quality open source library for DICOM to the .Net community?

 

If yes, please let me know how you want to arrange and manage this merge.

 

 

Thanks in Advance

 

Heshan Desouky

Technical Development Manager

Nebras Technology

[Colby Dillion]

There have been several companies that have taken the mDCM library and have improved and extended it internally to their organization and have not contributed any improvements to the community. This has been a source of disappointment for me as it is not within the spirit of open source software and is not what I (naively?) hoped for when I originally released my work to the community.

I am also not sure that all of these companies are complying with the LGPL license that mDCM is released under. The private versions of mDCM that these companies distribute should be considered derivative works and so the source (or an offer for the source) should be distributed with the software that they release. Sadly for the community, for the several instances of private mDCM libraries being seen in the wild, this is not the case. It seems rare that the mDCM library gets credited at all, even in the licensing documentation included with the software.

Please do not feel discouraged about contributing to fo-dicom after reading the above. It is simply a disclaimer for one of the reasons that I do not believe that partnering with another entity is in the best interest of the user community.

Commercial support and advanced add-on components (including source code) for fo-dicom are coming in the near future, but the library is, and always will be, considered a community effort. Both fo-dicom and mDCM have been released on GitHub because of the collaboration opportunities that the site provides. Both libraries have more active user communities and more contributors than many other DICOM implementations. I hope that this trend continues into the future.

Nebras Technology has obviously put in a great amount of work into the mDCM library. You certainly have several highly requested items on your feature list. I hope that if Nebras Technology intends to use fo-dicom in future products that you will consider contributing to the community through pull requests on GitHub and by lending your expertise to the Google Group. Active code contributors will be considered to be added as a Collaborator on GitHub which would allow your company to contribute directly to the main tree. I believe that this would achieve all of your goals of partnering while still protecting the interests of the user community.

Colby

[Hesham Desouky]

Thanks Colby for your reply,

 

I agree with all what you said about mDCM drivatives and how companies are not following th LGPL.

 

I understand from you it is better to go ahead and contribute directely into fo-DICOM, I was thinking of a little collaboration between us about how to do this contribution, is there any coding standard, best practices fo-DICOM is following.

 

One more request, if there any available documentt hat describe how DICOM data  and image rendering data flow occur it will be so good point to start.

 

Looking forward for your reply

[Colby Dillion]

I know that it leaves to question many coding decisions, but I have created a preliminary document describing design guidelines and coding style: https://github.com/rcd/fo-dicom/wiki/Design-Guidelines-and-Coding-Style

There are currently no technical documents describing the code flow.

I will be pushing a large amount of code over the next few days related to image rendering. You might wait to see what I have pushed before you expend too much energy in that area.