Hi Brad,<div><br></div><div>Sorry, I didn't mention it but in this performance test I used ITK 3.16 patched in order to solve the bug related to the UpdateOutputInformation. The patch was applied based on your commit. The other versions are stock versions.</div>
<div><br></div><div>Roger</div><div><div><br></div><div><br><br><div class="gmail_quote">On Fri, May 14, 2010 at 1:05 PM, Bradley Lowekamp <span dir="ltr"><<a href="mailto:blowekamp@mail.nih.gov">blowekamp@mail.nih.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hello Roger,<br>
<br>
That looks like a nice table to look at for performance analysis!<br>
<br>
Are your versions of ITK stock? I am surprised at the results because of the bug that we fix related to the UpdateOutputInformation taking too long. I expected that to be costly in 3.16, but better in 3.18.<br>
<br>
Brad<br>
<div><div></div><div class="h5"><br>
On May 13, 2010, at 5:00 PM, Roger Bramon Feixas wrote:<br>
<br>
> Hi,<br>
><br>
> Recently we updated our ITK version from ITK 3.16 to ITK 3.18 and we decided to relink ITK with system GDCM 2.0. After some tests, we concluded ITK 3.18+GDCM 2.0 is faster than ITK 3.18 reading DICOM Little Endian files, however ITK 3.18+GDCM 2.0 is rather slower reading DICOM JPEG files. I attach a PDF file which is a time comparison of ITK 2.8, 3.16, 3.18 and 3.18+GDCM2.0 versions.<br>
><br>
> I don't know if it's just a GDCM problem or if it depends on how ITK uses GDCM.<br>
><br>
> Thanks for your attention,<br>
><br>
> Roger<br>
</div></div>> <Performance ITK + gdcm 2.pdf><ATT00001..txt><br>
<br>
</blockquote></div><br></div></div>