[Insight-users] Performance regression ImageSeriesReader? (with test)

[Mathieu Malaterre]

Hi there,

  I was explicitely CC on this message so I am guessing I need to say
something...

On Mon, Mar 22, 2010 at 9:20 PM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
>
> On Mar 22, 2010, at 1:17 PM, Roger Bramon Feixas wrote:
>
> Bradley,
> I did the test using a computer which has Itel Core 2 Quad 2.4 GHz CPU with
> 4GB RAM. The OS is Windows XP 32bits. The data is on locale. During the
> execution one of the CPU's is 100% full.
> I did the test using 3 CT models:
> Head CT (http://mri.radiology.uiowa.edu/VHDicom/VHFCT1mm/VHF-Head.tar.gz)
>                 Reading directory   UpdateOutputInformation
> UpdateLargestPossibleRegion
> Itk 2.8                       390                         4
>            1409
> Itk 3.16                      394                       452
>            1502
>
> 123MB
> 234 files
> 6% gain in UpdateData
> an additional 30% from UpdateOutputInformation
>
> ________________________________________
> CT example study which we work with
> (http://dl.dropbox.com/u/3613789/ct_anonymized.zip)
>                 Reading directory   UpdateOutputInformation
> UpdateLargestPossibleRegion
> Itk 2.8                      1024                         9
>            2260
> Itk 3.16                     1030                      1666
>            2975
>
> 130MB
> 243 files
> 30% gain in UpdateData
> an additional 56% from UpdateOutputInformation
>
> _________________________________________
> CALIX/CT1 abdomen/D30MN BILISCOPIN from OSIRIX Data
> (http://pubimage.hcuge.ch:8080/DATA/CALIX.zip)
>                 Reading directory   UpdateOutputInformation
> UpdateLargestPossibleRegion
> Itk 2.8                       660                         7
>           20380
> Itk 3.16                      652                       850
>           21053
>
> 25MB
> 238 files
> 3% gain in UpdateData
> an additional 4% from UpdateOutputInformation
> Clearly the additional read of the metadata in UpdateOutputInformation is
> part cause of of the slow down.
> However there are a lot of odd performance numbers here. Why is OSIRIX data
> so slow? Why is the CT example's directory reading and UpdateData so slow? I
> don't know enough about the DICOM format to know if there are different
> forms of compression affecting things here or what. If the header is
> compressed, then the update of the meta data is clearly going to be a more
> computation intensive. Or perhaps it's the size or number of entries of the
> meta data ( which I didn't check ) causing the performance difference.

You are comparing:

$ gdcminfo IMG00000_an
MediaStorage is 1.2.840.10008.5.1.4.1.1.2 [CT Image Storage]
TransferSyntax is 1.2.840.10008.1.2 [Implicit VR Little Endian:
Default Transfer Syntax for DICOM]

With:

$ gdcminfo CALIX/CALIX/CT1 abdomen/D30MN BILISCOPINIM-0001-0001.dcm
MediaStorage is 1.2.840.10008.5.1.4.1.1.2 [CT Image Storage]
TransferSyntax is 1.2.840.10008.1.2.4.91 [JPEG 2000 Image Compression]


J2K is a pretty decent compression algorithm, unfortunately it is one
of the slowest.
Try gdcmraw --raw input.dcm output.uncompressed.dcm

Cheers
-- 
Mathieu