Error while trying to render image when OverlayData is present

[Muttleskovic]

Error while trying to render image when OverlayData is present

[gofal]

Also did some recherche. A lot of topics are discussed in forums like comp.protocols.dicom, but this never seemed o be a topic there.
And even if i understood the standard in a way that the 1 bits in overlay are counting and the rest may be assumed as zero, and even if dropping the overlay because of 4 missing bits would contradict the principle of "be as tollerant as possible when receiving data and as strict as possible when creating data", I would now agree to the PR if you all understand this file as invalid.

[gofal]

Throwing an exception was never a topic here in this issue. dcm4che does it, but I would not support this in fo-dicom.

The question in this issue was if we should draw the overlay except the last 4 bits and therefore be tollerant, or if we skip the whole overlay and therefore be more strict. This is why I said, that this would contratict the mantra.

[gofal]

In this image the Overlay rows are 567 and overlay columns are 652, and there are 1 bit per pixel. This means, that the data must be of length:

567 * 652 / 8 = 46210.5

As you can see from the screenshot, the length of the data is

46210

When fo-dicom wants to get the overlay-data from the last 4 pixels, it does all the bit-shift operations, and has to access the 46211th byte of the overlaydata, but this is not present.

i wonder if this is valid, that the overlaydata contains too less data. I did not find something in DICOM standard, that the data may be less and the renderer has to assume that the missing data shall be 0, or similar.

This file could be fixed easily. the overlay renderer has to check if the data length before accessing, instead of assuming that all data is present.

[amoerie]

While I agree with @gofal that it is an invalid DICOM file, I do feel that we should simply ignore this invalid overlay data while rendering. See my pull request for a fix.

[gofal]

No, I did not say that this DICOM image was invalid! I was wondering (a.k.a. asking) if this would be valid. I did not find something explicit that allows the pixel data to be shorter, but I also did not find something that says that the pixel data is required to have some minimal length.
This was a call for reading the standard. I did not have the time and wanted to do it later then.

[gofal]

So, as I mentioned, I also could not find any spot in the standard, that says that the data needs to have a certain length.
Instead there is something like: https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.9.2.html

The overlay bits corresponding to all the pixels included in the Graphics shall be set to 1. All other bits are set to 0.

This can also be be interpretatet, that the OverlayData has to contain a 1 in all pixels that belog to the overlay graphic, everything else should be considered as 0.

There is also in the dicom-standard, that the value has to be of even length in bytes. So if they would have added the 4 0-bits, then they would also have to add 12 more bits, so that the data has a even length in the end, 46212 bytes. So dropping the 4 last bits if they are 0 might be fine.

[amoerie]

Ah sorry for misinterpreting your words, carry on. So you would append zeros as needed?
Do we know how other DICOM libraries handle this?

[gofal]

yes, that is what I can read from the standard, that the OverlayData has to contain the 1 values, that correspond to the graphic, and the rest can be assumed for 0.
And no, I do not know what other libraries are doing. This issue requires some research.

[mrbean-bremen]

I very much doubt that the 0 bits are optional. As far as I understand, OverlayRows/OverlayColumns are handled the same way as Rows/Columns. Also the definition of OverlayData points in this direction, as far as I understand it:

Overlay pixel data.

The order of pixels encoded for each overlay is left to right, top to bottom, i.e., the upper left pixel is encoded first followed by the remainder of the first row, followed by the first pixel of the 2nd row, then the remainder of the 2nd row and so on.

Also, the wording:

The overlay bits ... shall be set to 1. All other bits are set to 0.

sounds to me like they shall indeed be set, not assumed to be set.

I have seen overlay data that starts or ends outside of the actual image (e.g. with a negative offset) and of all sizes, but I have never seen overlay data not "filled up". This is no evidence to the contrary, of course...

[amoerie]

I think I agree with @mrbean-bremen
Also, I think I found how dcm4che handles it:

https://github.com/dcm4che/dcm4che/blob/b69cac25c1f613acc725a8c1cbb738db871d0fb6/dcm4che-image/src/main/java/org/dcm4che3/image/Overlays.java#L270-L273

Looks like they ignore it. :-)

Edit: it also looks like they do a sort of "best attempt" at drawing the overlay data and ignoring the IndexOutOfRangeException when it occurs: https://github.com/dcm4che/dcm4che/blob/b69cac25c1f613acc725a8c1cbb738db871d0fb6/dcm4che-image/src/main/java/org/dcm4che3/image/Overlays.java#L288
but maybe that relates more to what you said @mrbean-bremen, about overlay data indices being shifted somewhat.

[amoerie]

I think silently ignoring the invalid overlay data is a better experience than throwing an Exception while trying to render. We could perhaps have also chosen the path to throw a clearer exception ("You cannot render this image because the overlay data pixels does not have the correct number of bytes!" or something like that. It would be better than IndexOutOfRange), but in most cases we're just receiving DICOM files from the modalities and we don't really have a say about it.
I think the proposed changes align nicely with the mantra indeed: be tolerant to input and strict with output.