[Insight-users] ITK 3.6 : Serial Transformations

[Luis Ibanez]

Hi Ruppert,


          I fully agree with Gaetan here,


We have a major void on reviews and that is preventing
the smooth flow of new code into the toolkit.

I'm afraid that the concept of "review" has been associated so
deeply with the corrupted practices of the publishing system
that ITK users feel no motivation to perform them.

Maybe we should change the term for something that sounds more
to software engineering and less to the childish behavior of
"I-did-it-first" that plagues the papers in our domain.


That being said....


Regarding the technical points that you brought up.

0) Please post them as reviews to both papers.
    When we move code into the Code/Review directory
    we go through the reviewers comments again.


1) Composing Jacobians will only be possible by
    creating a cumulated array of parameters that
    is the concatenation of the parameters of all
    the transforms. If this new parameters array
    has M elements, then the composed Jacobian
    will have M x N elements, where N is the
    dimension of the space (.e.g image dimension).


2) Arbitrarily long chain of transform shouldn't
    be a problem. However users will have to be
    aware that the total number of transform
    parameters comes with a price on memory
    requirements and computational time.


3) Possibility to define some fixed parameters,
    sounds like a good idea, and not too hard
    to implement.


4) Interactions with readers and writers will
    be challenging, but possible.



It seems indeed that you have enough drive on this
issue for posting your own paper to the Insight Journal.

I would suggest that you contact the authors of the two
other papers and work together in a single common solution.


Generating that sort of interaction is what
publishing papers should have been all about....



       Regards,


           Luis



---------------------
Gaëtan Lehmann wrote:
> 
> Hi Ruppert,
> 
> The problem seem to be the lack of reviews for those articles - in  
> fact, it seem to be a major problem of the insight journal: the users  
> are not contributing enough *reviews* to make the process work properly.
> 
> So I think you're right: you should think about posting a review, both  
> to speed up the inclusion process, and to enhance the contributions by  
> giving some advices to the authors, or by reporting some problems you  
> may have had.
> 
> You can check the reviews already there to see that there are not all  
> really long. Clearly, a short review is better than no review.  
> Potential reviewers should be less shy on the insight journal :-)
> 
> Regards,
> 
> Gaëtan
> 
> 
> Le 2 févr. 08 à 15:37, Rupert Brooks a écrit :
> 
>> Hi,
>>
>> One thing that caught my attention about the upcoming ITK release was
>> the plan to move the Serial Transformation class to the Review
>> directory (its in the low priority items).  I think the idea of
>> combining transforms would be a great addition; I have used this sort
>> of thing on occasion, and I am very curious if anyone else uses
>> combinations of transforms and what their requirements and thoughts on
>> the topic were.
>>
>> The thing is, the paper chosen does not support the registration
>> framework, where as another paper on the same topic does.  That paper,
>> however, has its own set of limitations. I think that a class for
>> serial or combined transforms is a valuable addition. However, I worry
>> that if done prematurely, we might get stuck with a limited interface
>> due to ITKs backwards compatibility policies. I think some serious
>> thought should be put into how this interface should work before
>> committing to a particular implementation.
>>
>> Links:
>> Serial Transforms (proposed for ITK3.6):
>> http://hdl.handle.net/1926/487
>> Combined Transforms
>> http://hdl.handle.net/1926/197
>>
>> At the very least i think that any such class should support:
>>
>>   1. The registration framework - ie - proper Jacobians - (one has to
>> transform one Jacobian by the spatial Jacobian of the other transforms
>> in certain cases).
>>   2. An arbitrarily long chain of transformations
>>   3. The ability to have some fixed and some parameterized transforms
>> - by this i mean that some transformation parameters do not appear in
>> the GetParameters and Jacobian methods.  (Sometimes part A is always
>> at 45 degrees to part B, for example.
>>   4. Some sort of intelligent interaction with the transform reader
>> and writer classes.
>>
>> I suppose that I should kick myself a bit, for not having reviewed
>> either of these papers at the time.  Anyway, im not saying that all
>> possibilities should be working immediately, but just that the
>> interface should be clean, so we don't have problems later.
>>
>> Thoughts?
>>
>> Rupert B
>>
>>
>> -- 
>> --------------------------------------------------------------
>> Rupert Brooks
>> McGill Centre for Intelligent Machines (www.cim.mcgill.ca)
>> Ph.D Student, Electrical and Computer Engineering
>> http://www.cyberus.ca/~rbrooks
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users