Kiyokawa / pydicom

Automatically exported from code.google.com/p/pydicom
0 stars 0 forks source link

Fix for ISO 2022 IR 13 and ISO 2022 IR 149 encodings #110

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
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.

Original issue reported on code.google.com by bastula on 22 Jan 2012 at 5:39

Attachments:

GoogleCodeExporter commented 8 years ago
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

Original comment by darcymason@gmail.com on 23 Jan 2012 at 1:21

GoogleCodeExporter commented 8 years ago
This issue was closed by revision 8e30847dc048.

Original comment by darcymason@gmail.com on 12 Feb 2012 at 2:27