From matt.mccormick at kitware.com  Tue Oct  4 11:52:47 2016
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Tue, 4 Oct 2016 11:52:47 -0400
Subject: [ITK-dev] ITK Confab Hangout Links
Message-ID: <CALzTN-S6W+YtQ+PFg6OiJu-_et5Mg9Z-n+Re1Xet+6xCFH_qvw@mail.gmail.com>

Hi,

Chatting with Jc about the Slicer community's use of Hangout's, Google
has now dropped support for G+ / Hangouts.

As suggested by Francois and Jc, I suggest we use a Google Calendar
entry with a Hangout link, then make the entry publicly visible. We
can publish a public hyperlink that people can use to join. This
worked well for the Slicer community.

Thanks,
Matt

From francois.budin at kitware.com  Tue Oct  4 11:55:55 2016
From: francois.budin at kitware.com (Francois Budin)
Date: Tue, 4 Oct 2016 11:55:55 -0400
Subject: [ITK-dev] ITK Confab Hangout Links
In-Reply-To: <CALzTN-S6W+YtQ+PFg6OiJu-_et5Mg9Z-n+Re1Xet+6xCFH_qvw@mail.gmail.com>
References: <CALzTN-S6W+YtQ+PFg6OiJu-_et5Mg9Z-n+Re1Xet+6xCFH_qvw@mail.gmail.com>
Message-ID: <CAHwLD2UvmY03vd1pH20j=Df-HaiVfZzMJJkpBUMNJxxYVnk9iw@mail.gmail.com>

Great idea. Thanks for looking more into that!

On Tue, Oct 4, 2016 at 11:52 AM, Matt McCormick <matt.mccormick at kitware.com>
wrote:

> Hi,
>
> Chatting with Jc about the Slicer community's use of Hangout's, Google
> has now dropped support for G+ / Hangouts.
>
> As suggested by Francois and Jc, I suggest we use a Google Calendar
> entry with a Hangout link, then make the entry publicly visible. We
> can publish a public hyperlink that people can use to join. This
> worked well for the Slicer community.
>
> Thanks,
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161004/235b0de7/attachment.html>

From matt.mccormick at kitware.com  Tue Oct  4 11:56:31 2016
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Tue, 4 Oct 2016 11:56:31 -0400
Subject: [ITK-dev] V4 Registration having trouble converging while V3
 works fine
In-Reply-To: <CAM7sfn22Yvi8Eo==QnwE4KsYoYs3y+urOw3MdCmr_s9W39Ha8w@mail.gmail.com>
References: <CAM7sfn22Yvi8Eo==QnwE4KsYoYs3y+urOw3MdCmr_s9W39Ha8w@mail.gmail.com>
Message-ID: <CALzTN-Tc7+WaoW_ssrUJsKt3R0p32ayd0fFfkw8bpisz+sm3Fg@mail.gmail.com>

Hi Sepide,

The parameters are not quite equivalent in the ITKv3 and ITKv4
frameworks. In particular, you may need to relax the convergence
criteria for ITKv4 to get the same behavior as ITKv3.

HTH,
Matt

On Fri, Sep 30, 2016 at 3:24 PM, sepideh movaghati
<sepideh.movaghati at gmail.com> wrote:
>
> Hi,
>
>
>
> I was comparing v3 and v4 registration performance on a set of 3D images. In
> few cases, I noticed that v4 registration is diverging while v3 converges to
> a reasonable result without any problem.
> I wonder if you have ever noticed a problem with v4 optimizer that could
> cause similar issues.
>
>
> I copied my code for v3 and v4 registration below. I tried to keep the
> registration configuration very similar in both versions. In v3 I set the
> NumberOfSpatialSamples to 380000 which is about 10% of voxels. I also tried
> with full sampling but the behavior stays the same.
>
>
> In the attached csv file you can see the metric value at each iteration of
> the optimizer for both v3 and v4 version. It is clear that v3 converges
> smoothly, but v4 makes the initial metric value worse after too many
> iterations.
>
>
>
> Thanks a lot in advance.
> Regards,
> Sepide
>
>
> auto interpolator = itk::LinearInterpolateImageFunction<ImageType,
> double>::New();
>
> auto transform = itk::AffineTransform<double>::New();
>
> transform->SetIdentity();
>
> itk::Array<double> scales;
>
> scales.SetSize(12);
>
> scales.Fill(1.0);
>
> scales[9] =  0.001; //translation parameters scales
>
> scales[10] =  0.001;
>
> scales[11] =  0.001;
>
>
>
> // Registration V3 ----------------------- :
>
>     auto metric = itk::MattesMutualInformationImageToImageMetric<ImageType,
> ImageType>::New();
>
>     auto optimizer = itk::RegularStepGradientDescentOptimizer::New();
>
>     auto registration = itk::ImageRegistrationMethod<ImageType,
> ImageType>::New();
>
>
>
>     int NumberOfSpatialSamples = 380000;
>
>
>
>     metric->SetNumberOfSpatialSamples(NumberOfSpatialSamples);
>
>     optimizer->SetScales(scales);
>
>     registration->SetMetric(metric);
>
>     registration->SetOptimizer(optimizer);
>
>     registration->SetInterpolator(interpolator);
>
>     registration->SetTransform(transform);
>
>     registration->SetFixedImage(fixedImage);
>
>     registration->SetMovingImage(movingImage);
>
>     registration->SetFixedImageRegion(fixedImage->GetBufferedRegion());
>
>     registration->SetInitialTransformParameters(transform->GetParameters());
>
>     registration->Update();
>
>
>
>
>
> // Registration V4 ----------------------- :
>
>     auto metric =
> itk::MattesMutualInformationImageToImageMetricv4<ImageType,
> ImageType>::New();
>
>     auto optimizer = itk::RegularStepGradientDescentOptimizerv4::New();
>
>     auto registration = itk::ImageRegistrationMethodv4<ImageType,
> ImageType>::New();
>
>
>
>     optimizer->SetScales(scales);
>
>     optimizer->SetDoEstimateScales(false);
>
>     optimizer->SetDoEstimateLearningRateAtEachIteration(false);
>
>     optimizer->SetDoEstimateLearningRateOnce(false);
>
>     optimizer->SetMetric(metric);
>
>
>
>     registration->SetNumberOfLevels(1);
>
>     registration->SetSmoothingSigmasPerLevel(0);
>
>     registration->SetShrinkFactorsPerLevel(1);
>
>     registration->SetMetricSamplingPercentagePerLevel(0.1);
>
>
>
>     registration->SetMetric(metric);
>
>     registration->SetOptimizer(optimizer);
>
>     registration->SetFixedImage(fixedImage);
>
>     registration->SetMovingImage(movingImage);
>
>     registration->SetMetricSamplingStrategy(RegistrationType::REGULAR);
>
>     registration->SetInitialTransform(transform);
>
>
>
>     registration->Update();
>
>
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/insight-developers
>

From matt.mccormick at kitware.com  Tue Oct  4 12:01:52 2016
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Tue, 4 Oct 2016 12:01:52 -0400
Subject: [ITK-dev] ITK Confab Hangout Links
In-Reply-To: <1957E440-0637-4DE1-85DC-789BBDB15186@mail.nih.gov>
References: <CALzTN-S6W+YtQ+PFg6OiJu-_et5Mg9Z-n+Re1Xet+6xCFH_qvw@mail.gmail.com>
 <1957E440-0637-4DE1-85DC-789BBDB15186@mail.nih.gov>
Message-ID: <CALzTN-QAOvEwDjwT-fPy0RxVg7t07KB7645aZkg6Ar=D8w9y-A@mail.gmail.com>

On Tue, Oct 4, 2016 at 11:58 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C]
<blowekamp at mail.nih.gov> wrote:
> Subscribing to a calendar would work well for me too.

Great!


> So G+ with Hangout is being dropped, but support for Google Hangout is still good?

Right.


> What about keeping ITK release dates on there too? Maybe other import ITK events/dates there too?

Maybe we should have an ITK calendar?


M

From blowekamp at mail.nih.gov  Tue Oct  4 11:58:58 2016
From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C])
Date: Tue, 4 Oct 2016 15:58:58 +0000
Subject: [ITK-dev] ITK Confab Hangout Links
In-Reply-To: <CALzTN-S6W+YtQ+PFg6OiJu-_et5Mg9Z-n+Re1Xet+6xCFH_qvw@mail.gmail.com>
References: <CALzTN-S6W+YtQ+PFg6OiJu-_et5Mg9Z-n+Re1Xet+6xCFH_qvw@mail.gmail.com>
Message-ID: <1957E440-0637-4DE1-85DC-789BBDB15186@mail.nih.gov>

Subscribing to a calendar would work well for me too.

So G+ with Hangout is being dropped, but support for Google Hangout is still good?

What about keeping ITK release dates on there too? Maybe other import ITK events/dates there too?

Brad


> On Oct 4, 2016, at 11:52 AM, Matt McCormick <matt.mccormick at kitware.com> wrote:
> 
> Hi,
> 
> Chatting with Jc about the Slicer community's use of Hangout's, Google
> has now dropped support for G+ / Hangouts.
> 
> As suggested by Francois and Jc, I suggest we use a Google Calendar
> entry with a Hangout link, then make the entry publicly visible. We
> can publish a public hyperlink that people can use to join. This
> worked well for the Slicer community.
> 
> Thanks,
> Matt


From matt.mccormick at kitware.com  Tue Oct  4 12:34:16 2016
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Tue, 4 Oct 2016 12:34:16 -0400
Subject: [ITK-dev] ITK Confab Hangout Links
In-Reply-To: <CALzTN-QAOvEwDjwT-fPy0RxVg7t07KB7645aZkg6Ar=D8w9y-A@mail.gmail.com>
References: <CALzTN-S6W+YtQ+PFg6OiJu-_et5Mg9Z-n+Re1Xet+6xCFH_qvw@mail.gmail.com>
 <1957E440-0637-4DE1-85DC-789BBDB15186@mail.nih.gov>
 <CALzTN-QAOvEwDjwT-fPy0RxVg7t07KB7645aZkg6Ar=D8w9y-A@mail.gmail.com>
Message-ID: <CALzTN-TMVz6q=Opz_JUzxk_2WkfBTU_j6q1DEsLzEftqbGeVPw@mail.gmail.com>

On Tue, Oct 4, 2016 at 12:01 PM, Matt McCormick
<matt.mccormick at kitware.com> wrote:
> On Tue, Oct 4, 2016 at 11:58 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C]
> <blowekamp at mail.nih.gov> wrote:
>> Subscribing to a calendar would work well for me too.
>
> Great!
>
>
>> So G+ with Hangout is being dropped, but support for Google Hangout is still good?
>
> Right.
>
>
>> What about keeping ITK release dates on there too? Maybe other import ITK events/dates there too?
>
> Maybe we should have an ITK calendar?

Here it is:

  https://calendar.google.com/calendar/embed?src=jhm9h5t9un1gbm21jktej2qvh0%40group.calendar.google.com&ctz=America/New_York


I'll be out on vacation this week, and I will not be able to join on Friday.

Thanks,
Matt

From blowekamp at mail.nih.gov  Tue Oct  4 13:15:31 2016
From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C])
Date: Tue, 4 Oct 2016 17:15:31 +0000
Subject: [ITK-dev] ITK Confab Hangout Links
In-Reply-To: <CALzTN-QAOvEwDjwT-fPy0RxVg7t07KB7645aZkg6Ar=D8w9y-A@mail.gmail.com>
References: <CALzTN-S6W+YtQ+PFg6OiJu-_et5Mg9Z-n+Re1Xet+6xCFH_qvw@mail.gmail.com>
 <1957E440-0637-4DE1-85DC-789BBDB15186@mail.nih.gov>
 <CALzTN-QAOvEwDjwT-fPy0RxVg7t07KB7645aZkg6Ar=D8w9y-A@mail.gmail.com>
Message-ID: <527B62C0-B562-45B9-B414-C8E2F895D223@mail.nih.gov>


> On Oct 4, 2016, at 12:01 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:
> 
> On Tue, Oct 4, 2016 at 11:58 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C]
> <blowekamp at mail.nih.gov> wrote:
>> Subscribing to a calendar would work well for me too.
> 
> Great!
> 
> 
>> So G+ with Hangout is being dropped, but support for Google Hangout is still good?
> 
> Right.
> 
> 
>> What about keeping ITK release dates on there too? Maybe other import ITK events/dates there too?
> 
> Maybe we should have an ITK calendar?
> 
> 

Yes, what do you looks good. I thought that is what your initial proposal was :)

> M


From francois.budin at kitware.com  Thu Oct  6 17:43:55 2016
From: francois.budin at kitware.com (Francois Budin)
Date: Thu, 6 Oct 2016 17:43:55 -0400
Subject: [ITK-dev] [ANN] ITK 4.10.0 has been released!
Message-ID: <CAHwLD2X5XbGycZmtnfoZYibxPeiuZgHxF+X1W2UGN=KApn35hQ@mail.gmail.com>

On behalf of the Insight Toolkit Community, we are happy to announce the
release of ITK 4.10.1!

Release files can be downloaded from:

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

This is a patch release that fixes critical issues, regressions,
documentation, and compiler support. Of the numerous issues addressed in
this release, most notable is a fix to the ITK Python wrapping lazy
loading. This improves load times for many Python scripts by an order of
magnitude! Other important fixes include Python builds with GCC 6.2, which
defaults to C++14, TBB 4.4/VTK 7 compatibility, and CUDA / C++11
compatibility.

The next feature release, 4.11.0, is scheduled for mid-December.

Enjoy ITK!


Changes from v4.10.0 to v4.10.1:

Bradley Lowekamp (9):

     COMP: Address VS9 ambiguous std::abs call in Haung calculator

     COMP: Fix undefined NumericTraits::Zero and One errors with mingw64

     BUG: Address itkHDF5ImageIO test failures for mingw64

     ENH: Enable CMP0063 New behavior

     COMP: Enable hidden visibility property with vxl static libraries

    COMP: Enable hidden visibility property with HDF5 static libraries

     BUG: Match Add2 function to AddImageFilter documentation

     COMP: Bypass XCode 7.3,8 internal compilation error

     ENH: Separate TransformFactory class into separate module

D?enan Zuki? (2):

     COMP: enables TBB 4.4 back-end for VTK7's SMP

     BUG: fixing buffer growing endlessly, as reported by Timothee Evain

Francois Budin (3):

     BUG: lazyAttributes dictionary keys could be over-ridden

     BUG: Missing associated test data

     ENH: Bump CMakeLists.txt version to 4.10.1.

Gert Wollny (1):

     BUG: Relax vnl_complex floating point comparisons for i386

Hans Johnson (1):

     COMP: Add long long usage for HDF5

Hastings Greer (4):

     BUG: ITK-3448 Wrap itkQuadEdgeCellTraitsInfo more specifically

     BUG: remove lsqr because of license issues ITK 1160

     BUG: make itkTriangleHelper instantiable to ease wrapping

     BUG: initialize X to zero in lsmr Solve

Matthew McCormick (13):

     BUG: Fix H5File memory leak in HDF5ImageIO.

     BUG: Limit WRAP_ITK_MODULES when building externally

     COMP: Fix wrapping with a space in the Python include path

     BUG: ResampleImageFilter honor isInside output of the transform method

     COMP: Avoid recursive include of itkMath.h

     COMP: Use add_python_test PythonLazyLoadingImage

     BUG: Index,Size,Offset constructors present in Python with C++11

     COMP: Address missing override it itkFactoryTestLib.cxx

     BUG: Address memory leak, remove NumPy build dep in BridgeNumPy

     COMP: Do not set ITK_LIBRARY_BUILD_TYPE in ITKTransformFactory

     BUG: Check when ITK_WRAP_VECTOR_COMPONENTS doesn't include
ITK_WRAP_IMAGE_DIMS

     BUG: RichardsonLucyDeconvolutionImageFilter with non-null input Image
Origin

     BUG: Fix inconsistent Twister start with Initialize(seed) and
SetSeed(seed)

Pierre Barbier de Reuille (1):

     COMP: Fix function naming error when using FFTWD

Simon Rit (1):

     COMP: remove C++11 compiler warning for CUDA compilations

Vladimir S. FONOV (1):

     COMP: Build against GCC 5.3.1

Ziv Yaniv (1):
     BUG: Metric sampling percentage accepted values outside (0.0, 1.0].
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161006/dfb54f6a/attachment.html>

From matt.mccormick at kitware.com  Wed Oct 12 09:58:06 2016
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 12 Oct 2016 09:58:06 -0400
Subject: [ITK-dev] CDash submissions for 2016-10-12
Message-ID: <CALzTN-QgbCWToJKJ623Jxv7AkSO6xrXtnOL2+Q8+SxtyzTrFXQ@mail.gmail.com>

Hi folks,

FYI - open.cdash.org had a hiccup last night, which explains why all
submissions are not on the dashboard today. They are all expected to
return tomorrow.

Matt

From francois.budin at kitware.com  Sun Oct 16 21:49:51 2016
From: francois.budin at kitware.com (Francois Budin)
Date: Sun, 16 Oct 2016 21:49:51 -0400
Subject: [ITK-dev] BUILD_SHARED_LIBS vs ITK_BUILD_SHARED
Message-ID: <CAHwLD2V3FRXt_-v1eOob+Pd4BevDJ24k=46_XbpgOoMEdArneA@mail.gmail.com>

Hello fellow ITK developers,

I was having linking errors on Windows when compiling a project that was
using the CMake variable BUILD_SHARED_LIBS and setting it to ON when I had
compiled ITK with BUILD_SHARED_LIBS to OFF.
I realized that when ITK gets included and used and when the project using
ITK using the IO factory mechanism, UseITK.cmake uses the variable
BUILD_SHARED_LIBS to set some parameters. I was wondering if instead of
using BUILD_SHARED_LIBS which could have a different value in ITK and the
project I am trying to compile, UseITK.cmake should not use
ITK_BUILD_SHARED instead (which is set when ITK is configured). If I modify
UseITK.cmake to use ITK_BUILD_SHARED instead of BUILD_SHARED_LIBS, the
linking error I was having disappears. Is this a bug or is there a reason
behind that design?

Thanks,
Francois

[1]
https://github.com/InsightSoftwareConsortium/ITK/blob/master/CMake/UseITK.cmake#L201
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161016/31722a74/attachment.html>

From blowekamp at mail.nih.gov  Mon Oct 17 08:56:35 2016
From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C])
Date: Mon, 17 Oct 2016 12:56:35 +0000
Subject: [ITK-dev] BUILD_SHARED_LIBS vs ITK_BUILD_SHARED
In-Reply-To: <CAHwLD2V3FRXt_-v1eOob+Pd4BevDJ24k=46_XbpgOoMEdArneA@mail.gmail.com>
References: <CAHwLD2V3FRXt_-v1eOob+Pd4BevDJ24k=46_XbpgOoMEdArneA@mail.gmail.com>
Message-ID: <87193762-E7B5-4B00-9F88-240D2EB0FBB0@mail.nih.gov>

Looks like a bug to me. This is relatively new code too [1].

You proposal sounds good to me too.

Brad

[1] https://github.com/InsightSoftwareConsortium/ITK/commit/1000370eec20511850c543cb3c02aa5118563ccc



On Oct 16, 2016, at 9:49 PM, Francois Budin <francois.budin at kitware.com<mailto:francois.budin at kitware.com>> wrote:

Hello fellow ITK developers,

I was having linking errors on Windows when compiling a project that was using the CMake variable BUILD_SHARED_LIBS and setting it to ON when I had compiled ITK with BUILD_SHARED_LIBS to OFF.
I realized that when ITK gets included and used and when the project using ITK using the IO factory mechanism, UseITK.cmake uses the variable BUILD_SHARED_LIBS to set some parameters. I was wondering if instead of using BUILD_SHARED_LIBS which could have a different value in ITK and the project I am trying to compile, UseITK.cmake should not use ITK_BUILD_SHARED instead (which is set when ITK is configured). If I modify UseITK.cmake to use ITK_BUILD_SHARED instead of BUILD_SHARED_LIBS, the linking error I was having disappears. Is this a bug or is there a reason behind that design?

Thanks,
Francois

[1] https://github.com/InsightSoftwareConsortium/ITK/blob/master/CMake/UseITK.cmake#L201
_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161017/10cf9466/attachment.html>

From matt.mccormick at kitware.com  Mon Oct 17 09:57:58 2016
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Mon, 17 Oct 2016 09:57:58 -0400
Subject: [ITK-dev] BUILD_SHARED_LIBS vs ITK_BUILD_SHARED
In-Reply-To: <87193762-E7B5-4B00-9F88-240D2EB0FBB0@mail.nih.gov>
References: <CAHwLD2V3FRXt_-v1eOob+Pd4BevDJ24k=46_XbpgOoMEdArneA@mail.gmail.com>
 <87193762-E7B5-4B00-9F88-240D2EB0FBB0@mail.nih.gov>
Message-ID: <CALzTN-Tstpa-7fJXi+TLZQ_DN8-G5rg5+9Vu=LkFVG4iQ3EbMg@mail.gmail.com>

Hi Francois,

Good observation. Yes, UseITK.cmake should be using ITK_BUILD_SHARED
from ITKConfig.cmake for ITK library build settings here [1].

Thanks,
Matt

[1] https://github.com/InsightSoftwareConsortium/ITK/blob/master/CMake/UseITK.cmake#L201




On Mon, Oct 17, 2016 at 8:56 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C]
<blowekamp at mail.nih.gov> wrote:
> Looks like a bug to me. This is relatively new code too [1].
>
> You proposal sounds good to me too.
>
> Brad
>
> [1]
> https://github.com/InsightSoftwareConsortium/ITK/commit/1000370eec20511850c543cb3c02aa5118563ccc
>
>
>
>
> On Oct 16, 2016, at 9:49 PM, Francois Budin <francois.budin at kitware.com>
> wrote:
>
> Hello fellow ITK developers,
>
> I was having linking errors on Windows when compiling a project that was
> using the CMake variable BUILD_SHARED_LIBS and setting it to ON when I had
> compiled ITK with BUILD_SHARED_LIBS to OFF.
> I realized that when ITK gets included and used and when the project using
> ITK using the IO factory mechanism, UseITK.cmake uses the variable
> BUILD_SHARED_LIBS to set some parameters. I was wondering if instead of
> using BUILD_SHARED_LIBS which could have a different value in ITK and the
> project I am trying to compile, UseITK.cmake should not use ITK_BUILD_SHARED
> instead (which is set when ITK is configured). If I modify UseITK.cmake to
> use ITK_BUILD_SHARED instead of BUILD_SHARED_LIBS, the linking error I was
> having disappears. Is this a bug or is there a reason behind that design?
>
> Thanks,
> Francois
>
> [1]
> https://github.com/InsightSoftwareConsortium/ITK/blob/master/CMake/UseITK.cmake#L201
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/insight-developers
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/insight-developers
>

From seun at rogue-research.com  Fri Oct 21 08:50:11 2016
From: seun at rogue-research.com (Seun Odutola)
Date: Fri, 21 Oct 2016 08:50:11 -0400
Subject: [ITK-dev] H5pubconf.h missing during installation (ITK master)
Message-ID: <A215321D-686B-495A-ACC1-161A9C6DC9CA@rogue-research.com>

Hello everyone,

   I recently tried to update my ITK to the latest on master and stumbled upon an error during installation - ?H5pubconf.h file not found?. The file H5pubconf.h is being included in H5public.h found in "include/ITK-4.11/itkhdf5/", although H5pubconf.h is present in the "/Modules/ThirdParty/HDF5/src/itkhdf5/? it's somehow missing during installation so I decided to copy H5pubconf.h over to the directory ?itkhdf5? where H5public.h was situated and on building my project it worked. I just thought I mention this and hopefully it gets fixed as it seems to be an installation bug.

Regards,
   Seun

From seun at rogue-research.com  Fri Oct 21 09:24:54 2016
From: seun at rogue-research.com (Seun Odutola)
Date: Fri, 21 Oct 2016 09:24:54 -0400
Subject: [ITK-dev] Naming inconsistency in ITK HDF5 lib in Debug and Release
Message-ID: <788B9F09-C262-4128-B711-6F6483C5A3BE@rogue-research.com>

Hello,

   I'm currently trying out the latest on ITK master and on successfully building/ installing and compiling my project (see my other post on "H5pubconf.h missing during installation (ITK master)?) all seems to work but only after a slight tweak. The tweak was necessary because I realised that the generated lib for hdf5 in both debug and release mode were named differently compared to the other libs. In Debug, all libs are named accordingly libITK... or libitk? ending with .a except that of libitkhdf5_cpp_debug.a & libitkhdf5_debug.a, whereas in Release it?s not the case as they are named libitkhdf5_cpp.a & libitkhdf5.a. It?s worth mentioning that the latter was how the libs were named prior to me updating my ITK to 4.11 (on master) which made linking against these libs easier in my case as I had only to provide the names in my configuration file without having to distinguish between debug or release. In a nutshell, why is this the case with HDF5, is this another one of ITK installation bugs or is this deliberate for some reason if so can someone explain why, thanks.

Regards,
  Seun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161021/2a9e5ca2/attachment.html>

From matt.mccormick at kitware.com  Fri Oct 21 16:25:33 2016
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Fri, 21 Oct 2016 16:25:33 -0400
Subject: [ITK-dev] H5pubconf.h missing during installation (ITK master)
In-Reply-To: <A215321D-686B-495A-ACC1-161A9C6DC9CA@rogue-research.com>
References: <A215321D-686B-495A-ACC1-161A9C6DC9CA@rogue-research.com>
Message-ID: <CALzTN-TxiNZ8JfmWm7-69Xp8cD1J-RnbZr2exy9NaXxWLKY+fQ@mail.gmail.com>

Hi Sean,

Thanks for reporting the issue.  Please review this patch:

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

Thanks,
Matt

On Fri, Oct 21, 2016 at 8:50 AM, Seun Odutola <seun at rogue-research.com> wrote:
> Hello everyone,
>
>    I recently tried to update my ITK to the latest on master and stumbled upon an error during installation - ?H5pubconf.h file not found?. The file H5pubconf.h is being included in H5public.h found in "include/ITK-4.11/itkhdf5/", although H5pubconf.h is present in the "/Modules/ThirdParty/HDF5/src/itkhdf5/? it's somehow missing during installation so I decided to copy H5pubconf.h over to the directory ?itkhdf5? where H5public.h was situated and on building my project it worked. I just thought I mention this and hopefully it gets fixed as it seems to be an installation bug.
>
> Regards,
>    Seun
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/insight-developers

From matt.mccormick at kitware.com  Fri Oct 21 16:27:31 2016
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Fri, 21 Oct 2016 16:27:31 -0400
Subject: [ITK-dev] Naming inconsistency in ITK HDF5 lib in Debug and
	Release
In-Reply-To: <788B9F09-C262-4128-B711-6F6483C5A3BE@rogue-research.com>
References: <788B9F09-C262-4128-B711-6F6483C5A3BE@rogue-research.com>
Message-ID: <CALzTN-Top7WKnWf_rEX9jgKwXdHTp=YCfkFZwz4eDczbd-5QRA@mail.gmail.com>

Hi Seun,

In ITK 4.11 (master), we upgraded the internal version of HDF5 to
1.8.17, and the library name change was something that was done in
upstream HDF5.

HTH,
Matt

On Fri, Oct 21, 2016 at 9:24 AM, Seun Odutola <seun at rogue-research.com> wrote:
> Hello,
>
>    I'm currently trying out the latest on ITK master and on successfully
> building/ installing and compiling my project (see my other post on
> "H5pubconf.h missing during installation (ITK master)?) all seems to work
> but only after a slight tweak. The tweak was necessary because I realised
> that the generated lib for hdf5 in both debug and release mode were named
> differently compared to the other libs. In Debug, all libs are named
> accordingly libITK... or libitk? ending with .a except that of
> libitkhdf5_cpp_debug.a & libitkhdf5_debug.a, whereas in Release it?s not the
> case as they are named libitkhdf5_cpp.a & libitkhdf5.a. It?s worth
> mentioning that the latter was how the libs were named prior to me updating
> my ITK to 4.11 (on master) which made linking against these libs easier in
> my case as I had only to provide the names in my configuration file without
> having to distinguish between debug or release. In a nutshell, why is this
> the case with HDF5, is this another one of ITK installation bugs or is this
> deliberate for some reason if so can someone explain why, thanks.
>
> Regards,
>   Seun
>
> _______________________________________________
> 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 johannes.keustermans at gmail.com  Tue Oct 25 08:39:50 2016
From: johannes.keustermans at gmail.com (Johannes Keustermans)
Date: Tue, 25 Oct 2016 14:39:50 +0200
Subject: [ITK-dev] description AdaptiveHistogramEqualizationImageFilter
Message-ID: <011901d22ebc$e0dd8930$a2989b90$@gmail.com>

Dear all,

 

 

The description of the AdaptiveHistogramEqualizationImageFilter is not
entirely correct in my (humble) opinion. From the description it seems that
the filter, depending on the parameter alpha, ranges from standard histogram
equalization (alpha = 0) to unsharp masking (alpha = 1). However, from the
paper and the implementation, the parameter alpha is used to steer between
standard histogram equalization and local mean subtraction. The rationale
for this connection is due to the fact that local mean subtraction is an
approximation for histogram equalization with a strongly gaussian smoothed
histogram. The parameter beta controls the level of local mean addition.

 

 

Kind regards,

Johannes Keustermans

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

From dzenanz at gmail.com  Tue Oct 25 09:57:47 2016
From: dzenanz at gmail.com (=?UTF-8?B?RMW+ZW5hbiBadWtpxIc=?=)
Date: Tue, 25 Oct 2016 09:57:47 -0400
Subject: [ITK-dev] [ITK] description
	AdaptiveHistogramEqualizationImageFilter
In-Reply-To: <011901d22ebc$e0dd8930$a2989b90$@gmail.com>
References: <011901d22ebc$e0dd8930$a2989b90$@gmail.com>
Message-ID: <CAPf2UMSnTXv_x6amuxEJdHHeEaSOJHx+91aL1oK0j3bLaBd59Q@mail.gmail.com>

Dear Johannes,

this is an excellent opportunity to contribute to ITK by improving the
documentation! Following these instructions
<https://itk.org/Wiki/ITK/Git/Develop>, modify the comments
<https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/ImageStatistics/include/itkAdaptiveHistogramEqualizationImageFilter.h#L27-L69>
before the filter declaration and submit a patch to Gerrit code review
system. Add a few active participants of the list as reviewers.

Regards,
D?enan

On Tue, Oct 25, 2016 at 8:39 AM, Johannes Keustermans <
johannes.keustermans at gmail.com> wrote:

> Dear all,
>
>
>
>
>
> The description of the AdaptiveHistogramEqualizationImageFilter is not
> entirely correct in my (humble) opinion. From the description it seems that
> the filter, depending on the parameter alpha, ranges from standard
> histogram equalization (alpha = 0) to unsharp masking (alpha = 1). However,
> from the paper and the implementation, the parameter alpha is used to steer
> between standard histogram equalization and local mean subtraction. The
> rationale for this connection is due to the fact that local mean
> subtraction is an approximation for histogram equalization with a strongly
> gaussian smoothed histogram. The parameter beta controls the level of local
> mean addition.
>
>
>
>
>
> Kind regards,
>
> Johannes Keustermans
>
> _______________________________________________
> 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/20161025/f13d9b6a/attachment.html>

From blowekamp at mail.nih.gov  Fri Oct 28 10:46:08 2016
From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C])
Date: Fri, 28 Oct 2016 14:46:08 +0000
Subject: [ITK-dev] Problem with ImageRegistrationMethodv4 and setting the
	VirtualDomain
Message-ID: <C6B78FD9-0FF3-497F-AB8C-2CF47747EB5D@mail.nih.gov>

Hi!

I am trying to add the VirtualDomain as an option to the SimpleITK ImageRegistrationMethod. I have does so here [1].

This method for setting the virtual domain follows the SimpleImageRegistrationTest / Example by setting the VirtualDomain on the Metric[2].

The test created in SimpleITK registers two gaussian blobs with a translation transform. The fixed image has it?s origin set to (5,100), and the FixedInitalTransform is set to a translation transform with the same 5,100 offset. This should map the 0-origined virtual domain to the same index on the fixed image, to essentially be an identity translation between then virtual domain and the fixed image when the origin and transform is take into consideration. This test fails with the following error:

MeanSquaresImageToImageMetricv4 (0x66f8930): No valid points were found during metric evaluation. For image metrics, verify that the images overlap appropriately. For instance, you can align the image centers by translation. For point-set metrics, verify that the fixed points, once transformed into the virtual domain space, actually lie within the virtual domain.

This is an indication the transforms are not being applied as I expect. My expectation of how the transforms should be applied here [3].

Digging into the code, I see that the ImageRegistrationMethod always sets the VirtualDomain here [4], to the FixedImage. This clobbers the value set directly to the Metric as in the example/test[2]. Hacking the code to use the GetCurrentLevelVirtualDomainImage() does get my one case to work.

Suggestions on how to correct this issue, or a patch are welcomed!

Thanks,
Brad


[1] http://review.source.kitware.com/#/c/21540/2
[2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Registration/RegistrationMethodsv4/test/itkSimpleImageRegistrationTest.cxx#L162
[3] http://insightsoftwareconsortium.github.io/SimpleITK-Notebooks/61_Registration_Introduction_Continued.html#Version-1.1
[4] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Registration/RegistrationMethodsv4/include/itkImageRegistrationMethodv4.hxx#L409-L415
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161028/8e78435c/attachment.html>

From ntustison at gmail.com  Fri Oct 28 11:48:43 2016
From: ntustison at gmail.com (Nicholas Tustison)
Date: Fri, 28 Oct 2016 08:48:43 -0700
Subject: [ITK-dev] Problem with ImageRegistrationMethodv4 and setting
 the VirtualDomain
In-Reply-To: <C6B78FD9-0FF3-497F-AB8C-2CF47747EB5D@mail.nih.gov>
References: <C6B78FD9-0FF3-497F-AB8C-2CF47747EB5D@mail.nih.gov>
Message-ID: <5456BF25-2B4A-4B8A-95D5-9664869D30E0@gmail.com>

Hi Brad,

Thanks for looking into this.  Although specific components of the registration
framework were designed to work with a generic virtual domain image (such 
as the similarity metrics), that?s not the case for the framework in it?s entirety. 
When we wrote the image registration methods, we hard-coded various 
choices such as the use of the fixed image as the virtual domain image.  More
work would be required to generalize this.

Nick


> On Oct 28, 2016, at 7:46 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] <blowekamp at mail.nih.gov> wrote:
> 
> Hi!
> 
> I am trying to add the VirtualDomain as an option to the SimpleITK ImageRegistrationMethod. I have does so here [1].
> 
> This method for setting the virtual domain follows the SimpleImageRegistrationTest / Example by setting the VirtualDomain on the Metric[2].
> 
> The test created in SimpleITK registers two gaussian blobs with a translation transform. The fixed image has it?s origin set to (5,100), and the FixedInitalTransform is set to a translation transform with the same 5,100 offset. This should map the 0-origined virtual domain to the same index on the fixed image, to essentially be an identity translation between then virtual domain and the fixed image when the origin and transform is take into consideration. This test fails with the following error:
> 
> MeanSquaresImageToImageMetricv4 (0x66f8930): No valid points were found during metric evaluation. For image metrics, verify that the images overlap appropriately. For instance, you can align the image centers by translation. For point-set metrics, verify that the fixed points, once transformed into the virtual domain space, actually lie within the virtual domain.
> 
> This is an indication the transforms are not being applied as I expect. My expectation of how the transforms should be applied here [3].
> 
> Digging into the code, I see that the ImageRegistrationMethod always sets the VirtualDomain here [4], to the FixedImage. This clobbers the value set directly to the Metric as in the example/test[2]. Hacking the code to use the GetCurrentLevelVirtualDomainImage() does get my one case to work.
> 
> Suggestions on how to correct this issue, or a patch are welcomed!
> 
> Thanks,
> Brad
> 
> 
> [1] http://review.source.kitware.com/#/c/21540/2 <http://review.source.kitware.com/#/c/21540/2>
> [2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Registration/RegistrationMethodsv4/test/itkSimpleImageRegistrationTest.cxx#L162 <https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Registration/RegistrationMethodsv4/test/itkSimpleImageRegistrationTest.cxx#L162>
> [3] http://insightsoftwareconsortium.github.io/SimpleITK-Notebooks/61_Registration_Introduction_Continued.html#Version-1.1 <http://insightsoftwareconsortium.github.io/SimpleITK-Notebooks/61_Registration_Introduction_Continued.html#Version-1.1>
> [4] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Registration/RegistrationMethodsv4/include/itkImageRegistrationMethodv4.hxx#L409-L415 <https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Registration/RegistrationMethodsv4/include/itkImageRegistrationMethodv4.hxx#L409-L415>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161028/a514f3ee/attachment.html>

From blowekamp at mail.nih.gov  Fri Oct 28 12:01:49 2016
From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C])
Date: Fri, 28 Oct 2016 16:01:49 +0000
Subject: [ITK-dev] Problem with ImageRegistrationMethodv4 and setting
 the VirtualDomain
In-Reply-To: <5456BF25-2B4A-4B8A-95D5-9664869D30E0@gmail.com>
References: <C6B78FD9-0FF3-497F-AB8C-2CF47747EB5D@mail.nih.gov>
 <5456BF25-2B4A-4B8A-95D5-9664869D30E0@gmail.com>
Message-ID: <B97959B9-29EF-420D-AE2A-17D592DFC666@mail.nih.gov>

Interesting. But the InitialFixedTransform is made available. I am not sure how that could be used with out the virtual domain.

After looking at it a bit more it doesn?t look too hard. Here is my attempt at it:
http://review.source.kitware.com/#/c/21675/1

Please let know know if this is close to a usable solution.

Thanks,
Brad

On Oct 28, 2016, at 11:48 AM, Nicholas Tustison <ntustison at gmail.com<mailto:ntustison at gmail.com>> wrote:

Hi Brad,

Thanks for looking into this.  Although specific components of the registration
framework were designed to work with a generic virtual domain image (such
as the similarity metrics), that?s not the case for the framework in it?s entirety.
When we wrote the image registration methods, we hard-coded various
choices such as the use of the fixed image as the virtual domain image.  More
work would be required to generalize this.

Nick


On Oct 28, 2016, at 7:46 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] <blowekamp at mail.nih.gov<mailto:blowekamp at mail.nih.gov>> wrote:

Hi!

I am trying to add the VirtualDomain as an option to the SimpleITK ImageRegistrationMethod. I have does so here [1].

This method for setting the virtual domain follows the SimpleImageRegistrationTest / Example by setting the VirtualDomain on the Metric[2].

The test created in SimpleITK registers two gaussian blobs with a translation transform. The fixed image has it?s origin set to (5,100), and the FixedInitalTransform is set to a translation transform with the same 5,100 offset. This should map the 0-origined virtual domain to the same index on the fixed image, to essentially be an identity translation between then virtual domain and the fixed image when the origin and transform is take into consideration. This test fails with the following error:

MeanSquaresImageToImageMetricv4 (0x66f8930): No valid points were found during metric evaluation. For image metrics, verify that the images overlap appropriately. For instance, you can align the image centers by translation. For point-set metrics, verify that the fixed points, once transformed into the virtual domain space, actually lie within the virtual domain.

This is an indication the transforms are not being applied as I expect. My expectation of how the transforms should be applied here [3].

Digging into the code, I see that the ImageRegistrationMethod always sets the VirtualDomain here [4], to the FixedImage. This clobbers the value set directly to the Metric as in the example/test[2]. Hacking the code to use the GetCurrentLevelVirtualDomainImage() does get my one case to work.

Suggestions on how to correct this issue, or a patch are welcomed!

Thanks,
Brad


[1] http://review.source.kitware.com/#/c/21540/2
[2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Registration/RegistrationMethodsv4/test/itkSimpleImageRegistrationTest.cxx#L162
[3] http://insightsoftwareconsortium.github.io/SimpleITK-Notebooks/61_Registration_Introduction_Continued.html#Version-1.1
[4] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Registration/RegistrationMethodsv4/include/itkImageRegistrationMethodv4.hxx#L409-L415


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161028/432653cd/attachment.html>

From ntustison at gmail.com  Fri Oct 28 12:45:24 2016
From: ntustison at gmail.com (Nicholas Tustison)
Date: Fri, 28 Oct 2016 09:45:24 -0700
Subject: [ITK-dev] Problem with ImageRegistrationMethodv4 and setting
 the VirtualDomain
In-Reply-To: <B97959B9-29EF-420D-AE2A-17D592DFC666@mail.nih.gov>
References: <C6B78FD9-0FF3-497F-AB8C-2CF47747EB5D@mail.nih.gov>
 <5456BF25-2B4A-4B8A-95D5-9664869D30E0@gmail.com>
 <B97959B9-29EF-420D-AE2A-17D592DFC666@mail.nih.gov>
Message-ID: <BA7B9E7C-2380-4D39-AE6E-F7F345557907@gmail.com>

You?re right in that the FIxedInitialTransform is available but it could?ve simply
been an oversight on my part.  I know I tried to keep the class as general as
possible while knowing that actually exercising the virtual domain image as 
anything other than the fixed image would take more work.  I can?t remember
exactly.  The problem is that I?ve made so many significant changes to that 
class (e.g., point sets, multiple metrics, accommodating changes to the specialized
ImageRegistrationMethods), that I can?t quite remember how it has evolved 
to its current state.

At first glance, your fix looks fine to me.   It passes all the tests and so I?m 
guessing we should merge and I?ll see if ANTs has any associated hiccups
which I?m sure we can easily fix.



> On Oct 28, 2016, at 9:01 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] <blowekamp at mail.nih.gov> wrote:
> 
> Interesting. But the InitialFixedTransform is made available. I am not sure how that could be used with out the virtual domain.
> 
> After looking at it a bit more it doesn?t look too hard. Here is my attempt at it:
> http://review.source.kitware.com/#/c/21675/1 <http://review.source.kitware.com/#/c/21675/1>
> 
> Please let know know if this is close to a usable solution.
> 
> Thanks,
> Brad
> 
>> On Oct 28, 2016, at 11:48 AM, Nicholas Tustison <ntustison at gmail.com <mailto:ntustison at gmail.com>> wrote:
>> 
>> Hi Brad,
>> 
>> Thanks for looking into this.  Although specific components of the registration
>> framework were designed to work with a generic virtual domain image (such 
>> as the similarity metrics), that?s not the case for the framework in it?s entirety. 
>> When we wrote the image registration methods, we hard-coded various 
>> choices such as the use of the fixed image as the virtual domain image.  More
>> work would be required to generalize this.
>> 
>> Nick
>> 
>> 
>>> On Oct 28, 2016, at 7:46 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] <blowekamp at mail.nih.gov <mailto:blowekamp at mail.nih.gov>> wrote:
>>> 
>>> Hi!
>>> 
>>> I am trying to add the VirtualDomain as an option to the SimpleITK ImageRegistrationMethod. I have does so here [1].
>>> 
>>> This method for setting the virtual domain follows the SimpleImageRegistrationTest / Example by setting the VirtualDomain on the Metric[2].
>>> 
>>> The test created in SimpleITK registers two gaussian blobs with a translation transform. The fixed image has it?s origin set to (5,100), and the FixedInitalTransform is set to a translation transform with the same 5,100 offset. This should map the 0-origined virtual domain to the same index on the fixed image, to essentially be an identity translation between then virtual domain and the fixed image when the origin and transform is take into consideration. This test fails with the following error:
>>> 
>>> MeanSquaresImageToImageMetricv4 (0x66f8930): No valid points were found during metric evaluation. For image metrics, verify that the images overlap appropriately. For instance, you can align the image centers by translation. For point-set metrics, verify that the fixed points, once transformed into the virtual domain space, actually lie within the virtual domain.
>>> 
>>> This is an indication the transforms are not being applied as I expect. My expectation of how the transforms should be applied here [3].
>>> 
>>> Digging into the code, I see that the ImageRegistrationMethod always sets the VirtualDomain here [4], to the FixedImage. This clobbers the value set directly to the Metric as in the example/test[2]. Hacking the code to use the GetCurrentLevelVirtualDomainImage() does get my one case to work.
>>> 
>>> Suggestions on how to correct this issue, or a patch are welcomed!
>>> 
>>> Thanks,
>>> Brad
>>> 
>>> 
>>> [1] http://review.source.kitware.com/#/c/21540/2 <http://review.source.kitware.com/#/c/21540/2>
>>> [2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Registration/RegistrationMethodsv4/test/itkSimpleImageRegistrationTest.cxx#L162 <https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Registration/RegistrationMethodsv4/test/itkSimpleImageRegistrationTest.cxx#L162>
>>> [3] http://insightsoftwareconsortium.github.io/SimpleITK-Notebooks/61_Registration_Introduction_Continued.html#Version-1.1 <http://insightsoftwareconsortium.github.io/SimpleITK-Notebooks/61_Registration_Introduction_Continued.html#Version-1.1>
>>> [4] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Registration/RegistrationMethodsv4/include/itkImageRegistrationMethodv4.hxx#L409-L415 <https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Registration/RegistrationMethodsv4/include/itkImageRegistrationMethodv4.hxx#L409-L415>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161028/59b5605d/attachment.html>

From blowekamp at mail.nih.gov  Mon Oct 31 10:41:00 2016
From: blowekamp at mail.nih.gov (Lowekamp, Bradley (NIH/NLM/LHC) [C])
Date: Mon, 31 Oct 2016 14:41:00 +0000
Subject: [ITK-dev] BSpline transform IO and spline order problems
Message-ID: <0F6D6272-122C-489A-ADBF-CAA200BCF35E@mail.nih.gov>

Hello,

I recently discovered that the BSpline transforms are not serializing the order of the spline. The ITK BSplineTransform class[1] is templated over the dimension and the bspline ORDER not the output dimension (like nearly every other transform).

Currently the following strings are in the Transform factory and in ITK transform files:

"BSplineTransform_double_2_2"
?BSplineTransform_double_3_3"

"BSplineTransform_float_2_2"
?BSplineTransform_float_3_3"


The 3D one correctly get loaded as a order 3 spline but the 2D BSplineTransform get loaded with order 2!!!

I believe this a a bug, as the default template parameter for the order is 3, and that is the order almost always used.


I have a patch here to address these issue[2].


So the questions for discussions:

1) Should we correct the behavior and have the string: ?BSplineTransform_double_2_2? create a BSplineTransform<2,Order=3> now?
2) Should be keep writing these strings for order 3 splines? Order just use the new string with the addition of order? i.e. ?BSplineTransform_double_2_2_3"


Brad

[1] https://itk.org/Doxygen/html/classitk_1_1BSplineTransform.html
[2] http://review.source.kitware.com/#/c/21677/

From mmskeen at gmail.com  Sat Oct 15 16:39:20 2016
From: mmskeen at gmail.com (Michael Skeen)
Date: Sat, 15 Oct 2016 20:39:20 -0000
Subject: [ITK-dev] ITK Architectural Patterns & Quality Attributes for
	Research
Message-ID: <CAAqp00Qm0C=RgTMDBy_DfVi6yD3ZE6hE=gmi3Aje+ytJbgRptQ@mail.gmail.com>

Hello ITK Community,


I am part of an undergraduate research group focusing on software
architecture patterns and quality attributes at Utah Valley University. We
recently analyzed the work published on ITK in the Architecture of Open
Source Applications <http://aosabook.org/en/index.html> (AOSA) and
referenced it in a paper we presented at the 13th Working IEEE/IFIP
Conference on Software Architecture (WICSA), as attached.  As a part of our
continuing research we wish to validate our architectural analysis for ITK with
the current developers.


We would like to know if we are missing any patterns or quality attributes
that may have been included in ITK, or if there are any we listed that
aren?t used. Any additional comment on these topics you might have would
also, of course, be welcome.


We believe we found the following software architectural patterns in this
application:


* Pattern Name | Is This Found in the Architecture? (yes / no / don't know)
| Comments (optional)*

Pipes & Filters Plugin

Other?


We also identified the following quality attributes:


* Attribute Name | Is This Found in the Architecture? | Comments (optional)*

Usability Extensibility Flexibility Maintainability Testability

Other?


For your convenience, we have a complete list below of the patterns and
quality attributes we referred to when conducting our research. To clarify,
we are specifically studying architectural patterns, rather than design
patterns such as the GoF patterns.


Architectural Patterns Considered

Quality Attributes Considered

Active Repository

Scalability

Batch

Usability

Blackboard

Extensibility

Broker

Performance

Client Server

Portability

Event System

Flexibility

Explicit Invocation

Reliability

Implicit Invocation

Maintainability

Indirection Layer

Security

Interceptor

Testability

Interpreter

Capacity

Layers

Cost

Master and Commander

Legality

Microkernel

Modularity

Model View Controller

Robustness

Peer to Peer


Pipes and Filters


Plugin


Presentation Abstraction Control


Publish Subscribe


Reflection


Rule-Based System


Shared Repository


Simple Repository


State Based


Virtual Machine



Please respond by October 25th, if possible.

Thank you for considering our request, and for your continued work on ITK.


Sincerely,


Michael Skeen, with

Erich Gubler,

Danielle Skinner,

Brandon Leishman,

Neil Harrison, Ph.D. (advisor)


Reference: Neil B. Harrison, Erich Gubler, Danielle Skinner, "Software
Architecture Pattern Morphology in Open-Source Systems",WICSA, 2016, 2016
13th Working IEEE/IFIP Conference on Software Architecture (WICSA), 2016
13th Working IEEE/IFIP Conference on Software Architecture (WICSA) 2016,
pp. 91-98, doi:10.1109/WICSA.2016.8
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161015/fad6e22d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PID4110571 (Morphology).pdf
Type: application/pdf
Size: 231943 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20161015/fad6e22d/attachment-0001.pdf>