[vtkusers] ComputeTransformedOrigin bug in vtkImageReader.cxx
Mathieu Malaterre
mathieu.malaterre at kitware.com
Fri Apr 23 13:35:03 EDT 2004
Ok, looks good to me. Before commiting the patch, I'll investigate why
the first one was apply.
Thanks for sending the sample code, this is very appreciated,
Mathieu
Ps: Seems like vtkVolume16Reader need to get your patch back.
Index: vtkImageReader.cxx
===================================================================
RCS file: /cvsroot/VTK/VTK/IO/vtkImageReader.cxx,v
retrieving revision 1.115
diff -u -3 -p -r1.115 vtkImageReader.cxx
--- vtkImageReader.cxx 10 Dec 2003 18:23:12 -0000 1.115
+++ vtkImageReader.cxx 23 Apr 2004 17:16:29 -0000
@@ -493,7 +493,7 @@ void vtkImageReader::ComputeTransformedO
if (transformedSpacing[i] < 0)
{
origin[i] = transformedOrigin[i] + transformedSpacing[i]*
- (transformedExtent[i*2+1] - transformedExtent[i*2] + 1);
+ (transformedExtent[i*2+1] - transformedExtent[i*2]);
}
else
{
Index: vtkVolume16Reader.cxx
===================================================================
RCS file: /cvsroot/VTK/VTK/IO/vtkVolume16Reader.cxx,v
retrieving revision 1.51
diff -u -3 -p -r1.51 vtkVolume16Reader.cxx
--- vtkVolume16Reader.cxx 5 Dec 2003 18:19:04 -0000 1.51
+++ vtkVolume16Reader.cxx 23 Apr 2004 17:16:29 -0000
@@ -534,7 +534,7 @@ void vtkVolume16Reader::AdjustSpacingAnd
{
if (Spacing[i] < 0)
{
- origin[i] = origin[i] + Spacing[i] * dimensions[i];
+ origin[i] = origin[i] + Spacing[i] * (dimensions[i] - 1);
Spacing[i] = -Spacing[i];
}
}
Josh Snyder wrote:
> The code below reproduces the problem, and is similar to the example
> described further down. The transform supplied to the vtkImageReader
> should reflect the first dimension of the data around x = 0 by
> transforming its -1 0 0 origin to 1 0 0. Instead, the new origin is 0 0
> 0. Plugging different origin/dimensions/extent values into this code
> reveals the same offset error every time.
>
> Thanks,
> Josh
>
>
> vtkImageData id
> id SetDimensions 1 1 1
> id AllocateScalars
>
> vtkImageWriter iw
> iw SetFileDimensionality 2
> iw SetFileName test.dat
> iw SetInput id
> iw Write
>
> vtkImageReader ir
> ir SetFileDimensionality 2
> ir SetFileName test.dat
> ir SetDataOrigin -1 0 0
> ir SetDataSpacing 1 1 1
> ir SetDataExtent 0 0 0 0 0 0
>
> vtkMatrix4x4 m
> m SetElement 0 0 -1
>
> vtkTransform t
> t SetMatrix m
>
> ir SetTransform t
>
> ir Update
> [ir GetOutput] GetOrigin
>
>
> Mathieu Malaterre wrote:
>
>> Josh,
>>
>> Could you provide us with a sample code that reproduce the problem ?
>>
>> Thanks
>> Mathieu
>>
>> Josh Snyder wrote:
>>
>>> Making this change fixed my problem. Could someone verify this and
>>> check it in?
>>>
>>> Josh
>>>
>>> Josh Snyder wrote:
>>>
>>>> I've run into a problem using vtkImageReader with the SetTransform
>>>> functionality, and I think it's due to the line of code referenced
>>>> in the post below (line 495 in the current CVS version). It seems to
>>>> me that the older version (w/out the +1) was correct. My
>>>> understanding is that if the Transform specifies an axis reversal,
>>>> the order of the voxels along that axis needs to be reversed, and
>>>> the origin coordinate for that axis needs to be shifted so that the
>>>> voxels originally occurring at negative locations become positive
>>>> and vice versa. The former step is handled by the inverse transform
>>>> of the increments during the vtkImageReaderUpdate2 method, and the
>>>> latter by the code mentioned below. I think the +1 addition is a
>>>> bug. For example, consider the case where the extent in the y
>>>> direction consists of a single voxel situated at y = -1, and the
>>>> Transform specifies that this axis be reversed. This line should
>>>> translate the origin to +1, so that the voxel is newly situated at +1.
>>>>
>>>> In this case, the variables would be set as follows:
>>>> original origin[1] = -1
>>>> original spacing[1] = 1
>>>>
>>>> Transform =
>>>> 1 0 0 0
>>>> 0 -1 0 0
>>>> 0 0 1 0
>>>> 0 0 0 1
>>>>
>>>> yields
>>>>
>>>> transformedOrigin[1] = 1
>>>> transformedSpacing[1] = -1
>>>>
>>>> transformedExtent[3] = 0
>>>> transformedExtent[2] = 0
>>>> i = 1
>>>>
>>>> The current code:
>>>> origin[i] = transformedOrigin[i] +
>>>> transformedSpacing[i]*(transformedExtent[i*2+1] -
>>>> transformedExtent[i*2] + 1)
>>>> = 1 + (-1 * (0 - 0 + 1)) = 1 - 1 = 0
>>>>
>>>> The old (correct?) code:
>>>> origin[i] = transformedOrigin[i] +
>>>> transformedSpacing[i]*(transformedExtent[i*2+1] -
>>>> transformedExtent[i*2])
>>>> = 1 + (-1 * (0 - 0)) = 1 + 0 = 1
>>>>
>>>> Is my understanding of this correct, or is there something I'm missing?
>>>>
>>>> Josh
>>>>
>>>>> Simon,
>>>>>
>>>>> I checked in your corrections this morning. I also fixed
>>>>> graphics/vtkVolume16Reader. Its logic was
>>>>> also flawed.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Bill
>>>>>
>>>>> -----Original Message-----
>>>>> From: Simon Warfield [mailto:warfield at bwh.harvard.edu
>>>>> <mailto:warfield%20at%20bwh.harvard.edu>]
>>>>> Sent: Sunday, July 08, 2001 7:09 PM
>>>>> To: vtkusers at public.kitware.com
>>>>> <mailto:vtkusers%20at%20public.kitware.com>
>>>>> Subject: [vtkusers] bug in vtkImageReader.cxx ?
>>>>>
>>>>>
>>>>>
>>>>> I notice that if I read some image data using vtkImageReader and
>>>>> transform
>>>>> it to correct for patient orientation using the
>>>>> vtkImagerReader::SetTransform
>>>>> function, then the new origin is at an unexpected location.
>>>>>
>>>>> I get data looking like:
>>>>> # vtk DataFile Version 3.0
>>>>> vtk output
>>>>> BINARY
>>>>> DATASET STRUCTURED_POINTS
>>>>> DIMENSIONS 256 256 90
>>>>> SPACING 0.703125 0.703125 1.5
>>>>> ORIGIN -90 -89.2969 -67.5
>>>>> CELL_DATA 5787225
>>>>> POINT_DATA 5898240
>>>>>
>>>>> When I expect to get data looking like:
>>>>> # vtk DataFile Version 3.0
>>>>> vtk output
>>>>> BINARY
>>>>> DATASET STRUCTURED_POINTS
>>>>> DIMENSIONS 256 256 90
>>>>> SPACING 0.703125 0.703125 1.5
>>>>> ORIGIN -90 -90 -67.5
>>>>> CELL_DATA 5787225
>>>>> POINT_DATA 5898240
>>>>>
>>>>> I think the problem is that line 936 of imaging/vtkImageReader.cxx
>>>>> should not
>>>>> read
>>>>> (transformedExtent[i*2+1] - transformedExtent[i*2]);
>>>>> but instead should be:
>>>>> (transformedExtent[i*2+1] - transformedExtent[i*2]+1);
>>>>>
>>>>> This part of vtkImageReader.cxx in the latest vtk nightly is doing
>>>>> a shift of the origin when an axis is reflected, but seems to be
>>>>> using one less
>>>>> than the width of the data to compute the new origin. I think the
>>>>> width
>>>>> of the data should be used.
>>>>>
>>>>> Could someone check this, and make the change to the CVS
>>>>> repository if it
>>>>> should be fixed ?
>>>>>
>>>>> --
>>>>> Simon Warfield, Ph.D. warfield at bwh.harvard.edu
>>>>> <mailto:warfield%20at%20bwh.harvard.edu> Phone:617-732-7090
>>>>> http://www.spl.harvard.edu/~warfield
>>>>> <http://www.spl.harvard.edu/%7Ewarfield> FAX: 617-582-6033
>>>>> Thorn 329, Brigham and Women's Hospital, Harvard Medical School
>>>>> Department of Radiology, 75 Francis St, Boston, MA, 02115
>>>>>
>>>>
>>>> _______________________________________________
>>>> This is the private VTK discussion list. Please keep messages
>>>> on-topic. Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> This is the private VTK discussion list. Please keep messages
>>> on-topic. Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>
>>
>>
>>
>> _______________________________________________
>> This is the private VTK discussion list. Please keep messages
>> on-topic. Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtkusers
>
>
>
More information about the vtkusers
mailing list