Upgrading 3.6.1 (via aptitude) to 3.6.2

[bnoeafk]

All,
I've been struggling a little to get DCMTK 3.6.1 upgraded to 3.6.2 (for BT support). I'm working on Ubuntu Server 14.04.5 LTS and installed dcmtk using "apt-get install -y dcmtk". This has worked extensively for me for a while now, but with no presentation context for BT studies, I now require 3.6.2, however the latest repos have is still 3.6.1.

I went ahead and downloaded the 3.6.2 tarball from the WWW site for Debian based systems and over wrote the files in /usr/bin. When attempting to run most commands, I get a missing dicom.dic file, asking me to check my DCMDICTPATH environment variable. As I'm operating in a server environment, and checking /etc/environment to ensure that nothing was set up there, I've been reading through the forum and noted that the dicom.dic file should be placed in the datadir, that being the folder where the rest of the executables reside (and that still being /usr/bin). In the download, the newer dicom.dic file was located in /usr/local/share/dcmtk, so I created a link from /usr/bin/dicom.dic to that file.

Still no joy.

So I took a leap of faith , removed dcmtk completely from the system and then compiled it on the server itself, with the --prefix option. Once that's been done, I still don't have a dicom.dic, but finding it in the "data" compile folder, I copied that to /usr/bin and tried again.

Still no joy.

Now one thread a read about 2 hours ago mentioned that on Debian, when setting the --prefix folder, there are certain "gotchas" - but that was for 3.5.2 ... but it appears that there are still some gotchas even on 3.6.2? I will try and re-compile without the "--prefix" setting and see where I get with that, but is there not:

1. An easier upgrade path when initially using the repos and then over-writing with the 3.6.2 tarball?
2. A working 3.6.2 build for Debian that works even when the --prefix option is set?

This is still AMAZING software and my hat is constantly raised to OFFIS for all of their work for this toolkit, and please read this as an interested party, rather than a frustrated one : just looking for some guidance!!

Thanks,


BNOEAFK

[bnoeafk]

Of all options, it would appear that this can only be done by setting the DCMDICTPATH environment variable. I have tried the following on multiple instances of Ubuntu server 14.04.5LTS:

1. With no DCMTK installed, successfully compiled DCMTK with no options, which places binaries in /usr/local/bin
2. With no DCMTK installed, successfully compiled DCMTK with --prefix=/usr which places binaries in /usr/bin
3. With DCMTK installed via "apt-get" (installs 3.6.0), downloaded the executable binaries with static linking and over-wrote the files. All utilities complain about missing dicom.dic unless the DCMDICTPATH is exported (and when it is exported, it's happily pointing to the newly extracted file residing at /usr/share/dcmtk/dicom.dic). This obviously shows that using the new dicom.dic file (irrespective of whether or not it's different from the original) works just fine.
4. From the above, unsetting the environment and then copying dicom.dic to (most obvious) "<datadir>" folders and attempting to run the utilities, again complains about the missing dicom.dic

From the help, in particular dcmodify in this case, it states (most pertinent placed in bold, I'm not shouting ) :

ENVIRONMENT
The dcmodify utility will attempt to load DICOM data dictionaries specified in the DCMDICTPATH environment
variable. By default, i.e. if the DCMDICTPATH environment variable is not set, the file <datadir>/dicom.dic will
be loaded unless the dictionary is built into the application (default for Windows).

The default behavior should be preferred and the DCMDICTPATH environment variable only used when alternative data
dictionaries are required. The DCMDICTPATH environment variable has the same format as the Unix shell PATH
variable in that a colon (':') separates entries. On Windows systems, a semicolon (';') is used as a separator.
The data dictionary code will attempt to load each file specified in the DCMDICTPATH environment variable. It is
an error if no data dictionary can be loaded.

I've multiple copies of dicom.dic now, every time copying it to a new location and checking dcmodify to see if it balks, and it does. I've currently tried:

• /usr/local/bin/dicom.dic
• /usr/bin/dicom.dic
• /usr/share/dcmtk/dicom.dic
• /usr/share/libdcmtk2/dicom.dic
• /usr/share/dicom.dic

So, I'm guessing that my question is now : where, in Ubuntu, would the DCMTK refer to as being the "<datadir>"?

[bnoeafk]

(I can confirm that if I get all my build utilities installed, I can compile DCMTK 3.6.2 over the top of 3.6.0) which solves my problem. However, I can't help but think that it's seems quite a laborious task when documentation states that a much simpler approach is possible, using the yet to be discovered "<datadir>". Henceforth, my question still stands : what folder does DCMTK think is its' datadir?

[Michael Onken]

Hi,

before trying anything else:

Find one of your dicom.dic files (no matter which one, e.g. "/my/dcmtk/folder/dicom.dic"), open a terminal and set the environment variable to this file via:

Code: Select all

export DCMDICTPATH="/my/dcmtk/folder/dicom.dic"

Run the utility, do this in the same terminal window where you set the environment variable.

Best,
Michael

[bnoeafk]

Michael,
Good to hear from you again - it's been a while!

Yes, when I export the DCMDICTPATH which points to the (newer) dicom.dic, everything works as expected (and when running in debug mode, states the dicom.dic being used is the one that I exported). Whilst this is a workaround, I would much prefer not to use environment variables, especially when it's stated that I just need to place the file in the <datadir>. One thing that may or may not make any difference, is that I did use "git clone" in order to obtain DCMTK 3.6.2, instead of the source files downloadable from the web site (I will test out these too this weekend, and report back). Thought it was worth mentioning, just in case perhaps that version hasn't been fully released yet?

After more checking this weekend, I've come up with the only possible upgrade that I can see possible and appears to work consistently and that is to compile DCMTK 3.6.2 over the top of the original 3.6.0, using either the downloadable source files from the web site, or through git clone (the latter of which reports back a version of "3.6.2 DEV").

OFFIS : during the installation of the dcmtk from aptitude, it also installs libdcmtk2. I will be checking later to see what happens if, after over-writing 3.6.0 with 3.6.2 as described above, I then use "apt-get remove dcmtk" and subsequently "apt-get autoremove" which will remove other libraries (libcharls1 libdcmtk2 libjbig0 libjpeg-turbo8 libjpeg8 libtiff5). I'm unsure if libdcmtk2 is still required, but I'm guessing not.

Finally - as noted in the initial post, I'm attempting to use storescu to send a BT but just noticed that BT isn't supported even in storescu's v3.6.2 SOP Classes (I was under the impression that it was, for some reason). Does DCMTK not have a way of sending BT's as an SCU? I'm getting a No presentation context error, similar to this post, so I'm wondering - in order to send BT, do I need a custom storescu.cfg file?

[Michael Onken]

Hi,

I will have a closer look of your upgrade problem within the next days and provide feedback on this.

For your remaining storescu Breast Tomosynthesis transfer problem: You have 3 options to work around this:

• Try storescu's --required (-R) option.
• Alternatively, you can use a configuration file (-xf option, sample storescu.cfg included in dcmtk).
• Finally, use dcmsend instead.

Background: The reason for not allowing all known SOP Classes per default in storescu is that the number of possible SOP Classes to be negotiated is limited in DICOM to 128. Due to storescu's strategy to use two proposals per SOP Class it can only negotiate 64, which is less the number of Storage SOP classes defined in DICOM. Thus, storescu is configured to only propose those that are the most commonly used (as we decided;)) subset of all possible SOP classes, with BT not being included per default. storescu in default mode does not look into the files but first proposes all SOP Classes it can handle, *then* opens the file(s) and prints an error if it realizes the SOP Class needed has not been proposed. Yes, that's not very smart. The -R option is smarter: It looks into the file(s) and then proposes only the required SOP Classes on that basis.

dcmsend works similar as storescu with -R option and also has other feature, e.g. use multiple connections if required, or to decompress files when needed.

HTH,
Michael

[bnoeafk]

Michael,
Many thanks for the explaining the inner workings ... makes sense now why I was running into those errors ... and of course, now the "-R" switch with storescu makes much more sense to me. Additionally, adding that switch does exactly what it says it does, and I'm no longer running into issues with missing presentation contexts - many, many thanks again for your continued support of this excellent toolkit.

Slight after thought : if "storescu -R ... file1 file2 file3" (where each file has differing SOPClassUIDs), does storescu collate each SOP and present them to the SCP within the same connection?

With regards to the upgrading, I was thinking of putting together a flow diagram that outlines my findings thus far, if that would be of any help. Also, please do reach out if there's anything that you believe I could assist with, I would be more than happy to help out in any way.

[Michael Onken]

Hi,

I think the upgrading should normally work out of the box, so something else must have went wrong at your side. To be sure that the error is not in the Linux binaries hosted on the OFFIS website, I want to have a look at those first, but I have no time for it now (thus later). However, if you draw the diagram for yourself anyway, feel free to post it, I'm sure it will be help for some future readers

Yes, storescu collects the infos from the files and then tries to send them over a single connection. If there are more SOP Classes in the files than it is possible to negotiate (not very likely, unless you want to migrate a PACS or so), then storescu will run into an error since it cannot go beyond the 128 negotiation limit. If this is a potential issue for you, you might switch to dcmsend.

Best,
Michael

[bnoeafk]

Michael,
PDF created, but I don't see anywhere where I can upload it?

[Michael Onken]

Hi,

sorry for the delay. You could upload the file to a common file hoster, or your dropbox, and put a link here. If you like, you also send it to me and I find a place for it on the OFFIS or Open Connections server.

I also looked at the static linux binaries (you took the static ones, right?) that you downloaded from the OFFIS website. I ran one of the executables and as indicated by the debug output it expects the dictionary at /usr/local/share/dcmtk/dicom.dic .

I am not sure whether this is the best location of the dictionary for the DCMTK static binaries. However, somewhere it *has* to be stored. At least we should document the expected dictionary location explicitly since the location is only noted in dcmtk/config/docs/envvars.txt, maybe not the first file a user looks into...

Another option would be to build the dictionary into the the static binaries, then no external dictionary is needed at all (but you can enable it via environment variable, still). I actually would prefer this approach and will discuss this with my colleagues at the next DCMTK team meeting.

Best regards,
Michael

[bnoeafk]

Michael,
As always, please accept all of our thanks for the speed and resolution into getting answers. It's a huge reason why we use the toolkit.

I will put your findings together in my document and get it somewhere where it can be shared. More of that later this week.

I actually checked both the static and dynamic binaries, but I never thought of running the executable in debug mode, that's my fault and apologies for not attempting to do that. Interesting that it expects the dictionary at /usr/local/share/dcmtk as I'm sure I checked that (see previous post) but I will check again and place results in the document.

I like the idea of embedding the dictionary into the statics, that would make a lot of sense, especially if (should the need arise) you could potentially use a custom version of that dictionary and point to it using (either) the DCMDICTPATH variable, or perhaps placing a custom dictionary at /usr/local/share/dcmtk/dicom.dic - that would give a lot of flexibility and overcome all conceivable outcomes, IMHO.


bnoeafk

[bnoeafk]

Michael,
Have been thinking about embedding the dictionary into the binaries and I'm not too sure that would be wise, all in all, certainly from the OFFIS point of view. Any changes in the dictionary would mean recompiling all binaries for that one reason, which may seem a little over the top. Having a shared dictionary means just updating that one file and all binaries would immediately be able to refer to it without recompiling.

If there can be a clear cut location for the dictionary that binaries could point to - I would imagine that that would be easier for OFFIS to move forward with. Just a thought.

[Michael Onken]

Thanks for your input bnoeafk, we'll consider it on our next time meeting (end of September).

Best,
Michael

[J. Riesmeier]

Late follow-up but "<datadir>" in the documentation refers to the directory that is specified by "./configure --datadir=DIR". The default value of "DIR" is "/usr/local/share/dcmtk" as you can see when calling "./configure --help".

Also the datadict.txt file is pretty clear on this (IMHO):

-----------------------------------------------------------------------------
DICTIONARY DEFAULT: AUTOCONF ON POSIX SYSTEMS
-----------------------------------------------------------------------------

By default on a Posix system the global data dictionary will attempt to load
the data dictionary from an external file. The location is pre-configured
to $DCMTK_DAT_DIR/dicom.dic where $DCMTK_DAT_DIR is DCMTK's data installation
directory chosen using configure's --datadir option (default value: /dcmtk).
See also --datarootdir and --prefix options. The resulting path is stored as
DCM_DICT_DEFAULT_PATH in the file config/include/dcmtk/config/osconfig.h,
which is created by Autoconf during the execution of the configure script and
thus is available to the dictionary code that includes osconfig.h.

With regard to your upgrading nightmare, this seems to be caused by the Debian/Ubuntu package(s) you've used or the way you've tried to upgrade it manually.