[vtkusers] vtkImageActor and scaling

[David Gobbi]

Hi Mark,

You can try using vtkImageShiftScale to remap your 16-bit data to 8-bit, it
might be slightly faster than using vtkImageMapToColors.

  David

On Fri, Dec 3, 2010 at 5:37 AM, endlosschleife1 <
endlosschleife1 at googlemail.com> wrote:

> 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/c4047f56/attachment.htm>