[vtkusers] Strange slowness with vtkImagePlaneWidget

Marco Sambin m.sambin at gmail.com
Thu Sep 5 05:45:14 EDT 2013


Hi Dean,

thanks again for your reply and time.

Testing with only one vtkImagePlaneWidget at a time did not produce changes
in the observed behavior: rendering on the old PC is still slow if the
input volume is made up of fewer slices, and fast if the input volume is
made up of more slices (i.e., larger).

Here is some info about my test environment:

VTK 6.0, compiled with Visual Studio 2008, 32-bit, MinSizeRel build config,
shared

The "old PC" has the following configuration:

Pentium 4, 3 GHz, 1 GB RAM
Two graphic cards: Intel Express (?) card 64 MB video memory driving the
primary color monitor + Barco 1MP2FH dual-head card driving two Barco
Coronis grayscale diagnostic monitors
Window XP Pro SP2 32-bit

Digging further, I discovered something interesting: trying to run the same
test on the primary color monitor (i.e., the one driven by the "stock"
Intel Express card), initially I had similar results: with the "smaller"
volume, NOTHING was displayed inside my vtkCanvas panel (totally empty);
with the "larger" volume, the three widget planes were displayed correctly
and interacted at good performances. While the cause of this behavior still
is very obscure to me, on this primary color monitor all issues disappeared
after an update of the driver of the Intel Express graphics card: with the
new driver, the widgets appear and work fine with both the small volume and
the large volume.

Unfortunately, I cannot find updated device drivers for the Barco graphics
card, so I am unable to test if updating drivers will fix the behavior also
on the diagnostic monitors.

However, once I am conviced that the really weird behavior I observed can
be marked as a "device driver issue", I am satisfied.

Any comments will be appreciated.
Thanks in advance.

Marco

On Wed, Sep 4, 2013 at 7:10 PM, Dean Inglis <inglis.dl at gmail.com> wrote:

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


More information about the vtkusers mailing list