DICOM @ OFFIS

Hi Spencer, it should not matter if the attribute is stored with data type UN in the file as long DCMTK knows it and fix the VR by looking it up in the dictionary when loading it into memory. Maybe something with the dictionary is wrong, or you haven't loaded one. Let's try to find out what happens....

Hi,

you are right, this doesn't look good. I created an issue on the issue tracker.

Best regards,
Michael

Hi Vasyl,

thank you for the investigation and proposed patch. I roughly looked over it a few days ago and it looks good. We will discuss the patch on Friday and I provide final feedback then.

Best regards,
Michael

Analogous to storescu's "--propose-..." flags, storescp has some "--prefer-..." flags, e.g. . However, to be sure storescp "eats" everything just use flag and you should be able to accept any transfer syntax.

BR Michael

Hi, storescu cannot (de)compress images and per default only supports uncompressed transmission. Try option --propose-jpeg8 to also propose JPEG Baseline, or --required to propose whatever is required if you also have files that use a different compression scheme than JPEG Baseline. If you want cust...

Hi,

make sure you download the DCMTK binaries that include the SSL extensions, see DCMTK 3.6.7 - OpenSSL based security extensions on the download page.

Best regards,
Michael

Hi,

I am not aware (at least) of any Windows-specific code in dcmdata's memory management, so I doubt the leak stems from DCMTK. If you can find the reason of the leak, let us know.

Best regards,
Michael

Hi, I doubt that the leak comes from DCMTK. I used this main(), running 10 iterations only, on a directory with > 1100 DICOM files (up-to-date DCMTK code): int main(int argc, char* argv[]) { std::string dir_path = "/path/to/images"; std::vector<fs::path> pathList; std::copy(fs::recursive_d...

Hi Arnauld, I agree with you that probably the conversion at the PACS side fails. Maybe your client could at least check the PACS logs to see how the PACS experiences this error. Also, if possible, get one of the affected DICOM files in original format (as it is stored in the PACS), if possible, by ...

Yes.

Yes, the server will send the C-STORE-RQ (to you) with the image on the same association as the C-GET-RQ is sent (from your side, to the server). The C-GET Retrieve SOP Classes will, per design, always re-use the same association and will never use two associations.

HI,

Great that it worked

Note that --enable-tls requires two arguments (key file and certificate file) while you provided only one:
Best regards,
Michael

Hi, it looks like something in the arriving command set of the C-STORE-RQ is wrong; in particular the DCMTK parser complains that this tag: (0000,0100) US [1] CommandField is missing, though at least in the DCM4CHEE log it is still present. Maybe you can record the DICOM communication using wireshar...

Hi,

at least I can say that there is no DCMTK-based solution. This is probably not well-suited for this forum.

Best regards,
Michael

Hi,

either CARDIAC1 is not configured in the PACS to your IP address/port, or the selected study does not have any images. Use --debug option and post check/post the details of the C-MOVE response.

Best regards,
Michael