[vtkusers] vtkImageActor and scaling

[endlosschleife1]

Hi David,

thanks for all the help. I have looked at the OpenGL primitves for
vtkImageActor and vtkImageMapper and it helped me understanding the basic
differences, and I played around a bit with performance testing with non-VTK
glDrawPixels vs. glTexImage2D programs.

The performance difference that I saw with
vtkImageActor/vtkWindowLeveLookupTable/vtkImageMapToColors does not seem to
come from the Open/GL part. It really seems to be the LUT operation (with
linear ramps / luminance output format) that makes the difference. When I
passed a ready pre-calculated 8 bit image to the actor instead of going
through this filter the ImageActor based implementation was quicker than the
vtkActor2D based implementation (so 20 seconds faster for the testing
procedure below).

Mark

2010/11/30 David Gobbi <david.gobbi at gmail.com>

> Hi Mark,
>
> The underlying OpenGL mechanism for vtkImageActor is completely different
> from vtkImageMapper, so if all other things are equal, any differences in
> speed are due to how fast the GPU and its drivers can do glTexImage2D (for
> ImageActor) versus glDrawPixels (for ImageMapper).
>
> You can make the comparison between them more fair by making certain that
> each of them uses the same number of pixel components.  By default,
> vtkImageMapToColors will output an RGBA image.  Use
> MapToColors->SetOutputFormatToLuminance() to ensure that it produces 8-bit
> greyscale images instead.
>
>   David
>
>
> On Tue, Nov 30, 2010 at 9:56 AM, endlosschleife1 <
> endlosschleife1 at googlemail.com> wrote:
>
>> It's possible that I'm misinterpreting the performance results of my
>> implementation and that applying the window level lookup table is actually
>> not what makes the difference. I'm comparing a vtkActor2D/vtkImageMapper
>> based and a vtkImageActor based implementation of something that shows a
>> series of images one by one with a specific window/level.
>>
>> If the window/level is not the issue, how much of a difference in
>> performance drop for the vtkImageActor implementation would be expected?
>>
>> I have 700 images (512 x 512, 12 bits stored), rendered into a 512 x 512
>> viewport). vtkActor2D/vtkImageMapper takes about 8 seconds, vtkImageActor
>> about 26 seconds to render the whole series. If I additionally resample my
>> data to add a scale to best fit to the vtkActor2D/vtkImageMapper
>> implementation I get to 18 seconds (that was my starting point to look for
>> accelarated scaling). There is no visible difference when I add scaling to
>> the vtkImageActor. That means that I'm getting much faster scaling for the
>> vtkImageActor based implementation, but that overall it still performs
>> slower. Unless there is some other bottleneck in my implementation.
>>
>> Mark
>>
>>
>>
>> 2010/11/30 David Gobbi <david.gobbi at gmail.com>
>>
>>  On Tue, Nov 30, 2010 at 7:10 AM, endlosschleife1 <
>>> endlosschleife1 at googlemail.com> wrote:
>>>
>>>    I was actually looking for accelerated scaling, so this sounds like
>>>> vtkActor2D is not be the right thing for that.
>>>>
>>>
>>> For accelerated scaling, you need to use vtkImageActor.
>>>
>>>  I'm not sure, but it looks like my implementation probably doesn't use
>>>> any GPU acceleration (it seems to be pure image data filtering). It still
>>>> seemed to be not as performant as I expected (compared to an implementation
>>>> where I only used VTK for the imaging pipeline, but did the LUT application
>>>> and visualization separetely).
>>>>
>>>
>>> The vtkImageMapper doesn't have accelerated window/level either.  It does
>>> all the computations on the CPU and then uses glDrawPixels() to render the
>>> image.
>>>
>>>
>>>>  I create a vtkWindowLevelTable, set the window and center, and then
>>>> call build on the lut. Then I used it with a vtkImageMapToColors instance:
>>>>
>>>> vtkImageMapToColors *color = vtkImageMapToColors::New();
>>>> color->SetLookupTable(lut); // lut is the vtkWindowLevelTable
>>>> color->SetInput(...) // some vtkImageData
>>>>
>>>
>>> Yes, that looks typical.  Make sure that you call
>>> table->SetRampToLinear() because by default, a VTK lookup table uses a
>>> curved ramp instead of a linear ramp (I was shocked when I discovered this
>>> for the first time).
>>>
>>>   David
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20101203/bf76580d/attachment.htm>