dataesr/scientific-paragraphs-categorization huggingface dataset:
14 , the average correlation reaches a maximum for r = 3 seconds then decreases. It is interesting to disaggregate the results and analyze the correlation per video type. Fig. 12 -right shows the correlation results for each of the 5 test videos in the MMSys18 dataset. For both videos of type exploration, PortoRiverside and PlanEnergyBiolab, the correlation is significantly low. However for the focus-type videos (Warship, WaterPark and Turtle), the correlation is moderate, being significant for the first two for 2 ≤ r ≤ 3 sec. , while for Turtle, the performance in unstable (it is worth noting that Turtle is of type moving focus video, which is not present in the training set). We also notice that the maximum correlation is obtained for r ≤ 1. 5 sec. for exploration videos, while the maximum is obtained for r ≥ 3 sec.
for focus-type videos. The other two datasets have 16 (PAMI18) and 42 (CVPR18) test videos. Therefore, to categorize the video automatically between exploration and focus-type video, we resort to the method presented by Romero et al. [52] , consisting in associating exploration (resp. focus) videos with low (resp. high) entropy values of the saliency maps obtained from the user traces. Fig. 13 -right and 14-right show the correlation results broken down into the 10% of videos with highest entropy, 10% with lowest entropy, and the rest. In Fig. 13 -right, we observe that for PAMI18 focus videos, the correlation is strong and significant for r ≥ 3 sec. , while it is low significant for exploration videos and moderate significant for the rest. Similar trends can be observed with CVPR18 videos, where the correlation is low and significant for exploration videos, and moderate and significant for the rest.
CONCLUSION In this article, we presented the first method for multiple head motion prediction in 360°videos. We showed that the need for multiple trajectories is motivated by the diversity of future trajectories in real-world user data. Our main contribution is a new learning framework, called DVMS, which builds on deep latent variable models and allows to predict multiple future trajectories from a given past. We design a training procedure to obtain a flexible and lightweight stochastic prediction model compatible with sequence-to-sequence architectures. Experimental results on 3 datasets show that DVMS matches relevant baselines for single trajectory prediction and outperforms competitors adapted from the self-driving domain by up to 37%, on prediction horizons up to 5 seconds. By exploiting the stationarity of the prediction error over the latent space, our method provides likelihood estimates of every predicted trajectory, enabling direct integration in streaming optimization.
ACKNOWLEDGMENTS This work has been partly supported by the  French government , through the  UCA JEDI  and  EUR DS4H Investments in the Future  projects  ANR-15-IDEX-0001  and  ANR-17-EURE-0004. This work was partly supported by  EU Horizon 2020  project  AI4Media , under contract no. 951911  (https://ai4media. eu/). This work was performed using HPC/AI resources from  GENCI-IDRIS  (Grant  2020-AD011012209 ).
The simulation was carried out using the Python package astroplan,  27  and observability was tested for a five-year period starting from the 01 January 2022. The results of our simulation are presented in Fig. 1 , with the top row of panels showing the distribution of planets according to period and duration and the bottom panel showing the planets' distribution on the sky. There are two very clear conclusions to be drawn from the top panels; firstly, we can see that ASTEP is the only observatory that can consistently observe full events for both infrequent and long duration transits. The other observatories have almost no observability above eight hours, while ASTEP maintains in excess of 20% for some transits lasting over 12 hours. Secondly, we can see that while all observatories can observe some long-period transits in full, their percentage observability is lower than ASTEP's, and where long periods intersect with long transits, there are no transits observable.
Targets selected for observation each night were recorded in a Google Doc 30 which was shared with the team. Both elements of this initial system were limited. The generation of the. pdf files required that each team member check the Google Drive for new files on a weekly basis. Our use of a Google Doc to record the upcoming schedule also rapidly became time consuming; additionally, the important information contained therein was vulnerable as the whole team had access. Finally, manual input of information meant that small inaccuracies could cause us to miss important observations. The earliest incarnations of the system we use now harnessed the G-Suite  30  Python APIs (Application Programming Interfaces) to read and write information to a Google Sheet instead of a Google Doc. G-Suite provides excellent collaborative working tools for international teams such as ours, but limiting vulnerability of underlying data while ensuring everyone could access crucial information became a top priority.
Generating the data: Python toolkit As described above, one of ASTEP's key goals that emerged from the 2020 observing season was to define a list of targets that were of particular scientific interest to us. With an ever-growing list of candidates emerging on a monthly basis from TESS, there was a need for a simple way to filter through the list of TOIs (TESS Objects of Interest) to find those best suited to our unique context. This motivated the development of our TESS target list tool, written in Python and used via a Jupyter Notebook with an ipywidgets GUI. This simple tool makes use of intuitive sliders and dropdown lists to make target lists based on user-selected parameters. We present a screenshot of the TESS target list tool in Fig. 4. With pre-selected target lists now in place, a vast amount of scheduling can be done ahead of time.
Computing the timings of upcoming transits using linear ephemerides is trivial, however the Python package astroplan 27 does this with elegance and simplicity. Not only can it compute the timings of upcoming events for eclipsing systems, both stellar and planetary in nature, but it will also output observability of said events for different observatories. Leveraging both astroplan and the Google Sheets Python API, we developed the scheduler: schedule ahead. This software reads the target list directly from a 'Master Target List' located on a Google Sheet (see Fig. 3 ) and imports the stellar coordinates and orbital ephemerides for each of the targets, provided they have an 'Observe' status of 'Active'. User inputs are an observatory (ASTEP, in this case), a start date, and a number of days to schedule for; these are combined with the system parameters from the target list and fed into astroplan.
2. 3). Additionally, the schedule often has large gaps (see Fig. 6 ) that can be filled with our pre-selected filler targets or opportunistic observations of transits. In order to facilitate the latter, we use a custom Python script to search the TESS Transit Finder 29 for transits of TESS candidates within a given date range. The results of the search are then scored according to how well each target suits our scientific interests, and airmass plot data are computed for the top 30 events using astropy. 31, 32   hese data, along with system parameters of interest, are stored in the Google Sheet. This script therefore completely replaces the IDL script which generated the. pdf files.
Holding the data: Google Sheet The team's Google Sheet holds all the underlying data generated by the Python toolkit, and updated and read by the website, as shown in Fig. 3 : the target list, the schedule, the airmass plot data, and the team's thoughts. The Master Target List contains host star parameters, transit ephemerides and TTF meta-data (such as observing notes) for each target we have chosen to observe. The data for this sheet are generated by our TESS target list tool, and updated by the ephemerides checking script before running the scheduler each week. Targets are grouped into observing programs and are each given an 'Observe' status: 'Active', 'Standby' or 'Retired'. This flag is read by the scheduler and can be updated manually or programmatically. The observation schedule is saved in two worksheets; one is human readable with observation and event timings in ISO format, while the other is intended to be read by the graphical web schedule and has timings in UNIX format.
The former is also used to display the schedule in tabular form on the website. As described above, the data for airmass plots of potentially interesting targets are generated via a Python script; these data are then stored in their own worksheet to be read by the website. The information contained therein is not intended to be human readable, therefore the worksheet is not formatted and has no headers. Data from previous weeks are cleared once observations have taken place to make the Google Sheet load quickly. Once the data for the airmass plots have been generated in advance of a weekly meeting, the upcoming events can be viewed on the website on the target selection page. In order to facilitate fruitful discussions during the meeting, there is a box where team members can add their preferences and thoughts for upcoming scheduling.
Displaying the data: The website For effective collaborative working in an international team, it is essential that everyone can access all the information in a convenient way. In addition, Google Sheets are handy but can be easily altered mistakenly. With this in mind, we developed a website for the ASTEP team using HTML, CSS and JavaScript. The essential feature the website provides is access to data (see Fig. 3 ), and this is done via DataTables * , a JavaScript package for interactive HTML tables. Information from each of the Google Sheets is fed in as JSON. As a result team members can access fully paginated, searchable and sortable HTML tables. These tables can also be exported in four formats; a screenshot of the schedule as displayed in a DataTable is presented in Fig. 5. In the hope of making the website experience as user-friendly as possible, we developed an interactive graphical view of the schedule using the JavaScript plotting package Highcharts †.
Future Direction During the 2021 observing season the version of the Google Sheets API we were using was unexpectedly retired, causing our entire toolkit to stop working. Upgrading to the new version of the API took approximately two weeks, during which time we had to revert to manual target selection. With this in mind, we aspire to phase out our use of G-Suite in future. This will be achieved by storing our data in databases as they can be easily written to and read by Python and web-based applications. The use of databases will therefore eliminate the need for a Google Sheet to store our data and the Sheets API to read/write information. A further limitation which we will seek to address is that the full Python toolkit is locally stored and run on one team member's computer. This will be improved in future by using a Python-based web framework such as Django * or Flask † to fully embed the toolkit in the website.
IDL Pipeline The IDL data process pipeline, only briefly described here (see Abe et al. 2013 6 for a complete description) is a custom IDL code using classical aperture photometry routines from the well-known IDL astronomical library. Each science exposure frame is bias subtracted, dark corrected and the astrometric solution is computed using reference stars from the UCAC4 catalogue. Photometric lightcurves of about 1,000 stars are then performed through 10 fixed circular apertures radii. The optimal calibrated lightcurve is then extracted using a set of comparison stars. This pipeline has served its purpose well and has allowed ASTEP to contribute to many publications since we joined TFOP in 2020  12, 13, 16, 17   ). However, the cost of IDL and its declining usage means that maintenance of the pipeline is becoming highly specialised knowledge.
Python Pipeline Rather than starting to develop the pipeline from scratch, we chose to build the pipeline around an astronomical data processing package written with TESS follow-up in mind: prose. prose * is an open-source Python package dedicated to astronomical image processing. 33 By featuring a wide range of pre-implemented processing blocks (from source detection to photometric extraction), it provides a framework to quickly assemble instrument-agnostic pipelines that are modular and easy to maintain. prose is supplemented by convenient tools to manage and share the products of astronomical observations, such as the automatic generation of TESS follow-up reports, making it an ideal base for the new ASTEP+ pipeline. In the following sections, describe the blocks and functionalities that form the core of the ASTEP+ pipeline, including custom modifications from the base prose package.
Image Calibration We based ASTEP+'s pipeline on the prose default photometric pipeline, which can be decomposed in two steps: The calibration and alignment of all images to produce a high-SNR stack image of the complete observation; And the extraction of the fluxes from the brightest stars in the field, using a wide range of size-varying apertures. The calibration sequence starts with the selection of a reference image, on which n reference stars are detected, later used to align the rest of the science images on. Then, each raw image sequentially go through bias, dark and flat calibrations, before being trimmed for overscan pixels. For each image, the n brightest stars are detected and compared to the reference ones in order to compute the affine transformation to the reference image. This is done using twirl ‡ (a simplified Python implementation of Astrometry.
* Unlike the IDL pipeline, the new pipeline only requires that we plate solve the stack image as the field rotation between each image is calculated by the twirl block by prose during the calibration stage of the pipeline. ASTEP+'s images are centered on the guide star, and its coordinates, together with the image pixel scale determined by the astrometric solution, are used to define a search cone. Under normal operation a call would be made to MAST (Barbara A. Mikulski Archive for Space Telescopes) via astroquery  35  to find all stars in this cone for a given catalog. In order to remove this need, we instead make use of a local version of the TESS Input Catalog (TIC),  36  saved in an SQLite database, to perform the search. The WCS header information is then used to transform celestial coordinates into pixel coordinates, and the closest aperture to the target is selected.
Lightcurve Modelling With the IDL pipeline, the biggest interaction required in post-processing has always been the modelling of lightcurves after they arrived in Europe. However, there are many simple cases where the detected transit matches the ephemerides well; to save time for these objects, we have written a new module for prose: auto modelling. All our lightcurves are correlated with airmass and background sky level. Additionally, variations in the FWHM (the full width at half maximum) can introduce spurious signals to the data. For this reason, all lightcurves are detrended by fitting an order two polynomial of time simultaneously to airmass, FWHM and the background sky level. This is done at the same time as the transit modelling. There are sometimes additional signals in the data caused by motion of the telescope in the night (dx and dy).
Rather than detrend on these parameters, we reject any images where either of these parameters are greater than 5. Transit fitting is implemented using exoplanet, 39 a flexible toolkit for modelling exoplanets using PyMC3 40 for MCMC (Markov Chain Monte Carlo) modelling. Priors on the transit parameters are taken from the image headers, while host star priors are drawn from the local TICv8 database. In cases where the stellar T eff , [Fe/H] and logg are available, quadratic limb darkening coefficients are also calculated using PyLDTK. 41 These are then set as normal priors for the fit; where host data is not available, solar values of stellar mass and radius are used instead. In these cases uniform priors between 0 -1 are used for the limb darkening coefficients. The automatic lightcurve modelling is not always successful.
Delivery of Data Products As described in Section 1, one of the biggest limitations that comes with an Antarctic telescope is the very limited internet connection. This is of course the motivation for our automatic data processing on-site, but it also limits how we access the data products output by the pipeline. The largest data products are the. phot files containing the aperture photometry for up to 1000 stars in the field as well as all the metadata for the observation, and the stack image produced during the reduction. These files are sent to a local server in Concordia using the Python package paramiko * ; this server has a folder which synchronises with a corresponding folder on a server in Rome. Depending on the size of the files, they take between 12-24 hours to arrive in Europe; they are then available for download for any necessary post-processing.
Noise and SNR comparison Following the method described in Garcia et al. (2022),  33  we compare the automatic lightcurves produced by the Python and IDL pipelines using four metrics: the binned white noise, the white and red noise following Pont et  al. (2006),  42  and the transit signal-to-noise ratio (SNR). All lightcurves used for the comparison were detrended by fitting a polynomial in time to the airmass and background sky level only; we then modelled each transit by fitting a simple Keplerian orbit using exoplanet. In all comparison cases, we placed uniform priors of U(0 -1) on quadratic limb darkening coefficients. Using the resulting transit models, we also compare the binned root mean square (RMS) scatter of the lightcurves, calculated as the standard deviation of the binned residuals.
CONCLUSIONS In this work we have presented a suite of tools developed for scheduling time-domain astronomical observations. While these systems have been written with ASTEP+ in mind, they are easily adaptable for other observatories focused on observations with strong time constraints. We have also presented a new automatic data analysis pipeline written in Python and built around prose. The new pipeline produces lightcurves that on average have lower red and white noise, lower scatter, and therefore allow for transits to be detected with higher SNR compared with the system it replaces. Additionally, as the pipeline runs significantly faster we will also decrease our energy usage and carbon footprint resulting from computationally intensive reductions. This remains true even taking into account the increase in data generated by having two cameras instead of one.
ACKNOWLEDGMENTS This research is in part funded by the  European Union 's  Horizon 2020 research and innovation programme  (grants agreements n • 803193/BEBOP), and from the  Science and Technology Facilities Council (STFC ; grant n •  ST/S00193X/1 ). We acknowledge support from the  European Space Agency (ESA)  through the  Science Faculty of the European Space Research and Technology Centre (ESTEC). ASTEP and ASTEP+ have benefited from the support of the  French and Italian polar agencies IPEV  and  PNRA , and from  INSU ,  ESA  through the  Science Faculty of the European Space Research and Technology Centre (ESTEC) , the  University of Birmingham , the  laboratoire Lagrange  ( CNRS UMR 7293 ) and the  Université Côte d'Azur  through  Idex UCAJEDI  ( ANR-15-IDEX-01 ). This publication benefits from the support of the  French Community of Belgium  in the context of the  FRIA Doctoral Grant  awarded to  Mathilde Timmermans  and  Lionel J.
Our contributions Our aim is to define a multi-task GP framework with common mean process, allowing reliable probabilistic forecasts even in multiple-step-ahead problems, or for sparsely observed individuals. For this purpose, (i) We introduce a GP model where the specific covariance structure of each individual is defined through a kernel and its associated set of hyper-parameters, whereas a mean function µ 0 overcomes the weaknesses of classic GPs in making predictions far from observed data. To account for its uncertainty, we propose to define the common mean process µ 0 as a GP as well. (ii) We derive an algorithm called Magma (available as a R package at https://github. com/ArthurLeroy/MAGMA) to compute µ 0 's hyper-posterior distribution together with the estimation of hyper-parameters in an EM fashion, and discuss its computational complexity.
(iii) We enrich Magma with explicit formulas to make predictions for a new, partially observed, individual. The hyperposterior distribution of µ 0 provides a prior belief on what we expect to observe before seeing any of the new individual's data, as an already-informed process integrating both trend and uncertainty coming from other individuals. (iv) We illustrate the performance of our method on synthetic and two real-life datasets, and obtain state-of-the-art results compared to alternative approaches.
Outline The paper is organised as follows. We introduce our multi-task Gaussian process model in Sec. 2, along with notation. Sec. 3 is devoted to the inference procedure, with an Expectation-Maximisation (EM) algorithm to estimate the Gaussian process hyperparameters. We leverage this strategy in Sec. 4 and derive a prediction algorithm. In Sec. 5, we analyse and discuss the computational complexity of both the inference and prediction procedures. Our methodology is illustrated in Sec. 6, with a series of experiments on both synthetic and real-life datasets, and a comparison to competing state-of-the-art algorithms. On those tasks, we provide empirical evidence that our algorithm outperforms other approaches. Sec. 7 draws perspectives for future work, and we defer all proofs to original results claimed in the paper to Sec.
Notation While GPs can be used for many types of data, their continuous nature makes them particularly well suited to study temporal phenomena. Throughout, we use the term individual as a synonym of task or batch, and adopt notation and vocabulary of time series to remain consistent with the real datasets application we provide in Sec. 6. 5, which addresses young swimmers performances' forecast. These time series are considered as pointwise observations of functions we try to reconstruct thanks to the following generative model. We are provided with functional data coming from M ∈ I different individuals, where I ⊂ N. For each individual i, we observe a set of inputs and outputs t 1 i , y i (t 1 i ) ,. , t N i i , y i (t N i i ) , where N i is the number of data points for the i-th individual.
• Initial values for the variance of the error terms {σ i } i. This choice mostly depends on the context and properties of the dataset. We suggest avoiding initial values with more than an order of magnitude different from the variability of data. In particular, a too high value might result in a model mostly capturing noise. As a final note, let us stress that the EM algorithm depends on the initialisation and is only guaranteed to converge to local maxima of the likelihood function  (Krishnan and McLachlan, 1997). Several strategies have been considered in the literature to tackle this issue such as simulated annealing and the use of multiple initialisations  (Biernacki et al. , 2003). In this paper, we choose the latter option.
Pseudocode We wrap up this section with the pseudocode of the EM component of our complete algorithm, which we call Magma (standing for Multi tAsk Gaussian processes with common MeAn). The corresponding code is available at https://github. com/ArthurLeroy/ MAGMA. Algorithm 1 Magma: EM component Initialise m 0 and Θ = {θ 0 , {θ i } i , {σ i } i }. while not converged do E step: Compute the hyper-posterior distribution p(µ 0 | {y i } i , Θ) = N( m 0 , K). M step: Estimate hyper-parameter by maximising Θ = argmax Θ E µ 0 |{y i } i [ p(µ 0 , {y i } i |Θ) ]. end while return Θ, m 0 , K.