dataesr/scientific-paragraphs-categorization huggingface dataset:
Implementation details We implement TasselNetv2 based on MatConvNet  [35]. During training, we use 1359 images in the training and validation sequences of the WSC dataset. 90% images are randomly chosen for training, while the rest Fig. 6  The structure of TasselNet, TasselNet added context and TasselNetv2. All of the networks adopt AlexNet-like architectures. The definition of the convolutional and pooling layers is in the format: fliter size + layer name, number of channels, padding, /stride. Fully connected layers are defined in the format: layer name, number of nodes. The different settings are highlighted in red for validation. Before learning, mean subtraction is preprocessed (the mean is computed from the training set). It is worth mentioning that, no data augmentation is performed because the WSC dataset already contains wheat spikes under various scenarios.
We initialize networks with the improved Xavier method  [36]. The standard stochastic gradient descent is applied to optimize the parameters of the network. The learning rate is initially set to 0. 1 and is decreased when the training error stagnates. To speed up and stabilize the error convergence process, a batch normalization layer  [37]  is attached after each convolutional layer before ReLU. The training time of TasselNetv2 on the WSC dataset varies from 4 h to 2 days depending on the network architecture used (4 hours for the Alex-like architecture, and 2 days when the pretrained VGG-16 is used). When training TasselNet on the WSC dataset, the training time varies between 4 days and 2 weeks according to the network capacity used (Matlab 2017a, OS: Window10 Home 64-bit, CPU: Intel i7-7700 3.
Results and discussion Extensive experiments are conducted to demonstrate the effectiveness and efficiency of TasselNetv2. First, we perform experiments on the WSC dataset to search optimal hyper parameters. After obtaining these, we verify the effect of adding context in TasselNetv2. Next, Tas-selNetv2 is further compared against other state-of-theart approaches on the WSC dataset. To demonstrate the generality of TasselNetv2, we also evaluate it on the MTC  [9]  and ShanghaiTech datasets  [5]. Mean absolute error (MAE) and root mean squared error (RMSE) are chosen to quantify the counting performance. They are defined as (1) MAE = 1 N N i=1 C pre i -C gt i , ( ) RMSE = 1 N N i=1 C pre i -C gt i 2 , 2 where N denotes the number of images, C pre i denotes the predicted count of the i-th image, and C gt i denotes the corresponding ground-truth count.
Searching optimal parameters Since TasselNet is the direct baseline of TasselNetv2, we set the hyper parameters of TasselNetv2 same as the Tas-selNet, in order to demonstrate the superiority of Tas-selNetv2 w. r. t. TasselNet and the benefit of embedding context information. Hence, we first search the optimal parameters on the WSC dataset using TasselNet so that TasselNet can report the optimal performance, and we then apply the same parameters to TasselNetv2. Through extensive experiments, the optimal setting of hyper parameters for TasselNet on the WSC dataset is summarized in Table  4. Detailed procedures of searching optimal parameters are provided in Additional file 1.
Comparison with state of the art According to the above evaluations, the optimal setting on the WSC dataset is shown in Table  4. Next, to compare TasselNetv2 with other state-of-the-art methods, several well-established baselines are chosen: • Segmentation method in  [13] : This is the latest counting by segmentation method specially designed  to count wheat spikes in the field. It first applies Laplacian frequency filtering to remove background, then utilizes the median filter to eliminate noise, and finally, finds the maximal to split individual wheat spikes; • Density map regression methods: CCNN  [6]  and MCNN  [5]  are two typical counting-by-regression methods, which aim to regress pixel-wise density maps. Their parameters are of the same order of magnitude as TasselNetv2. CSRNet  [23]  represents the state-of-the-art crowd counting approach and is composed of a much deeper CNN (pretrained VGG16) as the front-end used for feature extraction.
For a fair comparison, we replace the feature extractor in TasselNetv2 (the first 5 convolutional layers) with all convolutional layers in VGG16  [40]  and mark it as TasselNetv2 †. More details about TasselNetv2 † can be found in Additional file 1. • Local count regression method: TasselNet  [9]  regresses the local counts rather than density maps. This is our direct baseline and the most closelyrelated approach. A brief introduction to TasselNet can also be found in Additional file. Results are listed in Table  7. We can make the following observations: • Segmentation method in  [13]  works poorly on the WSC dataset (317. 19 MAE). Due to heavy dependency on the color information, this method is very sensitive to the illumination that significantly changes the color attributes. This also implies the problem of counting wheat spikes in the field-based environment cannot be addressed just by segmentation.
Evaluation on the MTC dataset To show that TasselNetv2 is a generic object counting method, particularly for the application in the agriculture scenario. We further evaluate the effectiveness of TasselNetv2 on the Maize Tassels Counting (MTC)  [9]  dataset, following the same setting as  [9]. Detailed results are shown in Table  8. TasselNet currently represents the state-of-theart approach on the MTC dataset. According to the results, we found that TasselNetv2 outperforms Tas-selNet and further reduces the counting error by 18. 2% (5. 4 MAE versus 6. 6 MAE). The context is also an important factor for maize tassels. With a pre-trained model, TasselNetv2 † only performs slightly better than TasselNetv2 but increases more than an order of magnitude of parameters. We conjecture the main reason is the lack of training samples in the MTC dataset (only 186 training images).
Evaluation on the ShanghaiTech dataset We further evaluate TasselNetv2 on the ShanghaiTech dataset  [5]  to see its generality to crowd counting, following the same experimental setting in  [5]. Results are listed in Table  9. On both the part A and part B subsets, the benefit of adding the context can be reflected when comparing TasselNetv2 with TasselNet, but the improvement is marginal. When using a pre-trained VGG-16 model, Tas-selNetv2 † outperforms CSRNet and reaches the state-ofthe-art performance. This suggests pre-trained models is necessary to fully exploit the benefit of context on the ShanghaiTech dataset.
Some failure cases Figure  10  shows some qualitative results of TasselNetv2 on the WSC dataset. In most cases, TasselNetv2 predicts accurate counts (the first four rows). However, it exposes prominent under-estimate phenomena in some cases, particularly when severe overlapping and heavy blurring occur. These visual patterns raise a huge challenge to discriminate spikes even for a human expert. Efforts still should be paid to overcome these challenges. We leave this for future explorations.
Conclusions In this work, we addressed an important and practical problem of counting wheat spikes in the field-based environment using computer vision. We observe that, some existing CNN-based local regression models, such as TasselNet, suffer from the problem of lacking contextual information, so they usually cannot predict correct counts when objects partially present in local image patches. By integrating the context into the framework of the TasselNet, we proposed a simple but effective extension, i. e. , TasselNetv2. A large-scale WSC dataset, with 1, 764 images and 675, 322 annotated wheat spikes, is also created. The dataset is very challenging due to intrinsic and extrinsic variations not only in spikes per se but also in environment, which makes it appropriate to be used as a benchmark for counting non-rigid objects.
Extensive experiments illustrate that, TasselNetv2 achieves state-of-the-art performance on the WSC dataset with 91. 01% relative counting accuracy, and is also more than an order of magnitude faster than Tas-selNet. Further evaluations on the MTC and Shangha-iTech datasets demonstrate that TasselNetv2 can also push forward the state of the art. Sufficient analyses of potential issues effecting the practical application of TasselNetv2 are also described, including emphasizing the role of the context in object counting, searching  optimal parameters for local counts regression, and analyzing potential errors. We believe TasselNetv2 shows great potentials to be applied to other object counting domains. Albeit empirically effective, the reason why the context can improve the counting performance only stays at an intuitive level, and it remains unclear how the context interacts with the central receptive field as auxiliary information.
A LabVIEW field programmable gate arrays (FPGAs)-based bump-in-the-wire (BITW) secure core is used to provide an AES (advanced encryption standard)-enabled security feature on the video stream of an IoVT node (ROV equipped with a live-feed camera). The designed LabVIEW-based software architecture provides an option to enable/disable the AES encryption for the video transmission. The latency effects of embedding encryption on the stream with real-time constraints are measured and presented. It is found that the encryption mechanism used does not greatly influence the video feedback performance of the observed IoVT node, which is critical for real-time secure video communication for ROV remote control and piloting. The video latency measurement results are taken using 128, 256 and 512 bytes block lengths of AES for both H.
The work of this paper mainly involves secure and unsecure video latency measurement over the Internet. As mentioned above, the target application is marine, which involves the remote control of an ROV from a control station. The encryption level security is implemented using a previously published AES  [14]  algorithm implementation on FPGA  [15, 16] , where AES is implemented on a traditional FPGA and then imported into LabVIEW FPGA to use with a developed LabVIEW application for video latency measurement. The AES security feature is controlled using the enable/disable option in the LabVIEW software. The structure of the target application is shown in Figure  1. It depicts the remote control station and the robot deployment location as two main components of the system. The two locations can be connected either through a LAN or through the Internet.
Encryption of the video stream data has been an active field of research for a long time. The IoVT technology increased the number of video streaming devices on the Internet, which in turn increases the necessity for having high quality security solutions. Existing video encryption solutions differ based on the amount of video stream data that actually gets encrypted. On this basis, there are partial and full video encryptions. With partial techniques, encryption is conducted on part of the data necessary for scrambling the video and making it worthless without decrypting. A full video encryption technique implies encryption of the complete content of the video stream, making it more secure, but at the same time the process of full encryption requires more processing power. Full encryption can be realized by using two techniques called homomorphic and invariant encryption  [37].
The encryption was implemented for the purpose of testing and analysing the performance of different ECC curves, which were then compared with the performance of AES-encrypted and non-encrypted video streams in streaming applications. Real-time is defined as continuous flow of the media stream over the Internet where the content is presented before it has been downloaded completely. End-to-end delay, jitter, packet loss, encryption and decryption times and data rates were measured and the results were analysed for a total of 18 tested curves and for the case with no encryption. All tests were conducted on an institutional LAN (local area network) and by using MJPEG for encoding the video. The RTSP (real-time streaming protocol)  [44]  was used for transferring the video and full encryption of the video stream data was conducted.
The presented end-to-end delay values do not exceed 10 ms for any curve. The encryption time of AES was found to be in sub-millisecond range. It is worth noting that in the paper there are no details about the technique used for delay measurement. The encryption technique presented in Ref. [45]  was applied to video stream data and transferred over the Internet using software designed to support video and network latency measurement. The stream was encrypted by using the efficient high speed AES algorithm, which is considered to be the most suitable for encryption of the real-time video in terms of speed and frame size overhead  [46]. The algorithm is implemented on a LabVIEW FPGA platform  [14]. Implementation of the algorithm on hardware is mandatory for real-time performance of the encryption, especially in the case of full video stream encryption.
The proposed architecture is based on the video server component described in  [12] , which was upgraded with applications, which are able to run on platforms with NI Linux RTOS (real-time operating system)  [47]. In addition, the modules which perform the encryption/decryption and have to be executed on the FPGA platform were also integrated into the software of  [12]. The major applications were developed in LabVIEW, while video decoding was performed by a third party component called FFmpeg  [48]  (version 4. 0 built by gcc (GNU Compiler Collection) 7. 3. 0). As shown in Figure  2 , the architecture consists of the following nodes: • Timestamp Sender • Camera Server • Encrypt/Decrypt Applications • Camera Client • Latency Measurement. Timestamp sender and latency measurement applications screenshots of Figure  2  are presented in Figure  3.
In terms of protocol type, there are two possible choices: UDP and TCP. This option modifies the way video data is streamed from the IP camera to the latency measurement node. When UDP is selected, all channels (both TCP and UDP) shown in Figure  2  are used. In this case, all video stream data are transferred over the UDP while TCP is used only for sending RTSP protocol packets. When TCP is selected all data is transferred over TCP connection only, greyed out UDP channels in Figure  2  are not used in this case. The encryption string length denotes the maximum amount of data which can be encrypted/decrypted at once. For this we used three sets of strings; 128 bytes, 256 bytes and 512 bytes. Additionally, there are two options available to select the encoding algorithm (i. e. , MJPEG or H264).
Encoding of the data was done by the IP camera, while the stream was decoded in the latency measurement application utilizing the FFMPEG library. Timestamp sender and latency measurement applications screenshots of Figure  2  are presented in Figure  3. The latency measurement application is the starting point for running of all tests (all other applications must be in running mode before executing this application). The purpose of this application is to initiate communication with other applications, which should result in receiving the IP camera video stream. Other applications from Figure  2  serve as clients/servers for parsing the data, encrypting/decrypting the stream when necessary and for providing reference time for latency measurement (timestamp sender). The main functionalities of the latency measurement application are: decode video and measure video latency.
Timestamp Sender Timestamp Sender is used for generating a visual event, which is captured by the camera's sensor. Each event is accompanied with the data containing the timestamp of the event and event ID. The event ID is a number which is incremented for each generated event. This number is displayed in the application window which is captured by the IP camera. The purpose of the event ID is to indicate the quality of the video for the end user. The timestamp is captured from windows system time with 1 ms resolution. The application acts as a server in a way that keeps a pre-defined UDP.
Timestamp Sender Timestamp Sender is used for generating a visual event, which is captured by the camera's sensor. Each event is accompanied with the data containing the timestamp of the event and event ID. The event ID is a number which is incremented for each generated event. This number is displayed in the application window which is captured by the IP camera. The purpose of the event ID is to indicate the quality of the video for the end user. The timestamp is captured from windows system time with 1 ms resolution. The application acts as a server in a way that keeps a pre-defined UDP port open for client registration. Any client that sends a request packet to the port will be registered and will keep receiving the visual event data periodically. The described functionality is shown in Figure  4.
It is worth noting that video data are encoded by either H264 or MJPEG encoding algorithms and this process is done by the IP camera before the transmission of the data to server application. Depending on the desired transport protocol for video data transfer (TCP or UDP), the stream can be transferred over the same TCP connection on which RTSP was initiated or it can be transferred over a UDP port, which needs to be negotiated in the RTSP initialization procedure. The application node is organized in two threads as can be seen in Figure  5. One thread is responsible for parsing the RTSP protocol while another thread is used for manipulation of video data. Once the stream commences, the data packets sent from the camera are accepted by the application and are reorganized into chunks of 128, 256 or 512 Bytes (Step 1), depending on data length encryption settings.
After that, the packet is forwarded to the FPGA application node, which performs data decryption (Step 2). When the FPGA finishes decryption and decrypted data is read by the client application (Step 3), the network latency is calculated by subtracting the timestamp, captured from the real-time operating system time after decryption is completed (Step 4) from the timestamp, which arrived together with the data packet (extracted in Step 1). The calculated network latency is logged to file on the real-time target (Step 4). In Step 5, the decrypted video data is forwarded to the main application. It is worth noting that the data after decryption is again encoded with H264 or MJPEG algorithms (depending on the video source encoding type).
Latency Measurement This application node is responsible for various important functionalities, which include connection to the camera client, the starting sequence of RTSP packets, accepting and decoding video data, detecting events in the video and calculating the video latency. The latency measurement node also registers to the timestamp sender application node in order to be able to receive event ID and timestamp data, based on which the video latency is calculated. A pre-built FFmpeg library was used for handling the RTSP and decoding of the video. The image processing and event detection is done by utilizing the NI vision development module. As illustrated in Figure  8 , the application is organised in four threads. The first thread utilises a pre-built FFMPEG library for starting the RTSP sequence and for decoding the video data.
The output of Thread 1 is a sequence of images, which are fed to Thread 2. Data transfer between the threads is The first step after receiving a fixed size data packet from the server is to the extract timestamp information from the packet (Step 1). After that, the packet is forwarded to the FPGA application node, which performs data decryption (Step 2). When the FPGA finishes decryption and decrypted data is read by the client application (Step 3), the network latency is calculated by subtracting the timestamp, captured from the real-time operating system time after decryption is completed (Step 4) from the timestamp, which arrived together with the data packet (extracted in Step 1). The calculated network latency is logged to file on the real-time target (Step 4). In Step 5, the decrypted video data is forwarded to the main application.
The output of Thread 1 is a sequence of images, which are fed to Thread 2. Data transfer between the threads is done by using queues in order to ensure that no data will be lost during the transfer. Thread 2 applies the IMAQ colour learn  [51]  function from the NI vision development module to each image in the sequence. The function outputs an image colour spectrum which contains the colour features present in the image. Whenever a visual event (which was generated by the timestamp sender application) is detected, the associated timestamp is captured and Thread 3 is notified. This thread is responsible for calculating the video latency, which is done by subtracting the timestamp at the moment the visual event was detected from the timestamp at the moment the same event was generated. The thread also logs the calculated latency data to a file.
Test Configurations The proposed architecture presented in Section 4 can be employed with all components within a LAN or it can be used over the Internet. A configuration of the measurement system, when components are connected over the Internet is shown in Figure  9. The components inside each LAN are connected by Gigabit Ethernet. As well as PCs, an IP camera and NTP servers, there are also two devices which feature on-board real-time processor and FPGA chips. The devices are of type cRIO-9034 from National Instruments with Intel Atom E3845 CPU running the 64-bit NI Linux real-time operating system. The on-board FPGA chip is of type Xilinx Kintex-7 7K325T and is connected to the CPU by PCI bus. As Figure  9  shows, nodes for data encryption and decryption run on the FPGA, while the camera server and camera client nodes run on the real-time processor.
Having larger chunks of data is beneficial because of the issue known as the "small-packet problem" for UDP. The TCP protocol implements Nagle's algorithm which deals with the problem by buffering packets and sending several small packets as one  [52]. The equipment configuration, shown in Figure  9 , is used for testing in the non-symmetrical scenario. Here, the camera client and decrypt application nodes run on a NI myRIO, while the camera server and encrypt application nodes run on a NI cRIO (compactRIO) device, and only a 128 byte string length is used due to the limits of the FPGA chip area in the NI myRIO. It is worth noting that part of the setup used in this scenario was located in Limerick (IP camera and cRIO), while the other part was located in Sarajevo (myRIO). Video latency measurement results are shown in Figure  17 , while network latency measurements are shown in Figure  18.
As mentioned earlier, the lowest video latency obtained here was in Case 4 (without encryption) and it had the value of 586. 16 ms. The lowest secure video latency measured was in Case 12 (i. e. , 724. 86 ms). The lowest value of latency for secure and unsecure video were obtained using the combination of MJPEG and UDP. These two cases differ in the length of the encrypted data string. Case 4 pertains to 128 bytes string length and Case 12 is conducted with encryption string length of 512 bytes. When comparing the results presented in this paper to the results published in Ref. [12] , it is noticeable that relations between cases with different options are kept the same in this paper. H264 encoding still results in greater video latency than MJPEG. In terms of the underlying protocol for transporting the video, an observation can be made that cases with the TCP protocol result in higher latency values than cases with UDP.