dataesr/scientific-paragraphs-categorization huggingface dataset:
The land use and land cover (LULC) information was extracted from the European Urban Atlas (UA) 2012 database  (Montero et al. , 2014) , cropping circular areas centred at each flux tower. The radii of these areas were set equal to the median distance of the 70th percentile of the estimated contribution of the cumulative flux footprint  (Kljun et al. , 2015) , irrespective of wind direction. This length represents the distance within which 70% of the measured flux is estimated to originate. It was calculated for 8 sites at which footprint estimates were available whereas, for the other 5 sites, it was estimated according to an average ratio between the calculated distances and measurement heights (Table  S1 ). To facilitate the interpretation of results, similar UA-LULC classes were combined into broader classes, the main four of which were: (i) predominantly residential areas (RES), consisting mainly of residential structures, but also including downtown areas and city centres (higher storeys of buildings are mostly residential), with various degrees of soil sealing; (ii) nonresidential areas (nRES), consisting in industrial and commercial areas, as well as schools and military units; (iii) areas dominated by roads and railway networks (ROD); and (iv) green urban areas (GUA), that include pervious surfaces with vegetation e.
g. lawns, parks, greenbelts, farmland, urban forests. We used Google Earth Imagery (© 2020 Google), Sentinel-2 satellite Normalised Difference Vegetation Index (NDVI), and local knowledge of each site, to improve the characterization of districts. At each site, relatively homogeneous wind sectors were associated with single LULC class (supplementary "Spatial analysis" section). The NDVI data were used to determine the extent of green spaces and to track the temporal dynamics in vegetation activity, to minimise the risk of misinterpreting trends in RFC arising from year-to-year variations (supplementary "Vegetation analysis" section). Two independent datasets of city-scale activity, the Carbon Monitor emission inventory (CM, https://carbonmonitor. org/) and Google COVID-19 Community Mobility Reports (©2021Google), were used to assist interpretation of the RFC at each site.
Some cities showed a clear and consistent decrease in RFC with SI (e. g. AT-Vienna, GR-Heraklion, IT-Pessaro) while others show more variability (e. g. AT-Innsbruck, FI-Helsinki) hinting at a more complex situation in which other drivers contributed to the emission reductions (further detail in Section 3. 3). When analysing all districts together (Fig. 3 ), a consistent and significant correlation between RFC and SI was found (slope = -0. 75, p < 0. 001). The average RFC during the LOCK period across all sites was Table 2 CO 2 relative flux change (RFC, %), calculated as the average percentage change between 2020 and previous years CO 2 daily fluxes. Minimum (min) and maximum (max) RFCs are calculated over all available years (Ny, excluding the 2020 and years with no data for the period of concern).
Acknowledgements G. N. and  S. Sa. thank the support of the  ICOS Ecosystem Thematic Centre. G. A. thanks the support of the  CHE H2020   Project  ( GA 776186 ). D. P. thanks the support of the " Departments of Excellence-2018" MIUR Program DIBAF "Landscape 4. 0 " and the  CoCO2 H2020 (GA 958927 ) projects. G. J. S. acknowledges the funding from the  Netherlands Organization for Scientific Research (NWO)   VIDI grant  " The Windy City " (file  864. 14. 007 ) and the funding from the  Amsterdam Institute for Metropolitan Solutions  for the AAMS observational network (Project  VIR16002 ). L. J. acknowledges the  Academy of Finland profiling action  (grant number  311932 ) and  CarboCity  project (grant number  321527 ). FI-Helsinki is a station part of the  ICOS network. N. C. thanks the support of the  Municipality of Heraklion  (Contract  105 ,  26/5/2020 ).
Data availability All the eddy covariance datasets used in the study are available in Figshare under CC-BY licence (DOI: https://doi. org/10. 6084/m9. figshare. 13686292), together with the buildings and road traffic daily emissions as estimated by the CarbonMonitor method. Other data that support the findings of this study are available at the following links: • Oxford COVID-19 Government Response Tracker (OxCGRT) data are available at https://www. bsg. ox. ac. uk/research/research-projects/ coronavirus-government-response-tracker#data • Urban Atlas 2012 data are available at https://land. copernicus. eu/local/ urban-atlas/urban-atlas-2012?tab=download • Google Community Mobility Reports data are available at https://www. google. com/covid19/mobility/index. html?hl=en.
Code availability Data in this study were analysed using R (R Core Team, 2019) version 3. 6. 2 (2019-12-12, Dark and Stormy Night) and RStudio (RStudio Team, 2021) version 1. 4. 1717 (Juliet Rose). The custom code used for the analysis is available at: https://github. com/Giacomo-Nicolini/UrbanFluxes_ COVID19.
Remote photoplethysmography (rPPG) aspires to automatically estimate heart rate (HR) variability from videos in realistic environments. A number of effective methods relying on data-driven, model-based and statistical approaches have emerged in the past two decades. They exhibit increasing ability to estimate the blood volume pulse (BVP) signal upon which BPMs (Beats per Minute) can be estimated. Furthermore, learning-based rPPG methods have been recently proposed. The present pyVHR framework represents a multi-stage pipeline covering the whole process for extracting and analyzing HR fluctuations. It is designed for both theoretical studies and practical applications in contexts where wearable sensors are inconvenient to use. Namely, pyVHR supports either the development, assessment and statistical analysis of novel rPPG methods, either traditional or learning-based, or simply the sound comparison of well-established methods on multiple datasets.
g. , medians), while controlling the confidence levels. Second, the framework is agile, covers each stage of the pipeline that instantiates it, and it is easily extensible. Indeed, one can freely embed new methods, datasets or tools for the intermediate steps (see section 'Extending the Framework') such as for instance: face detection and extraction, pre-and post-filtering of RGBs traces or BVPs signals, spectral analysis techniques, statistical methods. pyVHR can be easily employed for many diverse applications such as anti-spoofing, aliveness detection, affective computing, biometrics. For instance, in section 'Case Study: DeepFake detection with pyVHR' a case study on the adoption of rPPG technology for a Deepfake detection task is presented. Finally, computations can be achieved in real-time thanks to the NVIDIA GPU (Graphics Processing Units) accelerated code and the use of optimized Python primitives.
Related works In the last decade the rPPG domain has witnessed a flourish of investigations  (McDuff et al. , 2015; Rouast et al. , 2018; Heusch, Anjos & Marcel, 2017a; Unakafov, 2018; Wang et al. , 2016; McDuff & Blackford, 2019; Cheng et al. , 2021; McDuff, 2021; Ni, Azarang & Kehtarnavaz, 2021 ). Yet, the problem of a fair and reproducible evaluation has been in general overlooked. It is undeniable that theoretical evaluations are almost infeasible, given the complex operations or transformations each algorithm performs. Nevertheless, empirical comparisons could be very informative if conducted in the light of some methodological criteria  (Boccignone et al. , 2020a). In brief: pre/post processing standardization; reproducible evaluation; multiple dataset testing; rigorous statistical assessment.
To the best of our knowledge, a framework respecting all these criteria was missing until the introduction of the early version of pyVHR  Boccignone et al. (2020a). In  Heusch, Anjos & Marcel (2017a)  a Python collection of rPPG algorithms is presented, without claiming to be complete in the method assessment. Interestingly, in  Unakafov (2018) , the authors highlight the dependency of the pulse rate estimation on five main steps: ROI-selection, pre-processing, rPPG method, post-processing, pulse rate estimation. They present a theoretical framework to assess different pipelines in order to find out which combination provides the most precise PPG estimation; results are reported on the DEAP dataset  (Koelstra et al. , 2011). Unfortunately, no code has been made available. In  Pilz (2019)  a MATLAB toolbox is presented, implementing two newly proposed methods, namely Local Group Invariance (LGI)  (Pilz et al.
, 2018)  and Riemannian-PPGI (SPH)  (Pilz, 2019) , and comparing them to the GREEN channel expectation  (Verkruysse, Svaasand & Nelson, 2008)  baseline, and two state-of-the-art methods, i. e. , Spatial Subspace Rotation (SSR)  (Wang, Stuijk & De Haan, 2015) , and Projection Orthogonal to Skin (POS)  (Wang et al. , 2016). In  McDuff & Blackford (2019)  the authors propose iPhys, a MATLAB toolbox implementing several methods, such as Green Channel, POS, CHROM  (De Haan & Jeanne, 2013) , ICA  (Poh, McDuff & Picard, 2010) , and BCG  (Balakrishnan, Durand &   Guttag, 2013). The toolbox is presented as a bare collection of method implementations, without aiming at setting up a rigorous comparison framework on one or more datasets. It is worth noticing that all these frameworks are suitable for traditional methods only.
INSTALLATION The quickest way to get started with pyVHR is to install the miniconda distribution, a lightweight minimal installation of Anaconda Python. Once installed, create a new conda environment, automatically fetching all the dependencies based on the adopted architecture-with or without GPU-, by one of the following commands: for a CPU architecture with GPU support. The latest stable release build of pyVHR can be installed, inside the newly created conda environment, with: 1 $ pip install pyvhr -cpu for CPU-only, or 1 pip install pyvhr for CPU with GPU support. The source code for pyVHR can be found on GitHub at https://github. com/phuselab/ pyVHR and it is distributed under the GPL-3. 0 License. On GitHub, the community can report issues, questions as well as contribute with code to the project.
The pipeline Stages The Pipeline() class implements the sequence of stages or steps that are usually required by the vast majority of rPPG methods proposed in the literature, in order to estimate the BPM of a subject, given a video displaying his/her face. Eventually, going through all these steps in pyVHR is as simple as writing a couple of lines of Python code: 1 from pyVHR. analysis. pipeline import Pipeline Calling the run_on_video() method of the Pipeline() class starts the analysis of the video provided as argument and produces as output the time step of the estimated BPM and related uncertainty estimate. Figure  1  depicts the predicted BPM on Subject1 of the UBFC 2  dataset  (Bobbia et al. , 2019)  (blue trajectory). For comparison, the ground truth BPM trajectory (as recorded from a PPG sensor) is reported in red.
On the one hand the above-mentioned example witnesses the ease of use of the package by hiding the whole pipeline behind a single function call. On the other hand it may be considered too constraining as hinders the user from exploiting its full flexibility. Indeed, the run_on_video() method can be thought of as a black box delivering the desired result with the least amount of effort, relying on default parameter setting. Nevertheless, some users may be interested in playing along with all the different modules composing the pyVHR pipeline and the related parameters. The following sections aim at describing in detail each of such elements. These are shown in Fig. 2B  and can be recapped as follows: 1. Skin extraction: The goal of this first step is to perform a face skin segmentation in order to extract PPG-related areas; the latter are subsequently collected in either a single patch (holistic approach) or a bunch of ''sparse'' patches covering the whole face (patch-wise approach).
An example is shown in the left image of Fig. 3  on a subject of the LG-PPGI dataset  (Pilz et al. , 2018). 3 lternatively, the Face parsing extractor computes a semantic segmentation of the subject's face. It produces pixel-wise label maps for different semantic components (e. g. , hair, mouth, eyes, nose, c. ), thus allowing to retain only those related to the skin regions. Face semantic segmentation is carried over with BiSeNet  (Yu et al. , 2018).
A review of the principles/assumptions behind each of the implemented algorithms is out of the scope of the present work. The interested reader might refer to  Wang et al. (2016 ), McDuff et al. (2015)  and  Rouast et al. (2018). Currently, the package implements the following methods for the estimation of the pulse signal from the RGB traces: GREEN  (Verkruysse, Svaasand & Nelson, 2008) ,  CHROM (De Haan & Jeanne, 2013) , ICA  (Poh, McDuff & Picard, 2010) , LGI  (Pilz et al. , 2018) ,  PBV (De Haan & Van Leest, 2014) , PCA  (Lewandowska et al. , 2011) , POS  (Wang et al. , 2016) , SSR  (Wang, Stuijk & De Haan, 2015). However, the user may define any custom method for estimating BVP by extending the pyVHR. BVP. methods module. The BVP signal can be estimated in pyVHR as follows: 1 bvp = RGB_sig_to_BVP ( windowed_sig , fps , method = cpu_POS ).
Efficient computation and GPU acceleration Most of the steps composing the pipeline described above are well suited for parallel computation. For instance, the linear algebra operations involved in the pulse signal recovery from the RGB signal or, more generally, the signal processing steps (e. g. , filtering, spectral estimation, etc. ), not to mention the skin segmentation procedures from high resolution videos. To such end, pyVHR exploits the massive parallelism of Graphical Processing Units (GPUs). It is worth mentioning that GPUs are not strictly required to run pyVHR code; nevertheless, in some cases, GPU accelerated code allows to run the pipeline in real-time. Figure  10  shows the average per-frame time requirement for getting through the whole pipeline when using the POS method. It is worth noticing that, when using the Holistic approach (or equivalently one single patch), a video frame can be processed in less than 0.
GUI for online processing Besides being used as a Python library, pyVHR makes available a Graphical User Interface (GUI). It provides access to most of the available functionalities, while showing the BPMs estimation process in real-time. It is straightforward to use and it allows for setting up the pipeline parameters and the operating mode, by choosing either a webcam or a video file. To start the GUI, one can run the command: 1 $ Python pyVHR / realtime / GUI. py Figure  11  shows a screenshot of the GUI during the online analysis of a video. On the top right are presented the video file name, the video FPS, resolution, and a radio button list to select the type of frame displayed. The original or segmented face can be visualized either selecting the Original Video or the Skin option, while the Patches radio button enables the visualization of the patches (in red).
It essentially leverages a tensor-shift module and 2D-convolutional operations to perform efficient spatial temporal modeling in order to enable real-time cardiovascular and respiratory measurements. MTTS-CAN can be framed as an endto-end model since it does not need any pre-processing step before data is fed into the network, except performing trivial image normalizations. MTTS-CAN is included in the pyVHR framework, and below it is shown how practical is to extend the framework with similar DL-based approaches provided that the pre-trained model is available. As for the pipeline for traditional methods shown in previous section, pyVHR also defines a sequence of stages that allows to recover the time varying heart rate from a sequence of images displaying a face. These are detailed in the following.
For instance, consider the MTTS-CAN model currently embedded into the DeepPipeline() class; it estimates the rPPG pulse signal from which the BPM computation can be carried out by following the very same procedure outlined in section 'From BVP to BPM', namely time windowing and spectral estimation. Eventually, some optional pre/post filtering operations (section 'Pre and Post-Filtering') can be performed. The following few lines of Python code allow to carry out the above steps explicitly: In order to embed a new DL-method, the code above should be simply modified substituting the function MTTS_CAN_deep with a new one implementing the method at hand, while respecting the same signature (cfr. 'Extending the Framework').
Does a given rPPG algorithm outperforms the existing ones? To what extent? Is the difference in performance significantly large? Does a particular post-filtering algorithm cause an increase/drop of performance? Answering all such questions, calls for a rigorous statistical assessment of rPPG methods. As a matter of fact, although the field has recently experienced a substantial gain in interest from the scientific community, it is still missing a sound and reproducible assessment methodology allowing to gain meaningful insights and delivering best practices. By and large, novel algorithms proposed in the literature are benchmarked on nonpublicly available datasets, thus hindering proper reproducibility of results. Moreover, in many cases, the reported results are obtained with different pipelines; this makes it difficult to precisely identify the actual effect of the proposed method on the final performance measurement.
The design principles can be recapped as follows: • Standardized pipeline: When setting up an experiment to evaluate a new rPPG algorithm, the whole pipeline (except the algorithm) should be held fixed. • Reproducible evaluation: The evaluation protocol should be reproducible. This entails adopting publicly available datasets and code. • Comparison over multiple datasets: In order to avoid dataset bias, the analysis should be conducted on as many diverse datasets as possible. • Rigorous statistical assessment: The reported results should be the outcome of proper statistical procedures, assessing their statistical significance. The workflow of the Statistical Assessment Module is depicted in Fig. 12. In a nutshell, each video composing a particular rPPG dataset is processed by the pyVHR pipeline as described above.
Methods. It allows to configure each rPPG method to be analyzed (e. g. , eventual parametrs and pre/post filters). The two methods above are configured here. In particular, POS will not employ any pre/post filtering, while for the GREEN method, the above-defined band pass filter will be applied for both pre and post filtering. The experiment on the dataset defined in the. cfg file can be simply launched as: 1 from pyVHR. analysis. pipeline import Pipeline 2 3 pipe = Pipeline () 4 results = pipe. run_on_dataset ( '/ path / to / config. cfg ') 5 results. saveResults ( " / path / to / results. h5 " ) In the above code, the run_on_dataset method from the Pipeline class, parses the. cfg file and initiates a pipeline for each rPPG method defined in it. The pipelines are used to process each video in the dataset.
Concurrently, ground truth BPM data is loaded and comparison metrics are computed w. r. t. the predictions (cfr. Figure  12 ). The results are delivered as a table containing for each method the value of the comparison metrics computed between ground truth and predicted BPM signals, on each video belonging to the dataset, which are then saved to disk. The same considerations hold for the definition of. cfg files associated to DL-based methods. Clearly, in this case the information related to the RGB Signal block are unnecessary.
In the case of multiple comparisons (ANOVA/Friedman), a proper post-hoc analysis is required in order to establish the pairwise differences among the pipelines. Specifically, the Tukey post-hoc Test is adopted downstream to the rejection of the null hypothesis of ANOVA (the means of the populations are equal), while the Nemenyi post-hoc Test is used after the rejection of the Friedman's null hypothesis of equality of the medians of the samples. Besides the significance of the differences, it is convenient to report their magnitude, too. The effect size can be computed via the Cohen's d in case of Normal of populations; the Akinshin's γ is used otherwise. The two populations case pyVHR automatically handles the above significance testing procedure within the StatAnalysis() class, by relying on the Autorank Python package  (Herbold, 2020).
The box-plots showing the distributions of CCC values for all methods on the UBFC dataset is provided in Fig. 13 , while the output of the post-hoc Nemenyi test can be visualized through the Critical Difference (CD) diagram  (Demšar, 2006)  shown in Fig. 14 ; CD Diagrams show the average rank of each method (higher ranks meaning higher average scores); models whose difference in ranks does not exceed the CD α (α = 0. 05) are joined by thick lines and cannot be considered significantly different.
Comparing deep and traditional pipelines How does a given DL-based rPPG method compares to the above mentioned traditional approaches? The following code snippet allows to run both the traditional and deep pipelines. The results are saved to the same folder, which is then fed as input to the StatAnalysis class; the join_data =True flag allows to merge the results yielded by the two pipelines, thus enabling the statistical comparison between the chosen methods. In this case, the Signal-to-Noise Ratio (SNR) has been chosen as comparison metric; Fig. 15  qualitatively displays the results of the comparison of the above mentioned traditional methods with the MTTS-CAN DL-based approach  (Liu et al. , 2020). The outcome of the statistical assessment is shown in the CD diagram of Fig. 16.
EXTENDING THE FRAMEWORK Besides assessing built-in methods on public datasets included in the framework, the platform is conceived to allow the addition of new methods or datasets. This way, it is possible to assess a new proposal, comparing it against built-in methods, and testing it on either already included datasets or on new ones, this exploiting all the pre-and postprocessing modules made available in pyVHR. The framework extension can be achieved following simple steps as described in the subsequent subsections.
Adding a new dataset Currently pyVHR provides APIs for handling five datasets commonly adopted for the evaluation of rPPG methods, namely LGI-PPGI  (Pilz et al. , 2018) , UBFC  (Bobbia et al. , 2019) , PURE  (Stricker, Müller & Gross, 2014) , MAHNOB-HCI  (Soleymani et al. , 2011) , and COHFACE  (Heusch, Anjos & Marcel, 2017a). However, the platform allows to add new datasets favoring the method assessment on new data. A comprehensive list of the datasets that are typically employed for rPPG estimation and evaluation is reported in Table  3. The framework conceives datasets as a hierarchy of classes (see Fig. 17 ) that allows to describe a new dataset by inheriting from the Dataset base class and implementing few methods for loading videos and ground truth PPG data. Specifically, the following two functions should be supplied: • a loadFilenames() function to load video files in a Python list; this function has no inputs and defines two class variables, namely videoFilenames and BVPFilenames.
These are both Python lists containing, respectively, video and ground-truth BVP filenames from the dataset); • a readSigfile(filename) function loading and returning the ground-truth BVP signal given a video filename. The new dataset can then be included in the testing via the. cfg file as described in the paragraph Dataset of section 'The configuration (. cfg) file'. As for the addition of new method, also in case of adding a new dataset the. cfg file should be completed by specifying the path pointing to the new dataset class:    (Estepp, Blackford & Meier, 2014)  25 Multiple × MMSE-HR  (Zhang et al. , 2016)  140 Simulating facial expressions × OBF  (Li et al. , 2018)  106 Multiple × VIPL-HR  (Niu et al. , 2018)  107 Multiple × ECG-Fitness  (Špetlík, Franc & Matas, 2018)  17 Physical activities ×.