You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This has been discussed before (e.g. here) but we should have an issue to track it.
Pydicom is very loose in what it allows you to set as an attribute's value, even when you have the global configuration option pydicom.config.enforce_valid_values set to True. We have previously encountered and resolved this narrowly for decimal strings (DS) #57#65, but the issue is broader. Checks for the other VRs are largely absent from pydicom, but many VRs have limits on length of the string, list of allowable characters, capitalisation, etc (see standard). The result is many one-off checks being including to check user-supplied values in highdicom, as well as probably many missed checks that could allow files with invalid values to be produced. We should tackle this in a more unified way to reduce redundancy and probability of invalid values slipping through the net.
My feeling is that as far as possible we should add this functionality to pydicom and then integrate into highdicom.
The text was updated successfully, but these errors were encountered:
We should avoid the global configuration as much as possible. My preferred approach would be to add a parameter to the constructor of Dataset and friends (Sequence, etc.) such as enforce_valid_vr. That should allow us to enforce correct encoding when creating new objects while potentially allowing some invalid values when reading existing objects.
This has been discussed before (e.g. here) but we should have an issue to track it.
Pydicom is very loose in what it allows you to set as an attribute's value, even when you have the global configuration option
pydicom.config.enforce_valid_values
set toTrue
. We have previously encountered and resolved this narrowly for decimal strings (DS) #57 #65, but the issue is broader. Checks for the other VRs are largely absent from pydicom, but many VRs have limits on length of the string, list of allowable characters, capitalisation, etc (see standard). The result is many one-off checks being including to check user-supplied values in highdicom, as well as probably many missed checks that could allow files with invalid values to be produced. We should tackle this in a more unified way to reduce redundancy and probability of invalid values slipping through the net.My feeling is that as far as possible we should add this functionality to pydicom and then integrate into highdicom.
The text was updated successfully, but these errors were encountered: