DICOM @ OFFIS

Yes, that is still a problem - but i dont understand the the connection between the normal private (non-reservation) tags you posted above. But maybe I'm just too confused at the moment. By the way, I already corrected dcmdata routines so far, that they do not crash when reading such datasets. I'm n...

Hi Shaeto, btw if we checking private.dic (0027,"SVISION",13) DT NewestStudy 1 These are normal private tags (in that case of creator "SVISION"); of course not every private tag has to have a VR of LO. Reading part 5 of the standard about the reservation mechanisms using private ...

Hi, oops, then my colleague just forgot to mark that in the TODO list :-) But ok, even better that it's already done. what do you think about (0009-o-ffff,0010-u-00ff) LO PrivateCreator 1 PRIVATE if private creator will place SQ to that range instead of LO ? for example (0507, 0011) Thats illegal in...

Hi, thank you for sending. It's actually about the PrivateGroupLengthToEnd attribute which is part of the dicom.dic. As another team member (Marco) already pointed out in our TODO list, this attribute (and also IllegalGroupLengthToEnd and GenericGroupLengthToEnd) will probably removed from dicom.dic...

Hi Shaeto,

could you provide an example dataset to dicom (at) offis (dot) de? That helps for including and testing the proposed patch.

Thank you, Regards,
Michael

Hi Ofek, thank you for the hint. We always try to keep all compilers quiet during compilation; in earlier times we did that mainly when preparing a realease (*sigh*), so, at the moment we do only fix warnings occassionally. For the warning you reported, a fix was already applied a few months ago, th...

Hi,

I guess without any more information (did you compile your code with Debug information enabled?) that will be difficult

Regards,
Michael

Hi, mdfdsman.cc/h are not meant to be part of the dcmdata library. They are there because of some stupid dcmodify source code structuring which may change in the future. Thus, they are and will not be copied when installed. I guess there is no good reason for the Debian people to change that behavio...

Hi, no, the only way to find out which character sets might be used for querying the SCP is trying it out or looking into the conformance statement of the PACS. Also, please note that the Specific Character Set attributes only denotes what is sent. Thus the returned character set may be different fr...

Hm, maybe you mixed up both installations (apt-get installation + local installation) when actually trying to use only the apt-get version. However, everything works now -> fine

Regards and have fun with DCMTK,
Michael

Thats quite curious... the code looks ok. If you are also loading fom test.dcm, call "loadAllDataIntoMemory())" on pFileFormat to be sure all large data elemetns (like pixel data) are loaded into memory before writing to the same file. But also when not doing so, usually that should not le...

Hi Miklos,

first check whether loading the file was successful by checking the return value. See dcmdata documentation for an example.

Regards,
Michael

Hi, From my observation from the processing details, it seems that the bottleneck is the time wasted in waiting for Status=Pending. Please note that all C-MOVE-RSP message are only very small messages sent to movescu about what is happening on the _second_ connection, ie. to let movescu know how man...

Hi, sorry, I don't have any further ideas - your movescu call looks fine. So you want the PACS (AETitle D250GEPACS, IP 170.215.245.168, Port 4100) to send the study to another DICOM device (not movescu itself), with AETitle MYPACS01. What you (of course) must check is whether that MYPACS01 receiver ...