Incorrect color rendering when a volume contains dcm files that window level (or color) differs a lot

[1isten]

Sample file:
MPFSL_SLICE_Anonymized.zip

Attached is a series with 2 dcm files, and their window level are quite different, one is light, another is dark.

In the latest main branch: https://volview-dev.kitware.app

if I try to load them separately, the rendering is correct:

but when load together as a whole volume, the light dcm becomes incorrect:

it looks like some pixel data is totally lost, no matter how I adjust the window level it cannot be adjust to the correct version

[1isten]

Side note:

I've also expirenced strange rendering result in the stable volview: https://volview.kitware.app , but the result is different from the latest version. When load the 2 dcm files together, intially, the dark one is totally black and invisible, and the light one looks quite dark, like this:

but the problem in the stable volview version is not so serious as in the dev volview, at least in the stable version, I can still adjust the window level to finally make them visible, below is after window level adjustment:

at least after change window level the image sort of becoming correct in the stable version, but for the latest version, the pixel seems totally lost..

[floryst]

I'll take a look. I wonder if the two slices operate in different data ranges.

[1isten]

@floryst thanks for your following up!

[JiaBob]

I met the same issue, and I found out the reason.

Those pixels were not lost but became unsign values. The value should be like "-530", but actually became like "65006". The problem happened due to the first instance of the series. If the pixel of the first instance is always larger than 0, then all instance inside the series were regarded to have unsigned value. But if the above showed error instance is the first one insides the series, then all of them are regarded as signed value.

To fix it, I think the visualization should not rely on the first instance in terms of signed or unsigned value.

[1isten]

Dear VolView team, it seems that the issue may be related to the new chunk-by-chunk loading logic. I would like to continue using the latest code from the current git branch, but is there a quick way to modify the code to switch back to the previous logic for reading/building the image volume, instead of loading it chunk by chunk? I noticed that the constructImage and buildImage functions are still present in datasets-dicom.ts, it just no longer appears to be used.

@floryst @PaulHax

[1isten]

Or if it possible to add some config option to conditionally switch between the new chunk-by-chunk loading logic or the legacy loading logic?

[floryst]

Yeah, the chunk-by-chunk loading logic does have this limitation. I can see about adding a "legacy" loading logic.

[1isten]

@floryst I discovered that the issue is not actually related to the chunk-by-chunk loading logic, but rather occurs within the allocateImageFromChunks function.

The new code introduces some steps to produce a vtkImageData object. I tried intercepting that function and used the old buildImage function from datasets-dicom.ts to construct the vtkImageData instead. As a result, the image was rendered correctly! This also resolves another issue I just opened.

I have created a PR that adds a legacy option to the allocateImageFromChunks function, allowing the use of the legacy buildImage function if needed. Hope this got merged.

[1isten]

Well... I may see why the new chunk-by-chunk codebase no longer uses the legacy buildImage (which I believe is calling some itk-wasm functions under the hood). I have encountered some RuntimeError: memory access out of bounds error when trying to call the legacy buildImage function in the new codebase when my dataset contains 1000+ dcm files

[1isten]

Well... I may see why the new chunk-by-chunk codebase no longer uses the legacy buildImage (which I believe is calling some itk-wasm functions under the hood). I have encountered some RuntimeError: memory access out of bounds error when trying to call the legacy buildImage function in the new codebase when my dataset contains 1000+ dcm files

Regarding the RuntimeError: memory access out of bounds ITK error I mentioned above, I found some clues here: InsightSoftwareConsortium/ITK-Wasm#1312 (comment)

Modifying the sanitizeFileName function to generate shorter filenames eliminates the error. So I am sure it is not related to the chunk-by-chunk loading logic; that ITK memory error may also occur in the stable VolView release.

[floryst]

Thanks for your detailed investigations! I'll hopefully look into this soon-ish, since I'm interested in ensuring that the data load step is producing correct data.