DICOM @ OFFIS

Hi,

your report and patch have been correct, thanks again

I submitted a patch along with some test code to the DCMTK repository which will be available on the public mirrors within the next days.

BR Michael

This simply looks like a bug, we are looking into it. Thank you for reporting!

BR Michael

Hi, this is what your program ("jpgls") returns on my computer running the current version if DCMTK (master branch as of https://github.com/DCMTK/dcmtk/): ❯ bin/jpegls D: DcmDataDictionary: Loading file: /home/michael/data/builds/install/dcmtk_linux_368/share/dcmtk-3.6.8/dicom.dic D: DcmMe...

P.S: I also tried with a self-built OpenSSL. It also works for my out of the box. Download Windows build of OpenSSL. I used this one (Win64 OpenSSL v3.3.1 MSI installer Download and build source code as described here: https://wiki.openssl.org/index.php/Compilation_and_Installation#W64 Configure DCM...

Hi, I tried to use pre-built current version of OpenSSL to check building DCMTK with it. This is what I have done: Download Windows build of OpenSSL. I used this one (Win64 OpenSSL v3.3.1 MSI installer): https://slproweb.com/products/Win32OpenSSL.html Configure DCMTK in CMake (no options set) When c...

Maybe you should just build and check which library files are actually linked to your binaries when the linker is invoked. Or you can start "storescu --version" after the build and it should display the openssl version being used.

Then it still uses the DCMTK-build versions of those libraries.

Just build and install OpenSSL on windows the "default way". You can then tell DCMTK where to look for the OpenSSL library by defining the CMake variable "OPENSSL_ROOT_DIR" and point it to the (main) directory where you installed OpenSSL to. DCMTK will then pickup the right libra...

Hi, we might offer them in the future but we don't plan to spend time on this right now. DCMTK compiles fine with recent versions of OpenSSL, as stated in the INSTALL file: This release of DCMTK is known to compile with OpenSSL releases 1.1.1, 3.0.x, 3.1.x and 3.2.x. If you want to use up-to-date de...

No, you can always configure only for one platform, x64 or win32.
Just use two different build folders and configure/generate twice.

Can you expect every developer to put the project into the same folder, e.g. c:\my_project\src for the source code and c:\my_project\build for the build? If so, I would think the project is "portable". The project (sln) might still need cmake in the background, but I think it's portable as...

Sorry, no idea of the whole thing (creating .sln and just adapt environment variables) will work out in the end. At least I can say I never tried this and have no idea how to do it

You can suppress generation of by using if the cmake files don't change "in the background" after creating the VS project files (or you don't care), see the related CMake documentation.

Hi, I have no experience to make Visual Studio solution files relocatable, and maybe it is not even possible. That being said, the Visual Studio files are rarely commited to a source code repository (at leas when working with a team). Instead, every developer usually runs CMake on his own machine an...

Sometimes its just enough to hit Configure and Generate if you don't need any special features. We try to provide sane defaults...