Hi Mark,<div><br></div><div>You can try using vtkImageShiftScale to remap your 16-bit data to 8-bit, it might be slightly faster than using vtkImageMapToColors.</div><div><br></div><div>  David<br><br><div class="gmail_quote">

On Fri, Dec 3, 2010 at 5:37 AM, endlosschleife1 <span dir="ltr">&lt;<a href="mailto:endlosschleife1@googlemail.com">endlosschleife1@googlemail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div>Hi David,</div>
<div> </div>
<div>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.</div>



<div> </div>
<div>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).</div>

<div><div></div><div class="h5">

<div> </div>
<div>Mark<br><br></div>
<div class="gmail_quote">2010/11/30 David Gobbi <span dir="ltr">&lt;<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>&gt;</span><br>
<blockquote class="gmail_quote" style="padding-left:1ex;margin:0px 0px 0px 0.8ex;border-left:#ccc 1px solid">Hi Mark, 
<div><br></div>
<div>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).</div>



<div><br></div>
<div>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-&gt;SetOutputFormatToLuminance() to ensure that it produces 8-bit greyscale images instead.</div>



<div><br></div><font color="#888888">
<div>  David</div></font>
<div>
<div></div>
<div>
<div><br></div>
<div><br>
<div class="gmail_quote">On Tue, Nov 30, 2010 at 9:56 AM, endlosschleife1 <span dir="ltr">&lt;<a href="mailto:endlosschleife1@googlemail.com" target="_blank">endlosschleife1@googlemail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="padding-left:1ex;margin:0px 0px 0px 0.8ex;border-left:#ccc 1px solid">It&#39;s possible that I&#39;m misinterpreting the performance results of my implementation and that applying the window level lookup table is actually not what makes the difference. I&#39;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. <br>


<br>If the window/level is not the issue, how much of a difference in performance drop for the vtkImageActor implementation would be expected?<br><br>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&#39;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.<br>


<br>Mark<br><br><br><br>
<div class="gmail_quote">2010/11/30 David Gobbi <span dir="ltr">&lt;<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>&gt;</span> 
<div>
<div></div>
<div><br>
<blockquote class="gmail_quote" style="padding-left:1ex;margin:0pt 0pt 0pt 0.8ex;border-left:rgb(204,204,204) 1px solid">
<div>On Tue, Nov 30, 2010 at 7:10 AM, endlosschleife1 <span dir="ltr">&lt;<a href="mailto:endlosschleife1@googlemail.com" target="_blank">endlosschleife1@googlemail.com</a>&gt;</span> wrote:</div>
<div><br>
<div class="gmail_quote">
<div>
<blockquote class="gmail_quote" style="padding-left:1ex;margin:0pt 0pt 0pt 0.8ex;border-left:rgb(204,204,204) 1px solid">
<div class="gmail_quote">
<div></div>
<div>I was actually looking for accelerated scaling, so this sounds like vtkActor2D is not be the right thing for that.</div></div></blockquote>
<div><br></div></div>
<div>For accelerated scaling, you need to use vtkImageActor. </div>
<div>
<div><br></div>
<blockquote class="gmail_quote" style="padding-left:1ex;margin:0pt 0pt 0pt 0.8ex;border-left:rgb(204,204,204) 1px solid">
<div class="gmail_quote">
<div>I&#39;m not sure, but it looks like my implementation probably doesn&#39;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).</div>


</div></blockquote>
<div><br></div></div>
<div>The vtkImageMapper doesn&#39;t have accelerated window/level either.  It does all the computations on the CPU and then uses glDrawPixels() to render the image.</div>
<div>
<div> </div>
<blockquote class="gmail_quote" style="padding-left:1ex;margin:0pt 0pt 0pt 0.8ex;border-left:rgb(204,204,204) 1px solid">
<div class="gmail_quote">
<div>I create a vtkWindowLevelTable, set the window and center, and then call build on the lut. Then I used it with a vtkImageMapToColors instance:</div>
<div> </div>
<div>vtkImageMapToColors *color = vtkImageMapToColors::New();</div>
<div>color-&gt;SetLookupTable(lut); // lut is the vtkWindowLevelTable</div>
<div>color-&gt;SetInput(...) // some vtkImageData</div></div></blockquote>
<div><br></div></div>
<div>Yes, that looks typical.  Make sure that you call table-&gt;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).</div>



<div><br></div>
<div>  David</div></div><br></div></blockquote></div></div></div><br></blockquote></div><br></div></div></div></blockquote></div><br>
</div></div></blockquote></div><br></div>