https://support.dcmtk.org/redmine/issues/867
Some relevant commits:
b4ca1a8daff5f261e37361bd2538f10a42bc2468
15226ccc2c8020b2ebd9fa501bf564eb8baf9432
This had the surprising (to me anyway) breaking change of "count" now returning the number of items, which is VR-dependent, instead of the length of the data array.
PixelData can be OB or OW encoded, but we were always using the uint8 form and reading the appropriate chunks according to BitsAllocated, etc. I believe you have to do this regardless because BitsAllocated can be higher than 16 bit but the VR will never be OL (32-bit) or OV (64-bit), or it could be something like 24 that doesn't align with any of these larger VRs.
So, a few questions then:
- The backwards incompatibility is not addressed in the release notes, was it intentional and what's the reasoning?
- Can we still use DcmItem::findAndGetUint8Array for variable-VR items like PixelData?
- If so, what is the proper way to get the length of the data array regardless of e.g. OB vs OW?
- If not, what is the expected way to handle the variable-VR of PixelData uniformly?