[Bug] v3 and v2: RGB inconsistencies

[igoroctaviano]

RGB inconsistencies

Sample 1 (frame 23)

• Env: https://ohif-v3.web.app/viewer?StudyInstanceUIDs=1.3.6.1.4.1.14519.5.2.1.1078.3273.132220854463485495034769662271

Sample 2 (series with 397 slices)

• Env: https://ohif-v3.web.app/viewer?StudyInstanceUIDs=1.3.6.1.4.1.14519.5.2.1.1188.2803.215544713257596275140185968379

Sample 3

• Env: https://ohif-v3.web.app/viewer?StudyInstanceUIDs=1.3.6.1.4.1.5962.1.2.0.1677425356.1733

Sample 1 (v2)

• Env: https://testing-viewer.canceridc.dev/viewer/1.3.6.1.4.1.14519.5.2.1.1078.3273.132220854463485495034769662271

Sample 2 (v2)

• Env: https://testing-viewer.canceridc.dev/viewer/1.3.6.1.4.1.14519.5.2.1.1188.2803.215544713257596275140185968379

Sample 3 (v2)

• Env: see IDC OHIF v3 gaps document or ask @fedorov

[vicongit23]

Moving from 2934 issue branch. The problem is in cornerstone CornerstoneRender: using GPU rendering

[vicongit23]

The problem is GPU case ( I have "intel uhd graphics 630") ---also checked on GPU ATI Radeon- same problem Same environment , same dicom is rendered ok on CPU:

Can be that there is missing /additional RGB<->RGBA buffer transformation in case of GPU in postProcessDecodePixel flow ?

[vicongit23]

Please look at https://github.com/cornerstonejs/cornerstone3D/pull/707

[vicongit23]

Another aspect of the problem ( same RGB image degradation), but different workflow: OHIFserver/Local-> load RGB file- >see display v3.6.0- image is fine. v3.7.0-beta.41- image is mangled (` seen initially on v3.7.0-beta.37) .

[igoroctaviano]

@vicongit23 I noticed that the cornerstone issue you mentiioned was closed. Were you able to reproduce the problems presented in this issue with the new changes?

[vicongit23]

@vicongit23 I noticed that the cornerstone issue you mentiioned was closed. Were you able to reproduce the problems presented in this issue with the new changes?

With the change in https://github.com/cornerstonejs/cornerstone3D/pull/707 cornerstone "local" example behaves properly ( If I understood the question)

[igoroctaviano]

@sedghi @wayfarer3130 some updates using cornerstone3d 1.10.0 version which includes 703:

Sample 1 fixed

Sample 3 not fixed

There should be a single color image, not 3x3 B&W tiles - both for the image and for the thumbnails.

Sample 2 is still problematic (now the thumbnails are bad too compared to the PR screenshot before 703 changes)

You can test sample 2 using the same dicomweb (public) in this env: https://ohif-v3.web.app/viewer?StudyInstanceUIDs=1.3.6.1.4.1.14519.5.2.1.1188.2803.215544713257596275140185968379

[fedorov]

Looking at the sample 3, it is NOT fixed. There should be a single color image, not 3x3 B&W tiles - both for the image and for the thumbnails.

[igoroctaviano]

Looking at the sample 3, it is NOT fixed. There should be a single color image, not 3x3 B&W tiles - both for the image and for the thumbnails.

Thx for the input, I just updated the last comment.

[wayfarer3130]

Please include the relevant metadata and DICOMweb frame level header data. Without that, it is impossible to tell if this is failing because the data is wrong, or there is a bug in OHIF. Even if it is a bug in OHIF, it may well not be related to the changes made recently, which were mostly a decompression related issue. Ideally I'd like to have the DICOM file as well as the headers for accept and response, and the first 5 lines of the response data itself (so that it is possible to tell how the response is encoded.)

[fedorov]

Please include the relevant metadata and DICOMweb frame level header data.

Do you need this even though the dataset is public?

Or do you need instructions how to access the underlying dataset?

[fedorov]

@wayfarer3130 @sedghi if you would like to access a sample XC modality image for your testing, like the one above, we have them in public IDC buckets. Here's a quick 2-step process:

1. Download s5cmd binary release for your platform.
2. Run this command: s5cmd --no-sign-request --endpoint-url https://s3.amazonaws.com cp "s3://idc-open-data/56f8119f-5940-48c1-96ee-8d445dc0b5fd/*" .

If you would like more details etc about that dataset, check out this notebook.

[wayfarer3130]

I will download that dataset (in progress actually - command seems to take a really long time - have left it 5 minutes now), but I do need the headers as they come from the PACS back end as well. The reason is to figure out where the issue is coming from - OHIF or the PACS back end system. At a minimum, having the PhotometricInterpretation from the metadata and the .../frames/1 first 5 lines of the response, plus the response headers is needed. There are a few other things I might need still, but those can wait for the moment - I can grab those from the DICOM headers.

[wayfarer3130]

s5cmd doesn't seem to work for me. Will try the windows 32 bit version to see if it is any different. Finally ran - looks like s3 was having problems, it took quite a while to perform a handshake, but once it did, the rest went ok.

[fedorov]

looks like s3 was having problems

Can you confirm - did you use s3 or s5cmd?

I used s5cmd, but the s3 back end was having issues with the https negotiation. That seems to be working now, and I have downloaded and confirmed I'm also seeing issues.

[fedorov]

I will download that dataset (in progress actually - command seems to take a really long time - have left it 5 minutes now), but I do need the headers as they come from the PACS back end as well. The reason is to figure out where the issue is coming from - OHIF or the PACS back end system. At a minimum, having the PhotometricInterpretation from the metadata and the .../frames/1 first 5 lines of the response, plus the response headers is needed.

@igoroctaviano can you add Bill to the v3 sandbox you set up?

[igoroctaviano]

I will download that dataset (in progress actually - command seems to take a really long time - have left it 5 minutes now), but I do need the headers as they come from the PACS back end as well. The reason is to figure out where the issue is coming from - OHIF or the PACS back end system. At a minimum, having the PhotometricInterpretation from the metadata and the .../frames/1 first 5 lines of the response, plus the response headers is needed.

@igoroctaviano can you add Bill to the v3 sandbox you set up?

The sandbox is using the same IDC config (oidc) which means that we don't have more seats, right?

[fedorov]

You are right. Sorry, I keep forgetting about this...

@wayfarer3130 I will PM you.

[wayfarer3130]

The issue is that the Planar Configuration is 1 and that isn't being handled by OHIF. That means the images use the RGB format as: R1 R2 R3 .... G1 G2 G3 etc Looking now to see where that is occurring.

[sedghi]

@wayfarer3130 it is not in OHIF, it should be in the dicomImageLoader, maybe even in the createImage and decodeImageFrame

[wayfarer3130]

The code got removed to handle the colour space conversion. It is a mess, but I hope to push a fix later today: https://github.com/cornerstonejs/cornerstone3D/pull/730 That branch is working for me, but has a bunch of inconsistencies still depending on how images are encoded.

[wayfarer3130]

@wayfarer3130 it is not in OHIF, it should be in the dicomImageLoader, maybe even in the createImage and decodeImageFrame

Yes, it is in createImage - should have said CS3D instead of OHIF.

[wayfarer3130]

@igoroctaviano - could you try the current branch of CS3D? You might need to ensure it gets linked properly, as sometimes yarn link fails to work as expected.

[igoroctaviano]

• /viewer?StudyInstanceUIDs=1.3.6.1.4.1.5962.1.2.0.1677425356.1733

I tried the branch locally, here's the results: @fedorov

Sample 1

http://localhost:3000/viewer?StudyInstanceUIDs=1.3.6.1.4.1.14519.5.2.1.1078.3273.132220854463485495034769662271

Sample 2

http://localhost:3000/viewer?StudyInstanceUIDs=1.3.6.1.4.1.14519.5.2.1.1188.2803.215544713257596275140185968379

Sample 3

http://localhost:3000/viewer?StudyInstanceUIDs=1.3.6.1.4.1.5962.1.2.0.1677425356.1733

[fedorov]

Looking good!