dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgements This article is dedicated to the memory of  Alain Arneodo , who passed away during its writing. The authors acknowledge Alain's enthusiam and constant support. The authors also thank all members of the  OH lab as well as Arach Goldar ,  Patrice Abry  and  Nelly Pustelnik  for helpful discussions. We thank  Erwan Sallard  for his help generating the PSL strain. JMA and BA thanks  BioSyL Federation  and  Ecofect LabEx  [ ANR-11-LABX-0048 ] for inspiring scientific events. This work (OK-seq experiments) has benefited from facilities and expertise of the High-throughput Sequencing Platform of I2BC (Gif-sur-Yvette). We thank especially  Yan Jaszczyszyn  for expert help with Okazaki fragment sequencing. We thank the sequencing facility of  François Jacob Institute of biology (Genoscope, Evry ) for performing MinION sequencing.
Funding This work was supported by the  Ligue Nationale Contre le Cancer , the  Association pour la Recherche sur le Cancer , the  Agence Nationale de la Recherche  [ ANR-15-CE12-0011-01  and  ANR-18-CE45-0002 ], the  Fondation pour la Recherche Médicale  [ FRM DEI201512344404 ] and the  Cancéropole Ile-de-France  [ PLBIO16-302 ]. This work was partly supported by the  Genoscope , the  Commissariat à l'Energie Atomique et aux Energies Alternatives (CEA) and France Génomique  [ ANR-10-INBS-09-08 ]. BA acknowledges support from the  Joint Research Institute for Science and Society. Hennion  et al. , FORK-seq, 2020.
Availability of data and material The datasets generated during the current study are available from the ENA repository [PRJEB36782]  [51]. Raw data, as well as bed files with replication forks, initiation and termination events are included. The reads containing the 4,964 initiation and 4,485 termination events can be visualized at www. biologie. ens. fr/∼hennion/forkseq. html. RepNano can be downloaded from https://github. com/organic-chemistry/RepNano or https://doi. org/10. 5281/zenodo. 3743241 [21].
2013; Le Provost et al. 2013) , based on an FPGA for data preprocessing for the trigger and a Leon3 dual-core CPU running the complete ECLAIRs flight software including the trigger. As ECLAIRs' tantalum mask is opaque to soft gamma-ray photons, a source emitting such photons will project the shadow of the mask pattern onto the detector, and the image recorded by the detector is called a shadowgram. The sky image is reconstructed from the shadowgram using the mask deconvolution method (as it is, for example, currently used by the IBIS telescope onboard the ESA's INTEGRAL observatory; see e. g. Goldwurm et al. (2003)  for a description of the method). The deconvolution uses the detected number of counts per pixel D cnt and, assuming a Poissonian distribution per detector pixel (D var = D cnt ), it produces reconstructed sky images in number of counts (S cnt ) and variance (S var ) from which an SNR sky image is computed: S SNR = S cnt / √ S var.
Cross-correlation of catalogues and celestial position As the MAXI/GSC and Swift/BAT instruments provide crude positions (in comparison to the ones given by focused instruments such as Chandra or XMM-Newton in X-rays or even optical positions of their counterparts when they are known), the source positions that will be given in the onboard catalogue are the best positions that are reported in SIMBAD  (Wenger et al. 2000). Most of these come from the Gaia data release Gaia Collaboration (2018). Many sources have various names/identifiers, often associated with different counterparts in various spectral windows. In order to associate a MAXI source to a Swift one (and vice versa) we use the Sesame name resolver 2 for each source to find the main identifier. For instance, Crab has 56 identifiers (M 1, Taurus A, SWIFT J0534.
our needs. Moreover the bright sources will be cleaned regardless of their states (see Sec. 3. 5). As a result, 1698 sources can be well modelled with a single powerlaw spectrum and 95 sources are described by a broken powerlaw. Table 2 also gives the spectral parameters of the brightest sources. The full table giving the general properties, the data in the spectral bands from MAXI/GSC and Swift/BAT, and the spectral fit we performed, for all the 1793 sources, is available at the CDS. In the simulations presented in section 3, the sources will be projected through ECLAIRs' model, using the photon flux obtained by the integration of the spectrum in a maximum energy range of 4 to 150 keV. Photons from sources without Swift/BAT counterpart will be rejected above 20 keV, while photons from sources without MAXI/GSC counterpart (present only in the BAT 105 month catalogue) will be rejected below 14 keV.
If an event is detected and its position does not match with a source of the onboard catalogue (or there is no det or sky flag associated to the source in the triggering energy band), the observation strategy will follow the same as the one defined for GRB candidates. A faint X-ray source, that is not included in the onboard catalogue, may be identified on ground by a search in object databases such as SIMBAD. In this case, the detected source can be added to the onboard catalogue with a flag and a threshold (from ground by telecommand). Here, we suppose that the onboard instruments MXT and VT do not need to know whether the alert comes from such a source or from a GRB.
Conclusion The catalogue of sources that we presented in this article is composed of 1793 sources and is built from Swift/BAT and MAXI/GSC data. We used this catalogue to study the influence of the known X-ray sources on the SVOM/ECLAIRs background level and showed that the source contributions will widen the distribution of the SNR in sky images produced after deconvolution of ECLAIRs' detector images. We also produced a preliminary version of the onboard catalogue with 89 bright sources that need to be cleaned or avoided during new-source searches. The influence of the sources is strongly dependent on the pointing position, on the exposure time and on the trigger energy band. This study shows that in any case, a cleaning of bright sources (such as Sco X-1) is required to reduce as much as possible the coding noise in the sky images and to keep the standard deviation of the SNR distribution in reconstructed sky images close to 1, in order to detect new sources (such as GRBs) as part of the SVOM core program with a low false trigger rate.
Acknowledgements. ECLAIRs is a cooperation between  CNES ,  CEA  and  CNRS , with CNES acting as prime contractor. This work is supported by  CEA  and by the " IDI 2017" project of the French "Investissements d'Avenir" program , financed by  IDEX Paris-Saclay ,  ANR-11-IDEX-0003-02. This research has made use of the SIMBAD database, operated at  CDS, Strasbourg, France  and of the MAXI data provided by  RIKEN ,  JAXA  and the MAXI team. We would like to acknowledge helpful comments on the manuscript from the anonymous referee. We would also like to thank very much  David Palmer  from the  Swift/BAT  onboard trigger software team for his very valuable comments and advises.
Modern microscopy is based on reproducible quantitative analysis, image data should be batch-processed by a standardized system that can be shared and easily reused by others. Furthermore, such system should require none or minimal programming from the users. We developed TAPAS (Towards an Automated Processing and Analysis System). The goal is to design an easy system for describing and exchanging processing workflows. The protocols are simple text files comprising a linear list of commands used to process and analyse the images. An extensive set of 60 modules is already available, mostly based on the tools proposed in the 3D ImageJ Suite. We propose a wizard, called TAPAS menu, to help the user design the protocol by listing the available modules and the parameters associated. Most modules will have default parameters values for most common tasks.
Introduction Modern microscopy, through new systems like light-sheet or high-throughput microscopes, is generating a vast amount of complex data that needs to be analysed. These data can be large in size or in number. Furthermore, for the purpose of reproducible quantitative analysis, these data should be batch-processed by a standardized system, that can be easily shared and reused. Some batch systems already exist such as CellProfiler  1  , ICY  2  protocols or ImageJ macros  3. However, these systems may require some programming knowledge or time to set up for inexperienced users or are not yet fully multi-dimensional. First category of automation methods is script-based automation, such as ImageJ or ICY scripts, both based on Java or JavaScript language. These scripts will include reference to location of data itself and hence are not easily shared between users.
TAPAS modules are organised by categories: • Input/Output, to download and upload image and quantitative results data. • Calibration, to load, save and apply calibration to image data. • Processing, to edit image data such as cropping, mathematical operations, scaling. • Filtering, to filter 2D or 3D image data using either 3DFastFilters from the 3D ImageJ Suite or CLIJ filters (GPU filtering). • Thresholding, to create binary images, using different methods such as automatic global thresholding, hysteresis thresholding, iterative thresholding, percentile thresholding. • Labelling, with minimal and maximal size filtering. • Post-processing, to filter out binary or labelled data, including mathematical morphology (fill holes, closing), exclude objects on edges, keep biggest object, filter objects based on size or shape.
Amendments from Version 1 This revised version is an extended version giving more details about the TAPAS system. In Introduction the two different types of existing automation systems are explained, namely language-based and graphbased. TAPAS relies on a linear protocol based on independent modules. In Methods the different available modules are detailed and categorised. The TAPAS protocols are simple and humanreadable and modifiable text files, and some details are given about TAPAS syntax. TAPAS implements a simple, yet robust, execution interface, providing both inexperienced and confirmed developers guidelines to develop their own module, either based on the ImageJ ecosystem or any java-based library. Basically, developers only have to implement the "execute" function that will process an input image and provide an output image.
Modules parameters are managed as simple String variables. Finally the linear structure of the protocols is more detailed, with a typical example to segment objects in a multi-channel image, and perform intensity quantification. The main idea of the TAPAS system is to focus on a linear protocol, where an input image is processed by successive processing modules. In case of processing operations requiring two or more input images, the additional images input will serve as parameters to the main processing module and will need to be saved locally beforehand. Any further responses from the reviewers can be found at the end of the article includes advanced segmentation and analysis modules, TAPAS is focusing more on data organization and simplified workflows rather than complex segmentation or analysis algorithms.
TAPAS focused originally on data stored on an OMERO database, by allowing to retrieve, perform classical segmentation procedures and analysis, and push back the results, both images and tables, to the database. Data on OMERO are, by design, organized by user, then projects and datasets. In TAPAS the current analysed image is simply referred by the keyword ?image?, and the corresponding project and dataset the data belongs to by ?project? and ?dataset? respectively. Subsequent processed data are then referred as ?image?-processing, for instance ?image?-nucleus for the result of nucleus segmentation. Similarly, additional datasets can be created such ?dataset?-labels to store the results of segmentation. The results tables can be stored using the name of the image as reference such as ?image?-nucleus-volume.
csv. Results tables will be linked to the original raw image using OMERO attachments. The TAPAS workflow language is based on a linear sequence of modules, described by their name and parameters values. The module name is simply preceded by the keyword process. Note that the values for parameters can include space characters, and eventually commas if the parameter value is to be a list. A typical example for one module is then: // comment for the module process : name_of_module name_parameter1 : value of the parameter1 name_parameter2 : value of parameter2 The main difference with other workflow systems is that, in TAPAS, there is only one image data that is transferred between the different modules, and this image data does not need to be explicitly defined as one of the parameter. There is hence an implicit link between the output of a module and the input of the next module.
Implementation The system is implemented in Java, with a core library, including OMERO and BioFormats input/output utilities, and a plugins library including a comprehensive set of modules. Each module is generic as it will process a generic Image class, and each class will get an Image as input and will return an Image as output. The current system uses the ImageJ ImagePlus class as implementation for the Image class, however any other class can be used, allowing the use of any Java library. Alongside the actual image data, that is passed from module to module, the information about the original image data is also passed to the module in the form of an ImageInfo. This information will store the original information about the storage location of the image, i. e. its original project, dataset and image name, as defined above.
public class TapasProcessorMyImageType extends TapasProcessorAbstract<MyImageType> Second the developer has to implement the functions of the generic processing class. The function getName will simply return the name defined for the module. The main function is execute that will effectively do the processing of the image, and will take the Image type defined in the processor as input and output. The function setCurrentImage will transfer the image information to the module as an ImageInfo, and does need any rewriting. This information may be used to input or ouptut data. Finally, three functions deal with the parameters, the first one setParameter will give the information about one parameter to the module in the form of two Strings, the name and the value of the parameter. Actually, this function, besides execute, may need some work if the developer wants to carefully check the parameter names and their corresponding values.
Usually the set of possible parameter names are hard-coded and defined within the module class itself. Two other functions getParameters and getParameter(parameter name) are used for displaying parameters information. In order to link the Java classes to the modules names, there is a simple text file called tapas. txt organised as follows: module_name:path. to. the. java. class. The program will check, when initialized, if two classes link to the same name; the program will also store internally in a hashMap the link between modules names and java classes. The processing pipeline is constructed as an ordered list of processing classes, with their corresponding parameters. Since the classes are generic, a processor is also specified as how to process the image data, by default an ImagePlus processor is built.
An experimental version of processor with a set of processing modules using the clearCLBuffer class has been tested and validated using the CLIJ system 8. Operation TAPAS is java-based and works with the ImageJ/Fiji system, the use of a OMERO database is optional. TAPAS is designed to work with a database; either OMERO or a local database. A local database is a folder organized, not unlike OMERO, as projects, datasets, and finally images. We also add an attachments' folder to store the results tables. Having a completely similar organization between OMERO and a local database allows to have an exact same protocol to run using an OMERO database or a local database. A typical workflow of the system is presented in Figure  1. TAPAS is using the BioFormats library to open image files so it can handle most common microscopy image files when used with a local database.
Common image analysis workflow will require detecting objects in one or several channels, perform analysis in the same or other channels. Most of the time the input data is a multi-channel image, and a specific object type is detected within one channel. However, in TAPAS as in most image processing algorithms, image operations are performed on mono-channel images. The main difference in the TAPAS system is that the workflows are strictly linear and a module can only have one input image. In case a module, such as a co-localisation module, requires two input images, one image will be the main input and the other image will be used as a parameter, and hence need to be saved locally beforehand.
Use case To successfully build a TAPAS workflow we propose a simple TAPAS menu that will display in an organized manner the list of available modules with their corresponding category and documentation. After selecting a module, the list of parameters will be displayed, the user can then manually enter the parameters values, and the corresponding processing pipeline text will be created. Note that default values are also proposed for most of the parameters, if the user chooses to use the default value for a parameter, the line corresponding to this parameter can be omitted, greatly simplifying the workflow text. The system separates the data to be processed from the processing pipeline. Firstly, the list of image data to be processed is built, each image data to be processed is identified by its project, dataset and name (either on OMERO or on a local DB).
Second, the processing pipeline file is to be selected. After clicking run, the system will process the images sequentially, displaying information for each module, and the final processing time per image. Raw data will be pulled from the database and processed and analysed data will be pushed back to the database. We propose a simple TAPAS menu that will display in an organized manner the list of available modules with their corresponding category and documentation. After selecting a module, the list of parameters will be displayed, the user can then manually enter the parameters values, and the corresponding processing pipeline text will be created. Here we describe a typical workflow to perform intensity measurement on detected objects. The first part of the workflow will input the two channels separately, and save the raw intensity of channel 2 locally.
// input channel 2 and save it locally // since we are referring to the original image, we only need to specify the channel process : input channel : 2 // we save locally in the ImageJ/Fiji folder (other default folders are available) // ?image? refers to the original image name process : save dir : ?ij? file : ?image?-C2 2) The necessary data to be used later is saved locally, in a temporary folder (home folder, ImageJ/Fiji folder or system temporary folder). Here we saved the raw data for channel 1. 3) The data is processed, here a classical pipeline consisting of filtering, thresholding and labelling. 4) The resulting labelled data is output to the Database, here the labelled structure for channel 1 is the nucleus. 5) The previously saved raw data is used as parameter to quantify intensity inside the labelled nuclei.
Robert Haase Cluster of Excellence "Physics of Life", Technische Universität Dresden, Dresden, Germany I am happy to read the revised version of the manuscript. It covers all my suggestions from the last round. I appreciate the deeper insights into the technology the authors present and the comparison with other open source tools available aiming at a similar target audience. I congratulate the authors to this excellent manuscript and wish the best for the future of the TAPAS project. Competing Interests: I do maintain software projects that aim at a similar audience. The authors showed compatibility with my tools which is nice. Anyway, this could be interpreted as a potential confilict of interest. Reviewer Expertise: Bio-Image Analysis, Computer Science I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard.
Summary: Gilles et al. report a new software tool called TAPAS for batch processing and analysis of microscopy images. The tool is based on ImageJ/Fiji and can load images from the local file system or remote OMERO database. A set of 60 analysis modules or commands are currently available, mostly come from a previously developed package, 3D ImageJ Suite. The ability to batch process images using a standardized system is critical for ensuring the reproducibility of published results, and also the continuity of the development and applications of established analysis pipelines. The authors correctly point out that there are many existing tools that can do batch processing, such as CellProfiler, Icy, or ImageJ macros. However, one of the key advantages of TAPAS is the simplification of the specifications of an analysis workflow using text files (which can be edited using any text editor) and intuitive command syntax (which require minimum effort to learn).
Major comments: For this reviewer, the syntax of TAPAS is one of the most interesting and novel parts of the software. However, insufficient details and examples have been provided to explain the syntax and rules of the "TAPAS language". One suggestion is to provide an example for a typical image analysis pipeline (e. g. , image import, preprocessing, segmentation, feature extraction, result export). The authors may include pseudo codes (or a block diagram) and the corresponding TAPAS code that can accomplish the tasks.
1. It is not very clear what types of microscopy images can TAPAS process. The authors kind of alluded that the tools is meant for 3D images, but this has not been clearly presented. For example, can TAPAS process bright-field or RGB images? Time-lapse images? Or 3D-stack images? 2. Can TAPAS run any ImageJ commands/functions? Or is it restricted only to functions from the ~60 modules? 3. The authors may present some simple examples of the results and screenshots that can be obtained from TAPAS. For example, counting of cells or measurement of protein expression levels in 3D images. These examples will be very helpful to let the readers understand how TAPAS may be used.
To conclude, TAPAS is a great extension for ImageJ/Fiji and eases integration of workflows in the OMERO ecosystem. It is extensible and flexible in use giving a powerful toolbox in the hands of end-users. I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard, however I have significant reservations, as outlined above. The benefits of publishing with F1000Research: Your article is published within days, with no editorial bias • You can publish traditional articles, null/negative results, case reports, data notes and more • The peer review process is transparent and collaborative • Your article is indexed in PubMed after passing peer review • Dedicated customer support at every stage • For pre-submission enquiries, contact research@f1000.