Code Extension about fo-dicom

[gofal]

I'm happy to help. You know, there's a saying in german thats like "time isn't something that you do have, but it's something you have to take". If you're working on that then of course I will find the time to work with you on that :-)

[anders9ustafsson]

The Japanese character set (ISO 2022 IR 13/iso-2022-jp) is indeed supported in fo-dicom.

The problem you are encountering is that when fo-dicom reads the Specific Character Set data it only uses the first of the specified encodings in the data string. And since the first character in the Specific Character Set data in your file is a backslash (\) the data is interpreted as consisting of three (3) items with the first item empty...

I would say that your sample file is invalid and that the first backslash in the Specific Character Set data should be removed. If you remove it, fo-dicom appears to be able to interpret Japanese characters:

[anders9ustafsson]

Response by Mariusz Kowalski in Google Groups on July 27, 2015:

Anders,

Thank you for dealing with this issue.

I think that using backslash at the beginning of Specific Character Set is correct. I search a little and here are some examples:
http://www.manualslib.com/manual/24431/Canon-Cr-1-Mark-Ii.html?page=84
http://medical.nema.org/dicom/2013/output/chtml/part05/sect_H.3.html
https://www.dabsoft.ch/dicom/5/6.1/

I think that it is wrong behavior that fo-dicom uses only one (first) encoding because (if I understand this mechanism clearly) in case of Code Extension there are some escape characters in strings which should invoke switching of encoding.

Next thing is that when i remove backslash from the beginning of Specific Character Set fo-dicom still display some of tags incorrect:

Thanks,
Mariusz

[anders9ustafsson]

Many thanks for those links, Mariusz. You are right, I stand corrected :-)

Currently, fo-dicom does not support code extension techniques, but of course it should. As far as I can tell, it is quite a large task to implement though, so it will have to wait until after the version 1.1.0 of fo-dicom that we are about to release shortly.

As an additional help, Mariusz, could you please also display the correct values of the tags above?

[anders9ustafsson]

Response by Mariusz Kowalski in Google Groups on July 28, 2015:

Correct values:

Patient's Name: ??^??=漢字^表意=かな^ひょうおん
Patient ID: @DM_Cod11_ﾏﾀﾞﾀﾛｳ
Patient Comments: YamadaTarou山田太郎ﾔﾏﾀﾞﾀﾛｳ
Additional Patient History: YamadaTarou山田太郎ﾔﾏﾀﾞﾀﾛｳ

Thanks for your effort, Anders.

[timurposhva]

Any news about this issue?

[mrbean-bremen]

@gofal - you mentioned that now that the encoding lives in the dataset instead of in the tags (in fo-dicom 5), it would be easier to add code extension support. I guess to correctly support this, you would need a list of encodings instead of a single encoding in the dataset (at least optionally), which would probably also mean to change the API (I haven't looked closely at this, so I may be wrong). Are there any plans to add this support for the fo-dicom 5 release?

[mrbean-bremen]

If nobody is working on this, I may have a shot, if you don't mind.

[gofal]

@mrbean-bremen the idea of introducing the new version 5 was, to fix some issues that live deep in the core and change the api. in version4 a lot of things have not been implemented or fixed because it would break api or the core too much.
Yes, I have plans to implement this, but my time is very limited. So would be really great if you could do it!

[mrbean-bremen]

@gofal - Ok, I already had a look and I will see if I can put something together over the weekend to get this started. I will use the implementation in pydicom as a template (I refactored the encoding part there some time ago).
I will have some questions, of course, regarding upwards compatibility, performance (I may need some help in .NET regarding that), and more, so I will need some of your time anyway...

[mrbean-bremen]

Hah - that's my standard response if asked if I've got time to help...

[gofal]

some more details are handled in #1200