DicomValidation for VR PN #1785
Comments
|
Can you please add the |
|
So, you have "\ISO 2022 IR 87" as I understand that you are showing some code that reproduces the behavior, but I don't see where that code is used (and it is incomplete). As far as I understood, you get the problem with a dataset received via a C-FIND response, correct? |
|
I added the following
Sorry for the poor explanation, but the app has the ability to act as a MWM server (SCP) and return data such as patient name according to the C=FIND received from the modality (SCU). The role of the application is to mediate DICOM communication between the core system and the modalities.
The problem occurred when the patient name was formatted for DICOM communication, i.e., when the patient name was added to the data set. (See also the actual error description.) |
|
I have checked how fo-dicom handles that patient name, and I did not have any problems. To test it, I also patched a real DICOM file with that patient name and encoding, and the patient name is correctly read, decoded and validated on reading the dataset. It would help if you could show some code with that behavior. My assumption is that the patient name is somehow wrongly decoded, so that that "=" will still be in the string and be seen as a delimiter. What is done in the code is something like this (not exactly, this is for illustration), which works without problems: var bytes = new byte[] // your patient name
{
0x4e, 0x49, 0x53, 0x48, 0x49, 0x4b, 0x41, 0x57, 0x41, 0x5e, 0x52, 0x49, 0x53, 0x41, 0x54, 0x4f,
0x3d, 0x1b, 0x24, 0x42, 0x40, 0x3e, 0x40, 0x6e, 0x1b, 0x28, 0x42, 0x5e, 0x1b, 0x24, 0x42, 0x68,
0x3d, 0x4e, 0x24, 0x1b, 0x28, 0x42, 0x3d, 0x1b, 0x24, 0x42, 0x25, 0x4b, 0x25, 0x37, 0x25, 0x2b,
0x25, 0x6f, 0x1b, 0x28, 0x42, 0x5e, 0x1b, 0x24, 0x42, 0x25, 0x6a, 0x25, 0x35, 0x25, 0x48, 0x1b,
0x28, 0x42
};
var dataset = new DicomDataset();
result.Add(DicomTag.SpecificCharacterSet, "\\ISO 2022 IR 87");
var patientName = new DicomPersonName(DicomTag.PatientName,
dataset.GetEncodingsForSerialization(), new MemoryByteBuffer(bytes));
// patientName has now the correct decoded value
dataset.Add(patientName); // does validation |
|
The following is an excerpt of the code. PatientNameAll in the WorklistItem contained "=". Individual names will be withheld. Byte data of nameByte |
|
I'm not sure yet if this behavior is expected or a bug (I may have another look some time later), but you could avoid this problem by using the code I showed above, e.g.: var dataset = new DicomDataset();
result.Add(DicomTag.SpecificCharacterSet, "\\ISO 2022 IR 87");
// assuming patientNameAllByte is of type byte[] and has the correct value
var patientName = new DicomPersonName(DicomTag.PatientName,
dataset.GetEncodingsForSerialization(), new MemoryByteBuffer(patientNameAllByte));
dataset.Add(patientName); |
|
Sorry for the late reply. I tried the above code and was able to work around the problem. Thanks for your time! |
I will leave this issue as it may be investigated at a later date from the above. |
|
It seems the "dataset.Add" function cannot accept CJK string. If you are using some CJK characters in the string, it may not be encoded correctly. var raw = new byte[] {
0x59, 0x61, 0x6d, 0x61, 0x64, 0x61, 0x5e, 0x54, 0x61, 0x72, 0x6f, 0x75, 0x3d, 0x1b, 0x24, 0x42, 0x3b, 0x33,
0x45,
0x44, 0x1b, 0x28, 0x42, 0x5e, 0x1b, 0x24, 0x42, 0x42, 0x40, 0x4f, 0x3a, 0x1b, 0x28, 0x42, 0x3d, 0x1b, 0x24,
0x42,
0x24, 0x64, 0x24, 0x5e, 0x24, 0x40, 0x1b, 0x28, 0x42, 0x5e, 0x1b, 0x24, 0x42, 0x24, 0x3f, 0x24, 0x6d, 0x24,
0x26,
0x1b, 0x28, 0x42
}; // https://dicom.nema.org/medical/dicom/current/output/html/part05.html#table_H.3-1
var ds1 = new DicomDataset();
ds1.Add(DicomTag.SpecificCharacterSet, "\\ISO 2022 IR 87");
ds1.Add(DicomTag.PatientName, "Yamada^Tarou=山田^太郎=やまだ^たろう");
var ds2 = new DicomDataset();
ds2.Add(DicomTag.SpecificCharacterSet, "\\ISO 2022 IR 87");
var pn = new DicomPersonName(DicomTag.PatientName,
DicomEncoding.GetEncodings(ds2.GetValues<string>(DicomTag.SpecificCharacterSet)),
new MemoryByteBuffer(raw));
ds2.Add(pn);
var out1 = ds1.GetString(DicomTag.PatientName); // "Yamada^Tarou=山田^太郎=やまだ^たろう"
var out2 = ds2.GetString(DicomTag.PatientName); // "Yamada^Tarou=山田^太郎=やまだ^たろう"
var outbuf1 = ds1.GetValues<byte>(DicomTag.PatientName); // length of outbuf1 is 26
var outbuf2 = ds2.GetValues<byte>(DicomTag.PatientName); // length of outbuf2 is 60The ds2 is a correct way to add such DicomItem. However, the GetEncodingsForSerialization() seems to be an internal method. So, I replaced it to GetEncodings. |
|
@chen-wu - yes, this is exactly the described behavior, including the workaround, and the reason why this issue is still open. |
|
I just confirmed that saving with a single-value encoding works well, it only does not work with a multi-valued encoding. I just had forgotten that this is not implemented (and never has been), as I wrote a comment to that extent myself in the code in a PR I made some time ago... |
The problem, that I see in your example is, that you have various strings that should be binary serialized using different encodings. This is why you did not face any issue as soon as you pass the bytearray directly into the DicomDataset |
|
@gofal - that is true, but maybe the example by @chen-wu shows the problem better. If using a single value encoding that can encode the name (like GB18030 or UTF-8), this works without a problem. |
|
The code where the binary data is added directly seems to solve the issue that no validation error is raised. But does it also work on the modality side? Is the modality able, to render the PatientName correctly? fo-dicom is able to decode text that is encoded with mutliple encodings. But I also highly recommend taht if someone creates new data to use an encoding that contains all used characters, e.g. UTF-8. I also cannot imagine a usecase, where this is not possible. If we wanted to support encoding a text with various encodings, then this would require some API like StringBuilder, where you can add one text after the other and with each text also pass the encoding to use. |
|
Yes, I agree. I had a closer look, and there is a reason why I didn't implement this last time - it can get quite complicated. So while I'm not really happy with the current state (especially because I did some implementation on the decoding side and should have also done the encoding), I think we can live with this for now. |
|
Thank you! I could not find a issue about that encoding. Could you please open a new issue with label "Enhancement" about the feature of encodig a text with codeextensions? Then we could close this issue, but we have the feature in our backlog for future versions, |
|
Closing this issue after creating the spin-off, as discussed. |
Overview
Hello.
Please be aware that I am new to DICOM.
I am running into a problem with an application that receives a MWM worklist retrieval request (C-FIND) from a modality and returns a dataset with the requested tag.
(0010,0010) VR=PN VM=1 In Patient's Name, the byte data encoded with ISO 2022 IR87 for "莉" (JIS X 0208 2nd level Kanji), which is part of the name, contains "=", so when validating the dataset DicomValidation causes an error.
VR=PN allows up to two component delimiters "=", but because the byte data of the name contains "=", it reads as three "=", which causes an error if there are too many components in the VR=PN validation.
Currently, we are temporarily coping by removing DicomValidation and are able to communicate with the modality for now.
I referred to DICOM PS3.5 6.2, which is not a violation of the DICOM standard, so it seems normal to be able to send data without error with DicomValidation.
I don't want to remove DicomValidation to avoid other problems, but do you have any suggestions for a fundamental solution?
Expected behavior
DicomValidationException is not thrown.
Actual behavior
The method throws an DicomValidationException.
fo-dicom/FO-DICOM.Core/DicomValidation.cs
Line 495 in f13ce2e
Actual error content
Individual names will be withheld.
Byte data of patient name from Wireshark.
Steps to reproduce the behavior
Part of the process is shown in accordance with this issue.
reference data
In byte data, "莉" is 68 3D and "=" is 3D.
ASCII Table
JIS-X0208-1997 Code Table
DICOM PS3.5
fo-dicom version and OS/platform
Fellow Oak DICOM version: 5.1.1
OS: Windows 10 64bit
Platform: .NET 6
The text was updated successfully, but these errors were encountered: