fix: use array of mediatypes and transferSyntax when calling a get xhrRequest for image loading

[Punzo]

Re IDC https://github.com/OHIF/Viewers/issues/2934

Related to https://github.com/OHIF/Viewers/issues/2934#issuecomment-1252758264

This implements the get image in xhrRequuests using an array of mediaTypes and TransferSyntax (analogous to SLIM viewer https://github.com/herrmannlab/dicom-microscopy-viewer/blob/83739f1ba11840df7f4487cdf8015b7450ee419d/src/pyramid.js#L436-L491 ), instead of always requesting as this default:

 const mediaType =
      'multipart/related; type=application/octet-stream; transfer-syntax=*';

Requesting images with type=application/octet-stream; transfer-syntax=* as default can create several issues. For example as in https://github.com/OHIF/Viewers/issues/2934, the 8 bit colored jpeg will be decoded server side (including color corrections), but then the returned mime and transfer syntax is 1.2.840.10008.1.2 instead of 1.2.840.10008.1.2.4.50 (because the array is already decoded by the server), but at this point cornerstoneWADOLoader willl apply again color corrections (which is based on the photometric Interpretation of the image frame).

With this PR, type=application/octet-stream; transfer-syntax=* will have lower priority and used only as last resource. For example, in the case of 8 bit colored jpeg, the images will be donwloaded in jpeg format and always decoded (and color transformations applied) client-side.

[netlify[bot]]

❌ Deploy Preview for cornerstone-wado-image-loader failed.

Name	Link
🔨 Latest commit	213db6ad978de32cadc5cc7a2b9d17482c313fee
🔍 Latest deploy log	https://app.netlify.com/sites/cornerstone-wado-image-loader/deploys/633559a5ae4c0000081cc49f

[Punzo]

@sedghi can you please review this? thanks!

[Punzo]

see my comments, refactoring needed

@sedghi thanks for the review! I have refactored and applied your comments in https://github.com/cornerstonejs/cornerstoneWADOImageLoader/pull/477/commits/55628dd0ed4ef2b8d77cd6cb3394f9ba264ad5e6

[Punzo]

@sedghi applied last comment in https://github.com/cornerstonejs/cornerstoneWADOImageLoader/pull/477/commits/213db6ad978de32cadc5cc7a2b9d17482c313fee

[Punzo]

@GitanjaliChhetri leaving this to you, but it should be ready, and just merge it

[sedghi]

so if I understand this, this will create a giant accept header something like

multiplart/related; type="image/x-dicom-rle"; transfer-syntax=1.2.840.10008.1.2.5, multipart/related; type="image/jpeg"; transfer-syntax....., multipart/related; type="application/octstream"; transfer-syntax="*"

is this true?

I need another set of eyes to review this since this can be a bottleneck in the performance

[sedghi]

This might be related to this as well https://github.com/cornerstonejs/cornerstone3D-beta/pull/232

[NikGurev]

@sedghi maybe this doc will help you: https://dicom.nema.org/medical/dicom/current/output/chtml/part18/sect_8.7.7.html

If I understand correctly, it's OK to have one or more comma-separated mediatypes. And origin server will ignore all mediatypes that are not valid or not supported.

Any Accept header field values, including media type parameters, that are not valid or not supported shall be ignored by the origin server.

[wayfarer3130]

For the retrieve request, rather than generating a long query URL, you can retrieve just the specific request type you want by using the AvailableTransferSyntaxUID to map to a single accept header. If the back end supports it, you can avoid decoding the multipart/related by requesting single part. The single part request implicitly doesn't use the quotes, so it has no CORS issues.