* Limit memory usage in ThreadedInstancesLoader (re-use the config from the SequentialReaderWindowCapacity ?)
  Check if we can re-use the SequentialReaders from Orthanc.  Best solution: Orthanc exposes an SDK function to
  load and provide sequential instances so we don't have to re-implement it in this plugin and the RAM remains
  under control.

* Force usage of StudyInstanceUID & SeriesInstanceUID in WADO-URI for single instances:
  https://discourse.orthanc-server.org/t/dicomweb-wado-uri-does-not-work-if-duplicated-instances/5863

* Find a solution for slow and memory greedy computation of metadata for files containing large float arrays.
  https://discourse.orthanc-server.org/t/orthanc-1-12-11-performance-issues-with-deformable-registrations/6448
  File available at https://public-files.orthanc.team/test-files/429_MB_REG_OF.dcm

* https://orthanc.uclouvain.be/book/plugins/dicomweb.html#retrieving-dicom-resources-from-a-wado-rs-server
  Retrieve shall return the list of orthanc IDs -> it is not !

* when retrieving frames from Multi-frame instances, we should not transcode the whole instance for each frame !!!
  For a 90MB instance with 88 frames, OHIF is unusable because of this !
  Sample request:
  curl -H "Accept: multipart/related; type=application/octet-stream" http://localhost:8043/dicom-web/studies/1.2.156.112536.1.2143.25015081191207.14610300430.5/series/1.2.156.112536.1.2143.25015081191207.14610300430.6/instances/1.2.156.112536.1.2143.25015081191207.14610309990.44/frames/3 --output /tmp/out.bin
  check for these logs: DICOMweb RetrieveFrames: Transcoding instance a7aec17a-e296e51f-2abe8ad8-bc95d57b-4de269d0 to transfer syntax 1.2.840.10008.1.2.1

  Note: This has been partially handled in 1.18: Tf no transcoding is needed, we avoid downloading the full instance from Orthanc

  We should very likely implement a cache in the DicomWEB plugin and make sure that, if 3 clients are requesting the same instance at the same time, we only
  request one transcoding.

  No such issue in StoneViewer since Stone downloads the whole file.  However, Stone uses 2-3 workers at the same time and the file is read 2-3 times at the same time
  before it ends up in Orthanc cache -> we should introduce a state "is_being_loaded" in caches and have other consumers wait for it to be available.
  https://discourse.orthanc-server.org/t/possible-memory-leak-with-multiframe-dicom-orthanc-ohif/3988/12


* When OHIF downloads individual frames of a multiframe instance, we perform the same calls to tools/lookup to find the orthanc id of the study
  from its StudyInstanceUID -> implements some caching to avoid this call.  Maybe implement the same hierarchy caching as the one we have in the auth-plugin:

I0429 06:00:33.212574          HTTP-22 ElapsedTimer.cpp:102] (http) GET /dicom-web/studies/1.2.156.112536.1.2142.152204228000250042.15483240020.2/series/1.2.156.112536.1.2142.152204228000250042.15483240020.3/instances/1.2.156.112536.1.2142.152204228000250042.15483243750.11/frames/147
I0429 06:00:33.212712          HTTP-22 authorization:/Plugin.cpp:563] Testing whether user has the required permissions 'all|view' based on the HTTP header 'Authorization' required to match '^/dicom-web/studies/([.0-9]+)/series/([.0-9]+)/instances/([.0-9]+)(|/|/frames/.*|/rendered|/thumbnail|/metadata|/bulk/.*)(|/)$'
I0429 06:00:33.212785          HTTP-22 authorization:/Plugin.cpp:483] Testing whether user has the required permissions 'all|view' based on the HTTP header 'Authorization' required to match '^/dicom-web/studies/([.0-9]+)/series/([.0-9]+)/instances/([.0-9]+)(|/|/frames/.*|/rendered|/thumbnail|/metadata|/bulk/.*)(|/)$' -> not granted
I0429 06:00:33.212853          HTTP-22 authorization:/Plugin.cpp:370] Testing whether access to study "232a1d86-c4472d8b-000318a1-760becb0-2a8a93bd" is allowed with a resource token
I0429 06:00:33.212870          HTTP-22 authorization:/Plugin.cpp:400] Testing whether access to study "232a1d86-c4472d8b-000318a1-760becb0-2a8a93bd" is allowed with a resource token -> granted
I0429 06:00:33.212962          HTTP-22 OrthancPlugins.cpp:2849] (plugins) Delegating HTTP request to plugin for URI: /dicom-web/studies/1.2.156.112536.1.2142.152204228000250042.15483240020.2/series/1.2.156.112536.1.2142.152204228000250042.15483240020.3/instances/1.2.156.112536.1.2142.152204228000250042.15483243750.11/frames/147
I0429 06:00:33.213025          HTTP-22 OrthancPlugins.cpp:4463] (plugins) Plugin making REST POST call to URI /tools/find (after plugins)
I0429 06:00:33.213056          HTTP-22 OrthancPlugins.cpp:2849] (plugins) Delegating HTTP request to plugin for URI: /tools/find
I0429 06:00:33.213102   ****   HTTP-22 OrthancPlugins.cpp:3644] (plugins) Plugin making REST POST call on URI /tools/lookup (built-in API)
I0429 06:00:33.215805          HTTP-22 authorization:/Plugin.cpp:370] Testing whether access to study "232a1d86-c4472d8b-000318a1-760becb0-2a8a93bd" is allowed with a resource token
I0429 06:00:33.215833          HTTP-22 authorization:/Plugin.cpp:400] Testing whether access to study "232a1d86-c4472d8b-000318a1-760becb0-2a8a93bd" is allowed with a resource token -> granted
I0429 06:00:33.215849          HTTP-22 OrthancPlugins.cpp:3644] (plugins) Plugin making REST POST call on URI /tools/find (built-in API)
I0429 06:00:33.221304   ****   HTTP-22 ResourceFinder.cpp:1106] Number of candidate resources after fast DB filtering on main DICOM tags: 1
I0429 06:00:33.221585          HTTP-22 dicom-web:/WadoRsRetrieveFrames.cpp:500] DICOMweb RetrieveFrames on d3133a0e-b17babe4-b67118e0-5ec383cc-b31f561b, frames: 147
I0429 06:00:33.221611          HTTP-22 OrthancPlugins.cpp:3587] (plugins) Plugin making REST GET call on URI /instances/d3133a0e-b17babe4-b67118e0-5ec383cc-b31f561b/frames/146/raw (built-in API)
I0429 06:00:33.222777          HTTP-22 ElapsedTimer.cpp:107] (http) GET /dicom-web/studies/1.2.156.112536.1.2142.152204228000250042.15483240020.2/series/1.2.156.112536.1.2142.152204228000250042.15483240020.3/instances/1.2.156.112536.1.2142.152204228000250042.15483243750.11/frames/147 (elapsed: 10222 us)


* Implement capabilities: https://www.dicomstandard.org/using/dicomweb/capabilities/
  from https://groups.google.com/d/msgid/orthanc-users/c60227f2-c6da-4fd9-9b03-3ce9bf7d1af5n%40googlegroups.com?utm_medium=email&utm_source=footer

* /rendered at study level shall return all instances, not only one (https://groups.google.com/g/orthanc-users/c/uFWanYhV8Fs/m/ezi1iXCXCAAJ)
  Check /rendered at series level too.

* Implement serialization of DicomWeb jobs

* Add support for application/zip in /dicom-web/studies/ (aka sup 211: https://www.dicomstandard.org/docs/librariesprovider2/dicomdocuments/news/ftsup/docs/sups/sup211.pdf?sfvrsn=9fe9edae_2)

* Add support for thumbnails (aka sup 203: https://www.dicomstandard.org/docs/librariesprovider2/dicomdocuments/news/progress/docs/sups/sup203.pdf).
  Right now, thumbnail is equivalent to /rendered except for video thumbnails for which the same default video icon is shown since we are not able to
  extract a thumbnail from a video.

* Support private tags in search fields:
  https://discourse.orthanc-server.org/t/dicomweb-plugin-exception-of-unknown-dicom-tag-for-private-data-element-tags-while-using-query-parameters/3998
  

* Based on this discussion: https://discourse.orthanc-server.org/t/series-metadata-retrieval-is-very-long-even-with-configuration-optimization/3389 
  optimize studies/.../series/.../metadata route when "SeriesMetadata" is set 
  to "MainDicomTags" and "ExtraMainDicomTags" are configured according to recommandation 
  (from this setup: https://bitbucket.org/osimis/orthanc-setup-samples/src/master/docker/stone-viewer/docker-compose.yml).
  
  with a 600 instance series with SQLite - all timings are performed without verbose logs !!!!:
  - time curl http://localhost:8043/dicom-web/studies/1.2.276.0.7230010.3.1.2.1215942821.4756.1664826045.3529/series/1.2.276.0.7230010.3.1.3.1215942821.4756.1664833048.11984/metadata > /dev/null 
    -> 883ms in Full mode
    -> 565ms in MainDicomTags mode     

    -> 545ms in Full mode with 1 worker
    -> 335ms in Full mode with 2 workers
    -> 267ms in Full mode with 3 workers
    -> 270ms in Full mode with 4 workers
    -> 270ms in Full mode with 8 workers


  - note that all measurements have been performed on a DB with a single series !  We should repeat 
    that with a more realistic DB

  with a 3 series study (11 + 1233 + 598 instances)
  time curl http://localhost:8043/dicom-web/studies/1.2.276.0.7230010.3.1.2.1215942821.4756.1664826045.3529/metadata > /dev/null 
    -> 1.355ms in Full mode before using worker threads
    ->   700ms in Full mode with 4 workers