Precompiled libraries for /MD and /MDd?

[Ilan]

If possible, please trash my last post on LNK2005. I didn’t see that it was covered in the FAQ and it adds nothing new to the forum.

As described in the FAQ, I changed /MT -> /MD and /MTd -> /MDd and now my MFC compiles properly. Parts of the dcmtk fail to compile and the reason is that the libraries openssl-0.9.fd, libpng-1.2.5, libxml2-2.5.7, tiff-3.6.1 and zlib-1.2.1 are probably still using /MT and /MTd.

I’m not sure which of these I’m actually using, since I used the defaults in CMake (I set the directories to point to the proper objects, but didn’t change the on, off status from the defaults). One solution may be just to turn off all the options, but I’m not sure how that would affect my results. Another solution would be to ask if there are compiled libraries for these objects using /MD and /MDd?

For the moment it isn’t critical since all the libsrc modules compile correctly and just some apps fail. I can push forward with trying to integrate the dcmtk into my MFC application.

[Marco Eichelberg]

By default all libraries except libxml are configured as "on" in the CMake project files, and you would indeed need to have all external libraries compiled for /MD and /MDd if you wanted to use them with a DCMTK version compiled with this setting. Unfortunately, we do not have pre-compiled libraries of this kind available (nobody here uses MFC), so you will have to compile them on your own or disable them. All of the libraries can be disabled, but then all DCMTK functions relying on these libraries will be unavailable. That is:

• zlib: support for the "deflated" transfer syntax
• openssl: TLS encrypted transmission in the network module, digital signatures
• libpng, libtiff: PNG and TIFF export in dcm2pnm and dcmj2pnm
• libxml: XML import tools: xml2dcm, dsr2xml

If you don't need these functions, the safest and easiest solution for you would be to simply disable the external libraries using CMake.

[Ilan]

Hi Marco,
Thanks for your reply. I’m still feeling my way around the toolkit trying to find the easiest and best way to use it.

I have a general question with respect to zlib. It isn’t clear to me exactly when it comes into play. If it is for DICOM messages between servers, then both sides need to know that it is being used. The biggest files I transfer are CT slices. Would the CT data itself (7fe0:0010) be compressed during transfer?


deflate compression level (not with --write-xfer-little/big/implicit):

+cl --compression-level compression level: 0-9 (default 6)
0=uncompressed, 1=fastest, 9=best compression

The other obvious place to use it is on disk storage. However this should be the operating system’s problem, not the application. I use NTFS with file compression as the default for all disks.

I don’t know if you are interested that I report problems, but there is a mistake in your documentation for movescu:
Individual attributes of each file sent can be modified or supplemented using the "-k key" option. For example the command:
movescu -k '0010,0020=PAT002' caesar 5678 patqry.dcm
will, when sent to the SCP caesar at TCP/IP port 5678, cause any PatientID attribute in patqry.dcm to have the value 'PAT002'. If such an attribute is present it will be replaced, if absent it will be inserted.
The –k ‘0010,0020=PAT002’ should be written without the quotes as –k 0010,0020=PAT002. I happened to try it according to the documentation and found the problem.

[Marco Eichelberg]

zlib compression can be used both for network transmission and for file storage, but both functions are independent of each other. The "zlib transfer syntax" indeed applies zlib compression to all of the dataset, including the image pixel data.

Also thanks for the comment on the movescu man page.