[SVCS-86] Add Papaya Renderer for Dicom and NifTi Files

[TomBaxter]

Purpose:

Create renderer for NifTI images. (.nii)

Collateral

Supports .nii.gz (NifTi files are commonly saved with .gz) Supports .dcm (DICOM images)

Changes:

Create papaya renderer in /mfr/extensions/papaya Relies on https://github.com/rii-mango/Papaya Copies file to render to /mfr/extensions/papaya/static/data to make available to papaya.js NiFTI files are often saved as .nii.gz by convention. I've added a facility to handle file extensions with an additional extension, such as compression. At the beginning of each render files older then 5 minutes will be deleted. Added a test.

Side effects

Some rendered file data will temporarily exist in mfr/extensions/papaya/static/data

Notes

I created PR for our use case... https://github.com/rii-mango/Papaya/pull/101 Which was accepted as of Papaya release build-1430 Use papaya.js and papaya.css from /Papaya-build-1430/release/current/standard/

We should keep an eye on this project... https://github.com/FNNDSC/ami We may want to switch to it in the future.

Tickets

https://openscience.atlassian.net/browse/SVCS-86

[TomBaxter]

@cslzchen

1. OK
2. I don't think so. The Dicom files are the files that are in demand.
3. The temporary files are removed at the beginning of each run of the renderer.

[coveralls]

Coverage increased (+0.6%) to 64.458% when pulling e723f4c8b24143e4894ef7bb3405e353db555883 on TomBaxter:feature/svcs-86 into ee122ffb5ef0eae6ed9d4cb3fcc2bd022ca0eaf9 on CenterForOpenScience:develop.

[cslzchen]

There is an "entrypoints" test that needs to be updated if you add new file types. Don't worry about it and I will have it along with my PR.

[coveralls]

Coverage increased (+0.5%) to 68.47% when pulling 6937fee54171f5726fb145e313012fa7ad6389e5 on TomBaxter:feature/svcs-86 into 8bb2dd4d35f8c1d89a72fc8b9e09db317f3497f3 on CenterForOpenScience:develop.

[coveralls]

Coverage increased (+0.7%) to 68.726% when pulling c834abfcf546889e42e77881652272bf3d701ea5 on TomBaxter:feature/svcs-86 into 8bb2dd4d35f8c1d89a72fc8b9e09db317f3497f3 on CenterForOpenScience:develop.

[TomBaxter]

Keep in mind that the files MFR downloads get named with a UUID, so overlap is extremely unlikely.

[TomBaxter]

After discussing with @cslzchen , I understand his concern is that if two renderers try to delete a file that one will error since the other would have already deleted the file. An idea for handling this could be to simply handle the OSError exception with a try/except/pass .