[vtkusers] vtkResliceImageViewer::SetInputData() slow when executed after vtkDICOMImageReader::Update()

David Gobbi david.gobbi at gmail.com
Thu Feb 15 09:56:14 EST 2018


Hi Panos,

I peeked at the vtkResliceImageViewer source code and I see that
its SetInputData() is not a simple setter method, it does a lot of work
internally.  This is very unusual for a VTK SetInputData() method.

Your hypothesis about GetScalarRange() seems to be mostly correct.
If things are done as follows, the SetInputData() method is fast:

reader->Update();
data->GetScalarRange();
viewer->SetInputData(data);

When GetScalarRange() is called, the result is cached so that when
it's called again from the viewer it's fast.

For case (3), I suspect that the viewer updates one slice of its input
(via streaming) before calling GetScalarRange().  So that's why it
would be fast in that case: the range is computed for just one slice,
instead of for the entire volume.

 - David


On Wed, Feb 14, 2018 at 8:24 AM, ochampao <ochampao at hotmail.com> wrote:

> Hi David and thanks for the detailed reply.
>
> Your reply makes clear the difference between "streaming" data vs. loading
> the whole volume in memory. However, with these in mind, I still can't
> explain the behaviour I observe in the minimal example that I have posted
> above (see [1], same code repeated below as well). Namely, if we assume
> that
> reader->Update() loads the whole volume in memory, then why calling
> resliceImageViewer->SetInputData(data) takes longer to complete if
> Update()
> is called at positions (1) or (2)?
>
> When stepping through the code to see what causes this delay (when Update()
> is called at position (1) or (2) ) I have noticed that execution spends
> most
> of its time at the following line:
>
>   in->GetScalarRange(range);
>
> of the function vtkResliceImageViewer::SetInputData(vtkImageData *in)
> (line
> 450 in vtkResliceImageViewer.cxx).
>
> I guess, since the image is not yet loaded (when Update() is called at (3)
> )
> calculating the scalar range on an "empty" image takes no time. It is as if
> in case (3) we are "cheating" and skipping the GetScalarRange()
> calculation.
> Doesn't GetScalarRange() get executed at some point even for case (3), and
> if yes, why does it take less time?
>
> Thanks,
> P.
>
> =======================
>
> [1]
> http://vtk.1045678.n5.nabble.com/vtkResliceImageViewer-
> SetInputData-slow-when-executed-after-vtkDICOMImageReader-Update-
> td5746409.html#a5746426
>
> =======================
>
> #include "vtkDICOMImageReader.h"
> #include "vtkImageData.h"
> #include "vtkInteractorStyleImage.h"
> #include "vtkRenderer.h"
> #include "vtkRenderWindow.h"
> #include "vtkRenderWindowInteractor.h"
> #include "vtkResliceImageViewer.h"
> #include "vtkSmartPointer.h"
>
> int main(int argc, char** argv)
> {
>     vtkNew<vtkDICOMImageReader> reader;
>     vtkNew<vtkResliceImageViewer> resliceImageViewer;
>     vtkNew<vtkRenderWindowInteractor> renderWindowInteractor;
>     vtkNew<vtkInteractorStyleImage> style;
>     vtkNew<vtkRenderWindow> renderWindow;
>     vtkNew<vtkRenderer> renderer;
>     vtkSmartPointer<vtkImageData> data;
>
>     renderWindow->AddRenderer(renderer);
>     renderer->SetBackground(0.0, 0.0, 0.0);
>     renderWindowInteractor->SetInteractorStyle(style);
>
>     reader->SetDirectoryName("path/to/dicom/series");
>     //reader->Update();  // --> (1) SetInputData() takes ~18 seconds
>     data = reader->GetOutput();
>     //reader->Update();  // --> (2) SetInputData() takes ~18 seconds
>
>     resliceImageViewer->SetInputData(data);
>     reader->Update();  // --> (3) SetInputData() takes less than 1 seconds
>     resliceImageViewer->SetRenderWindow(renderWindow);
>     resliceImageViewer->SetupInteractor(renderWindowInteractor);
>     resliceImageViewer->SetResliceModeToAxisAligned();
>     resliceImageViewer->SetSlice(50);
>     resliceImageViewer->SetColorLevel(-27);
>     resliceImageViewer->SetColorWindow(1358);
>
>     renderWindowInteractor->Start();
>
>     return 0;
> }
>
> =======================
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtkusers/attachments/20180215/0cc62e4e/attachment.html>


More information about the vtkusers mailing list