DICOM @ OFFIS

The best I can offer is this outdated tutorial, should get you started though:
https://support.dcmtk.org/redmine/proje ... figuration

I'll see whether we can add another build to our nightlybuilds with that spec and then fix that issue. Seems we probably need another configuration test for that. Thanks for your insight and help reproducing the problem.

I think the easiest thing to try next would be to use MSYS and Unix Makefiles, see if that makes any difference.

Dear gzhang, I fear this is not a solution. The -i argument just lets make ignore any errors. The erroneous files will still be missing from the build. This is used in our nightlybuilds such that they really show all the errors, i.e. not aborting the build on the first error. It does not help with y...

Dear gzhang,

it is working in our nighlybuilds: https://support.dcmtk.org/dashboard/bui ... ldid=86630
May be you are doing something different or have a somehow different MinGW setup?

Best
Jan

So you mean, use an arbitrary prefix in connection with the DCMTK UID generator would be ok? I though it must be an official registered root. And what if my arbitrary root is the same as a registered root. Well, you should differentiate between testing and production purpose. In production, you are...

It's hard to answer this in general; there might be cases where commercial software allows configuring the UID prefix and, if configured to use the OFFIS one, that would be as intended. However, it is certainly not what one should do in some medical device that creates medical images (as in: not for...

Version 3.6.5 of the OFFIS DCMTK (DICOM ToolKit) software is now available for public release. This is a minor release that includes the following changes over the previous version 3.6.4: DCMTK 3.6.5 builds correctly on older and up-to-date versions of GNU gcc (4.4.7 to 9.2.0), Clang (3.4.2 to 9.0.0...

Michael Onken wrote: ↑Mon, 2019-10-28, 09:21 I am not sure whether it works on latest Windows versions but at least the evaluation is still available, just give it a try.

It most definitely should, we're maintaining it together with the public DCMTK.

bnoeafk wrote: ↑Thu, 2019-10-24, 02:19which has it's own issues...

Which ones? I'm currently preparing DCMTK 3.6.5, so I would like to know...

Nothing is impossible. You are on the right track: just derive your own class from DcmInputStream and map tell() etc. to std::istream::tellg() etc. I have some corrupted memory of having done that before myself for some reason, but I don't think anything is readily available for the general public. ...

You're supposed to use DcmFileFormat on DICOM files and not DcmDataset directly. DcmFileFormat handles parsing the file meta header and then uses an appropriately configured DcmDataset to actually load it. Also, use OFpath to handle concatination of szFilePath and filename.

Dear Franco, the CMake option would be -DDCMTK_ENABLE_CHARSET_CONVERSION:BOOL=OFF

Well, deactivating the ICU support would be an option, see INSTALL for how to achieve that. However, if you need character set conversion support, you should instead try to fix those linker errors. DCMTK handles linking the required ICU libraries automatically, so, it seems strange that these errors...

I would expect that to work, at least the unit tests succeed. Look at the nightly builds, in particular the ones for
AppleClang 10.0.1 and Visual Studio 2017