On the problem that dicmtk can't read drtstructuresetiod data

[zrhcheer]

When I use dicmtk-3.6.5, I read drtstructuresetiod data and report the following warning:


2020-08-05 15:16:43 WARN: SOPClassUID (0008,0016) violates VR definition in SOPCommonModule (F:\opensource\DCMTK\dcmtk-3.6.5\dcmrt\libsrc\drttypes.cc:175)
The data is not read in normally. After compiling the debugging code, it is found that:

int vrscan::scan(const OFString& vr, const char* const value, const size_t size)
{
yyscan_t scanner;
if (yylex_init(&scanner))
{
DCMDATA_WARN("Error while setting up lexer: "
<< OFStandard::getLastSystemErrorCode().message());
return 16 /* UNKNOWN */;
}

#if 0
size_t bufSize;
char *buf = makeBuffer(vr, value, bufSize);
struct vrscan_error error;
error.error_msg = "(Unknown error)";
yyset_extra(&error, scanner);

int result;
if (setjmp(error.setjmp_buffer))
{
DCMDATA_WARN("Fatal error in lexer: " << error.error_msg);
result = 16 /* UNKNOWN */;
}
else {
yy_scan_buffer(buf, bufSize, scanner);

result = yylex(scanner);

int res2 = yylex(scanner);
if (res2)
result = 16 /* UNKNOWN */;
}

yylex_destroy(scanner);
delete[] buf;
#else
struct cleanup_t
{
cleanup_t(yyscan_t& y) : t(y) {}
~cleanup_t() { yylex_destroy(t); }
yyscan_t& t;
}
cleanup(scanner);

OFString buffer;
buffer.reserve(vr.size() + size + 2);
buffer.append(vr);
buffer.append(value, size);
buffer.append("\0\0", 2); // yy_scan_buffer() requires this

struct vrscan_error error;
error.error_msg = "(Unknown error)";
yyset_extra(&error, scanner);

if (setjmp(error.setjmp_buffer)) // poor man's catch()
{
DCMDATA_WARN("Fatal error in lexer: " << error.error_msg);
return 16 /* UNKNOWN */;
}

yy_scan_buffer(OFconst_cast(char*, buffer.data()), buffer.size(), scanner);
const int result = yylex(scanner);
if (yylex(scanner))
return 16 /* UNKNOWN */;
#endif
This code is good in the way it used to be, but it doesn't work now.
What should I do to solve this problem.

[J. Riesmeier]

When I use dicmtk-3.6.5, I read drtstructuresetiod data and report the following warning:
2020-08-05 15:16:43 WARN: SOPClassUID (0008,0016) violates VR definition in SOPCommonModule (F:\opensource\DCMTK\dcmtk-3.6.5\dcmrt\libsrc\drttypes.cc:175)

Have you checked whether the value of SOP Class UID (0008,0016) really violates the definition of the value representation "UI"?

The data is not read in normally.

What do you mean by that?

[zrhcheer]

Yes, that's the data
My debug stack is:
xx.exe!vrscan::scan(const OFString & vr, const char * const value, const unsigned __int64 size) 行 59 C++
xx.exe!DcmElement::scanValue(const OFString & vr, const char * const value, const unsigned __int64 size) 行 2136 C++
xx.exe!DcmElement::scanValue(const OFString & value, const OFString & vr, const unsigned __int64 pos, const unsigned __int64 num) 行 2128 C++
xx.exe!DcmByteString::checkStringValue(const OFString & value, const OFString & vm, const OFString & vr, const int vrID, const unsigned __int64 maxLen, const OFString & charset) 行 898 C++
xx.exe!DcmUniqueIdentifier::checkStringValue(const OFString & value, const OFString & vm) 行 247 C++
xx.exe!DcmUniqueIdentifier::checkValue(const OFString & vm, const bool __formal) 行 98 C++
xx.exe!DRTTypes::checkElementValue(DcmElement & element, const OFString & vm, const OFString & type, const OFCondition & searchCond, const char * moduleName) 行 167 C++
xx.exe!DRTTypes::getAndCheckElementFromDataset(DcmItem & dataset, DcmElement & element, const OFString & vm, const OFString & type, const char * moduleName) 行 205 C++
xx.exe!DRTStructureSetIOD::checkDatasetForReading(DcmItem & dataset) 行 788 C++
xx.exe!DRTStructureSetIOD::read(DcmItem & dataset) 行 814 C++
xx.exe!DCMStructure::load(QString filename) 行 49 C++

To function:int vrscan::scan(const OFString& vr, const char* const value, const size_t size)The parameters of are:
vr=ui,value="1.2.840.10008.5.1.4.1.1.481.3",size=29

yy_scan_buffer(OFconst_cast(char*, buffer.data()), buffer.size(), scanner);
const int result = yylex(scanner); // first come
int kk = yylex(scanner);//for test //sec come
if (kk)
return 16 /* UNKNOWN */;

The first come yylex value is: 9, the second come the static library is zero is a good; dynamic library, the second come it is 16, it can not be good.

[zrhcheer]

It feels strange

[zrhcheer]

I went further and found that the size of the string read out in the dynamic library was not 29, but 30

[J. Riesmeier]

DICOM requires data element values to be stored with an even length. The padding character for UI values is a single 0 byte (at the end of the value). Maybe, in your dataset a space character is used instead?

I'm still not sure whether you only get a warning message on the logger (which could be ignored for now) or whether you also get an error message (such as "Invalid value for attribute SOPClassUID (0008,0016)").

[zrhcheer]

There are warnings in the log, but reading data failed. The static library is normal.
Open it with view file, and it seems that there is no space. During debugging, the static library is normal, and the string read by the dynamic library has no space, but the length is one more bit and becomes 30.

[zrhcheer]

how to sent test data?

[J. Riesmeier]

how to sent test data?

Please send your sample file by email to bugs/at/dcmtk/dot/org.

[zrhcheer]

I've sent the data

[J. Riesmeier]

I checked the file. It works as expected when I use drtdump to read the contents of the RT Structure Set object.
However, since the DICOM dataset is stored with Implicit VR Little Endian Transfer Syntax, it only works if the DICOM data dictionary is loaded. If I disable it (for testing purposes), I get the following output:

Code: Select all

W: no data dictionary loaded, check environment variable: DCMDICTPATH
E: unsupported SOPClassUID (31) in file: 1.2.840.113729.1.47736.2828.2019.3.20.3.14.49.375.39493.dcm

So, maybe your problems are also caused by the non-availability of the data dictionary.

[zrhcheer]

warn:
2020-08-10 08:56:11 WARN: SOPClassUID (0008,0016) violates VR definition in SOPCommonModule (F:\opensource\DCMTK\dcmtk-3.6.5\dcmrt\libsrc\drttypes.cc:175)
2020-08-10 08:56:11 WARN: PatientBirthDate (0010,0030) violates VR definition in PatientModule (F:\opensource\DCMTK\dcmtk-3.6.5\dcmrt\libsrc\drttypes.cc:175)
2020-08-10 08:56:11 WARN: StudyInstanceUID (0020,000d) violates VR definition in GeneralStudyModule (F:\opensource\DCMTK\dcmtk-3.6.5\dcmrt\libsrc\drttypes.cc:175)

[zrhcheer]

I found that dynamic library data can't be read out and file storescp.cfg It matters！
I added the following code，If i annotate this paragraph, the program will be OK：

Code: Select all

if (m_ptrSCP)//DcmTestSCP m_ptrSCP
	{
		m_ptrSCP->setPort(m_port);
		m_ptrSCP->setAETitle(m_AETitle);
		if (m_ptrSCP->loadAssociationCfgFile("storescp.cfg").good())
		{
			if (m_ptrSCP->setAndCheckAssociationProfile("Default").good())
			{
				if (m_ptrSCP->getDIMSEBlockingMode() == DIMSE_NONBLOCKING)
				{
					m_ptrSCP->setConnectionTimeout(ULONG_MAX);
					m_ptrSCP->setDIMSEBlockingMode(DIMSE_BLOCKING);
				}
			}
			if (m_ptrSCP->listen().bad())
			{
				DCMNET_INFO("\nSCP listen return condition BAD\n");
			}
		}
	}

File storescp.cfg is from the source code 3.6.5 in the exam, do not test Download problems!

[zrhcheer]

[img]e:/listen.png[/img]
Step by step, I noted the code and found that:

Code: Select all

OFCondition DcmSCP::listen()
{
  // make sure not to let dcmdata remove trailing blank padding or perform other
  // manipulations. We want to see the real data.
  dcmEnableAutomaticInputDataCorrection.set( OFFalse );
  

I set it when loading：

Code: Select all

dcmEnableAutomaticInputDataCorrection.set(OFTrue);

but i feel is not good

[Marco Eichelberg]

That may explain the problem. When dcmEnableAutomaticInputDataCorrection is set to OFTrue, then certain trivial data corrections such as removing unneeded padding characters at the end of a field are performed, and in the case of UID elements, all space characters (which should never occur in a UID) are removed and a zero byte is used as padding character instead of a space character, as required by DICOM. So perhaps this setting fixes the problem. In the sample file you sent, however, all UIDs are correctly zero-padded, I cannot see any space characters in the UIDs.