[Insight-developers] Dashboard woes

Thu Jun 2 09:56:07 EDT 2011

I dis-agree on the feature creep.  This is a longstanding deficiency in
ITK that arose from an initial avoidance of oriented physical image space.
 Now is our chance to fix it!

One of my favorite ITK powerpoint training slides is Bart Simpson writing
"I will not register images in index space" over and over and over on a
chalk board as punishment.  It is my opinion, (and hopefully the opinion
of every student that I've ever taught) that image operations on medical
images only make sense in physical space.  For those processing steps that
work only on the voxel lattice, there is still an implied physical space
that must be considered.  There are times when the developer can VERIFY
THAT ALL THE PHYSICAL SPACES AND INDEX SPACES ARE CONSISTENT for both
operand images, and then optimize the computation by using only the voxel
lattice, thus skipping the implied sameness of the physical space.

After all the effort put into making most of the ITK toolkit work properly
in physical space, one still could not add two images together unless
their voxel lattice was the same.  Even more disturbing, one could add two
images together that had the same voxel lattice, but have completely
different physical space representations, and no warning/error was thrown
(I know this because it has bitten me several times,  I've begun to trust
ITK to compute properly in physical space, or at least fail with rigor).

It was naive to think that folding it into the current "Math" filters was
the correct place to put this.  In my programs (and Slicers, and hopefully
other medical imaging applications) there is a need to compute in physical
space.

***
* At a minimum, the filters that only work on voxel lattices should at
least check that the physical space representations are compatible, and
provide a warning if they are not.  There are too many 256^3 voxel medical
images that do not have the same physical space representations.
* A parallel set of operators is needed that can work on images in
physical space, and if they have consistent physical space
representations, it should fall trough to the highly optimized index only
based computation.

Hans
--
Hans J. Johnson, Ph.D.
hans-johnson at uiowa.edu
Assistant Professor of Psychiatry
University of Iowa Carver College of Medicine
W278 GH, 200 Hawkins Drive

Iowa City, Iowa 52242
Phone:  319-353-8587

-----Original Message-----
From: Luis Ibanez <luis.ibanez at kitware.com>
Date: Thu, 2 Jun 2011 08:57:29 -0400
To: Bill Lorensen <bill.lorensen at gmail.com>
Cc: ITK <insight-developers at itk.org>
Subject: Re: [Insight-developers] Dashboard woes

Bill,

This is the consequence of an incomplete analysis
of dependencies when making changes.

1) The Changes in BinaryFunctorImageFilter
    introduced the use of the LinearInterpolator
    in a filter that up to now was quite self-sufficient.

2) BinaryFunctorImageFilter in in Core/Common

3) ITK-Common DEPENDS ITK-VNLInstantiation ITK-KWSys
     (only)

4) With the changes in BinaryFunctor, now Common
     depends (in practice) on the ITK-ImageFunctions module.
     because that's where the Interpolators are. But, the
     module dependency was not made explicit because...

5)  ITK-ImageFunction already depends on ITK-Common

6)  Ergo sum: Circular dependency

7) Why did this go unnoticed before ?

     Because the test of the BinaryFunctor was made to
     depend on the ITK-ImageFunction module, giving
     the false impression that the problem was fixed.

8)  The recent relocation of the ImageCompose - related
      filters exposed the missing dependency between
      the BinaryFunctorImageFitler and the Interpolators.

---

I would have to agree with Brad L. on that this change
in BinaryFunctorImageFilter is feature creep, and that
we should reconsider the usefulness of that change.

      Luis

--------------------
On Wed, Jun 1, 2011 at 11:55 PM, Bill Lorensen <bill.lorensen at gmail.com>
wrote:
> Folks,
>
> I suggest we hold off on any new merges except for those that will
> bring the Dashboard back to normalcy. There is no sense in checking in
> code when there are so many compile errors on so many platforms.
>
> Bill
> _______________________________________________
> 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.
________________________________