0xa900: Error: DataSetDoesNotMatchSOPClass

[anilta]

I am getting this error "0xa900: Error: DataSetDoesNotMatchSOPClass"
I am using DCMTK 3.6.7 (64 Bit) version.

I am using strscp for receiving DICOM images.

The command i run is this,
storescp.exe -d +xy 104

The error happens in function 'storeSCPCallback' of class storescp.cc.
The below string comparison fails,

Code: Select all

        else if (strcmp(sopInstance, req->AffectedSOPInstanceUID) != 0)
        {
          rsp->DimseStatus = STATUS_STORE_Error_DataSetDoesNotMatchSOPClass;
        }

I debugged the code in both client (written by us) with the DCMTK library.

Here is the log of client which exports the image,

Code: Select all

2023-04-26 09:40:31.411  INFO   17116           ===================== OUTGOING DIMSE MESSAGE ====================
2023-04-26 09:40:31.411  INFO   17116           Message Type                  : C-STORE RQ
2023-04-26 09:40:31.411  INFO   17116           Message ID                    : 1
2023-04-26 09:40:31.411  INFO   17116           Affected SOP Class UID        : VLSlideCoordinatesMicroscopicImageStorage
2023-04-26 09:40:31.411  INFO   17116           Affected SOP Instance UID     : 1.2.276.0.118.696685194.21556.1682492941.488
2023-04-26 09:40:31.411  INFO   17116           Data Set                      : present
2023-04-26 09:40:31.411  INFO   17116           Priority                      : low
2023-04-26 09:40:31.411  INFO   17116           ======================= END DIMSE MESSAGE =======================

The DCMTK receives this image and stores on the disk. Now the instance UID is changed
from 1.2.276.0.118.696685194.21556.1682492941.488 [to] 1.2.276.0.7230010.3.1.4.696685194.19676.1682494815.643

In the image which is received and stored on the disk has original UID stored in tag ====> Referenced SOP Instance UID which is 1.2.276.0.118.696685194.21556.1682492941.488

So, the comparison happens between,
sopInstance = 1.2.276.0.7230010.3.1.4.696685194.19676.1682494815.643
and
AffectedSOPInstanceUID = 1.2.276.0.118.696685194.21556.1682492941.488

which obviously fails, and gives the 0xa900 error.

How can i overcome this ?
Should i use any output option which prevents from creating new Instance UID and the comparison passes ?

Here is the partial image dump in txt

Code: Select all

(Group,Element)  	TAG Description                    	VR	VM	Length    	Value
(0002,0000)      	File Meta Information Group Length 	UL	1	4         	218
(0002,0001)      	File Meta Information Version      	OB	1	2         	00\01
(0002,0002)      	Media Storage SOP Class UID        	UI	1	30        	1.2.840.10008.5.1.4.1.1.77.1.3
(0002,0003)      	Media Storage SOP Instance UID     	UI	1	54        	1.2.276.0.7230010.3.1.4.696685194.19676.1682494815.643
(0002,0010)      	Transfer Syntax UID                	UI	1	22        	1.2.840.10008.1.2.4.50 (JPEG Baseline(Process 1))
(0002,0012)      	Implementation Class UID           	UI	1	28        	1.2.276.0.7230010.3.0.3.6.6
(0002,0013)      	Implementation Version Name        	SH	1	16        	OFFIS_DCMTK_366
(0002,0016)      	Source Application Entity Title    	AE	1	6         	Local
(0008,0005)      	Specific Character Set             	CS	1	10        	ISO_IR 192
(0008,0008)      	Image Type                         	CS	2	16        	DERIVED\PRIMARY
(0008,0016)      	SOP Class UID                      	UI	1	30        	1.2.840.10008.5.1.4.1.1.77.1.3
(0008,0018)      	SOP Instance UID                   	UI	1	54        	1.2.276.0.7230010.3.1.4.696685194.19676.1682494815.643
(0008,0020)      	Study Date                         	DA	1	8         	20230412
(0008,0021)      	Series Date                        	DA	1	8         	20230412
(0008,0023)      	Content Date                       	DA	1	8         	20230412
(0008,0030)      	Study Time                         	TM	1	6         	120709
(0008,0031)      	Series Time                        	TM	1	6         	120717
(0008,0033)      	Content Time                       	TM	1	6         	120717
(0008,0050)      	Accession Number                   	SH	0	0         	
(0008,0060)      	Modality                           	CS	1	2         	SM
(0008,0064)      	Conversion Type                    	CS	1	4         	WSD
(0008,0070)      	Manufacturer                       	LO	1	32        	MetaSystems Hard & Software GmbH
(0008,0080)      	Institution Name                   	LO	1	16        	XYZ Institution
(0008,0090)      	Referring Physician Name           	PN	0	0         	
(0008,1010)      	Station Name                       	SH	1	12        	AT-LT-WIN10
(0008,1030)      	Study Description                  	LO	1	14        	CLL-VTS7_CLLDF
(0008,103E)      	Series Description                 	LO	1	34        	Cu -  /  Sl XT  /  Sc C / Field 1
(0008,1090)      	Manufacturer Model Name            	LO	1	16        	MetaSystems Neon
(0008,2111)      	Derivation Description             	ST	1	86        	Lossy compression with JPEG baseline, IJG quality factor 90, compression ratio 91.861
(0008,2112)      	Source Image Sequence              	SQ	1	176       	
   (FFFE,E000)   	Item                               		1	168       	
      (0008,1150)	Referenced SOP Class UID           	UI	1	30        	1.2.840.10008.5.1.4.1.1.77.1.3
      (0008,1155)	Referenced SOP Instance UID        	UI	1	44        	1.2.276.0.118.696685194.21556.1682492941.488
      (0040,A170)	Purpose Of Reference Code Sequence 	SQ	1	66        	
         (FFFE,E000)	Item                               		1	58        	
            (0008,0100)	Code Value                         	SH	1	6         	121320
            (0008,0102)	Coding Scheme Designator           	SH	1	4         	DCM
            (0008,0104)	Code Meaning                       	LO	1	24        	Uncompressed predecessor
         (FFFE,E00D)	Item Delimitation Item             		0	          	
      (FFFE,E0DD)	Sequence Delimitation Item         		0	          	
   (FFFE,E00D)   	Item Delimitation Item             		0	          	
(FFFE,E0DD)      	Sequence Delimitation Item         		0	  

[Michael Onken]

Hi,

the SOP Instance UID is what inside the dataset, the actual object. The Affected SOP Instance UID only exists on the network in the command set of a message (here a C-STORE-RQ message).

When sending the over the network, the client has to copy the SOP Instance UID from the dataset into the command set. If both are different, the client makes a mistake here; he announces in the C-STORE-RQ command set that the object will have a specific SOP Instance UID but attached to the C-STORE-RQ is a different object (dataset with different SOP Instance UID). The client must use 1.2.276.0.7230010.3.1.4.696685194.19676.1682494815.643 as Affected SOP Instance UID instead (since this is what is in the object according to your dump).

storescp handles this as an error, and it is an error (what should storescp trust, the command set or the dataset?). I think there is no workaround in storescp. That means you would have to patch storescp (remove the check that you mentioned) in order to receive the file successfully.

Best regards,
Michael

[anilta]

Thank you Michael for your quick response.

At the client side,
the Affected SOP Instance UID is copied from the DICOM instance which we want to transfer.
In this case it is ==> 1.2.276.0.118.696685194.21556.1682492941.488

I checked the client side, and could confirm that, the Affected SOP Instance and the SOP Instance which is inside dataset is 1.2.276.0.118.696685194.21556.1682492941.488.

At the receiver side (strscp.exe),
The SOP Instance of the image which was saved on disk is ==> 1.2.276.0.7230010.3.1.4.696685194.19676.1682494815.643
(so it changed from 1.2.276.0.118.696685194.21556.1682492941.488 to 1.2.276.0.7230010.3.1.4.696685194.19676.1682494815.643)

But the Affected SOP Instance UID is still ==> 1.2.276.0.118.696685194.21556.1682492941.488 (this is correct and remains same from what client has sent in the request object).

Question is, why did it changed the SOP Instance UID of the image which was saved to disk ?

The dump of the image above is of the instance saved on disk by strscp.

[Michael Onken]

Hi,

storescp does never (? at least what I know, and for sure not in standard configuration) change the SOP Instance UID of the object. Double-check, maybe with Wireshark, what actually goes over the network. Also double-check that you don't look at an old file. I have no explanation for the described behavior otherwise...sorry.

Best regards,
Michael

[anilta]

Hi Michael,

Yes. True. strscp does not change the SOP Instance UID.
We were able to locate what changes the UID.

The below is the partial client code. 'chooseRepresentation' function is changing it. But not sure why it changes the UID.

The filexfer is 'Little Endian Explicit' and netTransfer.getXfer is 'JPEG Baseline'. So, in this state, 'dcmDataset->chooseRepresentation' is called.

Code: Select all

const OFCondition condition = ASC_findAcceptedPresentationContext(mDcmStoreSCU.getAssociation()->params, presId, &aPresentationContext);
	if (condition.good())
	{
		const DcmXfer netTransfer(static_cast<const char *>(aPresentationContext.acceptedTransferSyntax));
		if ((netTransfer.getXfer() != filexfer.getXfer()) && (EC_Normal != dcmDataset->chooseRepresentation(netTransfer.getXfer(), NULL)))
		{
			DcmLogger::getInstance()->e(dicomscu::DCM_MSG_STORE_CANNOT_CHOOSE_NEW_REPRESENTATION.c_str());
			retStatus = DCM_BADPRESENTATIONCONTEXTID;
		}
		else
		{
			retStatus = DCM_SUCCESS;
		}
	}

[Marco Eichelberg]

JPEG baseline is a lossy (irreversible) compression. That means that the compressed image may not be "identical" from a medical point of view to the original one - the difference being the image quality.
In such cases DICOM requires the SOP Instance UID to be changed.

[Michael Onken]

But storescp does not change the compression of the image?

[anilta]

Thanks, i understand now.

The UID changed by DCMTK does not have company specific root UID.
May be this can be improved.