<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi, thanks for the info.<br>
    <br>
    I found the post that you linked to when I was looking at this and
    attempted to re-sample the data first using vtkImageReslice which
    gave me quite a bit of improvement, but there still seemed to be
    some re-sampling going on in the mapper. I am reluctant to do too
    much hard-coding of maximum texture sizes as this means that on
    newer cards we are not making maximum use of the hardware, so I
    didn't pursue modifying the source code.<br>
    <br>
    I have since come back to this and discovered the
    vtkSmartVolumeMapper class in VTK 5.8 which seems to do quite a lot
    of the work of selecting the appropriate mapper for the hardware and
    was obviously written by someone with much more experience of the
    volume mappers than me! Also, the performance of the volume mappers
    (and presumably the vtkVolumeTextureMapper3D used by the smart
    mapper internally) seems much improved in 5.8.<br>
    <br>
    Thanks for all the hard work.<br>
    <br>
    Ian<br>
    <br>
    On 13/09/2011 09:44, Simon ESNEAULT wrote:
    <blockquote
cite="mid:CAC9gB0Dk6JGwjb1z0a4yD6HPtUcNiqOiK6YvmaDOKbbZ6qi3FQ@mail.gmail.com"
      type="cite">Hi Ian,
      <div><br>
      </div>
      <div>See this mail :</div>
      <div><a moz-do-not-send="true"
href="http://public.kitware.com/pipermail/vtkusers/2010-November/112994.html">http://public.kitware.com/pipermail/vtkusers/2010-November/112994.html</a></div>
      <div><br>
      </div>
      <div>and this bug report<br>
        <div><a moz-do-not-send="true"
            href="http://vtk.org/Bug/view.php?id=11391">http://vtk.org/Bug/view.php?id=11391</a></div>
        <div><br>
        </div>
        <div>I bet it's the same "bug" that affect's you.&nbsp;</div>
        <div>With an ATI card, the only solution you've got in VTK for a
          GPU volume rendering is the&nbsp;vtkVolumeTextureMapper3D class,
          but you will need to hack a little bit to make it work
          properly (fast). See instruction in the link above.</div>
        <div><br>
        </div>
        <div>Good luck, do not hesitate if you need some help.</div>
        <div><br>
        </div>
        <div>Simon</div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>
          <div><br>
            <br>
            <div class="gmail_quote">On Mon, Jun 6, 2011 at 11:38, Ian
              Lindsay <span dir="ltr">&lt;<a moz-do-not-send="true"
                  href="mailto:ilindsay@insigniamedical.co.uk">ilindsay@insigniamedical.co.uk</a>&gt;</span>
              wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi, I
                hope someone with a bit of experience with the hardware
                renderers<br>
                in vtk can help me. Apologies in advance for the long
                post, but I want<br>
                to give as much detail as possible.<br>
                <br>
                We are developing a medical imaging application which
                will visualise<br>
                CT/MR data using various techniques - MIP, MPR, volume
                rendering etc. I<br>
                am currently experimenting with the
                vtkVolumeTextureMapper3D class, and<br>
                while its performance is great on an ATI Radeon 3870
                once it has<br>
                started, and even better on newer cards, it seems to
                take a long time to<br>
                initialise. I am seeing ~20-25 seconds for a 250 slice
                CT set, each<br>
                image being 512X512 pixels at 2 bytes per pixel. We are
                seeing 100% CPU<br>
                usage on one CPU of a dual core Intel Core-2 duo, which
                would seem to<br>
                suggest that the algorithm is not multi-threaded in this
                case if that is<br>
                of any help. Doing a break while debugging seems to
                generally end up in<br>
                the vtkVolumeTextureMapper3DComputeScalars function in<br>
                vtkVolumeTextureMapper3D.cxx, in a loop that looks like
                it is doing some<br>
                sort of re-sampling.<br>
                <br>
                The pipeline is a fairly standard one as far as I can
                see:<br>
                &nbsp;vtkImageData<br>
                -&gt; vtkImageChangeInformation<br>
                -&gt; vtkVolumeTextureMapper3D<br>
                -&gt; vtkVolume<br>
                -&gt; vtkRenderer<br>
                -&gt; vtkRenderWindow<br>
                <br>
                We also introduce a vtkImageFlip for flipped data sets
                (e.g. CT heads)<br>
                to get them back to DICOM orientation before the volume
                mapper, but this<br>
                seems to make very little difference.<br>
                <br>
                One point that may make a difference is that we are
                doing offscreen<br>
                rendering due to our application architecture
                requirements, but we get<br>
                very good performance with MPR implemented with
                vtkImageReslice, so I<br>
                suspect this is not the issue.<br>
                <br>
                I have tried experienting with the
                SetUseCompressedTexture(true)<br>
                setting, which seemed to make things a little more
                stable, I sometimes<br>
                ended up with blank images, or strange lighting on
                occasions before, but<br>
                this does not seem to help the initialisation time. I
                have also tried<br>
                the vtkGPUVolumeRayCastMapper, but this seems to use
                features only<br>
                supported by NVIDIA cards (correct me if this is wrong),
                whereas we have<br>
                found our medical imaging displays work best with ATI
                cards, so we tend<br>
                to use these in preference.<br>
                <br>
                Does anyone have any helpful advice on settings/pipeline
                layout or<br>
                alternative ray casters that I could try?<br>
                <br>
                Thanks,<br>
                Ian Lindsay<br>
                <br>
                <br>
                <br>
                CONFIDENTIALITY NOTICE<br>
                This message is only for the use of the intended
                individual or entity and may contain information that is
                confidential, or subject to copyright.<br>
                If you are not the intended recipient, you are hereby
                notified that any dissemination, copying or distribution
                of this message, or any associated files, is strictly
                prohibited.<br>
                If you have received this message in error, please
                notify us immediately by replying to the message, and
                delete it from your computer.<br>
                Messages sent to and from Insignia Medical Systems
                Limited may be monitored.<br>
                Any views or opinions presented are solely those of the
                author and do not necessarily represent those of the
                company.<br>
                <br>
                _______________________________________________<br>
                Powered by <a moz-do-not-send="true"
                  href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
                <br>
                Visit other Kitware open-source projects at <a
                  moz-do-not-send="true"
                  href="http://www.kitware.com/opensource/opensource.html"
                  target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
                <br>
                Please keep messages on-topic and check the VTK FAQ at:
                <a moz-do-not-send="true"
                  href="http://www.vtk.org/Wiki/VTK_FAQ" target="_blank">http://www.vtk.org/Wiki/VTK_FAQ</a><br>
                <br>
                Follow this link to subscribe/unsubscribe:<br>
                <a moz-do-not-send="true"
                  href="http://www.vtk.org/mailman/listinfo/vtkusers"
                  target="_blank">http://www.vtk.org/mailman/listinfo/vtkusers</a><br>
              </blockquote>
            </div>
            <br>
            <br clear="all">
            <div><br>
            </div>
            -- <br>
------------------------------------------------------------------<br>
            Simon Esneault
            <div>13 rue Vasselot<br>
              35000 Rennes, France<br>
              Tel : 06 64 61 30 94<br>
              Mail : <a moz-do-not-send="true"
                href="mailto:simon.esneault@gmail.com" target="_blank">simon.esneault@gmail.com</a><br>
------------------------------------------------------------------</div>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
  <BR />
<BR />
<HR />
CONFIDENTIALITY&nbsp;NOTICE<BR />
This&nbsp;message&nbsp;is&nbsp;only&nbsp;for&nbsp;the&nbsp;use&nbsp;of&nbsp;the&nbsp;intended&nbsp;individual&nbsp;or&nbsp;entity&nbsp;and&nbsp;may&nbsp;contain&nbsp;information&nbsp;that&nbsp;is&nbsp;confidential,&nbsp;or&nbsp;subject&nbsp;to&nbsp;copyright.&nbsp;<BR />
If&nbsp;you&nbsp;are&nbsp;not&nbsp;the&nbsp;intended&nbsp;recipient,&nbsp;you&nbsp;are&nbsp;hereby&nbsp;notified&nbsp;that&nbsp;any&nbsp;dissemination,&nbsp;copying&nbsp;or&nbsp;distribution&nbsp;of&nbsp;this&nbsp;message,&nbsp;or&nbsp;any&nbsp;associated&nbsp;files,&nbsp;is&nbsp;strictly&nbsp;prohibited.&nbsp;<BR />
If&nbsp;you&nbsp;have&nbsp;received&nbsp;this&nbsp;message&nbsp;in&nbsp;error,&nbsp;please&nbsp;notify&nbsp;us&nbsp;immediately&nbsp;by&nbsp;replying&nbsp;to&nbsp;the&nbsp;message,&nbsp;and&nbsp;delete&nbsp;it&nbsp;from&nbsp;your&nbsp;computer.&nbsp;<BR />
Messages&nbsp;sent&nbsp;to&nbsp;and&nbsp;from&nbsp;Insignia&nbsp;Medical&nbsp;Systems&nbsp;Limited&nbsp;may&nbsp;be&nbsp;monitored.&nbsp;<BR />
Any&nbsp;views&nbsp;or&nbsp;opinions&nbsp;presented&nbsp;are&nbsp;solely&nbsp;those&nbsp;of&nbsp;the&nbsp;author&nbsp;and&nbsp;do&nbsp;not&nbsp;necessarily&nbsp;represent&nbsp;those&nbsp;of&nbsp;the&nbsp;company.<BR />
</body>
</html>