From matt.mccormick at kitware.com Wed Oct 1 15:40:44 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Wed, 1 Oct 2014 15:40:44 -0400 Subject: [ITK-dev] [ANNOUNCE] ITK 4.6.1 has been released! Message-ID: On behalf of the Insight Toolkit Community, we are happy to announce the release of ITK 4.6.1! This is a patch release that addresses critical issues. The 4.6.1 release fixes DICOM, MetaIO, TIFF, and PNG IO issues, 32-bit WrapITK build errors, Python wrapping warnings, CMake configuration with COMPONENTS, performance and memory consumption of the ITKv4 implementation of the mutual information matching metric, and a many other issues. Congratulations and thanks to everyone who contributed to this release. We are particularly grateful for the collaborations with the 3D Slicer, Debian, GDCM, and MINC communities to address these issues. Questions and comments are welcome on the ITK mailing lists. The release files can be downloaded from: http://itk.org/ITK/resources/software.html The next feature release of 4.6.0 is scheduled for June. Enjoy ITK! Changes from v4.6.0 to v4.6.1: Arnaud Gelas (5): BUG: fix gdcm version in GDCMImageIO. COMP: missing cast when calling gdcm::DataElement::SetByteValue BUG: GDCMImageIO was not working properly when m_KeepOriginalUID is false BUG: split include directories into appropriate cmake variables HDF5 BUG: missing gdcm libraries when using system GDCM Brad King (2): COMP: Fix vxl_config_macros usage of CMake check macros BUG: Fix itk_module_config for repeated calls Bradley Lowekamp (8): ENH: Adding License file from upstream MetaIO ENH: Adding script to update MetaIO from upstream ENH: Remove ITK MetaIO to prepare for upstream import COMP: Fix variable type for Set/Get macros BUG: Use METER of sCAL scale unit BUG: Use PNG_SCALE_METER for PNG sCAL unit BUG: Fix overflows computing size of read tiff image BUG: Use array delete operator for array new allocations Christopher Mullins (2): COMP: Allows latex to compile for ITKSoftwareGuide COMP: Wrap MeshBase templates David T. Chen (1): DOC: Fixed HistogramThresholdImageFitler Gert Wollny (1): COMP: Fix SSE2 build errors with WrapITK on GCC 4.9. (ForRelease) Girish Mallya (1): BUG: Tests added for BinaryImageToLabelMapFilter for single-row images. Hans Johnson (12): COMP: Add tolerance for comparing floating point PERF: Remove non-threadable algorithm components PERF: Remove large foot print of PDF derivatives. PERF: Revert Remove large foot print of PDF derivatives. STYLE: Test against almost equal for floating point values STYLE: Non-exact floating point testing PERF: Distribute initialization per thread buffers ENH: Remove unnecessary mutable qualifier. STYLE: Remove comment with no meaning. ENH: Moved accumlator logic to main MI class ENH: Allow staggering of accumulations per thread. PERF: Zero reset thread buffers during finalize Matthew McCormick (31): BUG: ArchiveTestingData.py future imports must occur at the beginning. DOC: Remove Image2.cxx reference from Book 2. DOC: Fix Software Guide page overruns in IterativeClosestPoint3.cxx. DOC: Remove references to Book 1 sections from Book 2. DOC: Make BinaryThresholdImageFilter not floating. DOC: Fix Software Guide figure caption for FlipImageFilter. DOC: Avoid duplicate figure description in ResampleImageFilter2.cxx. DOC: Remove duplicate figure in LaplacianRecursiveGaussianImageFilter2.cxx. DOC: ImageRandomConstIteratorWithIndex table reference. BUG: Bump GCCXML to 2014-08-06. BUG: Fix invalid assignment of second VoronoiBoundaryOrigin. BUG: Call clear instead of empty on PatchBasedDenoising EmptyCaches(). BUG: Fix Size() in ImageToListSampleAdaptor for VectorImage's. BUG: Fix alpha assignment for RGBA TIFF. BUG: Fix Nifti IO read with large images. BUG: Improve thread-safety and performance of PCAShapeSignedDistanceFunction. DOC: itk::statistics -> itk::Statistics. DOC: Remove duplicate text in LaplacianRecursiveGaussian example. DOC: Fix Software Guide page overruns in IterativeClosestPoint{1,2}.cxx. BUG: TransformFileReader does not clear its TransformList. BUG: Prevent dangling pointer in HDF5TransformIO. COMP: Fix missing prefix in ITKv3ImageRegistration20Test. BUG: Do not return SmartPointers in TimeVaryingVelocityFieldTransform STYLE: Improve style in BinaryImageToLabelMapFilter. BUG: Fix BinaryImageToLabelMapFilter on 1D image. ENH: Improve precision of the joint PDF sum BUG: Fix BinShrinkImageFilter for different input/output image types. COMP: Fix transform type for ITKv3/IterativeClosestPoint2. COMP: Add missing wrapping for TransformIOBaseTemplate. BUG: gdcm::StringFilter recognizes backslash delimiter. ENH: Bump ITK version to 4.6.1. MetaIO Maintainers (1): MetaIO (reduced) Michka Popoff (4): BUG: Improve SWIG version check BUG: Add VTK_VERSION for older VTK versions BUG: Update VTK minimum version (for release) BUG: Fix memory leak in MetaImageIO after exception Vladimir S. FONOV (1): BUG: Fixing incorrect MINC style inverse transform From matt.mccormick at kitware.com Wed Oct 1 15:50:33 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Wed, 1 Oct 2014 15:50:33 -0400 Subject: [ITK-dev] [ANNOUNCE] ITK 4.6.1 has been released! In-Reply-To: References: Message-ID: Minor correction: > > The next feature release of 4.6.0 is scheduled for June. > The next feature release of 4.7.0 is scheduled for December. From matt.mccormick at kitware.com Fri Oct 3 12:57:27 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Fri, 3 Oct 2014 12:57:27 -0400 Subject: [ITK-dev] Missing "gdcmImageHelper.h" "gdcmSerieHelper.h" on Debian-sid-gcc4-64bit Message-ID: Hi Steve, Mathieu, I noticed that the Debian-sid-gcc4-64bit is having build failures due to missing gdcmImageHelper.h, gdcmSerieHelper.h, since Tuesday, September 30th. Debian-sid-gcc4-32bit ?seems fine. Any ideas on what is happening? Thanks, Matt From mathieu.malaterre at gmail.com Sat Oct 4 08:11:09 2014 From: mathieu.malaterre at gmail.com (Mathieu Malaterre) Date: Sat, 4 Oct 2014 14:11:09 +0200 Subject: [ITK-dev] Missing "gdcmImageHelper.h" "gdcmSerieHelper.h" on Debian-sid-gcc4-64bit In-Reply-To: <3257282.IFWIHhm9zD@riemann> References: <3257282.IFWIHhm9zD@riemann> Message-ID: On Fri, Oct 3, 2014 at 10:15 PM, Steve M. Robbins wrote: > On October 3, 2014 12:57:27 PM Matt McCormick wrote: >> Hi Steve, Mathieu, >> >> I noticed that the Debian-sid-gcc4-64bit is having build failures due >> to missing gdcmImageHelper.h, gdcmSerieHelper.h, since Tuesday, >> September 30th. Debian-sid-gcc4-32bit seems fine. Any ideas on what >> is happening? > > Well, the difference between the two systems is that I update "Debian-sid- > gcc4-64bit" very regularly, and update "-32bit" very rarely. In particular, > "-64bit" has "gdcm (2.4.4-2)" updated on Sept 30th. > > I'll start looking into the build failure. Thanks for pointing it out. It's there: https://packages.debian.org/sid/amd64/libgdcm2-dev/filelist I guess the cmake cache is still using /usr/include/gdcm-2.2 instead of /usr/include/gdcm-2.4 2cts -- Mathieu From matt.mccormick at kitware.com Tue Oct 7 11:52:56 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 7 Oct 2014 11:52:56 -0400 Subject: [ITK-dev] Opportunities to share, discuss, design, and learn with other ITK community members Message-ID: On Friday, 11:00 AM Eastern USA time, an ITK development conference, https://plus.google.com/u/0/events/cs71fpcqpa7l9me2vq45mi61mq8 To get regular invites to these events, join the ITK Bar Camp G+ Community: https://plus.google.com/u/0/communities/111375098792764998322 All are welcome. Hope to talk to you then! From matt.mccormick at kitware.com Mon Oct 13 11:11:20 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 13 Oct 2014 11:11:20 -0400 Subject: [ITK-dev] [ITK-users] Opportunities to share, discuss, design, and learn with other ITK community members In-Reply-To: <2A6589EB-D292-4362-8863-D4804ADE41EC@gmail.com> References: <2A6589EB-D292-4362-8863-D4804ADE41EC@gmail.com> Message-ID: Hi Ariel, I'll see if we can record and upload the audio next time. Thanks, Matt On Thu, Oct 9, 2014 at 10:43 AM, Ariel Hern?n Curiale wrote: > Hi Matt, > Is there any chance to see the video of the meeting on you tube, for example > ? > > Cheers > __________________________________ > | Ariel Hern?n Curiale Ph.D Candidate > | ETSI Telecomunicaci?n > | Universidad de Valladolid > | Campus Miguel Delibes > | 47011 Valladolid, Spain > | Phone: 983-423000 ext. 5590 > | Web: www.curiale.com.ar > |_________________________________ > > On 07/10/2014, at 17:52, Matt McCormick wrote: > > On Friday, 11:00 AM Eastern USA time, an ITK development conference, > > https://plus.google.com/u/0/events/cs71fpcqpa7l9me2vq45mi61mq8 > > > To get regular invites to these events, join the ITK Bar Camp G+ Community: > > https://plus.google.com/u/0/communities/111375098792764998322 > > > All are welcome. Hope to talk to you then! > _____________________________________ > 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://www.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://public.kitware.com/mailman/listinfo/insight-users > > From matt.mccormick at kitware.com Mon Oct 13 17:39:15 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 13 Oct 2014 17:39:15 -0400 Subject: [ITK-dev] Gerrit Down Time Message-ID: Hi, Gerrit will be down tonight for a few hours starting at 7:00 PM Eastern USA time for infrastructure upgrades. Sorry for any inconvenience. Matt From matt.mccormick at kitware.com Thu Oct 16 00:05:07 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Thu, 16 Oct 2014 00:05:07 -0400 Subject: [ITK-dev] Opportunities to share, discuss, design, and learn with other ITK community members Message-ID: There are a couple of upcoming opportunities to share, discuss, design, and learn with your fellow ITK community members. On Thursday (tomorrow), 1:00 PM Eastern USA time, there will be a Google+ Hangout where we will be doing code reviews: https://plus.google.com/events/cg7hf091i0k638gm43n3ktkfic0 On Friday, 11:00 AM Eastern USA time, an ITK development conference, https://plus.google.com/events/c3fr7aeqa06lhp2j1r601586o1s For those that cannot join via Hangout, telephone call-in is also possible. Dial: 585-632-6296 Enter pin: 31423 To get regular invites to these events, join the ITK Bar Camp G+ Community: https://plus.google.com/u/0/communities/111375098792764998322 All are welcome. Hope to talk to you then! From matt.mccormick at kitware.com Thu Oct 16 15:30:10 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Thu, 16 Oct 2014 15:30:10 -0400 Subject: [ITK-dev] [ITK-users] Opportunities to share, discuss, design, and learn with other ITK community members In-Reply-To: References: <2A6589EB-D292-4362-8863-D4804ADE41EC@gmail.com> Message-ID: Based on feedback at the Code Review Hangout today, to respect the privacy of participants, we are not going to record the audio tomorrow. Matt On Mon, Oct 13, 2014 at 11:11 AM, Matt McCormick wrote: > Hi Ariel, > > I'll see if we can record and upload the audio next time. > > Thanks, > Matt > > On Thu, Oct 9, 2014 at 10:43 AM, Ariel Hern?n Curiale wrote: >> Hi Matt, >> Is there any chance to see the video of the meeting on you tube, for example >> ? >> >> Cheers >> __________________________________ >> | Ariel Hern?n Curiale Ph.D Candidate >> | ETSI Telecomunicaci?n >> | Universidad de Valladolid >> | Campus Miguel Delibes >> | 47011 Valladolid, Spain >> | Phone: 983-423000 ext. 5590 >> | Web: www.curiale.com.ar >> |_________________________________ >> >> On 07/10/2014, at 17:52, Matt McCormick wrote: >> >> On Friday, 11:00 AM Eastern USA time, an ITK development conference, >> >> https://plus.google.com/u/0/events/cs71fpcqpa7l9me2vq45mi61mq8 >> >> >> To get regular invites to these events, join the ITK Bar Camp G+ Community: >> >> https://plus.google.com/u/0/communities/111375098792764998322 >> >> >> All are welcome. Hope to talk to you then! >> _____________________________________ >> 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://www.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://public.kitware.com/mailman/listinfo/insight-users >> >> From norman-k-williams at uiowa.edu Wed Oct 22 14:35:12 2014 From: norman-k-williams at uiowa.edu (Williams, Norman K) Date: Wed, 22 Oct 2014 18:35:12 +0000 Subject: [ITK-dev] Can I get permission to upload a file to http://midas3.kitware.com? Message-ID: I have an account, I can upload my own public & private files, but I don?t have permission to add new test Data. Can I be added to the permitted uploaders? Thanks! ________________________________ 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. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Wed Oct 22 14:41:19 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Wed, 22 Oct 2014 14:41:19 -0400 Subject: [ITK-dev] Can I get permission to upload a file to http://midas3.kitware.com? In-Reply-To: References: Message-ID: Hi Kent, You have been added to the Community Moderator group. Please try to upload again and let use know if you have any difficulties. Thanks, Matt On Wed, Oct 22, 2014 at 2:35 PM, Williams, Norman K wrote: > I have an account, I can upload my own public & private files, but I don?t > have permission to add new test Data. Can I be added to the permitted > uploaders? > > Thanks! > > > > ________________________________ > 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.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://public.kitware.com/mailman/listinfo/insight-developers > From matt.mccormick at kitware.com Thu Oct 23 00:54:06 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Thu, 23 Oct 2014 00:54:06 -0400 Subject: [ITK-dev] Opportunities to share, discuss, design, and learn with other ITK community members Message-ID: There are a couple of upcoming opportunities to share, discuss, design, and learn with your fellow ITK community members. On Thursday (tomorrow), 1:00 PM Eastern USA time, there will be a Google+ Hangout where we will be doing code reviews: https://plus.google.com/events/cn4gsqfr90k9ssa0jogal8vobco On Friday, 11:00 AM Eastern USA time, an ITK development conference, https://plus.google.com/events/c2qo0onsh06h3adslvkcj66nr7k? For those that cannot join via Hangout, telephone call-in is also possible. Dial: 585-632-6296 Enter pin: 31423 To get regular invites to these events, join the ITK Bar Camp G+ Community: https://plus.google.com/u/0/communities/111375098792764998322 All are welcome. Hope to talk to you then! From norman-k-williams at uiowa.edu Thu Oct 23 13:32:05 2014 From: norman-k-williams at uiowa.edu (Williams, Norman K) Date: Thu, 23 Oct 2014 17:32:05 +0000 Subject: [ITK-dev] Can't build using NINJA with ITKDCMTK/ITKIODCMTK turned on. Message-ID: A couple of years ago, with massive help from Brad King, I managed to get an embedded ExternalProject build of DCMTK embedded into ITK/Modules/ThirdParty. This was workable, because the CMake dependencies were explicitly set up such that the DCMTK libraries depended on the ExternalProject DCMTK target, and the DCMTKImageIO module depended on the libraries. When using the CMake with the Makefile generator, this hangs together, because the sub-make in Modules/IO/DCMTK won?t happen until the ExternalProject build in Modules/ThirdParty/DCMTK is complete. Ninja, on the other hand, makes one flat megamake at the top level of ITK, and if you try and build with Module_ITKDCMTK/Module_ITKIODCMTK/Module_IOTransformDCMTK turned on, it fails immediately because the targets in Modules/IO/DCMTK depend on non-existent DCMTK libraries. It?s a problem if we support all CMake generators except Ninja. I like using Ninja because it shaves several seconds off build times, which is great when you?re in an edit/compile/test workflow. I have no idea how this could be resolved, except to remove the internal DCMTK build and require USE_SYSTEM_DCMTK=ON. Does anyone have a better idea. ________________________________ 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. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.hoffman at kitware.com Thu Oct 23 13:57:08 2014 From: bill.hoffman at kitware.com (Bill Hoffman) Date: Thu, 23 Oct 2014 13:57:08 -0400 Subject: [ITK-dev] Can't build using NINJA with ITKDCMTK/ITKIODCMTK turned on. In-Reply-To: References: Message-ID: <54494174.1080602@kitware.com> On 10/23/2014 1:32 PM, Williams, Norman K wrote: > I have no idea how this could be resolved, except to remove the internal > DCMTK build and require USE_SYSTEM_DCMTK=ON. Does anyone have a better > idea. > The other option is to build this without external project and use add_subdirectory like we do with other 3rd party stuff (png, etc). Using ExternalProject does not work unless you build everything with external project as this case shows. How hard would that be to do? -Bill From brad.king at kitware.com Thu Oct 23 14:03:21 2014 From: brad.king at kitware.com (Brad King) Date: Thu, 23 Oct 2014 14:03:21 -0400 Subject: [ITK-dev] Can't build using NINJA with ITKDCMTK/ITKIODCMTK turned on. In-Reply-To: References: Message-ID: <544942E9.40805@kitware.com> On 10/23/2014 01:32 PM, Williams, Norman K wrote: > it fails immediately because the targets in Modules/IO/DCMTK depend > on non-existent DCMTK libraries. This cannot be solved cleanly without addressing these issues: https://github.com/martine/ninja/issues/760#issuecomment-46540858 http://www.cmake.org/Bug/view.php?id=14963#c36130 Currently the only way to build an ExternalProject cleanly with Ninja is if the outer project contains nothing except custom commands/targets, i.e. a superbuild that does both DCMTK and ITK as external projects. -Brad From norman-k-williams at uiowa.edu Thu Oct 23 15:04:14 2014 From: norman-k-williams at uiowa.edu (Williams, Norman K) Date: Thu, 23 Oct 2014 19:04:14 +0000 Subject: [ITK-dev] Can't build using NINJA with ITKDCMTK/ITKIODCMTK turned on. In-Reply-To: <544942E9.40805@kitware.com> References: <544942E9.40805@kitware.com> Message-ID: Yeah that?s the problem right there. I would have no problem with including DCMTK in the distro. On 10/23/14, 1:03 PM, "Brad King" wrote: >On 10/23/2014 01:32 PM, Williams, Norman K wrote: >> it fails immediately because the targets in Modules/IO/DCMTK depend >> on non-existent DCMTK libraries. > >This cannot be solved cleanly without addressing these issues: > > https://github.com/martine/ninja/issues/760#issuecomment-46540858 > http://www.cmake.org/Bug/view.php?id=14963#c36130 > >Currently the only way to build an ExternalProject cleanly >with Ninja is if the outer project contains nothing except >custom commands/targets, i.e. a superbuild that does both >DCMTK and ITK as external projects. > >-Brad > ________________________________ 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. ________________________________ From bogus@does.not.exist.com Fri Oct 24 12:21:10 2014 From: bogus@does.not.exist.com () Date: Fri, 24 Oct 2014 16:21:10 -0000 Subject: No subject Message-ID: > When trying to define a hierarchy for the RegistrationTransformation > class, it seems to be a contradiction between the sense of "is a" > as it is used in math, and as it is used in C++. 1. It seems to me that you are adding unnecessary complexity by using separate classes for Euclidean, Similarity, and Affine transformations. The representations are all the same (matrix plus offset) and the difference is only in what conditions the matrix must satisfy. These conditions can be tested by using IsEuclidean, etc methods as needed. 2. The distinction between proper and improper transformations is at least as important as the one you intend to use and is not reflected at all in your proposed hierarchy. The distinction between affine and linear is probably less important but may matter in some applications. 3. The base class for transformations is not any of the above, but a more generic transformation class that transforms points in a given number of dimensions into other points; as a practical matter, it should probably be bijective and continuous, but we may not want to actually force that in the class definition. The obvious subclasses would include affine, grid-based, and mesh-based transformations; also possible are perspective and polynomial transformations, though I believe the first three are enough for us. 4. The file Documents/Registration.pdf discusses some of these issues in more detail. Paul Hughett From bogus@does.not.exist.com Fri Oct 24 12:21:10 2014 From: bogus@does.not.exist.com () Date: Fri, 24 Oct 2014 16:21:10 -0000 Subject: No subject Message-ID: -----Original Message----- From: Ross Whitaker [mailto:whitaker at cs.utah.edu] Sent: Tuesday, January 23, 2001 12:37 PM To: insight-developers at public.kitware.com Subject: [Insight-developers] SLC meeting Folks, Below I have included a "straw-man" agenda. There is a little bit of open space, but I am sure I forgot something. Edit and return to me, or send me you comments and revisions. A couple of logistical things about the meeting: 1) We are done with hotels. You are on your own for hotel reservations. 2) I need the number of people who are comming from each group. Please send me this at your earliest convenience. I also need to know (tenatively) how many cars you are bringing. 3) The web site for the U has directions and maps. The Merrill Engineering Building (MEB) parking lot has metered visitor parking. You should park there on the first morning for 3mins or so, and then we will give you tags to use for that day and the one following. Cheers, Ross -- Ross T. Whitaker, Assistant Professor 50 S. Central Campus Drive, Rm. 3190 University of Utah Salt Lake City, UT 84112-9205 voice: 801/587-9549, fax: 801/581-5843 web: www.cs.utah.edu/~whitaker From bogus@does.not.exist.com Fri Oct 24 12:21:10 2014 From: bogus@does.not.exist.com () Date: Fri, 24 Oct 2014 16:21:10 -0000 Subject: No subject Message-ID: and cannot use the non-standard STL hashed container extensions because they are not supported by microsoft. Our "itkHashTable" can either be completely STL-compatible, or stand-alone, or somewhere in between. I think the latter is a good compromise, ie. make a reasonable effort to implement the stl associative container concept (ideally by modifying some public domain implementation), but not try to tackle the full SGI hashed associative container concept. Other folks thoughts on this? If we agree that this is a reasonable way to go, I'll start putting something together. Josh. ______________________________ Josh Cates School of Computer Science University of Utah Email: cates at cs.utah.edu Phone: (801) 587-7697 URL: www.cs.utk.edu/~cates From bogus@does.not.exist.com Fri Oct 24 12:21:10 2014 From: bogus@does.not.exist.com () Date: Fri, 24 Oct 2014 16:21:10 -0000 Subject: No subject Message-ID: in VC++. I've seen that the definition of the * operator in vnl_matrix is done differently in vnl depending on the platform. (using ifdefs) Any ideas ? Thanks Luis From bogus@does.not.exist.com Fri Oct 24 12:21:10 2014 From: bogus@does.not.exist.com () Date: Fri, 24 Oct 2014 16:21:10 -0000 Subject: No subject Message-ID: as needed into the new version. Jim -----Original Message----- From: Brad King [mailto:brad.king at kitware.com] Sent: Tuesday, April 24, 2001 2:28 PM To: Insight Developers Subject: [Insight-developers] VXL upgrade finished Hello, all: As far as I know, the vxl upgrade has been completed, and all the problems created by yesterday's disaster have been solved. Insight builds for me on GCC 2.95.3, MSVC++ 6, and MipsPro 7.30. I'm currently testing the Intel compiler as well. If any of you have been holding off on an update or commit due to my messages yesterday, you should be okay now. -Brad _______________________________________________ Insight-developers mailing list Insight-developers at public.kitware.com http://public.kitware.com/mailman/listinfo/insight-developers From bogus@does.not.exist.com Fri Oct 24 12:21:10 2014 From: bogus@does.not.exist.com () Date: Fri, 24 Oct 2014 16:21:10 -0000 Subject: No subject Message-ID: declaring one: Mesh::Pointer mesh =3D Mesh::New(); or even more = typedefs such as typedef Mesh::CellTraits CellTraits; or typedef = Mesh::Cell Cell; ) causes over 100 warnings, and a few errors which i = am not sure what to make of: fatal error C1063: Command line warning D4028 : minimal rebuild failure, reverting to = normal build HeartMedialWindow.cpp f:\projects\flow versions\itkflow\itkflow\heartmedialwindow.cpp(0) : = fatal error C1033: cannot open program database 'f:\projects\flow = versions\itkflow\debug\vc60.pdb' HeartShape.cpp f:\projects\flow versions\itkflow\itkflow\heartshape.cpp(0) : fatal = error C1033: cannot open program database 'f:\projects\flow = versions\itkflow\debug\vc60.pdb' HeartShapeWindow.cpp f:\projects\flow versions\itkflow\itkflow\heartshapewindow.cpp(0) : = fatal error C1033: cannot open program database 'f:\projects\flow = versions\itkflow\debug\vc60.pdb' LaptopMain.cpp f:\projects\flow versions\itkflow\itkflow\laptopmain.cpp(0) : fatal = error C1033: cannot open program database 'f:\projects\flow = versions\itkflow\debug\vc60.pdb' MedialWindow.cpp f:\projects\flow versions\itkflow\itkflow\medialwindow.cpp(0) : fatal = error C1033: cannot open program database 'f:\projects\flow = versions\itkflow\debug\vc60.pdb' Shape.cpp f:\projects\flow versions\itkflow\itkflow\shape.cpp(0) : fatal error = C1033: cannot open program database 'f:\projects\flow = versions\itkflow\debug\vc60.pdb' ShapeWindow.cpp f:\projects\flow versions\itkflow\itkflow\shapewindow.cpp(0) : fatal = error C1033: cannot open program database 'f:\projects\flow = versions\itkflow\debug\vc60.pdb' Error executing cl.exe. itkFlow.exe - 8 error(s), 117 warning(s) Is there a possible compatibility issue with the itk components, = requiring another statement similar to the=20 #ifdef _MSC_VER #pragma warning ( disable : 4786 ) #endif statement in the itkMesh example? I'm not quite sure what to = think about it, so any advice would be appreciated.=20 = Aaron Cois = University of Pittsburgh ------=_NextPart_000_0045_01C0E8FD.A4910030 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have been trying diligently to add a = mesh=20 into one of our pieces of code, and have hit somewhat of a road=20 block.  i can include itkMesh.h without error, and declare this=20 typedef:  typedef itk::Mesh<int>  Mesh;
 
From what i can tell, adding anything = else related=20 to mesh (such as declaring one:   Mesh::Pointer mesh =3D=20 Mesh::New(); or even more typedefs such as typedef = Mesh::CellTraits =20 CellTraits; or typedef Mesh::Cell  Cell; ) causes over 100 = warnings, and a=20 few errors which i am not sure what to make of:
 
fatal error C1063:
Command line = warning D4028 :=20 minimal rebuild failure, reverting to normal=20 build
HeartMedialWindow.cpp
f:\projects\flow=20 versions\itkflow\itkflow\heartmedialwindow.cpp(0) : fatal error C1033: = cannot=20 open program database 'f:\projects\flow=20 versions\itkflow\debug\vc60.pdb'
HeartShape.cpp
f:\projects\flow=20 versions\itkflow\itkflow\heartshape.cpp(0) : fatal error C1033: cannot = open=20 program database 'f:\projects\flow=20 versions\itkflow\debug\vc60.pdb'
HeartShapeWindow.cpp
f:\projects\f= low=20 versions\itkflow\itkflow\heartshapewindow.cpp(0) : fatal error C1033: = cannot=20 open program database 'f:\projects\flow=20 versions\itkflow\debug\vc60.pdb'
LaptopMain.cpp
f:\projects\flow=20 versions\itkflow\itkflow\laptopmain.cpp(0) : fatal error C1033: cannot = open=20 program database 'f:\projects\flow=20 versions\itkflow\debug\vc60.pdb'
MedialWindow.cpp
f:\projects\flow = versions\itkflow\itkflow\medialwindow.cpp(0) : fatal error C1033: cannot = open=20 program database 'f:\projects\flow=20 versions\itkflow\debug\vc60.pdb'
Shape.cpp
f:\projects\flow=20 versions\itkflow\itkflow\shape.cpp(0) : fatal error C1033: cannot open = program=20 database 'f:\projects\flow=20 versions\itkflow\debug\vc60.pdb'
ShapeWindow.cpp
f:\projects\flow=20 versions\itkflow\itkflow\shapewindow.cpp(0) : fatal error C1033: cannot = open=20 program database 'f:\projects\flow = versions\itkflow\debug\vc60.pdb'
Error=20 executing cl.exe.
 
itkFlow.exe - 8 error(s), 117=20 warning(s)
 
 
        = Is there a=20 possible compatibility issue with the itk components, requiring another=20 statement similar to the
 
#ifdef _MSC_VER
#pragma warning ( = disable : 4786=20 )
#endif
 
        = statement in=20 the itkMesh example?  I'm not quite sure what to think about it, so = any=20 advice would be appreciated.
 
       =20             =    =20             =    =20             =    =20             =    =20             =    =20             =    =20             =    =20     Aaron Cois
          &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =        University=20 of Pittsburgh
------=_NextPart_000_0045_01C0E8FD.A4910030-- From bogus@does.not.exist.com Fri Oct 24 12:21:10 2014 From: bogus@does.not.exist.com () Date: Fri, 24 Oct 2014 16:21:10 -0000 Subject: No subject Message-ID: template void ImageBase ::SetRequestedRegion(DataObject *data) { ImageBase *imgData; std::cout << "ImageBase::SetRequestedRegion DataObject = " << data << std::endl; imgData = dynamic_cast(data); if (imgData) { m_RequestedRegion = imgData->GetRequestedRegion(); } else { // pointer could not be cast back down std::cerr << "itk::ImageBase::SetRequestedRegion(DataObject*) cannot cast " << typeid(data).name() << " to " << typeid(ImageBase*).name() << std::endl; } } From bogus@does.not.exist.com Fri Oct 24 12:21:10 2014 From: bogus@does.not.exist.com () Date: Fri, 24 Oct 2014 16:21:10 -0000 Subject: No subject Message-ID: /** * By default we set all the output requested regions to be the same. */ void ProcessObject ::GenerateOutputRequestedRegion(DataObject *output) { std::vector::size_type idx; for (idx = 0; idx < m_Outputs.size(); ++idx) { if (m_Outputs[idx] && m_Outputs[idx] != output) { m_Outputs[idx]->SetRequestedRegion(output); } } } -------------- Josh. ______________________________ Josh Cates School of Computer Science University of Utah Email: cates at cs.utah.edu Phone: (801) 587-7697 URL: www.cs.utk.edu/~cates From bogus@does.not.exist.com Fri Oct 24 12:21:10 2014 From: bogus@does.not.exist.com () Date: Fri, 24 Oct 2014 16:21:10 -0000 Subject: No subject Message-ID: (and we have on our team an anatomist who teaches about the region), this is one of the most challenging regions to segment. I think that before segmentation methods developed under itk will be systematically validated, we can't make statements about what method is the the best for what application (what imaging). We really can't make conjectures before we will validate... -Celina On Tue, 8 Jan 2002, Stephen R. Aylward wrote: > Hi Nils, > > I think I misunderstood your problem - you don't want just the bones - > you want everything in the pelvic area. Right? Sorry for the confusion. > > Watershed is a great approach for this. Fuzzy connectedness should > also be considered. It is a hard problem, though. This is one > application that really needs a user interface/visualization in order to > evaluate, control, and edit the segmentation process. Stay tuned for > itk2 :) > > As you go along, if you have suggestions for how we can better group the > methods, summarize their utility, etc, we would really appreciate it. > One thing, this year is going to focus on documenting the application of > itk to a variety of different medical image analysis tasks (as part of > method validation), and so the examples section is going to greatly > expand and perhaps that will help others in your position in the future. > Until then.... > > Thanks for your patience, > Stephen > > Nils Hanssen wrote: > > > > Hi Stephen, > > > > thank you very much for your step-by-step list. In fact i just had a > > conversation with lydia ycl about segmentation in the pelvic area because > > she deals with this topic. > > > > Instead of being limited to the pelvic area, we have a general interest in > > the segmentation capabilities of itk for CT and MR data. So far, we used vtk > > for visualization and used thresholding as well as region growing for > > segmentation and marching cubes for surface generation of bony structures. > > Since vtk's segmentation capabilities are (obviously) very limited, we were > > looking forward to become a first version of itk. > > > > I am very impressed by itk from the software-engineering point of view! I > > like the concepts and the realization of some design patterns. However, it's > > not easy to get an overview of the whole system and how everything belongs > > together. > > > > Currently i try to get the streamed watershed filter running. > > > > Nils > > > > > It looks like Nils wants to segment the pelvis from CT and MR. > > > > > > This should be do-able with itk now... > > > > > > 1) Region grow (itkRegionGrowImageFilter or > > > itkFuzzyConnectednessImageFilter.h) > > > 2) morphological erosion (2cm - remove ribs) > > > 3) morphological dilate (3cm - restore to original size + > > > fill in marrow > > > holes) > > > 4) morphological erosion (1cm - restore to original size) > > > > > > The problem with abdominal MR are the intensity inhomogeneities. > > > > > > Try the MRBiasFieldCorrection method and then do the above > > > for MR (bones > > > being dark). > > > > > > Stephen > > > > > > > > > > > > -- > > > =============================================== > > > Dr. Stephen R. Aylward > > > Assistant Professor of Radiology > > > Adjunct Assistant Professor of Computer Science > > > http://caddlab.rad.unc.edu > > > aylward at unc.edu > > > (919) 966-9695 > > > > > -- > =============================================== > Dr. Stephen R. Aylward > Assistant Professor of Radiology > Adjunct Assistant Professor of Computer Science > http://caddlab.rad.unc.edu > aylward at unc.edu > (919) 966-9695 > _______________________________________________ > Insight-developers mailing list > Insight-developers at public.kitware.com > http://public.kitware.com/mailman/listinfo/insight-developers > From bogus@does.not.exist.com Fri Oct 24 12:21:10 2014 From: bogus@does.not.exist.com () Date: Fri, 24 Oct 2014 16:21:10 -0000 Subject: No subject Message-ID: "If a template, a member template, or the member of a class template is explicitly specialized then that specialization shall be declared before the first use of that specialization that would cause implicit instantiation to take place, in every translation unit in which such a use occurs; no diagnostic is required." Since no diagnostic is required, most platforms don't report this problem. SGI is kind enough to notice the problem and complain. Here is the reason it is standard: foo.h: template struct A { /* Generic implementation. */ }; foo1.cxx: A a1; // Instantiates A from primary template in foo.h foo2.cxx: template <> struct A { /* Integer implementation. */ }; A a2; // Uses specialization. foo3.cxx: template <> struct A; A a3; // Uses specialization. Linker will find symbols. Now consider what happens when foo1.o, foo2.o, and foo3.o are linked. There are two definitions of the symbols from A, and they are different. This is because foo1 uses an instantiation of the primary template, while foo2 and foo3 use the speicalization. This will confuse the linker. If instead the forward-declaration of the specialization were in foo.h, all code would use the same symbols. I can go into more detail about linkers and weak v. strong symbols if you want. > It seems that on all other platforms the compiler is able to > automatically find the class specializations provided by the code in > *.cxx file. You've gotten lucky so far. The current situation doesn't involve all the components of the above example, but it could easily do so in the future. > Furthermore, forward declaring the template parameter doesn't work. The > class used as a template parameter has to be completely declared (at > least the way class GenerateMesh is implemented now, because > GenerateMesh references one of its typedefs...). True, I didn't notice that. You can, however, avoid the typedef lookup by simply using "const ElementType*" instead of "ElementType::ConstPointer". This is actually preferable as it is ITK standard to pass raw pointers as function arguments instead of smart pointers. In this case it won't change anything since ElementType::ConstPointer isn't a smart pointer anyway. > I implemented this class as templated one so that later, when new > elements are introduced, it should be quite simple to write functions > that generate various types of meshes from these new elements in a > consistently way. Basically you just need to provide the implementation > (specialization) of the member functions of GenerateMesh class for the > specific element type without the need for changing the existing library > code (file itkFEMGenerateMesh.h) and enforcing consistent syntax. > > The additional declaration of each specialized function in file > itkFEMGenerateMesh.h seems to defeat the purpose of using manual > specialization in the first place. Do you have any ideas, how these > things could be implemented in some other way? This approach is known as a "trait". Traits are used when most of the implementation of a class over two types is the same, but small sections differ. The code for sections that differ is looked up through a "trait" class that can be programmed on a per-type basis using template specialization. Your implementation of traits is different from the usual way we use in ITK. In this case, it looks like GenerateMesh is basically a trait class in itself. You might look at writing it this way: itkFEMGenerateMesh.h: // Empty primary template: template class GenerateMesh; // Specialization of entire class for Element2DC0LinearQuadrilateral: class Element2DC0LinearQuadrilateral; template<> class GenerateMesh { typedef Element2DC0LinearQuadrilateral ElementType; typedef vnl_vector VectorType; static void Rectangular(const ElementType* e0, Solver& S, VectorType& orig, VectorType& size, VectorType& Nel); }; // Other specializations... itkFEMGenerateMesh.cxx: // Implement specializations: void GenerateMesh ::Rectangular(ElementType::ConstPointer e0, Solver& S, VectorType& orig, VectorType& size, VectorType& Nel) { /* ... */ } This version requires a little more code, but it is more consistent with other traits in ITK, and will be more easily understood by most programmers (I think). -Brad From bogus@does.not.exist.com Fri Oct 24 12:21:10 2014 From: bogus@does.not.exist.com () Date: Fri, 24 Oct 2014 16:21:10 -0000 Subject: No subject Message-ID: each library to link but the problem with the tds size just gets push over to the when the executable links. Jim > -----Original Message----- > From: Bill Hoffman [mailto:bill.hoffman at kitware.com] > Sent: Friday, October 04, 2002 2:40 PM > To: Miller, James V (Research) > Cc: insight-developers at public.kitware.com > Subject: RE: [Insight-users] linker error with Borland > > > The only other thing we could do, is to create a static library > that has the test sources, and link the test driver to that library. > > -Bill > > > At 02:33 PM 10/4/2002 -0400, you wrote: > >Nope. > > > >> -----Original Message----- > >> From: Bill Hoffman [mailto:bill.hoffman at kitware.com] > >> Sent: Friday, October 04, 2002 2:32 PM > >> To: Miller, James V (Research) > >> Subject: RE: [Insight-users] linker error with Borland > >> > >> > >> So, -lGn did not work? > >> > >> -Bill > >> > >> > >> At 01:34 PM 10/4/2002 -0400, you wrote: > >> >Didn't seem to help. > >> > > >> >> -----Original Message----- > >> >> From: Bill Hoffman [mailto:bill.hoffman at kitware.com] > >> >> Sent: Friday, October 04, 2002 1:04 PM > >> >> To: Miller, James V (Research) > >> >> Subject: RE: [Insight-users] linker error with Borland > >> >> > >> >> > >> >> -lx Pass option x to linker > >> >> or this one: > >> >> -l-x Disables option x for the linker > >> >> > >> >> > >> >> At 12:41 PM 10/4/2002 -0400, you wrote: > >> >> >I couldn't see where to do that. There is a > >> >> > > >> >> >/Gn link option to turn off incremental linking > >> >> > > >> >> >But only the linker ilink32 accepts this option. > >> >> >It looks like the generated makefile uses bcc32 to > >> >> >link executables. I don't see an entry in the CMakeCache > >> >> >to force ilink32 to be used. > >> >> > > >> >> > > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Bill Hoffman [mailto:bill.hoffman at kitware.com] > >> >> >> Sent: Friday, October 04, 2002 12:31 PM > >> >> >> To: Miller, James V (Research); 'Luis Ibanez'; > >> >> dean.inglis at on.aibn.com > >> >> >> Cc: insight-users at public.kitware.com > >> >> >> Subject: RE: [Insight-users] linker error with Borland > >> >> >> > >> >> >> > >> >> >> Can we turn off incremental linking? > >> >> >> > >> >> >> > >> >> >> At 11:52 AM 10/4/2002 -0400, Miller, James V > (Research) wrote: > >> >> >> >Looks like we have been able to get a build going here that > >> >> >> >uses the MinSizeRel build configuration. This seems to > >> keep the > >> >> >> >tds files about an order of magnitude smaller. > >> >> >> > > >> >> >> >So we have a little more room before we hit the > >> Borland ceiling. > >> >> >> >We may still have issues with the examples. > >> Unfortunately, we may > >> >> >> >be limited to using to using the MinSizeRel > >> configuration only. > >> >> >> > > >> >> >> >Don't know if this can be set as the default in CMake. > >> >> >> > > >> >> >> >Also don't know whether the newer Borland Builder > >> suite still has > >> >> >> >this tds size issue. > >> >> >> > > >> >> >> >Jim > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> >> -----Original Message----- > >> >> >> >> From: Luis Ibanez [mailto:luis.ibanez at kitware.com] > >> >> >> >> Sent: Friday, October 04, 2002 10:22 AM > >> >> >> >> To: dean.inglis at on.aibn.com > >> >> >> >> Cc: insight-users at public.kitware.com > >> >> >> >> Subject: Re: [Insight-users] linker error with Borland > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> Hi Dean, > >> >> >> >> > >> >> >> >> Does the Borland linker has an option for increasing > >> the size > >> >> >> >> of the stack ? > >> >> >> >> > >> >> >> >> For VC++ we have to set it quite large.....= 0x989680 > >> >> >> >> > >> >> >> >> This may be related to the error you are getting... > >> >> >> >> > >> >> >> >> Just a guess. > >> >> >> >> > >> >> >> >> Luis > >> >> >> >> > >> >> >> >> ======================================================== > >> >> >> >> > >> >> >> >> dean.inglis at on.aibn.com wrote: > >> >> >> >> > >> >> >> >> >Hi, > >> >> >> >> > > >> >> >> >> >I'm getting a pb with linking of the sort: > >> >> >> >> >Turbo Incremental Link 5.00 Copyright (c) 1997, > 2000 Borland > >> >> >> >> >Fatal: Error detected (LME351) > >> >> >> >> >Warning: Cannot reserve virtual memory at addr > >> >> >> >> >720C0000 for -786432 bytes (errcode 87) > >> >> >> >> >** error 1 ** deleting > >> >> >> >> c:\Builder\itkRelease\bin\itkAlgorithmsTests.exe > >> >> >> >> > > >> >> >> >> >The Borland incremental linker seems to conk out > >> >> >> >> >when the .tds file ( associated with the exe) > >> >> >> >> >containing debug info etc. gets to around 35 Mb. > >> >> >> >> > > >> >> >> >> >I have increase virtual memory on a system that > >> >> >> >> >already has 768 Mb physical RAM. > >> >> >> >> > > >> >> >> >> >Dean > >> >> >> >> > > >> >> >> >> >_______________________________________________ > >> >> >> >> >Insight-users mailing list > >> >> >> >> >Insight-users at public.kitware.com > >> >> >> >> >http://public.kitware.com/mailman/listinfo/insight-users > >> >> >> >> > > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> _______________________________________________ > >> >> >> >> Insight-users mailing list > >> >> >> >> Insight-users at public.kitware.com > >> >> >> >> http://public.kitware.com/mailman/listinfo/insight-users > >> >> >> >> > >> >> >> >_______________________________________________ > >> >> >> >Insight-users mailing list > >> >> >> >Insight-users at public.kitware.com > >> >> >> >http://public.kitware.com/mailman/listinfo/insight-users > >> >> >> > >> >> >> > >> >> >_______________________________________________ > >> >> >Insight-users mailing list > >> >> >Insight-users at public.kitware.com > >> >> >http://public.kitware.com/mailman/listinfo/insight-users > >> >> > >> >> > >> > >> > > From bogus@does.not.exist.com Fri Oct 24 12:21:10 2014 From: bogus@does.not.exist.com () Date: Fri, 24 Oct 2014 16:21:10 -0000 Subject: No subject Message-ID: Cygwin is a UNIX environment, developed by Red Hat, for Windows. It consists of two parts: A DLL (cygwin1.dll) which acts as a UNIX emulation layer providing substantial UNIX API functionality. A collection of tools, ported from UNIX, which provide UNIX/Linux look and feel. -Bill From bogus@does.not.exist.com Fri Oct 24 12:21:10 2014 From: bogus@does.not.exist.com () Date: Fri, 24 Oct 2014 16:21:10 -0000 Subject: No subject Message-ID: Welcome, Bill BTW: you may want to save the following link: http://public.kitware.com/Insight/Testing/HTML/TestingResults/Dashboard/MostRecentResults-Nightly/Dashboard.html it points to the nightly insight dashboard. From bogus@does.not.exist.com Fri Oct 24 12:21:10 2014 From: bogus@does.not.exist.com () Date: Fri, 24 Oct 2014 16:21:10 -0000 Subject: No subject Message-ID: Before I dive into the code... Jim Miller _____________________________________ Visualization & Computer Vision GE Research Bldg. KW, Room C218B P.O. Box 8, Schenectady NY 12301 millerjv at research.ge.com james.miller at research.ge.com (518) 387-4005, Dial Comm: 8*833-4005, Cell: (518) 505-7065, Fax: (518) 387-6981 ------_=_NextPart_001_01C2C3CD.80DCE3C8 Content-Type: text/html; charset="iso-8859-1"
Is there any reason (for the code) for the mutual information image to image metric to return a negative value?
 
From the (abstract) definition of mutual information, this does not seem to plausible.
 
Before I dive into the code...

 

Jim Miller
_____________________________________
Visualization & Computer Vision
GE Research
Bldg. KW, Room C218B
P.O. Box 8, Schenectady NY 12301

millerjv at research.ge.com

james.miller at research.ge.com
(518) 387-4005, Dial Comm: 8*833-4005,
Cell: (518) 505-7065, Fax: (518) 387-6981

 

 
------_=_NextPart_001_01C2C3CD.80DCE3C8-- From norman-k-williams at uiowa.edu Fri Oct 24 12:45:17 2014 From: norman-k-williams at uiowa.edu (Williams, Norman K) Date: Fri, 24 Oct 2014 16:45:17 +0000 Subject: [ITK-dev] MatrixOffsetTransformBase::GetFixedParameters not ThreadSafe -- regression test? Message-ID: I was going to address this bug that I just logged: https://issues.itk.org/jira/browse/ITK-3324 Basically, if GetFixedParameters is called from multiple threads, it introduces a race to resize the internal fixed parameter array. This was never a problem before Hans Johnson?s recent patch to propagate fixed parameters int Transform::GetInverse() methods. He added: inverse->SetFixedParameters(this->GetFixedParameters()); which makes perfect sense. I have a decent idea of how to make this better: Set the fixed parameters? size in the constructor for MatrixOffsetTransformBase, and set the fixed parameters in SetCenter. I will review the other instances of GetFixedParameters and GetParameters to see if they?re similarly thread-unsafe. But how do you write a regression test for this? ________________________________ 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. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman-k-williams at uiowa.edu Fri Oct 24 12:59:41 2014 From: norman-k-williams at uiowa.edu (Williams, Norman K) Date: Fri, 24 Oct 2014 16:59:41 +0000 Subject: [ITK-dev] MatrixOffsetTransformBase::GetFixedParameters not ThreadSafe -- regression test? Message-ID: The problem is worse than I thought. CompositeTransform::GetFixedParameters() dynamically resizes the FixedParameters array, and then does a bunch of std::copy to copy fixed parameters out of its list of sub-transforms. The only way to make that thread safe is to use a Mutex lock to guard where it changes the member variable. From: , Mushly McMushmaster > Date: Friday, October 24, 2014 at 11:45 AM To: ITK > Subject: [ITK-dev] MatrixOffsetTransformBase::GetFixedParameters not ThreadSafe -- regression test? I was going to address this bug that I just logged: https://issues.itk.org/jira/browse/ITK-3324 Basically, if GetFixedParameters is called from multiple threads, it introduces a race to resize the internal fixed parameter array. This was never a problem before Hans Johnson?s recent patch to propagate fixed parameters int Transform::GetInverse() methods. He added: inverse->SetFixedParameters(this->GetFixedParameters()); which makes perfect sense. I have a decent idea of how to make this better: Set the fixed parameters? size in the constructor for MatrixOffsetTransformBase, and set the fixed parameters in SetCenter. I will review the other instances of GetFixedParameters and GetParameters to see if they?re similarly thread-unsafe. But how do you write a regression test for this? ________________________________ 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. ________________________________ ________________________________ 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. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From blowekamp at mail.nih.gov Fri Oct 24 13:25:42 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Fri, 24 Oct 2014 13:25:42 -0400 Subject: [ITK-dev] MatrixOffsetTransformBase::GetFixedParameters not ThreadSafe -- regression test? In-Reply-To: References: Message-ID: Kent, Mutable member are evil. Would it be possible to have the m_Center and the m_FixedArray point to the same block of data? Brad On Oct 24, 2014, at 12:59 PM, Williams, Norman K wrote: > The problem is worse than I thought. > > CompositeTransform::GetFixedParameters() dynamically resizes the FixedParameters array, and then does a bunch of std::copy to copy fixed parameters out of its list of sub-transforms. > > The only way to make that thread safe is to use a Mutex lock to guard where it changes the member variable. > > From: , Mushly McMushmaster > Date: Friday, October 24, 2014 at 11:45 AM > To: ITK > Subject: [ITK-dev] MatrixOffsetTransformBase::GetFixedParameters not ThreadSafe -- regression test? > > I was going to address this bug that I just logged: > > https://issues.itk.org/jira/browse/ITK-3324 > > Basically, if GetFixedParameters is called from multiple threads, it introduces a race to resize the internal fixed parameter array. > > This was never a problem before Hans Johnson?s recent patch to propagate fixed parameters int Transform::GetInverse() methods. He added: > > inverse->SetFixedParameters(this->GetFixedParameters()); > > which makes perfect sense. > > I have a decent idea of how to make this better: Set the fixed parameters? size in the constructor for MatrixOffsetTransformBase, and set the fixed parameters in SetCenter. I will review the other instances of GetFixedParameters and GetParameters to see if they?re similarly thread-unsafe. > > But how do you write a regression test for this? > > > > > 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. > > > 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.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://public.kitware.com/mailman/listinfo/insight-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman-k-williams at uiowa.edu Fri Oct 24 13:41:31 2014 From: norman-k-williams at uiowa.edu (Williams, Norman K) Date: Fri, 24 Oct 2014 17:41:31 +0000 Subject: [ITK-dev] MatrixOffsetTransformBase::GetFixedParameters not ThreadSafe -- regression test? In-Reply-To: References: Message-ID: If the API says const bool GetInverse(Self *inverse) const; If that changes the internal state of the class, isn?t that false advertising? Actually, I tried just fixing that one problem in MatrixOffsetTransformBase, and it just kicked the problem slightly down the road. ImageMaskSpatialObject::IsInside also advertises as being a const method; yet it calls SetInternalInverseTransformToWorldToIndexTransform() which is ALSO marked as const, and yet modifies an instance variable. From: Bradley Lowekamp > Date: Friday, October 24, 2014 at 12:25 PM To: Mushly McMushmaster > Cc: ITK > Subject: Re: [ITK-dev] MatrixOffsetTransformBase::GetFixedParameters not ThreadSafe -- regression test? Kent, Mutable member are evil. Would it be possible to have the m_Center and the m_FixedArray point to the same block of data? Brad On Oct 24, 2014, at 12:59 PM, Williams, Norman K > wrote: The problem is worse than I thought. CompositeTransform::GetFixedParameters() dynamically resizes the FixedParameters array, and then does a bunch of std::copy to copy fixed parameters out of its list of sub-transforms. The only way to make that thread safe is to use a Mutex lock to guard where it changes the member variable. From: , Mushly McMushmaster > Date: Friday, October 24, 2014 at 11:45 AM To: ITK > Subject: [ITK-dev] MatrixOffsetTransformBase::GetFixedParameters not ThreadSafe -- regression test? I was going to address this bug that I just logged: https://issues.itk.org/jira/browse/ITK-3324 Basically, if GetFixedParameters is called from multiple threads, it introduces a race to resize the internal fixed parameter array. This was never a problem before Hans Johnson?s recent patch to propagate fixed parameters int Transform::GetInverse() methods. He added: inverse->SetFixedParameters(this->GetFixedParameters()); which makes perfect sense. I have a decent idea of how to make this better: Set the fixed parameters? size in the constructor for MatrixOffsetTransformBase, and set the fixed parameters in SetCenter. I will review the other instances of GetFixedParameters and GetParameters to see if they?re similarly thread-unsafe. But how do you write a regression test for this? ________________________________ 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. ________________________________ ________________________________ 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.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://public.kitware.com/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. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman-k-williams at uiowa.edu Mon Oct 27 15:31:01 2014 From: norman-k-williams at uiowa.edu (Williams, Norman K) Date: Mon, 27 Oct 2014 19:31:01 +0000 Subject: [ITK-dev] review.source.kitware.com down again Message-ID: Someone needs to go bang on the side of the server. ________________________________ 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. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Mon Oct 27 16:06:02 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Mon, 27 Oct 2014 16:06:02 -0400 Subject: [ITK-dev] [ITK] review.source.kitware.com down again In-Reply-To: References: Message-ID: Thanks for the note. There was some unexpected downtime due to maintenance. It is back up again. On Mon, Oct 27, 2014 at 3:31 PM, Williams, Norman K wrote: > Someone needs to go bang on the side of the server. > > > > ________________________________ > 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.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://public.kitware.com/mailman/listinfo/insight-developers > > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community > From norman-k-williams at uiowa.edu Tue Oct 28 13:21:31 2014 From: norman-k-williams at uiowa.edu (Williams, Norman K) Date: Tue, 28 Oct 2014 17:21:31 +0000 Subject: [ITK-dev] Thread-unsafety of transform classes FOLLUWUP Message-ID: This is mostly for Bradley Lowenkamp and Matt McCormick, but at some point the wider developer community will be affected and input solicited. The MatrixOffsetTransformBase has 3 values in its FixedParameters, which is the values of the center of rotation. There was a mystery as to why MatrixOffsetTransformBase starts out with 12 fixed parameters, when it only really has 3. The reason is in the constructor for Transform, which initializes the FixedParameters to have the same number of values as the Parameters. This is a design flaw; it represents the Anti-Pattern ?Initialize a member/variable to a default that is almost always wrong.? This leads to most Transform classes resizing the FixedParameters when GetFixedParameters is called, and assigning their value based on the actual fixed parameters for that Transform class. This is thread-unsafe, since resizing m_FixedParameters involves a free/allocate pair. template Transform ::Transform(NumberOfParametersType numberOfParameters) : m_Parameters(numberOfParameters), m_FixedParameters(numberOfParameters) #ifdef ITKV3_COMPATIBILITY , m_SharedLocalJacobian(NOutputDimensions, numberOfParameters) #endif { } ________________________________ 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. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From blowekamp at mail.nih.gov Tue Oct 28 13:41:07 2014 From: blowekamp at mail.nih.gov (Bradley Lowekamp) Date: Tue, 28 Oct 2014 13:41:07 -0400 Subject: [ITK-dev] Thread-unsafety of transform classes FOLLUWUP In-Reply-To: References: Message-ID: <34B144F1-76BB-497B-914A-CAAE3F2A6893@mail.nih.gov> Perhaps the constructor needs another argument name numberOfFixedParameters, which defaults to the prior argument? Brad On Oct 28, 2014, at 1:21 PM, Williams, Norman K wrote: > This is mostly for Bradley Lowenkamp and Matt McCormick, but at some point the wider developer community will be affected and input solicited. > > The MatrixOffsetTransformBase has 3 values in its FixedParameters, which is the values of the center of rotation. > > There was a mystery as to why MatrixOffsetTransformBase starts out with 12 fixed parameters, when it only really has 3. > > The reason is in the constructor for Transform, which initializes the FixedParameters to have the same number of values as the Parameters. > > This is a design flaw; it represents the Anti-Pattern ?Initialize a member/variable to a default that is almost always wrong.? > > This leads to most Transform classes resizing the FixedParameters when GetFixedParameters is called, and assigning their value based on the actual fixed parameters for that Transform class. > > This is thread-unsafe, since resizing m_FixedParameters involves a free/allocate pair. > > template unsigned int NInputDimensions, > unsigned int NOutputDimensions> > Transform > ::Transform(NumberOfParametersType numberOfParameters) : > m_Parameters(numberOfParameters), > m_FixedParameters(numberOfParameters) > #ifdef ITKV3_COMPATIBILITY > , m_SharedLocalJacobian(NOutputDimensions, numberOfParameters) > #endif > { > } > > > > 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.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://public.kitware.com/mailman/listinfo/insight-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.mccormick at kitware.com Tue Oct 28 18:20:02 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 28 Oct 2014 18:20:02 -0400 Subject: [ITK-dev] Gerrit Downtime Message-ID: Hi, Gerrit will be down tonight for maintenance. Sorry for the inconvenience. Matt From matt.mccormick at kitware.com Tue Oct 28 22:14:49 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 28 Oct 2014 22:14:49 -0400 Subject: [ITK-dev] [ITK] Thread-unsafety of transform classes FOLLUWUP In-Reply-To: <34B144F1-76BB-497B-914A-CAAE3F2A6893@mail.nih.gov> References: <34B144F1-76BB-497B-914A-CAAE3F2A6893@mail.nih.gov> Message-ID: Thanks for the further investigations. I think it should default to zero fixed parameters. Here's a patch: http://review.source.kitware.com/#/c/17789/ Thanks, Matt On Tue, Oct 28, 2014 at 1:41 PM, Bradley Lowekamp wrote: > Perhaps the constructor needs another argument name numberOfFixedParameters, > which defaults to the prior argument? > > Brad > > On Oct 28, 2014, at 1:21 PM, Williams, Norman K > wrote: > > This is mostly for Bradley Lowenkamp and Matt McCormick, but at some point > the wider developer community will be affected and input solicited. > > The MatrixOffsetTransformBase has 3 values in its FixedParameters, which is > the values of the center of rotation. > > There was a mystery as to why MatrixOffsetTransformBase starts out with 12 > fixed parameters, when it only really has 3. > > The reason is in the constructor for Transform, which initializes the > FixedParameters to have the same number of values as the Parameters. > > This is a design flaw; it represents the Anti-Pattern ?Initialize a > member/variable to a default that is almost always wrong.? > > This leads to most Transform classes resizing the FixedParameters when > GetFixedParameters is called, and assigning their value based on the actual > fixed parameters for that Transform class. > > This is thread-unsafe, since resizing m_FixedParameters involves a > free/allocate pair. > > template unsigned int NInputDimensions, > unsigned int NOutputDimensions> > Transform > ::Transform(NumberOfParametersType numberOfParameters) : > m_Parameters(numberOfParameters), > m_FixedParameters(numberOfParameters) > #ifdef ITKV3_COMPATIBILITY > , m_SharedLocalJacobian(NOutputDimensions, numberOfParameters) > #endif > { > } > > > > ________________________________ > 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.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://public.kitware.com/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.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://public.kitware.com/mailman/listinfo/insight-developers > > _______________________________________________ > Community mailing list > Community at itk.org > http://public.kitware.com/mailman/listinfo/community > From matt.mccormick at kitware.com Tue Oct 28 22:22:26 2014 From: matt.mccormick at kitware.com (Matt McCormick) Date: Tue, 28 Oct 2014 22:22:26 -0400 Subject: [ITK-dev] Opportunities to share, discuss, design, and learn with other ITK community members Message-ID: There are a couple of upcoming opportunities to share, discuss, design, and learn with your fellow ITK community members. On Thursday, 1:00 PM Eastern USA time, there will be a Google+ Hangout where we will be doing code reviews: https://plus.google.com/events/carevmgo0kpecsvrontn575i34g On Friday, 11:00 AM Eastern USA time, an ITK development conference, https://plus.google.com/events/c7hsglaqhvn0hdkkbmqki8bs580 For those that cannot join via Hangout, telephone call-in is also possible. Dial: 585-632-6296 Enter pin: 31423 To get regular invites to these events, join the ITK Bar Camp G+ Community: https://plus.google.com/u/0/communities/111375098792764998322 All are welcome. Hope to talk to you then! From norman-k-williams at uiowa.edu Fri Oct 31 11:18:54 2014 From: norman-k-williams at uiowa.edu (Williams, Norman K) Date: Fri, 31 Oct 2014 15:18:54 +0000 Subject: [ITK-dev] Patch for SpatialObject -- fixed regressions, testing with BRAINSTools Message-ID: This doesn?t fix the general problem with thread safety that your patch to Transform::GetInverse exposed, but I believe it will fix the problem with BRAINSTools test regressions. I?m testing that now. It addresses (partially) the thread safety issue in the specific case of using a SpatialObject as a mask in the registration framework. Instead of computing the inverse at every invocation of SpatialObject::IsInside, it only computes it when the transform it depends on (the IndexToWorldTransform) . Since a mask object (or any SpatialObject) is will not change its WorldToIndex transform during registration, the patch remove the crash due to more than one thread modifying the transform at the same time. It also removes potentially hundreds of thousands of calls to Transform::GetInverse() which can only improve performance. I wonder why this simple-minded optimization never showed up on anyone?s radar before. The topic in Gerrit is here: http://review.source.kitware.com/#/c/17779/ It is also in the BRAINSia git fork of ITK: https://github.com/BRAINSia/ITK/tree/SpatialObjectInternalInverse ________________________________ 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. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: