Unknown encoding ISO 2022 IR 100

[Tim de Wit]

[2017-07-26 09:28:32,368: ERROR/PoolWorker-1] Task remapp.netdicom.qrscu.qrscu[858c8069-dee8-4b25-877d-ae51cf4ac32b] raised unexpected: LookupError('Invalid tag (0008, 0050): unknown encoding: ISO 2022 IR 100',)
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/celery/app/trace.py", line 367, in trace_task
    R = retval = fun(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/celery/app/trace.py", line 622, in __protected_call__
    return self.run(*args, **kwargs)
  File "remapp/netdicom/qrscu.py", line 663, in qrscu
    modalities_returned, modality_matching = _query_for_each_modality(all_mods, query, d, MyAE, RemoteAE)
  File "remapp/netdicom/qrscu.py", line 497, in _query_for_each_modality
    _query_study(MyAE, RemoteAE, d, query, query_id)
  File "remapp/netdicom/qrscu.py", line 430, in _query_study
    ss[1].decode()
  File "/usr/local/lib/python2.7/dist-packages/dicom/dataset.py", line 145, in decode
    self.walk(decode_callback, recursive=False)
  File "/usr/local/lib/python2.7/dist-packages/dicom/dataset.py", line 595, in walk
    callback(self, data_element)  # self = this Dataset
  File "/usr/lib/python2.7/contextlib.py", line 35, in __exit__
    self.gen.throw(type, value, traceback)
  File "/usr/local/lib/python2.7/dist-packages/dicom/tagtools.py", line 21, in tag_in_exception
    raise type(e)(err)
LookupError: Invalid tag (0008, 0050): unknown encoding: ISO 2022 IR 100

[Ed McDonagh]

Looks like that was only added to pydicom in 2015 (commit), whereas the current release version of pydicom was from 2014.

In the short term, I would just add that encoding into your pydicom code. Then we have two options:

1. Switch from pydicom to dicom, which is a drop-in legacy replacement of pydicom that keeps the import dicom style and methods etc, but is not going to be maintained. This was released in January this year (version 0.9.9.post1), so includes that fix.
2. Switch from pydicom 0.9.9 to pydicom 1.0.0a1. This is what I am doing at the moment, with both pynetdicom as it stands currently (development not release), and pynetdicom3. This is the way forward, as pydicom version 1 and pynetdicom3 will allow me to support python 2 and 3. The problem is that neither have reached a release candidate and are both being actively developed. It also requires a fair bit of reworking of the DICOM networking code.

The question is whether the effort and risk of going to non-released code is worth it. I've done a lot of the effort already, and will finish the task. But there will also be a little extra effort for users to install another library from git rather than pypi, but we'll have instructions.

I'm going to finish implementing pynetdicom3 and see where we go from there. If we do release 0.8.0 with pydicom v1.0.0a1 and pynetdicom3 v0.1.0 then I shall probably take a snapshot of the codebase and get OpenREM users to install that instead, so I can control what the code looks like, testing it before updating my copy when upstream changes.

Of course all this is not very compatible of my aim of getting 0.8.0 out the door asap so I can get on with writing it all up!

[Ed McDonagh]

I am going to document how to fix this by copying the codes into a users installed pydicom 0.9.9, as there are no sensible options at the moment. This will have to do until pydicom 1.0 is released and we change OpenREM to make use of it.

[Ed McDonagh]

New encoding errors doc to ref #532. Also moved server error 500 into own doc.

→ <<cset ca2730911a56>>

[Ed McDonagh]

Minor formatting correction and changes for ref #532

→ <<cset a7bbe81f450a>>

[Ed McDonagh]

I'm going to resolve this issue with documentation of a work-around. It will be fixed properly as a byproduct of modifying the code for pydicom 1.0 and pynetdicom3.

[Ed McDonagh]

Merged in issue532addcharsets (pull request #168)

Fixes #532

→ <<cset e788e9009db8>>