Handling of incorrect HighBit value

[galijot]

Hello DCMTK community!

As per the standard:

High Bit (0028,0102) shall be one less than Bits Stored (0028,0101)

We have faced a couple of files for which this wasn't the case. HighBit value would be 11 while BitsStored would be 16, which resulted in DCMTK failing to parse those files. I've found this implementation here in diimage.cc.

After some research we've found that we can edit the file's metadata before parsing to make HighBit value match BitsStored - 1, and after doing so, we were able to load all of the files which previously failed to load for this reason.

However, we are unsure whether the value that is incorrect here is indeed HighBit, or is it maybe BitsStored that should be edited to match HighBit + 1.

Is there a reason that DCMTK throws an error for these files instead of making the adjustment to match requirements, other than it being the standard? We're trying to figure if there are any risks of doing this change before loading files. Any information is helpful.

[J. Riesmeier]

However, we are unsure whether the value that is incorrect here is indeed HighBit, or is it maybe BitsStored that should be edited to match HighBit + 1.

I do understand your doubts. Maybe, you can derive the correct value(s) from additional information in the dataset. However, since the dataset in not valid there is always some risk in doing this, at least in a production environment.

Is there a reason that DCMTK throws an error for these files instead of making the adjustment to match requirements, other than it being the standard? We're trying to figure if there are any risks of doing this change before loading files. Any information is helpful.

The rule that High Bit shall always be Bits Stored - 1 has been added later to the DICOM standard, so there are valid DICOM Images that do not follow this rule. Also, as discussed above, how should the DCMTK know what the correct valued are? This requires more context information and should, therefore, better be handled on application level.

[galijot]

Maybe, you can derive the correct value(s) from additional information in the dataset.

Could you please help, which values could I examine in the dataset which could help me derive the correct values(s) for HighBit/BitsStored?

This makes perfect sense:

However, since the dataset in not valid there is always some risk in doing this, at least in a production environment.

Though I'd at least see if there's a pattern among the files that we're processing, or something that could make this a bit safer.

[J. Riesmeier]

You could e.g. check the DICOM Standard to see if there are restrictions for these Attributes regarding the underlying IOD (see PS3.3) or regarding the (compressed) Transfer Syntax (see PS3.5), hoping that the creator of the image has followed these restrictions.
And, of course, you could check the Pixel Data values to see whether the higher bits are actually used, i.e. if there are values higher than 2^BitsStored - 1 and/or if there are bits set beyond HighBit, assuming that no embedded Overlay Planes are present.