[vtkusers] Strange slowness with vtkImagePlaneWidget

Wed Sep 4 13:10:32 EDT 2013

Hi Marco,

can you test and see what happens with only 1 image plane widget?  Texture
mapping used in the widget works on a power of two sampling and
maybe for certain slice orientations, your hardware / driver is having
issue with that.  Test with only 1 widget and do the
test 3 x with the plane orientation orthogonally different with each test.
Try one widget with the plane orientation non-orthognally aligned.
Also, when reporting issues with VTK, you should specify your build
environment (eg., VTK version, compiler, static/shared, debug/release,
basic hardware and OS
parameters such as RAM, GPU, CPU etc.).

- Dean

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

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