View in #ohif on Slack
@Riccardo_Sapuppo: Why do all the RGB images look like this?
@Bill_Wallace: They don’t all look like that, but clearly your samples look like that. It might be an issue in the encoding side, or it might be a bug in cornerstone decoding. Can you try drag and drop onto the viewer-dev version of this at http://viewer-dev.ohif.org That is entirely local to your system so none of the data is shared. Then, I would join tomorrow’s OHIF office hours and bring that issue up as something to look at.
In the meantime, download dcm4che toolkit and run dcm2jpg on your file - that will create an image that the dcm4che toolkit thinks is correct. If that one is good, and OHIF is bad, then probably we need to look at why it is getting decoded that way, and for that we will need to look at header data. It is probably sample by plane representation, but there are several other options.
@Riccardo_Sapuppo: in the viewer-dev version same issue.
The strange thing is that sometimes, or if I resize the window, some images display correctly during scrolling. Could it have something to do with the GPU?
I modified the study, leaving only a couple of instances, and it displays them correctly. If I reload the study with all the series and all the instances, those same ones from before are not visible. Memory issues or something else?
Here is the anonymized DICOM. If you try to open it with http://viewer-dev.ohif.org, you can see the problem
I think problem is planar configuration and RRGGBB. I don’t know why, but despite the Planar Configuration tag (0028,0006) being set to 1, it is being treated as 0 and as RGB instead of RRGGBB.
@Bill_Wallace: Yes, that is correct, we don’t have decoding support for planar configuration 1
Can you create a defect please?
OHIF Office hours are on now - you could join to ask about your issue -
@Riccardo_Sapuppo: I saw that my question has been added to the Google Docs.
Is there anything else I can do?
@Bill_Wallace: Did you create an issue for this?
@Riccardo_Sapuppo: In the meantime, as a workaround, I use Node.js and Sharp to convert the bitmap I receive via WADO to JPEG on the fly and distribute it with the transfer syntax 1.2.840.10008.1.2.4.50.
@Bill_Wallace: You can also use dcm4che or another toolkit for the conversion
@Riccardo_Sapuppo: Ok, thank you
https://github.com/OHIF/Viewers/issues/4359
@Bill_Wallace: Talking about it in office hours, seems to work in OHIF v2
The fix is in isColorConversionRequired - just need to check that and create a PR