[Insight-developers] Update on DICOM

Fri Dec 23 22:04:49 EST 2011

Dear all,

Just speaking about DCMTK, the code has *NOT* been included directly
int he toolkit. Right now we are using a submodule that fetch the
CTK's github fork of DCMTK. We have not made the final decision about
wether we are going to keep the submodule way or switch to external
projects yet, but it does not really matter as in both case, we keep
itk light, we link nicely  to the upstream repositories and all the
other advantages you all mentioned.

Now moving forward, we will support system installs of dcmtk for sure.
However in the current stage of the project were modifications need to
be made in both ITK and DCMTK to have them talk together, we focus on
the submodule way to propagate changes faster to the upstream rep. As
soon as the ITK-DCMTK glue will be stable enough, then we will
implement the support for system installs.

In our case, as it was mentioned by someone previously, we have a
github fork (CTK's) that allows us to buffer the changes and to have
ITK working without waiting for DCMTK (proper) to adopt the changes.

I do not know if the code is really that big, but I agree that not all
DCMTK needs to be used for a given submodule. The NAMIC community
mentioned that we could try to have finer granularity packages to be
able to better share between projects, for easier maintenance, and to
reduce the download time if a user only ask for, say, ImageIO support
for DICOM and not PACS support. DCMTK code layout seems to be modular
enough for that (each lib is self contained). This is also in the
list, but again, should not be too difficult to do (some cmake magic)
when we will have made it work.

Speaking of which, reading in ITK from DICOM works since yesterday for
basic transfer syntax and RLE encoding. Today should be the JPEG day
;-)

Merry Xmass.

alex.

On Sat, Dec 24, 2011 at 2:05 AM, David Cole <david.cole at kitware.com> wrote:
> On Fri, Dec 23, 2011 at 1:55 PM, Johnson, Hans J <hans-johnson at uiowa.edu> wrote:
>> Matt,
>>
>> I agree with you 100%.  HDF5 should definitely be one of the first ones
>> for this conversion.
>>
>> I prefer the ExternalProject method for items from the Third party
>> directory.
>>
>> Hans
>>
>>
>> On 12/23/11 12:39 PM, "Matthew McCormick (thewtex)" <matt at mmmccormick.com>
>> wrote:
>>
>>>On Fri, Dec 23, 2011 at 12:44 PM, Steve M. Robbins <steve at sumost.ca>
>>>wrote:
>>>> Hi,
>>>>
>>>> If I may butt in with my Debian maintainer hat on ...
>>>>
>>>> On Fri, Dec 23, 2011 at 12:03:54PM -0500, Brad King wrote:
>>>>
>>>>> What is your plan for moving forward when the work is ready to be
>>>>> integrated in ITK upstream?  Do you want to try to maintain it as
>>>>> a submodule?  We could try bringing in a minimal snapshot of DCMTK
>>>>> like we do for HDF5:
>>>>>
>>>>>
>>>>>http://itk.org/gitweb?p=ITK.git;a=blob;f=Modules/ThirdParty/HDF5/src/REA
>>>>>DME-ITK.txt;hb=v4.0.0
>>>>
>>>> I see that the HDF5 support can be built with a system install of
>>>> HDF5.  From a packager point of view, that is crucial.  I hope you
>>>> will similarly support a system DCMTK.
>>>>
>>>>
>>>>> This will also allow us to make ITK-specific fixes without waiting
>>>>> for changes to go upstream.
>>>>
>>>> Is there a vision of coordinating with packagers on these ITK-specific
>>>> fixes?  As long as the ITK-specific fixes don't break non-ITK
>>>> software, Debian can generally apply the same fixes to the Debian
>>>> system HDF5, or DCMTK, etc.  So it would be awesome if there was a way
>>>> for me to receive notifications of such.  Any thoughts?
>>>>
>>>
>>>I think the current third party code in the ITK repository is a bad
>>>policy, and bringing DCMTK in code is not a good path.  DCMTK is a
>>>good opportunity to start doing things right, especially since the
>>>DCMTK code base is so huge.  We should avoid practices that:
>>>
>>>  - Make it hard to keep up-to-date with upstream.
>>>  - Discourage pushing patches upstream.
>>>  - Inflate the size of the repository.
>>>  - Discourage packaging by Linux distributions.
>>>
>>>A better solution would point to a fork on Github where we have a
>>>branch off upstream master.  We can easily merge in master, push
>>>patches upstream, keep the third party code out of the repository, and
>>>Linux distributions can see the patches applied with a 'git log'.
>>>
>>>Git submodule or CMake ExternalProject, either method is better than
>>>munging it into the repository.
>>>
>>>Matt
>>>
>>>Matt
>>>
>>>
>>>> Thanks,
>>>> -Steve
>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Kitware offers ITK Training Courses, for more information visit:
>>>> http://kitware.com/products/protraining.html
>>>>
>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>>
>>>_______________________________________________
>>>Powered by www.kitware.com
>>>
>>>Visit other Kitware open-source projects at
>>>http://www.kitware.com/opensource/opensource.html
>>>
>>>Kitware offers ITK Training Courses, for more information visit:
>>>http://kitware.com/products/protraining.html
>>>
>>>Please keep messages on-topic and check the ITK FAQ at:
>>>http://www.itk.org/Wiki/ITK_FAQ
>>>
>>>Follow this link to subscribe/unsubscribe:
>>>http://www.itk.org/mailman/listinfo/insight-developers
>>
>>
>>
>> ________________________________
>> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
>> ________________________________
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.html
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>
>
> SimpleITK already has a super build that builds swig and then ITK, and
> then SimpleITK itself.
>
> Perhaps its superbuild could be extended to build ITK third party
> stuff first. Or it could certainly be used as a model for how to do a
> similar superbuild for ITK itself.
>
> Superbuilds use the ExternalProject approach...
>
>
> 2 cents,
> David C.
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers