MantisBT - ITK
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007406ITKpublic2008-07-26 08:182010-11-04 19:36
ReporterHans Johnson 
Assigned ToBill Lorensen 
PrioritynormalSeveritytextReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Resolution Date
Sprint
Sprint Statuscompleted
Summary0007406: itkOrientImage needs documentation
Description1) The documentation for this class is very limited, and does not state how an itkOrientedImage is different from an itkImage. It just states what funding was used to generate this class.

2) There are several "#if 1/#else/#endif" sections in the code which indicates to me that perhaps this code is still in a debugging state and the behavior may change once the correct behavior is figured out. -- The #if 0 sections should become regular comments now that it is verified that the new efficient code works.

3) #ifdef ITK_USE_ORIENTED_IMAGE_DIRECTION : if this is not defined, does the itkOrientedImage behave like the itkImage? -- A note should be added to the head indicating that at compile time this should be defined in order for new programs to get proper gradient calculations.

============

A use case that would be useful to document is that the two items below produce the same result:

1)
Assume myimage has direction cosigns of [1 0 0; 0 0 -1; 0 1 0]
Assume myidentity is an affine identity matrix;

ResampleImageFilter->SetInput(myimage);
ResampleImageFilter->SetTransform(myidentity);
myoutput=ResampleImageFilter->GetOutput();
myoutput1->SetDirections(myidentity);

2)
Assume myimage has direction cosigns of [1 0 0; 0 0 -1; 0 1 0]
Assume myaffine is an affine identity matrix;

myaffine=myimage->GetDirections();
myimage->SetDirection(myidentity);
ResampleImageFilter->SetInput(myimage);
ResampleImageFilter->SetTransform(myaffine);
myoutput2=ResampleImageFilter->GetOutput();

Steps To Reproduce
Additional InformationHans,

The OrientedImage uses an image direction cosines when transforming
physical points to indexes and vice versa. It is in working condition.
The #else's are there to show a more readable version of the code. I
used template meta-programming to implement the transformations in an
efficient way. Unfortunately, the meta-programming code is hard to
follow.

The ITK_USE_ORIENTED_IMAGE_DIRECTION is newer code to properly handle
gradient computations when directions are present. I suspect it will
be defined by default in a future release.

I recommend using OrientedImage if your images have different directions.

Admittedly, the code should be documented better. Can you file a bug
report for that and assign it to me?

Regards,

Bill
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2008-07-26 08:18Hans JohnsonNew Issue
2008-07-26 08:19Hans JohnsonStatusnew => assigned
2008-07-26 08:19Hans JohnsonAssigned To => Bill Lorensen
2008-11-07 10:43Hans JohnsonNote Added: 0014060
2010-11-04 19:36Bill LorensenSprint Status => completed
2010-11-04 19:36Bill LorensenNote Added: 0022872
2010-11-04 19:36Bill LorensenStatusassigned => closed
2010-11-04 19:36Bill LorensenResolutionopen => fixed

Notes
(0014060)
Hans Johnson   
2008-11-07 10:43   
-DITK_USE_ORIENTED_IMAGE_DIRECTION:BOOL=ON
-DITK_IMAGE_BEHAVES_AS_ORIENTED_IMAGE:BOOL=ON

New flags introduced in version 3.10 make this irrelavant because the itkOrientedImage behavior is controlled by CMake Compile time flags.
(0022872)
Bill Lorensen   
2010-11-04 19:36   
OrientedImage behavior is now included in Image.