dicomcloud / dicomcloud

Azure friendly DICOMweb part 18 .NET server with qido-rs, wado-rs, stow-rs, wado-uri RESTful implementation

Deploy to Azure

Development Branch:

You can see the details of this Azure Resource Manager (ARM) Template here

Overview

The DICOMcloud is a standalone DICOMweb server with RESTful implementation of the DICOMweb/WADO services:

• QIDO-RS: Look up studies, series, images. Results will be limited to a maximum results. more info

• WADO-RS: Retrieve studies, series, images, frames and metadata

• STOW-RS: Store DICOM instances/images

• WADO-URI: Web Access to DICOM objects

Additionally, the server implements the following RESTful services which are not part of the DICOM standard:

• DELOW-RS: Delete DICOM instances/images

• OHIF-Viewer: Integration service with the OHIF viewer, return OHIF formatted study information (series and instances) Click here to learn more about using the DICOMcloud server and the OHIF Viewer.

 

The DICOMcloud server can interface with any DICOMweb client over the current implemented features (qido-rs, wado-uri, wado-rs and stow-rs).

Official documentation and examples can be found here:

https://dicomcloud.github.io/docs/dicomcloud/about/

Online Version:

An online version is hosted in Azure: https://dicomcloud.azurewebsites.net/

A DICOMweb Client demo is hosted live at: http://dicomweb.azurewebsites.net/

The Client demo source code is avaialbile here: https://github.com/DICOMcloud/DICOMweb-js

Architecture:

The DICOMcloud is a web server that can interface with any DICOMweb client over the current implemented features (qido-rs, wado-uri, wado-rs and stow-rs).

An example DICOMweb client implementation with viewer support is provided here.

The implementation is customizable by using StructureMap as a DI (Dependency Injection) framework to provide a plug-in architecture.

The main layers of the DICOMcloud:

Layer	Description	Project Name	Nuget Link
WebAPI RESTFUL Services	The webservice implementation as an ASP.NET WebAPI	DICOMcloud.Wado.WebAPI
DICOMweb Core Services	The DICOMweb implementation for processing web requests and returning web responses.	DICOMcloud.Wado
DICOM Services	The core DICOM code and business services that process the DICOM datasets, perform query, retrieve and store. With interfaces to classes for storage and data access.	DICOMcloud
Data Storage and Data Access	The specific implementation layer that physically save the DICOM dataset media to a file system or Azure Blob and interface with Microsoft/Azure SQL database.	DICOMcloud DICOMcloud.Azure DICOMcloud.DataAccess.Database	&

Platform:

The code is written in C# .NET Framework 4.5.2 and can be built using Visual Studio 2017 and can run on Windows machine or Azure WebApp.

The project uses MS SQL Database (Azure SQL Database compatabile) to query the DICOM information and saves the DICOM datasets to either the file system or an Azure Blob Storage.

Running the code

You will need Visual Studio 2017/2015 (can be downloaded for free here). Open the solution file DICOMcloud.sln on the root directory, if not already selected as the StartUp Project, right click on the "DICOMcloud.Wado.WebApi" project and select "Set as startup project" then run the solution by pressting F5.

Once you run the project, the DICOMweb server will run on https://localhost:44301/ and the default settings will attach an empty database to your local SQL DB server installed with Visual Studio (LocalDb)\MSSQLLocalDB and the images will be written to a directory under the "App_Data" folder.

You can change these settings from the web.config by updating the two values under the appSettings section:

 <add key="app:PacsStorageConnection" value="|DataDirectory|\App_Data\Storage\ds" />
 <add key="app:PacsDataArchieve" value="Data Source=(LocalDb)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\DB\DICOMcloud.mdf;Initial Catalog=DICOMcloud;Integrated Security=True" />  

Endpoints

A detailed endpoints URLs with parameters can be viewed here: https://dicomcloud.azurewebsites.net/swagger/

DICOM Support

The tables below describes the DICOMweb featrues currently implemented in the DICOMcloud project.

QIDO-RS

Feature	Support	Notes
application/dicom+xml	Y
application/json	Y
Studies	Y
Series	Y
Instances	Y
relational query	~
fuzzy matching	Y	Always supported
ranges	Y
includefield	Y
sequences	Y
limit	Y
offset	Y
dicomKeyword group element	N
dicomKeyword name	Y
TimezoneOffsetFromUTC	N

WADO-RS

Feature	Support	Notes
application/dicom+xml	Y
application/json	Y
transfer-syntax	Y
Retrieve Study	Y
Retrieve Series	Y
Retrieve Instance	Y
Retreive Frames	Y
Retrieve Bulkdata	Y	header is missing Content-Location: {BulkDataURI}
Retrieve Metadata	Y

STOW-RS

The server can be configured to anonymize the DICOM image by default by enabling the feature in the web.config:

 <add key="app:enableAnonymizer" value="true"/>
 <add key="app:anonymizerOptions" value="BasicProfile,RetainUIDs,RetainLongFullDates,RetainPatientChars"/>

Feature	Support	Notes
application/dicom	Y
application/dicom+xml	Y
application/dicom+json	Y
Multipart store	Y	can process multiple instances in single request

WADO-URI

Feature	Support	Notes
application/dicom	Y
Frame Number	Y
Charset	N
Anonymize	N
Transfer Syntax	Y
Charset	N
Annotation	N
Rows	N
Columns	N
Region	N
Windows Center	N
Window Width	N
Image Quality	N
Presentation UID	N
Presentation Series UID	N

Dependencies:

The DICOMcloud project utilizes the opensource fo-dicom DICOM library for operations on the DICOM datasets, such as reading and writing elements, compress/decompress the DICOM images, anonymization feature and many others.

License

Copyright 2017 DICOMcloud Contributors

Licensed under the Apache License, Version 2.0 (the "License"); 
you may not use this file except in compliance with the License.
You may obtain a copy of the License at 
    
    http://www.apache.org/licenses/LICENSE-2.0
    
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

dicomcloud's Issues

How can I config to connect to DIMSE pacs

Hi,

I 've tried connect DIMSE pacs and get json string.
I greatly appreciate if anybody tell where and how can I config?

Allow configuring the StoreCommand by passing "StorageSettings" instance from the application

Expected Behavior

The "StorageSettings" class can be instantiated, configured and passed to the "StoreCommand".

Actual Behavior

There is no way to pass the "StorageSettings" class to the StoreCommand upon instantiation. Currently, the only way is to update the "Settings" property after the command is created.

Steps to Reproduce the Problem

QIDO-RS ignores matching parameters value when requested for return

Issuing a QIDO-RS with a matching parameter value is ignored when this matching parameter is also requested for return (includefield).

Example: Query SOP Instances with a Study Instance UID (0020000D*) as matching and return:

https://dicomcloud.azurewebsites.net/qidors/instances?0020000D=1.2.392.200036.9116.2.6.1.3268.2051314020.1461904638.200374&includefield=00080018&includefield=0020000E&includefield=0020000D

STOW-RS not working

I'm trying test Dicomcloud on my local dev. enviroment , stow request responded with this XML:
<?xml version="1.0" encoding="utf-8"?><NativeDicomModel> <DicomAttribute keyword="TransferSyntaxUID" tag="00020010" vr="UI"> <Value number="1">1.2.840.10008.1.2.1</Value> </DicomAttribute> <DicomAttribute keyword="FailedSOPSequence" tag="00081198" vr="SQ"> <Item number="1"> <DicomAttribute keyword="SOPClassUID" tag="00080016" vr="UI"> <Value number="1">1.2.840.10008.5.1.4.1.1.4</Value> </DicomAttribute> <DicomAttribute keyword="SOPInstanceUID" tag="00080018" vr="UI"> <Value number="1">1.3.12.2.1107.5.2.30.27908.2017091907422330142800031</Value> </DicomAttribute> <DicomAttribute keyword="FailureReason" tag="00081197" vr="US"> <Value number="1">272</Value> </DicomAttribute> </Item> </DicomAttribute> <DicomAttribute keyword="RetrieveURI" tag="0040E010" vr="UR"> <Value number="1">https://localhost:44301/wadors/studies/</Value> </DicomAttribute> </NativeDicomModel>
according to http://dicom.nema.org/dicom/2013/output/chtml/part18/sect_6.6.html
the failure reason is : 0110 - Processing failure
The STOW-RS Service did not store the instance because of a general failure in processing the operation.
project is running without any errors and i can't find its reason.
can u help me?

Only single item in a ReferencedInstanceSequence is returned

Similar to issue #15 but for successful instances.

Expected Behavior:
When more than one instance succeed in a Store request, the returned ReferencedInstanceSequence should contain an item for each successful instsance.

Current Behavior:
When more than one image succeed in a store request, only single item is returned in the ReferencedInstanceSequence .

Add a way to sort the qido results on the server

Currently the query results are not sorted in any particular order. Add a mechanism on the server to control how the results should be sorted.

Dataset TransferSyntax is not updated when image is recompressed

Expected Behavior

When requesting an image with a transfer syntax (e.g. J2K) the returned image is compressed and the DICOM Dataset transfer syntax should reflect the new compression

Actual Behavior

The image is compressed but the transfer syntax is always "Explicit VR Little Endian"

Steps to Reproduce the Problem

1. Store an image
2. Request the image with J2K lossy tasnfer syntax (e.g. https://dicomcloud.azurewebsites.net/wadouri?RequestType=wado&studyUID=xxx&seriesUID=ccc&objectUID=vvv&contentType=application/dicom&transferSyntax=1.2.840.10008.1.2.4.91
3. Check the dataset header and it will be Explicit VR Little Endian although the image is compressed as J2K Lossy

wrong sequence being returned in stow-rs/store response

Expected Behavior

Successfully stored instances should be returned in "Referenced SOP Sequence"

http://dicom.nema.org/dicom/2013/output/chtml/part18/sect_6.6.html

Referenced SOP Sequence	(0008,1199)	1C	A sequence of Items where each Item references a single SOP Instance that was successfully stored.Required if one or more SOP Instances were successfully stored.

Actual Behavior

Successfully stored instances are returned in ReferencedInstanceSequence instead

Update MS dependencies to latest version

CORS error using DICOMCloud with Cornerstone

I have downloaded the Cornerstone library and am using it to test the DICOMCloud server. I use the test page provided in the project cornerstoneWADOImageLoader/examples/wadors/index.html and provide a wadors query which hits the DICOMCLud server (http:localhost:44301/wadors/studies/2/series/2/instances/2 )

cornerstone then makes a call to /wadors/studies/2/series/2/instances/2/metadata which is serviced by DICOMCloud correctly

however the next call is /wadors/studies/2/series/2/instances/2/metadata/frames/1

and this call when viewed in the network panel of the Chrome debugger shows a CORS error:
Access to XMLHttpRequest at 'http://localhost:44301/wadors/studies/2/series/2/instances/2/metadata/frames/1' from origin 'null' has been blocked by CORS policy: Request header field accept is not allowed by Access-Control-Allow-Headers in preflight response.

I checked a bit on internet and it seems some accept-headers may be missing as described in SO here:
[https://stackoverflow.com/questions/32500073/request-header-field-access-control-allow-headers-is-not-allowed-by-itself-in-pr
]

I will try to add the accept headers or disable CORS, any thoughts ?

QIDO: UID list parsing is not according to standard

Expected Behavior

A list of UIDs (e.g. StudyInstanceUID) shall be separated with ',' in the URL and not with ''.

From the standard: http://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_6.7.html#sect_6.7.1.1.1

Each {attributeID} query key shall be unique unless the associated DICOM Attribute allows UID List matching (see Section C.2.2.2.2 in PS3.4 ), in which case each {value} will be interpreted to be an element of the UID List.

The linked section http://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_C.2.2.2.2.html actually says, that the backslash () char shall be used, but this is for native DICOM only.

I did ask that question in the DICOM protocol group and got answered it now:
https://groups.google.com/forum/?hl=en#!topic/comp.protocols.dicom/NHA4l-q8Fo0

The correct implementation is to use commas in QIDO-RS; the PS3.18 trumps the reference in Part 4. We will submit a CP to make this more clear in the coming weeks.

Actual Behavior

When passing in e.g. "?StudyInstanceUID=1.2.3,1.2.4", the service accepts but does not return correct things.

Steps to Reproduce the Problem

See above.

Possible solution

One would need to add special handling for UI VR in the query service.

DICOMcloud/DICOMcloud.Wado/Services/QidoRsService.cs

Line 337 in cff2f16

uint tag = GetTagValue (tagString);

In case VR UI is passed an the value contains ",", then you would need to replace that value by a '' char. That is a quite simple line of code to change.

Cheers, Harald

STOW-RS Content-Type multipart not recognised

A DICOM-WEB client send a POST request on the STOW-RS endpoint with the following Header 👍

•   Request	{Method: POST, RequestUri: 'http://localhost:44301/stowrs', Version: 1.1, Content: System.Web.Http.WebHost.HttpControllerHandler+LazyStreamContent, Headers:
  

{
Cache-Control: no-cache
Accept: application/json
Accept-Encoding: gzip
Host: localhost:44301
User-Agent: LittleBrowser
Content-Length: 441283
Content-Type: multipart/related; type=application/dicom; boundary=---------------------------f0d9ae2
}}

But into stowRSController.cs line 29
if ( !Request.Content.IsMimeMultipartContent("related") )

The validation of multipartContent does not match.

With debug, the "Content" structure is
{Content-Length: 441283
Content-Type: multipart/related; type=application/dicom; boundary=---------------------------f0d9ae2
}
And the field Content-Type cannot be extracted.

Do you encountered this problem ?

Thanks

Eric

Easiest way to clear the DicomCloud Webapi server DB and storage?

I am testing the DICOMwebjs demo, and I am wondering if there is an easy way to clear the DB and all images stored in the DICOMCloud server?

Merge development v0.5.3-beta with master

Update to fo-dicom v4.0.0

Expected Behavior

DICOMcloud uses latest version of fo-dicom v4.0.0

Actual Behavior

Currently it is still on version v3.0.2.0

Sending a date range query in qido-rs request returns an error

Expected Behavior

Sending a date range query should find results between the given dates.
For example, a query with study date parameter value of: 20140309-20150309 should return results between 2014/03/09 and 2015/03/09

Actual Behavior

The server returns an error

Integrate with OHIF standalone Viewer

The standalone OHIF viewer now supports passing a URL parameter to a JSON file that contains the studies/series/images to be displayed. Issue #91

Create an endpoint in the DICOMcloud that receives a StudyInstanceUID and returns JSON data based on the format supporting by the

This will allow the studies in the DICOMcloud be directly viewable in the standalone OHIF viewer by providing the endpoint URL to a study and returning the JSON data for the viewer to consume.

Increase default upload limit from 4 MB to 10MB

Expected Behavior

When uploading an image with size of 10MB the server will store successfully.

Actual Behavior

The server will return an error as default upload limit is 4MB

Steps to Reproduce the Problem

How can I send DICOM Object to DICOMWeb Server?

I have tried with DICOM C-Store or DICOM C-Move to localhost:44301 but I can not success.

Support setting the content-type on Azure Blob storage

Expected Behavior

When reading a DICOM file from Azure blob storage, the content-type is set to "application/dicom"

Actual Behavior

Content Type is set to "application/octec-stream"

Add support for includefield value "all" in qido-rs

Expected Behavior

When the client sends a qido/query request with the includefield query parameter value of "all", the server should return all available attributes.

From the standard:

ncludefield={attributeID} | all

0-n includefield / {attributeID} pairs allowed, where "all" indicates that all available attributes should be included for each response.

Actual Behavior

Server returns an error.

Add support to redirect WADO-URI requests to read directly from Azure Blob Storage

Expected Behavior

When a user calls the WADO-URI service for a DICOM image that exists in Azure blob storage, the response should be redirected to the URL of the Azure Blob

This should reduce the overhead and latency of the request.

Actual Behavior

The applications reads the Azure Blob data into the webservice and is returned to the client directly.

This adds overhead and unnecessary time to download the Azure Blob locally and return it to the client.

Add database version table

With the changes to the database. It is worth adding a version table to track the changes.

WADO-RS retrieve frame is not working

Expected Behavior

Calling the WADO-RS with a frame number would return pixel data of that frame.

Actual Behavior

The frame is not returned.

Steps to Reproduce the Problem

Only single item in a FailedSOPSequence is returned

Expected Behavior:
When more than one instance fail in a Store request, the returned FailedSOPSequence should contain an item for each failed instsance.

Current Behavior:
When more than one image fail in a store request, only single item is returned in the FailedSOPSequence.

Wado-RS GetStudies not always working

I am trying to test more deeply the WADO services.

I see that when I place a breakpoint in the GetStudies method below and when I use the url http://localhost:44301//wadors/studies/20
It works, the breakpoint is hit!
This works also: http://localhost:44301//wadors/studies/20xasd

However if I use a URL with a dot

http://localhost:44301//wadors/studies/20.22
the breakpoint is not hit. I also tested from the DICOMCloud test page and I see that the breakpoint is not hit.

I think in this case the Controlleris interpreting the dot part of page insted of treating the whole last part as the StudyInstanceUID

From the standard the letters , numbers AND the "." should be supported.

Am I perhaps missing something or is there a simple fix since this is an important use case. Most UIDs tend to have dots as the separator.

[Route("wadors/studies/{StudyInstanceUID}")]
[HttpGet]
public HttpResponseMessage GetStudies
(
[ModelBinder(typeof(RsStudiesRequestModelBinder))]
IWadoRsStudiesRequest request
)
{
return WadoService.RetrieveStudy ( request ) ;
}

I am currently examining: https://stackoverflow.com/questions/27872820/how-can-i-use-mvc5-attribute-based-routes-with-a-dot-period-in-them
And there seem to be some web.config solutions there. I have tested adding the attribute to the modules tag as described in SO.

It works. They mention a possible performance penalty, however it should be minor for typical use cases for this code since these are low traffice servers. (not serving 1000's of pages per second...)
I will submit a PR directly onto the 4.0 branch.

qido-rs returns an error when query URL has an empty query param at the end

Use-case

User sends a study query request (qido-rs) to the server with an '&' appended to the end of the URL
e.g.
https://dicomcloud.azurewebsites.net/qidors/studies?00200010=&00080020=&00100010=&00100020=&limit=12&offset=0&

Expected Behavior

The server ignores the extra empty query parameter and returns results

Actual Behavior

The server returns a 500 error.

Steps to Reproduce the Problem

1. https://dicomcloud.azurewebsites.net/qidors/studies?00200010=&00080020=&00100010=&00100020=&limit=12&offset=0&

Consider making the SeriesId attribute Optional when storing dataset

The Series ID is a required attribute when querying a DICOM dataset. However, it seems there are a number of datasets that are missing this attribute and are failing to be stored.

I'm considering making this not a requirement at storage for the DICOMcloud and let the user enforce it they need to.

replace IObjectStorageDataAccess with IObjectArchieveDataAccess

This is a clean-up task. The empty IObjectArchieveDataAccess will be removed from the Database project and used to replace the IObjectArchieveDataAccess

Return standard error codes for storage

When storing a DICOM instance fails, there is not much information returned describing the reason.

Currently the following information is always returned instead:
HTTP Status Code: Conflict
The FailureReason (0008,1197) attribute: 272 ("0110 - Processing failure")

Proposed Solution:
The Failure Reason must should use any of the values defined in this table with Custom errors codes can be defined and documented to represent additional reasons

Custom Http Status Text can be returned in the response to include a descriptive reason

how can I delete it with DELOW-RS?

Hello, how can I delete it with DELOW-RS?
Request webapi “delowrs/studies/{studyInstanceUID}“
to display 404

Update version number to "0.5.3-beta" and build Nuget Packages

Upgrade projects to .NET 4.6.2

Code Refactoring and Name changes

• Making DICOMcloud.Wado.ModelBinders and DICOMcloud.Wado.ModelConverters easier to extend/customize

• Update to WadoRsRequest interface inheritance structure and fixing capitalization in the name.

• Use IStudyId, ISeriesId and IObjectId across the framework rather than passing strings.

• Fix interface/class name type "IRetieveUrlProvider" --> IRetrieveUrlProvider

• Remove connectionString dependency from ObjectArchieveDataAccess

Pagination is broken when including query parameters in a query level lower than requested

Expected Behavior

Doing a qido-rs study query and including modality (series level) for matching and a page size of 10 should return 10 studies that matches the request.

Actual Behavior

The returned studies will be less than 10 although there are 10 studies that matches the query.

Add support for "offset and "limit" parameters in QIDO-RS

Expected Behavior

When sending a qido-rs request to the server with the query parameters "offset" and "limit" the server should return responses = to the "limit" parameter starting from the "offset" index

Actual Behavior

The server ignores the "offset" and "limit" parameters

Support missing attributes in QIDO-RS

Expected Behavior

Doing a QIDO-RS request should return the following attributes:

Study Level:

Attribute Name	Tag
Modalities in Study	(0008,0061)
Number of Study Related Series	(0020,1206)
Number of Study Related Instances	(0020,1208)

Series Level:

Attribute Name	Tag
Number of Series Related Instances	(0020,1209)

Instance Level:

Attribute Name	Tag
Rows	(0028,0010)
Columns	(0028,0011)
Bits Allocated	(0028,0100)
Number of Frames	(0028,0008)

Actual Behavior

These attributes are not returned.

How to generate a series thumbnail

hi,Since loading the viewer is too long, I want to add a series list page, but I don't know how to generate the series thumbnail.
so，Need your help，thanks！

Create Release 0.5.4-beta and publish new packages

• Update version number
• Merge Development branch into Master
• Build and Publish NuGet packages

Support generating JPG pre-cached on store

When storing a DICOM file pre-generate a JPG image for quick retrieve.

Add support for mySQL database

Expected Behavior

Use can select mySQL database as a data store for structured storage/query

Actual Behavior

Only MS SQL Server is currently supported.

Steps to Reproduce the Problem

Store fails when only one of the RequestedProcedureID or ScheduledProcedureStepID elements is present in the dataset

The current implementation requires both attributes to be present in the database if one does. According to the DICOM standard, these attributes are type 1C and either one of them might be not present.

Proposed solution:
Make the RequestedProcedureID and ScheduledProcedureStepID optional in the database.

Requesting a JPEG image in WADO-URL request doesn't return a valid jpeg image format

Expected Behavior

When sending a WADO-URL with content-type "image/jpeg", a valid jpeg image should be returned by the server.

Actual Behavior

The data returned from the server is not a valid jpeg image.

Steps to Reproduce the Problem

1. Send a request to the DICOMcloud server in the format:
   http://localhost:44301/wadouri?RequestType=wado&studyUID=2.16.840.1.113669.632.20.130001.10006606097&seriesUID=1.3.46.670589.11.10175.5.0.22024.2011030510133425000&objectUID=1.3.46.670589.11.10175.5.0.22024.2011030510133503030&contentType=image/jpeg

Add support for attributeID "dicomKeyword" format in qido-rs

Expected Behavior

When sending a qido request with attributeID in the format of "dicomkeyword" (e.g. PatientID) the server should include and/or match based on this value

Actual Behavior

The server returns an error and doesn't process the request

Steps to Reproduce the Problem

1. send a request such as: http://dicomxxxx.azurewebsites.net/qidors/series?patientID=CR122
   A 500 error is returned.

Instructions for Azure deployment?

I am successfully running the DICOMcloud locally, but would like to install it into the Azure Cloud. I have located the azuredeploy.json, but it is pointing to non-existent URLs for resource download. I have also looked at the route through the Publish functionality from Visual Studio, but not sure which resources I need to setup in the cloud, especially how to properly get an Azure SQL instance properly configured with the required table structure.

Is there any documentation on the required steps for either route?

Add a configuration option to support Shared Access Signature/Self-Signed URLs

For cloud images (Azure), need an option to disable returning the WADO-URI images as a Shared Access Signature URL.

Add Changelog to track updates to the project

Expected Behavior

Project contains a changelog file to see changes between versions.

Actual Behavior

No change-log available

Add support to Amazon S3 | Simple Cloud Storage Service‎

Expected Behavior

Users can configure the server to store images to AWS S3 cloud storage

Actual Behavior

Users can only configure the server to store File system and Microsoft Azure

The first one of the sequence will be swapped with the middle image

Hello, I found a bug. If you upload enough images of a sequence, the first one of the sequence will be swapped with the middle image. (If you upload 5 images, there is no problem. If you upload 8 images, you will have problems. )

I also tried to modify the code, but I got some trouble. I found that there is no problem when looking up the database.，The first one is 097.

The instance also is no problem，the first one is also 097.

but the actionContext takes 124 when it takes the first one (my The sequence is from 097-150, so the first one (097) is interchanged with the middle one (124))

I hope you can help me：)

Support returning the "NumberOfFrames" in the OHIF viewer endpoint

This is to support displaying multi-frame images in the OHIF Viewer properly.

Expected Behavior

Call the OHIF endpoint metadata with a study of a multi-frame DICOM instance. The returned attributes list should contain the "numberOfFrames" attribute on the instance level.

Actual Behavior

This attribute is not returned which is causing the OHIF Viewer to only render the first frame

Steps to Reproduce the Problem

1. https://dicomcloud.azurewebsites.net//ohif/study/999.999.2.19960619.163000/series