dcmjs-org / dicomweb-client Goto Github PK

Can you add the 'withcredentials' attribute to the request

It's possible to search for studies with ascending or descending order for a specific field in a query?

@hackermd @swederik @emelalkim - any objections or comments?

Now that we have dicomweb-server-js underway in dcmjs-org, it would be nice to have naming symmetry between the client and server.

In addition, the name dicomweb-client is already used for the python version. @hackermd and I decided at the start that it was odd to use the same name for two different implementations but we did it anyway. Now I want to reverse that decision.

So on balance I think it's better to rename the client to match the server.

See: OHIF/Viewers#736

Currently _httpGetMultipartApplicationDicom is called within the major functions like retrieveStudy, with progressCallback hardcoded to "false".

Example:
return this._httpGetMultipartApplicationDicom(url, mediaTypes, false, false, withCredentials);

It would bring a lot of value if one could handover a progressCallback via the "options" parameter to retrieveStudy. Without that, we cannot show any progress of the download to the user.

We continue to have issues with the Travis CI builds. Let's use GitHub Workflows instead.

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

No npm token specified.

An npm token must be created and set in the NPM_TOKEN environment variable on your CI environment.

Please make sure to create an npm token and to set it in the NPM_TOKEN environment variable on your CI environment. The token must allow to publish to the registry https://registry.npmjs.org/.

Good luck with your project ✨

Your semantic-release bot 📦🚀

Hi,
cutting out the header has to be done for every part.
My setup is Orthanc, which responds to retrieveStudy with a response of the form

--7f6c0897-b97c-48ce-8d35-4b749ba0e9f9
Content-Type: application/dicom
Content-Length: 208474
MIME-Version: 1.0

<dicom data 0>
--7f6c0897-b97c-48ce-8d35-4b749ba0e9f9
Content-Type: application/dicom
Content-Length: 208474
MIME-Version: 1.0

<dicom data 1>
--7f6c0897-b97c-48ce-8d35-4b749ba0e9f9--

I remember from reading the DICOM standard a while ago that this kind of response is not what you would expect. I think multipartDecode expects at the moment

--7f6c0897-b97c-48ce-8d35-4b749ba0e9f9
Content-Type: application/dicom
Content-Length: 208474
MIME-Version: 1.0

<dicom data 0>
--7f6c0897-b97c-48ce-8d35-4b749ba0e9f9
<dicom data 1>
--7f6c0897-b97c-48ce-8d35-4b749ba0e9f9--

Here is a pull request that fixes it for me, need to check if it breaks other dicomweb servers
#18

Anyone know where this comes from?

https://travis-ci.com/dcmjs-org/dicomweb-client/builds/84592898?utm_source=email&utm_medium=notification

Maybe this line?
https://github.com/dcmjs-org/dicomweb-client/blob/master/.travis.yml#L12

Hi all, I ran into this issue over here and realized it was better addressed in this package. I'll create a PR with my fix, thanks!

In OHIF viewer the store measurements is failing when storing to DICOMlcoud server. see this issue for reference.

It has been traced and it was found to be caused by the server not recognizing the "Content-Type" header ( Built-in .NET library) because it is not formatted properly.

For STOW-RS, the Content-Type is being sent as:
Content-Type: multipart/related; type=application/dicom; boundary=2afeebaf-038d-792a-f952-d8e249ba8e96

The correct format should be:
Content-Type: multipart/related; type="application/dicom"; boundary="2afeebaf-038d-792a-f952-d8e249ba8e96"

Notice the "Quotation mark" around the type and boundary parameters: type="application/dicom"

This used to be a bug in the DICOM standard when DICOMweb was initially released but then they corrected it to match the HTTP RFC specs:
I think this is the new reference: http://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_8.7.3.5.1
and
https://tools.ietf.org/html/rfc2387

Related to this issue: dcmjs-org/dcmjs#113

The DICOMweb standard specifies that single part BulkDataURI responses are encoded in application/octet-stream, and not as multipart/related responses. That is specified here:
https://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_8.7.3.3.1

If the bulk data retrieve is done to fetch all bulk data for an instance or group, then I agree it comes back as multipart, but single retrieve is done not encapsulated, at least according to the standard.

Suggestion is to add a retrieveBulkData which knows how to retrieve either in multipart/related or in single part, handling either one transparently.

It would be nice to have an example tool that fetched a patient or study to a local directory - ideally in the DICOMweb format in terms of directory names, with options to control what got fetched. Something like the dcm4che dcmqr command, but using node/local retrieves.

The volume mounts configured via the docker compose file seem to prevent local execution of tests (at least on my Mac OSX via Docker for Mac).

I need a simple JSON representation of the measurement group data from a DICOM SR object.

I am aware of the dcmjs-library, and its functionality of naturalizing a dataset. Now i was wondering if there are any plans on implementing the function of DCMJS.data.DicomMetaDictionary.naturalizeDataset() in this library or would you suggest to just use the dcmjs library for this purpose?

It would be good to get a better JSON representation of the measurement groups and its values then the default response of retrieveInstanceMetadata(). For now i am parsing just this response in a format which fits my need like

{ "measurementGroupName" : { 
        "measurementName" : "value"
    }, 
    { ... }
} 

A question would be, if it is better to use a general dicom parsing method or ajusted to structured report values.

I looked over the code, and the various options and i'm not seeing a clear path to easily abort pending request? Is this possible?

https://server-url.com/v1/studies/{study_uid}/series

while hitting this endpoint, I get a 406 error. I noticed the accept headers
Accept: application/dicom+json, multipart/related; type=application/octet-stream

but if i try to send the request with the following accept header
Accept: application/dicom+json

PS: this endpoint is initiated with
const client = new DICOMwebClient.api.DICOMwebClient({url});
client.searchForSeries.then()

return "".concat(this.baseURL, "?").concat(paramString);

should be:

return "".concat(this.wadoURL, "?").concat(paramString);

Currently, dicomwebClient adds "" around the type in the accept header. However, having "" makes a request a "not simple request" resulting in a preflight request to be sent to the server first. You can see below

With quotation

This is basically twice the amount of request hence twice the travel to the server, making the load time significantly slower (on 600 images around 2 seconds).

Apparently in the original RFC for the standard there is no need for quotation, but in the examples there are quotations. I'm opening this issue to check on the feasibility for removing this quotation (or maybe see if there's a better way to do it.)

The RFC is https://www.ietf.org/rfc/rfc2387.txt and the text that is difinitive for the mime type is:

related-param := [ ";" "start" "=" cid ]
[ ";" "start-info" "="
( cid-list / value ) ]
[ ";" "type" "=" type "/" subtype ]
; order independent

where type and subtype are both tokens. Tokens are not permitted to have quotes around them unless otherwise specified in the syntax.

I'm CC'ing the people who I think might want to participate in this discussion

@hackermd @dclunie @pieper @swederik @chafey @wayfarer3130 @Zaid-Safadi @fedorov

The API is documented using JSDoc, but the API documentation is not accessible online.