[version 2; peer review: 2 not approved]
No competing interests were disclosed.
The radiology community has adopted several widely used standards for medical image files, including the popular DICOM (Digital Imaging and Communication in Medicine) and NIfTI (Neuroimaging Informatics Technology Initiative) standards. These file formats include image intensities as well as potentially extensive metadata. The NIfTI standard specifies a particular set of header fields describing the image and minimal information about the scan. DICOM headers can include any of >4,000 available metadata attributes spanning a variety of topics. NIfTI files contain all slices for an image series, while DICOM files capture single slices and image series are typically organized into a directory. Each DICOM file contains metadata for the image series as well as the individual image slice.
The programming environment R is popular for data analysis due to its free and open code, active ecosystem of tools and users, and excellent system of contributed packages. Currently, many published radiological image analyses are performed with proprietary software or custom unpublished scripts. However, R is increasing in popularity in this area due to several packages for processing and analysis of image files. While these R packages handle image import and processing, no existing package makes image metadata conveniently accessible. Extracting image metadata, combining across slices, and converting to useful formats can be prohibitively cumbersome, especially for DICOM files.
We present radtools, an R package for convenient extraction of medical image metadata. Radtools provides simple functions to explore and return metadata in familiar R data structures. For convenience, radtools also includes wrappers of existing tools for extraction of pixel data and viewing of image slices. The package is freely available under the MIT license at
We thank both referees for their thoughtful comments. Overall, both reports identified a lack of clarity around the specific value proposition of radtools, and highlighted the need for further explanation of its relationship to existing tools such as oro.dicom and oro.nifti. We have made several changes to the manuscript and package in light of their suggestions. Response to specific comments of Dr. Volker Schmid:
We have more clearly explained the specific need satisfied by this package that is not provided by existing tools: namely, convenient extraction and exploration of image metadata. We have pointed to the package vignette for examples of usage with publically available data. In the “Implementation” section, we have explained the relationship to the existing packages oro.dicom and oro.nifti, and clarified the point that radtools does not reimplement the DICOM and NIfTI formats, but rather defers to oro.dicom and oro.nifti for these implementations. We have provided more details about how the package was tested with available image datasets. We have made a change to the package regarding support for DICOM objects that do not include pixel data such as SR objects. As these objects still contain useful metadata, we have added support for them, and included an SR object in our unit tests. A new release of the package reflecting this change has been published on CRAN and GitHub. We have also added a sentence to the manuscript mentioning this type of valid DICOM object. We have modified the title to be more specific and removed the subjective word “smooth” from the manuscript; the language has been similarly modified in the package description and documentation on CRAN.
Response to specific comments of Dr. Andrey Fedorov:
Medical image analysis often lies at the boundary of research and the clinic, presenting challenges in both domains. Institutional and privacy concerns can compete with the objective of open data for research purposes. In particular, it remains standard practice to perform analysis with proprietary software or unpublished scripts. Additionally, the majority of imaging studies do not make image data publically available due to patient privacy requirements. These complex challenges can present barriers for scientists working in the image analysis domain.
In recent years, a small but growing number of open source computational tools have been developed to process and analyze medical images, promoting sharing of code; some of the most widely adopted are described in
Radtools
Radtools
Radtools implements novel functionality for extraction and processing of image metadata. For implementations of the DICOM and NIfTI-1 standards themselves, radtools uses the existing state-of-the-art R packages oro.dicom and oro.nifti
The correctness of our metadata implementations was tested with a diverse collection of 167 DICOM datasets and 23 NIfTI-1 datasets available publically; the tests and original source of test objects can be examined in the “tests” directory of the package source.
The only system requirement is a working installation of R version ≥3.4.0. The radtools workflow consists of calling radtools functions from the R console or within R scripts.
Radtools
The image itself can be extracted as a multidimensional matrix of intensities for either file format with `img_data_to_mat`. Image slices can be visualized with `view_slice`.
Finally, functions are provided to explore aspects of the DICOM standard itself. The functions `dicom_all_valid_header_tags`, `dicom_all_valid_header_names`, and `dicom_all_valid_header_keywords` return complete lists of valid DICOM header attributes. The functions `dicom_search_header_names` and `dicom_search_header_keywords` return attributes matching a search term.
For a demonstration of package usage including examples with publically available data, see the package vignette available at
Radtools
No data are associated with this article.
Radtools can be installed with the R command “install.packages(“radtools”).
Unfortunately the authors have revised their manuscript only slightly. I still see a general interest in the aim and the idea of the provided package. However, the value of the package is not explained in the manuscript, and that may be because the ability of the package is (still) limited. The manuscript needs example code, Figures, Tables etc. to show the value of the package.
The manuscript needs to answer the following question: Why is it convenient to use your package compared to writing code specifically tailored for my data set?
Are the conclusions about the tool and its performance adequately supported by the findings presented in the article?
No
Is the rationale for developing the new software tool clearly explained?
No
Is the description of the software tool technically sound?
Partly
Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others?
Yes
Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool?
No
Reviewer Expertise:
statistical analysis of medical images
I confirm that I have read this submission and believe that I have an appropriate level of expertise to state that I do not consider it to be of an acceptable scientific standard, for reasons outlined above.
Unfortunately, the manuscript is still lacking details about the added value it provides as compared to oro.* packages. The clarification that it provides "convenient extraction and exploration of image metadata", which, according to authors, "is not provided by existing tools", is not helpful. I do not understand what that statement actually means. Please include specific details how the functionality provided by Radtools is different from oro.*, and justify why that new functionality is important.
The authors refer to the "tests" directory in the package source, but the datasets referenced are from a local Dropbox folder. Considering TCIA provides API for retrieving images, it would make more sense to include code that retrieves all of the tests. Also, it is not clear why the specific datasets were selected, how they are different, and what aspects of the implementation they are testing.
About the updated title: "smooth" is equivalent to "convenient". Both are subjective qualifiers. I understand it was the authors intent to make extraction and navigation "more smooth" than available alternatives in their judgement, but whether this was successful or not will be up to the users of the package. I would drop the subjective qualifier, unless the manuscript includes specific objective criteria that would demonstrate it is "more smooth" or "more convenient" than the alternatives. Not sure how that would be demonstrated though - perhaps blinded user surveys?
Are the conclusions about the tool and its performance adequately supported by the findings presented in the article?
No
Is the rationale for developing the new software tool clearly explained?
No
Is the description of the software tool technically sound?
No
Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others?
Yes
Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool?
Yes
Reviewer Expertise:
medical image computing, imaging informatics, applications of DICOM for implementing FAIR principles in medical image computing
I confirm that I have read this submission and believe that I have an appropriate level of expertise to state that I do not consider it to be of an acceptable scientific standard, for reasons outlined above.
This manuscript describes the R package radtools. The aim of the R package is "smooth navigation of medical image data".
The idea to provide functions which appear "smooth" for the end user is of great importance. However, the functions provides in the package do not seem to be of much (additional) benefit to the end user. Functions for reading NIfTI and DICOM images are wrappers around function in the packages oro.nifti and oro.dicom; visualisations of medical images are realised in oro.nifti. Only the functions for exploring DICOM headers are genuinely original. This is of course an important part of working with (DICOM) images.
From my understanding, F1000Research requires software tools articles to contain examples of the use of the tools. This manuscript does not contain any examples. An example (or two examples) would not only strengthen the manuscript, but could/would also show the benefit of the R package itself.
Are the conclusions about the tool and its performance adequately supported by the findings presented in the article?
No
Is the rationale for developing the new software tool clearly explained?
No
Is the description of the software tool technically sound?
Partly
Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others?
Yes
Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool?
No
Reviewer Expertise:
statistical analysis of medical images
I confirm that I have read this submission and believe that I have an appropriate level of expertise to state that I do not consider it to be of an acceptable scientific standard, for reasons outlined above.
The authors present a new R package developed to support the use of DICOM and NIfTI files from the R environment. The authors rightfully discuss the popularity of R and the need to support image processing tasks in this environment. The argument for development of the proposed package, radtools, is that "[...] no existing package makes image metadata conveniently accessible. Extracting image metadata, combining across slices, and converting to useful formats can be prohibitively cumbersome, especially for DICOM". The resulting package is available from CRAN, and this reviewer confirmed its installation and basic functions.
The major issues that need to be addressed to make the article sound are the following:
Justification of the development of a new package for working with DICOM, or with NIfTI, is not sufficient. No details are provided about how the functionality was tested, and about the capabilities and limitations of the package in terms of supporting specific DICOM objects. Related to 2), no details are provided about how the DICOM files are handled "under the hood", i.e., whether all IO functionality was implemented from scratch, or the package is using some other DICOM libraries.
Through the text, the authors reference other R packages for similar tasks, and most notably oro.dicom and oro.nifti
DICOM is a complex standard, with a lot of ways information can be stored. For example, there are different methods to encode the content (transfer syntax), different character sets that can be used, private attributes. Therefore, often the quality of a DICOM implementation is defined to a large degree by the data that was used to test the implementation. The quality is also usually improved over time with the usage of the implementation. The proposed package is not accompanied by any details about what types of DICOM objects are supported, what was tested and how. Given it is a new package with a short development and usage history, one has to make a very strong argument for introducing such new tools in presence of existing alternatives.
Other suggestions:
The discussion of the DICOM objects is an oversimplification, which is reflected in the implementation of the functionality. The standard defines various types of objects that can be serialized as files, but those objects are not limited to images. As an example, DICOM defines Structured Reporting object, which will not have PixelData. The proposed package fails to read such object. The authors can find sample SR objects in the familiar to them TCIA (e.g., see QIN-HEADNECK collection). "smooth" is a subjective qualifier that is redundant in the title and the text.
I will be happy to reconsider this article after the authors address the above concerns. But my current opinion is that oro.dicom and oro.nifti set a rather high bar for any new implementation of similar functionality.
Are the conclusions about the tool and its performance adequately supported by the findings presented in the article?
No
Is the rationale for developing the new software tool clearly explained?
No
Is the description of the software tool technically sound?
No
Are sufficient details of the code, methods and analysis (if applicable) provided to allow replication of the software development and its use by others?
Yes
Is sufficient information provided to allow interpretation of the expected output datasets and any results generated using the tool?
Yes
Reviewer Expertise:
medical image computing, imaging informatics, applications of DICOM for implementing FAIR principles in medical image computing
I confirm that I have read this submission and believe that I have an appropriate level of expertise to state that I do not consider it to be of an acceptable scientific standard, for reasons outlined above.