[Insight-developers] DCMTK Questions

[Alexandre GOUAILLARD]

Dear william,

On Sat, May 26, 2012 at 5:47 AM, Williams, Norman K
<norman-k-williams at uiowa.edu> wrote:
> Hans has asked me to work on finishing Alexandre Gouaillard's work on the
> DCMTK ImageIO.

To be fair, this was the work of andrew wassem and bill ryan, as
reported in corresponding tickets:
https://issues.itk.org/jira/browse/ITK-2855

>
> Today I've been trying to move his work from his own github repository
> into a gerrit topic on the current branch.  There are a number of issues
> that this raises.

Again, not my work, not my repository.

The, I hope your gerrit topic will have more luck than ours that were
purely removed, without prior notice for having been inactive for "too
long". E-mail to report the extreme unmotivating effect of those
removal, and the lack of corresponding policy that would have
justified it, stayed unanswered and might explain the lack of activity
today.

>
> 1. Hans suggested using a CMake ExternalProject to build DCMTK instead of
> what Alex did,

As documented in JIRA, Bill ryan's work.
https://issues.itk.org/jira/browse/ITK-2853

And again, as documented in JIRA, we always knew it was evil, and
decided all together we should go for external project:
https://issues.itk.org/jira/browse/ITK-2774

> which is to introduce the DCMTK included in the CTK project
> as a git module.  For one thing, that version of DCMTK won't compile with
> Clang.

It was a requirement by terry and a recommendation by steve piper and
ron to stay close to the CTK's DCMTK. We made a fork to be able to
apply the modification to allow DCMTK to be compatible with ITK v4
which is a little ebit different than CTK. Most of those modification
were made by SLC's NAMIC Project eek in january, and synchronized with
CTK's DCMTK fork, which in turn, as far as I know, has been actively
porting it s enhancements back to the main DCMTK. Things should be
synchrony today. As for Clang, I don t know if it compiles, I agree
this should be important as by default the compiler on new macs (10.8
lion) is clang and not gcc 4.2 anymore, but to follow the process, I m
not sure it is in the supported compilers (it should). That s
typically an INSIGHT Consortium decision though.

>
> I don't see a clean way to grab and build DCMTK within the current ITK
> framework at all.  What's done everywhere else is that there's a
> SuperBuild or MetaBuild, which builds all of a project's prerequisites as
> ExternalProjects, and then builds the project itself as an
> ExternalProject, configuring it with ITK_DIR, VTK_DIR etc so that it finds
> the prerequisites.

that s one way, but what we were thinking about was more like what
gaethan was using in the wrapping part for SWIG. using cmake's
external_project without really doing a super build. grep
external_project and swig, it's not very complicated to implement. On
the other hand, you re right to say that there will be additional
work, as it will be a library and not an executable and you have to
enforce compatibility. Also, you have to have a mechanism that allow
to switch between a SYSTEM_DCMTK or this external project mechanism. I
guess we don t really want to have "embedded" library anymore in ITK
v4.

>
> Could that be something that will be part of the ITK build process? Or are
> we going to incorporate some sort of snapshot of DCMTK in
> Modules/ThirdParty?

I think the snapshot is neither necessary nor good in terms of
maintenance. Luis pointed out that it s better to have even a public
git fork, if only to track format and send the  modifications back to
the upstreams repositories. It improves them, and let everybody be in
charge of the maintenance of their package.

>
> 2. DCMTK can read a DICOM directory directly, meaning that it wouldn't be
> necessary to use an ImageSeriesReader to read dicom datasets.  Should I
> stick with creating a DCMTKSeriesFileNames?

DCMTKSeriesFileNames is here only for "Backward compatibility". People
with using ITK should have a one to one correspondence between
existing code if we choose to move away from GDCM to DCMTK (terry 's
position). Now, if there is a better way to do things, it should be
implemented and we could push people in that direction as well, but
maybe not at the cost of backward compatibility.

>
> That feels rather clumsy, but it raises the issue of trying to choose
> which image in a multi-series DicomDirectory to load.
>
> --
> Kent Williams norman-k-williams at uiowa.edu
>

I miss luis and bill.

Bill is/was mean but fair. He motivated me and others to appreciate
and look for perfection, 100% code coverage, writing tests, 0 valgrind
default, the beauty of dashboard greenness, and so on.
Luis was extremely motivating, only generating goodwill, always trying
to take you one step above and beyond what your current capacity
was/is.
I express here my utmost appreciation of their efforts as they helped
me grow and improve during the 10+ years I have been involved in ITK.

Nowadays, ITK development is highly unsatisfactory and un-motivating.
Commit or die. Be active for two weeks or get out. Finger pointing.
Wrong informations about who does what.

Gaetan is already not around anymore, he was the #1 non-paid
contributor to ITK. When I look at gerrit today, or at the mailing
list, or at the insight journal, I don t see a lot of new, unpaid,
contributor. Where do we go as a community?

alex, concerned and unmotivated.