DICOM @ OFFIS

I have had some weird issues in the past with "promiscuous mode" (see https://forum.dcmtk.org/viewtopic.php?f ... 56&p=12254 ), so I tend to prefer the more targeted approach with custom profiles.

Luckily I found this personal website with some pointers: http://www.wangchaofeng.com/parseNote.php?note=notes_imageProcessing_dicom_dcmtk.note#toc-make-dcmqrscp-accept-non-standard-sop-classuid The new '-xf' option to 'dcmqrscp' solves the association issue mentioned there, but I still had to remov...

I went ahead and compiled 3.6.5 from source and get the same result. The debug logging is below, i just had to trim some of the presentation contexts from the association request/response to fit with in this forum's char limit. The relevant presentation context ID is 243. D: Parsing an A-ASSOCIATE P...

I am trying to use the "--assoc-config-file" ("-xf") option for dcmqrscp (added in 3.6.2) so that it will accept private SOP classes. I can see that the presentation context for the private SOP class is proposed and accepted, but once the data set is sent I still get back an erro...

It seems these fixes never made it into the 3.6.0 release. Is there any plan to merge these changes?

Thanks!

Yes, unfortunately, this information (storage SOP class or not) cannot be derived from a private SOP class UID.

Doesn't the message type gives you this information (C-STORE RQ vs N-ACTION RQ)?

Thanks again for the quick response. I think I understand the issue now. It seems like it would be preferable for promiscuous mode to only accept unknown storage SOP classes (or at least make this configurable). For me it is not a big deal, since there is a small number of non-standard storage SOP c...

Thank you for being so responsive. The PACS does not have any special configuration to use Storage Commitment. Does the storescp application handle storage commitment differently when promiscuous mode is enabled? I cloned the master branch of DCMTK, compiled, and retested (with the same data set, so...

I only see the error with transfers from one specific PACS, other network nodes do not have an issue. This made me think it was an issue on that specific PACS, but it seems strange that disabling promiscuous mode makes the error go away. None of the images have to be non-standard SOP classes for the...

Hello, I am not entirely sure if this is a bug in DCMTK, but it does seem like it. For one of our network nodes (a PACS) I always get an error after storing the first image when I send to a storescp process started with promiscuous mode. The error does not occur when not in promiscuous mode (or when...