[vtkusers] BUG: vtkImageData::ComputeBounds() ... + solution

[Schaap, J.A. (LKEB)]

Hmm, interesting, all those concepts of what the bounds actualy are...
I think one could say that each of the three options make sense, so a debate about which one is "correct" is not very usefull.

Why don't we make the three options available to the programmer's preference? 
I imagine something like this:

add a enum variable to the class vtkImageData named "BoundsComputationMethod" which can have three values "BetweenExtents" "BetweenHalfShiftedVoxels" and "BetweenExentsPlusOne".

then add a switch statement to the vtkImageData::ComputeBounds() function, and handle it according to the BoundsComputationMethod variable.

If the BoundsComputationMethod can also be set globally, much like is doen now in for example vtkMapper::SetGlobalImmediateModeRendering(int val) , then the programmer could set his/her choice at the 
beginning of the program.
If the default is "BetweenExtents", then nobody would notice any difference when they upgrade, except that there are two new possible ways to compute the bounds.

Would this be a good idea? Not too much work, I would think?

Best regards, Jorrit




18-7-2002 15:26:12, "Ken Martin" <kenlists at nycap.rr.com> wrote:

>> maybe I have a different understanding of the concept
>> "bounds", but I think the current implementation of
>> vtkImageData::ComputeBounds() isn't quite right. (vtk version 4.0)
>>
>> void vtkImageData::ComputeBounds()
>> {
>>   float *origin = this->GetOrigin();
>>   float *spacing = this->GetSpacing();
>>
>>   this->Bounds[0] = origin[0] + (this->Extent[0] * spacing[0]);
>>   this->Bounds[2] = origin[1] + (this->Extent[2] * spacing[1]);
>>   this->Bounds[4] = origin[2] + (this->Extent[4] * spacing[2]);
>>
>>   this->Bounds[1] = origin[0] + (this->Extent[1] * spacing[0]);
>>   this->Bounds[3] = origin[1] + (this->Extent[3] * spacing[1]);
>>   this->Bounds[5] = origin[2] + (this->Extent[5] * spacing[2]);
>> }
>>
>>
>> I think it should be replaced by:
>>
>> void vtkImageData::ComputeBounds()
>> {
>>   float *origin = this->GetOrigin();
>>   float *spacing = this->GetSpacing();
>>
>>   this->Bounds[0] = origin[0] + (this->Extent[0] * spacing[0]);
>>   this->Bounds[2] = origin[1] + (this->Extent[2] * spacing[1]);
>>   this->Bounds[4] = origin[2] + (this->Extent[4] * spacing[2]);
>>
>>   this->Bounds[1] = origin[0] + ((this->Extent[1] + 1) *
>> spacing[0]);
>>   this->Bounds[3] = origin[1] + ((this->Extent[3] + 1) *
>> spacing[1]);
>>   this->Bounds[5] = origin[2] + ((this->Extent[5] + 1) *
>> spacing[2]);
>> }
>>
>>
>> Just to clarify this with an example...
>> suppose I would create a piece of vtkImageData with
>> dimensions 32x32x32.
>> This would give me an extent of [0, 31, 0, 31, 0, 31]
>> I set the spacing to (10, 10, 10) and the origin to (0, 0, 0)
>>
>> IMHO this would give me bounds of [0, 320, 0, 320, 0, 320],
>> but the current implementation yields [0, 310, 0, 310, 0, 310]
>>
>> If you agree, could this be corrected?
>
>This is a difficult issue and one I have raised in the past. Currently
>vtk defines an image to only exist between sample points. As such its
>bounds are correct. This has a number of advantages for mixing images
>and polygonal meshes. Few people would suggest that the bounds of a
>polygonal mesh go outside of the sample points. But, another
>interpretation of an image is to represent the area around a sample as
>a pixel. in which case the image bounds start a half pixel before the
>first sample and end a half pixel after the last sample. And the third
>interpretation is what you suggested, that the sample represents the
>lower left corner of a pixel, so the bounds go from the first sample
>to one pixel beyond the last sample. My suggestion would be the second
>option; the samples represent essentially cell data, not point data.
>But switching the vtkImage to use cell data would be a huge change.
>The other option would be to modify the readers to read in cell data
>and convert it to point data (so that a 256 by 256 pixel image would
>result in a 257 by 257 point image) But that's a little confusing as
>well. I'm open to suggestions, but so matter what the fix it goes
>beyond just changing the bounds computation. At a minimum the
>rendering must be changed as well so that the image is rendered into
>the "correct" space.
>
>Thanks
>Ken
>