Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
13
datasets available to search
ShareScore release 0.7.1
Dataset results
13 results for “cloud understanding”
Balloon-borne Aerosol-Cloud Interaction Studies (BACIS): Field campaigns to understand and quantify aerosol effects on clouds
<p>The dataset uploaded on Zenodo consists of in-situ measurements from specialised balloon borne sondes used in the field campaign named BACIS (Balloon borne Aerosol Cloud Interaction Studies) conducted from Gadanki, a location in Southern Peninsular India. Note that raw data from the observations is only uploaded here. There is lot more post processing of data carried out during our analysis for brining out meaningful data. Hence the users are cautioned in using the raw data for analysis and kindly advised to approach us for the post processed, quality controlled data. </p>
Data from the NASCENT campaign used in the publications: "Conditions favorable for secondary ice production in Arctic mixed-phase clouds" and "Understanding the history of two complex ice crystal habits deduced from a holographic imager"
<p>This repository contains the data from the Ny‐Ålesund AeroSol Cloud ExperimeNT campaign (NASCENT). This data were used to produce the figures in the two papers:</p> <p>(1) Pasquier, J. T., Henneberger, J., Ramelli, F., Korolev, A.,Wieder, J., Lauber, A., Li, G., David, R. O., Carlsen, T., Gierens, R., Maturilli, M., and Lohmann, U.: Understanding the history of two complex ice crystal habits deduced from a holographic imager, Geophys. Res. Lett., accepted, 2022</p> <p> </p> <p>(2) Pasquier J. T., Henneberger J., Ramelli F., Lauber A., David O. D., Wieder J., Carlsen T., Gierens R., Maturilli M., and Lohmann U.:Conditions favorable for secondary ice production in Arctic mixed-phase clouds, ACP, accepted.</p> <p>More information can be found in the README files.</p> <p> </p> <p>The scripts to reproduced the Figures are available on Zenodo</p> <p>(1) https://doi.org/10.5281/zenodo.7402296</p> <p>(2) https://doi.org/10.5281/zenodo.7407107</p>
Understanding cirrus clouds using explainable machine learning
<p>This repository contains the data for the paper:</p> <p>Authors: Kai Jeggle , David Neubauer , Gustau Camps-Valls and Ulrike Lohmann<br> Titel: Understanding cirrus clouds using explainable machine learning<br> Date: 2023</p> <p>Note that the scripts can be found in the accompanying package (https://github.com/tabularaza27/explaining_cirrus)</p>
Digital Twin Technologies Towards Understanding the Interactions between Transportation and other Civil Infrastructure Systems: LIDAR Point Cloud of a Portion of UTEP Campus
<p>This Autodesk ReCap file is a combination of numerous individual LiDAR scans captured using a Leica Terrestial LiDAR system. The scan includes some black and white and some color scans. The area of campus generally focuses on the southwestern portion of campus including the Interdisciplinary Research Building, the Mining Minds roundabout, the Sun Bowl 2 Parking Lot, the University Bookstore, and the Sun Bowl Parking Garage, and roads including University Ave. and Sun Bowl Drive.</p>
Artifacts of Paper "Understanding and Discovering Software Configuration Dependencies in Cloud and Datacenter Systems"
<p>This package contains all the artifacts (i.e. codes & datasets) we use in our paper "Understanding and Discovering Software Configuration Dependencies in Cloud and Datacenter Systems" accepted to FSE 2020.</p>
Understanding the Energy Consumption of Cloud-native Software Systems
<p>These artifacts contain the dataset generated in the paper "Understanding the Energy Consumption of Cloud-native Software Systems". The dataset contains resource utilisation, power consumption, estimated power consumption and load metrics for a cloud-native software system. The test setup is consists of 6 machines running an OpenStack cluster. This OpenStack cluster is running 12 virtual machines that are in turn hosting a Kubernetes cluster. Performance and (estimated) power consumption are measured on all levels of the system.</p> <p>The Bare-Metal (BM) and Virtual Machines (VM) are identified by their IP addresses. For BM the IP mapping is as follows:</p> <ul> <li>192.168.1.109 - i3-04</li> <li>192.168.1.110 - i3-02</li> <li>192.168.1.111 - i5-02</li> <li>192.168.1.112 - i3-01</li> <li>192.168.1.113 - i5-01</li> <li>192.168.1.114 - i5-04</li> </ul> <p>For VM the IP mapping is:</p> <ul> <li>192.168.1.190 - kubernetes-agent-7</li> <li>192.168.1.191 - kubernetes-agent-6</li> <li>192.168.1.192 - kubernetes-agent-10</li> <li>192.168.1.194 - kubernetes-master</li> <li>192.168.1.196 - kubernetes-agent-3</li> <li>192.168.1.197 - kubernetes-agent-1</li> <li>192.168.1.198 - kubernetes-agent-2</li> <li>192.168.1.201 - kubernetes-agent-4</li> <li>192.168.1.203 - kubernetes-agent-9</li> <li>192.168.1.204 - kubernetes-agent-5</li> <li>192.168.1.207 - kubernetes-agent-8</li> <li>192.168.1.209 - kubernetes-agent-11</li> </ul> <p>The VMs are deployed on the BMs as follows:</p> <ul> <li>i3-01 <ul> <li>kubernetes-agent-2</li> <li>kubernetes-agent-8</li> </ul> </li> <li>i3-02 <ul> <li>kubernetes-agent-1</li> <li>kubernetes-agent-6</li> </ul> </li> <li>i3-04 <ul> <li>kubernetes-agent-10</li> <li>kubernetes-agent-11</li> </ul> </li> <li>i5-01 <ul> <li>kubernetes-agent-3</li> <li>kubernetes-agent-5</li> </ul> </li> <li>i5-02 <ul> <li>kubernetes-master</li> <li>kubernetes-agent-7</li> </ul> </li> <li>i5-04 <ul> <li>kubernetes-agent-4</li> <li>kubernetes-agent-9</li> </ul> </li> </ul> <p>Note that the following BMs are excluded from the experiments as they have other roles in the cluster and do not run workloads:</p> <ul> <li>i3-03 (Juju - deploying OpenStack on BM nodes)</li> <li>i3-05 (ProxMox - external observability tools that do not run in the cluster)</li> <li>i5-03 (MAAS - provisioning of BM nodes)</li> </ul> <h1>Data Sets</h1> <p>The artifacts consists of 3 separate data sets: <code>constant</code>, <code>direct</code> and <code>linear</code>, corresponding to the respective load profile applied to the SUT as discussed in the paper. Each data set contains the same metrics, but the system is put under a different load.</p> <p>Every experiment is repeated 3 times. All 3 repetitions are included in the data set. The data is collected using Prometheus and stored in JSON files.</p> <p>For the <code>constant</code> and <code>linear</code> data sets, load is applied by deploying the "OpenTelemetry demo application", and sending automated user requests to the application. For the <code>direct</code> dataset, this application is not used and instead Kubernetes pods are created that apply a constant load to the cluster.</p> <p>The timestamps of the experiments are as follows:</p> <table> <tbody> <tr> <th>Run</th> <th>Iteration</th> <th>Start</th> <th>End</th> </tr> </tbody> <tbody> <tr> <td>Constant - 0 users</td> <td>1</td> <td>02-05-2024 10:08</td> <td>02-05-2024 10:52</td> </tr> <tr> <td> </td> <td>2</td> <td>06-05-2024 13:20</td> <td>06-05-2024 13:58</td> </tr> <tr> <td> </td> <td>3</td> <td>07-05-2024 09:20</td> <td>07-05-2024 09:54</td> </tr> <tr> <td>Constant - 50 users</td> <td>1</td> <td>02-05-2024 13:26</td> <td>02-05-2024 13:57</td> </tr> <tr> <td> </td> <td>2</td> <td>15-05-2024 14:06</td> <td>15-05-2024 14:38</td> </tr> <tr> <td> </td> <td>3</td> <td>07-05-2024 09:56</td> <td>07-05-2024 10:39</td> </tr> <tr> <td>Constant - 100 users</td> <td>1</td> <td>02-05-2024 14:00</td> <td>02-05-2024 14:40</td> </tr> <tr> <td> </td> <td>2</td> <td>06-05-2024 14:40</td> <td>06-05-2024 15:30</td> </tr> <tr> <td> </td> <td>3</td> <td>07-05-2024 10:42</td> <td>07-05-2024 11:33</td> </tr> <tr> <td>Constant - 200 users</td> <td>1</td> <td>16-05-2024 09:37</td> <td>16-05-2024 10:09</td> </tr> <tr> <td> </td> <td>2</td> <td>06-05-2024 15:32</td> <td>06-05-2024 16:13</td> </tr> <tr> <td> </td> <td>3</td> <td>07-05-2024 11:34</td> <td>07-05-2024 12:11</td> </tr> <tr> <td>Constant - 400 users</td> <td>1</td> <td>02-05-2024 15:24</td> <td>02-05-2024 15:55</td> </tr> <tr> <td> </td> <td>2</td> <td>06-05-2024 16:14</td> <td>06-05-2024 16:49</td> </tr> <tr> <td> </td> <td>3</td> <td>07-05-2024 12:13</td> <td>07-05-2024 13:08</td> </tr> <tr> <td>Linear</td> <td>1</td> <td>22-05-2024 15:13</td> <td>22-05-2024 15:56</td> </tr> <tr> <td> </td> <td>2</td> <td>22-05-2024 16:05</td> <td>22-05-2024 16:48</td> </tr> <tr> <td> </td> <td>3</td> <td>23-05-2024 09:58</td> <td>23-05-2024 10:41</td> </tr> <tr> <td>Direct</td> <td>1</td> <td>2024-05-23 13:01:28</td> <td>2024-05-23 14:00:05</td> </tr> <tr> <td> </td> <td>2</td> <td>2024-05-23 14:33:23</td> <td>2024-05-23 15:32:01</td> </tr> <tr> <td> </td> <td>3</td> <td>2024-05-23 15:39:36</td> <td>2024-05-23 16:38:12</td> </tr> </tbody> </table> <p>A complete log of the experiments can be found in <code>experiments_log.txt</code>.</p> <h2>Constant</h2> <p>The constant data set contains the metrics for the system under a constant load. The load is generated by a Locust script that sends requests to the system. Data collection starts 1 minute after the desired number of concurrent users is reached and requests have stabilised. This experiment is performed for the following constant number of concurrent users:</p> <ul> <li>0 users</li> <li>50 users</li> <li>100 users</li> <li>200 users</li> <li>400 users</li> </ul> <p>Note that the <code>0 users</code> data does not contain the <code>report_*.html</code> and <code>request_*.csv</code> files, as these are generated by Locust and Locust is not run for the <code>0 users</code> scenario.</p> <p>Furthermore, note that Horizontal Pod Autoscaling is <em>not</em> enabled for this data set.</p> <h2>Linear</h2> <p>The linear dataset contains the metrics for the system under a linearly scaling load. The load is generated through Locust. It starts at 0 users, and scales up to 100 users at a rate of 1 user per 20 seconds. After the load reaches 100 users, another 10 minutes of data is recorded. Every dataset is 45 minutes long, with 1.7 minutes of no load, 33.3 minutes of scaling up, and 10 minutes of max load.</p> <p>Note that Horizontal Pod Autoscaling <em>is</em> enabled for this data set.</p> <h2>Direct</h2> <p>The direct data set compliments the linear dataset. While the linear dataset provides a realistic load with things like networking factors being taken into account, the linear dataset can bottleneck on things like networking and the request client, so CPU usage is not maxed out. The direct dataset scales up linearly by applying direct CPU load to the Kubernetes pods without any application simulating a real usecase. The dataset works by deploying Kubernetes pods that max out immediately on exactly 200mCPU of load. The experiment starts with 1 pod, and 2 pods are added every 90 seconds up till 77 pods (the maximum number of pods the cluster allows to be scheduled). The first 1.5 minutes is no load, then 57 minutes to scale up, and then another 1.5 minutes at max load.</p> <p>Note that the <code>direct</code> data set does not contain the <code>app_*.json</code> files, as this data set does not deploy an application and therefore no application specific metrics are collected. Instead, a <code>script_log.txt</code> is provided that explains when and how the direct load was scaled up.</p> <h1>Files</h1> <p>A table for each file in the data set can be found below, including the unit of the metric and a description of what data is collected in that file. The format of all JSON files is the API response format used by Prometheus. More information on this topic can be found here: <a title="https://prometheus.io/docs/prometheus/latest/querying/api/" href="https://prometheus.io/docs/prometheus/latest/querying/api/">https://prometheus.io/docs/prometheus/latest/querying/api/</a>. All timestamps are in the CEST timezone.</p> <table> <tbody> <tr> <th>Filename</th> <th>Unit</th> <th>Description</th> </tr> </tbody> <tbody> <tr> <td>app_ads_ad_requests_total.json</td> <td>Total Count</td> <td>Total requests received by the ad microservice</td> </tr> <tr> <td>app_currency_counter_total.json</td> <td>Total Count</td> <td>Total currency that circulated through the system</td> </tr> <tr> <td>app_frontend_requests_total.json</td> <td>Total Count</td> <td>Total requests received by the frontend service</td> </tr> <tr> <td>app_payment_transactions_total.json</td> <td>Total Count</td> <td>Total transactions made to the transaction microservice</td> </tr> <tr> <td>app_recommendations_counter_total.json</td> <td>Total Count</td> <td>Total recommendations made by the recommendation microservice</td> </tr> <tr> <td>container_blkio_device_usage_total.json</td> <td>Total Bytes</td> <td>Total bytes used by blkio devices for pods</td> </tr> <tr> <td>container_cpu_usage_seconds_total.json</td> <td>Total Seconds</td> <td>Cumulative cpu time consumed by the pod</td> </tr> <tr> <td>container_cpu_user_seconds_total.json</td> <td>Total Seconds</td> <td>Cumulative user cpu time consumed by the pod</td> </tr> <tr> <td>container_fs_reads_bytes_total.json</td> <td>Total Bytes</td> <td>Cumulative count of bytes read by the pod</td> </tr> <tr> <td>container_fs_writes_bytes_total.json</td> <td>Total Bytes</td> <td>Cumulative count of bytes written by the pod</td> </tr> <tr> <td>container_memory_rss.json</td> <td>Bytes</td> <td>Resident Set Size of the pod</td> </tr> <tr> <td>kepler_container_bpf_cpu_time_ms_total.json</td> <td>Milliseconds</td> <td>CPU time for the pod as measured through a Kepler BPF program</td> </tr> <tr> <td>kepler_container_core_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of CPU cores used by a pod</td> </tr> <tr> <td>kepler_container_dram_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of DRAM used by a pod</td> </tr> <tr> <td>kepler_container_joules_total.json</td> <td>Total Joules</td> <td>Aggregated total energy consumption of a pod</td> </tr> <tr> <td>kepler_container_package_joules_total.json</td> <td>Total Joules</td> <td>Cumulative energy consumed by all cores and uncore components of a pod</td> </tr> <tr> <td>kepler_node_core_joules_total.json</td> <td>Total Joules</td> <td>Aggregation of core_joules of all pods running on a Kubernetes node</td> </tr> <tr> <td>kepler_node_dram_joules_total.json</td> <td>Total Joules</td> <td>Aggregation of dram_joules of all pods running on a Kubernetes node</td> </tr> <tr> <td>kepler_node_package_joules_total.json</td> <td>Total Joules</td> <td>Aggregation of package_joules of all pods running on a Kubernetes node</td> </tr> <tr> <td>node_cpu_scaling_frequency_hertz.json</td> <td>Hertz</td> <td>Current scaled cpu thread frequency of a machine (BM or VM)</td> </tr> <tr> <td>node_cpu_seconds_total.json</td> <td>Total Seconds</td> <td>Total number of seconds the CPU worked on a machine (BM or VM)</td> </tr> <tr> <td>node_disk_read_time_seconds_total.json</td> <td>Total Seconds</td> <td>Total number of seconds spent reading disk on a machine (BM or VM)</td> </tr> <tr> <td>node_disk_write_time_seconds_total.json</td> <td>Total Seconds</td> <td>Total number of seconds spent writing disk on a machine (BM or VM)</td> </tr> <tr> <td>node_hwmon_temp_celsius.json</td> <td>Celsius</td> <td>Temperature of the machine (BM) as reported by its monitoring hardware</td> </tr> <tr> <td>node_load1.json</td> <td>Load Average</td> <td>Load on the machine (BM or VM) averaged over 1 minute</td> </tr> <tr> <td>node_load5.json</td> <td>Load Average</td> <td>Load on the machine (BM or VM) averaged over 5 minutes</td> </tr> <tr> <td>node_load15.json</td> <td>Load Average</td> <td>Load on the machine (BM or VM) averaged over 15 minutes</td> </tr> <tr> <td>node_memory_Active_bytes.json</td> <td>Bytes</td> <td>Active number of bytes in memory on the machine (BM or VM)</td> </tr> <tr> <td>node_memory_Committed_AS_bytes.json</td> <td>Bytes</td> <td>Committed number of bytes in memory on the machine (BM or VM)</td> </tr> <tr> <td>node_rapl_core_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of CPU cores by a machine, estimated by RAPL</td> </tr> <tr> <td>node_rapl_dram_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of DRAM by a machine, estimated by RAPL</td> </tr> <tr> <td>node_rapl_package_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of the machine package, estimated by RAPL</td> </tr> <tr> <td>node_rapl_psys_joules_total.json</td> <td>Total Joules</td> <td>Total energy consumption of the machine psys, estimated by RAPL</td> </tr> <tr> <td>power_consumption.json</td> <td>Watt</td> <td>Energy consumption as measured by the physical power plugs</td> </tr> <tr> <td>report_*.html</td> <td>-</td> <td>HTML report describing details of locust actions during the experiment</td> </tr> <tr> <td>requests_*.csv</td> <td>-</td> <td>Request summary per endpoint generated by locust</td> </tr> <tr> <td>scaph_host_power_microwatts.json</td> <td>Microwatt</td> <td>Power consumption of the whole machine as estimated by Scaphandre</td> </tr> <tr> <td>scaph_process_cpu_usage_percentage.json</td> <td>Percentage</td> <td>Per-process CPU usage as a percentage of total machine CPU</td> </tr> <tr> <td>scaph_process_memory_bytes.json</td> <td>Bytes</td> <td>Per-process memory usage</td> </tr> <tr> <td>scaph_process_power_consumption_microwatts.json</td> <td>Microwatt</td> <td>Per-process energy consumption as estimated by Scaphandre</td> </tr> <tr> <td>script.log</td> <td>-</td> <td>Log for the direct experiments for scaling up the pods</td> </tr> </tbody> </table> <h1>Scripts</h1> <div> <div>All scripts used to query this data from the prometheus endpoint and to generate the results in the associated paper are included in the scripts directory. To run a script, the script must be placed in the same directory as the data it is operated on (e.g. /scripts/constant/power_estimation.ipynb has to be in /constant).</div> </div>
Supporting dataset of Balloon-bore Aerosol-Cloud Interaction Studies (BACIS): Field campaigns to understand and quantiy aerosol effects on clouds
<p>The upload comprises raw dataset of supporting instruments from BACIS Campaigns conducted from NARL, Gadanki.</p>
WebMicroscope's Deep Learning AI platform automates image analyses with an approach that is faster and able to understand tissue context, which reduces steps needed for accurate results. Researchers can gain access to digitized samples, such as this image of breast-cancer tissue (left), and analyze results through the cloud platform anywhere, anytime. This is a whole slide image of a tissue section of an adrenal gland (right). Fimmic's WebMicroscope cloud platform allows researchers to manage, share, and view digital gigapixel images with any modern browser. Researchers can rapidly pan, zoom, and analyze a digital sample. Photographs: Courtesy of Fimmic Oy. in Deep learning brings speed, accuracy to the life sciences.
WebMicroscope's Deep Learning AI platform automates image analyses with an approach that is faster and able to understand tissue context, which reduces steps needed for accurate results. Researchers can gain access to digitized samples, such as this image of breast-cancer tissue (left), and analyze results through the cloud platform anywhere, anytime. This is a whole slide image of a tissue section of an adrenal gland (right). Fimmic's WebMicroscope cloud platform allows researchers to manage, share, and view digital gigapixel images with any modern browser. Researchers can rapidly pan, zoom, and analyze a digital sample. Photographs: Courtesy of Fimmic Oy.
Data for "Using Simulated Radiances to Understand the Limitations of Satellite Retrieved Volcanic Ash Data and the Implications for Volcanic Ash Cloud Forecasting"
<p>This location contains all of the data used in the analysis for the paper "Using Simulated Radiances to Understand the Limitations of Satellite Retrieved Volcanic Ash Data and the Implications for Volcanic Ash Cloud Forecasting" which is currently in prep.</p> <p>All of the retrieved satellite data can be seen in the retrieved_satellite_data.zip folder. the data is organised by the input ash cloud properties being simulated and the hdf files contain all of the retrieved variables where ash has been successfully detected.</p> <p>All of the output dispersion model data is available in NAME_output_data.zip. </p> <p>All of the input source data used in the dispersion model simulations (including the data from REFIR) is available in NAME_source_data_REFIR.zip.</p>
Generated datasets for Yue et al. (2020, Earth and Space Science): "Combining In-situ and Satellite Observations to Understand the Vertical Structure of Tropical Anvil Cloud Microphysical Properties During the TC4 Experiment"
<p>This archive contains the data sets generated from the research conducted by Yue et al. (2020) titled "Combining In-situ and Satellite Observations to Understand the Vertical Structure of Tropical Anvil Cloud Microphysical Properties During the TC4 Experiment" published in Earth and Space Science. The method to generated the following data sets is described in Yue et al. (2020) and stored as Matlab .mat files.</p> <p>CombiningTC4_Satellite_eof_cov_mat.mat contains the correlation matrix shown in Figure 1a.</p> <p>TC4_processed.mat contains the correlation matrix shown in Figure 1b.</p> <p>RO_processed.mat contains the correlation matrix shown in Figure 2a.</p> <p>RVOD_processed.mat contains the correlation matrix shown in Figure 2b.</p> <p>ICE_processed.mat contains the correlation matrix shown in Figure 2c.</p> <p> </p> <p> </p>
Artifacts of Paper "Understanding and Discovering Software Configuration Dependencies in Cloud and Datacenter Systems"
<p>This package contains all the artifacts (i.e. codes & datasets) we use in our paper "Understanding and Discovering Software Configuration Dependencies in Cloud and Datacenter Systems" accepted to FSE 2020.</p>
Artifacts of Paper "Understanding and Discovering Software Configuration Dependencies in Cloud and Datacenter Systems"
<p>This package contains all the artifacts (i.e. codes & datasets) we use in our paper "Understanding and Discovering Software Configuration Dependencies in Cloud and Datacenter Systems" accepted to FSE 2020.</p>
CloudSEN12 - a global dataset for semantic understanding of cloud and cloud shadow in Sentinel-2
<p><strong>Description</strong></p> <p>CloudSEN12 is a large dataset for cloud semantic understanding that consists of 9880 regions of interest (ROIs). Each ROI has five 5090x5090 meters image patches (IPs) collected on different dates; we manually choose the images to guarantee that each IP inside an ROI matches one of the following cloud cover groups:</p> <p>- clear (0%)</p> <p>- low-cloudy (1% - 25%) </p> <p>- almost clear (25% - 45%)</p> <p>- mid-cloudy (45% - 65%)</p> <p>- cloudy (65% >)</p> <p>An IP is the core unit in CloudSEN12. Each IP contains data from Sentinel-2 optical levels 1C and 2A, Sentinel-1 Synthetic Aperture Radar (SAR), digital elevation model, surface water occurrence, land cover classes, and cloud mask results from eight cutting-edge cloud detection algorithms. Besides, in order to support standard, weakly, and self-/semi-supervised learning procedures, cloudSEN12 includes three distinct forms of hand-crafted labelling data: high-quality, scribble, and no annotation. Consequently, each ROI is randomly assigned to a different annotation group:</p> <ul> <li> <p>2000 ROIs with pixel-level annotation, where the average annotation time is 150 minutes (high-quality group).</p> </li> <li> <p>2000 ROIs with scribble level annotation, where the annotation time is 15 minutes (scribble group).</p> </li> <li> <p>5880 ROIs with annotation only in the cloud-free (0\%) image (no annotation group).</p> </li> </ul> <p>For high-quality labels, we use the Intelligence foR Image Segmentation\cite{iris2019} (IRIS) active learning technology, a system that combines human photo-interpretation and machine learning. For scribble, ground truth pixels were drawn using IRIS but without ML support. Finally, the no annotation dataset is generated automatically, with manual annotation only in the clear image patch. The dataset is already available here: <strong><a href="https://shorturl.at/cgjtz">https://shorturl.at/cgjtz</a></strong>. Check out our website <strong><a href="https://cloudsen12.github.io/">https://cloudsen12.github.io/</a></strong> for examples of how to download the dataset via STAC.</p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.