DICOM @ OFFIS

I don't see any reason why this should not work, but in the absence of an IPv6 network, I cannot test it. Sorry.

There is no general answer to this question. If you have a DICOM image type that exists both in a single frame and a multiframe variety, then converting from multiframe to single frame requires an adaptation of all physical parameters related to the image acquisition. This is a fairly complex tasks ...

The command line tools will not work with IPv6 yet. On library level, some classes and functions are "IPv6 ready", such as class OFSockAddr OFStandard::getHostnameByAddress() the gethostid() function, which in some cases uses the system's IP address the oflog logging module Other functions...

DCMTK contains partial support for IPv6, but the support is incomplete, so it is not entirely surprising that you are encountering issues.

OFFIS explicity permits the use of the UIDs generated by DCMTK under the OFFIS UID root by DCMTK users. While we cannot accept any legal responsibility for the uniqueness of the UIDs, the UIDs are as unique as technically possible. If the PACS vendor has reason to suspect otherwise, I would be happy...

I have today committed a fix for this issue to our testing branch. This should appear in the public git repository in a couple of days.
I have also reported the issue to FreeBSD, see https://bugs.freebsd.org/bugzilla/show_ ... ?id=278229.

The CMake variable is named "WITH_OPENSSLINC", not "WITHOPENSSLINC", and it should point to the main directory for OpenSSL, not to the include directory. There should be an "include" subdirectory in the directory to which you point "WITH_OPENSSLINC".

Once you have converted the image to uncompressed DICOM, you can use one of the lossless compression schemes available in DCMTK to apply an image compression, e.g. check the "dcmcjpeg" and "dcmcjpls" tools. Note that it is NOT possible to convert a PNG image to DICOM without deco...

That is probably correct. PNG is a compressed image format, DICOM is uncompressed. So the DICOM image file will necessarily be larger than the PNG file. A compression ratio of 3:1 sounds plausible.

I plan to report this to FreeBSD once I have analyzed the issue in more detail.

I can confirm this behaviour and have added an issue to our issue tracker: https://support.dcmtk.org/redmine/issues/1113 Apparently, this is caused by incorrect translation tables, in this case oficonv/datasrc/csmapper/ISO-8859/UCS%ISO-8859-2.src. This is remarkable, because these tables come from t...

I mean the value of the photometric from --dataset-from documents/study-00000.series-00000.image-00000.dcm was not copied to ./frame2large/header.dcm That is right. The photometric interpretation is derived from the image file that is converted to DICOM. It would make very little sense to specify t...

when your saying running storescu with sudo is a bad idea , what is the reason for that ? A tool should, in general, always run with the least required privileges. storescu does not need root access rights. The only possible reason might be that it runs as a user that cannot access the DICOM files ...

You are not linking all required libraries. Your DCMTK has been compiled to include zlib and libwrap support, so you need to link against libwrap (-lwrap) and zlib (-lz).

This is not something that can be solved in DCMTK. The writeBMP() method simply uses fopen() to create a file. Such a file always has the owner corresponding to the process creating the file, and access rights 0666 (read-write permission for owner, group and others) as modified by the process umask,...