Dear william, On Sat, May 26, 2012 at 5:47 AM, Williams, Norman K <[email protected]> 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 [email protected] > 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. _______________________________________________ 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.php 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
