Technical
Among our several repositories, we provide instructions for the technical issues. In those instructions, we define a set of requirements that a product or assembly must meet or exceed. So that it can be used easily by anyone. The following set of instructions will guide us for that purpose. However, any issue encountered should be reported. For that, just open a New issue and describe the problem if it is an overall issue of the project. If it is specific to a certain repository, please open a new issue there, not here.
Our entire source was tested on Unix systems, such as macOS and Linux. The used Linux distributions were both Ubuntu and Debian. However, we are using several tools and libraries as dependencies which are described next.
-
The primary dependency is NodeJS;
-
It is also important to guarantee the presence of
npmin your machine; -
An important library is CornerstoneJS;
-
To host locally, you also need a DICOM server;
First of all, please see this page for general architecture information regarding the cornerstone library. It is also important to follow the specific details regarding the cornerstoneTools dependency, as well as the respective Architecture. Also, the tools are currently being designed and can be found in this page which captures a list of notes on the design goals and issues.
The easiest DICOM server to set up is Orthanc, which can be installed on your local machine. The packages in this repository are designed to use Web Access to DICOM Objects (WADO) Service requests and are therefore capable of connecting to many types of DICOM server. This application has been successfully tested with Orthanc.
| Infrastructure | URL | Ports |
|---|---|---|
| ARDITI | breastscreening.arditi.pt | 8000:8999 |
In this research project, we follow the Filesystem Hierarchy Standard found in this Ask Ubuntu question to guarantee a conventional deployment of our solutions and information. Categorically, we deployed our solutions and information in the /srv directory to specify the location of our solutions, which require single tree data permissions, data files for a particular solution, as well as writable data and scripts. Our method for structuring directories under the srv/ folder is by purpose. For instance, we are deploying our research projects into the projects/ folder. Meaning that for the example of the BreastScreening research work, we created the breastscreening/ folder for the purpose. Inside this breastscreening/ folder, we typically have the dashboard/ folder (i.e., cloned from the dashboard repository), the deployer/ folder (i.e., cloned from the deployer repository), the sources/ folder, and the storage/ folder. The sources/ folder will have the different deployment environments, such as demo/ and test/ folders representing different environment samples in our research work, between others. As a matter of fact, it is in these test/ folders that we will have the UTA prototypes deployed for our user evaluations to test the solutions as a proof-of-concept. On the other hand, the storage/ folder will have the solutions to store our critical data, such as the example of the dicom-server/ folder (i.e., cloned from the dicom-server repository).
As an example of the above folder structure convention, the following information is representative of the directory logic:
.
├── ...
├── srv
│ ├── ...
│ ├── projects
│ │ ├── ...
│ │ ├── breastscreening
│ │ └── ...
│ │ │ ├── ...
│ │ │ ├── dashboard
│ │ │ ├── deployer
│ │ │ ├── env-files
│ │ │ ├── sources
│ │ │ │ ├── ...
│ │ │ │ ├── demo
│ │ │ │ │ ├── ...
│ │ │ │ │ ├── pc
│ │ │ │ │ │ ├── ...
│ │ │ │ │ │ ├── prototype-cornerstone
│ │ │ │ │ │ └── ...
│ │ │ │ │ └── ...
│ │ │ │ ├── test
│ │ │ │ │ ├── ...
│ │ │ │ │ ├── uta11
│ │ │ │ │ ├── uta7
│ │ │ │ │ │ ├── ...
│ │ │ │ │ │ ├── dataset-uta7-ai
│ │ │ │ │ │ ├── prototype-multi-modality-assistant
│ │ │ │ │ │ └── ...
│ │ │ │ │ └── ...
│ │ │ │ └── ...
│ │ │ ├── storage
│ │ │ │ ├── ...
│ │ │ │ ├── dicom-server
│ │ │ │ └── ...
│ │ │ └── ...
│ └── ...
└── ...