[vtkusers] Strange slowness with vtkImagePlaneWidget

[Marco Sambin]

Hi,

let me add something to my previous post, since I discovered some facts
which may be useful in identifying the issue.

I made the following test:

1) I have a set of 357 raw files in an input folder. Each file contains a
512x512 unsigned short pixel matrix.

2) Using this single set of raw files (i.e., always keeping the same input
test volume), after several attempts I discovered that if I limit my reader
to read just 326 slices or less, then rendering of the vtkImagePlaneWidget
will be slow. On the other side, if I allow my reader to read 327 slices or
more, then rendering of vtkImagePlaneWidget will be fast. In code (with
reference to the code posted in my previous message):

[...]
imageReaderVTK.SetDataExtent(0, sliceCols - 1,
                              0, sliceRows - 1,
                              0, 325);
[...]
---> rendering will be SLOW


[...]
imageReaderVTK.SetDataExtent(0, sliceCols - 1,
                              0, sliceRows - 1,
                              0, 326);
[...]
---> rendering will be FAST

Once again, the set of RAW input slices available in the input folder is
always the same.

Any explanation for this?

The only explanation which comes to my mind is the existence in VTK of a
rendering technique adopting a policy like "if data is small enough to be
managed by the graphic card, then demand this task to the graphic card,
otherwise use the CPU", and on that old PC the CPU may be a lot faster than
the graphic card to do that job.

Is this just fantasy? Or there may be an explanation of that kind to the
behavior I observed on that old PC?

Thanks in advance for your comments.

Marco


On Wed, Sep 4, 2013 at 5:29 PM, Marco Sambin <m.sambin at gmail.com> wrote:

> Hi Dean,
>
> first of all, thank you for your message.
>
> The underlying pixel data type is unsigned short for both volumes.
> Here is how I configure the reader:
>
>         imageReaderVTK =  new vtkImageReader2();
>         imageReaderVTK.FileLowerLeftOn();
>         imageReaderVTK.SetFilePrefix(filePrefix);
>         imageReaderVTK.SetFilePattern("%s_%d.raw");
>         imageReaderVTK.SetDataExtent(0, sliceCols - 1,
>                               0, sliceRows - 1,
>                               0, numOfImages - 1);
>         imageReaderVTK.SetDataSpacing(xSpacing, ySpacing, zSpacing);
>         imageReaderVTK.SetDataOrigin(0.0, 0.0, 0.0);
>         imageReaderVTK.SetDataScalarTypeToUnsignedShort();
>         imageReaderVTK.SetDataByteOrderToBigEndian();
>         imageReaderVTK.UpdateWholeExtent();
>
>
> And here is how I configure the widget:
>
>     vtkGenericRenderWindowInteractor interactor =
> getRenderWindowInteractor();
>     planeWidgets[planeWidgetIndex].RestrictPlaneToVolumeOn();
>     planeWidgets[planeWidgetIndex].SetInteractor(interactor);
>     planeWidgets[planeWidgetIndex].DisplayTextOn();
>     planeWidgets[planeWidgetIndex].TextureInterpolateOn();
>     planeWidgets[planeWidgetIndex].UserControlledLookupTableOff();
>     planeWidgets[planeWidgetIndex].SetResliceInterpolateToCubic();
>     planeWidgets[planeWidgetIndex].KeyPressActivationOff();
>
> planeWidgets[planeWidgetIndex].SetInputConnection(imageReaderVTK.GetOutputPort());
>     planeWidgets[planeWidgetIndex].SetWindowLevel(winWidth, winLevel, 0);
>     planeWidgets[planeWidgetIndex].SetPlaneOrientation(planeWidgetIndex);
>
>     planeWidgets[planeWidgetIndex].PlaceWidget(volBounds);
>     planeWidgets[planeWidgetIndex].On();
>     planeWidgets[planeWidgetIndex].SetEnabled(1);
>
> As I explained in my previous post, strangely the widgets interact with
> much better performances when my volume is made up of 360 512x512 slices,
> and worse when my volume is made up of 90 512x512 slices.
> But this only happens on the old PC. On my development machine the
> rendering performance of the widgets are fine and undistinguishable in both
> cases.
>
> I would like to underline that, on the old machine and with the smaller
> volume, the rendering of the vtkImagePlaneWidget is slow even when I try to
> modify the camera position through the default VTK interactor. I do not
> trigger any recomputation of window/level, or other, just roll my camera
> around the volume, and still I see the rendering slowness (I can
> distinguish painting of each triangle of each texture).
>
> Thanks in advance for sharing your comments and suggestions with me.
>
> Marco
>
>
>
> On Wed, Sep 4, 2013 at 4:21 PM, Dean Inglis <inglis.dl at gmail.com> wrote:
>
>> Hi Marco,
>>
>> what is the underlying pixel data type in those two images ?  The widget
>> has an internal
>> vtkImageMapToColors which will do additional processing to convert the
>> input to
>> uchar if required.  How do you configure your widgets ?
>>
>>
>> - Dean
>>
>>
>> On Wed, Sep 4, 2013 at 7:08 AM, Marco Sambin <m.sambin at gmail.com> wrote:
>>
>>> Hi all.
>>>
>>> In my VTK6-based Java application, I am using a vtkCanvas where I
>>> display three orthogonal vtkImagePlaneWidgets, cutting a volume loaded
>>> through vtkImageReader2.
>>>
>>> Everything works fine on my development machine, which is a recent and
>>> moderately-powerful 64-bit Win 7-based machine.
>>>
>>> For legacy-compatibility purposes, I tested this application under an
>>> older Win XP-based Pentium 4 machine with 1 GB RAM and old Barco graphic
>>> cards, and I obtained "strange" results:
>>>
>>> - if I feed vtkImageReader2 with a volume made up of around 360 raw
>>> slices, each one 512x512 pixels, then the overall rendering performances of
>>> the view containing the three vtkImagePlaneWidgets are acceptable.
>>>
>>> - on the other side, if I feed vtkImageReader2 with a volume made up of
>>> 90 (i.e., fewer) raw slices, each one 512x512 pixels, then the overall
>>> rendering performances of the view containing the three
>>> vtkImagePlaneWidgets become really poor, and I can distinguish the texture
>>> appearing on top of each plane widget painting as two separate triangles,
>>> given the slow rendering.
>>>
>>> Can you guess why the rendering performance of the vtkImagePlaneWidgets
>>> are much worse with the smaller volume w.r.t. with the larger volume?
>>>
>>> Thanks for any hints you will give.
>>>
>>> Best regards,
>>>
>>> Marco
>>>
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Please keep messages on-topic and check the VTK FAQ at:
>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20130904/2bde5599/attachment.htm>