Feature/Value Multiplicity Info

[bpeake-illuscio]

Once again, I love this lib. Here's a PR with some functionality I have been needing in my own work, refactored to be a first class citizen of the lib.

Sometimes when working with Dicoms (especially when writing), it is useful to inspect the Value Multiplicity / Cardinality of a tag to make sure it lines up with the dicom spec.

Right now we just get a raw string like '1', '1-2', '1-n', or '2-2n'. Inside of these stings is some encoded information that is important if we are verifying a dicom is valid per the spec.

This PR introduces a new VMInfo field on the tag.Info struct which is a struct of the same name.

VMInfo in turn, declares the following fields:

• Minimum: The minimum number of values. 2 when VM is equal to '2', '2-n' or '2-2n'.
• Maximum: The maximum number of values. 2 when VM is equal to '2', or '1-2', and -1 when unbounded (vm is '1-n')
• Step: 1 except when VM is similar to '2-2n', in which case it is equal to 2.

The python script for auto-generating our dict of known tags has been updated to include this information. There were a few places the type names it generated seemed out of date so those were updated.

Tests have been added to ensure:

1. All tags in the current parsed spec are parsed correctly.
2. Helper function on the VMInfo object work correctly.

Let me know what you think, and if this is something that might be useful for your library.

Thoughts:

If I were designing the API from scratch I would probably replace "VM" with this VMInfo object, then move the raw string into VMInfo as a "Raw" string field, but this would obviously break backward compatibility.

[bpeake-illuscio]

This also seems to touch on #147. If you like the API for this, I am happy to a take a crack at refactoring the generation code based on the innolitics JSON dump.

[suyashkumar]

Hi @bpeake-illuscio thank you for the PRs, kind words, and interest in the project 😄! Just wanted to hop in and say I'm a bit short on time at the moment so may not get a chance to take a close look at all of these for another week or so. Apologies for the delay and thanks again for the interest--will get to these shortly!!

[suyashkumar]

Does #169 cover this too? I'm thinking it might be good to get that one in good shape, as that's ultimately what I've wanted to do for a while (e.g. #147 as you saw)

[bpeake-illuscio]

Does #169 cover this too? I'm thinking it might be good to get that one in good shape, as that's ultimately what I've wanted to do for a while (e.g. #147 as you saw)

I wanted to keep #169 somewhat self-contained (not adding any new API features), so it does not currently contain this logic.

The logic here would be easy to port though, so I think if you like #169, the path forward would be to close this PR, and I can open a new PR for this feature that builds on #169 once it is merged.

[bpeake-illuscio]

I'm going to close this one for now and will open a new PR based on #169 once we get around to getting that in good shape.