[Insight-users] Performance regression in ITK + gdcm 2.0 reading DICOM JPEG files
Roger Bramon Feixas
rogerbramon at gmail.com
Tue Jun 1 15:40:31 EDT 2010
Hi Mathieu,
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.
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. 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().
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:
- 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.
- Using the trunk version even though it isn't stable, or
- waiting for GDCM 2.1 if it will be released soon.
I will try to test it on Windows tomorrow and send you the time results.
Many thanks!
Roger
On Mon, May 31, 2010 at 11:21 PM, Mathieu Malaterre <
mathieu.malaterre at gmail.com> wrote:
> Hi Roger,
>
> Yes ! I finally found some time, Snakes on a Plane gave this opportunity
> ;)
>
> I think I made some progress with the JPEG DICOM file. JPEG 2000
> files will be slightly more difficult. See log at:
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=3009661&group_id=137895&atid=739587
>
> For reference, this issue entered GDCM 2.x, when handling the
> lossy/lossless duality of J2K and JPEG-LS in DICOM. I am required to
> know after ExecuteInformation whether the encapsulated JPEG fragment
> was compressed with lossy algorithm (this is not indicated in the
> DICOM dataset).
>
> Could you please confirm this on your side (again JPEG 2000 will
> take me some more time) ?
>
> Thanks again for your report
>
> On Fri, May 28, 2010 at 12:00 AM, Roger Bramon Feixas
> <rogerbramon at gmail.com> wrote:
> > Hi,
> > Have you had time to think about the causes of the performance regression
> > problem? I can work on it, but I would like to have, if you have it, some
> > information which helps me to know where I need to focus the effort.
> >
> > Thanks,
> > Roger
> >
> > On Tue, May 18, 2010 at 9:14 AM, Roger Bramon Feixas <
> rogerbramon at gmail.com>
> > wrote:
> >>
> >> Hi Mathieu,
> >> Perhaps, the answer of question 3 wasn't so clear:
> >> ITK versions:
> >> - CMAKE_BUILD_TYPE:RelWithDebInfo
> >> - BUILD_SHARED_LIBS: OFF
> >> GDCM: Release from http://gdcm.sourceforge.net
> >> Test program: Release.
> >> Compiling the test program in Debug mode, it takes more time but we also
> >> have large differences between GDCM 1.2.x and GDCM 2.0.
> >>
> >> Roger
> >> On Mon, May 17, 2010 at 11:50 PM, Roger Bramon Feixas
> >> <rogerbramon at gmail.com> wrote:
> >>>
> >>> Hi Mathieu,
> >>> Thanks for your attention. I answer your questions:
> >>> 1. What is your platform ?
> >>> I used a Windows XP 32bits to do the test. However, this behaviour also
> >>> occurs in Mac OS X platform.
> >>> 2. What is your compiler ?
> >>> All ITK versions were compiled with Visual Studio 2008 and we
> downloaded
> >>> GDCM 2.0.14 binary from http://gdcm.sourceforge.net
> >>> 3. What are your compiler option (eg. I hope you do not run bench
> >>> without CMAKE_BUILD_TYPE:Release) ?
> >>> RelWithDebInfo
> >>> 4. Where is the dataset used ?
> >>> Dataset 5 is from OSIRIX: http://pubimage.hcuge.ch:8080/DATA/CALIX.zip
> >>> -> CALIX/CT1 abdomen/D30MN BILISCOPIN
> >>> We are really interested to improve the time needed to load jpeg
> lossless
> >>> datasets. The jpeg lossless datasets used are non-anonymized datasets,
> I
> >>> will try to anonymize them if you want them.
> >>> 5. Where is the source code used ?
> >>> I attach it in this mail.
> >>>
> >>> Thanks!
> >>> Roger
> >>> On Mon, May 17, 2010 at 10:44 PM, Mathieu Malaterre
> >>> <mathieu.malaterre at gmail.com> wrote:
> >>>>
> >>>> Hi Roger,
> >>>>
> >>>> This is a very interesting post !
> >>>>
> >>>> On Thu, May 13, 2010 at 11:00 PM, Roger Bramon Feixas
> >>>> <rogerbramon at gmail.com> wrote:
> >>>> > Hi,
> >>>> > 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.
> >>>> > I don't know if it's just a GDCM problem or if it depends on how ITK
> >>>> > uses
> >>>> > GDCM.
> >>>>
> >>>> GDCM Reading
> >>>> UpdateOutput- UpdateLargest-
> >>>> Data ITK version version directory Information
> >>>> PossibleRegion
> >>>>
> >>>>
> >>>> 5 2,8 1,2 642
> >>>> 6 20153
> >>>> 3,16 1,2 547
> >>>> 0 25121
> >>>> 3,18 1,2 547
> >>>> 0 25124
> >>>> 3,18 2 25297
> >>>> 187 71437
> >>>>
> >>>>
> >>>>
> >>>> Data Transfer syntax Modality Files
> >>>> Size (MB)
> >>>>
> >>>> 5 JPEG 2000 CT
> >>>> 243 23
> >>>>
> >>>>
> >>>>
> >>>> Could you please post a little bit more on :
> >>>> 1. What is your platform ?
> >>>> 2. What is your compiler ?
> >>>> 3. What are your compiler option (eg. I hope you do not run bench
> >>>> without CMAKE_BUILD_TYPE:Release) ?
> >>>> 4. Where is the dataset used ?
> >>>> 5. Where is the source code used ?
> >>>>
> >>>> Thanks a bunch !
> >>>> --
> >>>> Mathieu
> >>>
> >>
> >
> >
>
>
>
> --
> Mathieu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20100601/2e077fe9/attachment-0001.htm>
More information about the Insight-users
mailing list