regression in dcmtk-3.5.5_20091222 from 3.5.4 ubuntu package

[semi-newbie]

Earlier today I compiled the latest snapshot (3.5.5_20091222) of DCMTK. However, when I attempt to substitute the newly compiled storescp for the older one, my image transfer fails early.

I am using Ubuntu 9.10, with the following packages installed (listing just those that are specifically related to my attempt to use dcmtk):

[prepackaged]
dcmtk
libdcmtk1

[for compiling dcmtk against]
libssl-dev
zlib1g-dev
libtiff4-dev
libxml2-dev
libwrap0-dev
libpng12-dev
libjpeg62-dev
libtiffxx0c2

I was able to build and install dcmtk, and by invoking 'commandname --version' for several of dcmtk's commands, I was able to verify that the third-party libraries were found during compilation.

I am running storescp from xinetd as so (manually copied, so typos are possible):

service storescp
{
socket_type = stream
protocol = tcp
port = 10009
type = UNLISTED
wait = no
user = root
#server = /usr/bin/storescp
server = /opt/dcmtk-3.5.5_20091222/bin/storescp
server_args = --inetd --prefer-jpeg12 --prefer-jpeg8 --access-full --max-pdu 131072 --aetitle MYAETITLE --eostudy-timeout 30 --sort-conc-studies migrated_on --filename-extension .dcm --output-directory /srv/my_images_directory 10009
}

When I use /usr/bin/storescp, the directory /srv/my_images_directory/migrated_on_20091227_123456789 is created, and each file is properly transferred and saved as /srv/my_images_directory/migrated_on_20091227_123456789/US.1.2.blah.blah.blah.blah.blah.blah.blah.1.##.dcm (where ## is the nth image in the study, and each blah represents a pack of one or more digits).

However, when I attempt to use the newly-compiled /opt/dcmtk-3.5.5_20091222/bin/storescp, I instead get weird behaviour. Instead of the directory /srv/my_images_directory/migrated_on_20091227_123456789 being created, the directory /srv/my_images_directory/migrated_on_20091227_123456789.blah.blah.1.1.dcm is created (each blah here is a pack of one or more digits also). The transfer fails, and no files whatsoever are stored within this directory.

The sort-conc-studies directory is created with an odd name that appears to be a hybrid of what it ought to be named and the name of the first file that should be being stored within it once it has been created.

[Jörg Riesmeier]

I can confirm that there seems to be a bug in the current snapshot regarding the --sort-conc-studies option. We will check this as soon as we are back in our office, i.e. probably next week.

Btw, using option --prefer-jpeg12 in conjunction with --prefer-jpeg8 makes no sense since they are mutually exclusive. In case you would like to accept multiple compression schemes, you should use an appropriate association negotiation profile (see documentation for details).

[Uli Schlachter]

The patch from viewtopic.php?t=2367 should fix this one, too. Alternatively you can wait for the next snapshot.

[semi-newbie]

The patch from viewtopic.php?t=2367 should fix this one, too. Alternatively you can wait for the next snapshot.

Thank you for releasing a new snapshot (20100114) with an attempted fix. I have just tried it out. Now, the subdirectory is successfully created, and images are successfully captured and saved within it. However, there still appears to be a problem with the naming of the files that are stored inside the subdirectory.

Each stored file used to begin with US.1.2., but now some of them begin with USm.1.2. instead. The number of files stored with USm instead of US in their name varies with the study being transferred, though I did not transfer the same study twice to detect if there are changes even in that case. Based on the CHANGES notes on the prior remedial action, I believe that there may be another string handling bug: my wild guess is that the software sometimes picks up a leftover "m" from either a prior or the current filename extension option, which in my case is set to dcm.

Also, the file contents of the current snapshot are slightly different than what was delivered by 3.5.4. Generally, they are approximately the same size (within 0.1%). When displayed on-screen, the images are not visibly different to the untrained (non-physician) eye. If I were to turn all compression off for transfers between the current release version (3.5.4) and the current snapshot, should the images received be byte-for-byte identical? Or, would that be an invalid test?

[Jörg Riesmeier]

The "USm" is not another bug ... see CHANGES entry from 2007.07.11:

Code: Select all

- Changed the modality codes used for filename generation for the current and
  retired ultrasound multiframe SOP classes to USm and USf, respectively.
  Affects: dcmdata/libsrc/dcuid.cc

With regard to the byte-by-byte comparison: The DICOM encoding allows for some deviations which are regarded as being non-significant (e.g. padding or presence of group length elements). Also the version number in the meta-header will be different ...

[semi-newbie]

The "USm" is not another bug ... see CHANGES entry from 2007.07.11:

Code: Select all

- Changed the modality codes used for filename generation for the current and
  retired ultrasound multiframe SOP classes to USm and USf, respectively.
  Affects: dcmdata/libsrc/dcuid.cc

With regard to the byte-by-byte comparison: The DICOM encoding allows for some deviations which are regarded as being non-significant (e.g. padding or presence of group length elements). Also the version number in the meta-header will be different ...

Okay, it's great to know that the "USm" is actually intended behaviour. Also, having that distinction captured in the filename is a nice feature. Thanks!

I can also confirm that "--sort-on-patientname" is now also working. That had been failing on the last snapshot, and I was going to report it as a bug until I noticed that even the --sort-conc-studies that had previously been working was failing, so I reported that problem instead. The breakage was quite similar and I figured the fix would likely be the same.