dataesr/scientific-paragraphs-categorization huggingface dataset:
0 chip. To simulate an individual genome, we first assigned randomly to each pedigree founder a haplotype origin (CEU or YRI). For example, a 1C offspring will have randomly between 0 and 8 pedigree founders with a CEU origin. Then, according to this haplotype origin, HapMap reference haplotypes were randomly drawn without replacement for each chromosome and were assigned to pedigree founders to construct the genotype data of the individual. Pedigree founders were used to detect the true HBD segments of an individual, and the haplotypes of CEU and YRI origin. The true inbreeding coefficient of an individual (f true ) was calculated by dividing the genome length in cM that is HBD by the total genome length. The genome length was obtained by adding the genetic distance between the first and the last marker on each autosome.
To compare the benefit of using multi-point methods, such as the one implemented in FSuite, to single-point ones, we first estimated f in each replicate through the single-point method implemented in PLINK version 1. 90b2b. Then, to take into account the admixture of the individuals, we also ran single-point method implemented in REAP version 1. 2 on each simulated sample. Ancestry proportion of each individual and allele frequencies of each of the ancestral populations were estimated by running software Admixture version 1. 23 on each sample; LD within each sample was removed as advised in the Admixture documentation (PLINK pruning option-indep-pairwise 50 10 0. 1), and the number of ancestral populations was set to K = 2. All PLINK and REAP negative estimates were set to 0. The performances of the different estimators were compared on the 5 different types of offspring (1-4C and OUT) by randomly drawing one individual of each type from each replicate with f true > 0.
)  and the scientific community is increasingly exploiting tools for image analysis in highperformance computing (HPC) environments  (Lee et al. 2011; Plaza et al. 2011a; Plaza et al. 2011b ). Nevertheless, the development of scientific prototypes exploiting parallel and distributed computing paradigms remains challenging for domain experts typically working with high-level programming languages such as Python, R and Matlab. In this contribution we report on our experience and current efforts in the development of a processing chain for the monitoring of surface deformation from time-series of VHR satellite images (i. e. Pléiades). Sub-pixel image correlation of optical satellite images has been demonstrated to be a valuable tool for measuring surface deformation such as co-seismic slip  (Leprince et al.
METHODS AND DATA The processed dataset comprises multiple time steps of VHR satellite images acquired over a landslide prone area in the Southern French Alps including 4 stereo-pairs and 1 monoscopic images. For the generation of surface models and the orthorectification of all images commercial software (Imagine Photogrammetry) was used in a cloud-based environment (SaaS) following the approach described in  (Stumpf et al. 2014b ). The resulting 10 panchromatic orthoimages comprise approximately 14 GB. While this is not a large volume per se it already poses challenges for analytics required for precise deformation measurements. To quantify the local pixel shift among the orthoimages a hierarchical sub-pixel image correlation technique implemented in the open source MicMac library  (Deseilligny et al.
R is originally not designed for image processing tasks but contributing packages  (Hijmans 2015)  now provide a broad range of functionalities and data structures for handling gridded data. In particular, it provides features for processing large geospatial raster datasets stored on disk and circumvents the need of loading the entire dataset into memory. In addition our implementation makes use of several libraries for multi-core processing  (Greenberg 2014; Weston 2014a, b)  to enable the parallel execution of conversion, stacking and the fPCA analysis. While this already provides a significant speed up the implementation does not yet support distributed processing.
3f. It can be seen that the AUC is highest if only is taken into account which significantly enhances specificity and sensitivity compared to a thresholding only on the mean. The ROC analysis can be further exploited to determine an optimal threshold maximizing the sum of specificity and sensitivity (Fig. 3f ). The determined threshold was applied to derrive the final result presented in Fig. 3d  showing very close correspondance with the ground truth provided by the expert (Fig. 3e ) illustrating the effectivness of the presented method. Fig. 4  presents the results obtained for the entire dataset. While three known major landslides in the valley (La Valette, Super Sauze and Poche) are clearly detected, the analysis also reveals the activity of several further smaller failures (Fig. 4 b, c ) which previously have been previously undetected.
The runtime for the matching of each pair scales aproximately linearly (O(n)) with the number of overlapping pixels (n) in the two orthoimages. Since the number of available nodes exceeded the number of matching pairs, all pairs could be processed in parallel and the linear scaling could be preserved resulting in a runtime of less than <12h with the currently available HPC infrastructure. Further speed ups would require a profound reimplementation of the already highly optimized C++ code base which we currently deem not justified. The conversion, stacking and fPCA analysis in R also scales linearly (O(n)) with n but the basic cost per operation is currently a severe bottleneck which for the presented dataset, required more than 5 days on a highend workstation with 16 cores. While the necessary algebraic operations and the PCA analyis already rely on efficient implementations using compiled C code, most of the runtime is spend for read access of the focal values in the stack.
Thanks to this evaluation method, more than 500,000 configurations have been automatically tested, which would be almost impossible to evaluate with classical protocols. The results show that the kinematic information obtained by the Kinect software is generally accurate enough to fill in ergonomic assessment grids. However inaccuracy strongly increases for some specific poses and sensor positions. Using this OPEN ACCESS evaluation method enabled us to report configurations that could lead to these high inaccuracies. As a supplementary material, we provide a software tool to help designers to evaluate the expected accuracy of this sensor for a set of upper-limb configurations. Results obtained with the virtual mannequin are in accordance with those obtained from a real subject for a limited set of poses and sensor placements.
This device (based on PrimeSense Technology, Tel Aviv, Israel)  [12] [13] [14]  is composed of an infrared projector of structured light and an infrared camera that returns a depth image of the scene at 30 Hz. The associated software enables us to identify pixels that belong to the body parts by the use of a randomized decision forest algorithm. This body part classification finally leads to the estimation of twenty 3D joint positions of the main joints in the human body  [15]. Several authors have studied the accuracy of the kinematic data provided by the Kinect in various application domains  [16] [17] [18] [19]. The hardware accuracy has been investigated through the study of the depth map  [20] [21] [22]. The results show that the hardware component of the Kinect is accurate enough to capture 3D objects in a workplace environment  [20].
They proposed to deform the anthropometric 3D mesh to mimic the desired poses and simulate the resulting depth image of the scene, as a Kinect would do under the same conditions. Using a simulated depth map representing a 3D mesh instead of real humans before running the Shotton's algorithm enables us to test a large set of configurations and repetitions, as Shotton did in  [15]. It also enables us to test the kinematic data reconstruction algorithm independently from the hardware device. The quality of the depth images measured with a Kinect has been extensively evaluated in previous works  [20] [21] [22]  and the new version of the Kinect offers better quality. However the accuracy of the kinematic reconstruction software is less clear whatever the quality of the sensor is, especially for complex 3D poses in constrained environments, such as the workplaces.
Using rendered virtual mannequins as an input of this kinematic reconstruction software will enable us to clarify the reliability of this estimation in realistic conditions, independently from the sensor's accuracy. In this work, we consequently propose to evaluate the accuracy of kinematic data computed by the Kinect software according to simulated depth images associated with a wide set of poses and sensor positions. The results of this work aims at providing the reader with details about the accuracy of the Kinect to help experimenters use this sensor in an optimal way under workplace conditions. Section 2 provides details about the material and methods used to achieve this goal. Section 3 reports the results, i. e. , the accuracy of the reconstructed poses using a Kinect thanks to virtual mannequins.
Using a virtual mannequin instead of real subjects could introduce biases in the results, especially if the skinning of the character is not totally in accordance with a real human silhouette. Thus, to ensure that results obtained with the virtual mannequin could be used to estimate errors in real humans, we carried out an experiment with a real subject. The pose of the virtual mannequin is set to match its joint centers positions to those of the real subject to compare (1) the joint angles measured with the virtual mannequin and the simulated Kinect; (2) the actual joint angles of the skeleton; and (3) the joint angles provided by the actual Kinect sensor and software.
Method Overview The pipeline of the method can be divided in three parts, as shown in Figure  1. In the first part, an anthropometric 3D mesh representing the surface of the human body is generated using MakeHuman software  [31] , as suggested in  [30]. A skeleton is associated with the mesh to control the pose of this virtual human. As a consequence, changes in joint configuration leads to an adaptation of the 3D mesh thanks to linear blend skinning method available in the Blender software  [32]. The resulting 3D mesh is exported in a standard obj file and the corresponding joint positions are exported in a separated text file. In the second part, the behavior of the Kinect sensor is simulated by transforming the 3D mesh into depth images according to the imposed virtual sensor position and orientation in space, and the camera-intrinsic parameters.
This way, we assume that the sensor is noise-free and is able to deliver accurate depth maps. The resulting 3D mesh is transformed into a depth map that is used as an input of the Kinect software. This software estimates the 3D position of the joint centers according to the Shotton's algorithm  [15]. Let us consider now the method used to compare the results obtained with the Kinect software to the reference data (i. e. , the joint angles applied to the virtual mannequin).
Kinematic Parameters Used to Estimate the Accuracy of the Kinect Software In this subsection, we describe the method used to compute joint angles according to the joint positions estimated by the Kinect software. First of all, one has to notice that if a pose sent to the Kinect is too different from the previous one, the system may need several frames to converge to a stable estimation. In this work we wish to send poses without any continuity in time and we consequently have to let the system converge to this stable solution. In the context of this experiment we have shown that the system converges after a maximum of 5 images. To take a security margin into account, we sent each pose to the Kinect software 15 times to guarantee reaching a stable estimation. In the end, only the final pose (the 15th one) is used in the following to analyze the accuracy of the system.
Once a stable pose is obtained, we have to compare the results to the reference values that were used to generate the 3D mesh of the virtual mannequin. The Kinect software only returns joint positions. An error in joint position would have a direct impact on the computation of joint angles and RULA score. Consequently, in this paper, we focused on three main parameters: joint position (shoulder, elbow, and wrist joint), joint angles (shoulder and elbow joint angles), and the corresponding RULA upper-limb score. According to the estimated joint positions, joint angles should be computed using the ISB recommendation  [33]. However the skeleton estimated by the Shotton's method is not compatible with this recommendation except for the humerus coordinate system. For the other joint coordinate systems, we have to proceed slightly differently according to the available points.
For the trunk, the X-axis is defined as the normal of the plan formed by the spine joint (placed at the pelvis), the basis of the neck, and the right shoulder joint. The right shoulder joint is chosen to compute the trunk reference frame because it does not move significantly when performing left-arm motions. As the Kinect software does not deliver all the required kinematic information to compute the forearm reference frame according to the ISB recommendations, we alternatively use the vector convention detailed by  [18]. Once the joint angles are known it is possible to compute RULA upper-limb scores  [4]. For the shoulder joint, we need to isolate the flexion/extension angle and the abduction/adduction angles. The ISB guidelines propose to use three Eulerian angles to define the shoulder motion.
The Kinect skeleton model was directly obtained at 30 Hz from the official Microsoft software development kit (Microsoft Kinect SDK v1. 8) based on the Shotton's algorithm  [15]. Let us denote the data provided by the Kinect as RK, and data provided by the Vicon motion capture system as MBS. The two systems were synchronized thanks to the inter-correlation method suggested in  [36]. Data were also resampled to obtain the same timestamp to facilitate comparison. A fourth order low-pass Butterworth filter with a cut-off frequency of 6 Hz was applied on the angle data for both systems  [18]. The root mean square error (RMSE) and the Pearson correlation between the three estimation methods is performed for the upper-limb joint angles. Each reference pose measured on the subject with (MBS) was then retargeted to drive the numerical mannequin in a similar joint configuration using inverse kinematics, as reported in  [37].
The position of the elbow and wrist joint centers were used as constraints of the inverse kinematics algorithm. This optimization method returns the joint angles minimizing the distance between virtual and real joint centers for the numerical mannequin. Finally we applied the method described in Section 2. 1 to compute expected outputs of the Kinect software based on the resulted virtual mannequin. Let us denote the data provided by this simulation of the Kinect sensor with the virtual mannequin as VK. The overall process is depicted in Figure  4. Experimental setup of the comparison of joint angles estimated with an optoelectronic motion capture system (MBS), the corresponding actual Kinect measurements (RK), and the simulated outputs using a virtual mannequin (VK).
Evaluation of the Pose Estimation Accuracy for a Kinect Placed in Front of the Character The first part of the results shows the accuracy of the estimated kinematic data when only the pose is changing, with a Kinect placed in front of the subject. Out of 4752 tested poses, we report the highlight of the results that seem representative of the global results (all the results are available as supplementary material: an executable program providing accuracy for all the possible upper-limb configurations). Figure  5  depicts the estimation error for the 135° swivel angle for all the azimuth and elevation configurations, with no elbow flexion. The first row depicts the error for the shoulder, elbow, and wrist joint positions. The second row depicts the error for the shoulder and elbow joint angles.
Discussion In this study, we have estimated the accuracy of the Kinect in simulated workplace conditions for a large set of work poses and with different sensor positions. This paper aims at providing the reader with details about the accuracy of the Kinect software to provide optimal methods for its use in workplace conditions. Our results are in accordance with previous works, especially for the accuracy of the estimated joint position  [23, 24]  and joint angles  [24, 25]. It remains difficult to compare our work with others because most of them generally measure planar gestures in 2D anatomical plans. Previous studies were also limited to a Kinect placed in front of the subject, and the impact of the device position relative to the subject was generally not evaluated. Only one work measured the accuracy of the Kinect for different orientations of the subject, ranging from the frontal to the side view  [23].
In other cases, the kinematic information provided by the Kinect software is acceptable for most applications (0. 052 ± 0. 03 m for the shoulder position error). One has to consider that results could be worse than those reported in this paper when using a real Kinect because of noise that was not taken into account here. In the third part of the results, the measured joint angles of a real human were correlated with those obtained with a real Kinect and method simulated Kinect based on the virtual mannequin. In this pilot study, the errors reported when using our method were similar to those obtained with a real Kinect. However, one can notice that the results obtained with the simulated Kinect were slightly better than those obtained with the real Kinect, which is in accordance to the fact that the virtual sensor is noise-free while the actual sensor is noisy.
In this study, the RULA evaluation is limited to the shoulder and elbow joints. It will be interesting to measure the other body parts requested by the RULA method (trunk, neck, wrist, and leg), to quantify their impacts on the resulting RULA score. To this end it would be necessary to apply the same method to these joint angles in a new protocol. The Kinect software does not deliver all the required kinematic information to compute the reference frames according to the ISB recommendations. In this work we slightly adapted the trunk reference frame to compute the joint angles of the shoulder. We also used an alternative computation for the elbow joint, as proposed by  [18]. This lack of information would be a problem if we implement a biomechanical model from the Kinect data, such as using inverse dynamics to estimate joint torques and forces.
Conclusions The study presented in this work suggests that the Kinect software can be a useful motion capture tool for ergonomic evaluation. In most of the results reported in this work, the accuracy is enough to correctly fill-in ergonomic assessment grids like the RULA grid. However large errors can occur in specific cases that have been reported in this paper, such as when the arm is aligned with the Kinect sensor. We also noticed that sensor placement may lead to bad estimations. Hence, an experimenter has to carefully design his protocol according to these results. He has to deal with constraints of the environment (such as occlusions or possible sensor placements) while taking these recommendations into account. The results reported in this study have been obtained with a new systematic method based on a virtual mannequin.
It allows us to automatically estimate the accuracy of the system for numerous complex poses and sensor positions, which would not be possible with classical methods and protocols. Moreover, this method focuses on the accuracy of the pose estimation algorithm provided by the official Kinect software. It assumes that the device is noise-free and delivers perfect depth images. Hence results with an actual Kinect sensor would certainly be worse than those reported in this paper. However, we assumed that being able to separate errors due to the sensor from those due to the method is a strong advantage, even for future upgrades of the measurement systems, such as the new Kinect 2. It would be possible to add noise to the simulated depth images used as an input in this work to simulate potential noise of the sensor.
Background: Biological pathways are descriptive diagrams of biological processes widely used for functional analysis of differentially expressed genes or proteins. Primary data analysis, such as quality control, normalisation, and statistical analysis, is often performed in scripting languages like R, Perl, and Python. Subsequent pathway analysis is usually performed using dedicated external applications. Workflows involving manual use of multiple environments are time consuming and error prone. Therefore, tools are needed that enable pathway analysis directly within the same scripting languages used for primary data analyses. Existing tools have limited capability in terms of available pathway content, pathway editing and visualisation options, and export file formats. Consequently, making the full-fledged pathway analysis tool PathVisio available from various scripting languages will benefit researchers.
Results: We developed PathVisioRPC, an XMLRPC interface for the pathway analysis software PathVisio. PathVisioRPC enables creating and editing biological pathways, visualising data on pathways, performing pathway statistics, and exporting results in several image formats in multiple programming environments. We demonstrate PathVisioRPC functionalities using examples in Python. Subsequently, we analyse a publicly available NCBI GEO gene expression dataset studying tumour bearing mice treated with cyclophosphamide in R. The R scripts demonstrate how calls to existing R packages for data processing and calls to PathVisioRPC can directly work together. To further support R users, we have created RPathVisio simplifying the use of PathVisioRPC in this environment. We have also created a pathway module for the microarray data analysis portal ArrayAnalysis.
org that calls the PathVisioRPC interface to perform pathway analysis. This module allows users to use PathVisio functionality online without having to download and install the software and exemplifies how the PathVisioRPC interface can be used by data analysis pipelines for functional analysis of processed genomics data. Conclusions: PathVisioRPC enables data visualisation and pathway analysis directly from within various analytical environments used for preliminary analyses. It supports the use of existing pathways from WikiPathways or pathways created using the RPC itself. It also enables automation of tasks performed using PathVisio, making it useful to PathVisio users performing repeated visualisation and analysis tasks.
Background Biological pathways are descriptive diagrams used to depict complex cellular processes such as metabolism, gene regulation, and signal transduction. Disturbances in such processes can cause disease. Pathways thus can help understand the functions of individual genes and proteins in terms of the systems and processes that contribute to normal physiology and to disease. Pathway analysis integrates and visualises global high throughput measurements and is a widely applied method among researchers to gain functional understanding from biological quantifications, such as gene expression and (relative) metabolite and protein abundances  [1]. Pathways can be obtained from pathway databases. The Pathguide website  [2, 3] , at the time of writing, listed more than 570 pathway-related databases.