dataesr/scientific-paragraphs-categorization huggingface dataset:
Image Enhancement In this section we have performed our proposed method of image enhancement on medical images in order to obtain an appropriate recovered image for medical diagnostic. As mentioned earlier, performing the denoising algorithm on the low-dose medical images may result in some blurring and loss of details. This blurring effect can cause loss of data that may lead to misdiagnosis. To enhance the image quality and overcome the mentioned issue, the denoised images are treated with the algorithm explained in section 4. 5 as a post-processing step. In our experiments, we can use both high dose and lose dose images in fusion step. In case that we have a set of high dose CT images we can use an average of them in the fusion step (method 1) and if we are not supported with these kinds of datasets we can use the noisy image itself and do the fusion step (method 2).
Image Enhancement via Fusion In the proposed method, we solved the problem of fusion based image enhancement of the denoised images. The proposed fusion based enhancement method combines the second level (LL) wavelet coefficients of the Low-dose/High-dose image and the denoised image utilizing the weighted average rule. By fusing the low dose/high dose CT images and the denoised image, we achieved an improvement in the quality and recovered some of the blurred edges and important details for diagnosis in the images. Taking advantage of any available high dose database and taking an average of them result in a better enhancement. This method is straightforward and easy to implement. In both approaches LL subband is used to extract the useful information not included in the denoised image. The LL subband is the best option to choose since noise is usually affecting high frequency information and therefore choosing a low frequency subband can eliminate the noise disturbance in the image.
Acknowledgements I wish to thank, first and foremost, my  Professor Dr. Javad Alirezaie , my MASc. supervisor in  Department of Electrical and Computer Engineering, Ryerson University  for making this research possible. His support, guidance and advice throughout researches and studies are greatly appreciated. Indeed, without his guidance, I would not be able to put the topic together. I would like to express my appreciation to  Dr. Paul Babyn  for his support and comments on my papers and providing me with excellent resources. I am very grateful to my spouse,  Mr. Amir Khoshnood  and my parents for their encouragement and support during my study at the  Ryerson University. v.
Objective: Microaneurysms represent the first sign of diabetic retinopathy, and their detection is fundamental for the prevention of vision impairment. Despite several research attempts to develop an automated system to detect microaneurysms in fundus images, none has shown the level of performance required for clinical practice. We propose a new approach, based on a multi-agent system model, for microaneurysm segmentation. Methods and materials: A multi-agent based approach, preceded by a preprocessing phase to allow construction of the environment in which agents are situated and interact, is presented. The proposed method is applied to two available online datasets and results are compared to other previously described approaches. Results: Microaneurysm segmentation emerges from agent interaction.
With regard to the detection of MAs in color fundus images, Niemeijer et al. [18]  created the Retinopathy Online Challenge (ROC) website. Its aim is to bring together research community efforts toward the creation of algorithms for the detection of MAs, by evaluating their performance on a common dataset and with the same evaluation modality. This permits a fair comparison between algorithms of different groups. To date, 11 research groups have displayed their results on the website. The methodologies they used, which have been published, are all described above, and the results are shown in Table  1.
Retinal images and system performance evaluation A set of images by Quellec et al. , available online  [7]  and called LaTIM (Laboratoire de Traitement de l'Information Médicale) dataset in this study, was used for the performance evaluation. This dataset consisted of 36 images with 2240 × 1488 pixels and was stored in tiff file format. Moreover, the dataset also contained a text file for each image, with small, red lesions manually annotated by a single DR expert. Another publicly available database used in this study was provided in the ROC competition  [18]. This database was composed of 100 images, equally divided into a training set and a test set. The images were acquired by three different cameras and were of  different resolutions and sizes, ranging from 768 × 576 to 1389 × 1383. All images were stored in JPEG format, and compression was set in the camera.
For both datasets, the proposed approach performance was evaluated in terms of the free-response receiver-operating characteristic (FROC) curve, where per lesion sensitivity values were plotted against the average number of false positives (FP) per image. Sensitivity represents the proportion of MAs correctly detected by the algorithm, while FP is the number of non-MAs identified as MAs. For the ROC dataset, and to facilitate the comparison with the other methods already submitted on the challenge website, the FROC curve was summarized in several quantitative points, by which method the sensitivity values for the false positive per image rates values of (1/8), (1/4), (1/2), 1, 2, 4, and 8 were achieved and averaged to obtain a final score. Moreover, only the results obtained with the test set and provided by the ROC organizers were analyzed, as described in the next section.
Results To facilitate the algorithm parameterization, the sizes of all images from both datasets were normalized without losing the relevant study information. The LaTIM images were resized to 1120 × 744 pixels and the ROC images to 836 × 835 pixels. The algorithm parameters were chosen according to the image size and the typical dimension of MAs in fundus images, thereby T c = 40, D = 2 and A max = 40 were the values used when applying the proposed approach to both datasets. The MAS model performance depended on the preprocessing step and how the agents interpreted the information provided from this first phase. As such, it is important to compare the   gradient image resulting from the preprocessing step with the binary image resulting from the MAS model. Fig. 10  illustrates an original color image with manually segmented MAs and the respective image resulting from the preprocessing phase, and the binary image provided by the MAS model before the local feature analysis.
Fig. 11  demonstrates the binary images that resulted from the MAS model before and after the feature analysis step, made by the RAs. The segmentation performance obtained with the MAS model in the LaTIM dataset was compared with another approach, which is schematically illustrated in Fig. 12  (bold), and consists of the preprocessing and segmentation phases of the "standard" approach referred in Section 2. That is, only the detection method of the candidate was considered because the proposed approach is unsupervised and, in that way, a fair comparison is made. The comparative results are illustrated in Fig. 13  where the curve for the "standard" approach was obtained by varying the threshold value (t ∈ {3 : 1 : 12}). Fig. 14  shows the results related to the detection of MAs close to blood vessels using the two approaches.
Acknowledgments Work supported by  FEDER funds through the "Programa Operacional Factores de Competitividade -COMPETE " and by national funds by FCT -Fundac ão para a Ciência e a Tecnologia. C. Pereira  thanks the  FCT  for the  SFRH/BD/61829/2009  grant. The authors also would like to thank to the reviewers for their valuable comments for this article improvement.
Background: Research in modern biomedicine and social science requires sample sizes so large that they can often only be achieved through a pooled co-analysis of data from several studies. But the pooling of information from individuals in a central database that may be queried by researchers raises important ethico-legal questions and can be controversial. In the UK this has been highlighted by recent debate and controversy relating to the UK's proposed 'care. data' initiative, and these issues reflect important societal and professional concerns about privacy, confidentiality and intellectual property. DataSHIELD provides a novel technological solution that can circumvent some of the most basic challenges in facilitating the access of researchers and other healthcare professionals to individual-level data.
Methods: Commands are sent from a central analysis computer (AC) to several data computers (DCs) storing the data to be co-analysed. The data sets are analysed simultaneously but in parallel. The separate parallelized analyses are linked by non-disclosive summary statistics and commands transmitted back and forth between the DCs and the AC. This paper describes the technical implementation of DataSHIELD using a modified R statistical environment linked to an Opal database deployed behind the computer firewall of each DC. Analysis is controlled through a standard R environment at the AC. Results: Based on this Opal/R implementation, DataSHIELD is currently used by the Healthy Obese Project and the Environmental Core Project (BioSHaRE-EU) for the federated analysis of 10 data sets across eight European countries, and this illustrates the opportunities and challenges presented by the DataSHIELD approach.
Introduction The analysis of complex interrelated datasets containing demographic, social, health-related and/or biological information derived from large numbers of individuals has become pivotal to the investigation of disease causation and to the evaluation of healthcare programmes and interventions. However, the daunting sample sizes needed to provide adequate statistical power  [1] [2] [3]  often exceed the provision of any one single study. Furthermore, if major research funders are to optimize return on their investment of public or charitable money, it is crucial that researchers other than those who originally created a particular data set are able to access and work with those data. 4 These two imperatives underpin the active encouragement of 'data sharing'across several studies, or from a single data source-which is central to contemporary bioscience.
5 The data to be shared may be derived from large epidemiological studies, from smaller research projects and/or from healthcare or administrative records. They may originally have been intended for research or for direct support of patient care or public health. There is no doubt that liberating and integrating such information to support medical research has the potential to generate enormous future health benefits. But substantive challenges exist, and the sharing of data-particularly individual-level data, also known as microdata  6  -raises important societal and professional concerns. In the UK, these concerns were recently highlighted by controversy surrounding the care. data project. 7, 8 At a societal level they include real and perceived frailties of information governance when a research database containing potentially sensitive personal information about individuals is made accessible to any third party including researchers.
12 Crucially, because it does not require underpinning by a major informatics infrastructure and because it is based on non-commercial open source software, it is both locally implementable and very cost effective. Co-analysis of data from several studies/sources is often conducted using study-level meta-analysis (SLMA),  [13] [14] [15]  using conventional meta-analysis to combine results generated by each study separately. 16, 17 In contrast, individuallevel meta-analysis (ILMA)involves the physical transfer of data from each study to produce a single central database that is then analysed as if it were a conventional multicentre data set. 16, 17 Unfortunately, both SLMA and ILMA present significant problems. 12, 16, 17 Because SLMA combines analytical results (e. g. means, odds ratios, regression coefficients) produced ahead of time by the contributing studies, it can be very inflexible: only the pre-planned analyses undertaken by all the studies can be converted into joint results across all studies combined.
21, 24 Individual-level data never cross, and are never visible outside, the firewall of their home study. 12, 20, 24 Jones et al. 22  explain why fitting a generalized linear model (GLM) under DataSHIELD produces exactly the same results-not just a good approximationas a GLM fitted to a single database containing the individual-level data from all studies combined. This is confirmed empirically in the current article by the comparison of the output of a GLM model fitted initially via DataSHIELD on all studies separately, and then through R on the pooled data (i. e. the separate data sets stacked together into one table). Second, however, DataSHIELD can also be configured to mimic a secure SLMA but without the need to ask individual studies to undertake their own analyses. Under DataSHIELD, any non-disclosive analysis may therefore be requested at any time without physically sharing data.
DataSHIELD can also protect intellectual property when data producers are keen for external researchers to query and work with their data but do not wish to lose ultimate control by physically transferring their data. This can even apply to a single study-single-site DataSHIELD-which may be viewed as being a particularly simple and cost-effective way to construct a 'secure data enclave' within which data can be comprehensively analysed but not accessed. For all of these reasons, DataSHIELD encourages 'true', equal-status collaboration. Figure  1  illustrates the basic IT infrastructure for a hypothetical DataSHIELD implementation for co-analysing six studies. The individual-level data themselves remain on 'data computers' (DCs) at their home bases. A central 'analysis computer' (AC) is used to issue commands to enact and control the analysis.
As a by-product of its underlying structure, DataSHIELD can enhance governance and data management because data are locally maintained by their producers who typically know them best; that is, it encourages storage, updating and sharing of complex multi-class data from ongoing studies through a federated rather than a centralized architecture. However, this does not deny the important complementary role of large centralized repositories specializing in archiving particular classes of data, such as the European Genome-Phenome Archive  25  or the UK Data Service. 10 As an additional consequence of its structure, DataSHIELD can also avoid the need to move very large data sets. Finally, because all data remain unobserved at their home repository, DataSHIELD can mitigate some of the dilemmas arising from findings of actionable clinical significance in individuals.
26 Specifically, external researchers cannot, in principle, produce results pertaining to individual participants. Rather, individual clinical results can only be generated by investigators working with data from their own study and these investigators should be covered by formal internal policies. DataSHIELD offers both opportunities and challenges. It has been known for several years that it works in principle,  12, 22  but its practical implementation and utilization on an IT platform that can be used by non-expert researchers has proved to be challenging. This paper describes the application platform that has now been developed. It explains each of the fundamental steps in a typical DataSHIELD analysis and outlines the key elements of the infrastructure that underpins these steps. Illustration is based on a real-world setting in which DataSHIELD is currently being used to analyse data for a pan-European consortium: the Healthy Obese Project (HOP).
The IT infrastructure The IT infrastructure required to carry out a DataSHIELD analysis comprises three main components: a computer server at each source study hosting an Opal database; 28 the statistical programming environment(R 29 ); and DataSHIELD-specific R libraries installed on the data servers (data computers ¼ DCs) and on the client computer (analysis computer ¼ AC). Opal is a core database application for biobanks and epidemiological studies developed by the Maelstrom Research group  30  in collaboration with OBiBa, an international software development project creating open-source software for Biobanks. 31 Opal, R and DataSHIELD are open source and freely available. Instances of Opal, the R server and the DataSHIELD server-side R libraries are implemented behind the firewall of each data owner's DC (Figure  2 ).
DataSHIELD process explained DataSHIELD as described in this article is intended for the pooled analysis of 'horizontally partitioned' data, i. e. contributing sources hold the same variables but on different individuals (see Figure  3b ). A new version of DataSHIELD is currently being developed for 'vertically partitioned' data where various sources hold different variables on the same individuals (see Figure  3c ). This uses an overlapping range of secure approaches to secure data integration and retains the same fundamental principle: leave the data where they are but analyse them as if they were combined in one database. As for any co-analysis, shared data must be harmonized first. The harmonization phase of the HOP project  32  within BioSHaRE-EU  33  (described in detail elsewhere  27, 34, 35  ) is functionally independent of DataSHIELD itself (Table  1 , step 0).
DataSHIELD functions The fundamental building blocks of DataSHIELD are its client-side and server-side functions. As illustrated in Figure  2 , server-side functions reside in the modified R environments located behind the firewall of the DC at each individual study. It is the server-side functions that actually process the individual-level data at the distinct repositories. The outputs from server-side functions (non-disclosive study-level statistics) represent the only information that ever leaves a DC, and this is why we can claim that DataSHIELD allows full analysis of individual-level data without those data ever having to be moved, or even rendered visible, outside their study of origin. Client-side functions reside on the conventional R environment on the AC. Client-side functions call and control server-side functions and combine information across different repositories when required.
Examples of DataSHIELD commands Although the examples in this section are real as they use real data from the HOP project, they are included here for illustrative purposes only. For the sake of conciseness-and to maintain consistency across all examples-we include only four of the available studies in these examples. Throughout this section the DataSHIELD commands, in bold and italic font, are preceded by explanations and followed, where there is any, by the output of the command, in italic font.
Histogram plots Figure  6  illustrates the output from a DataSHIELD histogram plot of HDL cholesterol for each of the four studies (Figure  6A ) and for the pooled data (Figure  6B ). The DataSHIELD function ds. histogram filters the information returned from each study to remove bars based on a count of between 1 and 4. This means that potentially disclosive outliers are not shown on the plot. It however reports the number of invalid cells in the original grid density matrix used to produce the graph. For all DataSHIELD commands, the 'type' argument indicates whether to report results for each study separately (type5'split') or across all studies, the default behaviour.
Here, the categorical BMI variable is tabulated against gender. The function ds. table2D also produces column percentages, row percentages, global percentages and validity information. It also runs chi-square tests for homogeneity on (nc-1)*(nr-1) degrees of freedom for each study and for all studies combined, where nc is the number of columns and nr the number of rows. Generalized linear models (GLMs) Because we wanted to directly compare the results of a GLM analysis under DataSHIELD with the corresponding results obtained from a conventional R-based GLM analysis-i. e. with the raw data from all sources physically combined in one database (Table  3 )-our GLM example is based on four of the HOP studies that explicitly allowed their data to be physically shared within the HOP consortium, as well as to be analysed via DataSHIELD: NCDS,  38  KORA,  39  LifeLines 40 and Mitchelstown.
e. after the model has converged) are included in the output below. In order to enhance its illustrative value, the particular model we have fitted contains study-specific terms allowing for heterogeneity in the baseline risk of disease and have used the * operator to specify an interaction between GENDER and a three-level factor encoding BMI. In addition, we compare the estimates and confidence intervals from the GLM fitted using DataSHIELD with their equivalents from the same GLM fitted directly to a combined database into which the individual-level data from each study have been physically pooled. This provides empirical con-firmation of the precise theoretical equivalence of the two approaches. 22 It should be noted that when variables are initially transferred from Opal into the DataSHIELD R environment at each source, they are by default placed in a data frame denoted 'D'.
Application in other this paper we have illustrated the use of DataSHIELD in a involving research-focused analysis of data that were originally collected for research purposes. But it could potentially be of equal value in settings involving co-analysis of data from multiple health service or other administrative databases, or the joint analysis of research data with administrative data. It is for these purposes that major infrastructural projects  7, 8  like care. data  7, 8  and secure data-sharing infrastructures  10, 11  have been proposed and developed. For example, the aim of care. data was to amalgamate medical information on individuals from various administrative sources, including general practice (GP) records, into a single research database held by the Health and Social Care Information Centre and made available to approved researchers.
The second challenge is to securely combine information relating to individuals from a primary source (e. g. from a particular research project, or from GP medical records) with other health or administrative records on the same individuals, using record linkage and co-analysis. This is essential if some of the required data are not directly available from the primary source (e. g. hospitalization data, or education data). In such a setting, a vertical of DataSHIELD can play a useful (Figure  7b ), although it is out of the scope of this paper to discuss vertical DataSHIELD in detail. In principle, DataSHIELD could provide a means to reassure the public that their data were being used in a secure manner. However, important challenges remain: (i) ongoing technical refinement of the functionality of the vertical implementation of DataSHIELD; (ii) extensive discussion with data-providing agencies-including governmentand relevant governance committees to ensure that they are all comfortable with application of DataSHIELD to potentially sensitive administrative data; and (iii) consideration of whether, in any particular setting, the agencies involved will be willing and able to devote the time and resources required to prepare and document data ready for vertical DataSHIELD use.