Hi,<div><br></div><div>I attach the test results on Windows. We can observe that trunk version is about 2x faster compared to gdcm2.0.14, however gdcm1.2 is still 2x faster than trunk version. </div><div><br></div><div>I'm looking forward your answers and let's me know if you need some help.</div>
<div><br></div><div>Thanks,</div><div><br></div><div>Roger<br><br><div class="gmail_quote">On Tue, Jun 1, 2010 at 9:40 PM, Roger Bramon Feixas <span dir="ltr"><<a href="mailto:rogerbramon@gmail.com">rogerbramon@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Mathieu,<div><br></div><div>Thanks for you time! I just tested it on Mac OS X (I will also test it on Windows soon) and there is a really nice performance improvement, about 2x. </div>
<div><br></div><div>However, I have two code comments: First, there is an abort() at line 350 of gdcmBitmap.cxx which causes a crash, I commented it to be able to test it. <span style="font-family:arial, sans-serif;font-size:13px;white-space:pre-wrap">The other problem is related to the use of gdcm::PixelFormat::UINT8 at line 342 of gdcmBitmap.cxx. If you're working with JPEG files and its pixel format is more than 8 bits, a downscale has to be done. Perhaps, it could be replaced for GetPixelFormat().</span></div>
<div><font face="arial, sans-serif"><span style="white-space:pre-wrap"><br></span></font></div><div><span style="font-size:13px"></span><font face="arial, sans-serif"><span style="white-space:pre-wrap">On the other hand, we want to include this commit in our GDCM compilation but I would like to know which is the best way:</span></font></div>
<div><font face="arial, sans-serif"><span style="white-space:pre-wrap"> - <span style="font-size:13px">Using GDCM 2.0.14 patched. It's the last stable version but I don't know if patch it is a good idea because some changes have been done.</span></span></font></div>
<div><font face="arial, sans-serif"><span style="white-space:pre-wrap"> - Using the trunk version even though it isn't stable, or</span></font></div><div><font face="arial, sans-serif"><span style="white-space:pre-wrap"> - waiting for GDCM 2.1 if it will be released soon.<br>
</span></font><br></div><div>I will try to test it on Windows tomorrow and send you the time results.</div><div><br></div><div>Many thanks!</div><div><br></div><font color="#888888"><div>Roger</div></font><div><div></div>
<div class="h5"><div><br></div><div><br><div class="gmail_quote">
On Mon, May 31, 2010 at 11:21 PM, Mathieu Malaterre <span dir="ltr"><<a href="mailto:mathieu.malaterre@gmail.com" target="_blank">mathieu.malaterre@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Roger,<br>
<br>
Yes ! I finally found some time, Snakes on a Plane gave this opportunity ;)<br>
<br>
I think I made some progress with the JPEG DICOM file. JPEG 2000<br>
files will be slightly more difficult. See log at:<br>
<a href="http://sourceforge.net/tracker/index.php?func=detail&aid=3009661&group_id=137895&atid=739587" target="_blank">http://sourceforge.net/tracker/index.php?func=detail&aid=3009661&group_id=137895&atid=739587</a><br>
<br>
For reference, this issue entered GDCM 2.x, when handling the<br>
lossy/lossless duality of J2K and JPEG-LS in DICOM. I am required to<br>
know after ExecuteInformation whether the encapsulated JPEG fragment<br>
was compressed with lossy algorithm (this is not indicated in the<br>
DICOM dataset).<br>
<br>
Could you please confirm this on your side (again JPEG 2000 will<br>
take me some more time) ?<br>
<br>
Thanks again for your report<br>
<br>
On Fri, May 28, 2010 at 12:00 AM, Roger Bramon Feixas<br>
<div><div></div><div><<a href="mailto:rogerbramon@gmail.com" target="_blank">rogerbramon@gmail.com</a>> wrote:<br>
> Hi,<br>
> Have you had time to think about the causes of the performance regression<br>
> problem? I can work on it, but I would like to have, if you have it, some<br>
> information which helps me to know where I need to focus the effort.<br>
><br>
> Thanks,<br>
> Roger<br>
><br>
> On Tue, May 18, 2010 at 9:14 AM, Roger Bramon Feixas <<a href="mailto:rogerbramon@gmail.com" target="_blank">rogerbramon@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi Mathieu,<br>
>> Perhaps, the answer of question 3 wasn't so clear:<br>
>> ITK versions:<br>
>> - CMAKE_BUILD_TYPE:RelWithDebInfo<br>
>> - BUILD_SHARED_LIBS: OFF<br>
>> GDCM: Release from <a href="http://gdcm.sourceforge.net" target="_blank">http://gdcm.sourceforge.net</a><br>
>> Test program: Release.<br>
>> Compiling the test program in Debug mode, it takes more time but we also<br>
>> have large differences between GDCM 1.2.x and GDCM 2.0.<br>
>><br>
>> Roger<br>
>> On Mon, May 17, 2010 at 11:50 PM, Roger Bramon Feixas<br>
>> <<a href="mailto:rogerbramon@gmail.com" target="_blank">rogerbramon@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi Mathieu,<br>
>>> Thanks for your attention. I answer your questions:<br>
>>> 1. What is your platform ?<br>
>>> I used a Windows XP 32bits to do the test. However, this behaviour also<br>
>>> occurs in Mac OS X platform.<br>
>>> 2. What is your compiler ?<br>
>>> All ITK versions were compiled with Visual Studio 2008 and we downloaded<br>
>>> GDCM 2.0.14 binary from <a href="http://gdcm.sourceforge.net" target="_blank">http://gdcm.sourceforge.net</a><br>
>>> 3. What are your compiler option (eg. I hope you do not run bench<br>
>>> without CMAKE_BUILD_TYPE:Release) ?<br>
>>> RelWithDebInfo<br>
>>> 4. Where is the dataset used ?<br>
>>> Dataset 5 is from OSIRIX: <a href="http://pubimage.hcuge.ch:8080/DATA/CALIX.zip" target="_blank">http://pubimage.hcuge.ch:8080/DATA/CALIX.zip</a><br>
>>> -> CALIX/CT1 abdomen/D30MN BILISCOPIN<br>
>>> We are really interested to improve the time needed to load jpeg lossless<br>
>>> datasets. The jpeg lossless datasets used are non-anonymized datasets, I<br>
>>> will try to anonymize them if you want them.<br>
>>> 5. Where is the source code used ?<br>
>>> I attach it in this mail.<br>
>>><br>
>>> Thanks!<br>
>>> Roger<br>
>>> On Mon, May 17, 2010 at 10:44 PM, Mathieu Malaterre<br>
>>> <<a href="mailto:mathieu.malaterre@gmail.com" target="_blank">mathieu.malaterre@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Hi Roger,<br>
>>>><br>
>>>> This is a very interesting post !<br>
>>>><br>
>>>> On Thu, May 13, 2010 at 11:00 PM, Roger Bramon Feixas<br>
>>>> <<a href="mailto:rogerbramon@gmail.com" target="_blank">rogerbramon@gmail.com</a>> wrote:<br>
>>>> > Hi,<br>
>>>> > Recently we updated our ITK version from ITK 3.16 to ITK 3.18 and we<br>
>>>> > decided<br>
>>>> > to relink ITK with system GDCM 2.0. After some tests, we concluded ITK<br>
>>>> > 3.18+GDCM 2.0 is faster than ITK 3.18 reading DICOM Little Endian<br>
>>>> > files,<br>
>>>> > however ITK 3.18+GDCM 2.0 is rather slower reading DICOM JPEG files. I<br>
>>>> > attach a PDF file which is a time comparison of ITK 2.8, 3.16, 3.18<br>
>>>> > and<br>
>>>> > 3.18+GDCM2.0 versions.<br>
>>>> > I don't know if it's just a GDCM problem or if it depends on how ITK<br>
>>>> > uses<br>
>>>> > GDCM.<br>
>>>><br>
>>>> GDCM Reading<br>
>>>> UpdateOutput- UpdateLargest-<br>
>>>> Data ITK version version directory Information<br>
>>>> PossibleRegion<br>
>>>><br>
>>>><br>
>>>> 5 2,8 1,2 642<br>
>>>> 6 20153<br>
>>>> 3,16 1,2 547<br>
>>>> 0 25121<br>
>>>> 3,18 1,2 547<br>
>>>> 0 25124<br>
>>>> 3,18 2 25297<br>
>>>> 187 71437<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Data Transfer syntax Modality Files<br>
>>>> Size (MB)<br>
>>>><br>
>>>> 5 JPEG 2000 CT<br>
>>>> 243 23<br>
>>>><br>
>>>><br>
>>>><br>
>>>> Could you please post a little bit more on :<br>
>>>> 1. What is your platform ?<br>
>>>> 2. What is your compiler ?<br>
>>>> 3. What are your compiler option (eg. I hope you do not run bench<br>
>>>> without CMAKE_BUILD_TYPE:Release) ?<br>
>>>> 4. Where is the dataset used ?<br>
>>>> 5. Where is the source code used ?<br>
>>>><br>
>>>> Thanks a bunch !<br>
>>>> --<br>
>>>> Mathieu<br>
>>><br>
>><br>
><br>
><br>
<br>
<br>
<br>
</div></div>--<br>
<font color="#888888">Mathieu<br>
</font></blockquote></div><br></div>
</div></div></blockquote></div><br></div>