<div dir="ltr">Hi Mathieu,<br><br>Thank you for your cooperation.<br>But, unfortunately, it failed.<br>Because the original code is as follows;<br><br><pre>> if ( size[0] > GL_MAX_TEXTURE_SIZE ||<br>> size[1] > GL_MAX_TEXTURE_SIZE )<br>
> {<br>> return 0;<br>> }<br><br>According to the above code, if the size[0] or size[0] exceed GL_MAX_TEXTURE_SIZE, <br>the gdcmviewer will be forced to stop.<br>But, the gdcmviewer haven't stoped with the large DICOM Data, yet.<br>
Then, I have to conclude that the above code is not the cause of the poor performance.<br></pre>What do you think of it?<br><br>Thanks,<br><br>Maty<br><br><div class="gmail_quote">2008/10/5 Mathieu Malaterre <span dir="ltr"><<a href="mailto:mathieu.malaterre@gmail.com">mathieu.malaterre@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Fri, Oct 3, 2008 at 11:52 AM, Mathieu Malaterre<br>
<<a href="mailto:mathieu.malaterre@gmail.com">mathieu.malaterre@gmail.com</a>> wrote:<br>
> 'lo<br>
><br>
> On Fri, Oct 3, 2008 at 11:41 AM, masabumi ishihara<br>
> <<a href="mailto:maty.ishihara@gmail.com">maty.ishihara@gmail.com</a>> wrote:<br>
>> Hi Mathieu,<br>
>><br>
>> Thank you for your splendid opinion.<br>
>> This time, we compareed two viewers' preformances.<br>
>> Unfortunately, the results are as follows;<br>
>><br>
>> CPU rate<br>
>> performance of moving<br>
>> gdcmviewer with release mode 50~60% slow<br>
>> our prototype viewer 50~60% real time<br>
>><br>
>> DICOM Data : LittleEndianExplicit 15,000 KB<br>
><br>
> hum... for a 2D slice ? This is not that small after all. Maybe you<br>
> are suffering from the non-power of two issue in OpenGL + texture.<br>
><br>
> What is the size of the image (it is printed in the output of<br>
> gdcmviewer). Something like:<br>
><br>
> ...<br>
> Bounds:<br>
> Xmin,Xmax: (0, 347.85)<br>
> Ymin,Ymax: (424.05, 848.1)<br>
> Zmin,Zmax: (0, 0)<br>
> Compute Time: 0<br>
> ScalarType: 5<br>
> NumberOfScalarComponents: 1<br>
> Spacing: (0.15, 0.15, 1)<br>
> Origin: (0, 424.05, 0)<br>
> Dimensions: (2320, 2828, 1)<br>
> Increments: (0, 0, 0)<br>
> Extent: (0, 2319, 0, 2827, 0, 0)<br>
> ...<br>
><br>
>> Can you believe the above results?<br>
>> Do you have any reason, e.g. memory sled ..., ?<br>
>> Our prototype viewer is simple 2D viewer, which doesn't have any interface<br>
>> to VTK, ITK GDCM.<br>
>> Then, we would like to use the other viewer for the future.<br>
>> But, it have to be real time operative.<br>
><br>
> Because this is not my area of knowledge, I'll have to ask other<br>
> people if there is anything to do to speed things up. Maybe some<br>
> OpenGL guru will answer...<br>
<br>
This is fixed in VTK CVS, backporting patch to VTK 5.2 do fix the<br>
issue also for me:<br>
<br>
<a href="http://public.kitware.com/cgi-bin/viewcvs.cgi/Rendering/vtkOpenGLImageActor.cxx?r1=1.37&r2=1.38&view=patch" target="_blank">http://public.kitware.com/cgi-bin/viewcvs.cgi/Rendering/vtkOpenGLImageActor.cxx?r1=1.37&r2=1.38&view=patch</a><br>
<br>
thanks to Francois !<br>
<br>
--<br>
<font color="#888888">Mathieu<br>
</font></blockquote></div><br></div>