From blowekamp at mail.nih.gov  Tue Jul  1 10:32:49 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Tue, 1 Jul 2014 10:32:49 -0400
Subject: [ITK-dev] ITK Doxygen Tags and XML not updating
In-Reply-To: <CALzTN-SWHXBzgiCjQ7-GSxW9MpEUpoqNYC-QvEWjsFcn-dEA9Q@mail.gmail.com>
References: <6BB8F06E-FBCE-4F95-9EFE-6CA17B4CD2F8@mail.nih.gov>
 <CALzTN-SWHXBzgiCjQ7-GSxW9MpEUpoqNYC-QvEWjsFcn-dEA9Q@mail.gmail.com>
Message-ID: <71404C62-E870-476E-9E4E-DF033C67223B@mail.nih.gov>

It looks like it didn't work.

Further more it looks like the nightly doxygen in unavailable again. It would be good if the robustness of the system could be improved.

Brad

On Jun 30, 2014, at 1:11 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:

> Hi Brad,
> 
> Great to see all the Doxygen cross-linking!
> 
> I looked into the old tag and XML issue, and I resolved one issue.  I
> will re-check tomorrow to ensure the new version is being uploaded.
> 
> Thanks,
> Matt
> 
> On Mon, Jun 30, 2014 at 9:22 AM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>> Hello,
>> 
>> I have been using the XML[1], and tag[2] files link at the bottom the the nightly ITK doxygen page[3] for SimpleITK.
>> 
>> These files appear to be old, and not being updated recently.
>> 
>> Specifically, for SimpleITK I extract the doxygen documentation and place that into SimpleITK. Additionally, we have begun to use the ITK tags to link to the nightly ITK doxygen from SimpleITK doxygen as is done in the See Also section here[4].
>> 
>> Thanks,
>> Brad
>> 
>> [1] http://public.kitware.com/pub/itk/NightlyDoxygen/InsightDoxygenDocXml.tar.gz
>> [2] http://public.kitware.com/pub/itk/NightlyDoxygen/InsightDoxygenDocTag.gz
>> [3] http://www.itk.org/Doxygen/html/
>> [4] http://www.itk.org/SimpleITKDoxygen/html/classitk_1_1simple_1_1GridImageSource.html


From blowekamp at mail.nih.gov  Tue Jul  1 14:56:06 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Tue, 1 Jul 2014 14:56:06 -0400
Subject: [ITK-dev] Modular Code Coverage for remote modules
Message-ID: <F8946B66-E801-4C62-B055-77367B23684B@mail.nih.gov>

Hello,

I am trying to run code coverage for each remote module.

How do I restrict the coverage to just the Remote Module?

Currently it is being reported for all files run during the testing, which includes the IOs[1]. This is what I currently have [2].

Is there a magic options I need to set some place? Or do we need to add source file LABELS to enable the LABELS option to ctest_coverage[3]?

Thanks,
Brad


[1] http://open.cdash.org/viewCoverage.php?buildid=3390315
[2] http://open.cdash.org/viewNotes.php?buildid=3390283
[3] http://www.cmake.org/cmake/help/v3.0/command/ctest_coverage.html


From blowekamp at mail.nih.gov  Wed Jul  2 08:16:43 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Wed, 2 Jul 2014 08:16:43 -0400
Subject: [ITK-dev] https://issues.itk.org/jira/browse/ITK-3291
Message-ID: <93107DC9-8FE7-4853-A835-09116A3012F8@mail.nih.gov>

Hello,

With the unused-local-typedefs warning now enabled there are a large number of warning on the dashboard which should be addressed. I have created a JIRA issue to help coordinate the effort:
https://issues.itk.org/jira/browse/ITK-3291

I recommend doing this on a Group by Group basis, and logging in the JIRA ticked.

Thanks,
Brad

From matt.mccormick at kitware.com  Wed Jul  2 11:30:47 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 2 Jul 2014 11:30:47 -0400
Subject: [ITK-dev] ITK Doxygen Tags and XML not updating
In-Reply-To: <71404C62-E870-476E-9E4E-DF033C67223B@mail.nih.gov>
References: <6BB8F06E-FBCE-4F95-9EFE-6CA17B4CD2F8@mail.nih.gov>
 <CALzTN-SWHXBzgiCjQ7-GSxW9MpEUpoqNYC-QvEWjsFcn-dEA9Q@mail.gmail.com>
 <71404C62-E870-476E-9E4E-DF033C67223B@mail.nih.gov>
Message-ID: <CALzTN-T=PObnnJf5xkn-acC7megr8AfEdnH++HKncvKg=5Xi5A@mail.gmail.com>

Doxygen HTML, and Tag and XML are up again!  They are the now at the
latest version.

I also added check on the size of the generated files that will
improve robustness.

Please let me know if there are other issues that come up.

Thanks,
Matt

On Tue, Jul 1, 2014 at 10:32 AM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> It looks like it didn't work.
>
> Further more it looks like the nightly doxygen in unavailable again. It would be good if the robustness of the system could be improved.
>
> Brad
>
> On Jun 30, 2014, at 1:11 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:
>
>> Hi Brad,
>>
>> Great to see all the Doxygen cross-linking!
>>
>> I looked into the old tag and XML issue, and I resolved one issue.  I
>> will re-check tomorrow to ensure the new version is being uploaded.
>>
>> Thanks,
>> Matt
>>
>> On Mon, Jun 30, 2014 at 9:22 AM, Bradley Lowekamp
>> <blowekamp at mail.nih.gov> wrote:
>>> Hello,
>>>
>>> I have been using the XML[1], and tag[2] files link at the bottom the the nightly ITK doxygen page[3] for SimpleITK.
>>>
>>> These files appear to be old, and not being updated recently.
>>>
>>> Specifically, for SimpleITK I extract the doxygen documentation and place that into SimpleITK. Additionally, we have begun to use the ITK tags to link to the nightly ITK doxygen from SimpleITK doxygen as is done in the See Also section here[4].
>>>
>>> Thanks,
>>> Brad
>>>
>>> [1] http://public.kitware.com/pub/itk/NightlyDoxygen/InsightDoxygenDocXml.tar.gz
>>> [2] http://public.kitware.com/pub/itk/NightlyDoxygen/InsightDoxygenDocTag.gz
>>> [3] http://www.itk.org/Doxygen/html/
>>> [4] http://www.itk.org/SimpleITKDoxygen/html/classitk_1_1simple_1_1GridImageSource.html
>

From matt.mccormick at kitware.com  Wed Jul  2 11:47:08 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 2 Jul 2014 11:47:08 -0400
Subject: [ITK-dev] [ITK]  Modular Code Coverage for remote modules
In-Reply-To: <F8946B66-E801-4C62-B055-77367B23684B@mail.nih.gov>
References: <F8946B66-E801-4C62-B055-77367B23684B@mail.nih.gov>
Message-ID: <CALzTN-QbD5f5FRY4acKWYZaZRO1oTTVGv=DzE4EMHZD2_6bQHA@mail.gmail.com>

Hi Brad,

Very cool.

Yes, restricting to source file labels is a good idea. I don't think
we set the source file labels to the module name yet.  To do so, we
could get the SOURCES property of the TARGET here [1], then set the
LABELS property on those sources with set_property.

HTH,
Matt

[1] http://itk.org/gitweb?p=ITK.git;a=blob;f=CMake/ITKModuleMacros.cmake;h=c32a29eda33a0af9b7301d55e14d07567cc6f00f;hb=HEAD#l232

On Tue, Jul 1, 2014 at 2:56 PM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> Hello,
>
> I am trying to run code coverage for each remote module.
>
> How do I restrict the coverage to just the Remote Module?
>
> Currently it is being reported for all files run during the testing, which includes the IOs[1]. This is what I currently have [2].
>
> Is there a magic options I need to set some place? Or do we need to add source file LABELS to enable the LABELS option to ctest_coverage[3]?
>
> Thanks,
> Brad
>
>
> [1] http://open.cdash.org/viewCoverage.php?buildid=3390315
> [2] http://open.cdash.org/viewNotes.php?buildid=3390283
> [3] http://www.cmake.org/cmake/help/v3.0/command/ctest_coverage.html
>
> _______________________________________________
> 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 blowekamp at mail.nih.gov  Wed Jul  2 13:12:36 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Wed, 2 Jul 2014 13:12:36 -0400
Subject: [ITK-dev] ATTN: Remote Module maintainers
Message-ID: <165B2AE2-8926-48C1-8950-84C7743F35A3@mail.nih.gov>

Hello,

As part of the ITK 4.6 release candidate process I have run valgrind on a number of Remote modules and non standard modules.

Here are the results on CDash[1] and a brief summary:

IOSTL  - 14
ITKIOMINC - 30
SCIFIO - 2340
SmoothingRecursiveYvvGaussian - 29

Many of these memory defaults are easily addressable.

Thank you for your kind attention to these issue.
Brad


[1] http://open.cdash.org/index.php?project=Insight&date=2014-07-02&filtercount=3&showfilters=1&filtercombine=and&field1=buildname/string&compare1=64&value1=Linux-x86_64-gcc4.4-valgrind&field2=hasdynamicanalysis/bool&compare2=1&value2=&field3=site/string&compare3=61&value3=lhcp-rh6.nlm.nih.gov.nlm


From matt.mccormick at kitware.com  Thu Jul  3 13:35:05 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Thu, 3 Jul 2014 13:35:05 -0400
Subject: [ITK-dev] [ANNOUNCE] ITK 4.6 Release Candidate 2 has been tagged!
Message-ID: <CALzTN-Sk_yPBp23Jtiy9XU2YHONWSayn_ags+DNZkijES8qJqA@mail.gmail.com>

On behalf of the Insight Toolkit community, we are proud to announce
that ITK 4.6.0 release candidate 2 has been tagged and is available
for testing!


To obtain the source code,

  git clone http://itk.org/ITK.git
  cd ITK
  git checkout -q --detach v4.6rc02

For more details, please see the Git documentation [1].


Please test the release candidate and share your experiences on the
mailing list, issue tracker, and Gerrit Code Review. Please help
identify issues submitting an Experimental build to the dashboard [2]
with:

  ctest -M Experimental  -T Configure -T Build -T Test -T Submit

and notifying the mailing list.  Testing your own applications against
the RC is also appreciated.

Those community members wishing to contribute by cleaning up the
dashboard can find a list potential candidates on the issue tracker
[3]. Please do not hesitate to ask about any aspect of the
contribution process.

One of the issues that arose in this release candidate phase was
warnings generate by unused typedefs on newer compilers. Assistance
working on these warnings is welcome as is testing to ensure that
removed typedefs does not break code that builts against the toolkit..

Congratulations and well done to everyone that has contributed to this
release. Release candidates are tagged every week.  The final release
is scheduled for July 14th.


[1] http://www.itk.org/Wiki/ITK/Git

[2] http://open.cdash.org/index.php?project=Insight

[3] https://issues.itk.org/jira/issues/?jql=project%20%3D%20ITK%20AND%20fixVersion%20%3D%20%2220140714_ITKv4.6.0_FINAL%22%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)

New Features
------------------

* CMake improvements
  - Improved Remote Module support
  - Add ITK_FORBID_DOWNLOADS for package maintainers
  - ITK_USE_SYSTEM_EXPAT available

* Filtering Improvements
  - Moved TransformToDisplacementField out of Review
  - An entire noise image generation module
    - http://hdl.handle.net/10380/3158
  - Better pipeline support for ResampleImageFilter
  - Move MagnitudeAndPhaseToComplexImageFilter out of Review
  - Setters for LabelMap overlay filters
  - More consistent filter progress reporting

* ImageO improvements
  - Register the GE image formats by default
  - More IO modules are built as shared libraries
  - OpenFileForReading/Writing methods in ImageIO
  - Support for system tiff 4.0.0-4.0.2 (e.g. some Ubuntu versions)
  - Mangling to internal OpenJPEG
  - SCIFIO improvements

* Infrastructure improvements
  - MetaDataObject print specialization for common types
  - Improvements to ResourceProbe and RealTimeClock
  - More Solve methods for VNLSparseLUSolverTraits
  - Output stream operator for LightObject exposed
  - FFTW bump to 3.3.3

* New Remote Modules
  - Skull stripper
    - http://hdl.handle.net/10380/3353
  - Wiki examples
  - Sphinx examples
  - Variational registration
    - http://hdl.handle.net/10380/3460
  - AnalyzeObjectMapIO
    - http://hdl.handle.net/1926/593
  - FDFImageIO
  - SplitComponents
    - http://hdl.handle.net/10380/320

* Registrationv4 improvements
  - v4 regular step gradient descent optimizer
  - v4 amoeba optimizer
  - v4 exhaustive optimizer
  - v4 Powell optimizer
  - v4 one-plus-one-evolutionary optimizer
  - v4 LBFGS optimizer improvements
  - Use registration method classes as pipeline filters

* Performance improvements
  - Registrationv4
  - Histogram computation
  - Improved SmartPointer copy
  - CompositeTransform
  - Registration Jacobian re-use

* Wrapping improvements
  - pygccxml 1.0.0
  - .pth symlink usable in a virtualenv
  - Cleaner CMake configuration
  - SWIG and PCRE updated to 3.0.2, 8.34
  - Latest GCCXML, which works with GCC 4.9
  - Sweeping wrapping generation cleanup

* Many style improvements -- ITK gets more stylish with every release!

* Improved code coverage -- some measures put us over 85%!

* *Lots* of important bug fixes

* And more! See details in the log below.


List of changes since v4.6rc01
---------------------------------------

Bradley Lowekamp (3):
      BUG: Do not ENABLED_SHARED for GDCMIO
      DOC: Add break in brief description of Canny edge filter
      BUG: Add additional MetaDataObject explicit instantiation.

Jean-Christophe Fillion-Robin (2):
      COMP: Fix "unused-local-typedefs" warnings
      COMP: Fix "unused-local-typedefs" warning in
LandmarkBasedTransformInitializer

Kent Williams (1):
      COMP: Fix typo in ReflectiveImageRegionConstIterator.

Matthew McCormick (4):
      DOC: CMake warning BRANWEB -> BRAINWEB.
      BUG: Remove -Wno-unused-local-typedefs flag.
      COMP: Fix IOSTL Doxygen group and Windows shared build.
      BUG: Use Remote repository explicitly on git fetch.

Michka Popoff (6):
      COMP: Move itkMatrixCoefficients wrapping to Filtering module
      COMP: Fix wrapping with Core only
      STYLE: Pep8 cleanup for generators
      COMP: Fix default wrapping with all modules
      ENH: Use open() instead of file() for python 3 compatibility
      ENH: Allow to use methods which pass std::string by reference from python

Nick Tustison (1):
      ENH:  Adding generic computation type.

From matt.mccormick at kitware.com  Sun Jul  6 02:58:38 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Sun, 6 Jul 2014 02:58:38 -0400
Subject: [ITK-dev] [ITK] [ITK-users] Fail to execute TransformReadWrite
	example
In-Reply-To: <CA+5pysiPrrTs+rDpnsmNGKiNtqJYSnMJ85MGyWhAOsBSZAQkTA@mail.gmail.com>
References: <CA+5pysjCb933hKxi8+nb9PZoE+1j5AuvnpOSXJD5v0VQjXgUjw@mail.gmail.com>
 <CA+5pysiPrrTs+rDpnsmNGKiNtqJYSnMJ85MGyWhAOsBSZAQkTA@mail.gmail.com>
Message-ID: <CALzTN-RMsc_hvg32YLhn49WDkJi08ZN_R+XS2mVERoPcxDC5Sg@mail.gmail.com>

Hi Wagner,

Here is a patch that addresses the example [1]. Please review [2].
However, test appears to have uncovered a gap in testing coverage,
because it fails to write the CompositeTransform.  We'll have to look
into the issue further.

Thanks,
Matt

[1] http://review.source.kitware.com/#/c/16048/

[2] http://insightsoftwareconsortium.github.io/ITKBarCamp-doc/CommunitySoftwareProcess/PerformAGerritReview/index.html

On Fri, Jul 4, 2014 at 6:43 PM, Wagner Sales <wsales at gmail.com> wrote:
> Hi,
> I've found the problem. The class HDF5TransformIOTemplate makes an extension
> check. After change the transform output file to Transforms.hdf, works fine.
> I think this needs to be changed on Example and on book, since explicity
> talks:
>
>   // Then we set the filename using the SetFileName() function. The file's
> extension
>   // does not matter for the transform reader/writer. Then we call the
> Update()
>   // function to write the transform(s) onto the disk.
>
> The changed code are above:
>
> template< typename TInternalComputationValueType >
>
> bool
>
> HDF5TransformIOTemplate< TInternalComputationValueType >
>
> ::CanWriteFile(const char *fileName)
>
> {
>
>   //
>
>   // all extensions mentioned in wikipedia + 'hd5'
>
>   // actually HDF doesn't care about extensions at
>
>   // all and this is just by convention.
>
>   const char *extensions[] =
>
>   {
>
>     ".hdf",".h4",".hdf4",".h5",".hdf5",".he4",".he5",".hd5",0,
>
>   };
>
>   std::string ext
>
>     (itksys::SystemTools::GetFilenameLastExtension(fileName));
>
>   for(unsigned i = 0; extensions[i] != 0; i++)
>
>     {
>
>     if(ext == extensions[i])
>
>       {
>
>       return true;
>
>       }
>
>     }
>
>   return false;
>
> }
>
> Regards,
>
> Wagner Sales
>
>
> 2014-07-04 18:41 GMT-03:00 Wagner Sales <wsales at gmail.com>:
>
>> Hi all,
>>
>> I'm trying to save transforms and catching an strange error. I tried to
>> execute the simple example on IO directory to validate this, and:
>>
>> --> checking permission
>> wsales at wsales-desktop:/tmp/trf$ touch ihavepermission
>> wsales at wsales-desktop:/tmp/trf$ ls -la
>> total 28464
>> drwxrwxr-x  2 wsales wsales     4096 Jul  4 17:52 .
>> drwxrwxrwt 31 root   root      12288 Jul  4 17:52 ..
>> -rw-rw-r--  1 wsales wsales        0 Jul  4 17:52 ihavepermission
>> -rwxrwxr-x  1 wsales wsales 29128152 Jul  4 17:52 TransformReadWrite
>>
>> wsales at wsales-desktop:/tmp/trf$ ./TransformReadWrite test
>> Error while saving the transforms
>>
>> itk::ExceptionObject (0x2af4c30)
>> Location: "void itk::TransformFileWriterTemplate<ScalarType>::Update()
>> [with ScalarType = double]"
>> File:
>> /home/wsales/Sources/InsightToolkit-4.5.2/Modules/IO/TransformBase/include/itkTransformFileWriter.hxx
>> Line: 200
>> Description: itk::ERROR: TransformFileWriterTemplate(0x2ae6300): Can't
>> Create IO object for file Transforms.meta
>>
>> Since I can create the file, problem with permissions is not the issue.
>> About my system ( latest Ubuntu, 'll update today ):
>> uname  -a
>> Linux wsales-desktop 3.13.0-27-generic #50-Ubuntu SMP Thu May 15 18:06:16
>> UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>>
>> Compiler:
>> clang --version
>> Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM
>> 3.4)
>> Target: x86_64-pc-linux-gnu
>> Thread model: posix
>>
>> Some idea about this?
>> This example was worked fine to me on ITK 3.20, before my version upgrade.
>>
>> Regards,
>>
>> Wagner Sales
>>
>>
>>
>
>
> _____________________________________
> 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
>
> _______________________________________________
> Community mailing list
> Community at itk.org
> http://public.kitware.com/mailman/listinfo/community
>

From mohammedrashadkm at gmail.com  Mon Jul  7 11:14:35 2014
From: mohammedrashadkm at gmail.com (Rashad M)
Date: Mon, 7 Jul 2014 17:14:35 +0200
Subject: [ITK-dev] itkSignedMaurerDistanceMapImageFilterTest3 failing on
	Fedora
Message-ID: <CANNqv9dYOzwSOMwNik4=a3zUnPPsDpe132TJd7h9MNwLnAzgOw@mail.gmail.com>

Hello all,


I have a weekly submission on dashboard[1] of ITK git. The test in the
subject is always failing and a similar behavior is seen in other tests and
mostly on Fedora Linux. I am wondering weather this has something to do
with the Fedora or version of the packages in its repository (cmake etc.).
Unfortunately there is not enough submission from Fedora to confirm this.

Does anyone have any suggestions?

Fedora 20 x86_64 (Heisenbug)
cmake, ctest version 2.8.12.2
gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)

[1]
http://open.cdash.org/testSummary.php?project=2&name=itkSignedMaurerDistanceMapImageFilterTest3&date=2014-06-01

-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140707/c8b038bf/attachment.html>

From bill.lorensen at gmail.com  Mon Jul  7 14:11:02 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Mon, 7 Jul 2014 14:11:02 -0400
Subject: [ITK-dev] [ITK] itkSignedMaurerDistanceMapImageFilterTest3
 failing on Fedora
In-Reply-To: <CANNqv9dYOzwSOMwNik4=a3zUnPPsDpe132TJd7h9MNwLnAzgOw@mail.gmail.com>
References: <CANNqv9dYOzwSOMwNik4=a3zUnPPsDpe132TJd7h9MNwLnAzgOw@mail.gmail.com>
Message-ID: <CADZJ4hNtowyhEVwZaaUhYxt9_k84vORMNFh-MuRyiupBMEKdsA@mail.gmail.com>

Strange. I run Fedora 20 with the same cmake and gcc versions. My tests pass.

Bill

On Mon, Jul 7, 2014 at 11:14 AM, Rashad M <mohammedrashadkm at gmail.com> wrote:
> Hello all,
>
>
> I have a weekly submission on dashboard[1] of ITK git. The test in the
> subject is always failing and a similar behavior is seen in other tests and
> mostly on Fedora Linux. I am wondering weather this has something to do with
> the Fedora or version of the packages in its repository (cmake etc.).
> Unfortunately there is not enough submission from Fedora to confirm this.
>
> Does anyone have any suggestions?
>
> Fedora 20 x86_64 (Heisenbug)
> cmake, ctest version 2.8.12.2
> gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
>
> [1]
> http://open.cdash.org/testSummary.php?project=2&name=itkSignedMaurerDistanceMapImageFilterTest3&date=2014-06-01
>
> --
> Regards,
>    Rashad
>
> _______________________________________________
> 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
>



-- 
Unpaid intern in BillsBasement at noware dot com

From bill.lorensen at gmail.com  Mon Jul  7 14:14:58 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Mon, 7 Jul 2014 14:14:58 -0400
Subject: [ITK-dev] [ITK] itkSignedMaurerDistanceMapImageFilterTest3
 failing on Fedora
In-Reply-To: <CADZJ4hNtowyhEVwZaaUhYxt9_k84vORMNFh-MuRyiupBMEKdsA@mail.gmail.com>
References: <CANNqv9dYOzwSOMwNik4=a3zUnPPsDpe132TJd7h9MNwLnAzgOw@mail.gmail.com>
 <CADZJ4hNtowyhEVwZaaUhYxt9_k84vORMNFh-MuRyiupBMEKdsA@mail.gmail.com>
Message-ID: <CADZJ4hM_3Ak8qCo-0LzUNG_y1bFe3NfQHDvNu6oH=B2oR4KpxQ@mail.gmail.com>

Are you running with a system PND library? I see this in your output:

libpng warning: sCAL: invalid unit
libpng warning: sCAL: invalid unit

but not in my output.


On Mon, Jul 7, 2014 at 2:11 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Strange. I run Fedora 20 with the same cmake and gcc versions. My tests pass.
>
> Bill
>
> On Mon, Jul 7, 2014 at 11:14 AM, Rashad M <mohammedrashadkm at gmail.com> wrote:
>> Hello all,
>>
>>
>> I have a weekly submission on dashboard[1] of ITK git. The test in the
>> subject is always failing and a similar behavior is seen in other tests and
>> mostly on Fedora Linux. I am wondering weather this has something to do with
>> the Fedora or version of the packages in its repository (cmake etc.).
>> Unfortunately there is not enough submission from Fedora to confirm this.
>>
>> Does anyone have any suggestions?
>>
>> Fedora 20 x86_64 (Heisenbug)
>> cmake, ctest version 2.8.12.2
>> gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
>>
>> [1]
>> http://open.cdash.org/testSummary.php?project=2&name=itkSignedMaurerDistanceMapImageFilterTest3&date=2014-06-01
>>
>> --
>> Regards,
>>    Rashad
>>
>> _______________________________________________
>> 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
>>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com



-- 
Unpaid intern in BillsBasement at noware dot com

From mohammedrashadkm at gmail.com  Mon Jul  7 14:27:25 2014
From: mohammedrashadkm at gmail.com (Rashad M)
Date: Mon, 7 Jul 2014 20:27:25 +0200
Subject: [ITK-dev] [ITK] itkSignedMaurerDistanceMapImageFilterTest3
 failing on Fedora
In-Reply-To: <CADZJ4hNtowyhEVwZaaUhYxt9_k84vORMNFh-MuRyiupBMEKdsA@mail.gmail.com>
References: <CANNqv9dYOzwSOMwNik4=a3zUnPPsDpe132TJd7h9MNwLnAzgOw@mail.gmail.com>
 <CADZJ4hNtowyhEVwZaaUhYxt9_k84vORMNFh-MuRyiupBMEKdsA@mail.gmail.com>
Message-ID: <CANNqv9dpb4Ac=i7VTfcN47KgxmJhF9S+B2dKXvKxJGO5qL4MPQ@mail.gmail.com>

On Mon, Jul 7, 2014 at 8:11 PM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> Strange. I run Fedora 20 with the same cmake and gcc versions. My tests
> pass.
>

Ok. Thanks for testing this soon. I can't see any reason it fails on my
system. Everything updated weekly from git and no local changes also. But
this test is failing constantly..

>
> Bill
>
> On Mon, Jul 7, 2014 at 11:14 AM, Rashad M <mohammedrashadkm at gmail.com>
> wrote:
> > Hello all,
> >
> >
> > I have a weekly submission on dashboard[1] of ITK git. The test in the
> > subject is always failing and a similar behavior is seen in other tests
> and
> > mostly on Fedora Linux. I am wondering weather this has something to do
> with
> > the Fedora or version of the packages in its repository (cmake etc.).
> > Unfortunately there is not enough submission from Fedora to confirm this.
> >
> > Does anyone have any suggestions?
> >
> > Fedora 20 x86_64 (Heisenbug)
> > cmake, ctest version 2.8.12.2
> > gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
> >
> > [1]
> >
> http://open.cdash.org/testSummary.php?project=2&name=itkSignedMaurerDistanceMapImageFilterTest3&date=2014-06-01
> >
> > --
> > Regards,
> >    Rashad
> >
> > _______________________________________________
> > 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
> >
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>



-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140707/7394e49d/attachment.html>

From mohammedrashadkm at gmail.com  Mon Jul  7 14:32:43 2014
From: mohammedrashadkm at gmail.com (Rashad M)
Date: Mon, 7 Jul 2014 20:32:43 +0200
Subject: [ITK-dev] [ITK] itkSignedMaurerDistanceMapImageFilterTest3
 failing on Fedora
In-Reply-To: <2CD24A027ACF154199B5D6F6E5EF830BB480AD98@CINMBCNA06.e2k.ad.ge.com>
References: <CANNqv9dYOzwSOMwNik4=a3zUnPPsDpe132TJd7h9MNwLnAzgOw@mail.gmail.com>
 <CADZJ4hNtowyhEVwZaaUhYxt9_k84vORMNFh-MuRyiupBMEKdsA@mail.gmail.com>
 <CADZJ4hM_3Ak8qCo-0LzUNG_y1bFe3NfQHDvNu6oH=B2oR4KpxQ@mail.gmail.com>
 <2CD24A027ACF154199B5D6F6E5EF830BB480AD98@CINMBCNA06.e2k.ad.ge.com>
Message-ID: <CANNqv9c2MVKmFHha3h_XuykKfk=7n-ZLJ-0Ft18LmeS__4EO1g@mail.gmail.com>

Hi Miller,

But where comes mixing of libpng? I have ITK_USE_SYSTEM_PNG=ON




On Mon, Jul 7, 2014 at 8:29 PM, Miller, James V (GE Global Research) <
millerjv at ge.com> wrote:

> To back up Bill's question, I get libpng warnings like these on my Windows
> systems when reading pngs with OpenCV which were written with ITK, i.e.
> mixing versions of libpng.
>
> Jim
>
> -----Original Message-----
> From: Insight-developers [mailto:insight-developers-bounces at itk.org] On
> Behalf Of Bill Lorensen
> Sent: Monday, July 07, 2014 2:15 PM
> To: Rashad M
> Cc: ITK
> Subject: Re: [ITK-dev] [ITK] itkSignedMaurerDistanceMapImageFilterTest3
> failing on Fedora
>
> Are you running with a system PND library? I see this in your output:
>
> libpng warning: sCAL: invalid unit
> libpng warning: sCAL: invalid unit
>
> but not in my output.
>
>
> On Mon, Jul 7, 2014 at 2:11 PM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
> > Strange. I run Fedora 20 with the same cmake and gcc versions. My tests
> pass.
> >
> > Bill
> >
> > On Mon, Jul 7, 2014 at 11:14 AM, Rashad M <mohammedrashadkm at gmail.com>
> wrote:
> >> Hello all,
> >>
> >>
> >> I have a weekly submission on dashboard[1] of ITK git. The test in
> >> the subject is always failing and a similar behavior is seen in other
> >> tests and mostly on Fedora Linux. I am wondering weather this has
> >> something to do with the Fedora or version of the packages in its
> repository (cmake etc.).
> >> Unfortunately there is not enough submission from Fedora to confirm
> this.
> >>
> >> Does anyone have any suggestions?
> >>
> >> Fedora 20 x86_64 (Heisenbug)
> >> cmake, ctest version 2.8.12.2
> >> gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
> >>
> >> [1]
> >> http://open.cdash.org/testSummary.php?project=2&name=itkSignedMaurerD
> >> istanceMapImageFilterTest3&date=2014-06-01
> >>
> >> --
> >> Regards,
> >>    Rashad
> >>
> >> _______________________________________________
> >> 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
> >>
> >
> >
> >
> > --
> > Unpaid intern in BillsBasement at noware dot com
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
> _______________________________________________
> 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
>



-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140707/24795d64/attachment.html>

From millerjv at ge.com  Mon Jul  7 14:29:27 2014
From: millerjv at ge.com (Miller, James V (GE Global Research))
Date: Mon, 7 Jul 2014 18:29:27 +0000
Subject: [ITK-dev] [ITK] itkSignedMaurerDistanceMapImageFilterTest3
 failing on Fedora
In-Reply-To: <CADZJ4hM_3Ak8qCo-0LzUNG_y1bFe3NfQHDvNu6oH=B2oR4KpxQ@mail.gmail.com>
References: <CANNqv9dYOzwSOMwNik4=a3zUnPPsDpe132TJd7h9MNwLnAzgOw@mail.gmail.com>
 <CADZJ4hNtowyhEVwZaaUhYxt9_k84vORMNFh-MuRyiupBMEKdsA@mail.gmail.com>
 <CADZJ4hM_3Ak8qCo-0LzUNG_y1bFe3NfQHDvNu6oH=B2oR4KpxQ@mail.gmail.com>
Message-ID: <2CD24A027ACF154199B5D6F6E5EF830BB480AD98@CINMBCNA06.e2k.ad.ge.com>

To back up Bill's question, I get libpng warnings like these on my Windows systems when reading pngs with OpenCV which were written with ITK, i.e. mixing versions of libpng.

Jim

-----Original Message-----
From: Insight-developers [mailto:insight-developers-bounces at itk.org] On Behalf Of Bill Lorensen
Sent: Monday, July 07, 2014 2:15 PM
To: Rashad M
Cc: ITK
Subject: Re: [ITK-dev] [ITK] itkSignedMaurerDistanceMapImageFilterTest3 failing on Fedora

Are you running with a system PND library? I see this in your output:

libpng warning: sCAL: invalid unit
libpng warning: sCAL: invalid unit

but not in my output.


On Mon, Jul 7, 2014 at 2:11 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Strange. I run Fedora 20 with the same cmake and gcc versions. My tests pass.
>
> Bill
>
> On Mon, Jul 7, 2014 at 11:14 AM, Rashad M <mohammedrashadkm at gmail.com> wrote:
>> Hello all,
>>
>>
>> I have a weekly submission on dashboard[1] of ITK git. The test in 
>> the subject is always failing and a similar behavior is seen in other 
>> tests and mostly on Fedora Linux. I am wondering weather this has 
>> something to do with the Fedora or version of the packages in its repository (cmake etc.).
>> Unfortunately there is not enough submission from Fedora to confirm this.
>>
>> Does anyone have any suggestions?
>>
>> Fedora 20 x86_64 (Heisenbug)
>> cmake, ctest version 2.8.12.2
>> gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
>>
>> [1]
>> http://open.cdash.org/testSummary.php?project=2&name=itkSignedMaurerD
>> istanceMapImageFilterTest3&date=2014-06-01
>>
>> --
>> Regards,
>>    Rashad
>>
>> _______________________________________________
>> 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
>>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com



--
Unpaid intern in BillsBasement at noware dot com _______________________________________________
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 mohammedrashadkm at gmail.com  Mon Jul  7 18:46:03 2014
From: mohammedrashadkm at gmail.com (Rashad M)
Date: Tue, 8 Jul 2014 00:46:03 +0200
Subject: [ITK-dev] [ITK] itkSignedMaurerDistanceMapImageFilterTest3
 failing on Fedora
In-Reply-To: <CADZJ4hNtowyhEVwZaaUhYxt9_k84vORMNFh-MuRyiupBMEKdsA@mail.gmail.com>
References: <CANNqv9dYOzwSOMwNik4=a3zUnPPsDpe132TJd7h9MNwLnAzgOw@mail.gmail.com>
 <CADZJ4hNtowyhEVwZaaUhYxt9_k84vORMNFh-MuRyiupBMEKdsA@mail.gmail.com>
Message-ID: <CANNqv9cQC7BATnZAVWBcg3YASnAa5mnAHuecK7h51rCHfvr1dA@mail.gmail.com>

Hi,

Please see dashobard submission[1]. I had this from a different fedora 20
64 bit.  Only test failing is SingedMaurerDistanceMapImageFilter3 !!.

I will try Jim, suggestion about using internal libpng and will reply back

[1] http://open.cdash.org/testDetails.php?test=266617478&build=3400059


On Mon, Jul 7, 2014 at 8:11 PM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:

> Strange. I run Fedora 20 with the same cmake and gcc versions. My tests
> pass.
>
> Bill
>
> On Mon, Jul 7, 2014 at 11:14 AM, Rashad M <mohammedrashadkm at gmail.com>
> wrote:
> > Hello all,
> >
> >
> > I have a weekly submission on dashboard[1] of ITK git. The test in the
> > subject is always failing and a similar behavior is seen in other tests
> and
> > mostly on Fedora Linux. I am wondering weather this has something to do
> with
> > the Fedora or version of the packages in its repository (cmake etc.).
> > Unfortunately there is not enough submission from Fedora to confirm this.
> >
> > Does anyone have any suggestions?
> >
> > Fedora 20 x86_64 (Heisenbug)
> > cmake, ctest version 2.8.12.2
> > gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
> >
> > [1]
> >
> http://open.cdash.org/testSummary.php?project=2&name=itkSignedMaurerDistanceMapImageFilterTest3&date=2014-06-01
> >
> > --
> > Regards,
> >    Rashad
> >
> > _______________________________________________
> > 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
> >
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>



-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140708/6b39907b/attachment.html>

From mohammedrashadkm at gmail.com  Mon Jul  7 20:02:58 2014
From: mohammedrashadkm at gmail.com (Rashad M)
Date: Tue, 8 Jul 2014 02:02:58 +0200
Subject: [ITK-dev] [ITK] itkSignedMaurerDistanceMapImageFilterTest3
 failing on Fedora
In-Reply-To: <2CD24A027ACF154199B5D6F6E5EF830BB480B1AF@CINMBCNA06.e2k.ad.ge.com>
References: <CANNqv9dYOzwSOMwNik4=a3zUnPPsDpe132TJd7h9MNwLnAzgOw@mail.gmail.com>
 <CADZJ4hNtowyhEVwZaaUhYxt9_k84vORMNFh-MuRyiupBMEKdsA@mail.gmail.com>
 <CADZJ4hM_3Ak8qCo-0LzUNG_y1bFe3NfQHDvNu6oH=B2oR4KpxQ@mail.gmail.com>
 <2CD24A027ACF154199B5D6F6E5EF830BB480AD98@CINMBCNA06.e2k.ad.ge.com>
 <CANNqv9c2MVKmFHha3h_XuykKfk=7n-ZLJ-0Ft18LmeS__4EO1g@mail.gmail.com>
 <CANNqv9cFg=ZcU9vwievQbFp4XONHErbaXmCzTyw7VB-FCCLhkQ@mail.gmail.com>
 <2CD24A027ACF154199B5D6F6E5EF830BB480B1AF@CINMBCNA06.e2k.ad.ge.com>
Message-ID: <CANNqv9dJ3kA7HVAT_rV0PZOj3hp+GQ8cNNwbQQqmLrmBftRLHg@mail.gmail.com>

On Mon, Jul 7, 2014 at 9:09 PM, Miller, James V (GE Global Research) <
millerjv at ge.com> wrote:

>  The mixing probably come reading the original data or baseline images
> from disk.  The baseline images were created with ITK_USE_SYSTEM_PNG=OFF.
> Your system is reading them using the system png library. The ITK writers
> that created the baseline images set some fields that you are not using.
>
>
>
> But these are only warnings.  I wouldn?t expect a test to fail because of
> this.
>

Yes it is strange that using system PNG test is failing while using
internal PNG that test is passing.

dashboard submission
with system png -
http://open.cdash.org/viewTest.php?onlyfailed&buildid=3400059
with internal png - http://open.cdash.org/buildSummary.php?buildid=3400062
 (greeny submission)  :)

So to sum up on Fedora system ITK_USE_SYSTEM_PNG=OFF is the only solution?.
It works for me but would be great to have system png though.

 Jim
>
>
>
>
>
>
>
> *From:* Rashad M [mailto:mohammedrashadkm at gmail.com]
> *Sent:* Monday, July 07, 2014 2:55 PM
> *To:* Miller, James V (GE Global Research)
>
> *Subject:* Re: [ITK-dev] [ITK] itkSignedMaurerDistanceMapImageFilterTest3
> failing on Fedora
>
>
>
> Sorry I misspelled your name in last mail.
>
>
>
> On Mon, Jul 7, 2014 at 8:32 PM, Rashad M <mohammedrashadkm at gmail.com>
> wrote:
>
> Hi Miller,
>
>
>
> But where comes mixing of libpng? I have ITK_USE_SYSTEM_PNG=ON
>
>
>
>
>
>
>
> On Mon, Jul 7, 2014 at 8:29 PM, Miller, James V (GE Global Research) <
> millerjv at ge.com> wrote:
>
> To back up Bill's question, I get libpng warnings like these on my Windows
> systems when reading pngs with OpenCV which were written with ITK, i.e.
> mixing versions of libpng.
>
> Jim
>
>
> -----Original Message-----
> From: Insight-developers [mailto:insight-developers-bounces at itk.org] On
> Behalf Of Bill Lorensen
> Sent: Monday, July 07, 2014 2:15 PM
> To: Rashad M
> Cc: ITK
> Subject: Re: [ITK-dev] [ITK] itkSignedMaurerDistanceMapImageFilterTest3
> failing on Fedora
>
> Are you running with a system PND library? I see this in your output:
>
> libpng warning: sCAL: invalid unit
> libpng warning: sCAL: invalid unit
>
> but not in my output.
>
>
> On Mon, Jul 7, 2014 at 2:11 PM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
> > Strange. I run Fedora 20 with the same cmake and gcc versions. My tests
> pass.
> >
> > Bill
> >
> > On Mon, Jul 7, 2014 at 11:14 AM, Rashad M <mohammedrashadkm at gmail.com>
> wrote:
> >> Hello all,
> >>
> >>
> >> I have a weekly submission on dashboard[1] of ITK git. The test in
> >> the subject is always failing and a similar behavior is seen in other
> >> tests and mostly on Fedora Linux. I am wondering weather this has
> >> something to do with the Fedora or version of the packages in its
> repository (cmake etc.).
> >> Unfortunately there is not enough submission from Fedora to confirm
> this.
> >>
> >> Does anyone have any suggestions?
> >>
> >> Fedora 20 x86_64 (Heisenbug)
> >> cmake, ctest version 2.8.12.2
> >> gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
> >>
> >> [1]
> >> http://open.cdash.org/testSummary.php?project=2&name=itkSignedMaurerD
> >> istanceMapImageFilterTest3&date=2014-06-01
> >>
> >> --
> >> Regards,
> >>    Rashad
> >>
> >> _______________________________________________
> >> 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
> >>
> >
> >
> >
> > --
> > Unpaid intern in BillsBasement at noware dot com
>
>
>
> --
>
> Unpaid intern in BillsBasement at noware dot com
> _______________________________________________
>
> 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
>
>
>
>
>
> --
>
> Regards,
>    Rashad
>
>
>
>
>
> --
>
> Regards,
>    Rashad
>



-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140708/25a33eb6/attachment.html>

From blowekamp at mail.nih.gov  Mon Jul  7 23:11:57 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Mon, 07 Jul 2014 22:11:57 -0500
Subject: [ITK-dev] [ITK] itkSignedMaurerDistanceMapImageFilterTest3
 failing on Fedora
In-Reply-To: <CANNqv9dJ3kA7HVAT_rV0PZOj3hp+GQ8cNNwbQQqmLrmBftRLHg@mail.gmail.com>
References: <CANNqv9dYOzwSOMwNik4=a3zUnPPsDpe132TJd7h9MNwLnAzgOw@mail.gmail.com>
 <CADZJ4hNtowyhEVwZaaUhYxt9_k84vORMNFh-MuRyiupBMEKdsA@mail.gmail.com>
 <CADZJ4hM_3Ak8qCo-0LzUNG_y1bFe3NfQHDvNu6oH=B2oR4KpxQ@mail.gmail.com>
 <2CD24A027ACF154199B5D6F6E5EF830BB480AD98@CINMBCNA06.e2k.ad.ge.com>
 <CANNqv9c2MVKmFHha3h_XuykKfk=7n-ZLJ-0Ft18LmeS__4EO1g@mail.gmail.com>
 <CANNqv9cFg=ZcU9vwievQbFp4XONHErbaXmCzTyw7VB-FCCLhkQ@mail.gmail.com>
 <2CD24A027ACF154199B5D6F6E5EF830BB480B1AF@CINMBCNA06.e2k.ad.ge.com>
 <CANNqv9dJ3kA7HVAT_rV0PZOj3hp+GQ8cNNwbQQqmLrmBftRLHg@mail.gmail.com>
Message-ID: <BFC4815C-ABD3-4257-A2CB-DC3156C9D84A@mail.nih.gov>

Hello,

This is with the current master/rc? Does the previous version 4.5.1 also exhibit this issue?

Thanks,
Brad

On Jul 7, 2014, at 7:02 PM, Rashad M <mohammedrashadkm at gmail.com> wrote:

> 
> 
> 
> On Mon, Jul 7, 2014 at 9:09 PM, Miller, James V (GE Global Research) <millerjv at ge.com> wrote:
> The mixing probably come reading the original data or baseline images from disk.  The baseline images were created with ITK_USE_SYSTEM_PNG=OFF. Your system is reading them using the system png library. The ITK writers that created the baseline images set some fields that you are not using.
> 
>  
> 
> But these are only warnings.  I wouldn?t expect a test to fail because of this. 
> 
> 
> Yes it is strange that using system PNG test is failing while using internal PNG that test is passing.
> 
> dashboard submission 
> with system png - http://open.cdash.org/viewTest.php?onlyfailed&buildid=3400059
> with internal png - http://open.cdash.org/buildSummary.php?buildid=3400062  (greeny submission)  :)
> 
> So to sum up on Fedora system ITK_USE_SYSTEM_PNG=OFF is the only solution?. It works for me but would be great to have system png though.
> 
> Jim
> 
>  
> 
>  
> 
>  
> 
> From: Rashad M [mailto:mohammedrashadkm at gmail.com] 
> Sent: Monday, July 07, 2014 2:55 PM
> To: Miller, James V (GE Global Research)
> 
> 
> Subject: Re: [ITK-dev] [ITK] itkSignedMaurerDistanceMapImageFilterTest3 failing on Fedora
> 
>  
> 
> Sorry I misspelled your name in last mail.
> 
>  
> 
> On Mon, Jul 7, 2014 at 8:32 PM, Rashad M <mohammedrashadkm at gmail.com> wrote:
> 
> Hi Miller,
> 
>  
> 
> But where comes mixing of libpng? I have ITK_USE_SYSTEM_PNG=ON
> 
>  
> 
>  
> 
>  
> 
> On Mon, Jul 7, 2014 at 8:29 PM, Miller, James V (GE Global Research) <millerjv at ge.com> wrote:
> 
> To back up Bill's question, I get libpng warnings like these on my Windows systems when reading pngs with OpenCV which were written with ITK, i.e. mixing versions of libpng.
> 
> Jim
> 
> 
> -----Original Message-----
> From: Insight-developers [mailto:insight-developers-bounces at itk.org] On Behalf Of Bill Lorensen
> Sent: Monday, July 07, 2014 2:15 PM
> To: Rashad M
> Cc: ITK
> Subject: Re: [ITK-dev] [ITK] itkSignedMaurerDistanceMapImageFilterTest3 failing on Fedora
> 
> Are you running with a system PND library? I see this in your output:
> 
> libpng warning: sCAL: invalid unit
> libpng warning: sCAL: invalid unit
> 
> but not in my output.
> 
> 
> On Mon, Jul 7, 2014 at 2:11 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> > Strange. I run Fedora 20 with the same cmake and gcc versions. My tests pass.
> >
> > Bill
> >
> > On Mon, Jul 7, 2014 at 11:14 AM, Rashad M <mohammedrashadkm at gmail.com> wrote:
> >> Hello all,
> >>
> >>
> >> I have a weekly submission on dashboard[1] of ITK git. The test in
> >> the subject is always failing and a similar behavior is seen in other
> >> tests and mostly on Fedora Linux. I am wondering weather this has
> >> something to do with the Fedora or version of the packages in its repository (cmake etc.).
> >> Unfortunately there is not enough submission from Fedora to confirm this.
> >>
> >> Does anyone have any suggestions?
> >>
> >> Fedora 20 x86_64 (Heisenbug)
> >> cmake, ctest version 2.8.12.2
> >> gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
> >>
> >> [1]
> >> http://open.cdash.org/testSummary.php?project=2&name=itkSignedMaurerD
> >> istanceMapImageFilterTest3&date=2014-06-01
> >>
> >> --
> >> Regards,
> >>    Rashad
> >>
> >> _______________________________________________
> >> 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
> >>
> >
> >
> >
> > --
> > Unpaid intern in BillsBasement at noware dot com
> 
> 
> 
> --
> 
> Unpaid intern in BillsBasement at noware dot com _______________________________________________
> 
> 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
> 
> 
> 
> 
>  
> 
> --
> 
> Regards,
>    Rashad
> 
> 
> 
> 
>  
> 
> --
> 
> Regards,
>    Rashad
> 
> 
> 
> 
> -- 
> Regards,
>    Rashad
> _______________________________________________
> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20140707/a5cf7742/attachment-0001.html>

From mohammedrashadkm at gmail.com  Tue Jul  8 03:15:33 2014
From: mohammedrashadkm at gmail.com (Rashad M)
Date: Tue, 8 Jul 2014 09:15:33 +0200
Subject: [ITK-dev] [ITK] itkSignedMaurerDistanceMapImageFilterTest3
 failing on Fedora
In-Reply-To: <BFC4815C-ABD3-4257-A2CB-DC3156C9D84A@mail.nih.gov>
References: <CANNqv9dYOzwSOMwNik4=a3zUnPPsDpe132TJd7h9MNwLnAzgOw@mail.gmail.com>
 <CADZJ4hNtowyhEVwZaaUhYxt9_k84vORMNFh-MuRyiupBMEKdsA@mail.gmail.com>
 <CADZJ4hM_3Ak8qCo-0LzUNG_y1bFe3NfQHDvNu6oH=B2oR4KpxQ@mail.gmail.com>
 <2CD24A027ACF154199B5D6F6E5EF830BB480AD98@CINMBCNA06.e2k.ad.ge.com>
 <CANNqv9c2MVKmFHha3h_XuykKfk=7n-ZLJ-0Ft18LmeS__4EO1g@mail.gmail.com>
 <CANNqv9cFg=ZcU9vwievQbFp4XONHErbaXmCzTyw7VB-FCCLhkQ@mail.gmail.com>
 <2CD24A027ACF154199B5D6F6E5EF830BB480B1AF@CINMBCNA06.e2k.ad.ge.com>
 <CANNqv9dJ3kA7HVAT_rV0PZOj3hp+GQ8cNNwbQQqmLrmBftRLHg@mail.gmail.com>
 <BFC4815C-ABD3-4257-A2CB-DC3156C9D84A@mail.nih.gov>
Message-ID: <CANNqv9dvBRCD5VYqAfT9e_=P+SPx7hw4Nyz8WL23FisWoyY+Xg@mail.gmail.com>

Hi Brad,

Yes. this problem exists with 4.5 version and also with current git master.


On Tue, Jul 8, 2014 at 5:11 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>
wrote:

> Hello,
>
> This is with the current master/rc? Does the previous version 4.5.1 also
> exhibit this issue?
>
> Thanks,
> Brad
>
> On Jul 7, 2014, at 7:02 PM, Rashad M <mohammedrashadkm at gmail.com> wrote:
>
>
>
>
> On Mon, Jul 7, 2014 at 9:09 PM, Miller, James V (GE Global Research) <
> millerjv at ge.com> wrote:
>
>>  The mixing probably come reading the original data or baseline images
>> from disk.  The baseline images were created with ITK_USE_SYSTEM_PNG=OFF.
>> Your system is reading them using the system png library. The ITK writers
>> that created the baseline images set some fields that you are not using.
>>
>>
>>
>> But these are only warnings.  I wouldn?t expect a test to fail because of
>> this.
>>
>
> Yes it is strange that using system PNG test is failing while using
> internal PNG that test is passing.
>
> dashboard submission
> with system png -
> http://open.cdash.org/viewTest.php?onlyfailed&buildid=3400059
> with internal png - http://open.cdash.org/buildSummary.php?buildid=3400062
>  (greeny submission)  :)
>
> So to sum up on Fedora system ITK_USE_SYSTEM_PNG=OFF is the only
> solution?. It works for me but would be great to have system png though.
>
> Jim
>>
>>
>>
>>
>>
>>
>>
>> *From:* Rashad M [mailto:mohammedrashadkm at gmail.com]
>> *Sent:* Monday, July 07, 2014 2:55 PM
>> *To:* Miller, James V (GE Global Research)
>>
>> *Subject:* Re: [ITK-dev] [ITK]
>> itkSignedMaurerDistanceMapImageFilterTest3 failing on Fedora
>>
>>
>>
>> Sorry I misspelled your name in last mail.
>>
>>
>>
>> On Mon, Jul 7, 2014 at 8:32 PM, Rashad M <mohammedrashadkm at gmail.com>
>> wrote:
>>
>> Hi Miller,
>>
>>
>>
>> But where comes mixing of libpng? I have ITK_USE_SYSTEM_PNG=ON
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Jul 7, 2014 at 8:29 PM, Miller, James V (GE Global Research) <
>> millerjv at ge.com> wrote:
>>
>> To back up Bill's question, I get libpng warnings like these on my
>> Windows systems when reading pngs with OpenCV which were written with ITK,
>> i.e. mixing versions of libpng.
>>
>> Jim
>>
>>
>> -----Original Message-----
>> From: Insight-developers [mailto:insight-developers-bounces at itk.org] On
>> Behalf Of Bill Lorensen
>> Sent: Monday, July 07, 2014 2:15 PM
>> To: Rashad M
>> Cc: ITK
>> Subject: Re: [ITK-dev] [ITK] itkSignedMaurerDistanceMapImageFilterTest3
>> failing on Fedora
>>
>> Are you running with a system PND library? I see this in your output:
>>
>> libpng warning: sCAL: invalid unit
>> libpng warning: sCAL: invalid unit
>>
>> but not in my output.
>>
>>
>> On Mon, Jul 7, 2014 at 2:11 PM, Bill Lorensen <bill.lorensen at gmail.com>
>> wrote:
>> > Strange. I run Fedora 20 with the same cmake and gcc versions. My tests
>> pass.
>> >
>> > Bill
>> >
>> > On Mon, Jul 7, 2014 at 11:14 AM, Rashad M <mohammedrashadkm at gmail.com>
>> wrote:
>> >> Hello all,
>> >>
>> >>
>> >> I have a weekly submission on dashboard[1] of ITK git. The test in
>> >> the subject is always failing and a similar behavior is seen in other
>> >> tests and mostly on Fedora Linux. I am wondering weather this has
>> >> something to do with the Fedora or version of the packages in its
>> repository (cmake etc.).
>> >> Unfortunately there is not enough submission from Fedora to confirm
>> this.
>> >>
>> >> Does anyone have any suggestions?
>> >>
>> >> Fedora 20 x86_64 (Heisenbug)
>> >> cmake, ctest version 2.8.12.2
>> >> gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
>> >>
>> >> [1]
>> >> http://open.cdash.org/testSummary.php?project=2&name=itkSignedMaurerD
>> >> istanceMapImageFilterTest3&date=2014-06-01
>> >>
>> >> --
>> >> Regards,
>> >>    Rashad
>> >>
>> >> _______________________________________________
>> >> 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
>> >>
>> >
>> >
>> >
>> > --
>> > Unpaid intern in BillsBasement at noware dot com
>>
>>
>>
>> --
>>
>> Unpaid intern in BillsBasement at noware dot com
>> _______________________________________________
>>
>> 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
>>
>>
>>
>>
>>
>> --
>>
>> Regards,
>>    Rashad
>>
>>
>>
>>
>>
>> --
>>
>> Regards,
>>    Rashad
>>
>
>
>
> --
> Regards,
>    Rashad
>  _______________________________________________
> 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
>
>
>


-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140708/40d41a0f/attachment.html>

From jerome.velut at kitware.com  Wed Jul  9 08:57:18 2014
From: jerome.velut at kitware.com (Jerome Velut)
Date: Wed, 9 Jul 2014 14:57:18 +0200
Subject: [ITK-dev] ANN: ITK course in Lyon, France - October 2nd
Message-ID: <CAG8ZUkFgz4GtqkTAP2Tjiir_FcU2kkATdKq02rg68HDg7eczTQ@mail.gmail.com>

Kitware will be holding a developers training course on October 2nd 2014 in
Lyon, France. This course will cover the features of ITKv4 :
- Overview/Architecture
- Segmentation
- Registration
- Using ITK in your applications

Please visit our web site for more information and registration details at :

http://formations.kitware.fr/browse/50
<http://formations.kitware.fr/browse/65>

Note that the course will be taught in English. If you have any questions,
please contact us at courses[at]kitware.com or formations[at]kitware.fr.


Best regards,

-- 
J?r?me Velut
Research and Development
Kitware SAS
26 rue Louis Gu?rin
69100 Villeurbanne, France
F: +33 (0)4.37.45.04.15
http://www.kitware.fr
http://www.kitware.fr/company/team/velut.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140709/ec37bf0b/attachment.html>

From norman-k-williams at uiowa.edu  Fri Jul 11 10:14:11 2014
From: norman-k-williams at uiowa.edu (Williams, Norman K)
Date: Fri, 11 Jul 2014 14:14:11 +0000
Subject: [ITK-dev] Deprecated Begin/End in iterators?
Message-ID: <CFE55B62.8DB2%norman-k-williams@uiowa.edu>

I ran into this when doing an explicit instantiation of ImageRegionIterator.

Explicit instantiation will elaborate every method in a class, not just the ones that are called, so ImageRegionIterator::Begin (which is deprecated) is implemented by calling Superclass::Begin (which is also deprecated) which throws a compiler warning about the method being deprecated.

My first impulse was to change the implementation to call the non-deprecated Superclass::GoToBegin,  but that?s kind of silly ? it?s probably not worth the effort to push through Gerrit.

The real question is this: Why are Begin and End deprecated in the Image Region iterators, and not in all the other classes?  There are a lot of classes that have Begin/End and not GoToBegin and GoToEnd:

ConstShapedNeighborhoodIterator
ConstSliceIterator
EquivalencyTable
FixedArray
FixedArray
ImageConstIterator
ImageConstIteratorWithIndex
ImageConstIteratorWithOnlyIndex
ImageIterator
ImageRegionConstIterator
ImageRegionIterator
ImageRegionReverseConstIterator
ImageRegionReverseIterator
ImageReverseConstIterator
IndexedContainerInterface
IndexedContainerInterface
MapContainer
MapContainer
MetaDataDictionary
MetaDataDictionary
Neighborhood
Neighborhood
NeighborhoodIterator
ObjectStore
Point
ShapedNeighborhoodIterator
SliceIterator
SparseFieldLayer
SparseFieldLayer
SpecialCoordinatesImage
ThreadedIteratorRangePartitioner
VectorContainer
VectorContainer
NarrowBand
NarrowBand
MultivariateLegendrePolynomial
MultivariateLegendrePolynomial
Histogram
Histogram
ImageToListSampleAdaptor
ImageToListSampleAdaptor
ImageToNeighborhoodSampleAdaptor
ImageToNeighborhoodSampleAdaptor
JointDomainImageToListSampleAdaptor
JointDomainImageToListSampleAdaptor
ListSample
ListSample
MembershipSample
MembershipSample
PointSetToListSampleAdaptor
PointSetToListSampleAdaptor
Subsample
Subsample
VectorContainerToListSampleAdaptor
VectorContainerToListSampleAdaptor
LevelSetContainerBase
LevelSetContainerBase
LevelSetEquationContainer
LevelSetEquationContainer
LevelSetEquationTermContainer
LevelSetEquationTermContainer
OneWayEquivalencyTable
WatershedSegmentTable
WatershedSegmentTable
WatershedSegmentTree
WatershedSegmentTree



________________________________
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: <http://public.kitware.com/pipermail/insight-developers/attachments/20140711/a40981ca/attachment.html>

From matt.mccormick at kitware.com  Fri Jul 11 10:53:35 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Fri, 11 Jul 2014 10:53:35 -0400
Subject: [ITK-dev] [ITK]  Deprecated Begin/End in iterators?
In-Reply-To: <CFE55B62.8DB2%norman-k-williams@uiowa.edu>
References: <CFE55B62.8DB2%norman-k-williams@uiowa.edu>
Message-ID: <CALzTN-QmncSPSg+mndAieTxieRv92=zzgqzxk8xKtc6h+SJXAA@mail.gmail.com>

Hi Kent,

I think this is a bug -- they should all be deprecated -- with ITKv4
we tried to use GoToBegin and GoToEnd consistently.

Thanks,
Matt

On Fri, Jul 11, 2014 at 10:14 AM, Williams, Norman K
<norman-k-williams at uiowa.edu> wrote:
> I ran into this when doing an explicit instantiation of ImageRegionIterator.
>
> Explicit instantiation will elaborate every method in a class, not just the
> ones that are called, so ImageRegionIterator::Begin (which is deprecated) is
> implemented by calling Superclass::Begin (which is also deprecated) which
> throws a compiler warning about the method being deprecated.
>
> My first impulse was to change the implementation to call the non-deprecated
> Superclass::GoToBegin,  but that?s kind of silly ? it?s probably not worth
> the effort to push through Gerrit.
>
> The real question is this: Why are Begin and End deprecated in the Image
> Region iterators, and not in all the other classes?  There are a lot of
> classes that have Begin/End and not GoToBegin and GoToEnd:
>
> ConstShapedNeighborhoodIterator
> ConstSliceIterator
> EquivalencyTable
> FixedArray
> FixedArray
> ImageConstIterator
> ImageConstIteratorWithIndex
> ImageConstIteratorWithOnlyIndex
> ImageIterator
> ImageRegionConstIterator
> ImageRegionIterator
> ImageRegionReverseConstIterator
> ImageRegionReverseIterator
> ImageReverseConstIterator
> IndexedContainerInterface
> IndexedContainerInterface
> MapContainer
> MapContainer
> MetaDataDictionary
> MetaDataDictionary
> Neighborhood
> Neighborhood
> NeighborhoodIterator
> ObjectStore
> Point
> ShapedNeighborhoodIterator
> SliceIterator
> SparseFieldLayer
> SparseFieldLayer
> SpecialCoordinatesImage
> ThreadedIteratorRangePartitioner
> VectorContainer
> VectorContainer
> NarrowBand
> NarrowBand
> MultivariateLegendrePolynomial
> MultivariateLegendrePolynomial
> Histogram
> Histogram
> ImageToListSampleAdaptor
> ImageToListSampleAdaptor
> ImageToNeighborhoodSampleAdaptor
> ImageToNeighborhoodSampleAdaptor
> JointDomainImageToListSampleAdaptor
> JointDomainImageToListSampleAdaptor
> ListSample
> ListSample
> MembershipSample
> MembershipSample
> PointSetToListSampleAdaptor
> PointSetToListSampleAdaptor
> Subsample
> Subsample
> VectorContainerToListSampleAdaptor
> VectorContainerToListSampleAdaptor
> LevelSetContainerBase
> LevelSetContainerBase
> LevelSetEquationContainer
> LevelSetEquationContainer
> LevelSetEquationTermContainer
> LevelSetEquationTermContainer
> OneWayEquivalencyTable
> WatershedSegmentTable
> WatershedSegmentTable
> WatershedSegmentTree
> WatershedSegmentTree
>
>
>
> ________________________________
> 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 millerjv at ge.com  Fri Jul 11 10:24:31 2014
From: millerjv at ge.com (Miller, James V (GE Global Research))
Date: Fri, 11 Jul 2014 14:24:31 +0000
Subject: [ITK-dev] Deprecated Begin/End in iterators?
In-Reply-To: <CFE55B62.8DB2%norman-k-williams@uiowa.edu>
References: <CFE55B62.8DB2%norman-k-williams@uiowa.edu>
Message-ID: <2CD24A027ACF154199B5D6F6E5EF830BB48182B4@CINMBCNA06.e2k.ad.ge.com>

Background.

In STL, one requests an iterator from a container using the begin()/end() methods.  In ITK, we have many potential iterator types to run across an image, so we removed the iterators from the containers (image). There is a fair amount of work to initialize an image iterator, so rather than constructing new iterators (in loops) using methods like begin()/end(), we created the GoToBegin()/IsAtEnd() methods.

Current issue.

If Begin() on an iterator returns an iterator, then it should be deprecated. We'd rather people use use GoToBegin()/IsAtEnd() to be efficient.

Begin()/End() should have been removed from all Image iterators long ago.

But many of the other types listed (MapContainer, FixedArray, Neighborhood, ...) follow the STL paradigm more closely (where you ask a container for an iterator) and these should have Begin()/End() methods and probably should not have GoToBegin()/GoToEnd().

So in summary, Begin()/End() should be called on a container to return an iterator while GoToBegin()/IsAtEnd() should be called on an iterator to reset or test the end condition.

Jim


From: Insight-developers [mailto:insight-developers-bounces at itk.org] On Behalf Of Williams, Norman K
Sent: Friday, July 11, 2014 10:14 AM
To: ITK
Subject: [ITK-dev] Deprecated Begin/End in iterators?

I ran into this when doing an explicit instantiation of ImageRegionIterator.

Explicit instantiation will elaborate every method in a class, not just the ones that are called, so ImageRegionIterator::Begin (which is deprecated) is implemented by calling Superclass::Begin (which is also deprecated) which throws a compiler warning about the method being deprecated.

My first impulse was to change the implementation to call the non-deprecated Superclass::GoToBegin,  but that's kind of silly - it's probably not worth the effort to push through Gerrit.

The real question is this: Why are Begin and End deprecated in the Image Region iterators, and not in all the other classes?  There are a lot of classes that have Begin/End and not GoToBegin and GoToEnd:

ConstShapedNeighborhoodIterator
ConstSliceIterator
EquivalencyTable
FixedArray
FixedArray
ImageConstIterator
ImageConstIteratorWithIndex
ImageConstIteratorWithOnlyIndex
ImageIterator
ImageRegionConstIterator
ImageRegionIterator
ImageRegionReverseConstIterator
ImageRegionReverseIterator
ImageReverseConstIterator
IndexedContainerInterface
IndexedContainerInterface
MapContainer
MapContainer
MetaDataDictionary
MetaDataDictionary
Neighborhood
Neighborhood
NeighborhoodIterator
ObjectStore
Point
ShapedNeighborhoodIterator
SliceIterator
SparseFieldLayer
SparseFieldLayer
SpecialCoordinatesImage
ThreadedIteratorRangePartitioner
VectorContainer
VectorContainer
NarrowBand
NarrowBand
MultivariateLegendrePolynomial
MultivariateLegendrePolynomial
Histogram
Histogram
ImageToListSampleAdaptor
ImageToListSampleAdaptor
ImageToNeighborhoodSampleAdaptor
ImageToNeighborhoodSampleAdaptor
JointDomainImageToListSampleAdaptor
JointDomainImageToListSampleAdaptor
ListSample
ListSample
MembershipSample
MembershipSample
PointSetToListSampleAdaptor
PointSetToListSampleAdaptor
Subsample
Subsample
VectorContainerToListSampleAdaptor
VectorContainerToListSampleAdaptor
LevelSetContainerBase
LevelSetContainerBase
LevelSetEquationContainer
LevelSetEquationContainer
LevelSetEquationTermContainer
LevelSetEquationTermContainer
OneWayEquivalencyTable
WatershedSegmentTable
WatershedSegmentTable
WatershedSegmentTree
WatershedSegmentTree


________________________________
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: <http://public.kitware.com/pipermail/insight-developers/attachments/20140711/0703f1cd/attachment.html>

From matt.mccormick at kitware.com  Sat Jul 12 13:10:32 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Sat, 12 Jul 2014 13:10:32 -0400
Subject: [ITK-dev] [ANNOUNCE] ITK 4.6 Release Candidate 3 has been tagged!
Message-ID: <CALzTN-SPv-k6APtSWP1cL0JmU7mp2oW-wbyL5EQVetOkfLWzVQ@mail.gmail.com>

On behalf of the Insight Toolkit community, we are proud to announce
that ITK 4.6.0 release candidate 3 has been tagged and is available
for testing!


To obtain the source code,

  git clone http://itk.org/ITK.git
  cd ITK
  git checkout -q --detach v4.6rc03

For more details, please see the Git documentation [1].


Please test the release candidate and share your experiences on the
mailing list, issue tracker, and Gerrit Code Review. Please help
identify issues submitting an Experimental build to the dashboard [2]
with:

  ctest -M Experimental  -T Configure -T Build -T Test -T Submit

and notifying the mailing list.  Testing your own applications against
the RC is also appreciated.

Those community members wishing to contribute by cleaning up the
dashboard can find a list potential candidates on the issue tracker
[3]. Please do not hesitate to ask about any aspect of the
contribution process.


Congratulations and well done to everyone that has contributed to this
release. Release candidates are tagged every week.  The final release
is scheduled for next week.


[1] http://www.itk.org/Wiki/ITK/Git

[2] http://open.cdash.org/index.php?project=Insight

[3] https://issues.itk.org/jira/issues/?jql=project%20%3D%20ITK%20AND%20fixVersion%20%3D%20%2220140714_ITKv4.6.0_FINAL%22%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)

New Features
------------------

* CMake improvements
  - Improved Remote Module support
  - Add ITK_FORBID_DOWNLOADS for package maintainers
  - ITK_USE_SYSTEM_EXPAT available

* Filtering Improvements
  - Moved TransformToDisplacementField out of Review
  - An entire noise image generation module
    - http://hdl.handle.net/10380/3158
  - Better pipeline support for ResampleImageFilter
  - Move MagnitudeAndPhaseToComplexImageFilter out of Review
  - Setters for LabelMap overlay filters
  - More consistent filter progress reporting

* ImageIO improvements
  - Register the GE image formats by default
  - More IO modules are built as shared libraries
  - OpenFileForReading/Writing methods in ImageIO
  - Support for system tiff 4.0.0-4.0.2 (e.g. some Ubuntu versions)
  - Mangling to internal OpenJPEG
  - SCIFIO improvements

* Infrastructure improvements
  - MetaDataObject print specialization for common types
  - Improvements to ResourceProbe and RealTimeClock
  - More Solve methods for VNLSparseLUSolverTraits
  - Output stream operator for LightObject exposed
  - FFTW bump to 3.3.3

* New Remote Modules
  - Skull stripper
    - http://hdl.handle.net/10380/3353
  - Wiki examples
  - Sphinx examples
  - Variational registration
    - http://hdl.handle.net/10380/3460
  - AnalyzeObjectMapIO
    - http://hdl.handle.net/1926/593
  - FDFImageIO
  - SplitComponents
    - http://hdl.handle.net/10380/320

* Registrationv4 improvements
  - v4 regular step gradient descent optimizer
  - v4 amoeba optimizer
  - v4 exhaustive optimizer
  - v4 Powell optimizer
  - v4 one-plus-one-evolutionary optimizer
  - v4 LBFGS optimizer improvements
  - Use registration method classes as pipeline filters

* Performance improvements
  - Registrationv4
  - Histogram computation
  - Improved SmartPointer copy
  - CompositeTransform
  - Registration Jacobian re-use

* Wrapping improvements
  - pygccxml 1.0.0
  - .pth symlink usable in a virtualenv
  - Cleaner CMake configuration
  - SWIG and PCRE updated to 3.0.2, 8.34
  - Latest GCCXML, which works with GCC 4.9
  - Sweeping wrapping generation cleanup

* Many style improvements -- ITK gets more stylish with every release!

* Improved code coverage -- some measures put us over 85%!

* *Lots* of important bug fixes

* And more! See details in the log below.

List of changes since v4.6rc02
---------------------------------------

Ali Ghayoor (1):
      ENH: Convert seven ImageRegistration examples to ITKv4

Bradley Lowekamp (2):
      BUG: Remove multiple per-pixel allocations in Mahalanobis Membership
      COMP: Fix unused-local-typedef warnings in the Registration and Numeric

Hans Johnson (1):
      ENH: Prepare for ITKv4 registration Examples

Matthew McCormick (5):
      BUG: Improve module Group membership detection.
      COMP: Fix unused-local-typedef warnings in Group Core.
      BUG: Update TransformReadWrite example.
      COMP: Fix unused-local-typedef warnings in the Filtering Group.
      COMP: Remove unused typedefs.

Nick Tustison (1):
      ENH:  Missed spec for generic computation type.

From blowekamp at mail.nih.gov  Wed Jul 16 11:27:46 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Wed, 16 Jul 2014 11:27:46 -0400
Subject: [ITK-dev] Debian Sid Otsu Failing tests
Message-ID: <1A1E2838-8189-426C-B4F0-AC14EFB71374@mail.nih.gov>

Hello,

There is a bit of work going on to track down this failing test:

http://open.cdash.org/testDetails.php?test=268467426&build=3411169

There is currently a bit of a dialog here:
http://review.source.kitware.com/#/c/16164/

Current information is that it fails in release, passes in debug. Can be reproduced with gcc 4.4.7 RHEL5 with "-m32 -march=i386", and printing the variable changes the results...


This test just started failing on the 3rd of this month:

http://open.cdash.org/index.php?project=Insight&date=2014-07-03

what changed...

Did the compiler change?

Brad






From matt.mccormick at kitware.com  Wed Jul 16 11:40:28 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 16 Jul 2014 11:40:28 -0400
Subject: [ITK-dev] Debian Sid Otsu Failing tests
In-Reply-To: <1A1E2838-8189-426C-B4F0-AC14EFB71374@mail.nih.gov>
References: <1A1E2838-8189-426C-B4F0-AC14EFB71374@mail.nih.gov>
Message-ID: <CALzTN-QTMNEa9v7-QKjYfeqPWGBP-sOXpAfXu5Qxjw75pGW4vg@mail.gmail.com>

Hi,

It may be related to how floats are handled?  Regardless, this patch
fixes the test:

  http://review.source.kitware.com/#/c/16230/

Thanks,
Matt

On Wed, Jul 16, 2014 at 11:27 AM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> Hello,
>
> There is a bit of work going on to track down this failing test:
>
> http://open.cdash.org/testDetails.php?test=268467426&build=3411169
>
> There is currently a bit of a dialog here:
> http://review.source.kitware.com/#/c/16164/
>
> Current information is that it fails in release, passes in debug. Can be reproduced with gcc 4.4.7 RHEL5 with "-m32 -march=i386", and printing the variable changes the results...
>
>
> This test just started failing on the 3rd of this month:
>
> http://open.cdash.org/index.php?project=Insight&date=2014-07-03
>
> what changed...
>
> Did the compiler change?
>
> Brad
>
>
>
>
>

From norman-k-williams at uiowa.edu  Fri Jul 18 10:36:42 2014
From: norman-k-williams at uiowa.edu (Williams, Norman K)
Date: Fri, 18 Jul 2014 14:36:42 +0000
Subject: [ITK-dev] [ITK]  Deprecated Begin/End in iterators?
In-Reply-To: <CALzTN-QmncSPSg+mndAieTxieRv92=zzgqzxk8xKtc6h+SJXAA@mail.gmail.com>
References: <CFE55B62.8DB2%norman-k-williams@uiowa.edu>
 <CALzTN-QmncSPSg+mndAieTxieRv92=zzgqzxk8xKtc6h+SJXAA@mail.gmail.com>
Message-ID: <CFEE9A90.981F%norman-k-williams@uiowa.edu>

I can?t find his reply in my ITK developer list folder ? likely because Outlook for OS X is a total piece of crap ? but here is what Jim Miller said:

Background.

In STL, one requests an iterator from a container using the begin()/end() methods.  In ITK, we have many potential iterator types to run across an image, so we removed the iterators from the containers (image). There is a fair amount of work to initialize an image iterator, so rather than constructing new iterators (in loops) using methods like begin()/end(), we created the GoToBegin()/IsAtEnd() methods.

Current issue.

If Begin() on an iterator returns an iterator, then it should be deprecated. We?d rather people use use GoToBegin()/IsAtEnd() to be efficient.

Begin()/End() should have been removed from all Image iterators long ago.

But many of the other types listed (MapContainer, FixedArray, Neighborhood, ?) follow the STL paradigm more closely (where you ask a container for an iterator) and these should have Begin()/End() methods and probably should not have GoToBegin()/GoToEnd().

So in summary, Begin()/End() should be called on a container to return an iterator while GoToBegin()/IsAtEnd() should be called on an iterator to reset or test the end condition.

Jim

On 7/11/14, 9:53 AM, "Matt McCormick" <matt.mccormick at kitware.com<mailto:matt.mccormick at kitware.com>> wrote:

Hi Kent,

I think this is a bug -- they should all be deprecated -- with ITKv4
we tried to use GoToBegin and GoToEnd consistently.

Thanks,
Matt

On Fri, Jul 11, 2014 at 10:14 AM, Williams, Norman K
<norman-k-williams at uiowa.edu<mailto:norman-k-williams at uiowa.edu>> wrote:
I ran into this when doing an explicit instantiation of ImageRegionIterator.

Explicit instantiation will elaborate every method in a class, not just the
ones that are called, so ImageRegionIterator::Begin (which is deprecated) is
implemented by calling Superclass::Begin (which is also deprecated) which
throws a compiler warning about the method being deprecated.

My first impulse was to change the implementation to call the non-deprecated
Superclass::GoToBegin,  but that?s kind of silly ? it?s probably not worth
the effort to push through Gerrit.

The real question is this: Why are Begin and End deprecated in the Image
Region iterators, and not in all the other classes?  There are a lot of
classes that have Begin/End and not GoToBegin and GoToEnd:

ConstShapedNeighborhoodIterator
ConstSliceIterator
EquivalencyTable
FixedArray
FixedArray
ImageConstIterator
ImageConstIteratorWithIndex
ImageConstIteratorWithOnlyIndex
ImageIterator
ImageRegionConstIterator
ImageRegionIterator
ImageRegionReverseConstIterator
ImageRegionReverseIterator
ImageReverseConstIterator
IndexedContainerInterface
IndexedContainerInterface
MapContainer
MapContainer
MetaDataDictionary
MetaDataDictionary
Neighborhood
Neighborhood
NeighborhoodIterator
ObjectStore
Point
ShapedNeighborhoodIterator
SliceIterator
SparseFieldLayer
SparseFieldLayer
SpecialCoordinatesImage
ThreadedIteratorRangePartitioner
VectorContainer
VectorContainer
NarrowBand
NarrowBand
MultivariateLegendrePolynomial
MultivariateLegendrePolynomial
Histogram
Histogram
ImageToListSampleAdaptor
ImageToListSampleAdaptor
ImageToNeighborhoodSampleAdaptor
ImageToNeighborhoodSampleAdaptor
JointDomainImageToListSampleAdaptor
JointDomainImageToListSampleAdaptor
ListSample
ListSample
MembershipSample
MembershipSample
PointSetToListSampleAdaptor
PointSetToListSampleAdaptor
Subsample
Subsample
VectorContainerToListSampleAdaptor
VectorContainerToListSampleAdaptor
LevelSetContainerBase
LevelSetContainerBase
LevelSetEquationContainer
LevelSetEquationContainer
LevelSetEquationTermContainer
LevelSetEquationTermContainer
OneWayEquivalencyTable
WatershedSegmentTable
WatershedSegmentTable
WatershedSegmentTree
WatershedSegmentTree



________________________________
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<mailto:Community at itk.org>
http://public.kitware.com/mailman/listinfo/community

_______________________________________________
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: <http://public.kitware.com/pipermail/insight-developers/attachments/20140718/a6d71885/attachment-0001.html>

From matt.mccormick at kitware.com  Mon Jul 21 23:58:32 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Mon, 21 Jul 2014 23:58:32 -0400
Subject: [ITK-dev] 4.6.0 release candidate freeze over
Message-ID: <CALzTN-SCgi9BKbLdVRo1V8OKrWiX0xKy5fA+KMRGKGDzf+4dRg@mail.gmail.com>

Hi,

ITK v4.6.0 has been tagged! I am still working on the supporting
materials from the other repositories.

Please merge to master while keeping our shiny green dashboard [1] clean!

Thanks,
Matt

[1] http://open.cdash.org/index.php?project=Insight

From norman-k-williams at uiowa.edu  Wed Jul 23 11:23:50 2014
From: norman-k-williams at uiowa.edu (Williams, Norman K)
Date: Wed, 23 Jul 2014 15:23:50 +0000
Subject: [ITK-dev] Undefined IOFactoryRegister__Private methods?
Message-ID: <CFF53DB3.9AF1%norman-k-williams@uiowa.edu>

We have a bunch of big Cmake build systems that until very recently (I noticed it yesterday) were working fine. Now we get link errors like this:

  "itk::BMPImageIOFactoryRegister__Private()", referenced from:
      itk::(anonymous namespace)::ImageIOFactoryRegisterRegisterList in libmaxcurvatureLib.a(maxcurvature.cxx.o)
  "itk::GE4ImageIOFactoryRegister__Private()", referenced from:
      itk::(anonymous namespace)::ImageIOFactoryRegisterRegisterList in libmaxcurvatureLib.a(maxcurvature.cxx.o)

When I  go looking for these symbols,  I see them where you?d expect them ? libITKBMPIO-4.6.a etc.

The problem seems to be that the IO libraries are being LEFT OUT of the ITK_LIBRARIES Cmake variable.

We use a pretty recent version of ITK:
commit 06d5bfec67805bfadb5dc344b08ab554381592c6
Merge: b960bce c1bcfb7
Author: Matt McCormick <matt.mccormick at kitware.com>
Date:   Tue Jul 15 16:05:22 2014 -0400
o
    Merge topic 'FixThresholdMaxCCWarning'

    c1bcfb73 COMP: Fix implicit conversion warnings



________________________________
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: <http://public.kitware.com/pipermail/insight-developers/attachments/20140723/bcc2850a/attachment.html>

From blowekamp at mail.nih.gov  Wed Jul 23 11:28:12 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Wed, 23 Jul 2014 11:28:12 -0400
Subject: [ITK-dev] Undefined IOFactoryRegister__Private methods?
In-Reply-To: <CFF53DB3.9AF1%norman-k-williams@uiowa.edu>
References: <CFF53DB3.9AF1%norman-k-williams@uiowa.edu>
Message-ID: <8A284992-A0BD-42FA-A2FA-F9CDCB5C60FC@mail.nih.gov>

How are you "finding" and "using" ITK in the CMake code? Are you using ITK via components?

Brad

On Jul 23, 2014, at 11:23 AM, Williams, Norman K <norman-k-williams at uiowa.edu> wrote:

> We have a bunch of big Cmake build systems that until very recently (I noticed it yesterday) were working fine. Now we get link errors like this:
> 
>   "itk::BMPImageIOFactoryRegister__Private()", referenced from:
>       itk::(anonymous namespace)::ImageIOFactoryRegisterRegisterList in libmaxcurvatureLib.a(maxcurvature.cxx.o)
>   "itk::GE4ImageIOFactoryRegister__Private()", referenced from:
>       itk::(anonymous namespace)::ImageIOFactoryRegisterRegisterList in libmaxcurvatureLib.a(maxcurvature.cxx.o)
> 
> When I  go looking for these symbols,  I see them where you?d expect them ? libITKBMPIO-4.6.a etc.
> 
> The problem seems to be that the IO libraries are being LEFT OUT of the ITK_LIBRARIES Cmake variable.
> 
> We use a pretty recent version of ITK:
> commit 06d5bfec67805bfadb5dc344b08ab554381592c6
> Merge: b960bce c1bcfb7
> Author: Matt McCormick <matt.mccormick at kitware.com>
> Date:   Tue Jul 15 16:05:22 2014 -0400
> o
>     Merge topic 'FixThresholdMaxCCWarning'
>     
>     c1bcfb73 COMP: Fix implicit conversion warnings
>  
> 
> 
> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20140723/a2800e1e/attachment.html>

From norman-k-williams at uiowa.edu  Wed Jul 23 11:42:33 2014
From: norman-k-williams at uiowa.edu (Williams, Norman K)
Date: Wed, 23 Jul 2014 15:42:33 +0000
Subject: [ITK-dev] Undefined IOFactoryRegister__Private methods?
In-Reply-To: <8A284992-A0BD-42FA-A2FA-F9CDCB5C60FC@mail.nih.gov>
References: <CFF53DB3.9AF1%norman-k-williams@uiowa.edu>
 <8A284992-A0BD-42FA-A2FA-F9CDCB5C60FC@mail.nih.gov>
Message-ID: <CFF540A9.9AF6%norman-k-williams@uiowa.edu>

The ?usual way?

I?m trying to track down where this goes wrong; I wondered if anyone else
had run into this problem. It?s with a package that might need some TLC
with its Cmake build system. http://www.nitrc.org/projects/dtiprocess/

find_package(ITK REQUIRED)
include(${ITK_USE_FILE})


From:  Bradley Lowekamp <blowekamp at mail.nih.gov>
Date:  Wednesday, July 23, 2014 at 10:28 AM
To:  Mushly McMushmaster <norman-k-williams at uiowa.edu>
Cc:  Insight <insight-users at itk.org>, ITK <insight-developers at itk.org>
Subject:  Re: [ITK-dev] Undefined IOFactoryRegister__Private methods?


How are you "finding" and "using" ITK in the CMake code? Are you using ITK
via components?

Brad

On Jul 23, 2014, at 11:23 AM, Williams, Norman K
<norman-k-williams at uiowa.edu> wrote:


We have a bunch of big Cmake build systems that until very recently (I
noticed it yesterday) were working fine. Now we get link errors like this:

  "itk::BMPImageIOFactoryRegister__Private()", referenced from:
      itk::(anonymous namespace)::ImageIOFactoryRegisterRegisterList in
libmaxcurvatureLib.a(maxcurvature.cxx.o)
  "itk::GE4ImageIOFactoryRegister__Private()", referenced from:
      itk::(anonymous namespace)::ImageIOFactoryRegisterRegisterList in
libmaxcurvatureLib.a(maxcurvature.cxx.o)


When I  go looking for these symbols,  I see them where you?d expect them
? libITKBMPIO-4.6.a etc.

The problem seems to be that the IO libraries are being LEFT OUT of the
ITK_LIBRARIES Cmake variable.

We use a pretty recent version of ITK:
commit 06d5bfec67805bfadb5dc344b08ab554381592c6
Merge: b960bce c1bcfb7
Author: Matt McCormick <matt.mccormick at kitware.com>
Date:   Tue Jul 15 16:05:22 2014 -0400
o
    Merge topic 'FixThresholdMaxCCWarning'

    c1bcfb73 COMP: Fix implicit conversion warnings



________________________________________
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 <http://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.
________________________________

From norman-k-williams at uiowa.edu  Wed Jul 23 14:39:18 2014
From: norman-k-williams at uiowa.edu (Williams, Norman K)
Date: Wed, 23 Jul 2014 18:39:18 +0000
Subject: [ITK-dev] Undefined IOFactoryRegister__Private methods?
In-Reply-To: <8A284992-A0BD-42FA-A2FA-F9CDCB5C60FC@mail.nih.gov>
References: <CFF53DB3.9AF1%norman-k-williams@uiowa.edu>
 <8A284992-A0BD-42FA-A2FA-F9CDCB5C60FC@mail.nih.gov>
Message-ID: <CFF56B6C.9B6C%norman-k-williams@uiowa.edu>

This is an issue with recent changes to SlicerExecutionModel, and JC is on the job ;-)

From: Bradley Lowekamp <blowekamp at mail.nih.gov<mailto:blowekamp at mail.nih.gov>>
Date: Wednesday, July 23, 2014 at 10:28 AM
To: Mushly McMushmaster <norman-k-williams at uiowa.edu<mailto:norman-k-williams at uiowa.edu>>
Cc: Insight <insight-users at itk.org<mailto:insight-users at itk.org>>, ITK <insight-developers at itk.org<mailto:insight-developers at itk.org>>
Subject: Re: [ITK-dev] Undefined IOFactoryRegister__Private methods?

How are you "finding" and "using" ITK in the CMake code? Are you using ITK via components?

Brad

On Jul 23, 2014, at 11:23 AM, Williams, Norman K <norman-k-williams at uiowa.edu<mailto:norman-k-williams at uiowa.edu>> wrote:

We have a bunch of big Cmake build systems that until very recently (I noticed it yesterday) were working fine. Now we get link errors like this:

  "itk::BMPImageIOFactoryRegister__Private()", referenced from:
      itk::(anonymous namespace)::ImageIOFactoryRegisterRegisterList in libmaxcurvatureLib.a(maxcurvature.cxx.o)
  "itk::GE4ImageIOFactoryRegister__Private()", referenced from:
      itk::(anonymous namespace)::ImageIOFactoryRegisterRegisterList in libmaxcurvatureLib.a(maxcurvature.cxx.o)

When I  go looking for these symbols,  I see them where you?d expect them ? libITKBMPIO-4.6.a etc.

The problem seems to be that the IO libraries are being LEFT OUT of the ITK_LIBRARIES Cmake variable.

We use a pretty recent version of ITK:
commit 06d5bfec67805bfadb5dc344b08ab554381592c6
Merge: b960bce c1bcfb7
Author: Matt McCormick <matt.mccormick at kitware.com<mailto:matt.mccormick at kitware.com>>
Date:   Tue Jul 15 16:05:22 2014 -0400
o
    Merge topic 'FixThresholdMaxCCWarning'

    c1bcfb73 COMP: Fix implicit conversion warnings



________________________________
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<http://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: <http://public.kitware.com/pipermail/insight-developers/attachments/20140723/ef275acf/attachment.html>

From blowekamp at mail.nih.gov  Thu Jul 24 10:27:35 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Thu, 24 Jul 2014 10:27:35 -0400
Subject: [ITK-dev] Optimizing composite transforms and center of transform
Message-ID: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>

Hello,

There are a lot of transforms involved in the new registration framework.

I am trying to figure out what the implications for the fix parameters of the transform "Center" ( ie center of rotation/scaling ) are when combined with composite transforms and the fixed/moving/registration coordinate frames...

Based on how the transforms are composed it seems necessary to set the  fix "Center" for subsequent transformations. Additionally, I am unsure how one would "improve" ( poorly defined? ) the center for a subsequent transform ie Affine after a similarity...

Are there some documented guidance or figures to help with this issue?
Do we have a comprehensive diagram of these transforms?

Thanks,
Brad


From blowekamp at mail.nih.gov  Thu Jul 24 11:06:23 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Thu, 24 Jul 2014 11:06:23 -0400
Subject: [ITK-dev] ScaleTransform missing fixed Center
Message-ID: <1B1364C8-932A-414A-B433-E4CEDC6BD1AC@mail.nih.gov>

Hello,

I am wrapping itk::ScaleTransform for SimpleITK and I believe I encountered a bug.

This class has a "Center" of scaling, yet reports no fixed parameters. Additionally, this "Center" is not serializes to files.

The transformation of points behaves as expected with a "Center" of scaling, therefor I think there is an error with the fixed parameters.

Additionally these itk::MatrixOffsetTransformBase::GetCenter and SetCenter are not virtual.






From fdrakopo at gmail.com  Fri Jul 25 15:32:25 2014
From: fdrakopo at gmail.com (Fotis Drakopoulos)
Date: Fri, 25 Jul 2014 15:32:25 -0400
Subject: [ITK-dev] Problems with the integration of LASPack package into ITK
Message-ID: <CAG6AjRNfc-phtvD0coYnFonXEAKTObtYHAaTmb6-AyNe80MFhA@mail.gmail.com>

Hi ITK developers,

I am working on the integration of the LASPack package (
http://www.netlib.org/linalg/) inside the ITK for solving for solving large
sparse systems of linear equations with iterative methods.
I created a new folder with name laspack under the directory :
Modules/ThirdParty/VNL/src/vxl/v3p/netlib/ with the following CMakeList.txt
:

*PROJECT( laspack )*

*# List sources for each library component.*
*SET(V3P_NETLIB_laspack_SOURCES*
*    eigenval.c*
*    errhandl.c*
*    factor.c*
*    itersolv.c*
*    matrix.c*
*    mlsolv.c*
*    operats.c*
*    precond.c*
*    qmatrix.c*
*    rtc.c*
*    vector.c*
*    eigenval.h*
*    elcmp.h*
*    errhandl.h*
*    factor.h*
*    itersolv.h*
*    lastypes.h*
*    matrix.h*
*    mlsolv.h*
*    operats.h*
*    precond.h*
*    qmatrix.h*
*    rtc.h*
*    vector.h*
*    version.h*
*    copyrght.h*
*    xc/getopts.c*
*    xc/xstring.c*
*    xc/getopts.h*
*    xc/version.h*
*    xc/xstring.h*
*    xc/xtypes.h*
*  )*

*# Create a library .*
*ADD_LIBRARY(itkv3p_laspack ${V3P_NETLIB_laspack_SOURCES})*
*IF(UNIX)*
*  TARGET_LINK_LIBRARIES( itkv3p_laspack m )*
*ENDIF(UNIX)*
*IF(ITK_LIBRARY_PROPERTIES)*
*  SET_TARGET_PROPERTIES(itkv3p_laspack PROPERTIES
${ITK_LIBRARY_PROPERTIES})*
*ENDIF(ITK_LIBRARY_PROPERTIES)*

*IF(NOT VXL_INSTALL_NO_LIBRARIES)*
*  INSTALL(TARGETS itkv3p_laspack*
*    EXPORT ${VXL_INSTALL_EXPORT_NAME}*
*    RUNTIME DESTINATION ${VXL_INSTALL_RUNTIME_DIR} COMPONENT
RuntimeLibraries*
*    LIBRARY DESTINATION ${VXL_INSTALL_LIBRARY_DIR} COMPONENT
RuntimeLibraries*
*    ARCHIVE DESTINATION ${VXL_INSTALL_ARCHIVE_DIR} COMPONENT Development)*
*ENDIF(NOT VXL_INSTALL_NO_LIBRARIES)*
*IF(NOT VXL_INSTALL_NO_DEVELOPMENT)*
*  INSTALL_NOBASE_HEADER_FILES(${VXL_INSTALL_INCLUDE_DIR}
${V3P_NETLIB_laspack_SOURCES})*
*ENDIF(NOT VXL_INSTALL_NO_DEVELOPMENT)*

Also in the CMakeLists.txt located in direcory : Modules/ThirdParty/VNL/src
I added the new *itkv3p_laspack* library as follows:

*add_subdirectory(vxl)*
*foreach(lib itkvcl itkv3p_netlib itkv3p_lsqr itkv3p_laspack itktestlib
itkvnl itkvnl_algo)*
*  itk_module_target(${lib} NO_INSTALL)*
*endforeach()*

When I build ITK I do not get any errors and the *libitkv3p_laspack. a*  is
normally created like all the other ITK libraries.
However when I compile an external project which links to ITK with
TARGET_LINK_LIBRARIES(PROJECT_NAME ${ITK_LIBRARIES}),   I am getting the
following link error:

*/home/fdrakopo/local/bin/ITKDev/release/lib/libitkvnl_algo-4.1.a(vnl_sparse_iterative_solver.cxx.o):
In function
`vnl_sparse_iterative_solver::vnl_sparse_iterative_solver(vnl_sparse_matrix<double>
const&)':*
*vnl_sparse_iterative_solver.cxx:(.text+0x6a): undefined reference to
`Q_SetName(QMatrixType*, char*)'*
*collect2: error: ld returned 1 exit status*
*make[2]: *** [PAPBNRR] Error 1*
*make[1]: *** [CMakeFiles/PAPBNRR.dir/all] Error 2*
*make: *** [all] Error 2*

The vnl_sparse_iterative_solver is a new class I created under :
Modules/ThirdParty/VNL/src/vxl/core/vnl/algo
and encapsulates the implemented calls (functions, etc.) to the LASPack
package (similarly to vnl_sparse_lu class that calls Kenneth's Kundert
SPARSE package).
Also the itkvnl_algo inks to itkv3p_laspack :
*TARGET_LINK_LIBRARIES( itkvnl_algo ${NETLIB_LIBRARIES} itkvnl itkv3p_lsqr
itkv3p_laspack ) *

Any ideas how can I solve the above link error?

Regards,
Fotis Drakopoulos
CRTC lab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140725/43b46566/attachment.html>

From blowekamp at mail.nih.gov  Fri Jul 25 15:44:51 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Fri, 25 Jul 2014 15:44:51 -0400
Subject: [ITK-dev] Problems with the integration of LASPack package into
	ITK
In-Reply-To: <CAG6AjRNfc-phtvD0coYnFonXEAKTObtYHAaTmb6-AyNe80MFhA@mail.gmail.com>
References: <CAG6AjRNfc-phtvD0coYnFonXEAKTObtYHAaTmb6-AyNe80MFhA@mail.gmail.com>
Message-ID: <BB0E3B5E-49C4-4560-827F-87182513A4A5@mail.nih.gov>

Hello,

I am not certain but I just was looking around at a few things and found some work related to ITKv4 Numerics Refactors[1] here on github that's a bit out dated:
https://github.com/chuckatkins/ITK/commits/numlibs_refactor

Looks like similar work and my first search reveals this may be of use:
https://github.com/chuckatkins/ITK/commit/2c773edc695cbe7b907bebf356ee14e0af66b01a

Brad

[1] http://www.itk.org/Wiki/ITK_Release_4/Refactor_Numerical_Libraries

On Jul 25, 2014, at 3:32 PM, Fotis Drakopoulos <fdrakopo at gmail.com> wrote:

> Hi ITK developers,
> 
> I am working on the integration of the LASPack package (http://www.netlib.org/linalg/) inside the ITK for solving for solving large sparse systems of linear equations with iterative methods.
> I created a new folder with name laspack under the directory : Modules/ThirdParty/VNL/src/vxl/v3p/netlib/ with the following CMakeList.txt :
> 
> PROJECT( laspack )
> 
> # List sources for each library component.
> SET(V3P_NETLIB_laspack_SOURCES
>     eigenval.c
>     errhandl.c
>     factor.c
>     itersolv.c
>     matrix.c
>     mlsolv.c
>     operats.c
>     precond.c
>     qmatrix.c
>     rtc.c
>     vector.c
>     eigenval.h
>     elcmp.h
>     errhandl.h
>     factor.h
>     itersolv.h
>     lastypes.h
>     matrix.h
>     mlsolv.h
>     operats.h
>     precond.h
>     qmatrix.h
>     rtc.h
>     vector.h
>     version.h
>     copyrght.h
>     xc/getopts.c
>     xc/xstring.c
>     xc/getopts.h
>     xc/version.h
>     xc/xstring.h
>     xc/xtypes.h
>   )
> 
> # Create a library .
> ADD_LIBRARY(itkv3p_laspack ${V3P_NETLIB_laspack_SOURCES})
> IF(UNIX)
>   TARGET_LINK_LIBRARIES( itkv3p_laspack m )
> ENDIF(UNIX)
> IF(ITK_LIBRARY_PROPERTIES)
>   SET_TARGET_PROPERTIES(itkv3p_laspack PROPERTIES ${ITK_LIBRARY_PROPERTIES})
> ENDIF(ITK_LIBRARY_PROPERTIES)
> 
> IF(NOT VXL_INSTALL_NO_LIBRARIES)
>   INSTALL(TARGETS itkv3p_laspack
>     EXPORT ${VXL_INSTALL_EXPORT_NAME}
>     RUNTIME DESTINATION ${VXL_INSTALL_RUNTIME_DIR} COMPONENT RuntimeLibraries
>     LIBRARY DESTINATION ${VXL_INSTALL_LIBRARY_DIR} COMPONENT RuntimeLibraries
>     ARCHIVE DESTINATION ${VXL_INSTALL_ARCHIVE_DIR} COMPONENT Development)
> ENDIF(NOT VXL_INSTALL_NO_LIBRARIES)
> IF(NOT VXL_INSTALL_NO_DEVELOPMENT)
>   INSTALL_NOBASE_HEADER_FILES(${VXL_INSTALL_INCLUDE_DIR} ${V3P_NETLIB_laspack_SOURCES})
> ENDIF(NOT VXL_INSTALL_NO_DEVELOPMENT)
> 
> Also in the CMakeLists.txt located in direcory : Modules/ThirdParty/VNL/src I added the new itkv3p_laspack library as follows: 
> 
> add_subdirectory(vxl)
> foreach(lib itkvcl itkv3p_netlib itkv3p_lsqr itkv3p_laspack itktestlib itkvnl itkvnl_algo)
>   itk_module_target(${lib} NO_INSTALL)
> endforeach()
> 
> When I build ITK I do not get any errors and the libitkv3p_laspack. a  is normally created like all the other ITK libraries.
> However when I compile an external project which links to ITK with TARGET_LINK_LIBRARIES(PROJECT_NAME ${ITK_LIBRARIES}),   I am getting the following link error:
> 
> /home/fdrakopo/local/bin/ITKDev/release/lib/libitkvnl_algo-4.1.a(vnl_sparse_iterative_solver.cxx.o): In function `vnl_sparse_iterative_solver::vnl_sparse_iterative_solver(vnl_sparse_matrix<double> const&)':
> vnl_sparse_iterative_solver.cxx:(.text+0x6a): undefined reference to `Q_SetName(QMatrixType*, char*)'
> collect2: error: ld returned 1 exit status
> make[2]: *** [PAPBNRR] Error 1
> make[1]: *** [CMakeFiles/PAPBNRR.dir/all] Error 2
> make: *** [all] Error 2
>  
> The vnl_sparse_iterative_solver is a new class I created under : Modules/ThirdParty/VNL/src/vxl/core/vnl/algo 
> and encapsulates the implemented calls (functions, etc.) to the LASPack package (similarly to vnl_sparse_lu class that calls Kenneth's Kundert SPARSE package).
> Also the itkvnl_algo inks to itkv3p_laspack :
> TARGET_LINK_LIBRARIES( itkvnl_algo ${NETLIB_LIBRARIES} itkvnl itkv3p_lsqr itkv3p_laspack ) 
> 
> Any ideas how can I solve the above link error?
> 
> Regards,
> Fotis Drakopoulos
> CRTC lab
> 
> _______________________________________________
> 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: <http://public.kitware.com/pipermail/insight-developers/attachments/20140725/b1b7fad5/attachment.html>

From fdrakopo at gmail.com  Sat Jul 26 13:15:02 2014
From: fdrakopo at gmail.com (Fotis Drakopoulos)
Date: Sat, 26 Jul 2014 13:15:02 -0400
Subject: [ITK-dev] Problems with the integration of LASPack package into
	ITK
In-Reply-To: <BB0E3B5E-49C4-4560-827F-87182513A4A5@mail.nih.gov>
References: <CAG6AjRNfc-phtvD0coYnFonXEAKTObtYHAaTmb6-AyNe80MFhA@mail.gmail.com>
 <BB0E3B5E-49C4-4560-827F-87182513A4A5@mail.nih.gov>
Message-ID: <CAG6AjRNcCeQpR_jwUmBysvnbCxCcpzmxsZ8c6uKYnU1eLs3t-A@mail.gmail.com>

Hi Brad,
I made the appropriate changes to all CMakeLists.txt files according to [1]
but I still get the same error when I link the external project to ITK
libraries.
I also tried NOT to create a separate *libitkv3p_laspack *but to include
laspack into the *itkv3p_netlib*  (like the SPARSE package) and I still get
the same link error.
After spending several days on the LASPack integration I am not sure why I
get this link error...

[1]
https://github.com/chuckatkins/ITK/commit/2c773edc695cbe7b907bebf356ee14e0af66b01a

Best,
Fotis


On Fri, Jul 25, 2014 at 3:44 PM, Bradley Lowekamp <blowekamp at mail.nih.gov>
wrote:

> Hello,
>
> I am not certain but I just was looking around at a few things and found
> some work related to ITKv4 Numerics Refactors[1] here on github that's a
> bit out dated:
> https://github.com/chuckatkins/ITK/commits/numlibs_refactor
>
> Looks like similar work and my first search reveals this may be of use:
>
> https://github.com/chuckatkins/ITK/commit/2c773edc695cbe7b907bebf356ee14e0af66b01a
>
> Brad
>
> [1] http://www.itk.org/Wiki/ITK_Release_4/Refactor_Numerical_Libraries
>
> On Jul 25, 2014, at 3:32 PM, Fotis Drakopoulos <fdrakopo at gmail.com> wrote:
>
> Hi ITK developers,
>
> I am working on the integration of the LASPack package (
> http://www.netlib.org/linalg/) inside the ITK for solving for solving
> large sparse systems of linear equations with iterative methods.
> I created a new folder with name laspack under the directory :
> Modules/ThirdParty/VNL/src/vxl/v3p/netlib/ with the following CMakeList.txt
> :
>
> *PROJECT( laspack )*
>
>  *# List sources for each library component.*
> *SET(V3P_NETLIB_laspack_SOURCES*
> *    eigenval.c*
> *    errhandl.c*
> *    factor.c*
> *    itersolv.c*
> *    matrix.c*
> *    mlsolv.c*
> *    operats.c*
> *    precond.c*
> *    qmatrix.c*
> *    rtc.c*
> *    vector.c*
> *    eigenval.h*
> *    elcmp.h*
> *    errhandl.h*
> *    factor.h*
> *    itersolv.h*
> *    lastypes.h*
> *    matrix.h*
> *    mlsolv.h*
> *    operats.h*
> *    precond.h*
> *    qmatrix.h*
> *    rtc.h*
> *    vector.h*
> *    version.h*
> *    copyrght.h*
> *    xc/getopts.c*
> *    xc/xstring.c*
> *    xc/getopts.h*
> *    xc/version.h*
> *    xc/xstring.h*
> *    xc/xtypes.h*
> *  )*
>
> *# Create a library .*
> *ADD_LIBRARY(itkv3p_laspack ${V3P_NETLIB_laspack_SOURCES})*
> *IF(UNIX)*
> *  TARGET_LINK_LIBRARIES( itkv3p_laspack m )*
> *ENDIF(UNIX)*
> *IF(ITK_LIBRARY_PROPERTIES)*
> *  SET_TARGET_PROPERTIES(itkv3p_laspack PROPERTIES
> ${ITK_LIBRARY_PROPERTIES})*
> *ENDIF(ITK_LIBRARY_PROPERTIES)*
>
> *IF(NOT VXL_INSTALL_NO_LIBRARIES)*
> *  INSTALL(TARGETS itkv3p_laspack*
> *    EXPORT ${VXL_INSTALL_EXPORT_NAME}*
> *    RUNTIME DESTINATION ${VXL_INSTALL_RUNTIME_DIR} COMPONENT
> RuntimeLibraries*
> *    LIBRARY DESTINATION ${VXL_INSTALL_LIBRARY_DIR} COMPONENT
> RuntimeLibraries*
> *    ARCHIVE DESTINATION ${VXL_INSTALL_ARCHIVE_DIR} COMPONENT Development)*
> *ENDIF(NOT VXL_INSTALL_NO_LIBRARIES)*
> *IF(NOT VXL_INSTALL_NO_DEVELOPMENT)*
> *  INSTALL_NOBASE_HEADER_FILES(${VXL_INSTALL_INCLUDE_DIR}
> ${V3P_NETLIB_laspack_SOURCES})*
> *ENDIF(NOT VXL_INSTALL_NO_DEVELOPMENT)*
>
> Also in the CMakeLists.txt located in direcory :
> Modules/ThirdParty/VNL/src I added the new *itkv3p_laspack* library as
> follows:
>
> *add_subdirectory(vxl)*
> *foreach(lib itkvcl itkv3p_netlib itkv3p_lsqr itkv3p_laspack itktestlib
> itkvnl itkvnl_algo)*
> *  itk_module_target(${lib} NO_INSTALL)*
> *endforeach()*
>
> When I build ITK I do not get any errors and the *libitkv3p_laspack. a*
> is normally created like all the other ITK libraries.
> However when I compile an external project which links to ITK with
> TARGET_LINK_LIBRARIES(PROJECT_NAME ${ITK_LIBRARIES}),   I am getting the
> following link error:
>
> */home/fdrakopo/local/bin/ITKDev/release/lib/libitkvnl_algo-4.1.a(vnl_sparse_iterative_solver.cxx.o):
> In function
> `vnl_sparse_iterative_solver::vnl_sparse_iterative_solver(vnl_sparse_matrix<double>
> const&)':*
> *vnl_sparse_iterative_solver.cxx:(.text+0x6a): undefined reference to
> `Q_SetName(QMatrixType*, char*)'*
> *collect2: error: ld returned 1 exit status*
> *make[2]: *** [PAPBNRR] Error 1*
> *make[1]: *** [CMakeFiles/PAPBNRR.dir/all] Error 2*
> *make: *** [all] Error 2*
>
> The vnl_sparse_iterative_solver is a new class I created under :
> Modules/ThirdParty/VNL/src/vxl/core/vnl/algo
> and encapsulates the implemented calls (functions, etc.) to the LASPack
> package (similarly to vnl_sparse_lu class that calls Kenneth's Kundert
> SPARSE package).
> Also the itkvnl_algo inks to itkv3p_laspack :
> *TARGET_LINK_LIBRARIES( itkvnl_algo ${NETLIB_LIBRARIES} itkvnl itkv3p_lsqr
> itkv3p_laspack ) *
>
> Any ideas how can I solve the above link error?
>
> Regards,
> Fotis Drakopoulos
> CRTC lab
>
> _______________________________________________
> 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
>
>
>  ------------------------------
>
> Spam
> <https://www.spamtrap.odu.edu/canit/b.php?i=02MuHJuoo&m=974aceda4769&t=20140725&c=s>
> Not spam
> <https://www.spamtrap.odu.edu/canit/b.php?i=02MuHJuoo&m=974aceda4769&t=20140725&c=n>
> Forget previous vote
> <https://www.spamtrap.odu.edu/canit/b.php?i=02MuHJuoo&m=974aceda4769&t=20140725&c=f>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140726/383c5ce1/attachment.html>

From ntustison at gmail.com  Mon Jul 28 20:57:24 2014
From: ntustison at gmail.com (Nicholas Tustison)
Date: Mon, 28 Jul 2014 17:57:24 -0700
Subject: [ITK-dev] Optimizing composite transforms and center of
	transform
In-Reply-To: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
Message-ID: <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>

Hi Brad,

I apologize for the delayed response.  I?m still catching up on my 
workload after moving to CA.  We might want to talk to Luis as it 
was my understanding that the ?center? component of the linear 
transforms might be a carry-over from all the ?Centered? transforms, 
e.g., 

http://www.itk.org/Doxygen/html/classitk_1_1CenteredAffineTransform.html

which, if I remember correctly, Luis said were somewhat sub optimally 
conceived but this was such a long time ago that I might be completely
misremembering.  However, fixing the center for all transforms within 
a composite transform is certainly not necessary within the specified
framework.  Rather, the matrix and offset are updated with the ?Center?
being updated implicitly.

Nick



On Jul 24, 2014, at 7:27 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:

> Hello,
> 
> There are a lot of transforms involved in the new registration framework.
> 
> I am trying to figure out what the implications for the fix parameters of the transform "Center" ( ie center of rotation/scaling ) are when combined with composite transforms and the fixed/moving/registration coordinate frames...
> 
> Based on how the transforms are composed it seems necessary to set the  fix "Center" for subsequent transformations. Additionally, I am unsure how one would "improve" ( poorly defined? ) the center for a subsequent transform ie Affine after a similarity...
> 
> Are there some documented guidance or figures to help with this issue?
> Do we have a comprehensive diagram of these transforms?
> 
> Thanks,
> Brad
> 


From blowekamp at mail.nih.gov  Mon Jul 28 22:11:12 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Mon, 28 Jul 2014 22:11:12 -0400
Subject: [ITK-dev] Optimizing composite transforms and center of
	transform
In-Reply-To: <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
Message-ID: <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>

Helloo Nick!

I am glad you got back to me.

I suspect that I have spent more time this past week looking at the ITK affine transforms than anyone else[1] this week. With that here is my current understanding...

1) The CenterTransformInitializers estimates an initial "Center" and an initial "Translation" parameter from either the geometry or the first moments. From my problematic experiences, getting the initial transform which is a "good" guess is been critical for the optimizer to head to the correct solution.

2) The Center parameter of a transform can either be "Fixed" or an optimizable parameter. The transforms with the "Centered" monkier are the the ones with the Center parameter optimizable. This issue seems to be what you were referring to in to message.

In many ways the point I am trying to make is independent of #2. I have observed that it's important to have the "Center" of an affine transform ( or sub parameterization thereof ) at the center of the object you are trying to register. That is the coordinate space of the optimizable parameters' point 0 is near the center. This enables rotation to easily rotate around the center, as well as scaling to maintain the same relative center when "zooming". This issue is independent of wether that center point can be optimized.

For example, consider changing the origin of an image for alignment by say 500, and compensating with just an initial translation and not setting the "Center" parameter. If we are trying to optimize rotation and translation, then the optimization path would be very difficult to traverse with these inter-dependent parameters to force it to rotate around the center of the object. This scenario may be more common in microscopy then medical imaging, due to microscopy frequently having multiple subjects across large images. I could write up a IPython Notebook to illustrate the case.

So that is my understanding of why using a fixed center is important. I thought this may have been shared knowledge, but perhaps is not or is incorrect...

Now I am trying to understand how this interacts with all the coordinate frames involved with the ITKv4 registration framework, and the composite transforms. Specifically the composite transform apply the transforms in "reverse order"[2]. As I understand that that means that the newest transform get applied first. So that transform parameters are being optimized in the images space not in the virtual domains we are working towards. Therefore the center of our transforms is still important as we composite transforms?

I hope I explained that clearly, a white board may really be needed....

Thanks,
Brad


[1] https://github.com/SimpleITK/SimpleITK/compare/master...9bc9bc8440e64d94099d3519eb23bcc16c7cf015
[2] http://www.itk.org/Doxygen/html/classitk_1_1CompositeTransform.html

On Jul 28, 2014, at 8:57 PM, Nicholas Tustison <ntustison at gmail.com> wrote:

> Hi Brad,
> 
> I apologize for the delayed response.  I?m still catching up on my 
> workload after moving to CA.  We might want to talk to Luis as it 
> was my understanding that the ?center? component of the linear 
> transforms might be a carry-over from all the ?Centered? transforms, 
> e.g., 
> 
> http://www.itk.org/Doxygen/html/classitk_1_1CenteredAffineTransform.html
> 
> which, if I remember correctly, Luis said were somewhat sub optimally 
> conceived but this was such a long time ago that I might be completely
> misremembering.  However, fixing the center for all transforms within 
> a composite transform is certainly not necessary within the specified
> framework.  Rather, the matrix and offset are updated with the ?Center?
> being updated implicitly.
> 
> Nick
> 
> 
> 
> On Jul 24, 2014, at 7:27 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> 
>> Hello,
>> 
>> There are a lot of transforms involved in the new registration framework.
>> 
>> I am trying to figure out what the implications for the fix parameters of the transform "Center" ( ie center of rotation/scaling ) are when combined with composite transforms and the fixed/moving/registration coordinate frames...
>> 
>> Based on how the transforms are composed it seems necessary to set the  fix "Center" for subsequent transformations. Additionally, I am unsure how one would "improve" ( poorly defined? ) the center for a subsequent transform ie Affine after a similarity...
>> 
>> Are there some documented guidance or figures to help with this issue?
>> Do we have a comprehensive diagram of these transforms?
>> 
>> Thanks,
>> Brad
>> 
> 


From matt.mccormick at kitware.com  Tue Jul 29 17:38:22 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Tue, 29 Jul 2014 17:38:22 -0400
Subject: [ITK-dev] [ITK] Optimizing composite transforms and center of
	transform
In-Reply-To: <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
 <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
Message-ID: <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>

Hi Brad,

Your assessment that the fixed center is important is correct.

In most cases, a transform with a Center is the first transform in a
Composite transform. There not any issues here.  However, if the
transform with a Center is further along the chain, then a
CenteredTransformInitializer that was applied before the registration
is started will not generate the desired result. In this case, we
would have to respond to an Event in the registration process and
estimated the center on the imaged after the other transforms have
been applied. It is more work, but it is a more unusual case.

HTH,
Matt



On Mon, Jul 28, 2014 at 10:11 PM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> Helloo Nick!
>
> I am glad you got back to me.
>
> I suspect that I have spent more time this past week looking at the ITK affine transforms than anyone else[1] this week. With that here is my current understanding...
>
> 1) The CenterTransformInitializers estimates an initial "Center" and an initial "Translation" parameter from either the geometry or the first moments. From my problematic experiences, getting the initial transform which is a "good" guess is been critical for the optimizer to head to the correct solution.
>
> 2) The Center parameter of a transform can either be "Fixed" or an optimizable parameter. The transforms with the "Centered" monkier are the the ones with the Center parameter optimizable. This issue seems to be what you were referring to in to message.
>
> In many ways the point I am trying to make is independent of #2. I have observed that it's important to have the "Center" of an affine transform ( or sub parameterization thereof ) at the center of the object you are trying to register. That is the coordinate space of the optimizable parameters' point 0 is near the center. This enables rotation to easily rotate around the center, as well as scaling to maintain the same relative center when "zooming". This issue is independent of wether that center point can be optimized.
>
> For example, consider changing the origin of an image for alignment by say 500, and compensating with just an initial translation and not setting the "Center" parameter. If we are trying to optimize rotation and translation, then the optimization path would be very difficult to traverse with these inter-dependent parameters to force it to rotate around the center of the object. This scenario may be more common in microscopy then medical imaging, due to microscopy frequently having multiple subjects across large images. I could write up a IPython Notebook to illustrate the case.
>
> So that is my understanding of why using a fixed center is important. I thought this may have been shared knowledge, but perhaps is not or is incorrect...
>
> Now I am trying to understand how this interacts with all the coordinate frames involved with the ITKv4 registration framework, and the composite transforms. Specifically the composite transform apply the transforms in "reverse order"[2]. As I understand that that means that the newest transform get applied first. So that transform parameters are being optimized in the images space not in the virtual domains we are working towards. Therefore the center of our transforms is still important as we composite transforms?
>
> I hope I explained that clearly, a white board may really be needed....
>
> Thanks,
> Brad
>
>
> [1] https://github.com/SimpleITK/SimpleITK/compare/master...9bc9bc8440e64d94099d3519eb23bcc16c7cf015
> [2] http://www.itk.org/Doxygen/html/classitk_1_1CompositeTransform.html
>
> On Jul 28, 2014, at 8:57 PM, Nicholas Tustison <ntustison at gmail.com> wrote:
>
>> Hi Brad,
>>
>> I apologize for the delayed response.  I?m still catching up on my
>> workload after moving to CA.  We might want to talk to Luis as it
>> was my understanding that the ?center? component of the linear
>> transforms might be a carry-over from all the ?Centered? transforms,
>> e.g.,
>>
>> http://www.itk.org/Doxygen/html/classitk_1_1CenteredAffineTransform.html
>>
>> which, if I remember correctly, Luis said were somewhat sub optimally
>> conceived but this was such a long time ago that I might be completely
>> misremembering.  However, fixing the center for all transforms within
>> a composite transform is certainly not necessary within the specified
>> framework.  Rather, the matrix and offset are updated with the ?Center?
>> being updated implicitly.
>>
>> Nick
>>
>>
>>
>> On Jul 24, 2014, at 7:27 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>>
>>> Hello,
>>>
>>> There are a lot of transforms involved in the new registration framework.
>>>
>>> I am trying to figure out what the implications for the fix parameters of the transform "Center" ( ie center of rotation/scaling ) are when combined with composite transforms and the fixed/moving/registration coordinate frames...
>>>
>>> Based on how the transforms are composed it seems necessary to set the  fix "Center" for subsequent transformations. Additionally, I am unsure how one would "improve" ( poorly defined? ) the center for a subsequent transform ie Affine after a similarity...
>>>
>>> Are there some documented guidance or figures to help with this issue?
>>> Do we have a comprehensive diagram of these transforms?
>>>
>>> Thanks,
>>> Brad
>>>
>>
>
> _______________________________________________
> 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 blowekamp at mail.nih.gov  Tue Jul 29 19:16:06 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Tue, 29 Jul 2014 19:16:06 -0400
Subject: [ITK-dev] [ITK] Optimizing composite transforms and center of
	transform
In-Reply-To: <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
 <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
 <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>
Message-ID: <2A37CDEA-B4F3-4826-BAF8-D64D6C4A53F6@mail.nih.gov>

Hello,

Ok, to further explore this problem, and hopeful help other people too: I created an IPython Notebook viewable here:
http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/blob/master/Transform%20Composition%20And%20Order.ipynb

It doesn't come through on the static page, but I added some nifty interactive slider widgets to change the rotation parameter. Which is really the point  to enable understanding of the parameters for the transform and how they should be best optimized. The notebook should work with SimpleITK >= 0.8 and IPython Notebooks 2.1. I'll encourage every one to try it out :) IPython Notebooks widget are very cool!

EXPLANATION:

The the order of the composite transform is that the new transforms are applied first.

BUT they map from the virtual domain ( fixed ) to the moving image. Therefore if your first transform moves the center of mass to the origin then the second added transform's space will be centered on the mass, which is good for optimizing rotation and affine parameters.

QUESTION:

Therefore I am inclined to conclude that its best practices to map the fixed and moving image to the virtual domain such that the center of mass ( or some other "center feature" ) are at the origin. This would then the scale, rotation and other affine parameters around the center, with out having to used the "Center" parameter the transforms currently have.

Is this what others are doing in their registration? For general best practices should this be recommend?

@Brian I know I have seen this multi-domain description many time, but I think I may have just gotten it... Is the well describe in the literature some place? I think this may be an important part add the software guide.

Thanks,
Brad




On Jul 29, 2014, at 5:38 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:

> Hi Brad,
> 
> Your assessment that the fixed center is important is correct.
> 
> In most cases, a transform with a Center is the first transform in a
> Composite transform. There not any issues here.  However, if the
> transform with a Center is further along the chain, then a
> CenteredTransformInitializer that was applied before the registration
> is started will not generate the desired result. In this case, we
> would have to respond to an Event in the registration process and
> estimated the center on the imaged after the other transforms have
> been applied. It is more work, but it is a more unusual case.
> 
> HTH,
> Matt
> 
> 
> 
> On Mon, Jul 28, 2014 at 10:11 PM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>> Helloo Nick!
>> 
>> I am glad you got back to me.
>> 
>> I suspect that I have spent more time this past week looking at the ITK affine transforms than anyone else[1] this week. With that here is my current understanding...
>> 
>> 1) The CenterTransformInitializers estimates an initial "Center" and an initial "Translation" parameter from either the geometry or the first moments. From my problematic experiences, getting the initial transform which is a "good" guess is been critical for the optimizer to head to the correct solution.
>> 
>> 2) The Center parameter of a transform can either be "Fixed" or an optimizable parameter. The transforms with the "Centered" monkier are the the ones with the Center parameter optimizable. This issue seems to be what you were referring to in to message.
>> 
>> In many ways the point I am trying to make is independent of #2. I have observed that it's important to have the "Center" of an affine transform ( or sub parameterization thereof ) at the center of the object you are trying to register. That is the coordinate space of the optimizable parameters' point 0 is near the center. This enables rotation to easily rotate around the center, as well as scaling to maintain the same relative center when "zooming". This issue is independent of wether that center point can be optimized.
>> 
>> For example, consider changing the origin of an image for alignment by say 500, and compensating with just an initial translation and not setting the "Center" parameter. If we are trying to optimize rotation and translation, then the optimization path would be very difficult to traverse with these inter-dependent parameters to force it to rotate around the center of the object. This scenario may be more common in microscopy then medical imaging, due to microscopy frequently having multiple subjects across large images. I could write up a IPython Notebook to illustrate the case.
>> 
>> So that is my understanding of why using a fixed center is important. I thought this may have been shared knowledge, but perhaps is not or is incorrect...
>> 
>> Now I am trying to understand how this interacts with all the coordinate frames involved with the ITKv4 registration framework, and the composite transforms. Specifically the composite transform apply the transforms in "reverse order"[2]. As I understand that that means that the newest transform get applied first. So that transform parameters are being optimized in the images space not in the virtual domains we are working towards. Therefore the center of our transforms is still important as we composite transforms?
>> 
>> I hope I explained that clearly, a white board may really be needed....
>> 
>> Thanks,
>> Brad
>> 
>> 
>> [1] https://github.com/SimpleITK/SimpleITK/compare/master...9bc9bc8440e64d94099d3519eb23bcc16c7cf015
>> [2] http://www.itk.org/Doxygen/html/classitk_1_1CompositeTransform.html
>> 
>> On Jul 28, 2014, at 8:57 PM, Nicholas Tustison <ntustison at gmail.com> wrote:
>> 
>>> Hi Brad,
>>> 
>>> I apologize for the delayed response.  I?m still catching up on my
>>> workload after moving to CA.  We might want to talk to Luis as it
>>> was my understanding that the ?center? component of the linear
>>> transforms might be a carry-over from all the ?Centered? transforms,
>>> e.g.,
>>> 
>>> http://www.itk.org/Doxygen/html/classitk_1_1CenteredAffineTransform.html
>>> 
>>> which, if I remember correctly, Luis said were somewhat sub optimally
>>> conceived but this was such a long time ago that I might be completely
>>> misremembering.  However, fixing the center for all transforms within
>>> a composite transform is certainly not necessary within the specified
>>> framework.  Rather, the matrix and offset are updated with the ?Center?
>>> being updated implicitly.
>>> 
>>> Nick
>>> 
>>> 
>>> 
>>> On Jul 24, 2014, at 7:27 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>>> 
>>>> Hello,
>>>> 
>>>> There are a lot of transforms involved in the new registration framework.
>>>> 
>>>> I am trying to figure out what the implications for the fix parameters of the transform "Center" ( ie center of rotation/scaling ) are when combined with composite transforms and the fixed/moving/registration coordinate frames...
>>>> 
>>>> Based on how the transforms are composed it seems necessary to set the  fix "Center" for subsequent transformations. Additionally, I am unsure how one would "improve" ( poorly defined? ) the center for a subsequent transform ie Affine after a similarity...
>>>> 
>>>> Are there some documented guidance or figures to help with this issue?
>>>> Do we have a comprehensive diagram of these transforms?
>>>> 
>>>> Thanks,
>>>> Brad
>>>> 
>>> 
>> 
>> _______________________________________________
>> 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 ntustison at gmail.com  Tue Jul 29 19:55:16 2014
From: ntustison at gmail.com (Nicholas Tustison)
Date: Tue, 29 Jul 2014 16:55:16 -0700
Subject: [ITK-dev] [ITK] Optimizing composite transforms and center of
	transform
In-Reply-To: <2A37CDEA-B4F3-4826-BAF8-D64D6C4A53F6@mail.nih.gov>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
 <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
 <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>
 <2A37CDEA-B4F3-4826-BAF8-D64D6C4A53F6@mail.nih.gov>
Message-ID: <8C9CCC8B-5379-4A6A-902F-ACAE609F5789@gmail.com>

Sorry, Brad, but I?m having a hard time following what
the problem is exactly.  I agree with you that getting a
good initialization, i.e., centering the objects of interest
to be registered is important.  And that is something 
we do in ANTs by employing the centered transform
initializer or aligning origins by converting the result to
a translation transform.  That translation transform is then
pushed onto the composite transform queue.  

If that is followed up by other transforms to be optimized,
such as rigid or affine, the moving image is already "centered"
in the virtual domain within the similarity metric classes and 
optimization in terms of translation to center the objects is (or 
at least, should be) minimal.

Does that help?

Nick
 




On Jul 29, 2014, at 4:16 PM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:

> Hello,
> 
> Ok, to further explore this problem, and hopeful help other people too: I created an IPython Notebook viewable here:
> http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/blob/master/Transform%20Composition%20And%20Order.ipynb
> 
> It doesn't come through on the static page, but I added some nifty interactive slider widgets to change the rotation parameter. Which is really the point  to enable understanding of the parameters for the transform and how they should be best optimized. The notebook should work with SimpleITK >= 0.8 and IPython Notebooks 2.1. I'll encourage every one to try it out :) IPython Notebooks widget are very cool!
> 
> EXPLANATION:
> 
> The the order of the composite transform is that the new transforms are applied first.
> 
> BUT they map from the virtual domain ( fixed ) to the moving image. Therefore if your first transform moves the center of mass to the origin then the second added transform's space will be centered on the mass, which is good for optimizing rotation and affine parameters.
> 
> QUESTION:
> 
> Therefore I am inclined to conclude that its best practices to map the fixed and moving image to the virtual domain such that the center of mass ( or some other "center feature" ) are at the origin. This would then the scale, rotation and other affine parameters around the center, with out having to used the "Center" parameter the transforms currently have.
> 
> Is this what others are doing in their registration? For general best practices should this be recommend?
> 
> @Brian I know I have seen this multi-domain description many time, but I think I may have just gotten it... Is the well describe in the literature some place? I think this may be an important part add the software guide.
> 
> Thanks,
> Brad
> 
> 
> 
> 
> On Jul 29, 2014, at 5:38 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:
> 
>> Hi Brad,
>> 
>> Your assessment that the fixed center is important is correct.
>> 
>> In most cases, a transform with a Center is the first transform in a
>> Composite transform. There not any issues here.  However, if the
>> transform with a Center is further along the chain, then a
>> CenteredTransformInitializer that was applied before the registration
>> is started will not generate the desired result. In this case, we
>> would have to respond to an Event in the registration process and
>> estimated the center on the imaged after the other transforms have
>> been applied. It is more work, but it is a more unusual case.
>> 
>> HTH,
>> Matt
>> 
>> 
>> 
>> On Mon, Jul 28, 2014 at 10:11 PM, Bradley Lowekamp
>> <blowekamp at mail.nih.gov> wrote:
>>> Helloo Nick!
>>> 
>>> I am glad you got back to me.
>>> 
>>> I suspect that I have spent more time this past week looking at the ITK affine transforms than anyone else[1] this week. With that here is my current understanding...
>>> 
>>> 1) The CenterTransformInitializers estimates an initial "Center" and an initial "Translation" parameter from either the geometry or the first moments. From my problematic experiences, getting the initial transform which is a "good" guess is been critical for the optimizer to head to the correct solution.
>>> 
>>> 2) The Center parameter of a transform can either be "Fixed" or an optimizable parameter. The transforms with the "Centered" monkier are the the ones with the Center parameter optimizable. This issue seems to be what you were referring to in to message.
>>> 
>>> In many ways the point I am trying to make is independent of #2. I have observed that it's important to have the "Center" of an affine transform ( or sub parameterization thereof ) at the center of the object you are trying to register. That is the coordinate space of the optimizable parameters' point 0 is near the center. This enables rotation to easily rotate around the center, as well as scaling to maintain the same relative center when "zooming". This issue is independent of wether that center point can be optimized.
>>> 
>>> For example, consider changing the origin of an image for alignment by say 500, and compensating with just an initial translation and not setting the "Center" parameter. If we are trying to optimize rotation and translation, then the optimization path would be very difficult to traverse with these inter-dependent parameters to force it to rotate around the center of the object. This scenario may be more common in microscopy then medical imaging, due to microscopy frequently having multiple subjects across large images. I could write up a IPython Notebook to illustrate the case.
>>> 
>>> So that is my understanding of why using a fixed center is important. I thought this may have been shared knowledge, but perhaps is not or is incorrect...
>>> 
>>> Now I am trying to understand how this interacts with all the coordinate frames involved with the ITKv4 registration framework, and the composite transforms. Specifically the composite transform apply the transforms in "reverse order"[2]. As I understand that that means that the newest transform get applied first. So that transform parameters are being optimized in the images space not in the virtual domains we are working towards. Therefore the center of our transforms is still important as we composite transforms?
>>> 
>>> I hope I explained that clearly, a white board may really be needed....
>>> 
>>> Thanks,
>>> Brad
>>> 
>>> 
>>> [1] https://github.com/SimpleITK/SimpleITK/compare/master...9bc9bc8440e64d94099d3519eb23bcc16c7cf015
>>> [2] http://www.itk.org/Doxygen/html/classitk_1_1CompositeTransform.html
>>> 
>>> On Jul 28, 2014, at 8:57 PM, Nicholas Tustison <ntustison at gmail.com> wrote:
>>> 
>>>> Hi Brad,
>>>> 
>>>> I apologize for the delayed response.  I?m still catching up on my
>>>> workload after moving to CA.  We might want to talk to Luis as it
>>>> was my understanding that the ?center? component of the linear
>>>> transforms might be a carry-over from all the ?Centered? transforms,
>>>> e.g.,
>>>> 
>>>> http://www.itk.org/Doxygen/html/classitk_1_1CenteredAffineTransform.html
>>>> 
>>>> which, if I remember correctly, Luis said were somewhat sub optimally
>>>> conceived but this was such a long time ago that I might be completely
>>>> misremembering.  However, fixing the center for all transforms within
>>>> a composite transform is certainly not necessary within the specified
>>>> framework.  Rather, the matrix and offset are updated with the ?Center?
>>>> being updated implicitly.
>>>> 
>>>> Nick
>>>> 
>>>> 
>>>> 
>>>> On Jul 24, 2014, at 7:27 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> There are a lot of transforms involved in the new registration framework.
>>>>> 
>>>>> I am trying to figure out what the implications for the fix parameters of the transform "Center" ( ie center of rotation/scaling ) are when combined with composite transforms and the fixed/moving/registration coordinate frames...
>>>>> 
>>>>> Based on how the transforms are composed it seems necessary to set the  fix "Center" for subsequent transformations. Additionally, I am unsure how one would "improve" ( poorly defined? ) the center for a subsequent transform ie Affine after a similarity...
>>>>> 
>>>>> Are there some documented guidance or figures to help with this issue?
>>>>> Do we have a comprehensive diagram of these transforms?
>>>>> 
>>>>> Thanks,
>>>>> Brad
>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> 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 mohammedrashadkm at gmail.com  Tue Jul 29 21:58:30 2014
From: mohammedrashadkm at gmail.com (Rashad M)
Date: Wed, 30 Jul 2014 03:58:30 +0200
Subject: [ITK-dev] mingw64 execvp -fpermissive error from
	KWSys/SharedForward.h
Message-ID: <CANNqv9fc8DokoKHmOkkqz47eucN-eBnLvM=4Pk0xAGa6+fnTFQ@mail.gmail.com>

Hi all,

Building ITK with MinGW64 comes clean but when using it in other library
gives the below error. Turning -fpermissive can solve this bug but its not
a option to be considered.

I had attached a  patch which will resolve this issue.

[ 78%] Building CXX object
Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperApplicationRegistry.cxx.obj
[ 79%] Building CXX object
Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperChoiceParameter.cxx.obj
Linking CXX shared library ../../bin/libOTBTesting.dll
[ 79%] Built target OTBTesting
[ 79%] Building CXX object
Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperInputImageListParameter.cxx.obj
[ 79%] Building CXX object
Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperOutputImageParameter.cxx.obj
Scanning dependencies of target otbTestDriver
[ 79%] Building CXX object
Code/Testing/CMakeFiles/otbTestDriver.dir/otbTestDriver.cxx.obj
In file included from /.../OTB-Nightly/Code/Testing/otbTestDriver.cxx:35:0:
/home/rashad/packages/mxe/usr/x86_64-w64-mingw32.shared/include/ITK-4.6/itksys/SharedForward.h:
In function 'void kwsys_shared_forward_execvp(const char*, const char*
const*)':

/home/rashad/packages/mxe/usr/x86_64-w64-mingw32.shared/include/ITK-4.6/itksys/SharedForward.h:516:19:
error: invalid conversion from 'const char* const*' to 'char* const*'
[-fpermissive]

   execvp(cmd, argv);
                   ^
In file included from
/home/rashad/packages/mxe/usr/x86_64-w64-mingw32.shared/include/ITK-4.6/itksys/SharedForward.h:158:0,
                 from /.../OTB-Nightly/Code/Testing/otbTestDriver.cxx:35:


-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140730/7e22ad70/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itk-3-execvp.patch
Type: text/x-patch
Size: 627 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140730/7e22ad70/attachment.bin>

From blowekamp at mail.nih.gov  Wed Jul 30 08:49:17 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Wed, 30 Jul 2014 08:49:17 -0400
Subject: [ITK-dev] [ITK] mingw64 execvp -fpermissive error
	from	KWSys/SharedForward.h
In-Reply-To: <CANNqv9fc8DokoKHmOkkqz47eucN-eBnLvM=4Pk0xAGa6+fnTFQ@mail.gmail.com>
References: <CANNqv9fc8DokoKHmOkkqz47eucN-eBnLvM=4Pk0xAGa6+fnTFQ@mail.gmail.com>
Message-ID: <8D3BE72F-7A44-410C-AD30-41F9F13F5FA7@mail.nih.gov>

Hello,

Could you please submit your patch to gerrit for review:

http://www.itk.org/Wiki/ITK/Git/Develop

Thanks,
Brad



On Jul 29, 2014, at 9:58 PM, Rashad M <mohammedrashadkm at gmail.com> wrote:

> Hi all,
> 
> Building ITK with MinGW64 comes clean but when using it in other library gives the below error. Turning -fpermissive can solve this bug but its not a option to be considered.
> 
> I had attached a  patch which will resolve this issue. 
> 
> [ 78%] Building CXX object Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperApplicationRegistry.cxx.obj
> [ 79%] Building CXX object Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperChoiceParameter.cxx.obj
> Linking CXX shared library ../../bin/libOTBTesting.dll
> [ 79%] Built target OTBTesting
> [ 79%] Building CXX object Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperInputImageListParameter.cxx.obj
> [ 79%] Building CXX object Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperOutputImageParameter.cxx.obj
> Scanning dependencies of target otbTestDriver
> [ 79%] Building CXX object Code/Testing/CMakeFiles/otbTestDriver.dir/otbTestDriver.cxx.obj
> In file included from /.../OTB-Nightly/Code/Testing/otbTestDriver.cxx:35:0:
> /home/rashad/packages/mxe/usr/x86_64-w64-mingw32.shared/include/ITK-4.6/itksys/SharedForward.h: In function 'void kwsys_shared_forward_execvp(const char*, const char* const*)':
> 
> /home/rashad/packages/mxe/usr/x86_64-w64-mingw32.shared/include/ITK-4.6/itksys/SharedForward.h:516:19: error: invalid conversion from 'const char* const*' to 'char* const*' [-fpermissive]
> 
>    execvp(cmd, argv);
>                    ^
> In file included from /home/rashad/packages/mxe/usr/x86_64-w64-mingw32.shared/include/ITK-4.6/itksys/SharedForward.h:158:0,
>                  from /.../OTB-Nightly/Code/Testing/otbTestDriver.cxx:35:
> 
> 
> -- 
> Regards,
>    Rashad
> <itk-3-execvp.patch>_______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140730/627be59e/attachment.html>

From mohammedrashadkm at gmail.com  Wed Jul 30 08:56:17 2014
From: mohammedrashadkm at gmail.com (Rashad M)
Date: Wed, 30 Jul 2014 14:56:17 +0200
Subject: [ITK-dev] [ITK] mingw64 execvp -fpermissive error from
	KWSys/SharedForward.h
In-Reply-To: <8D3BE72F-7A44-410C-AD30-41F9F13F5FA7@mail.nih.gov>
References: <CANNqv9fc8DokoKHmOkkqz47eucN-eBnLvM=4Pk0xAGa6+fnTFQ@mail.gmail.com>
 <8D3BE72F-7A44-410C-AD30-41F9F13F5FA7@mail.nih.gov>
Message-ID: <CANNqv9dTfvk0LJx00eb1cQbE=HoKTSW3UiY-b8HywxDWe44gYQ@mail.gmail.com>

Hello Brad,

Already in [1]

*(If your change modifies the "Modules/ThirdParty/KWSys/src/KWSys"
directory please contribute directly to KWSys
<http://www.itk.org/Wiki/KWSys/Git>instead.)*

So should continue in itk gerrit or KWSys?. If ITK it should be in release
branch or trunk (4.7). AFAICT, this happens to block build on MingW64 bit
on windows


[1] http://www.itk.org/Wiki/ITK/Git/Develop


On Wed, Jul 30, 2014 at 2:49 PM, Bradley Lowekamp <blowekamp at mail.nih.gov>
wrote:

> Hello,
>
> Could you please submit your patch to gerrit for review:
>
> http://www.itk.org/Wiki/ITK/Git/Develop
>
> Thanks,
> Brad
>
>
>
> On Jul 29, 2014, at 9:58 PM, Rashad M <mohammedrashadkm at gmail.com> wrote:
>
> Hi all,
>
> Building ITK with MinGW64 comes clean but when using it in other library
> gives the below error. Turning -fpermissive can solve this bug but its not
> a option to be considered.
>
> I had attached a  patch which will resolve this issue.
>
> [ 78%] Building CXX object
> Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperApplicationRegistry.cxx.obj
> [ 79%] Building CXX object
> Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperChoiceParameter.cxx.obj
> Linking CXX shared library ../../bin/libOTBTesting.dll
> [ 79%] Built target OTBTesting
> [ 79%] Building CXX object
> Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperInputImageListParameter.cxx.obj
> [ 79%] Building CXX object
> Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperOutputImageParameter.cxx.obj
> Scanning dependencies of target otbTestDriver
> [ 79%] Building CXX object
> Code/Testing/CMakeFiles/otbTestDriver.dir/otbTestDriver.cxx.obj
> In file included from /.../OTB-Nightly/Code/Testing/otbTestDriver.cxx:35:0:
> /home/rashad/packages/mxe/usr/x86_64-w64-mingw32.shared/include/ITK-4.6/itksys/SharedForward.h:
> In function 'void kwsys_shared_forward_execvp(const char*, const char*
> const*)':
>
> /home/rashad/packages/mxe/usr/x86_64-w64-mingw32.shared/include/ITK-4.6/itksys/SharedForward.h:516:19:
> error: invalid conversion from 'const char* const*' to 'char* const*'
> [-fpermissive]
>
>    execvp(cmd, argv);
>                    ^
> In file included from
> /home/rashad/packages/mxe/usr/x86_64-w64-mingw32.shared/include/ITK-4.6/itksys/SharedForward.h:158:0,
>                  from /.../OTB-Nightly/Code/Testing/otbTestDriver.cxx:35:
>
>
> --
> Regards,
>    Rashad
>  <itk-3-execvp.patch>_______________________________________________
> 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
>
>
>


-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140730/b5eef485/attachment.html>

From blowekamp at mail.nih.gov  Wed Jul 30 09:00:06 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Wed, 30 Jul 2014 09:00:06 -0400
Subject: [ITK-dev] [ITK] mingw64 execvp -fpermissive error from
	KWSys/SharedForward.h
In-Reply-To: <CANNqv9dTfvk0LJx00eb1cQbE=HoKTSW3UiY-b8HywxDWe44gYQ@mail.gmail.com>
References: <CANNqv9fc8DokoKHmOkkqz47eucN-eBnLvM=4Pk0xAGa6+fnTFQ@mail.gmail.com>
 <8D3BE72F-7A44-410C-AD30-41F9F13F5FA7@mail.nih.gov>
 <CANNqv9dTfvk0LJx00eb1cQbE=HoKTSW3UiY-b8HywxDWe44gYQ@mail.gmail.com>
Message-ID: <EE7AC762-AD3D-4204-9CCE-0E5148A4A6B7@mail.nih.gov>

Sorry about that. It looks like KWsys aslo uses gerrit, so similar process there:
http://www.itk.org/Wiki/KWSys/Git/Develop

It seems like a good candidate for the release branch. Once merged into KWSys, we'll see if it smoothly merged into ITK's release branch.

Brad

On Jul 30, 2014, at 8:56 AM, Rashad M <mohammedrashadkm at gmail.com> wrote:

> Hello Brad,
> 
> Already in [1]
> 
> (If your change modifies the "Modules/ThirdParty/KWSys/src/KWSys" directory please contribute directly to KWSysinstead.)
> 
> So should continue in itk gerrit or KWSys?. If ITK it should be in release branch or trunk (4.7). AFAICT, this happens to block build on MingW64 bit on windows
> 
> 
> [1] http://www.itk.org/Wiki/ITK/Git/Develop
> 
> 
> On Wed, Jul 30, 2014 at 2:49 PM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> Hello,
> 
> Could you please submit your patch to gerrit for review:
> 
> http://www.itk.org/Wiki/ITK/Git/Develop
> 
> Thanks,
> Brad
> 
> 
> 
> On Jul 29, 2014, at 9:58 PM, Rashad M <mohammedrashadkm at gmail.com> wrote:
> 
>> Hi all,
>> 
>> Building ITK with MinGW64 comes clean but when using it in other library gives the below error. Turning -fpermissive can solve this bug but its not a option to be considered.
>> 
>> I had attached a  patch which will resolve this issue. 
>> 
>> [ 78%] Building CXX object Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperApplicationRegistry.cxx.obj
>> [ 79%] Building CXX object Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperChoiceParameter.cxx.obj
>> Linking CXX shared library ../../bin/libOTBTesting.dll
>> [ 79%] Built target OTBTesting
>> [ 79%] Building CXX object Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperInputImageListParameter.cxx.obj
>> [ 79%] Building CXX object Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperOutputImageParameter.cxx.obj
>> Scanning dependencies of target otbTestDriver
>> [ 79%] Building CXX object Code/Testing/CMakeFiles/otbTestDriver.dir/otbTestDriver.cxx.obj
>> In file included from /.../OTB-Nightly/Code/Testing/otbTestDriver.cxx:35:0:
>> /home/rashad/packages/mxe/usr/x86_64-w64-mingw32.shared/include/ITK-4.6/itksys/SharedForward.h: In function 'void kwsys_shared_forward_execvp(const char*, const char* const*)':
>> 
>> /home/rashad/packages/mxe/usr/x86_64-w64-mingw32.shared/include/ITK-4.6/itksys/SharedForward.h:516:19: error: invalid conversion from 'const char* const*' to 'char* const*' [-fpermissive]
>> 
>>    execvp(cmd, argv);
>>                    ^
>> In file included from /home/rashad/packages/mxe/usr/x86_64-w64-mingw32.shared/include/ITK-4.6/itksys/SharedForward.h:158:0,
>>                  from /.../OTB-Nightly/Code/Testing/otbTestDriver.cxx:35:
>> 
>> 
>> -- 
>> Regards,
>>    Rashad
>> <itk-3-execvp.patch>_______________________________________________
>> 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
> 
> 
> 
> 
> -- 
> Regards,
>    Rashad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140730/776adc25/attachment.html>

From mohammedrashadkm at gmail.com  Wed Jul 30 09:37:13 2014
From: mohammedrashadkm at gmail.com (Rashad M)
Date: Wed, 30 Jul 2014 15:37:13 +0200
Subject: [ITK-dev] [ITK] mingw64 execvp -fpermissive error from
	KWSys/SharedForward.h
In-Reply-To: <EE7AC762-AD3D-4204-9CCE-0E5148A4A6B7@mail.nih.gov>
References: <CANNqv9fc8DokoKHmOkkqz47eucN-eBnLvM=4Pk0xAGa6+fnTFQ@mail.gmail.com>
 <8D3BE72F-7A44-410C-AD30-41F9F13F5FA7@mail.nih.gov>
 <CANNqv9dTfvk0LJx00eb1cQbE=HoKTSW3UiY-b8HywxDWe44gYQ@mail.gmail.com>
 <EE7AC762-AD3D-4204-9CCE-0E5148A4A6B7@mail.nih.gov>
Message-ID: <CANNqv9d2gKG9Fci8Mxf4r6-ZLgs5HFudNR=W8d58AtB9JKfT2g@mail.gmail.com>

Done.

http://review.source.kitware.com/16452


On Wed, Jul 30, 2014 at 3:00 PM, Bradley Lowekamp <blowekamp at mail.nih.gov>
wrote:

> Sorry about that. It looks like KWsys aslo uses gerrit, so similar process
> there:
> http://www.itk.org/Wiki/KWSys/Git/Develop
>
> It seems like a good candidate for the release branch. Once merged into
> KWSys, we'll see if it smoothly merged into ITK's release branch.
>
> Brad
>
> On Jul 30, 2014, at 8:56 AM, Rashad M <mohammedrashadkm at gmail.com> wrote:
>
> Hello Brad,
>
> Already in [1]
>
> *(If your change modifies the "Modules/ThirdParty/KWSys/src/KWSys"
> directory please contribute directly to KWSys
> <http://www.itk.org/Wiki/KWSys/Git>instead.)*
>
> So should continue in itk gerrit or KWSys?. If ITK it should be in release
> branch or trunk (4.7). AFAICT, this happens to block build on MingW64 bit
> on windows
>
>
> [1] http://www.itk.org/Wiki/ITK/Git/Develop
>
>
> On Wed, Jul 30, 2014 at 2:49 PM, Bradley Lowekamp <blowekamp at mail.nih.gov>
> wrote:
>
>> Hello,
>>
>> Could you please submit your patch to gerrit for review:
>>
>> http://www.itk.org/Wiki/ITK/Git/Develop
>>
>> Thanks,
>> Brad
>>
>>
>>
>> On Jul 29, 2014, at 9:58 PM, Rashad M <mohammedrashadkm at gmail.com> wrote:
>>
>>  Hi all,
>>
>> Building ITK with MinGW64 comes clean but when using it in other library
>> gives the below error. Turning -fpermissive can solve this bug but its not
>> a option to be considered.
>>
>> I had attached a  patch which will resolve this issue.
>>
>> [ 78%] Building CXX object
>> Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperApplicationRegistry.cxx.obj
>> [ 79%] Building CXX object
>> Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperChoiceParameter.cxx.obj
>> Linking CXX shared library ../../bin/libOTBTesting.dll
>> [ 79%] Built target OTBTesting
>> [ 79%] Building CXX object
>> Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperInputImageListParameter.cxx.obj
>> [ 79%] Building CXX object
>> Code/ApplicationEngine/CMakeFiles/OTBApplicationEngine.dir/otbWrapperOutputImageParameter.cxx.obj
>> Scanning dependencies of target otbTestDriver
>> [ 79%] Building CXX object
>> Code/Testing/CMakeFiles/otbTestDriver.dir/otbTestDriver.cxx.obj
>> In file included from
>> /.../OTB-Nightly/Code/Testing/otbTestDriver.cxx:35:0:
>> /home/rashad/packages/mxe/usr/x86_64-w64-mingw32.shared/include/ITK-4.6/itksys/SharedForward.h:
>> In function 'void kwsys_shared_forward_execvp(const char*, const char*
>> const*)':
>>
>> /home/rashad/packages/mxe/usr/x86_64-w64-mingw32.shared/include/ITK-4.6/itksys/SharedForward.h:516:19:
>> error: invalid conversion from 'const char* const*' to 'char* const*'
>> [-fpermissive]
>>
>>    execvp(cmd, argv);
>>                    ^
>> In file included from
>> /home/rashad/packages/mxe/usr/x86_64-w64-mingw32.shared/include/ITK-4.6/itksys/SharedForward.h:158:0,
>>                  from /.../OTB-Nightly/Code/Testing/otbTestDriver.cxx:35:
>>
>>
>> --
>> Regards,
>>    Rashad
>>  <itk-3-execvp.patch>_______________________________________________
>> 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
>>
>>
>>
>
>
> --
> Regards,
>    Rashad
>
>
>


-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140730/af8832c5/attachment.html>

From blowekamp at mail.nih.gov  Wed Jul 30 10:12:56 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Wed, 30 Jul 2014 10:12:56 -0400
Subject: [ITK-dev] [ITK] Optimizing composite transforms and center of
	transform
In-Reply-To: <8C9CCC8B-5379-4A6A-902F-ACAE609F5789@gmail.com>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
 <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
 <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>
 <2A37CDEA-B4F3-4826-BAF8-D64D6C4A53F6@mail.nih.gov>
 <8C9CCC8B-5379-4A6A-902F-ACAE609F5789@gmail.com>
Message-ID: <8727A959-8F80-471A-9E24-04C0E564D8DC@mail.nih.gov>

Nick,

To try to summaries... sorry if have not been clear enough in my explanations.

INITIAL QUESTION

How does composite transform and the "Center" parameter interact? How does this relate to the virtual domain?

MY UNDERSTANDING

1) Using a "Center" initialized transform only works correctly for a single transform and directly with a composite. ( This is with the current center initializers, a different approach could be done which takes into consideration the composition )

2) The virtual domain should be initialized such that the two images "Center"s are at the origin. This an alternative to using the "Center" transform parameters, and better works with composite transforms.

I was not aware that 2 was the best practice with the ITKv4 framework. Do we have any examples/test/documentation to indicate this?  Further more using the current CenterTransformInitalizers to initialize the virtual domain is not readily apparent[1] how to map the parameters.

PROPOSAL

Perhaps we need a new Initializer filter to assist with initializing the virtual domain to initialize this practice? 

Brad


[1] https://github.com/stnava/ANTs/blob/master/Examples/itkantsRegistrationHelper.h#L830-L878


On Jul 29, 2014, at 7:55 PM, Nicholas Tustison <ntustison at gmail.com> wrote:

> Sorry, Brad, but I?m having a hard time following what
> the problem is exactly.  I agree with you that getting a
> good initialization, i.e., centering the objects of interest
> to be registered is important.  And that is something 
> we do in ANTs by employing the centered transform
> initializer or aligning origins by converting the result to
> a translation transform.  That translation transform is then
> pushed onto the composite transform queue.  
> 
> If that is followed up by other transforms to be optimized,
> such as rigid or affine, the moving image is already "centered"
> in the virtual domain within the similarity metric classes and 
> optimization in terms of translation to center the objects is (or 
> at least, should be) minimal.
> 
> Does that help?
> 
> Nick
> 
> 
> 
> 
> 
> On Jul 29, 2014, at 4:16 PM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> 
>> Hello,
>> 
>> Ok, to further explore this problem, and hopeful help other people too: I created an IPython Notebook viewable here:
>> http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/blob/master/Transform%20Composition%20And%20Order.ipynb
>> 
>> It doesn't come through on the static page, but I added some nifty interactive slider widgets to change the rotation parameter. Which is really the point  to enable understanding of the parameters for the transform and how they should be best optimized. The notebook should work with SimpleITK >= 0.8 and IPython Notebooks 2.1. I'll encourage every one to try it out :) IPython Notebooks widget are very cool!
>> 
>> EXPLANATION:
>> 
>> The the order of the composite transform is that the new transforms are applied first.
>> 
>> BUT they map from the virtual domain ( fixed ) to the moving image. Therefore if your first transform moves the center of mass to the origin then the second added transform's space will be centered on the mass, which is good for optimizing rotation and affine parameters.
>> 
>> QUESTION:
>> 
>> Therefore I am inclined to conclude that its best practices to map the fixed and moving image to the virtual domain such that the center of mass ( or some other "center feature" ) are at the origin. This would then the scale, rotation and other affine parameters around the center, with out having to used the "Center" parameter the transforms currently have.
>> 
>> Is this what others are doing in their registration? For general best practices should this be recommend?
>> 
>> @Brian I know I have seen this multi-domain description many time, but I think I may have just gotten it... Is the well describe in the literature some place? I think this may be an important part add the software guide.
>> 
>> Thanks,
>> Brad
>> 
>> 
>> 
>> 
>> On Jul 29, 2014, at 5:38 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:
>> 
>>> Hi Brad,
>>> 
>>> Your assessment that the fixed center is important is correct.
>>> 
>>> In most cases, a transform with a Center is the first transform in a
>>> Composite transform. There not any issues here.  However, if the
>>> transform with a Center is further along the chain, then a
>>> CenteredTransformInitializer that was applied before the registration
>>> is started will not generate the desired result. In this case, we
>>> would have to respond to an Event in the registration process and
>>> estimated the center on the imaged after the other transforms have
>>> been applied. It is more work, but it is a more unusual case.
>>> 
>>> HTH,
>>> Matt
>>> 
>>> 
>>> 
>>> On Mon, Jul 28, 2014 at 10:11 PM, Bradley Lowekamp
>>> <blowekamp at mail.nih.gov> wrote:
>>>> Helloo Nick!
>>>> 
>>>> I am glad you got back to me.
>>>> 
>>>> I suspect that I have spent more time this past week looking at the ITK affine transforms than anyone else[1] this week. With that here is my current understanding...
>>>> 
>>>> 1) The CenterTransformInitializers estimates an initial "Center" and an initial "Translation" parameter from either the geometry or the first moments. From my problematic experiences, getting the initial transform which is a "good" guess is been critical for the optimizer to head to the correct solution.
>>>> 
>>>> 2) The Center parameter of a transform can either be "Fixed" or an optimizable parameter. The transforms with the "Centered" monkier are the the ones with the Center parameter optimizable. This issue seems to be what you were referring to in to message.
>>>> 
>>>> In many ways the point I am trying to make is independent of #2. I have observed that it's important to have the "Center" of an affine transform ( or sub parameterization thereof ) at the center of the object you are trying to register. That is the coordinate space of the optimizable parameters' point 0 is near the center. This enables rotation to easily rotate around the center, as well as scaling to maintain the same relative center when "zooming". This issue is independent of wether that center point can be optimized.
>>>> 
>>>> For example, consider changing the origin of an image for alignment by say 500, and compensating with just an initial translation and not setting the "Center" parameter. If we are trying to optimize rotation and translation, then the optimization path would be very difficult to traverse with these inter-dependent parameters to force it to rotate around the center of the object. This scenario may be more common in microscopy then medical imaging, due to microscopy frequently having multiple subjects across large images. I could write up a IPython Notebook to illustrate the case.
>>>> 
>>>> So that is my understanding of why using a fixed center is important. I thought this may have been shared knowledge, but perhaps is not or is incorrect...
>>>> 
>>>> Now I am trying to understand how this interacts with all the coordinate frames involved with the ITKv4 registration framework, and the composite transforms. Specifically the composite transform apply the transforms in "reverse order"[2]. As I understand that that means that the newest transform get applied first. So that transform parameters are being optimized in the images space not in the virtual domains we are working towards. Therefore the center of our transforms is still important as we composite transforms?
>>>> 
>>>> I hope I explained that clearly, a white board may really be needed....
>>>> 
>>>> Thanks,
>>>> Brad
>>>> 
>>>> 
>>>> [1] https://github.com/SimpleITK/SimpleITK/compare/master...9bc9bc8440e64d94099d3519eb23bcc16c7cf015
>>>> [2] http://www.itk.org/Doxygen/html/classitk_1_1CompositeTransform.html
>>>> 
>>>> On Jul 28, 2014, at 8:57 PM, Nicholas Tustison <ntustison at gmail.com> wrote:
>>>> 
>>>>> Hi Brad,
>>>>> 
>>>>> I apologize for the delayed response.  I?m still catching up on my
>>>>> workload after moving to CA.  We might want to talk to Luis as it
>>>>> was my understanding that the ?center? component of the linear
>>>>> transforms might be a carry-over from all the ?Centered? transforms,
>>>>> e.g.,
>>>>> 
>>>>> http://www.itk.org/Doxygen/html/classitk_1_1CenteredAffineTransform.html
>>>>> 
>>>>> which, if I remember correctly, Luis said were somewhat sub optimally
>>>>> conceived but this was such a long time ago that I might be completely
>>>>> misremembering.  However, fixing the center for all transforms within
>>>>> a composite transform is certainly not necessary within the specified
>>>>> framework.  Rather, the matrix and offset are updated with the ?Center?
>>>>> being updated implicitly.
>>>>> 
>>>>> Nick
>>>>> 
>>>>> 
>>>>> 
>>>>> On Jul 24, 2014, at 7:27 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> There are a lot of transforms involved in the new registration framework.
>>>>>> 
>>>>>> I am trying to figure out what the implications for the fix parameters of the transform "Center" ( ie center of rotation/scaling ) are when combined with composite transforms and the fixed/moving/registration coordinate frames...
>>>>>> 
>>>>>> Based on how the transforms are composed it seems necessary to set the  fix "Center" for subsequent transformations. Additionally, I am unsure how one would "improve" ( poorly defined? ) the center for a subsequent transform ie Affine after a similarity...
>>>>>> 
>>>>>> Are there some documented guidance or figures to help with this issue?
>>>>>> Do we have a comprehensive diagram of these transforms?
>>>>>> 
>>>>>> Thanks,
>>>>>> Brad
>>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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 ntustison at gmail.com  Wed Jul 30 13:57:23 2014
From: ntustison at gmail.com (Nicholas Tustison)
Date: Wed, 30 Jul 2014 10:57:23 -0700
Subject: [ITK-dev] [ITK] Optimizing composite transforms and center of
	transform
In-Reply-To: <8727A959-8F80-471A-9E24-04C0E564D8DC@mail.nih.gov>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
 <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
 <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>
 <2A37CDEA-B4F3-4826-BAF8-D64D6C4A53F6@mail.nih.gov>
 <8C9CCC8B-5379-4A6A-902F-ACAE609F5789@gmail.com>
 <8727A959-8F80-471A-9E24-04C0E564D8DC@mail.nih.gov>
Message-ID: <B64FB7E2-37AE-4D41-9777-064CC6E4CBE8@gmail.com>

> To try to summaries... sorry if have not been clear enough in my explanations.

No, I blame me?I?m consistently distracted by the scenery outside here in
California and it?s definitely affecting my ability to concentrate on code
questions.

> INITIAL QUESTION
> 
> How does composite transform and the "Center" parameter interact? How does this relate to the virtual domain?

The composite transform is agnostic with respect to whether or not a 
transform has a center or any other fixed parameter set.  The only
distinction we make is typology with respect to linear/deformable. To 
be clear, we?re not discussing any of the  ?Centered? transforms:

* CenteredAffineTransform
* CenteredEuler3DTransform
* CenteredEuler2DTransform
* CenteredSimilarity2DTransform

None of those transforms are used in ANTs but I don?t think 
their optimization would be an issue in the new ITKv4 registration 
framework.

The virtual domain is simply defined in terms of standard image 
geometry (origin, spacing, etc.) and is currently set in terms of the 
fixed image geometry.  

> MY UNDERSTANDING
> 
> 1) Using a "Center" initialized transform only works correctly for a single transform and directly with a composite. ( This is with the current center initializers, a different approach could be done which takes into consideration the composition )

I don?t see why it would only work correctly for a single transform.  Suppose
I optimize a translation transform to get it?s optimal parameters for a given
registration problem.  It?s not clear to me why it would be a problem to follow
that with optimizing an Euler3D transform (which we do all the time in ANTs).  
Obviously, we have to specify a staring point for the second transform (which
is identity by default) and perhaps it would be better to have a different 
starting point but I don?t see why starting with the default parameters is a 
problem.

If the ?Center initialized transform? is one of the transforms listed above 
then we don?t use those.  If it?s simply the result of using the 
CenteredTransformInitializer, then we just pull the itk::TranslationTransform 
part from the result and push that translation transform into the composite 
transform queue.   I don?t see why it would be a problem to then optimize, 
for example, the Euler3DTransform which just has 3 translation parameters 
and 3 angle parameters to optimize where the center is implicitly defined 
(unlike the CenteredEuler3DTransform which does have additional Center 
parameters).  

> 2) The virtual domain should be initialized such that the two images "Center"s are at the origin. This an alternative to using the "Center" transform parameters, and better works with composite transforms.

Yes, that would probably be a better initialization but I don?t know why it would
be a problem for the current framework to optimize with the origin elsewhere.
Right now, each transform within the composite transform queue is 
optimized starting from its identity parameters but perhaps the initializer
idea that you propose would improve optimization. 

> I was not aware that 2 was the best practice with the ITKv4 framework. Do we have any examples/test/documentation to indicate this?  Further more using the current CenterTransformInitalizers to initialize the virtual domain is not readily apparent[1] how to map the parameters.
> PROPOSAL
> 
> Perhaps we need a new Initializer filter to assist with initializing the virtual domain to initialize this practice? 
> 
> Brad


From matt.mccormick at kitware.com  Wed Jul 30 14:44:08 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 30 Jul 2014 14:44:08 -0400
Subject: [ITK-dev] [ANNOUNCE] ITK 4.6.0 has been released!
Message-ID: <CALzTN-T6uCOHxJQy5ZdoVktbONd3AW7X-Ci46rWZ+MPzW+hjFg@mail.gmail.com>

On behalf of the Insight Toolkit community, we are proud to announce
that ITK 4.6.0 has been released!


Links to the Sourceforge.net tarballs can be found on the download page:

 http://www.itk.org/ITK/resources/software.html


Outline
----------

1. Introduction
2. New Documentation
3  New Features
4. ITK Changelog
5. ITK Sphinx Examples Changelog
6. ITK Software Guide Changelog


Introduction
-------------------------

The 4.6 release is a major milestone that marks the hard work of many
outstanding community members.


Among the major contributions in this release are improved Remote
Module support with a number of exciting new Remote Modules.  The
TransformToDisplacementField filter and a entire module of image noise
generation classes were migrated into the default build. A number of
new optimizers were added to the Registrationv4 framework, which also
experienced a number of performance improvements. Performance
improvements were a general theme as was improved code coverage.
Python wrapping underwent a huge cleanup.


Our documentation continues to improve with better examples, Doxygen
documentation, and guidance material.  The Software Guide was split in
anticipation of the release of two new hard copy books.


Thanks to everyone for their hard work!

Enjoy ITK!


New Documentation
-------------------------


Our documentation continues to improve.  Remote modules are now
grouped in the Doxygen Module page [1]. A number of new examples were
added to the Sphinx repository and the Wiki, which can now also be
built as Remote modules. The Software Guide was split into two books
and the ITK configure and build instructions were revised.

[1] http://www.itk.org/Doxygen/html/modules.html


New Features
------------------


* CMake improvements
  - Improved Remote Module support
  - Add ITK_FORBID_DOWNLOADS for package maintainers
  - ITK_USE_SYSTEM_EXPAT available


* Filtering Improvements
  - Moved TransformToDisplacementField out of Review
  - An entire noise image generation module
    - http://hdl.handle.net/10380/3158
  - Better pipeline support for ResampleImageFilter
  - Move MagnitudeAndPhaseToComplexImageFilter out of Review
  - Setters for LabelMap overlay filters
  - More consistent filter progress reporting


* ImageIO improvements
  - Register the GE image formats by default
  - More IO modules are built as shared libraries
  - OpenFileForReading/Writing methods in ImageIO
  - Support for system tiff 4.0.0-4.0.2 (e.g. some Ubuntu versions)
  - Mangling to internal OpenJPEG
  - SCIFIO improvements


* Infrastructure improvements
  - MetaDataObject print specialization for common types
  - Improvements to ResourceProbe and RealTimeClock
  - More Solve methods for VNLSparseLUSolverTraits
  - Output stream operator for LightObject exposed
  - FFTW bump to 3.3.3


* New Remote Modules
  - Skull stripper
    - http://hdl.handle.net/10380/3353
  - Wiki examples
  - Sphinx examples
  - Variational registration
    - http://hdl.handle.net/10380/3460
  - AnalyzeObjectMapIO
    - http://hdl.handle.net/1926/593
  - FDFImageIO
  - SplitComponents
    - http://hdl.handle.net/10380/320


* Registrationv4 improvements
  - v4 regular step gradient descent optimizer
  - v4 amoeba optimizer
  - v4 exhaustive optimizer
  - v4 Powell optimizer
  - v4 one-plus-one-evolutionary optimizer
  - v4 LBFGS optimizer improvements
  - Use registration method classes as pipeline filters


* Performance improvements
  - Registrationv4
  - Histogram computation
  - Improved SmartPointer copy
  - CompositeTransform
  - Registration Jacobian re-use


* Wrapping improvements
  - pygccxml 1.0.0
  - .pth symlink usable in a virtualenv
  - Cleaner CMake configuration
  - SWIG and PCRE updated to 3.0.2, 8.34
  - Latest GCCXML, which works with GCC 4.9
  - Sweeping wrapping generation cleanup

* Many style improvements -- ITK gets more stylish with every release!


* Improved code coverage -- some measures put us over 85%!


* *Lots* of important bug fixes


* And more! See details in the log below.


List of changes since v4.6rc03
--------------------------------------


Arnaud Gelas (1):
     DOC: ThresholdBetween does not exist, it should be ThresholdOutside

Bradley Lowekamp (6):
     BUG: Remove division in inner loop for otsu threshold calculator
     COMP: Fix implicit conversion warnings
     BUG: Print the histogram calculator for auto threshold filter
     BUG: Use tolerant float compare when choosing better otsu threshold
     BUG: Fix out of bounds access for image region size
     BUG: Add export specification to DCMTKFileReader and utilities

Luis Ibanez (1):
     BUG: Increased OtsuThreshold computation precision

Matthew McCormick (13):
     COMP: Remove unused local typedef's.
     COMP: Make Doxygen Modules group definition consistent.
     STYLE: Improve readability and const correctness of ImageIORegion.
     BUG: GDCM does not apply rescale slope / intercept on write.
     COMP: Ignore itkIndex.h -Warray-bounds warnings on GCC 4.9.
     COMP: Remove unused typedefs in ITKReview module.
     COMP: Remove unused FFTW typedef's.
     COMP: Remove unused typedefs from the Examples.
     COMP: Remove unused typedefs in compatibility code.
     BUG: Fix GDCM buffer size when written pixel type is different.
     COMP: Disable array above bounds warnings in FixedArray for GCC 4.9.
     BUG: Increase itkVoronoiPartitioningImageFilterTest1 for 32-bit builds.
     BUG: Set output type to unsigned char when writing uchar in GDCMIO test.

Michka Popoff (3):
     BUG: Fix GeodesicActiveContourImageFilterOutput7.png
     STYLE: Threshold Segmentation LevelSet Image Filter Figure
     ENH: Remove GeodesicActiveContourImageFilter.py example

List of changes since v4.6rc02
---------------------------------------


Ali Ghayoor (1):
          ENH: Convert seven ImageRegistration examples to ITKv4

Bradley Lowekamp (2):
          BUG: Remove multiple per-pixel allocations in Mahalanobis Membership
          COMP: Fix unused-local-typedef warnings in the Registration
and Numeric

Hans Johnson (1):
          ENH: Prepare for ITKv4 registration Examples

Matthew McCormick (5):
          BUG: Improve module Group membership detection.
          COMP: Fix unused-local-typedef warnings in Group Core.
          BUG: Update TransformReadWrite example.
          COMP: Fix unused-local-typedef warnings in the Filtering Group.
          COMP: Remove unused typedefs.

Nick Tustison (1):
          ENH:  Missed spec for generic computation type.


List of changes since v4.6rc01
---------------------------------------


Bradley Lowekamp (3):
     BUG: Do not ENABLED_SHARED for GDCMIO
     DOC: Add break in brief description of Canny edge filter
     BUG: Add additional MetaDataObject explicit instantiation.

Jean-Christophe Fillion-Robin (2):
     COMP: Fix "unused-local-typedefs" warnings
     COMP: Fix "unused-local-typedefs" warning in
LandmarkBasedTransformInitializer

Kent Williams (1):
     COMP: Fix typo in ReflectiveImageRegionConstIterator.

Matthew McCormick (4):
     DOC: CMake warning BRANWEB -> BRAINWEB.
     BUG: Remove -Wno-unused-local-typedefs flag.
     COMP: Fix IOSTL Doxygen group and Windows shared build.
     BUG: Use Remote repository explicitly on git fetch.

Michka Popoff (6):
     COMP: Move itkMatrixCoefficients wrapping to Filtering module
     COMP: Fix wrapping with Core only
     STYLE: Pep8 cleanup for generators
     COMP: Fix default wrapping with all modules
     ENH: Use open() instead of file() for python 3 compatibility
     ENH: Allow to use methods which pass std::string by reference from python

Nick Tustison (1):
     ENH:  Adding generic computation type.


List of changes since v4.5.0
--------------------------------------

Alexander Schmidt-Richberg (1):
      ENH: Added *.remote.cmake for remote module VariationalRegistration


Ali Ghayoor (22):
      ENH: Add a registration test for LBFGS-B optimizer
      ENH: Add versorTransformOptimizerv4 class to ITKv4
      BUG: Fix Coverity defects for LBFGS-B tests
      BUG: avoid division by zero in versorOptimizerv4
      ENH: Add RegularStep gradient optimizer to ITKv4
      DOC: The use of VersorTransformOptimizerv4 is deprecated.
      ENH: [SG]et optimizable params ITKv4 registration
      ENH: remove VersorTransformOptimizerv4 from ITKv4
      ENH: Add AmoebaOptimizerv4 to ITKv4 registration
      ENH: Add ExhaustiveOptimizerv4 to ITKv4 registration
      ENH: Add PowellOptimizerv4 to ITKv4 registration
      BUG: define the GetStopConditionDescription as a public member funciton
      ENH: Add OnePlusOneEvolutionaryOptimizerv4 to ITKv4 registration
      BUG: lbfgsb optimizer could not be used in unbounded mode
      ENH: Add GetCurrentIteration to ExhaustiveOptimizerv4
      ENH: Add currentIteration to the AmoebaOptimizerv4
      PERF: Move the currentIteration to optimizersv4 base class
      ENH: Move the NumberOfIterations to the Optimizersv4 base class
      PERF: Change the parent class of RegularStepGradDescentv4 optimizer
      ENH: Add currentIteration to LBFGSBOptimizerv4
      BUG: Fix memory leak in LBFGSBOptimzierv4
      ENH: Add distance vector to KdTree search API


Bill Lorensen (32):
      BUG: Tiff compression was broken and untested
      ENH: Add SetJPEGQuality method
      COMP: Missing breaks in swithc
      COMP: Uninitialized scalar field
      COMP: Uninitialized scalar field
      COMP: Unused pointer value
      ENH: Add SkullStrip Remote Module
      BUG: Tiff compression was broken and untested
      COMP: Missing breaks in swithc
      ENH: Improved message for missing IO factories
      COMP: Remove vcl_time and vcl_clock
      ENH: Remove vcl_math calls
      COMP: std::abs integral overloads not always provided
      COMP: Array versus singleton access
      COMP: Failed to check dynamic_cast results
      STYLE: Empty lines exceed 3
      COMP: Uninitialized member data
      BUG: Two tests try to write the same file
      ENH: Uninitialized scalar field
      COMP: Constructor initialize list improvement
      COMP: Type warnings in constructors
      BUG: Copy/paste error
      COMP: Arguments of wrong type
      BUG: Buffer not null terminated
      BUG: Dereference after null check
      BUG: Division or modulo by zero
      ENH: Uninitialized scalar field
      BUG: Uninitialized scalar field
      BUG: Not restoring ostream format
      ENH: Add an exception safe state restore class for streams
      BUG: Not restoring ostream format
      ENH: Add WikiExamples as a remote module


Brad King (4):
      COMP: Remove extra calls to cmake_minimum_required
      COMP: Fix cmake_minimum_required call order
      COMP: Set CMake Policies CMP0025 and CMP0042 as necessary
      COMP: Add missing call to cmake_minimum_required


Bradley Lowekamp (91):
      ENH: Removed non-work TCL Examples
      DOC: Add missing const in Doxygen GetConstReferenceMacro
      BUG: Correctly re-throw exception to restore AbortEvent, ProcessAborted
      BUG: Emit StartEvent before a ProgressEvent
      BUG: Do not throw exception in Probes with mis-matched Stop
      BUG: Correctly re-throw exception to restore AbortEvent, ProcessAborted
      BUG: Adding export specification to Exception objects
      COMP: fix unused variable warning in abort test
      BUG: Adding export specification to Exception objects
      COMP: fix failing voronoi segmentation tests
      COMP: Remove explicit typed exception specifications
      ENH: Print Object name for observers of objects
      ENH: Adding progress reporting to some filters
      BUG: fixing grind peak progress to reach 1.0
      COMP: use std::transform with static_cast to avoid conversion warning
      BUG: disable ipa-cp-clone in GDCM
      COMP: fix unused variable warning in abort test
      BUG: Do not throw exception in Probes with mis-matched Stop
      BUG: Address Shared Library issues with SCIFIO
      COMP: fix failing voronoi segmentation tests
      COMP: export required in explicitly defined NumbericTraits consts
      DOC: Make comment the Doxygen brief
      BUG: Adding missing raw data file to MINC test
      BUG: Fix linkage for SmartPointerForwardReference for clang 4
      BUG: Fixing missing char type and doc for Thresholding filters
      BUG: Add support for system libtiff 4.0.0-4.0.2
      BUG: remove second wrapping of BinShrink for scalars
      BUG: Fix LabelStatistics and LabelOverlap to require same image size
      PERF: Remove IncreaseFrequencyOfMeasurement from inner loops
      STYLE: Save deference iterator mapped type to variable
      PERF: switch to scanline and linear iterators
      COMP: Fix checks for system libtiff
      PERF: add namespace swap to SmartPoitners
      PERF: Use stl iterator algorithm in Iterator Partitioner
      BUG: Add mutex lock to MersenneTwister GetInstance
      STYLE: MersenneTwister move methods to cxx, docs
      STYLE: renaming files to standard ITK conventions
      ENH: Improving Noise Simulation Filters
      COMP: Explicitly make constant an unsigned int
      BUG: Fix uninitialized ivar in NoiseBaseImageFilter
      ENH: Make NoiseBaseImageFilter an abstract base class
      COMP: remove extraneous cast to double
      BUG: Same test function in different file causes conflict
      ENH: Explicitly specify internal linkage for internal observer objects
      ENH: Enable observed events to modify observers
      BUG: Catch exception in DeleteEvent
      STYLE: dynamic_cast to pointer does not throw
      COMP: Fix GCC warning about unused typedef in ConceptChecking
      COMP: Adding itkMacro.h for ITK_NULLPTR definition
      ENH: Use DynamicCastInDebugMod for name input macros
      BUG: Add support for signed char output
      BUG: Use NewMacro for Clone with TimeVaryingVElocityFieldTransforms
      ENH: Improve DataObjectDecorator with Modifiable, Graft ReleaseData
      ENH: Improve Resample's use of pipeline inputs
      ENH: Adding output of line and file on test failure
      ENH: Add InitialTransform as pipelined input with inplace option
      ENH: Use Transform base class as default template parameter
      ENH: Use InitialTransform in deformation examples
      COMP: add missing stl algorithm header for std::max
      COMP: add missing stl algorithm header for std::max
      Revert "ENH: Add Remote module group description to Doxygen."
      COMP: Remove incorrect override declaration
      ENH: Encapsulate expat header
      ENH: Make IntialMoving and InitialFixed transforms decorated inputs
      ENH: Update SimpleRegistration test
      BUG: Don't create new Decorator in GenerateData
      BUG: Use referenceImage for output information
      ENH: Adding some ImageIO libraries as shared
      ENH: Use TransformParametersAdaporBase on Transform base class
      ENH: Removing const_casts from ImageRegistrationv4 tests
      BUG: Add AllocateOutputs method to other v4 RegistrationMethods
      ENH: Update v4 registration tests to set initial transform
      BUG: Explicitly instantiate common MetaDataObjects
      BUG: Disable explicit visibility with OSX gcc  and llvm gcc 4.2
      ENH: Register GE Image formats
      COMP: Fix warning for overloading AllocateElements
      COMP: Suppress warning for using extern template instantiation
      PERF: Use shallow swap over deep assignment
      ENH: Use LearingRate member variable for scaling gradient
      ENH: support learning rate estimation for regular step optimizer
      COMP: Add space between string literals
      ENH: remove catch as dynamic_cast of pointers is nothrow
      BUG: Use rounding in TestingStretchIntensity for portability
      BUG: Warn if unsupported ITK_BRAINWEB_DATA_ROOT is being used
      ENH: Use MultiResolutionIteration event for registration
      ENH: Use exception safe copy-and-swap for assignment
      BUG: Use DEPENDS for dependent files
      STYLE: Add itkPrintSelfObjectMacro to improve indenting
      BUG: Print missing member variables
      ENH: Make more IO modules shared.
      COMP: Add missing header for EXIT_FAILURE


Brian Helba (66):
      ENH: Disable tip to enable Uncrustify from SetupForDevelopment
      STYLE: Rename TValueType template parameters to TValue
      COMP: Fix compiler warnings with ITK_USE_SYSTEM_VXL
      BUG: Make all specializations NumericTrails::SetLength re-zero contents
      ENH: 3048, 3224: Refactor *SampleFilters to fix multiple issues
      ENH: Re-enable the array-bounds warnings for GCC 4.7
      DOC: Fix a bug with SquaredEdgeLengthDecimationQuadEdgeMeshFilter
      DOC: Clean up comments in NiftiImageIO, for better Doxygen compatibility
      STYLE: Remove unused typedefs from AlgorithmsPrintTests
      BUG: Fix improper usage of VoronoiSegmentationRGBImageFilter
      ENH: Move OpenFileForReading/Writing from StreamingImageIO to parent class
      ENH: Improve OpenFileForReading/Writing logic and documentation
      BUG: Prevent ObjectFactoryBase from possibly throwing an exception
      STYLE: Make internal-use CMake variables lowercase in KWStyle.cmake
      PERF: Prevent FindKWStyle.cmake from being called multiple times
      BUG: Fix FindKWStyle crash when kwstyle returns empty version info
      BUG: Fix Coverity issue 1081600: Use after free
      BUG: Update SmoothingRecursiveYvvGaussianFilter to fix CMake warnings
      ENH: Update ImageIO classes to use OpenFileForReading/Writing
      COMP: Fix array subscript build warning
      COMP: Except Git's status messages from CTest reporting
      COMP: Suppress Coverity defect when Examples create an ITK object
      BUG: Fix uninitialized variable in GradientRecursiveGaussianImageFilter
      DOC: Fix documentation in VoronoiDiagram2DGenerator
      BUG: Coverity 1081062: Fix big parameter passed by value
      BUG: Update IOSTL to include new bug fixes upstream
      DOC: Improve documentation for StatisticsAlgorithm functions
      BUG: Coverity 1130670: Buffer not null terminated in GE4ImageIO
      BUG: Coverity 1103200: Copy into fixed size buffer in GE5ImageIO
      STYLE: Coverity 1080839: Dead default in switch in
QuadEdgeMeshEulerOperatorJoinVertexTest
      STYLE: Coverity 1080963: Dereference after null check in TreeIteratorBase
      BUG: Coverity 1081009: Missing break in switch in GiftiMeshIO
      BUG: Coverity 1081422: Uninitialized pointer field in
QuadEdgeMeshFrontBaseIterator
      STYLE: Coverity 1081140: Dereference before null check
      BUG: Coverity 1081547: Uninitialized pointer field in
ConnectedRegionsMeshFilter
      STYLE: Coverity 40ee44a9: Self assignment in
VoronoiSegmentationImageFilterTest
      BUG: Coverity 1081129: Dereference before null check in itkIOCommonTest
      COMP: Update libminc from upstream, fixing a compiler warning on OSX
      BUG: Coverity 1081019: Improper use of negative value in StringTools
      COMP: Fix downcast warnings
      BUG: Coverity 1103189: Big parameter passed by value in FindSampleBound
      COMP: Fix implicit conversion warning
      COMP: Fix unused variable warning on Intel compilers
      BUG: Fix uninitialized variable in GradientRecursiveGaussianImageFilter
      BUG: Make all specializations NumericTrails::SetLength re-zero contents
      BUG: Update SmoothingRecursiveYvvGaussianFilter remote module
      BUG: Update SplitComponents remote module
      COMP: Fix implicit conversion warning
      BUG: Update SmoothingRecursiveYvvGaussianFilter remote module
      COMP: Update LesionSizingToolkit remote module from upstream
      STYLE: Coverity 1103618-1103620: Structurally dead code
      STYLE: Coverity 1081585: Structurally dead code
      STYLE: Coverity 1081584: Structurally dead code
      STYLE: Coverity 1081583: Structurally dead code
      STYLE: Coverity 1081580: Structurally dead code
      STYLE: Coverity 1081570-1081578: Structurally dead code
      STYLE: Coverity 1081566-1081568: Structurally dead code
      STYLE: Coverity 1081564: Structurally dead code
      STYLE: Coverity 1080826-1080827: Logically dead code
      STYLE: Coverity 1080862: Logically dead code
      STYLE: Coverity 1081598: Unused pointer value
      BUG: Coverity 1103595: Uninitialized pointer field
      BUG: Coverity 1081508: Uninitialized pointer field
      BUG: Fix uninitialized pointer fields
      BUG: Coverity 1081381: Uninitialized scalar field
      STYLE: Coverity 1103107-1103116: Logically dead code


Constantine Zakkaroff (1):
      DOC: HelloWorld Comments Edit for ITKSoftwareGuide


David Cole (2):
      COMP: Eliminate some level 4 warnings
      BUG: Add missing header files to enable try_run tests to run
without crashing


Dirk Padfield (2):
      DOC: Improved comments and reorganized code for IsolatedConnected
      DOC: Corrected documentation for threshold boundaries.


Eric Greveson (1):
      ENH: Add setters for the overlay functor in labelmap overlay filters.


Fotis Drakopoulos (1):
      ENH: Adding GetFEMFilter method to
PhysicsBasedNonRidgidRegistrationMethod.


GCC-XML Upstream (1):
      pygccxml 1.0.0 (reduced)


Ga?tan Lehmann (1):
      ENH: Importing files from Noise Simulation Article


Gib Bogle (1):
      BUG: Windows BigTIFF errors: stat failure and lack of COMPRESSION_DEFLATE


Google double-conversion Maintainers (1):
      COMP: Google double-conversion (reduced)


Guillaume Pasero (1):
      ENH: Add mangling to internal OpenJpeg


Hans Johnson (40):
      PERF: 15% speed improvement for registration
      PERF: Simplify conditionals in loop
      COMP: Conditional assert check warning unused var.
      COMP: SimpleITK linkage failure
      BUG: Missing Modified() call
      COMP: SimpleITK linkage failure
      BUG: Element numbers 1053, 1052 not hex
      BUG: Remove valgrind reported leak
      BUG: Add missing transform types to factory
      BUG: Missing Modified() call
      PERF: Reviewing code for facilitating compiler optimizations
      COMP: Fix const constructor for const arrays
      ENH: Add LBFGOptimizerv4(for BSPline registration)
      COMP: Test failure from numerical precision
      BUG: Memory leak introduced.
      COMP: Remove deprecated 'register' keyword
      ENH: Ignore autocompletion clang helper files
      ENH: Move to latest remote module tag
      STYLE: Improve testing of member Get/Set functions
      COMP: Update AnalyzeObjectMapIO replacing deprecated
      DOC: Fixed documentation regarding multi-threading
      DOC: Improved Image Representation
      PERF: Minimize redundant function calls
      PERF: Pull loop termination constants out of loop
      ENH: Refactoring the CompositeTransform class
      STYLE: Explicitly declare virtual for derived class member functions
      STYLE: Explicitly recognize virtual functions
      STYLE: Add ITK_NULLPTR supporting c++11 checks
      BUG: Missing parentheses for logic comparison
      STYLE: Explicitly declare virtual (cont. of 1c8609)
      STYLE: Consistency of threadID and threadId
      BUG: FFTConvolutionImageFilter outputs incorrect
      STYLE: GetStopConditionDescription abstract method
      PERF: Re-use jacobian rather than instantiation
      ENH: Improve test in preparation for performance testing
      PERF: Code simplifications for performance testing
      BUG: Missed an API change for Allocate
      STYLE: Remove unnecessary comments.
      BUG: Expose unusable functions
      BUG: Incomplete refactoring of member variable name


Jean-Christophe Fillion-Robin (1):
      COMP: Fix "unused-local-typedefs" warnings


Jens Wetzl (2):
      BUG: Fix race conditions in itkInvertDisplacementFieldImageFilter
      STYLE: Incorporated reviewer suggestions


Jon Haitz Legarreta (8):
      ENH: New test for itkSigmoidTransferFunction.
      COMP: Fix type casting build warning.
      ENH: New test for itkLogSigmoidTransferFunction
      ENH: Added call to Print() method
      STYLE: Changed LogSigmoidTransferFunction template argument names.
      ENH: Added StatisticsRelabelImageFilterTest to testing
      BUG: Fix issues with the BinaryStatisticsOpeningImageFilter test
      COMP: Test for itkCustomColormapFunction


Kent Williams (13):
      ENH: Add remote module for AnalyzeObjectMapIO
      BUG: incorrect loop var increment
      COMP: Update the DoubleConversion library upstream update script.
      ENH: Turn off DCMTK Logger messages by default
      COMP: fixed license test command in UpdateDoubleConversionFromGoogle.sh
      ENH: Add FDFImageIO as a remote module.
      PERF: replace image allocate followed by fillbuffer with allocate(true)
      COMP: Add test to verify Slope/Intercept handling
      BUG: GDCM reporting wrong spacing for some Media Types
      ENH: Add test for itkTestingStretchIntensityImageFilter
      COMP: Fix misplaced closing brace
      ENH: Remove try/catch exception handling around dynamic_catch
      ENH: Disallow vector multiply by itself


Liza Shrestha (1):
      COMP: Added new unit tests for increasing code coverage


Luis Ibanez (11):
      ENH: Add STLMeshIO remote module.
      BUG: Fixed module name IOSTL.
      COMP: Fixing instantiation of templated functions.
      BUG: Fixed Affine test 32bits. Precision checks.
      PERF: Accelerate initialize via selective testing.
      COMP: ShapeUniqueLabelMapFilter test was missing.
      STYLE: Coverity 1103119: Logically dead code
      BUG: itkLoggerThreadWrapper test was disabled.
      BUG: No DiscreteHessianGaussianImageFunctionTest.
      BUG: DiffusionTensorReconstruction lacked Progress
      BUG: TestingExtractSliceImageFilter lacked test.


Luke Bloy (4):
      BUG: Fixes itkBoxSpatialObject part of issue ITK-3153
      BUG: Fixes itkImageMaskSpatialObject part of issue ITK-3153
      BUG: Fixes itkBoxSpatialObject part of issue ITK-3153
      BUG: Fixes itkImageMaskSpatialObject part of issue ITK-3153


Marius Staring (2):
      ENH: add reset function to resource probe
      ENH: adding handle to RealTimeClock


Mark Hiner (1):
      ENH: bump to latest scifio-imageio


Martin Stegh?fer (1):
      BUG: Match behavior of SimpleFastMutexLock on different
platforms (#ITK-3248)


Matthew McCormick (93):
      ENH: Bump CMakeLists.txt to version 4.6.0.
      BUG: Remove unused itkAffineTransformXX.txt content links.
      BUG: Avoid SimpleImageRegistration{Float,Double}Test output clobbering.
      BUG: Prevent MINC transform tests outputs from clobbering.
      BUG: Add random number generator seed for vnl_algo_test_sparse_lm.
      COMP: Update libminc to latest version.
      ENH: Only build tests for modules explicitly enabled.
      BUG: Remove unused forward declarations in RegistrationMethodsv4.
      COMP: Update libminc to latest version.
      ENH: Add REQUIRES_DISPLAY CTest label.
      ENH: Add SplitComponents Remote Module.
      DOC: Suggest MeshFileReader instead VTKPolyDataReader.
      DOC: Add itkSetGetDecoratedInputMacro definition for Doxygen.
      COMP: Bump DCMTK to fix warning.
      BUG: Wrap TransformFileReader, TransformFileWriter.
      BUG: Remove unused itkAffineTransformXX.txt content links.
      COMP: Wrap OptimizerParameterScalesEstimatorTemplate.
      COMP: CommandIterationUpdate has field whose type uses anonymous
namespace.
      COMP: Do not use -fno-ipa-cp-clone with clang.
      ENH: Move TransformToDisplacementFieldSource out of Review.
      ENH: Bump ITK version to 4.5.1.
      COMP: ImageRegistrationHistogramPlotter Clone never referenced.
      ENH: Add the ITK_INSTALL_LIBRARY_DIR to WrapITK.pth.
      ENH: Bump SCIFIO to add wrapping.
      COMP: ImageRegistrationHistogramPlotter unchecked dynamic_cast.
      BUG: Fix Array memory leaks with non-const construction.
      BUG: Prevent ambiguous Array construction methods.
      COMP: HDF5 library version variables contain '@'.
      COMP: Remove add_custom_command(SOURCE...
      COMP: Wrap OptimizerParameterScalesEstimatorTemplate.
      BUG: Wrap TransformFileReader, TransformFileWriter.
      COMP: Add missing itkVerson.h header.
      COMP: LBFGSOptimizerBasev4 explicit Doxygen link request.
      ENH: Bump FFTW to 3.3.3.
      COMP: Duplicated VectorContainer wrapping for real types.
      BUG: Increase tolerance for itkFEMC0TriangularElement-NodalLoads-BCs
      STYLE: Add missing "Test" to GDCM test names and filenames.
      DOC: No ReferenceImage members in TransformToDisplacementFieldSource.
      COMP: Bump LesionSizingToolkit for Doxygen warnings.
      BUG: GDCM Series does not write z-spacing.
      COMP: Remove unreachable return statements.
      ENH: Add ITK_FORBID_DOWNLOADS option. ITK-3239
      COMP: Bump SplitComponents Remote for Doxygen warnings.
      COMP: return will never be executed after exception thrown.
      BUG: Invalid read during ImageIOBase SetDirection.
      COMP: Fix failed itkTIFFImageIOCompressionTest merge.
      ENH: Bump version to 4.5.2.
      COMP: return will never be executed after exception thrown.
      COMP: SigmoidTransferFunction conversion from double.
      BUG: BoxImageFilter GenerateInputRequestRegion public -> protected.
      DOC: KernelImageFilter does not reimplement GenerateInputRequestedRegion.
      STYLE: Remove SigmoidTransferFunction .hxx doxy comments.
      BUG: Clean up Python module2module test.
      BUG: TestingExtractSliceImageFilterTest v3 direction strategy.
      STYLE: Remove duplicated TestingExtractSliceImageFilter doxygen.
      COMP: Use latex formula for HoughTransform doxygen.
      COMP: SigmoidTransferFunction members Alpha, Beta real type.
      STYLE: Fix SigmoidTransformFunction template argument names.
      COMP: BuildHeaderTest.py print_function import.
      BUG: Fix print function errors in pygccxml.
      BUG: Fix print functions in igenerator.py.
      ENH: Add Remote module group description to Doxygen.
      STYLE: Clean up MetaDataObjectBase.
      STYLE: Clean up MetaDataObject.
      ENH: Add unit test for MetaDataObject.
      ENH: Add MetaDataObject Print specialization for common types.
      STYLE: Fix template statements in SigmoidTransformFunction.
      BUG: Remove public MetaDataObject constructors.
      BUG: Add missing private copy constructors to MetaDataObject.
      BUG: Remove FEMRegistrationFilter debug code.
      DOC: Improve documentation and types for SplitRequestedRegion.
      Revert "Revert "ENH: Add Remote module group description to Doxygen.""
      DOC: Remove errant "+" in Remote_documentation.
      ENH: For shared libraries when wrapping.
      ENH: Collect all wrapping configuration checks in one place.
      ENH: Better CMake defaults with wrapping.
      ENH: Replace CSWIG preprocessor definition with ITK_WRAPPING.
      BUG: Remove old itkSampleBuildTest.cmake.in file.
      ENH: Move MagnitudeAndPhaseToComplexImageFilter out of Review.
      COMP: Fix Doxygen warnings in itkMetaDataObject.h.
      BUG: Exclude Remote Modules the default ON Group values.
      COMP: Documentation CMake target must come before add_custom_command.
      BUG: Assign Remote modules to groups more robustly.
      BUG: Remove MagnitudeAndPhaseWriteComplexImageFilter test from
Review Module.
      BUG: Remove old tests from Review for classes that have been removed.
      DOC: Fix Software Guide LaTeX syntax errors in the examples.
      COMP: Define ITKCommon_EXPORT_EXPLICIT for Doxygen.
      COMP: Remove itkImageReadComplexWriteMagnitudeAndPhaseTest.cxx from list.
      BUG: Move MagnitudeAndPhaseToComplexImageFilter to the
ImageIntensity module.
      COMP: StdStreamStateSave Doxygen include.
      ENH: Add Sphinx examples as a Remote Module.
      BUG: Remove ITK_INSTALL_NO_LIBRARIES and ITK_INSTALL_NO_DEVELOPMENT.
      ENH: Make ITK_WRAPPING INTERNAL.


Matthew Woehlke (1):
      COMP: Fix egregious -Wcast-qual warnings


Michka Popoff (53):
      BUG: Fix for the WrapITK.pth destination path
      COMP: Fixes the Python wrapping under OS 10.8.5
      STYLE: Removed itkExtras folder
      BUG: Fix for the WrapITK.pth destination path
      COMP: Fixed itkQuasiNewtonOptimizerv4 wrapping warnings
      STYLE: 4 space indentation for python files
      COMP: Fixed itkGradientDescentOptimizerv4 wrapping warnings
      STYLE: Removed deprecated itk functions
      STYLE: Removed unused and misplaced python tests
      STYLE: Removed legacy python importing
      STYLE: Pep8 cleanup for the python files
      STYLE: Remove deprecated python strel function
      COMP: Fixed itkQuasiNewtonOptimizerv4 wrapping warnings
      COMP: Fixed itkGradientDescentOptimizerv4 wrapping warnings
      ENH: Use python warnings module for template warnings
      COMP: Duplicated wrapping for double in Array2D
      COMP: Update SWIG to 2.0.12
      COMP: Require at least Python 2.6 for Python wrapping
      ENH: Remove python dl dependency
      ENH: Remove psyco import
      COMP: Update PCRE to 8.34
      ENH: Update Swig to 3.0.0
      STYLE: Remove WrapITK versions
      COMP: Remove cmp0011 in wrapping
      COMP: Remove unused code in ConfigureWrapping.cmake
      COMP: Remove clrLine in itkExtras
      COMP: Fix the python import and progress callbacks
      STYLE: Remove reference to CableSwig
      STYLE: Clean up BinaryThresholdImageFilter (python)
      COMP: Fix the Python ResampleImageFilter test
      ENH: Bump SCIFIO for OS X installation
      ENH: Bump SCIFIO for OS X installation
      COMP: Update PCRE to 8.35
      STYLE: Remove unused compile all code for Python Wrapping
      ENH: Replace python print with print() function
      STYLE: Remove deprecated Python wrapping macros
      COMP: Fix failing header test
      COMP: Fix the writing of .idx files
      COMP: Fix python print import for .pth file creation
      COMP: Fix print import statement in itkExtras.py
      STYLE: Refactor swig call and code cleanup
      COMP: Fix for wrapping warnings (RealTimeClock and SimpleFastMutexLock)
      STYLE: Remove old Python examples
      COMP: Update gccxml
      ENH: Use pygccxml snapshot.
      ENH: Update to swig 3.0.2
      DOC: Update commit instructions for JIRA bugtracker
      ENH: Update GCCXML
      BUG: Fix wrapping with dimension 2 only
      COMP: Temporarily hide pygccxml warnings
      BUG: Do not wrap BinaryMask3DMeshSource when building with 2D only
      COMP: Move itkMatrixCoefficients wrapping to Filtering module
      COMP: Fix wrapping with Core only


Miguel Algaba (1):
      ENH: Added further Solve methods to VNLSparseLUSolverTraits


Nick Tustison (2):
      BUG:  Ignored the case for exceeding iteration limit.
      ENH: Preparing point set metrics for use with registration.


Rashad M (1):
      STYLE: Allow system installed expat library with ITK_USE_SYSTEM_EXPAT=ON


Sean McBride (6):
      BUG: initialize m_SmallBlock ivar in ctor; fixes garbage read
      BUG: changed some variables involved in shifting to unsigned
      COMP: Updated libminc to a78661bb592359ab86f417cc0c298299e593d808
      BUG: initialize m_SmallBlock ivar in ctor; fixes garbage read
      PERF: Mark ImageRegistration8Test with RUNS_LONG
      COMP: workaround clang -Windent warnings by fixing indentation


Sebastian P?lsterl (1):
      BUG: Return null pointer if class label does not exist (#3235)


Taylor Braun-Jones (1):
      ENH: Expose the output stream operator for LightObject


Vladimir Chalupecky (1):
      DOC: Fix description of SpatialObject::GetBoundingBox()


Vladimir S. FONOV (3):
      COMP: Fixed libminc to build on Windows
      COMP: Updated libminc, hopefully reducing number of warnings
      COMP: Improved MINCIOTransform tests


Wei Liu (1):
      BUG: Fixed a bug in ExpectationMaximiationMixtureModelEstimator.


Yves Frederix (1):
      ENH: GeodesicActiveContourShapePrior deals with DerivativeSigma
equal to zero


ITK Sphinx Examples Changelog
-----------------------------------------

Arnaud Gelas (25):
     remove annonying messages about include folders not used with Clang
     ENH: Add one example for LabelMapMakImageFilter
     upgrade breathe to 1.2.0
     add documentation for ITKLabelMap
     ENH: Add one example to convert a triangular mesh to binary image
     ENH: Add example for itk::AccumulateImageFilter
     read an unknown image type
     add example to generate mesh from binary image
     ENH: Add one example for ExpNegativeImageFilter
     add one example for ThresholdImageFilter
     Add one example to translate one itk::Mesh
     add Iterative hole filling example
     wrong directory name
     fix link to c++ code
     link to the wrong folder for canny edge detection example
     Resample scalar image (with identity transform)
     fix command line for cloning in README
     COMP: Fix for failing ApplyAccumulateImageFilter baseline comparison test
     add one example to translate one itk::Image
     add PasteImageFilter example
     fix path in ArchiveBinaryData.py.in
     BUG: error when TEST_IMAGE_PREFIX was used
     fix broken links as detected by linkcheck
     add example for PermuteAxesImageFilter
     Add one example to apply an affine transform given homogeneous matrix

Brian Helba (3):
     ENH: Support ExternalData_OBJECT_STORES being set with a Superbuild
     ENH: Allow ExternalData path to be set by environment on dashboards
     BUG: Set correct URL scheme in dashboard common script

Matt McCormick (21):
     ENH: DilateABinaryImage uses FlatStructuringElement.
     ENH: Add DilateABinaryImage.py.
     ENH: ErodeABinaryImage uses FlatStructuringElement.
     ENH: Add ErodeABinaryImage.py.
     ENH: Use Git email as default when uploading binary data.
     BUG: ITKIOImageBase module directory not included.
     BUG: MaskOneImageGivenLabelMap test name for baseline comparison.
     ENH: Add Register IO Factories example.
     ENH: Add documentation upload to common CDash script.
     ENH: Add ApplyExpNegativeImageFilter.py.
     BUG: Remove non-existent Sphinx example entry.
     DOC: Give an example call to UploadBinaryData.py.
     COMP: Fix Doxygen link to LevelSets visualization classes.
     ENH: Rename module to follow Remote Module convention.
     COMP: QUIET initial find_package( ITK ).
     ENH: Bump ITK Superbuild tag to 4.6.0.
     BUG: Fix ConvertAnITKGrayScaleImageToCVMat compare_to_baseline.
     COMP: Remove breathe link to ConstantPadImageFilter.
     BUG: Fix figure path for Iterative Hole Filling.
     BUG: Evolution.gif needs to be ..only:: html
     COMP: Content not permitted in image:: directive.

Michka Popoff (29):
     ENH: Add examples for grayscale image dilation/erosion
     ENH: Add BinaryThresholdImageFilter example
     COMP: Fix for cmake 3.0 compatibility
     ENH: Clean up ThresholdAnImageUsingOtsu
     ENH: Add missing python documentation call for binarythreshold example
     STYLE: Fix Python subtitles
     ENH: Add CannyEdgeDetectionImageFilter example
     COMP: Add cmake_minimum_required back
     STYLE: Cleanup include( ${ITK_USE_FILE} ) and minor alignements
     COMP: Fix for Canny Edge example
     ENH: Add CastImageFilter.py and code cleanup
     ENH: Add ComputeCurvatureAnisotropicDiffusion example
     ENH: Add GradientAnisotropicDiffusionImageFilter example
     ENH: Add ComputeGradientMagnitudeRecursiveGaussian python example
     ENH: Add CurvatureFlowImageFilter example
     STYLE: Clean up pipeline and uniformize error catching
     ENH: Add mean and median filters
     ENH: Add Laplacian filter example
     ENH: Add an example of image resampling
     COMP: Fix two documentation warnings
     STYLE: Update sys.argv len() checks
     ENH: Add example for Sigmoid computation
     STYLE: Rename python examples to Code.py
     ENH: Fix the git URL
     ENH: Add python code for ThresholdAnImage
     ENH: Add example for SmoothWithRecursiveGaussianImageFilter
     COMP: Fix failing setup of SegmentBloodVessels example
     STYLE: Update title for Apply Affine Transform example
     ENH: Add GeodesicActiveContourLevelSetImageFilter example


ITK Software Guide Changelog
---------------------------------------

Brad King (3):
      SoftwareGuideCover: Port to VTK >= 5
      SoftwareGuideCover: Re-order code to simplify non-interactive run
      SoftwareGuideCover: Adjust colors and camera position for new cover

Bradley Lowekamp (1):
      Fix spelling of Lowekamp

Constantine Zakkaroff (1):
      ENH: Revise Configure and Build Instructions

Hans Johnson (4):
      ENH: Reorder IO and filtering chapters.
      STYLE: Remove end of line spaces.
      COMP: File name change needed
      DOC: Added Direction to the figure

Matt McCormick (39):
      ENH: Improve Hello World directions.
      BUG: Remove extra configuration of SoftwareGuideConfiguration.tex.
      ENH: Update the printed SoftwareGuide authors.
      BUG: Updates to PrintedPreamble.
      BUG: Update the cover sources location.
      STYLE: Update CMake style in SoftwareGuide/Latex/CMakeLists.txt
      ENH: Split into two books.
      BUG: Build resolving citations.
      BUG: Update build process description in SoftwareGuide/README.txt.
      BUG: Remove SoftwareGuide/Latex/00-SoftwareGuide.tex.
      DOC: Move build instructions to top level README.
      ENH: Update funding acknowledgement.
      DOC: Remove minipage about VTK/CMake books.
      STYLE: Improve spacing after preamble year.
      BUG: Update Cover VWSegmentation CMakeLists.txt.
      COMP: Fix compilation of ModerBasedSegmentation.cxx.
      STYLE: Strip trailing whitespace from SoftwareGuide sources.
      COMP: Add -dUseCIEColor when building Printer quality.
      BUG: o -> % in comment.
      ENH: Update the Kitware logo.
      ENH: Update copyright notice.
      STYLE: Place the appendix before \backmatter.
      BUG: Remove commentted content.
      ENH: Matt -> Matthew.
      ENH: Add Ali Ghayoor to contributors.
      ENH: Add contributors for covers.
      BUG: Update participants URL.
      BUG: Move build configuration to PrintedPreamble-Common.
      ENH: Add description for book cover 2.
      BUG: Update index generation.
      BUG: Remove wrapping Tcl entry.
      BUG: Remove old comments.
      ENH: Bump ITK to v4.6.0.
      ENH: Pass PDF_QUALITY_LEVEL in superbuild.
      BUG: Remove unused RunExamples.py imports.
      ENH: Reduce verbosity of RunExamples.py.
      BUG: Do not include RegistrationITKv4 example sources in the build.
      BUG: Fix caption on Confidence Connectened on BrainWeb figures.
      BUG: Bump the ITK superbuild for LaTeX fixes.