Study with Photometric Interpretation YBR_FULL_422 are "green"

[asemeria]

Hello to everyone,

when I try to visualize a study with Photometric Interpretation YBR_FULL_422 the images are "green". Seems like there is trouble with the color channels.

If I open the same study with another viewer (weasis or osirix) the images are correctly shown.

I have this problem with OHIF Viewer v2 and v3-stable.

Below is a snippet of the viewer configuration

imageRendering: 'wadors'
thumbnailRendering: 'wadors'

If I replace wadors with wadouri the images are correctly shown.

Can you help me?

[sedghi]

I'm investigating this early next week.

[sedghi]

is this still happening in the latest master branch?

[asemeria]

Hi @sedghi I will check next week.
Did you fix it?

[sedghi]

We had couple of fixes, so please try

[niirdan]

same issue v3.8.0beta-27

[sedghi]

Could you kindly provide the data if it has been anonymized and you can confirm that there is no patient health information present in any of the headers or embedded within the pixel data?

[sedghi]

Check out the latest master branch, it is most likely fixed

[BITC01]

I'm running 3.8.0-beta.54 and still seeing the same issue here. Do you still need some test data ? I might be able to provide some if it's still needed.

[sedghi]

It's not just about the data, but also about what servers do (arbitrarily). It would make sense to send both the data and server information.

[niirdan]

@BITC01
Hey, the issue has already fixed
@sedghi helped me a lot solving it

Cloning the latest version should solve the problem.

Adding this :

dataSources: [
{
...
acceptHeader: [ 'multipart/related; type=application/octet-stream; transfer-syntax=*']
},
}], to your configuration file (under dataSources) will also solve the issue

[sedghi]

You don't need this even anymore, it is default

[sedghi]

but try

[BITC01]

@BITC01 Hey, the issue has already fixed @sedghi helped me a lot solving it

Cloning the latest version should solve the problem.

Adding this :

dataSources: [ { ... acceptHeader: [ 'multipart/related; type=application/octet-stream; transfer-syntax=*'] }, }], to your configuration file (under dataSources) will also solve the issue

I tried that but it didn't work unfortunately, We are not using OrthanC as our server so it's something else.
A little more information before I go through the process of uploading. I have tried the same with Uncompressed studies and it works fine(ie; xfersyntax=1.2.840.10008.1.2.4.50= Jpeg Process 1) . Its just UltraSound studies that have been compressed jpeg lossless (We are encoding as Process 14 =xfersyntax= 1.2.840.10008.1.2.4.57).
Our reply sends the following header in response to the ..frames/1 call to wadors.

Content-Type: "image/jpeg"; transfer-syntax=1.2.840.10008.1.2.4.57
and we also send back the raw pixel data from the dicom file without conversion as far as I can tell.

Thanks for looking into this.

P.S. I've also looked at 0028,0004(PHOTOMETRIC) in metadata we are sending YBR_FULL.

[sedghi]

As i said it is about servers, they sometimes tell (in metadata) that it is YBR_FULL but in reality it is something else. So it is a bug in your server, we are trying to catch those anomalies here, maybe stay tuned and that will fix it, but in reality it is the server issue cornerstonejs/cornerstone3D#829

[BITC01]

As i said it is about servers, they sometimes tell (in metadata) that it is YBR_FULL but in reality it is something else. So it is a bug in your server, we are trying to catch those anomalies here, maybe stay tuned and that will fix it, but in reality it is the server issue cornerstonejs/cornerstone3D#829

I have written a bit of code to replace the metadata with whatever it "should" be. Can you tell me how I can figure out what it should be. I've replaced the metadata with "RGB" , "YBR_FULL_422" and neither of those values make a difference. If I can see it in the BINARY data somewhere maybe that would lead me to the right place ?

[sedghi]

The server should respond with whatever the client is asking, if it is asking for * it should return as it is, and if it converts the color spaces the metadata should be in sync

you can read more here https://discourse.orthanc-server.org/t/orthanc-convert-ybr-to-rgb-but-does-not-change-metadata/3533?u=alireza

[BITC01]

I read that thread before posting here. It is what lead me to believe that the issue is the colorspace. However unlike in orthanc , our server simply sends back the pixeldata AS IS. The server does not decompress it , thus the Metadata PHOTOMETRIC value and the actual colorspace for the pixel data should be in sync naturally. However I'm still seeing the green overlay.
Is there a test I can perform on the binary pixeldata we're returning to make sure it's colorspace matches what is in the metadata.
I do have access to the server code and I'm attempting to find this bug, if it is indeed in the server I'd like to squash it.
btw Thanks for your assistance and attention to this.

[sedghi]

YBR and RGB can't be easily distinguished by the pixel data. I've shared a link to a PR in Cornerstone3D. Once it's merged, it might solve your problem. In the meantime, you can try checking out that branch and locally linking it to OHIF for testing purposes.

https://docs.ohif.org/development/link/

[BITC01]

just a small added bit of info JIC it makes a difference . We are using Dgate for the dicom compression.

[BITC01]

YBR and RGB can't be easily distinguished by the pixel data. I've shared a link to a PR in Cornerstone3D. Once it's merged, it might solve your problem. In the meantime, you can try checking out that branch and locally linking it to OHIF for testing purposes.

https://docs.ohif.org/development/link/

@sedghi
I'll link it in and see if it makes a difference. Thanks again for you assistance.

[BITC01]

@sedghi
I hope it's ok to ask this here. I can make this request elsewhere if there's a more appropriate location .
I had some time today to try and link in the PR you were discussing. But first I followed your tutorial on linking in cornerstone3d tools into ohifviewer. before I did the yarn link @cornerstonejs/tools I was able to successfully run yarn dev and yarn run build. Once I linked it in i am now getting an error whenever I try to yarn run build or even yarn dev. I get the following error output from yarn

using description file: /data/OHIFv3Working/node_modules/@kitware/vtk.js/package.json (relative path: ./Filters/General/ContourLoopExtraction)
@ohif/app: no extension
@ohif/app: Field 'browser' doesn't contain a valid alias configuration
@ohif/app: /data/OHIFv3Working/node_modules/@kitware/vtk.js/Filters/General/ContourLoopExtraction doesn't exist
@ohif/app: .js

I'm not a big react person so I'm at a bit of a loss as to where to go from here. If you might have a pointer in the correct direction that would be great.

[sedghi]

You need to upgrade vtk.js on OHIF, we have PRs soon, but since you are linking you should add that

[BITC01]

@sedghi
As requested in the office hours last week I have found a study that exhibits the behavior outlined in this thread. I have verified this by using https://viewer-dev.ohif.org/localbasic . I have attached the zipped study to this post.
As a reminder to the discussion in office hours I was able to generate an OHIF viewer with the Cornerstone3d PR #829 and have verified that PR does not fix this issue.
I also need to correct a statement I made above. We are not compressed as transfer-syntax= 1.2.840.10008.1.2.4.57 , We ARE compressed as transfer-syntax= 1.2.840.10008.1.2.4.70.
Please let me know if I can provide any more information or study data.
BrokenUS.zip

[sedghi]

closing in favor of #4082