suever
commented
9 years ago From darcymason@gmail.com on January 22, 2012 17:21:47
Thanks for the detailed report and code. If you can send me the test files you created that would be great. I'll see if I can resize or model the important bits to create a unit test, and then post all these changes to the repository. Thanks! Darcy
Status: Accepted
From bastula on January 22, 2012 00:39:06
What steps will reproduce the problem? 1. Try to read the test data that either includes ISO 2022 IR 13 or ISO 2022 IR 149 encodings What is the expected output? What do you see instead? pydicom should be able to decode the values, but throws an exception instead.
A diff with a fix for both Japanese (ISO 2022 IR 13) and Korean (ISO 2022 IR 149) is included. This was tested with chrH32.dcm for Japanese and chrI2.dcm for Korean from the testcharset directory. Also tested was the korean_agfa_infinitt_2008-3.dcm obtained from: http://www.dclunie.com/images/charset/ Also modified was charlist.py to show the proper decoding of the values. This can be used to compare against the real decoded values from David Clunie's charset files: http://www.dclunie.com/images/charset/charsettests.screenshot.png Finally, I also created some test files based on korean_agfa_infinitt_2008-3 that contain multi-valued data elements for both Korean and Japanese. I can send these to you separately since they are quite large and I was not able to resize them.
I also have a patch against pydicom 0.9.6 if needed, as I plan to use it with dicompyler until pydicom 0.9.7 is released.
Attachment: pydicom_cjk_encoding.diff
Original issue: http://code.google.com/p/pydicom/issues/detail?id=110