Open toropok opened 2 years ago
@toropok This might have been fixed by 0.16.8
@md-prog Thanks! will try it asap
@md-prog
This might have been fixed by 0.16.8
unfortunately it doesn't help
@toropok Indeed, it's unfortunate. It resolved mine.
@toropok Is there any chance you can post the anonymized DICOM file for us to test and fix?
It's really my problem.
I tested using cornerstone.setUseCPURendering(true)
and it worked.
A very strange thing, I've been testing example "DICOM P10 from local file system" the result was right. I don't see what the difference is.
I am having the same issue and could provide an anonymized study that reproduces it. I think it has to do with the way the windowing values are used but unsure. I tried the CPU rendering and the images will render correctly (but breaks some other things so I would like to stick to GPU rendering).
The odd thing is that when I load only 1 canvas, I am able to scroll through the images and it gets rendered correctly.
NOTE: The thumbnails are bitmaps so they are not cornerstone canvases.
As soon as another canvas comes in play, it will become white like this:
The cached images (when it was only 1 canvas active and I scrolled through few images) are actually loading fine and only the newly rendered images become white:
It really feels like one of the group 28 attributes is causing this issue and only for GPU rendering. Hope this can be fixed.
can you try again now, I moved the canvas rendering to gpu, but the API has changed to accept an object
For me, two issues were causing problems with window levels. I will file them separately, but for future reference I'll put a summary here:
cornerstoneDICOMImageLoader.wadouri.loadImage()
, I had to pass preScale: { enabled: true }
cornerstoneDICOMImageLoader.webWorkerManager.initialize()
during initialization, and not when I don't. Here's my exact call causing issues:
cornerstoneDICOMImageLoader.webWorkerManager.initialize({
maxWebWorkers: concurrency,
startWebWorkersOnDemand: true,
taskConfiguration: {
decodeTask: {
initializeCodecsOnStartup: false,
},
},
});
These issues are filed separately as #887 and #888, and might be related to this issue.
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?
The issues is occurring from me as well. Hope to fix this issue asap.
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?
https://drive.google.com/file/d/1XdpbPhwQQH3_3QiKiVmZ_QevRK2ECyFO/view?usp=sharing
Here is the images that I tried.
Any solution for this will be appreciated!
I've filed #887 and #888 as possible root causes for this issue, including reproduction cases and a workaround.
use cpu render
private _resizeUsingCustomResizeHandler( customRenderingViewports: StackViewport[], keepCamera = true, immediate = true ) { // 1. If viewport has a custom resize method, call it here. ... // 3. Reset viewport cameras customRenderingViewports.forEach((vp) => { const prevCamera = vp.getCamera(); vp.resetCamera();
if (keepCamera) {
vp.setCamera(prevCamera);
}
});
// 2. If render is immediate: Render all
if (immediate === true) {
this.render();
}
}
private getCameraCPU(): Partial
there is an error: Cannot read properties of undefined (reading 'direction') @sedghi
use cpu render. Enums.Events.VOI_MODIFIED Will not trigger the first time @sedghi
Hi,
For our custom DICOM viewer we use following libs:
Unexpetedly cornerstone adds a lot of white to images while rendering (except first image in series):
https://user-images.githubusercontent.com/14867014/192189820-f2121204-16e2-46d6-aac9-f1b9c6cae864.mov
But if you're setting CPU render only - this "white" effect dissappears
https://user-images.githubusercontent.com/14867014/192190164-878fa145-f29c-4782-9235-47687f553efd.mov
What may cause that?
regards, --leo