[Insight-developers] ITKv4: Features vs Clean up
Williams, Norman K
norman-k-williams at uiowa.edu
Tue Jul 12 10:53:31 EDT 2011
And if you have a test that SHOULD work as written in ITK3 and ITK4
consider adding it to the patch and resolving the error.
If you have developer access to the ITK Gerrit, you can download a patch,
modify it and push it back up yourself -- you don't have to be the author.
OTOH this should only be done in a case like this, not a case where people
are uploading dueling patches.
On 7/12/11 9:36 AM, "David Cole" <david.cole at kitware.com> wrote:
>On Tue, Jul 12, 2011 at 7:55 AM, Rupert Brooks <rupert.brooks at gmail.com>
>wrote:
>> Hi Nick
>>
>> Im trying to review this change:
>>http://review.source.kitware.com/#change,1856
>>
>> I wrote my own test and am comparing the results in ITK 3, ITK 4
>> master and your branch. In the comments, you mentioned some slides
>> or a migration document for the API changes - could i see that
>> document? Or - more to the point - how do you set the grid size in
>> the new Transform Initializer API. Thats what i cant figure out.
>>
>> Interestingly, my test works in ITK3, but segfaults in ITK4 - master
>> so i think there may have been a regression before your branch. I am
>> still working to understand it. For general interest my test code
>> follows.
>>
>> Also - should i add myself as a reviewer to the change and comment
>> there instead of in the list? It doesn't seem obvious to me how to
>> attach a comment directly on the change.
>
>For comments related to gerrit changes, please make them right in the
>gerrit review itself. Look for the "Review" button to make a general
>comment on the overall patch set. Double click on any line of source
>code while looking at a diff view to make an inline comment about a
>specific line of code.
>
>
>HTH,
>David
>
>
>>
>> Cheers
>>
>> Rupert
>>
>> #include <iostream>
>> #include <itkImage.h>
>> #include <itkBSplineDeformableTransformInitializer.h>
>> #include <itkBSplineDeformableTransform.h>
>>
>> template<class ImageType>
>> typename ImageType::PointType GetImageCorner(typename
>> ImageType::Pointer image, unsigned int c, int step=0) {
>> const unsigned int dim=ImageType::ImageDimension;
>> typename ImageType::SizeType
>>sz=image->GetLargestPossibleRegion().GetSize();
>> typename ImageType::IndexType cornerIndex;
>> for(unsigned int d=0;d<dim;++d) {
>> cornerIndex[d]=((c & d)>0)?(sz[d]-1-step):0+step;
>> }
>> typename ImageType::PointType p;
>> image->TransformIndexToPhysicalPoint(cornerIndex, p);
>> return p;
>> }
>>
>>
>> template<unsigned int dim, unsigned int order>
>> bool TestIt() {
>> std::cout << "A BSpline test with dimension " << dim << " order "
>> << order << std::endl;
>> typedef itk::Image<unsigned char, dim> ImageType;
>> typedef itk::BSplineDeformableTransform<double, dim, order>
>>TransformType;
>> typedef typename ImageType::SizeType SizeType;
>> typedef typename ImageType::IndexType IndexType;
>> typedef typename ImageType::PointType PointType;
>> typedef typename ImageType::SpacingType SpacingType;
>> typedef typename ImageType::RegionType RegionType;
>> typedef typename ImageType::DirectionType DirectionType;
>> typedef typename TransformType::ParametersType ParametersType;
>>
>> typedef
>>itk::BSplineDeformableTransformInitializer<TransformType,ImageType>
>> TransformInitializerType;
>>
>> typename ImageType::Pointer anImage=ImageType::New();
>> {
>> SizeType aSize;
>> PointType anOrigin;
>> SpacingType aSpacing;
>> for(unsigned int i=0;i<dim;++i) {aSize[i]=50+25*i;
>> anOrigin[i]=-11.1+5*i+double(i)/8;aSpacing=0.75+double(i)/8;}
>> // avoid zeros or equal sizes and spacings, just to be sure no
>> one mixed up...
>>
>> DirectionType aDirection;
>> aDirection.SetIdentity();
>> //Rotate a little around each dir
>>
>> IndexType aStart;aStart.Fill(0);
>> RegionType aRegion(aStart,aSize);
>> anImage->SetRegions(aRegion);
>> anImage->SetOrigin(anOrigin);
>> anImage->SetSpacing(aSpacing);
>> anImage->SetDirection(aDirection);
>> anImage->Allocate();
>> }
>>
>> typename TransformType::Pointer aTransform=TransformType::New();
>>
>> typename TransformInitializerType::Pointer
>> anInitializer=TransformInitializerType::New();
>> anInitializer->SetImage(anImage);
>> anInitializer->SetTransform(aTransform);
>> typename TransformInitializerType::TransformType::SizeType
>>aTransformSize;
>> for(unsigned int i=0;i<dim;++i) {aTransformSize[i]=3+i;}
>> anInitializer->SetGridSizeInsideTheImage(aTransformSize);
>> anInitializer->InitializeTransform();
>>
>> const unsigned int NP=aTransform->GetNumberOfParameters();
>> ParametersType p=aTransform->GetParameters();
>> std::cout << "Number of Transform Parameters: " << NP << std::endl;
>>
>> for(unsigned int np=0;np<NP/dim;++np) {
>> for(unsigned int d=0;d<dim;++d) {
>> p[np+d*NP]=5+double(np)/NP*dim;
>> }
>> }
>>
>>
>> /* this doesnt work in ITK3.20
>> // typename TransformType::CoefficientImageArray
>> coeff=aTransform->GetCoefficientImage();
>> typename TransformType::ImagePointer *
>> coeff=aTransform->GetCoefficientImage();
>> // Dump the positions of the grid points
>> for(unsigned int i=0;i<dim;++i) {
>> std::cout << "Positions of grid points along dimension " << i <<
>> std::endl;
>> PointType
>> p1=GetImageCorner<ImageType>(anImage,static_cast<unsigned
>> int>(0),false);
>> PointType
>> p2=GetImageCorner<ImageType>(anImage,static_cast<unsigned
>> int>(std::pow(2,i)), false );
>> std::cout << "ImageLimits: " << p1[i] << " -> " << p2[i] <<
>>std::endl;
>> typename TransformType::ImageType::Pointer im = coeff[i];
>> typename TransformType::ImageType::SizeType
>> sz=im->GetLargestPossibleRegion().GetSize();
>> typename TransformType::ImageType::IndexType ix; ix.Fill(0);
>> for(unsigned int j=0; j<sz[i];++j) {
>> ix[i]=j;
>> PointType p;
>> im->TransformIndexToPhysicalPoint(ix,p);
>> std::cout << " " << j << ": " << p;
>> }
>> std::cout << std::endl;
>> }
>> */
>> // Check the image corners - are they in or out.
>> unsigned int c=0;
>> unsigned int nbCorners=std::pow(2,dim);
>> while(c<nbCorners) {
>> SizeType sz=anImage->GetLargestPossibleRegion().GetSize();
>> PointType pin=GetImageCorner<ImageType>(anImage,c,1);
>> std::cout << "Origin: " << anImage->GetOrigin() << " point " <<
>> pin << std::endl;
>> // this segfaults in ITK master, why?
>> PointType tin=aTransform->TransformPoint(pin);
>> {
>> std::cout << "Corner " << c << " pin " << pin << " " << tin
>> << std::endl;
>> }
>> PointType pout=GetImageCorner<ImageType>(anImage,c,-1);
>> PointType tout=aTransform->TransformPoint(pout);
>> {
>> std::cout << "Corner " << c << " pout " << pout << " " <<
>> tout << std::endl;
>> }
>> c=c+1;
>> }
>>
>> return true;
>>
>> }
>>
>>
>> int main(int argc, char ** argv) {
>> //TestIt<2,1>();
>> TestIt<2,2>();
>> TestIt<2,3>();
>> TestIt<2,4>();
>> return EXIT_SUCCESS;
>> }
>> --------------------------------------------------------------
>> Rupert Brooks
>> rupert.brooks at gmail.com
>>
>>
>>
>>
>> On Thu, Jun 30, 2011 at 09:31, Nicholas Tustison <ntustison at gmail.com>
>>wrote:
>>> Hi Rupert,
>>>
>>> Much of the work is in the RegistrationRefactoring branch on github
>>> as mentioned. However, more-or-less self-encapsulated units are
>>> currently on gerrit and you're certainly welcome to review them. For
>>> example, some fundamental fixes to the B-spline deformable transform
>>> and initializer are proposed here
>>>
>>> http://review.source.kitware.com/#change,1856
>>>
>>> Additionally, a good chunk of the point set metric
>>>refactoring/enhancements
>>> are proposed here
>>>
>>> http://review.source.kitware.com/#change,1976
>>>
>>> I don't know if they fall within your interest but we're always
>>>looking for
>>> feedback.
>>>
>>> Nick
>>>
>>>
>>> On Jun 30, 2011, at 9:19 AM, Rupert Brooks wrote:
>>>
>>>> Procrastinate for two weeks. Absolutely ;-)
>>>>
>>>> The latter part of the email seems to suggest though that it might
>>>> help if i follow along during the process of putting the refactored
>>>> code into ITK4. I assume this would best be done via the Gerrit
>>>> review process. If i understand correctly, whats in
>>>> RegistrationRefactoring will soon be pushed to the ITKV4 master. Is
>>>> this the right way to proceed?
>>>>
>>>> Rupert
>>>>
>>>>
>>>> --------------------------------------------------------------
>>>> Rupert Brooks
>>>> rupert.brooks at gmail.com
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Jun 30, 2011 at 08:27, Johnson, Hans J
>>>><hans-johnson at uiowa.edu> wrote:
>>>>> Rupert and Brian,
>>>>>
>>>>> I have a proposal:
>>>>>
>>>>> Rupert: Would you be able to wait two weeks to do your review? We
>>>>>just
>>>>> finished our ITKv4 developers meeting, and there will be a lot of
>>>>>action
>>>>> in the next two weeks to bring this directly into ITKv4.
>>>>>
>>>>> Brian: Could we help get the current alpha pieces pushed into ITKv4
>>>>> proper?
>>>>>
>>>>> ==========================
>>>>> I am concerned about getting distracted from the primary goal of
>>>>>getting
>>>>> the registration into ITKv4 directly.
>>>>>
>>>>> Hans: I was planning to do extensive registration testing, and
>>>>>external
>>>>> tool code refactoring to match the ITKv4 registration framework
>>>>>during the
>>>>> second 1/2 of July. If Rupert and Hans could assist Brian's team in
>>>>> getting the source code moved and integrated with ITKv4 between now
>>>>>and
>>>>> July 15, then we will be more efficient in identifying use case
>>>>>problems
>>>>> related to algorithmic and api problems.
>>>>>
>>>>> Does this timeline work for the two of you?
>>>>>
>>>>> Hans
>>>>>
>>>>>
>>>>>
>>>>> On 6/30/11 7:12 AM, "Rupert Brooks" <rupert.brooks at gmail.com> wrote:
>>>>>
>>>>>> Hi Brian,
>>>>>>
>>>>>> This looks very interesting. I hope you dont mind a few questions.
>>>>>> If theres a written document to refer me to, feel free.
>>>>>>
>>>>>> I've been reading this:
>>>>>>
>>>>>>http://www.itk.org/Wiki/ITK_Release_4/Enhancing_Image_Registration_Fr
>>>>>>amewo
>>>>>> rk
>>>>>> but i have trouble mapping it to what i see in the GIT.
>>>>>>
>>>>>> I'm having some trouble identifying all the diffs between the
>>>>>> Registration branch and current ITK master, but it seems to me that
>>>>>> most is in Modules/Registration/Refactoring. Would that be the
>>>>>>case?
>>>>>> Is this ImageToObjectRegistration framework intended to replace one
>>>>>>or
>>>>>> more of the current Parametric / PDE / FEM registration frameworks,
>>>>>>or
>>>>>> to be in parallel with them. Or, to ask my question another way -
>>>>>>I
>>>>>> currently have some feedback / commentary regarding
>>>>>> itkOptimizer.h and its children...
>>>>>> itkCompositeTransform.txx
>>>>>> itkImageToImageMetric.txx
>>>>>> itkNormalizedCorrelationImageToImageMetric.txx
>>>>>> which are in Modules/Registration/Common
>>>>>>
>>>>>> Currently in RegistrationRefactoringNew these seem to be the same as
>>>>>> in master. Will the new refactored framework replace these classes,
>>>>>> so i shouldnt spend any time fiddling with them, or is it more or
>>>>>>less
>>>>>> independent.
>>>>>>
>>>>>> I've only had about half an hour to look at it, and i havent had
>>>>>>time
>>>>>> to compile it yet, so i may be about to embarrass myself with a
>>>>>>stupid
>>>>>> question. I'll ask anyway. A core fundamental refactoring -
>>>>>>looking
>>>>>> at the example you pointed me to - is that the update to the
>>>>>> parameters seems to have been pushed down all the way to the
>>>>>> transform, via the metric in the middle. This is a very interesting
>>>>>> choice - for transforms such as the versor transform, which must
>>>>>> remain on a manifold that doesnt embed well in Euclidean space, this
>>>>>> removes the constraint issue from the optimizer. However - it did
>>>>>>make
>>>>>> me wonder - what if i want to do anything other than gradient
>>>>>>descent?
>>>>>> Also, it seems to force the computation to complete an entire
>>>>>> computation of the gradient, and hold it in memory, even though for
>>>>>>a
>>>>>> local transform, it may be possible to perform the same update
>>>>>>without
>>>>>> ever actually creating the whole gradient object in memory at once?
>>>>>>
>>>>>> I saw tantalizing pieces of GPU registration code commented out. Is
>>>>>> that in process somewhere?
>>>>>>
>>>>>> In any case, i will spend more time on it which should hopefully
>>>>>>lead
>>>>>> to more intelligent commentary, over the weekend.
>>>>>>
>>>>>> Cheers,
>>>>>> Rupert
>>>>>> --------------------------------------------------------------
>>>>>> Rupert Brooks
>>>>>> rupert.brooks at gmail.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 29, 2011 at 21:13, brian avants <stnava at gmail.com>
>>>>>>wrote:
>>>>>>> rupert
>>>>>>>
>>>>>>> help is very welcome.
>>>>>>>
>>>>>>> refactored registration framework is here:
>>>>>>>
>>>>>>>
>>>>>>>https://github.com/picslITK/ITK4_topics/tree/RegistrationRefactoring
>>>>>>>New
>>>>>>>
>>>>>>> take a look at :
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>ITK4_topics/Modules/Registration/Refactoring/test/itkDemonsImageToIm
>>>>>>>ageOb
>>>>>>> jectRegistrationTest.cxx
>>>>>>>
>>>>>>> which gives an example of a demons registration run in the standard
>>>>>>> framework. the framework is changing, though, so realize what's
>>>>>>>there
>>>>>>> now is a mid-stream snapshot.
>>>>>>>
>>>>>>> brian
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jun 29, 2011 at 8:59 PM, Rupert Brooks
>>>>>>> <rupert.brooks at gmail.com> wrote:
>>>>>>>> Hi Luis and everyone,
>>>>>>>>
>>>>>>>> As a pretty heavy user of ITK, I'm interested in helping out as
>>>>>>>>well.
>>>>>>>> At the moment im working on some registration problems and im
>>>>>>>>trying
>>>>>>>> to explore the refactored registration framework in ITK 4.
>>>>>>>> As im going through the current master, im noticing various things
>>>>>>>> ranging from typos to classes that seem to have gotten left
>>>>>>>>behind to
>>>>>>>> questionable math. I'd be happy to give this information as
>>>>>>>>feedback
>>>>>>>> or fixes if its helpful.
>>>>>>>>
>>>>>>>> So question 1 - is the registration refactoring well represented
>>>>>>>>in
>>>>>>>> ITK master, or is there more work elsewhere? Is this the right
>>>>>>>>time
>>>>>>>> to review it from a user perspective or is it premature?
>>>>>>>>
>>>>>>>> Question 2 - whats the best way to proceed? Do i need to
>>>>>>>>configure
>>>>>>>> Gerrit access, etc as a developer to contribute to the textual
>>>>>>>>notes
>>>>>>>> you mentioned?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Rupert
>>>>>>>> --------------------------------------------------------------
>>>>>>>> Rupert Brooks
>>>>>>>> rupert.brooks at gmail.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jun 3, 2011 at 09:46, Luis Ibanez
>>>>>>>><luis.ibanez at kitware.com>
>>>>>>>> wrote:
>>>>>>>>> Hi Tom,
>>>>>>>>>
>>>>>>>>> Thanks for volunteering.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The plans for the global clean up are here:
>>>>>>>>> http://www.itk.org/Wiki/ITK_Release_4/Global_Code_Review
>>>>>>>>>
>>>>>>>>> The procedure is described here
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>http://www.itk.org/Wiki/ITK_Release_4/Modularization/Code_Reviews/
>>>>>>>>>Proce
>>>>>>>>> ss#Git-Based
>>>>>>>>>
>>>>>>>>> Essentially:
>>>>>>>>>
>>>>>>>>> We have a duplicate Git repository
>>>>>>>>>
>>>>>>>>>https://github.com/InsightSoftwareConsortium/itk-retroactive-revie
>>>>>>>>>w
>>>>>>>>>
>>>>>>>>> that contains a .txt file for every source code file in ITK.
>>>>>>>>>
>>>>>>>>> Instead of making bug entries in MANTIS,
>>>>>>>>> just edit those .txt files, and commit them.
>>>>>>>>>
>>>>>>>>> Of course, if some issues are actual bugs,
>>>>>>>>> please feel free to report them in MANTIS.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> More comments below...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Jun 3, 2011 at 5:11 AM, Tom Vercauteren
>>>>>>>>> <tom.vercauteren at m4x.org> wrote:
>>>>>>>>>> Hi Luis,
>>>>>>>>>>
>>>>>>>>>> I would like to help in the cleanup process (especially for the
>>>>>>>>>>code
>>>>>>>>>> I
>>>>>>>>>> worked on in the past) but have unfortunately very little time
>>>>>>>>>>for
>>>>>>>>>> it.
>>>>>>>>>> The least I could do is pinpoint some places that I believe
>>>>>>>>>>require
>>>>>>>>>> cleanup. The problem is I don't really know if such a task is
>>>>>>>>>>wanted
>>>>>>>>>> and if so, how it should be done. Should I file bug reports
>>>>>>>>>>for each
>>>>>>>>>> cleanup task and mark them as feature requests? But then, who
>>>>>>>>>>would
>>>>>>>>>> be
>>>>>>>>>> in charge of triaging these feature requests? Are other more
>>>>>>>>>> effective
>>>>>>>>>> options available?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>http://www.itk.org/Wiki/ITK_Release_4/Modularization/Code_Reviews/
>>>>>>>>>Proce
>>>>>>>>> ss#Git-Based
>>>>>>>>>
>>>>>>>>>https://github.com/InsightSoftwareConsortium/itk-retroactive-revie
>>>>>>>>>w
>>>>>>>>>
>>>>>>>>>> For the time being, there are a least a few places on the top
>>>>>>>>>>of my
>>>>>>>>>> head that require cleanup (some of which might be considered as
>>>>>>>>>> features depending on how you look at it). Sorted by order of
>>>>>>>>>> importance:
>>>>>>>>>>
>>>>>>>>>> 1) Bad design in ImportImageContainer.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://github.com/Kitware/ITK/blob/master/Modules/Core/Common/in
>>>>>>>>>>clude
>>>>>>>>>> /itkImportImageContainer.h
>>>>>>>>>> The memory allocation and deallocation functions have an
>>>>>>>>>>inconsistent
>>>>>>>>>> signature. One uses a member and the others returns a pointer:
>>>>>>>>>> virtual TElement * AllocateElements(ElementIdentifier size)
>>>>>>>>>>const;
>>>>>>>>>> virtual void DeallocateManagedMemory();
>>>>>>>>>>
>>>>>>>>>> This makes it really difficult to override the class in a
>>>>>>>>>>correct
>>>>>>>>>> manner. I have actually stumped into a bug in
>>>>>>>>>> TestImportImageContainer
>>>>>>>>>> coming from this design issue ( that I haven't filed yet :( )
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://github.com/Kitware/ITK/blob/master/Modules/Core/Common/te
>>>>>>>>>>st/it
>>>>>>>>>> kFactoryTestLib.cxx
>>>>>>>>>> With this TestImportImageContainer class, reallocating an image
>>>>>>>>>>will
>>>>>>>>>> fail. This is bad since it will most certainly be the first
>>>>>>>>>>thing
>>>>>>>>>> people will look at when trying to override the default memory
>>>>>>>>>> handling of ITK.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Fair enough...
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2) The unicode filename problem on windows.
>>>>>>>>>> Most of the low-level code necessary to deal with unicode
>>>>>>>>>>filenames
>>>>>>>>>> through utf-8 encoding is already in the repository but it
>>>>>>>>>>isn't used
>>>>>>>>>> yet. What still need to be done is use this low-level code for
>>>>>>>>>>all IO
>>>>>>>>>> operations. More detail in:
>>>>>>>>>> http://www.itk.org/Bug/view.php?id=9623
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 3) There are a lot of useless vector-specific classes that were
>>>>>>>>>> introduced probably for MSVC 6. It might be the right time to
>>>>>>>>>>merge
>>>>>>>>>> them back into the corresponding "scalar" classes.
>>>>>>>>>> http://itk.org/Bug/view.php?id=2712
>>>>>>>>>>
>>>>>>>>>>http://www.itk.org/Wiki/ITK_Release_4/Wish_List#Image_Registratio
>>>>>>>>>>n
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes,
>>>>>>>>> Cory, Arnaud, Gaetan and Brad L. have been improving
>>>>>>>>> the support for multiple components...
>>>>>>>>> We need raise the priority of this one,
>>>>>>>>> since it is so fundamental for
>>>>>>>>> Microscopy and for Remote Sensing.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 4) Some default options are not the most meaningful ones:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>http://www.itk.org/Wiki/ITK_Release_4/Wish_List#Backward_compatib
>>>>>>>>>>ility
>>>>>>>>>> _and_cleanup
>>>>>>>>>> For example Gaussian smoothing uses either a sigma defined in
>>>>>>>>>>terms
>>>>>>>>>> of
>>>>>>>>>> physical space or pixel space depending on its implementation
>>>>>>>>>> (discrete versus recursive).
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yeap, the API is inconsistent.
>>>>>>>>> Plus some take Sigma, while others take Variance...
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 5) Others inconsistencies
>>>>>>>>>> http://www.itk.org/Bug/view.php?id=7351
>>>>>>>>>> http://www.itk.org/Bug/view.php?id=8944
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>http://www.itk.org/Wiki/ITK_Release_4/Wish_List#Make_the_boundary
>>>>>>>>>>_cond
>>>>>>>>>> itions_usage_consistent_across_the_toolkit
>>>>>>>>>> For example the behavior of the interpolators outside the image
>>>>>>>>>> domain
>>>>>>>>>> is not practical. This is one of the reason why I implemented
>>>>>>>>>> VectorLinearInterpolateNearestNeighborExtrapolateImageFunction
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>https://github.com/Kitware/ITK/blob/master/Modules/Nonunit/Review
>>>>>>>>>>/incl
>>>>>>>>>>
>>>>>>>>>>ude/itkVectorLinearInterpolateNearestNeighborExtrapolateImageFunc
>>>>>>>>>>tion.
>>>>>>>>>> h
>>>>>>>>>> Ideally, the functionnality of this class should be handled by
>>>>>>>>>> LinearInterpolateImageFunction.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hope this helps,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It certainly does.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Many Thanks
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Luis
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----------------------------
>>>>>>>>>> Tom
>>>>>>>>>>
>>>>>>>>>> On Thu, Jun 2, 2011 at 15:06, Luis Ibanez
>>>>>>>>>><luis.ibanez at kitware.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> I want to second Brad L. comment regarding
>>>>>>>>>>> our current misplaced focus on ITKv4.
>>>>>>>>>>>
>>>>>>>>>>> There is a disproportionate number of changes
>>>>>>>>>>> that are introducing new features in the toolkit,
>>>>>>>>>>> when we are supposed to be focused on cleaning
>>>>>>>>>>> up and restructuring for the next 10 years.
>>>>>>>>>>>
>>>>>>>>>>> I suggest that we prioritize every patch in Gerrit
>>>>>>>>>>> based on whether it is:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 1) Bug fix
>>>>>>>>>>> 2) Clean up resulting from code reviews
>>>>>>>>>>> 3) Needed for refactoring (FEM, Regist, LevelSets)
>>>>>>>>>>> ....
>>>>>>>>>>> 99) New features
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> We have limited time and resources to do all
>>>>>>>>>>> the refactoring and revision of ITKv4 and we
>>>>>>>>>>> are being side-tracked dealing with changes
>>>>>>>>>>> that are not part of the ITKv4 charter.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Luis
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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.html
>>>>>>>>>>>
>>>>>>>>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>>>>>>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>>>>>>>>>
>>>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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.html
>>>>>>>>>
>>>>>>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>>>>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>>>>>>>
>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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.html
>>>>>>>>
>>>>>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>>>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>>>>>>
>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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.html
>>>>>>
>>>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>>>>
>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>>>
>>>>>
>>>>>
>>>>> ________________________________
>>>>> 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.html
>>>>
>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>
>>>
>> _______________________________________________
>> 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.html
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>_______________________________________________
>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.html
>
>Please keep messages on-topic and check the ITK FAQ at:
>http://www.itk.org/Wiki/ITK_FAQ
>
>Follow this link to subscribe/unsubscribe:
>http://www.itk.org/mailman/listinfo/insight-developers
________________________________
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.
________________________________
More information about the Insight-developers
mailing list