Multiframe images are not working

OHIF / Viewers

OHIF zero-footprint DICOM viewer and oncology specific Lesion Tracker, plus shared extension packages

https://docs.ohif.org/

MIT License

3.13k stars 3.3k forks source link

Multiframe images are not working #539

Closed ZYuanCheng closed 5 years ago

ZYuanCheng commented 5 years ago

V2.0 Select US type dicom ,but not running. and V1.0 meteor can be running. Click the cine play button and it will not play.

dannyrb commented 5 years ago

@ZYuanCheng, I am unable to reproduce on: https://viewer.ohif.org

What are the steps to reproduce? Can you provide a minimal reproduction? Is the issue specific to this study? What versions of the dependent libraries are you using?

ZYuanCheng commented 5 years ago

I am using the latest version of the current master. I imported the US image type file in dcm4chee-arc. In the previous meteor version, I can animate it, but now I don't. I found that the requested dicom data only requested a dicom data. File, this should be a bug in this react version

dannyrb commented 5 years ago

I don't 100% follow. If you could provide a full-proof way to reproduce these steps, or a minimal example in a new repo, I would be more than happy to investigate further.

ZYuanCheng commented 5 years ago

Because I don't have an external network environment, I can only provide some sample files. You can import them into dcm4chee-arc-light and view them in OHIF. You can see the above problem.

imagesdc.zip

dannyrb commented 5 years ago

ZYuanCheng commented 5 years ago

This zip file contains the dicom files, you need to extract the zip file and import these dicom files into dcm4chee-arc-light 5.4 or higher.The decompression tool I use is WinRAR. imagesdc.zip

vicOnGit75 commented 5 years ago

Are there any updates-I experience the same problem. Also I succeeded to unzip ZYuanCheng's dataset- if needed I upload few files directly.

dannyrb commented 5 years ago

FWIW, I see this issue and a rendering issue with the provided images. I'm unsure of the best path forward here. Having a known good test case in our default dataset would be helpful.

I haven't played with this enough to identify the exact issue, but it is something that we should address.

vicOnGit75 commented 5 years ago

To be on the same page: is "default dataset" the one on https://server.dcmjs.org (dcm4chee-arc/aets/DCM4CHEE/rs/)? Asking cause there are no multiframe DICOM files there and it looks that the problem is not only with US, but with multiframe files from other modalities (XA, NM) also.

swederik commented 5 years ago

Hmm that would definitely be a problem. I haven't tested specifically with multiframe images.

swederik commented 5 years ago

Yep I can confirm that this is the issue:

The first series in this is a multiframe: https://viewer.ohif.org/viewer/1.3.6.1.4.1.5962.99.1.3814087073.479799962.1489872804257.3.0 and it does not appear to be working.

var element = window.store.getState().viewports.viewportSpecificData[0].dom 
cornerstoneTools.getToolState(element, 'stack').data[0].imageIds

Looks like the imageIds for all images in the stack are identical

Somehow OHIF/Viewers/Packages-react/ohif-core/src/utils/getWADORSImageId.js must be called with the wrong frame value.

vicOnGit75 commented 5 years ago

Looks that replacement in getWADORSImageUrl(instance, frame)

wadorsuri = wadorsuri.replace(/(%2Fframes%2F)(\d+)/, "$1".concat(frame)); to wadorsuri = wadorsuri.replace(/frames\/(.*)/, 'frames/'.concat(frame));

does the work.

ohif-bot commented 5 years ago

:tada: This issue has been resolved in version 0.8.2 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

adityapol1058 commented 2 years ago

How to fix this issue while displaying the DICOM image in OHIF using the JSON supplied via the '?url=' query parameter? @vicOnGit75 @dannyrb @swederik