value of private tags changes when using DcmStorageSCU

[benwu]

to transmit dicom via the command line tool remains the original values of all private tags,
but the value changes when I using dcmStorageSCU.

The Server side is dcmStorageSCP.
Could anyone give me some suggestions?

[J. Riesmeier]

Could you be more specific. Which element values change when using your own program (based on DcmStorageSCU), and which transfer syntax is used?

[benwu]

hi:

there are some of the tags:
0033,1014
0033,1015
0033,1020
0033,1021
0033.1024
0033,1025
0033,1028
0033,1029
0033,1031
0033,1031 <-- this one is automatic generated, should not be here

7FE0,0010 Pixel Data <-- is minor changes normal ?

transfer syntax:

ts.push_back(UID_LittleEndianExplicitTransferSyntax);
ts.push_back(UID_BigEndianExplicitTransferSyntax);
ts.push_back(UID_LittleEndianImplicitTransferSyntax);

there's a thing , we modify some codes in server(DcmStorageSCP) and everything is OK for only one time.

generateDirAndFilename ==> DGM_SeriesDate

From:
// stream << "TempParseData" << PATH_SEPARATOR

To:
stream << this->DEF_StandardSubdirectory << PATH_SEPARATOR

In addition, we successfully send/receive dicom from CSImport,
but we can not send/receive dicom to ourself.

[J. Riesmeier]

I'm sorry but it's still not clear to me what your problem/question is.

What do you mean by "the value changes"? Do you refer to the padding, the VR (different presentation of the element value in textual output)...?
Which transfer syntax is actually used for the storage service? If it is implicit VR, the VR of private tags might not be known to the receiver...
What do you mean by "this one is automatic generated, should not be here" or "is minor changes normal ?"
What do you mean by "we modify some codes in server(DcmStorageSCP) and everything is OK for only one time"?

Since the DcmStorageSCU and DcmStorageSCP classes are also used for the dcmsend and dcmrecv command line tools: Does it work to transmit your sample file(s) using these tools?

In order to get help, you should provide enough detail on what you intend to do, what you've tried to do, what does not work and how this shows up.

[benwu]

I think the problem is that my application sends/receives inappropriate syntax.
similar to this one:http://www.mirthcorp.com/community/foru ... php?t=3709
Should we use dcmconv ?

Specific Infomation:

The original dicom[send by scu]https://dl.dropboxusercontent.com/u/11252568/origin.dcm

The incorrect dicom[received by scp]https://dl.dropboxusercontent.com/u/112 ... orrect.dcm

the related setting code:

Code: Select all

void AglStoreSCU::sendDICOMs(QStringList files)
{
	this->clear();
	// register JPEG decoder
	DJDecoderRegistration::registerCodecs();
	// register JPEG-LS decoder
	DJLSDecoderRegistration::registerCodecs();
	OFCondition ret;
	this->setReadFromDICOMDIRMode(1);
	this->clearPresentationContexts();
	OFList<OFString> ts;
	ts.push_back(UID_LittleEndianExplicitTransferSyntax);
	ts.push_back(UID_BigEndianExplicitTransferSyntax);
	ts.push_back(UID_LittleEndianImplicitTransferSyntax);

	this->addPresentationContext(UID_VerificationSOPClass, ts);

	qDebug() << this->getNumberOfSOPInstances();
	for (int i = 0; i < files.length(); i++)
	{
		this->addDicomFile(files[i].toStdString().c_str());
		qDebug() << "fileName" << files[i].toStdString().c_str();
	}

	qDebug() << this->getNumberOfSOPInstances();

	this->addPresentationContexts();

	ret = this->initNetwork();
	if (ret != EC_Normal) qDebug() << "initNetwork Fail!";
	ret = this->negotiateAssociation();
	if (ret != EC_Normal) qDebug() << "negotiateAssociation Fail!";
	ret = this->sendSOPInstances();
	if (ret != EC_Normal) qDebug() << "sendSOPInstance Fail!";

	closeAssociation(DCMSCU_RELEASE_ASSOCIATION);
}


// SCP settings

	_aglStoreSCP.setVerbosePCMode(false);
	_aglStoreSCP.setOutputDirectory("C:\\Git\\BaiLingCloud\\AglStorageSCP\\x64\\Debug");
	_aglStoreSCP.setACSETimeout(-1);
	_aglStoreSCP.setDIMSETimeout(10000);
	_aglStoreSCP.setDIMSEBlockingMode(DIMSE_NONBLOCKING);
	_aglStoreSCP.setDirectoryGenerationMode(DcmStorageSCP::DGM_SeriesDate);
	_aglStoreSCP.setFilenameGenerationMode(DcmStorageSCP::FGM_Default);
	_aglStoreSCP.setDatasetStorageMode(DcmStorageSCP::DGM_StoreToFile);
	_aglStoreSCP.setHostLookupEnabled(OFTrue);

	OFList< OFString > transferSyntaxes;
	transferSyntaxes.push_back(UID_LittleEndianExplicitTransferSyntax);
// 	transferSyntaxes.push_back(UID_BigEndianExplicitTransferSyntax);
// 	transferSyntaxes.push_back(UID_LittleEndianImplicitTransferSyntax);
	_aglStoreSCP.addPresentationContext(UID_NuclearMedicineImageStorage, transferSyntaxes,);
	_aglStoreSCP.addPresentationContext(UID_CTImageStorage, transferSyntaxes);

[J. Riesmeier]

The main difference between your "origin.dcm" and your "incorrect.dcm" file is that the first is stored with Explicit VR Little Endian and the latter with Implicit VR Little Endian, i.e. if your file reader does not understand the private tags in "incorrect.dcm" then the VR is unknown. However, since Implicit VR Little Endian is the Default Transfer Syntax (for uncompressed DICOM objects) you always have to propose it (on the SCU side) and to accept it (on the SCP side).

By the way, this is the reason why I was asking "which transfer syntax is used" in my first response.

[benwu]

thank you for your reply:

My SCP have to store the dicom with Explicit VR Little Endian,
and other tool can do this (e.g. CSImport or storescu.exe)
when I use these tools as a client to send the original dicom.

What can I do with my SCP/SCU ?

[J. Riesmeier]

DcmStorageSCP stores the received DICOM datasets as file with the same transfer syntax as used for network transmission (see documentation). If the storage SCU offers multiple transfer syntaxes per SOP class, the SCP selects the first one (that is supported).
So, I would guess that Explicit VR Little Endian is used for your sample code. Please enable the log output in order to see what is negotiated between SCU and SCP.

[benwu]

My question is solved by adding these code:

Code: Select all

QString path = QDir::currentPath() + "/storescp.cfg";
 OFCondition ret = _aglStoreSCP->loadAssociationCfgFile(path.toStdString().c_str());

It seems to relate some default settings and the order of transfer syntax ?
don't know why it works.

[J. Riesmeier]

I checked a modified version of "dcmrecv" and can confirm that always Implicit VR Little Endian is accepted...

As far as I can see, this looks like a bug in the underlying DcmSCP class (or DcmSCPConfig to be more specific). I will send a bug report to the original author(s).

[Michael Onken]

Hi, the bug should have been fixed some days ago, see this commit.

Best,
Michael