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.
15
datasets available to search
ShareScore release 0.9.0
Dataset results
15 results for “webassembly”
Static Stack-Preserving Intra-Procedural Slicing of WebAssembly Binaries
<p># About this artifact<br> This artifact contains the implementation and the results of the evaluation of a<br> static slicer for WebAssembly described in the ICSE 2022 paper titled "Static<br> Stack-Preserving Intra-Procedural Slicing of WebAssembly Binaries".</p> <p>The artifact contains a docker image (`wassail-eval.tar.xz`) that contains<br> everything necessary to reproduce our evaluation, and the actual data resulting<br> from our evaluation:<br> 1. The implementation of our slicer (presented in Section 4.1) is included in<br> the docker machine, and is available publicly here:<br> https://github.com/acieroid/wassail/tree/icse2022<br> 2. Test cases used for our evaluation of RQ1 are included in the docker machine<br> and in the `rq1.tar.xz` archive.<br> 3. The dataset used in RQ2, RQ3, and RQ4 is included in the docker machine.<br> 4. The code needed to run our evaluation of RQ2, RQ3, and RQ4 is included in the<br> docker machine.<br> 5. The scripts used to generate the statistics and graphs that are included in<br> the paper for RQ2, RQ3, and RQ4 are included in the docker machine and as the<br> `*.py` files in this artifact.<br> 6. The data of RQ5 that has been used in our manual investigation is included in<br> the docker machine and in the `rq5.tar.xz` archive, along with<br> `rq5-manual.txt` detailing our manual analysis findings.</p> <p># How to obtain it<br> Our artifact is available on Zenodo at the following URL: https://zenodo.org/record/5821007</p> <p># Setting up the Docker image<br> ## Downloading The Artifact<br> The artifact is available at the following URL: https://zenodo.org/record/5821007</p> <p>## Loading The Docker Image<br> Once the artifact is downloaded in the file `icse2022slicing.tar.xz`, it can be extracted and loaded into Docker as follows (this takes a few minutes):<br> ```<br> docker import icse2022slicing.tar.xz<br> ```<br> To simplify further commands, you can tag the image using the printed sha256 hash of the image: if the `docker import` command resulted in the hash `54aa9416a379a6c71b1c325985add8bf931752d754c8fb17872c05f4e4b52ea2`, you can run:<br> ```<br> docker tag 54aa9416a379a6c71b1c325985add8bf931752d754c8fb17872c05f4e4b52ea2 wassail-eval<br> ```</p> <p>Once the Docker image has been loaded, you can run the following commands to<br> obtain a shell in the appropriate environment:<br> ```<br> docker volume create result<br> docker run -it -v result:/tmp/out/ wassail-eval bash<br> su - opam<br> ```</p> <p># Reproducing results of RQ1<br> Our manual translations of the "classical" examples are included in the `rq1/`<br> directory (available in the docker image and in `rq1.tar.xz`). We<br> include the slices computed by our implementation in the `rq1/out/` directory.</p> <p>A slice can be produced for each example in the docker image as follows, where<br> the first argument is the name of the program being sliced, the second the<br> function index being sliced, the third the slicing criterion (indicated as the<br> instruction index, where instructions start at 1), and the last argument is the<br> output file for the slice:</p> <p>```<br> cd rq1/<br> wassail slice scam-mug.wat 5 8 scam-mug-slice.wat<br> wassail slice montreal-boat.wat 5 19 montreal-boat-slice.wat<br> wassail slice word-count.wat 1 41 word-count-slice1.wat<br> wassail slice word-count.wat 1 43 word-count-slice2.wat<br> wassail slice word-count.wat 1 39 word-count-slice3.wat<br> wassail slice word-count.wat 1 45 word-count-slice4.wat<br> wassail slice word-count.wat 1 37 word-count-slice5.wat<br> wassail slice agrawal-fig-3.wat 3 38 agrawal-fig-3-slice.wat<br> wassail slice agrawal-fig-5.wat 3 37 agrawal-fig-5-slice.wat<br> ```</p> <p>The slice results can then be inspected manually, and compared with the original<br> version of the .wat program to see which instructions have been removed, or with<br> the expected solutions in the `out/` directory, e.g. by running:<br> ```<br> diff word-count-slice1.wat out/word-count-slice1.wat<br> ```<br> (No output is expected if the slice is correct)</p> <p># Reproducing results of RQ2, RQ3, and RQ4<br> For these RQ, we include the data resulting from our evaluation, but we also<br> allow reviewers to rerun the full evaluation if needed. However, such an<br> evaluation requires a heavy machine and takes quite some time (4-5 days to run<br> to completion with a 4 hours timeout). In our case, we used a machine with 256<br> GB of RAM and a 64-core processor with HyperThreading enabled, allowing us to<br> run 128 slicing jobs in parallel.</p> <p>## Runnig the Evaluation<br> We explain how to run the full evaluation, or only a partial evaluation below.<br> One can directly skip to the next section and reuse our raw evaluation results,<br> provided alongside this artifact.</p> <p>### Running the Full Evaluation<br> In order to reproduce our evaluation, you can run the following commands in the<br> docker image. It is recommended to run them in a tmux session if one wants to<br> inspect other elements in parallel (tmux is installed in the docker image). The<br> timeout (set to 4 hours per binary, like in the paper) can be decreased by<br> editing the `evaluate.sh` script (vim is installed in the docker image).</p> <p>This is expected to take 2-3 days of time, on a machine with 128 cores.<br> In order to produce only partial results, see the next section.</p> <p>```<br> cd filtered<br> cat ../supported.txt | parallel --bar -j 128 sh ../evaluate.sh {}<br> ```</p> <p>The results are outputted in the `/tmp/out/` directory.</p> <p>### Running a Partial Evaluation<br> If one does not have access to a high-end machine with 128 cores nor the time to<br> run the full evaluation, it is possible to produce partial results. To do so,<br> the following commands can be run. This will run the evaluation on the full<br> dataset in a random order, which can be stopped early to represent a partial<br> view of our evaluation, on a random subset of the data. In order to gather more<br> datapoints, it is also advised to decrease the timeout in the `evaluate.sh`<br> file, for example to 20 minutes by setting `TIMEOUT=20m` with `nano<br> evaluate.sh`. The number of slicing jobs running in parallel can also be<br> decreased to match the number of processors on the machine running the<br> experiments (the `-j 128` argument in the following command runs 128 parallel<br> jobs)</p> <p>```<br> sudo chown opam:opam /tmp/out/<br> cd filtered<br> shuf ../supported.txt | parallel --bar -j 128 sh ../evaluate.sh {}<br> ```</p> <p>The evaluation results will be stored in the `/tmp/out/` directory.</p> <p>### Skipping the Evaluation Run<br> Instead of rerunning the evaluation, one can rely on our full results included<br> in the `data.txt.xz` and `error.txt.xz` archives. These can simply be downloaded<br> from within the Docker machine and extracted in `/tmp/out/`:</p> <p>```<br> cd /tmp/out/<br> wget https://zenodo.org/record/5821007/files/data.txt.xz<br> wget https://zenodo.org/record/5821007/files/error.txt.xz<br> unxz data.txt.7z<br> unxz error.txt.7z<br> ```</p> <p>## Processing the data</p> <p>In order to process this data, we included multiple python script.<br> These require around 100GB of RAM to load the full dataset in memory.<br> The scripts should be run with Python 3.<br> When running this in the docker image, first run `cd /tmp/out/ && cp /home/opam/*.py ./`<br> - To count the number of functions sliced, run `cut -d, -f 1,2 data.txt | sort<br> -u | wc -l`. This takes around 6 minutes to run on the full dataset.<br> - To count the total number of slices encountered, run `wc -l data.txt<br> error.txt`. This takes around 15 seconds to run.<br> - To count the number of errors encountered, run `wc -l error.txt`. This takes<br> around 1 second to run.<br> - To produce data and graphs regarding the sizes and timing, run `python3<br> statistics-and-plots.py`. This will output the statistics presented in the<br> paper, along with Figure 2 (rq2-sizes.pdf) and Figure 3 (rq2-times.pdf). This<br> script takes around 35 minutes to run.<br> - To find the executable slices that are larger than the original programs, run<br> `python3 larger-slices.py > larger.txt`. This script takes around 2h30 to<br> run. It will list the slice using the notation `filename function-sliced<br> slicing-criterion` in the larger.txt file, from which the slice can be<br> recomputed by running `wassail slice function-sliced slicing-criterion<br> output.wat` in the docker image. It will also output statistics regarding<br> these slices, which you can easily inspect by running `tail larger.txt`.<br> - To investigate slices that could not be computed, run:<br> ```<br> sed -i error.txt -e 's/annotation,/annotation./'<br> python3 errors.py<br> ```<br> This will take a few seconds to run and will print a summary of the errors<br> encountered during the slicing process, and requires some manual sorting to map<br> to the categories we discuss in the paper. Here is a summary of the errors<br> encountered and their root cause:</p> <p>### Root Cause: Unsupported Usage of br_table<br> Error: (Failure"Invalid vstack when popping 2 values")<br> Error: (Failure"Spec_inference.drop: not enough elements in stack")<br> Error: (Failure"Spec_inference.take: not enough element in var list")<br> Error: (Failure"unsupported in spec_inference: incompatible stack lengths (probably due to mismatches in br_table branches)")<br> ### Root Cause: Unreachable Code<br> Error: (Failure"Unsupported in slicing: cannot find an instruction. It probably is part of unreachable code.")<br> Error: (Failure"bottom annotation")<br> Error: (Failure"bottom annotation. this an unreachable instruction")</p> <p># RQ5: Comparison to Slicing C Programs<br> For this RQ, we include the following data in the `rq5.7z` archive, and in the `rq5/` directory in the docker image:<br> - The slicing subjects in their C and textual wasm form in `rq5/subjects/`<br> - The CodeSurfer slices in their C and textual wasm form in `rq5/codesurfer/`<br> - Our slices in their wasm form in `rq5/wasm-slices/`</p> <p>As this RQ requires heavy manual comparison, we do not expect the reviewers to<br> reproduce all of our results. We include a summary of our manual investigation<br> in `rq5-manual.txt`. In order to validate these manual findings, one can for<br> example inspect a specific slice. For example, the following line in<br> `rq5-manual.txt`:</p> <p>```<br> adpcm_apl1_565_expr.c.wat INTERPROCEDURAL<br> ```</p> <p>can be validated as follows:<br> ```<br> cd ~/<br> # This generates a trimmed down version of the CodeSurfer slice, only containing the function of interest<br> wassail count-in-slice rq5/codesurfer/adpcm_slices/adpcm_apl1_565_expr.c.wat slice.wat<br> # This compares the CodeSurfer slice with our slice<br> diff --side-by-side slice.wat rq5/adpcm_apl1_565_expr.c.wat<br> ```</p> <p>In this case, most extraneous instructions are present in the CodeSurfer slices,<br> at the end of the function. This indicates that these are present in order to<br> preserve interprocedural behavior, which corresponds to the `INTERPROCEDURAL`<br> tag in the `rq5-manual.txt`</p> <p> </p>
OOPSLA 2022 Artifact for "A Fast in-place Interpreter for WebAssembly"
<p>This archive includes</p> <ul> <li>source-code snapshots of 3 Web Engines for executing WebAssembly</li> <li>3 non-Web engines: Wasm3, the WebAssembly Micro-Runtime, and the Wizard Research Engine</li> <li>binary builds for Linux x86-64</li> <li>build instructions</li> <li>PolyBenchC benchmark Wasm binaries</li> <li>benchmarking setup and scripts</li> <li>data collected from experiments included in the OOPSLA 2022 paper</li> <li>instructions for running the benchmarks on Linux systems</li> </ul>
Dataset and Experiment Scripts for "When Function Inlining Meets WebAssembly: A Counterintuitive Effect on Runtime Performance"
<p>This repository contains the Experiment Results and Collection scripts for our ESEC/FSE 2023 submission, "When Function Inlining Meets WebAssembly: A Counterintuitive Effect on Runtime Performance"</p> <p>Our runtime experiment data is located in the <em>Experiment Results</em> directory. This directory contains two subdirectories, <em>All Experiment Results</em> and <em>Counterintuitive Results Only</em>. In <em>All Experiment Results</em>, we present the runtime results from our Experiments 1-5 and the Libsodium.js case study as CSV files. For the Chromium and Firefox results, each CSV file list the sample names and multiple columns for each of the four optimization levels, O0-O3. Under each optimization level, we list the runtime (in milliseconds) with inlining enabled (from the Baseline experiment), the runtime with inlining enabled (from one of Experiment #1-5), and percent change in runtime after disabling inlining.</p> <p>The <em>Counterintuitive Results Only</em> directory contains CSV files presenting only the samples from each Experiment #1-5 that meet our threshold of at least a 5% decrease in runtime after disabling inlining.</p> <p>The Excel file, <em>Wasm Function Inlining Experiment Data.xlsx</em>, contains all of these results in a single workbook, as well as formatting applied to highlight the counterintuitive runtime values presented in our paper.</p> <p>The raw data collected from our experiments, including the generated WebAssembly, HTML, and JS files to run the samples, is found under the <em>RawCollectedData</em> directory. This folder contains a zipped file that, when extracted, contains subdirectories for each sample's collected data.</p> <p>The <em>CollectionScripts</em> directory contains the scripts necessary to run our experiments. The <em>PatchFiles</em> directory contains the files from the Binaryen and LLVM infrastructures with the changes that we introduced to enable and disable select optimization passes through environment variables. The <em>Scripts</em> directory contains the scripts we used to run our experiments. The main file within this directory that serves as the entry point is <em>opt_level_inlining.py</em>. This file uses the other scripts to run Experiments 1-5 in our study. The script <em>libsodiumjs_script.py</em> is used to run our Libsodium.js case study.</p> <p>The scripts are written in Python and Node.js, and the dependencies to run the scripts are Node.js, Python, and MySQL. To download the necessary dependencies for the scripts, run the command `pip install -r requirements.txt` in <em>Scripts </em>folder<em>, and run `npm install` in the Scripts/performance-measurement-tool</em> folder. Then, import the included MySQL schemas under the<em> Scripts </em>folder into a MySQL database. Update the MySQL connection details in the <em>Scripts\__db_utils.py</em> and <em>Scripts\performance-measurement-tool\src\MySQLConnector.ts</em> files, and then run `npm run build` in the <em>Scripts\performance-measurement-tool</em> folder.</p>
Dataset for the Paper: Issues and Their Causes in WebAssembly Applications: An Empirical Study
<p>This dataset accompanies the paper titled 'Issues and Their Causes in WebAssembly Applications: An Empirical Study.' The dataset is stored in a Microsoft Excel file, which comprises multiple worksheets. A brief description of each worksheet is provided below.</p><p>(1) The '<strong>Selected Systems</strong>' worksheet contains information on the 12 chosen open-source WebAssembly applications, along with the URL for each application.</p><p>(2) The '<strong>GitHub-Raw Data</strong>' worksheet contains information on the initially retrieved 6,667 issues, including the titles, links, and statuses of each individual issue discussion.</p><p>(3) The '<strong>SOF-Raw Data</strong>' worksheet contains information on the initially retrieved 6,667 questions and answers, including the details of each question and answer, respective links, and associated tags.</p><p>(4) The '<strong>GitHubData Random Selected</strong>' worksheet contains a list of issues randomly selected from the initial pool of 6,667 issues, as well as extracted data from the discussions associated with these randomly selected issues.</p><p>(5) The '<strong>GitHub-(Issues, Causes)</strong>' worksheet contains the initial codes categorizing the types of issues and causes.</p><p>(6) The '<strong>SOF (Issues, Causes)</strong>' worksheet contains information gleaned from a randomly selected subset of 354 Stack Overflow posts. This information includes the title and body of each question, the associated link, tags, as well as key points for types of issues and causes.</p><p>(7) The '<strong>Combine (Git and SOF) Data</strong>' worksheet contains the compiled issues and causes extracted from both GitHub and Stack Overflow.</p><p>(8) The <strong>'Issue Taxonomy</strong>' worksheet contains a comprehensive issue taxonomy, which is organized into 9 categories, 20 subcategories, and 132 specific types of issues.</p><p>(9) The '<strong>Cause Taxonomy</strong>' worksheet contains a comprehensive cause taxonomy, which is organized into 10 categories, 35 subcategories, and 283 specific types of causes.</p>
Replication package for "An Empirical Evaluation of Static, Dynamic, and Hybrid Slicing of WebAssembly Binaries"
<p>This is the replication package that accompanies the paper "An Empirical Evaluation of Static, Dynamic, and Hybrid Slicing of WebAssembly Binaries".</p> <p>It is structured as follows.</p> <p> - RQs.py is the script that generates the data that is included in the paper. For each research question, it generates statistics and plots.<br> - The .csv files and nok.txt are used by RQs.py. They contain the raw size and timing data for each slice. The headers of the .csv files indicate what each column represents.<br> - `sqlite-slices.csv` contains the raw data for RQ8, which is contained in the paper<br> - The .tar.gz files contain the source and the slices generated by each slicer, namely:<br> - `static_slices.tar.gz` contains the slices generated by CsE, the static slicer. For example, the file `static_slices/adpcm/adpcm_ah1_254_expr/static_adpcm.wat.slice` is the slice of the adpcm program taken with respect to the variable `ah1` at line `254` of the original `.c` program.<br> - `slice.tar.gz` contains slices from the dynamic slicers:<br> - slice-sce - the SCE slices<br> - slice-ces - the CES slices<br> - slice-cse - the CSE slices<br> - slice-sces - the SCES slices<br> - slice-cses - the CsES slices<br> - `src.tar.gz` includes the unsliced `C` and `wasm` source<br> - `bc.support.tar.gz` includes the complete `bc` source code <br> - `sqlite.tar.gz` contains the slices of RQ8, each in a directory named after the slicer used. For example, the file `sqlite/CES/avg.wat` contains the CES slice for the `avg` slicing criterion.<br> <br>In order to regenerate the data and plots that are in the paper, you should simply run:</p> <p>```<br>python RQs.py<br>```</p>
Sample WebAssembly Data Files for Reproducible Analysis and Visualization of iEEG (RAVE)
<p>The data was derived from the following work and packaged into WebAssemply via Emscripten. The modification includes removing large data files and only keep up with the minimal requirements.</p> <blockquote> <p>Magnotti, J. F., Wang, Z., & Beauchamp, M. S. (2020). RAVE: Comprehensive open-source software for reproducible analysis and visualization of intracranial EEG data. <em>NeuroImage</em>, <em>223</em>, 117341.</p> </blockquote> <p> </p>
Wasmizer: Curating WebAssembly-driven Projects on GitHub
<p>This is the dataset and artifact that accompanies the MSR 2023 paper titled: "Wasmizer: Curating WebAssembly-driven Projects<br> on GitHub"</p>
Dynamic Slicing of WebAssembly Binaries
<p>This is the replication package that accompanies the paper titled: "Dynamic Slicing of WebAssembly Binaries".</p> <p># Slices dataset<br> ## Generating the dataset<br> The dynamic slices have been generated with [P-ORBS](https://syed-islam.github.io/research/program-analysis/#observation-based-program-slicing-orbs).<br> The steps and scripts to generate the dynamic slices are included in the `slicing-steps/` directory.<br> These steps also describe how to generate the `stats.csv` file that is included in this dataset.</p> <p>The static slices have been generated with [wassail](https://github.com/acieroid/wassail).<br> The scripts to generate the static slices are included in the current directory (`generate-static-slices.sh` which relies on `run_wassail.sh`).<br> These steps generate the file `static-stats.csv` that is included in this dataset.</p> <p>The `original-size.csv` file, included in this dataset, can be generated as follows:<br> ```sh<br> find subjects-wasm-extract-slice -name \*.c.wat -exec c_count {} \; | grep subjects > counts.txt<br> echo 'slice,original fn slice' > evaluation/original-sizes.csv<br> sed -E 's|^(.*) subjects-wasm-extract-slice/[^/]*/([^/]*)/.*$|\2,\1|' counts.txt >> evaluation/original-sizes.csv<br> ```</p> <p>The numbers in Table 1 of the paper (the list of programs in the dataset along with their sizes) can be generated as follows.<br> For the WebAssembly files, we can count the function size:</p> <p>```<br> find subjects-wasm-extract-slice -name \*.c.wat -exec c_count {} \; | grep subjects > counts.txt<br> sed -E 's|^(.*) subjects-wasm-extract-slice/([^/]*)/.*$|\1 \2|' counts.txt | python evaluation/table1-wasm-mean.py<br> ```</p> <p>or the full program size:</p> <p>```<br> find subjects-wasm-extract-slice -name t.wat -exec c_count {} \; | grep subjects > counts.txt<br> sed -E 's|^(.*) subjects-wasm-extract-slice/([^/]*)/.*$|\1 \2|' counts.txt | python evaluation/table1-wasm-mean.py<br> ```</p> <p>## Structure of the dataset</p> <p>The dataset is structured as follows:</p> <p> - `subjects/` contains the instrumented `.c` source code, along with scripts to generate the dynamic slices.<br> The original source code can be obtained by removing the line `printf("\nORBS:%x\n....`.<br> - `subjects-wasm-extract-slice/` contains the original WebAssembly programs to slice. Each program has two files: `t.wat` is the full binary file, and `name.c.wat` is the binary code of the function containing the slicing criterion.<br> - `all_slices/` contains the slices. For example, program `adpcm_ah1_254_expr` has the following files<br> - `adpcm/adpcm_ah1_254_expr/EWS_adpcm.wat`: the EWS slice<br> - `adpcm/adpcm_ah1_254_expr/SEW_adpcm.wat`: the SEW slice<br> - `adpcm/adpcm_ah1_254_expr/ESW_adpcm.wat`: the ESW slice<br> - `adpcm/adpcm_ah1_254_expr/static_adpcm.wat.slice`: the SWS slice<br> The other files are produced by intermediary steps and can be ignored. They are:<br> - `adpcm/adpcm_ah1_254_expr/ESW_adpcm.wat.orig`: original (unsliced) binary *file* from which SW and ESW slices are computed<br> - `adpcm/adpcm_ah1_254_expr/SEW_adpcm.wat.orig`: original (unsliced) binary *function* from which SEW slice is computed<br> - `adpcm/adpcm_ah1_254_expr/SW_adpcm.wat`: slice of entire binary file from which ESW slice is extracted<br> - `adpcm/adpcm_ah1_254_expr/WS_adpcm.wat`: compiled (binary) version of dynamic C slice from which EWS slice is extracted<br> <br> # Research questions<br> ## RQ1</p> <p>The script `./RQ1.py` found in the `evaluation/` directory generates:</p> <p> - Figure 3 (time.pdf)<br> - The mean, min, max, and stddev of the times<br> - How many slices are computed below 10, 100, 1000, and 10000 seconds</p> <p>## RQ2</p> <p>The script `./RQ2.py` found in the `evaluation/` directory generates:</p> <p> - Figure 4 (loc.pdf)<br> - The mean, median, min, max, and stddev of the sizes<br> - The largest differences between the approaches<br> - The number of slices larger than the original program<br> <br> ## RQ3 and RQ4</p> <p>The process for these research questions is manual and requires comparing slices.<br> It cannot be automated. <br> We did make heavy use of `diff --side-by-side` in this analysis.<br> </p>
WASMDYPA: Effectively Detecting WebAssembly Bugs via Dynamic Program Analysis
<p>This contains all the experimental code, data sets, and result files for our experiments.</p>
A Comprehensive Study of Bugs in WebAssembly Virtual Machines
<p>This contains the dataset and results of our analysis.</p>
A Comprehensive Study of Bugs in Embedded WebAssembly Virtual Machines
<p>This contains all the experimental code, data sets, and result files for our experiments.</p>
A Comprehensive Study of Bugs in Embedded WebAssembly Virtual Machines
<p>This contains all the experimental code, data sets, and result files for our experiments.</p>
A Comprehensive Study of Bugs in Embedded WebAssembly Virtual Machines
<p>This contains all the experimental code, data sets, and result files for our experiments.</p>
An Empirical Study of Embedded WebAssembly Virtual Machine
<p>This contains all the experimental code, data sets, and result files for our experiments.</p>
A Comprehensive Study of Bugs in Embedded WebAssembly Virtual Machines
<p>This contains all the experimental code, data sets, and result files for our experiments.</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.