# Vesuvius Challenge — scrollprize.org full content > Vesuvius Challenge is a machine learning, computer vision, and geometry competition reading the carbonized Herculaneum scrolls — ~1,800 papyrus rolls buried and carbonized by the eruption of Mount Vesuvius in 79 AD. Using high-resolution X-ray CT scanning, "virtual unwrapping," and AI ink detection, the project recovers text without physically opening the fragile scrolls. In 2023 a $700,000 Grand Prize was awarded for reading the first passages; by 2025 ~70% of scroll PHerc. 172 had been digitally unwrapped. Over $1,800,500 in prizes has been awarded. Founded by Nat Friedman and Daniel Gross with Prof. Brent Seales (EduceLab, University of Kentucky). ===== PAGE: Overview ===== URL: https://scrollprize.org/ STATUS: current Vesuvius Challenge uses machine learning and computer vision to read the carbonized Herculaneum scrolls buried by Vesuvius in 79 AD. ===== PAGE: Get Started ===== URL: https://scrollprize.org/get_started STATUS: current ===== PAGE: Data Formats ===== URL: https://scrollprize.org/data STATUS: current Quick start: [example quick data access notebook](https://github.com/ScrollPrize/open-data/blob/main/examples/get-to-know-a-dataset.ipynb) ## Overview [section: /data#overview] A vast library of papyrus scrolls in ancient Herculaneum was buried beneath volcanic mud and ash during the 79 AD eruption of Mount Vesuvius. The scrolls were carbonized into a fragile but remarkably preserved state. The Vesuvius Challenge uses synchrotron micro‑CT imaging to study both intact scrolls and detached fragments. ## Multiple datasets [section: /data#multiple-datasets] This portal aggregates multiple released datasets under one Vesuvius Challenge data portal. - Vesuvius Challenge - CT Scans of Herculaneum Papyri: newer scans released directly by Vesuvius Challenge. Most current releases on this portal belong to this dataset. - EduceLab-Scrolls: the legacy dataset. Scrolls 1-4 and Fragments 1-6 scanned before 2025 at DLS belong to this dataset. If you are publishing or presenting results, make sure you cite the dataset that corresponds to the scans you used. ## Data repositories [section: /data#data-repositories] We host the dataset in the open data bucket: `s3://vesuvius-challenge-open-data/`, usable with any S3‑compatible client (e.g., AWS CLI, boto3, s3fs, etc.). It's also [browsable directly](https://vesuvius-challenge-open-data.s3.us-east-1.amazonaws.com/index.html). An overview of the dataset can be found in the [Data Browser](/data_browser). The browser is the unified sample index for both scrolls and fragments. For deeper exploration, use [Curated Datasets](/data_datasets) for ready-to-use bundles built for specific research tasks. ## What's included [section: /data#whats-included] The open data repository provides a consistent set of artifacts across scrolls and fragments: - Volumes: 3D micro‑CT reconstructions of papyrus (primary input for virtually unrolling). - Segments: extracted papyrus surfaces (geometry + surface‑aligned "texture" volumes). - Representations / Predictions: derived products such as ML‑predicted surfaces and ink detection outputs (when available). - Metadata: lightweight JSON/text files that describe scans, exports, and processing (where available). ## Formats at a glance [section: /data#formats-at-a-glance] This is a practical "what you'll actually see on disk" summary. | Data type | What it represents | Common formats | | -------------------------------- | -------------------------------------------------------------- | --------------------------------------------------------------- | | Volumetric scans ("volumes") | 3D density/intensity values from CT reconstruction | OME‑Zarr (primary), sometimes TIFF stacks | | Segment surface volumes | 2D/3D data extracted along a papyrus surface at several depths | OME‑Zarr and/or TIFF stacks (`00.tif`, `01.tif`, …) | | Surface geometry ("meshes") | The 3D sheet geometry and its flattened mapping | OBJ meshes, plus TIFXYZ (x/y/z TIFF triplet + metadata) | | Model outputs | Predicted surfaces, ink probability maps, derived images | OME‑Zarr (volumetric outputs), TIFF (image outputs) | | Metadata | Provenance, parameters, IDs, links between artifacts | JSON (and occasional text files) | ### Why OME‑Zarr? [section: /data#why-omezarr] OME‑Zarr is the primary distribution format because it is cloud‑optimized (chunked, multi‑resolution) and supports streaming / partial reads—so you don't need to download entire terabyte‑scale volumes to get started. ## Organization on disk [section: /data#organization-on-disk] The repository follows this high‑level structure: ```text {SAMPLE_ID}/ ├── volumes/ # 3D reconstructed volumes (OME‑Zarr, sometimes TIFF) ├── segments/ # Extracted surfaces: meshes, surface volumes, (optional) ink results └── representations/ # Derived artifacts (e.g., predictions) ``` You will typically browse by sample ID (e.g., a specific scroll or fragment), then choose the artifact you need (a volume, a segment, or a derived representation). ## Scrolls and Fragments [section: /data#scrolls-and-fragments] - Herculaneum scrolls scanned via synchrotron micro‑CT. These are the core targets for "virtual unwrapping" and reading. - Detached fragments with exposed ink on their surfaces. These are especially useful for building and validating ML approaches (e.g., ink detection), because they provide ground truth signals. ➡️ Browse all samples: [Data Browser](/data_browser) ## Documentation and references [section: /data#documentation-and-references] - For information on the updated scans (2026), read the [technical pre-print](https://arxiv.org/abs/2606.29085). - [Scan at ESRF Draft Info Sheet (2025)](https://docs.google.com/document/d/1CDPgx7XhNsnLJw6uErT8Z5tgY3wnETQdvXpR5Kwu9K4/edit?usp=sharing) draft regarding the 2025 scans. - [EduceLab Data Sheet (2023)](https://drive.google.com/file/d/1I6JNrR6A9pMdANbn6uAuXbcDNwjk8qZ2/view?usp=sharing): technical description of the 2023 scans. - [EduceLab-Scrolls (2023)](https://arxiv.org/abs/2304.02084): technical paper describing the original dataset work. ## How to Cite [section: /data#how-to-cite] If you use Vesuvius Challenge data in a publication or presentation, cite the dataset that corresponds to the scans you used. ### Vesuvius Challenge - CT Scans of Herculaneum Papyri [section: /data#vesuvius-challenge---ct-scans-of-herculaneum-papyri] Use this citation for newer scans released directly by Vesuvius Challenge: > Giorgio Angelotti, Stephen Parsons, Sean Johnson, Elian Rafael Dal Prà, Johannes Rudolph, Paul Tafforeau, Alessandro Mirone, Paul Henderson, Hendrik Schilling, Forrest McDonald, David Josey, Youssef Nader, C. Seth Parker, W. Brent Seales. *Vesuvius Challenge - CT Scans of Herculaneum Papyri*. Vesuvius Challenge. ### EduceLab-Scrolls [section: /data#educelab-scrolls] Scrolls 1-4 and Fragments 1-6 scanned at DLS before 2025 belong to the legacy EduceLab-Scrolls dataset. - In any published abstract, cite `EduceLab-Scrolls` as the source of the data. - In any published manuscripts using data from EduceLab-Scrolls, reference: Parsons, S., Parker, C. S., Chapman, C., Hayashida, M., & Seales, W. B. (2023). *EduceLab-Scrolls: Verifiable Recovery of Text from Herculaneum Papyri using X-ray CT*. ArXiv [Cs.CV]. https://doi.org/10.48550/arXiv.2304.02084. - Include language similar to the following in the methods section: "Data used in the preparation of this article were obtained from the EduceLab-Scrolls dataset [above citation]." ## Support [section: /data#support] - GitHub Issues: [Vesuvius Challenge repository](https://github.com/scrollprize/villa) - Community Forum: [Discord](https://discord.gg/V4fJhvtaQn) ## Licenses [section: /data#licenses] - [CC‑BY‑NC 4.0](https://creativecommons.org/licenses/by-nc/4.0/) (unless otherwise noted for specific assets) - Scrolls 1-4 and Fragments 1-6 scanned at DLS before 2025 are from the EduceLab-Scrolls Dataset, copyrighted by EduceLab/The University of Kentucky. Permission to use the data linked herein according to the terms outlined above is granted to Vesuvius Challenge, with additional citation requirements listed in [How to Cite](#how-to-cite). ===== PAGE: Data Browser ===== URL: https://scrollprize.org/data_browser STATUS: current This is the unified browser for all released samples (scrolls and fragments), grouped by sample ID and linked to their available artifacts. Formats, repositories, and organization are described on the [Data Formats](/data) page. Looking for dataset-specific citation guidance? See [How to Cite](/data#how-to-cite). ===== PAGE: Curated Datasets ===== URL: https://scrollprize.org/data_datasets STATUS: current # Curated Datasets July 2026 The data available through Vesuvius Challenge is large, frequently updated, and can be overwhelming to navigate. Here are some organized datasets suited for particular tasks or subproblems. Largely, these curate the segmentation efforts of our team and community. Click one of the datasets to find a download along with more information. ## `spiral-input` (2026-07) [section: /data_datasets#spiral-input-2026-07] A collection of same-winding and multi-winding annotations, in the form of: surface patches, line annotations, and point collections. This dataset contains manual annotations of the scroll wraps, recording which parts of the surface belong to the same wrap (*winding*) of the sheet for use as ground-truth inputs when fitting a global winding solution. It is organized by scroll. Each scroll below provides some combination of: verified and unverified surface patches (grid-topology quad meshes sampled on the papyrus surface), line annotations (curves traced across the surface), point collections, same-/relative-/absolute-winding annotations, and the fitted umbilicus. ### Paris4 [section: /data_datasets#paris4] Spiral annotations for scroll PHercParis4 (Scroll 1). Contents include ~27,000 verified and ~204,000 unverified surface patches, traced tracks, and point collections, together with `same_windings` / `relative_windings` / `abs_winding` graphs, the fitted `umbilicus`, fiber and outer-shell geometry, and the volume inputs used by the fitting pipeline (~49.6 GB total). - [README](/pathname:///data/datasets/spiral-input-PHercParis4-README.md) - [Browse on the data server](https://dl.ash2txt.org/datasets/spiral_datasets/PHercParis4/) - [Tutorial: Spiral Fitting](/tutorial_spiral) — how to fit a whole-scroll surface to these annotations ## `surface-labels` (2026-07) [section: /data_datasets#surface-labels-2026-07] Labeled papyrus surfaces: voxelized, recto (inside) sheet surfaces within the scroll volume. Voxelized surface segmentation that identifies the volumetric part of the papyrus we want to map. This dataset provides labels of the recto surfaces of the papyrus sheet, paired with the corresponding scroll volume data so they can be used directly as training inputs for machine-learning models. - [README](/pathname:///data/datasets/surface-labels-README.md) - [Browse on Hugging Face](https://huggingface.co/buckets/scrollprize/datasets/tree/surfaces) ## `ink-labels` (2026-07) [section: /data_datasets#ink-labels-2026-07] Binary ink masks aligned to surface volumes (2D) and scroll volumes (3D). Ink labels are binary images marking the location of ink on a papyrus surface. No infrared ground truth exists in scrolls — labels begin as hand-annotated ink strokes and are refined through iterative pseudo-labeling. Models trained on these labels can then detect ink elsewhere in the scrolls. - [README](/pathname:///data/datasets/ink-labels-README.md) - [Browse on Hugging Face](https://huggingface.co/buckets/scrollprize/datasets/tree/ink) Archived datasets — earlier pipeline generation Note (OUTDATED CONTENT): The datasets below describe an earlier generation of the Vesuvius Challenge pipeline. Tools, data layouts, and results referenced here may have been superseded. ## `fiber-skeletons` (2025-07) [section: /data_datasets#fiber-skeletons-2025-07] A dataset of manually annotated papyrus fibers - the individual strands that make up a papyrus sheet. Cubes of size 256^3 or 512^3 were selected from within the scroll, and inside each cube, every papyrus fiber was traced and labeled. The fibers have been converted to a volumetric/voxelized representation to be used as inputs to machine learning or other methods that expect 3D image data. - [README](https://dl.ash2txt.org/datasets/fiber-skeletons/README.txt) - [.zip download](https://dl.ash2txt.org/datasets/fiber-skeletons/fiber-skeletons.zip) (422 MB) ## `volumetric-instance-labels` (2024-10) [section: /data_datasets#volumetric-instance-labels-2024-10] Volumetric instance segmentation labels. This dataset contains a subset of Scroll 1, chunked into 256x256x256 cubes. For each cube, the original scroll volume data and the instance segmentation data are provided (each in `.nrrd` format). - [README](https://dl.ash2txt.org/full-scrolls/Scroll1/PHercParis4.volpkg/volumetric-instance-labels/README.txt) - [.zip download](https://dl.ash2txt.org/full-scrolls/Scroll1/PHercParis4.volpkg/volumetric-instance-labels/instance-labels-harmonized.zip) (1.4 GB) ## `grand-prize-banner-region` (2024-12) [section: /data_datasets#grand-prize-banner-region-2024-12] Data related to the 2023 Grand Prize (GP) region from Scroll 1. The dataset includes the scan volume and segmented surface meshes created by our segmentation team. We also provide predictions from machine learning [models](https://dl.ash2txt.org/ml-models/) that aim to segment the medial surface of the papyrus sheet. - [README](https://dl.ash2txt.org/datasets/grand-prize-banner-region/README.txt) - [gp_meshes.7z](https://dl.ash2txt.org/datasets/grand-prize-banner-region/gp_meshes.7z) (288 MB) - [gp_volume.zarr/](https://dl.ash2txt.org/datasets/grand-prize-banner-region/volumes/gp_volume.zarr) (77 GB) - [gp_tifstack.7z](https://dl.ash2txt.org/datasets/grand-prize-banner-region/volumes/gp_tifstack.7z) (389.9 GB) - [gp_legendary-medial-surfaces.7z](https://dl.ash2txt.org/datasets/grand-prize-banner-region/predictions/gp_legendary-medial-cubes.7z) (5.8 GB) - [gp_legendary-medial-surfaces-softmax.7z](https://dl.ash2txt.org/datasets/grand-prize-banner-region/predictions/gp_legendary-medial-cubes-softmax.7z) (146.8 GB) ===== PAGE: The Tutorials ===== URL: https://scrollprize.org/tutorial STATUS: archived These tutorials share the best tools and techniques for virtually unwrapping and reading carbonized papyrus scrolls. We expect you will build on these techniques, improving the tools and models. But of course, you may have better ideas, and are free to approach Vesuvius Challenge any way you think will work! There are five steps in our process for reading a carbonized scroll: Note (ARCHIVED): This page has been archived and is no longer maintained. It describes an earlier generation of the Vesuvius Challenge pipeline — tools, data layouts, and results referenced here may have been superseded. See [Open Problems](/2026_open_problems) for the current state of the pipeline and [Prizes](/prizes) for what is open today. 1. Scan: use X-ray tomography to create a 3D scan of a scroll or fragment. The digital twin is a volumetric image where each voxel (3D pixel) represents the average density of the material at the scan resolution. 2. Representation: choosing a digital or mathematical representation for data manipulation. Scanning outputs voxels in a 3D grid, but other options like point clouds exist. Switching between representations is possible if no important information is lost. 3. Segmentation: mapping and transforming the written surface into a flat, 2D projection and sampling nearby voxels to create a flattened volume that contains all surface features. 4. Ink Detection: identifying the inked regions in the flattened surface volume using a machine learning model 5. Read: decipher ink strokes, interpret meaning, unlock history ### Where we are now [section: /tutorial#where-we-are-now] Before we dive into the Herculaneum papyri with their [radiolucent](https://en.wikipedia.org/wiki/Radiodensity) ink, it's helpful to understand how the En-Gedi scroll was virtually unwrapped in 2015. Here is an excellent 2 minute overview of how this was achieved: Image stacks can be visualized using 3D volume rendering software. We will learn how to do this in the [Scanning Tutorial](/tutorial1). ### 2. Representation [section: /tutorial#2-representation] Input: 3D scan volume (.tif “image stack”). Output: modified 3D volume (.tif “image stack”), pointclouds (.ply), other? Rather than working directly from the raw scan volume, some of our techniques leverage various mathematical transformations to render new, processed volumes. Choosing an appropriate digital or mathematical representation is important for effectively manipulating the scroll data. While the raw scan is represented by voxels in a 3D grid, this isn’t the only option. For example, if we map each voxel to a point in Euclidean space based on its grid coordinates, we create a point cloud. Each representation has its own advantages and disadvantages and may be more suitable for certain geometrical processing and machine learning algorithms. As long as we retain all important information, we can switch between different representations as needed. The [Representation Tutorial](/tutorial2) provides an in-depth explanation of how to create representations and the reasons behind their use. ### 3. Segmentation [section: /tutorial#3-segmentation] Input: 3D volume (.tif “image stack”). Output: 3D flattened “surface volume” (.tif “image stack”) The goal of segmentation is to map and capture information near the written surface of the rolled papyrus scroll. Each section of the written surface that we have mapped within the 3D volume and converted into a surface volume is called a "segment". There are four steps to segmentation: * Map. Working from the chosen representation, map the surface (VC, Khartes) or volume (Slicer, Napari, Dragonfly) of the targeted scroll section. * Mesh. Once the surface has been mapped in three dimensions, we need to start preparing the ground to visualize the results. In computer vision, the common approach is triangulating the surface obtaining a “triangular mesh”. Triangular meshes allow coherent texturization and rendering of the surface for both enhanced 3D visualization and flattened 2D visualization. The triangular mesh is stored in a “.obj” file. * Subvolume. Sample voxels around the mesh to extract a subvolume containing information around the surface (surface volume). * Flatten. Transform this subvolume into a new .tif image stack where each layer is 2D, similar to creating a map of the earth on flat paper The output of this process is a flattened 3D volume of the voxels around the mapped surface, which we call a “surface volume”. This is again a .tif image stack, just like our original volume. However, it is much smaller than the original volume and more consistent since the papyrus always sits roughly in the middle of the volume. In ["Tutorial: Segmentation"](/segmentation) we’ll dive deeper into segmentation and virtual unwrapping, and in ["Tutorial: Spiral Fitting"](/tutorial_spiral) we show how to combine many small segments into a single coherent surface covering a whole scroll. ### 4. Ink detection [section: /tutorial#4-ink-detection] Input: 3D “surface volume” around the mesh (.tif “image stack”), hand-labeled binary mask Output: Predicted ink mask We use machine learning models to detect ink, training them on previously identified regions of ink. The trained models predict new regions of ink, which can be iteratively added to the training sets. Regions that contain ink can also be located via “persistent direct visual inspection” - staring at the surface volume images to identify characteristics of ink signal (crackle). Fragments have exposed regions of ink on the surface that can be photographed. The visibility of the ink is enhanced with IR imaging. IR photographs have been aligned with surface volumes of the top layer and included alongside binary masks for each fragment. Most fragments consist of multiple layers adhered together, which can be segmented to search for hidden ink. We go into great detail in [“Tutorial 5: Ink Detection”](/tutorial5). ### 5. Read [section: /tutorial#5-read] Input: One or more predicted ink masks. Output: Words, sentences, whole books, translations, journal papers, worldwide news coverage, eternal fame. Your work ends at ink detection. But for the world's papyrologists and classicists, this is where the excitement begins! Papyrologists can often extract more information than you might think. They are used to working with damaged, incomplete information, interpreting it, putting it into a historical context, and making history. ### Visual summary [section: /tutorial#visual-summary] ```mermaid %%{init: {'theme':'dark'}}%% graph TD classDef substep fill:#223B46 Scanning["1\. Micro-CT scan"]:::substep Papyrus([Papyrus scroll]) --> Scanning --> tif[/"Scroll volume (.tif stack)"/] Segmentation["2\. Segmentation"]:::substep tif --> Segmentation --> obj[/"3D mesh (.obj)"/] Volumes["3\. Flattening and rendering"]:::substep tif --> Volumes obj --> Volumes Volumes --> surfVol[/"Surface volume (.tif stack)"/] Alignment["4\. Ground data truth alignment"]:::substep Infrared[/Infrared photo/] --> Alignment --> alInf[/Aligned infrared/] --> labels[/Hand-labeled binary mask/] surfVol --> Alignment Ink["5\. Ink detection"]:::substep surfVol --> Ink labels --> Ink --> predInk[/Ink predictions/] Interpretation["6\. Interpretation"]:::substep predInk --> Interpretation --> Knowledge([New knowledge]) ``` ===== PAGE: Tutorial: Scanning ===== URL: https://scrollprize.org/tutorial1 STATUS: archived Note (ARCHIVED): This page has been archived and is no longer maintained. It describes an earlier generation of the Vesuvius Challenge pipeline — tools, data layouts, and results referenced here may have been superseded. See [Open Problems](/2026_open_problems) for the current state of the pipeline and [Prizes](/prizes) for what is open today. ### Campfire scroll [section: /tutorial1#campfire-scroll] To get a basic understanding of the kind of data we’re working with, it’s useful to look at it directly. Our goal will be to look at a scroll in two ways: 1) a “word soup” of floating letters, and 2) a mesh representation: We’ll use [Stephen Parsons’s](https://www2.cs.uky.edu/dri/stephen-parsons/) “campfire scroll” proxy (available on the [Data page](/data)). He made this scroll by writing on papyrus with both carbon ink (low contrast with papyrus in CT scans) and iron gall ink (high contrast with papyrus in CT scans). We won’t give away all the reference pictures, but here is the last page of the scroll: Stephen then _carbonized_ the scroll through a process that is similar to that of making charcoal: he rolled up the scroll, sealed it in a cookie tin with a tiny hole poked in the top, and heated the tin in a campfire. In a hot, oxygen-poor environment like the cookie tin, the papyrus turns to carbon rather than catching on fire. He then put the resulting carbonized scroll in a benchtop CT scanner (Bruker SkyScan 1173). ### Fiji [section: /tutorial1#fiji] Note: We now also have a community-contributed program that is worth trying out: [Scroll Viewer](https://github.com/lukeboi/scroll-viewer). We’ll use the [“Fiji”](https://imagej.net/software/fiji/downloads) open source program, which is a versatile tool for all sorts of image-based operations. It is a distribution of ImageJ, but the main version of ImageJ doesn’t include all the features we need. (In fact, “Fiji” is a recursive acronym for “Fiji Is Just ImageJ”.) Note (OS-specific instructions): * No known issues. * Even if you’re using an M1/M2 processor, please use the x86_64 version. * If you get a popup saying that the app can’t be opened, be sure to *right click > Open* to circumvent the blocking. * Alternatively, you can use the “Open Anyway” trick: go to *“System Preferences > Security & Privacy > General > Open Anyway”*. * We recommend downloading the `.app` portable application from their website, instead of using a package manager. It does require you to have the JVM installed. To follow along, download the tutorial data: [campfire.zip](https://gist.github.com/janpaul123/280262ebce904f7366fe4cc155593e90). In here there are three folders: * `raw`: the raw X-ray photos of the scroll. * `rec`: the reconstructed 3D image volume (“rec” = “reconstructed”). * `logs`: log files during scanning and reconstruction. Let’s start with `raw`. These are the raw X-ray photos of the scroll, taken in 0.15 degree steps for a full 360 degree rotation, so there are 2400 photos in total (you can see these details in `logs/carbonized01-45kV_.log` and `logs/carbonized01-45kV__TS.csv`). However, to keep this tutorial dataset small, we have resized these photos to 1/4th their size and kept only every 4th photo. This effectively reduces the voxel size of these scans from the original 26µm to 104µm. We also reduced the bit depth from 16 bits to 8 bits. We don’t typically use these photos directly, but they are useful to understand how CT scanning works. 1. In Fiji navigate to *“File > Import > Image Sequence”*. Then *“Browse”* to select `campfire/raw`. 2. The *“Count”* should show exactly 600. If the count is not exactly 600: double-check that the unzipping of the dataset resulted in multiple directories. Sometimes zip programs put all files inside one big directory. 3. Click *“OK”* to load the image stack. Note: If Fiji crashes, or you run into other issues, try to increase the memory limit: *“Edit > Options > Memory and Threads”.* Note that when you are loading a dataset that hasn’t been reduced in size beforehand, you can do that here. For example, we could have set *“Scale”* to *“25%”* and *“Step”* to *“4”*, to get a similar result. In the resulting scan you can vaguely see some features, perhaps even some ink, but it's hard to see what is actually in there: ### Volumes [section: /tutorial1#volumes] However, this is not yet the data we use for virtual unwrapping or machine learning. For that, these x-ray projection images are combined using a process called [tomographic reconstruction](https://en.wikipedia.org/wiki/Tomographic_reconstruction). This is typically done by software that comes with the CT scanner, so we already have done this, in our case using the Bruker SkyScan NRecon tool. The result of reconstruction is a 3D image, or volume, which is made up of 3D pixel cubes called voxels. The *voxel size* of the volume tells us the physical size of the cube, and the value stored in the voxel is an estimate of that location's radiodensity. Like the x-ray images, the volume is stored as a .tif image stack, but this time each image represents a slice along the “z” axis of the volume. * First close the existing window with the image stack. * Then open our reconstructed slices `campfire/rec` in the same way into Fiji (*“File > Import > Image Sequence”*). * The count should be 477 now. The result should look like this: In these images, radiodense materials have bright pixel values while more radiolucent materials have darker pixel values. As a result, you can see the iron gall ink light up quite clearly in these slices as bright lines which follow the wraps of the scroll. However, it’s impossible to make out any letters from this "top-down" view of the volume. * Go to *“Plugins > Volume Viewer”*. * It can take a while to load — there is a status bar with a loading bar on the main Fiji window. * In the top bar select *“Mode > Volume (4)” And *“Interpolation: Nearest Neighbor (0)” Check all 3 checkboxes at the bottom (*“Axes”*, *“Clipping”*, and *“Slice positions”*). * Click the *“xy”* button at the bottom so you get a top down view * Then click and drag up on the visualization to rotate it down. * Next, draw the alpha graph to be roughly a diagonal line. * The x-axis represents the brightness of the color (left = dark, right = bright). * The y-axis represents the opacity that we’ll draw with. * A diagonal line means low opacity (= high translucency) for dark colors, which makes the parts without ink transparent, so we can see the ink shine through. * You have to do the drawing in one go, because Fiji can hang for a while when it decides to rerender the image. * Now you can play with the *“Distance”* and *“Scale”* sliders. “Distance”* slices the volume away from the camera, revealing more of the inner structure. “Scale”* is simple zooming. * See if you can uncover the spiral on the last page of the scroll: Here is a video showing the whole process: That is a what we call a “word soup” — letters floating in the air. Our real datasets aren’t nearly as pretty as this, but this should give you some idea of what volumetric data of papyrus scrolls looks like in the best case scenario. However, it’s still hard to read anything. [“Tutorial 3: Segmentation and Flattening”](/tutorial3) should help with this. ### Meshes [section: /tutorial1#meshes] There is another way we can visualize the volume: we can convert it into triangles. A set of triangles is called a “mesh”, and it allows us to view our volume in tools that don’t support image stacks directly, which is sometimes useful. For this, we need to export to a mesh from Fiji: * Go back to the tomographically reconstructed image stack in Fiji (or import it again using *“File > Import > Image Sequence”*). * Go to *“Image > Type (at the very top) > RGB Color”* (this is required for the meshing algorithm). * Go to *“File > Save As > Wavefront .OBJ (near the bottom)” Now choose an intensity threshold above which we consider the object “solid”. A value of *“40”* works well for the campfire scroll. * Press *“OK”* and save the file somewhere. * Wait a moment until the file is saved. It should be around 400MB. Now, download and install [MeshLab](https://www.meshlab.net/#download). * Use *“File > Import”*, or drag the file into MeshLab. * It can take a while to import; there is a progress bar at the bottom. * In the right panel, click on the cylinder icon (see screenshot below), then click on *“Back-Face > Double”*. * Drag around using the left mouse button to rotate the mesh. You can quite clearly see the different pieces of papyrus, and even the container holding the scroll in place inside the scanner. However, all information of letters contained in the data is lost. We’ll use Meshlab in later tutorials, so it’s useful to have seen it. Here is a video where we navigate around the model in Meshlab: ===== PAGE: Tutorial: Representation ===== URL: https://scrollprize.org/tutorial2 STATUS: archived Note (ARCHIVED): This page has been archived and is no longer maintained. It describes an earlier generation of the Vesuvius Challenge pipeline — tools, data layouts, and results referenced here may have been superseded. See [Open Problems](/2026_open_problems) for the current state of the pipeline and [Prizes](/prizes) for what is open today. The micro-CT scan converts the scroll into a volumetric grid of density measurements, providing a mathematical description with integer coordinates and average material densities in small adjacent cubes known as voxels. While the raw scan volume represents the maximum amount of information available, this dataset is huge and the papyrus surface is difficult to locate throughout the scroll. Mathematical calculations and machine learning can be used to manipulate the digital dataset into different representations that are easier to interpret both visually and computationally. Besides the raw scan volume, three types of representations have been explored: Input: 3D scan volume (voxels in .tif “image stack”) Output: binary 3D volume (voxels in .tif “image stack”) Machine learning segmentation involves separating the part of the papyrus we wish to work with from the rest of the scan. We have trained models on a number of different papyrus features, but our current methods focus on two structures that exist within the scroll: The recto (inside) or verso (outside) surfaces, and the fibers which make up the papyrus sheet itself. In the image below, the purple lines mark the recto surface, giving us a much more tractable representation to work with on downstream tasks than the scan itself. ### Input: 3D scan volume (voxels in .tif “image stack”) Output: new 3D volume (voxels in .tif “image stack”) Traditional image processing techniques have mostly been intended to aid manual segmentation, either to make the papyrus easier to interpret or to help segmentation algorithms follow the surface better. Popular techniques include thresholding, noise reduction, various colourization schemes, edge detection, and skeletonization. Most of these techniques have not been successful at improving segmentation. Input: 3D scan volume (voxels in .tif “image stack”) Output: point cloud (.ply or .obj) The goal of point clouds is to extract a limited but useful subset of information from the raw scan volume. In the point cloud representation, calculations select voxels that describe the surface of a sheet. The fixed grid and density values are discarded, using traditional edge/surface detection to generate infinitesimal points characterized by 3D real coordinates. If needed, the discarded information can be reattached to the points to revert to the voxel representation. ## Semantic Segmentation of Scroll Structures [section: /tutorial2#semantic-segmentation-of-scroll-structures] This guide will focus on utilizing machine learning to create semantic segmentations of recto surfaces, but the same methods apply to any of our other datasets, such as fibers -- simply swap out the training images and their associated labels. It is written using Ubuntu 22.04, but the guide should translate to most any version of Linux. Windows users are advised to use WSL2 and place their data within the Linux filesystem. For this tutorial, we'll be using a library/framework known as [nnUNetv2](https://github.com/MIC-DKFZ/nnUNet) nnUNet is a well regarded and highly performant machine learning library with a focus on volumetric data within the medical domain, which has many parallels to our imaging modalities (namely xray tomography), and provides us with a fantastic baseline and starting point for experimentation. This is a simplified guide, it is highly recommended to visit [the repository](https://github.com/MIC-DKFZ/nnUNet) and read further after following this! ### Installing nnUNet and its Dependencies [section: /tutorial2#installing-nnunet-and-its-dependencies] Requirements - Working CUDA installation -- [Installation instructions](https://developer.nvidia.com/cuda-downloads) - Nvidia GPU with 10GB VRAM - 32GB CPU RAM (although you may be able to get by with a bit less) If you do not already have a virtual environment manager, install miniconda: ```bash wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh -b -p $HOME/miniconda3 source $HOME/miniconda3/bin/activate ``` Create a virtual environment for nnUNet: ```bash conda create -n nnunet python=3.10 conda activate nnunet ``` Install Pip within the Conda Environment (this is done because PyTorch no longer creates Conda packages) ```bash conda install pip ``` Install PyTorch ```bash pip install torch torchvision ``` Install nnUNetv2. If you wish to extend nnUNet, you can install in editable mode by following [these instructions](https://github.com/MIC-DKFZ/nnUNet/blob/master/documentation/installation_instructions.md#installation-instructions) ```bash pip install nnunetv2 ``` ### Data Preparation and Preprocessing [section: /tutorial2#data-preparation-and-preprocessing] Download and extract the [test dataset](https://dl.ash2txt.org/community-uploads/bruniss/nnunet_models/nnUNet_raw/Dataset060_s1_s4_s5_patches_frangiedt_test.zip). Choose a folder you'd like to store your nnUNet data in, and structure the folders like so, placing the dataset where indicated in the tree: ``` . └── nnUNet_data/ ├── nnUNet_raw/ │ └── Dataset060_s1_s4_s5_patches_frangiedt_test/ │ ├── imagesTr │ ├── labelsTr │ └── dataset.json ├── nnUNet_preprocessed └── nnUNet_results ``` You may notice by now that the images contain a suffix of _0000 while the labels do not. This suffix maps the images to a normalization scheme defined in `dataset.json`, for more information if desired, visit [this page](https://github.com/MIC-DKFZ/nnUNet/blob/master/documentation/explanation_normalization.md). nnUNet requires some information about where you have stored this dataset, which it accesses from environment variables. Set them for the current session with the following commands. You can make them permanent if you'd like by adding the same lines to your `~/.bashrc` file. ```bash export nnUNet_raw="/path/to/nnUNet_data/nnUNet_raw/" export nnUNet_preprocessed="/path/to/nnUNet_data/nnUNet_preprocessed/" export nnUNet_results="/path/to/nnUNet_data/nnUNet_results/" ``` Now we can begin the preprocessing stage. nnUNet will gather some information about your dataset, verify there is nothing wrong with it, and extract it into uncompressed numpy arrays. ```bash nnUNetv2_plan_and_preprocess -d 060 -pl nnUNetPlannerResEncM ``` This can take a few minutes, and will print some information as it goes. It should finish without errors. ### Training [section: /tutorial2#training] With our data preprocessed we can finally begin training. The command here will begin a training run using dataset `060` (the identifier for our test dataset), using the `3d_fullres` configuration, and fold `0`. nnUNet automatically creates 5 training folds for cross-validation on your dataset, and these splits can be modified in the `splits_final.json` which is generated after initiating training. You can run without any cross-validation by specifying `all` instead of a fold number. ```bash nnUNetv2_train 060 3d_fullres 0 -p nnUNetResEncUNetMPlans ``` nnUNet will extract the dataset, and begin training at epoch 0. While training runs it will print the progress in the terminal. The EMA pseudo dice is computed on a random validation batch, and shouldn't be taken as gospel, but can provide a relative idea of how well the training is going, provided you have not used the `all` fold. nnUNet will also store a graph that can be used to assess the current training run located in `/path/to/nnUNet_data/nnUNet_results/Dataset060_s1_s4_s5_patches_frangiedt_test/nnUNetTrainer__nnUNetResEncUNetMPlans__3d_fullres/fold_0/progress.png` This contains information about current learning rate and epoch time, but of particular interest is the top graph containing information about current psuedo dice and training and validation loss. Ideally, your bar should look like this -- where both training and validation loss are continuing to drop along similar paths. Towards the end, you can see my training loss continues to drop while my validation loss levels out, this tells us that the model is no longer improving on the validation data, and is likely beginning to overfit to the training data. This is not necessarily bad, but you would not want these lines to diverge too greatly. You can end training at any time by pressing `ctrl+c` in the terminal window, or allow training to continue for the default `max_epochs`, which for nnUNet is 1,000. ### Inference [section: /tutorial2#inference] To run inference with your newly trained model, you first need to ensure that the file names contain the same suffix as the ones you trained with. In our case, this is `_0000`. This example will run inference on all of P.Herc. 1667 to show the process of reconstructing the inference back to the original volume, you can simply download a single grid and run inference on only one if you only wish to see what the inference output looks like! Download the [Scroll 4 grids](https://dl.ash2txt.org/community-uploads/bruniss/scrolls/s4/grids/). These are 600x600x600 volumes, with the same naming convention as the original scroll grids, but with 50 voxels of overlap in all directions so that when we reconstruct it we can do so in a way that mitigates edge artifacts. Inference on this entire volume takes around 13 hours on two RTX 3090s. Note: If you stopped your training early, you'll need to go into the results folder in your nnUNet_results path, and change one of the checkpoints to `checkpoint_final.pth` Place the data in any folder, and run the command ```bash nnUNetv2_predict -d 060 -f 0 -c 3d_fullres -i /path/to/input/grids -o /path/to/output/grids -p nnUNetResEncUNetMPlans ``` for multi-gpu setups, you can run inference like so, repeating for as many gpus as you have available ```bash CUDA_VISIBLE_DEVICES=0 nnUNetv2_predict d 060 -f 0 -c 3d_fullres -i /path/to/input/folder -o /path/to/output/folder -p nnUNetResEncUNetMPlans -num_parts 2 -part_id 0 & CUDA_VISIBLE_DEVICES=1 nnUNetv2_predict d 060 -f 0 -c 3d_fullres -i /path/to/input/folder -o /path/to/output/folder -p nnUNetResEncUNetMPlans -num_parts 2 -part_id 1 ``` Note: To export the probabilities, append --save_probabilities to the end of the inference commands. This will save an npz and a pkl file, which you can turn into uint8 tifs with [this script](https://dl.ash2txt.org/community-uploads/bruniss/scrolls/helper-scripts/mp-softmax.py) Once inference has completed, download [this script](https://dl.ash2txt.org/community-uploads/bruniss/scrolls/helper-scripts/grids_to_zarr.py), and in the main block, change `map=False` to `map=True`, and change `Scroll='1'` to `Scroll='4'`. This will modify the pixel values of your inference (which are simply 0 for background and 1 for foreground) to 0 and 255, and map your grids to the proper volume shape. You can modify `max_workers` and `chunk_size` if desired. ```bash python grids_to_zarr.py ``` This script will add your blocks to a zarr array of the proper shape, and trim the 50 voxel overlaps we added previously. The result of this is a single resolution zarr. It is recommended to create a multi-resolution ome-zarr , by using [this script](https://github.com/KhartesViewer/scroll2zarr/blob/main/zarr_to_ome.py), written by Discord member @khartes_chuck. ```bash python zarr_to_ome.py /path/to/single_resolution.zarr /path/to/multi_resolution_ome.zarr --algorithm max ``` The final result is the predicted recto surface for the entirety of Scroll 4 that should be much easier to work with than the original scan data in downstream tasks. Volumes like this one are the inputs for methods used in our [next guide](/segmentation) on segmentation. ===== PAGE: Tutorial: Segmentation and Flattening ===== URL: https://scrollprize.org/tutorial3 STATUS: archived Note (ARCHIVED): This page has been archived and is no longer maintained. It describes an earlier generation of the Vesuvius Challenge pipeline — tools, data layouts, and results referenced here may have been superseded. See [Open Problems](/2026_open_problems) for the current state of the pipeline and [Prizes](/prizes) for what is open today. This tutorial walks through a slice-based approach to segmentation, which is helpful background for learning about the task. This was used to generate the 2023 [Grand Prize results](/grandprize). We are now working on more automated, 3D approaches to segmentation. Note: Please see the accompanying video tutorial for segmentation using Volume Cartographer here: https://www.youtube.com/watch?v=gdQmepxWhuY As we saw in the ["Scanning" tutorial](/tutorial1), it’s quite hard to extract useful information out of a “word soup”, even when the ink is quite clear. For this tutorial we’ll show how to use virtual unwrapping to produce a flattened image which shows the content clearly. Two key steps to virtually unwrapping a scroll or manuscript are _segmenting_ a surface from inside the 3D volume and _flattening_ that surface to 2D. The video below shows the idea quite well; or check out the [full version](https://youtu.be/VG8oOMHCg74?t=37) (It was made by Dr. Seales’s son and daughter!). The red line during the reconstruction phase represents the surface that we want to virtually unwrap. To perform segmentation, you have two choices of software: Khartes, and Volume Cartographer. Both of these choices have different strengths and weaknesses, but either can accomplish the task of accurate segmentation. Khartes relies on Volume Cartographer to perform the flattening portion of this guide. Thanks to @hari_seldon and @djosey of the segmentation team for their feedback and help with making this guide! Strengths: - Faster at creating larger segments - tool-assisted annotation, requiring less clicking - Entire pipeline in one application - No shape limitation (lines can turn in on themselves, can be fully circular) Weaknesses: - Can only segment on the Z plane, which is a challenge in some areas - No preview during segmentation - Relatively high hardware requirements Strengths: - View z, x, and y planes and segment on any of them - Interactive full scroll movement through ome-zarr - Minimal hardware requirements - Live view of segmentation results, enabling very high accuracy Weaknesses: - Is limited to creating segments that do not contain lines that turn back towards their origin, in essence limiting you to half circles at most. This can be severely limiting in some regions that have severe warping, and its hard to tell when you begin if a sheet will do this eventually. - Requires much more manual clicking than VC - Requires VC in some parts of the rendering / flattening pipeline Khartes is written by @khartes_chuck and has extensive documentation on github located [here](https://github.com/KhartesViewer/khartes). This guide will focus on [Volume Cartographer](https://github.com/educelab/volume-cartographer), a virtual unwrapping toolkit built by EduceLab’s Seth Parker. Volume Cartographer is designed to create meshes along surfaces of a manuscript (e.g. pages or scroll wraps) and then sample the voxels around these meshes to create a 2D image of the manuscript's contents. Volume Cartographer includes many tools and utilities. In this tutorial we’ll be looking at the main VC GUI as well as the vc_render tool. Volume Cartographer screenshots and recordings below are © EduceLab/University of Kentucky. The segmentation team uses a custom version of Volume Cartographer, initially forked by @RICHI and further enhanced by @spacegaier. These versions include significant improvements, such as Optical Flow Segmentation (OFS), substantial performance increases, ui improvements, and many other changes. The latest fork, maintained by @spacegaier, is available here: https://github.com/spacegaier/volume-cartographer. This guide uses this same version of VC. If you use a different version this guide will vary significantly from your experience, so it is highly recommended to use this version. ### Installing Volume Cartographer [section: /tutorial3#installing-volume-cartographer] To begin, let's install Volume Cartographer: Note (OS-specific instructions): 1. Install the [VcXsrv Windows X Server](https://sourceforge.net/projects/vcxsrv/) or a similar X Server (if you use the Chocolatey package manager: `choco install vcxsrv`). 2. Run *“XLaunch”* from the Start Menu, or from *“C:\Program Files\VcXsrv\xlaunch.exe”*. 3. Use the default settings, except: 4. Check that the X Server is running in the tray: 5. Install [Docker Desktop](https://docs.docker.com/desktop/install/windows-install/). 6. Pull the latest Docker image by running: ```bash docker pull ghcr.io/spacegaier/volume-cartographer:edge ``` Note: this does not install the fork of Volume Cartographer mentioned above. Install [Homebrew](https://brew.sh/). Run `brew install --no-quarantine educelab/casks/volume-cartographer`. * The GUI app will be installed to `/Applications/VC.app`. * The command line tools are installed to `\$(brew --prefix)/bin` and should be available in the terminal immediately (e.g. `vc_packager`) — if not, make sure you have `eval \$(/opt/homebrew/bin/brew shellenv)` in your shell profile and restart your terminal. If you prefer Docker, here are the steps: 1. Install XQuartz: https://www.xquartz.org/ 2. Log out and back into macOS. 3. Launch XQuartz. Under the XQuartz menu, select *“Preferences”*. 4. Go to the *“Security”* tab and ensure *“Allow connections from network clients”* is checked. 5. Quit XQuartz and restart it. 6. Install [Docker Desktop](https://docs.docker.com/desktop/install/mac-install/). 7. Pull the latest Docker image by running: ```bash docker pull ghcr.io/spacegaier/volume-cartographer:edge ``` 8. Then run: ```bash xhost +localhost ``` * We assume that you’re running the X Window System (if you’re unsure, you probably do). * First, install [Docker](https://docs.docker.com/engine/install/). Do *not* use Snap to install it. * Pull the latest Docker image by running: ```bash docker pull ghcr.io/spacegaier/volume-cartographer:edge ``` * Then run: ```bash xhost +local:docker ``` * First, install basic [build dependencies](https://github.com/educelab/volume-cartographer/blob/develop/README.md) like `build-essential`, `cmake`, and Qt6. * Then: ```bash # Recursive clone, so we get the vc-deps repo, which contains dependencies. git clone --recursive https://github.com/spacegaier/volume-cartographer.git # Build vc-deps. cd volume-cartographer/vc-deps mkdir build && cd build cmake -DCMAKE_BUILD_TYPE=Release .. make -j # Build main app. cd ../.. mkdir build && cd build cmake -DVC_PREBUILT_LIBS=ON -DCMAKE_BUILD_TYPE=Release .. make -j # Install, or skip this and refer directly to the executables in build/bin. make install ``` ### Gathering data [section: /tutorial3#gathering-data] Now let's gather our scroll data and setup our folders... We're going to start with Scroll 1 (PHerc. Paris 4) as this is the scroll that the 2023 Grand Prize segments were from, and is also the easiest of the current scrolls to segment. VC requires all of the folders listed under the PHercParis4.volpkg, in addition to the config.json and meta.json files. This is the recommended structure for the full_scrolls folder (with a full example given for Scroll1): ``` full_scrolls/ ├── Scroll1/ │ └── PHercParis4.volpkg/ │ ├── volumes/ │ │ └── 20230205180739/ │ │ ├── 00000.tif │ │ ├── . │ │ ├── . │ │ ├── 14375.tif │ │ └── meta.json │ ├── paths │ ├── renders │ ├── working │ └── config.json ├── Scroll2 │ └── PHercParis3.volpkg/ ├── Scroll3 │ └── PHerc332.volpkg/ └── Scroll4 └── PHerc1667.volpkg/ ``` And this is the recommended structure for your new_segments folder: ``` new_segments/ ├── Scroll1 ├── Scroll2 ├── Scroll3 ├── Scroll4 └── run_vc.sh ``` To download the data, first navigate to the `/volumes/20230205180739` directory. You can also place the files in `/volumes/20230205180739` after they are downloaded. Use this `rclone` command to download all of the Scroll 1 volumes quickly: ```bash rclone copy :http:/full-scrolls/Scroll1/PHercParis4.volpkg/volumes/20230205180739/ . --http-url https://dl.ash2txt.org/ --progress --size-only ``` If you wish to begin with a smaller portion of Scroll 1, rather than the entire scroll, you can download 1cm of scan data from the center using: ```bash for i in `seq 6000 7250`; do wget http://dl.ash2txt.org/full-scrolls/Scroll1/PHercParis4.volpkg/volumes/20230205180739/0\$i.tif; done ``` Be sure to have the config.json file at the root of the `.volpkg` directory, and the meta.json file in the `volumes` directory so that VC can work with it. More information can be found at the [Vesuvius Data Download Repo](https://github.com/JamesDarby345/VesuviusDataDownload). ### Running the Volume Cartographer GUI [section: /tutorial3#running-the-volume-cartographer-gui] We will use the main `VC` GUI app to perform segmentation: finding a surface of papyrus and exporting it as a 3D mesh. Note: This guide was written using Linux. Most of the commands are similar, but you may need to remove 'sudo' from the front of the commands depending on your operating system. The -v switch used below is mapping a local path (or volume) to the Docker container. To check if your paths have been created properly you can run the Docker container and initiate a list command by typing: ```bash docker run -v \path\to\full_scrolls\:/full_scrolls ghcr.io/spacegaier/volume-cartographer:edge ls ``` If you see your scroll folders, you’ve probably mapped this correctly. Open a terminal and run (replacing the paths with your folder paths to the same folders): ```bash sudo docker run -v /path/to/new_segments/:/new_segments -v /path/to/full_scrolls/:/full_scrolls -e DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix ghcr.io/spacegaier/volume-cartographer:edge VC ``` Let's take a moment to get oriented before continuing: 1. In the top left are the current segmentations, or paths, in the current volume package (from here on referred to as a volpkg) along with the file, edit, help and view buttons. 2. In the bottom left are the current segmentation runs and anchor information for the currently selected segment id. 3. On the right are your OFS Segmentation settings. 4. Located at the bottom is some navigation information. The primary number useful to you here will be the current slice number. ### Navigating a .volpkg [section: /tutorial3#navigating-a-volpkg] Now that we’ve oriented ourselves with the UI, let's open our .volpkg... 1. Open a .volpkg by clicking file, then open .volpkg, and select the .volpkg for the volume you wish to segment on, ensuring you select the .volpkg folder, and not one of the subfolders. Click choose, and the volume will open at slice 0. 2. Practice scrolling through the volume, using shift+scroll wheel to move up and down through slice layers, and ctrl+scroll wheel to zoom in and out. You can right click and drag to pan around the slice. Move through the layers until you find an area of the sheet that looks “easy” to segment. An ideal area has spacing on the inside face towards the center of the scroll, and maintains this spacing as you scroll through the layers for a time. You can increase the amount of slices you move through with the scroll wheel by pressing Q and E. The small number that shows up next to your cursor is the number of slices skipped each “click” of the scroll wheel. 3. Look now to the top left in the segments window; our VC shows some segmentations in the segmentation window, but yours at this point will be blank. ### Creating a segment [section: /tutorial3#creating-a-segment] We will now create our first segment. Click "New" in the Volume Package segmentation window on the top left to create a new segment path. Ensure "Display" and "Compute" are both checked. Click “Pen Tool”, and place points along the sheet by left clicking, placing as many points as necessary to keep the line on the surface of the sheet. Note that you cannot undo or delete points here. This part does not need to be particularly accurate, as you’ll be able to fix it in the next step much easier. When you are happy with the length of the line, click pen tool once again to exit the pen tool. You’ll notice now that the purple line becomes a series of points. This is your “segmentation line”. It is from this line that VC will create your final flattened surface volume. Ideally, you want this to be on the inside face of the sheet, as this is where we expect to find ink. Now, click “Segmentation Tool” (You can also enter the segmentation tool by pressing 'T'). Let’s configure our Segmentation settings in the right box to match the ones in this image. The primary parameter you could modify here and see if you have any improvement is 'smoothen curve at bright points'. If at this point your segmentation line is off the sheet, you can manipulate it in a few ways. The primary method for manipulating this line is to “snap” it to a point, by clicking. VC will take the X nearest points to the cursor (where X is the input range setting located in the bottom right, also in/decreased by hitting A and D respectively) and snap them to the cursor. You can also click and drag the line itself. Play around with this for a bit before continuing. In addition to just panning along the line with right click, you can press R+Scroll Wheel to follow the segmentation line automatically. This is also mapped to the front and back side mouse buttons, if you have them. Once you are happy with the location of the line, ensure your slice and anchor settings are correct. If you’re going “up” in the volume, you want forward slice and backward anchor, and conversely if you're going “down” in the volume, you want a forward anchor and “backward slice”. The number in the forward or backward slice is the number the segmentation run will finish at. It is recommended to start low here, between 30 and 50, and depending on how far the line diverges from the sheet, you can increase from there. In areas of particularly damaged papyrus values as low as 10 can be required. Click “Start” to begin the segmentation run. After a short period of time VC will drop you off at the slice indicated by your previous forward or backward slice setting. Your line of points will now be colored red, and may have wandered slightly from the sheet. VC has attempted to “follow” the sheet from your annotation (or anchor) line to the slice indicated in your forward slice setting. From here, click “segmentation tool” again, and then manipulate the line back onto the sheet. You’ll notice lines you have modified turn yellow, where ones you have not remain red. Pan through the layers a bit if you are having a hard time following the sheet, as it's easier to follow “in motion”. Press space to hide the line if it helps you see. Note: You can press T at any time within the segmentation tool to return to the slice you began the segmentation on. After you’ve guided the line along the sheet, hit “Start” again, and repeat the process. This is the general workflow for segments of any size, from the GP winners at over 100cm^2 to the smallest segments. Conceptually, it works something like this: Be sure to save it using *“File > Save volpkg”*. You can keep segmenting for a bit here to get the hang of VC, but keep the size manageable for your first few segments until you get more familiar. The process completed during this step looks like this in 3D. We've identified the sheet surface, but still would have a hard time finding ink on a single voxel sheet that is still wrapped in the scroll. In the video below, the sheet is on the visible outside, but most of our segments are completely surrounded by additional sheets. ### Flattening and texturing [section: /tutorial3#flattening-and-texturing] Ok, we've got a line...Now what? In order to see the content on the surface of our segment, we need to flatten and texture the segment. These steps can be run individually, but it’s highly suggested to use the following process so that you end up with the same format and files as the official segmentations. Let's create a bash script to combine a number of different VC apps into one single command: 1. Open a basic text editor (ex: Notepad) 2. Copy this code block into the editor ```BASH #!/bin/bash # Set environment variables export SEGMENT=20240227040603 #change to the segment number you've created export SCROLL="Scroll1/PHercParis4.volpkg" #change to whatever scroll you are currently working in # Navigate to the segment folder, create a directory named after \$SEGMENT cd \${SCROLL} mkdir -p "\${SEGMENT}" cd "\${SEGMENT}" # Copy necessary files from the scroll folder to the current directory cp "/full_scrolls/\${SCROLL}/paths/\${SEGMENT}/pointset.vcps" . cp "/full_scrolls/\${SCROLL}/paths/\${SEGMENT}/meta.json" . cp "/full_scrolls/\${SCROLL}/paths/\${SEGMENT}/pointset.vcano" . # Convert and render pointset, then generate layers and calculate area nice vc_convert_pointset -i pointset.vcps -o "\${SEGMENT}_points.obj" nice vc_render -v "/full_scrolls/\${SCROLL}/" -s "\${SEGMENT}" -o "\${SEGMENT}.obj" --output-ppm "\${SEGMENT}.ppm" --intermediate-mesh "\${SEGMENT}_intermediate_mesh.obj" --save-graph 0 --orient-normals mkdir -p layers nice vc_layers_from_ppm -v "/full_scrolls/\${SCROLL}" -p "\${SEGMENT}.ppm" --output-dir layers/ -r 32 -f tif --cache-memory-limit 50G vc_area "/full_scrolls/\${SCROLL}" \${SEGMENT} | grep cm | awk '{print \$2}' | tee area_cm2.txt # Set author name echo '' > author.txt ``` 3. Modify the environment variables at the top of the script, the ones that begin with `export`, and the author at the bottom. You'll want these values to reflect the scroll you're working in, the name of your segment, and who you'd like to list as the author. 4. Name the script `run_vc.sh` and save it to the 'new_segments' directory Once we have our script created and have the right values for the environment variables, we can now execute the flattening pipeline. Open a new terminal (not the one you have the GUI running in), and enter ```bash sudo docker run -it -v /path/to/new_segments/:/new_segments -v /path/to/full_scrolls/:/full_scrolls -e DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix ghcr.io/spacegaier/volume-cartographer:edge VC ``` The terminal for the container should open. Enter the following lines: ```bash cd /new_segments/ /bin/bash run_vc.sh ``` This command will render your points into a mesh, and then create the surface volume layers from it. This can take a long time depending on the size of your segment, but thankfully you will get some progress information on the console. Congratulations! You've completed your first segment! In the new_segments directory you set when you launched VC, you will now have a folder with the name of your new segment, and within that folder a folder called `layers/`, and a number of different files, the most important of which are detailed below. Much of this information was gathered from @Seth P. and @khartes_chuck on the discord: * `layers/` contains files numbered 00.tif to 64.tif (or 000.tif to 156.tif for 3.24um scans). These are slices of the surface volume, each of a thickness equal to the voxel size of the scroll you are currently segmenting, typically what we call “low res” are the 7.91um voxel spacing, and “high res” would be 3.24um voxel spacing. For a 7.91um volume, this means that each surface volume is 64 tifs * 7.91um, for about 506um thickness, or .506mm. * `.obj` this is a 3D image format that stores information about the geometry of a 3D model, such as vertex positions, texture maps, normals, and faces. This is a mesh created from the pointset created by your segmentation line and detailed further below. * `.tif` is a composite image of maximum intensity pixels from within the surface volume, it is also used for texturing in combination with the mtl file. * `.mtl` is a text file that contains information about the material, such as opacity, reflectivity, and points to the texture file (the tif in the previous line). * `.ppm` A simple way to think about this is to think of it as a super dense point cloud that for each voxel in the flattened volume contains a point representing the 3d location in the original volume that voxel came from, and some information about that point. A better explanation is that a .ppm is special case of an ordered pointset, where type = double and dim = 6. It is generated by flattening the segmented surface, discretizing the parameterization, and storing the corresponding 3D point and surface normal for each spot on the surface. Using slice notation, ppm[y, x, 0:3] stores the 3D point and ppm[y, x, 3:6] stores the surface normal. Because the surface does not fill the 2D array entirely, there is a *_mask.png file next to the PPM. It stores which pixels in the PPM have valid values. More info here: Volume Cartographer PPM file format (github.com) * `_mask.png` as detailed in the ppm description, just denotes areas that do not contain information from the scroll data. * `.vcps` this is the pointset created by your segmentation line. A .vcps file stores lists or 2D arrays of N-dimensional, numerical vectors. It starts with a header as described, then the points are written in sequence, usually in binary and rarely in ASCII. The type field in the header tells you the fundamental C++ type stored. * `.vcano` contains information about which points were manually moved, and their original locations. * `Author.txt` contains the name of the person who created it. * `Area_cm2.txt` is simply the size of the segment in cm^2. ### Outputs [section: /tutorial3#outputs] So, what did we just do? When looking for ink in the volume, we need to look at more than just the voxels that directly intersect the segment mesh we just created. We also need to look a little bit “above“ and “below“ the mesh, at the neighborhood of voxels that surround our segment. Conceptually, this neighborhood looks something like this (though this video is exaggerated): To generate the composite .tif file, called `.tif`, `vc_render` searched through this neighborhood, gathering the voxel intensities, and placed the results of that search in the flattened output image. The ppm file that we generated contains a mapping between our flattened output image and the original 3D surface. With this file, we transformed the 3D neighborhood into a simplified surface volume. That process looks something like this: The result of this process are the 65 tifs in the /layers/ directory. Each of these .tif images is a "slice" of the surface volume, with 32.tif ideally representing the middle, or the area directly on your segmentation line. ### Ink detection [section: /tutorial3#ink-detection] So, where's the ink? By now you'll notice that, contrary to the ink in some scrolls, the ink in our scrolls is not readily detectable in your images. The reason for this is that not all inks have the same radio-density. Some inks, like iron gall, show up quite clearly in CT scans because they absorb more x-rays than the papyrus on which they sit. This creates _high contrast_ between the bright iron gall ink voxels and the less bright papyrus voxels. Carbon-based inks, on the other hand, have a very similar radio-density to papyrus and thus have _low contrast_ when compared against the papyrus voxels. More often than not, the contrast is so low for carbon ink that it is very difficult to differentiate the ink from the papyrus when looking at the volume data with the naked eye. Thankfully, as you'll learn in our next tutorial on [“Ink Detection”](/tutorial5), even very difficult to detect ink can still be found... ===== PAGE: Volume Cartographer (Segmentation) ===== URL: https://scrollprize.org/tutorial_VC STATUS: archived Note (ARCHIVED): This page has been archived and is no longer maintained. It describes an earlier generation of the Vesuvius Challenge pipeline — tools, data layouts, and results referenced here may have been superseded. See [Open Problems](/2026_open_problems) for the current state of the pipeline and [Prizes](/prizes) for what is open today. Volume Cartographer was used to generate the 2023 [Grand Prize results](/grandprize). This guide was made by @bruniss with feedback and help from @hari_seldon and @djosey of the segmentation team. Note: Please see the accompanying video tutorial for segmentation using Volume Cartographer here: https://www.youtube.com/watch?v=gdQmepxWhuY Volume Cartographer has been a popular option for manual segmentation. Strengths: - Fastest manual tool for creating accurate, large segments - Tool-assisted annotation, requiring less clicking - Entire pipeline in one application Weaknesses: - Can only segment on the Z plane, which is a challenge in some areas - No preview during segmentation - Relatively high hardware requirements This guide will focus on [Volume Cartographer](https://github.com/educelab/volume-cartographer), a virtual unwrapping toolkit built by EduceLab’s Seth Parker. Volume Cartographer is designed to create meshes along surfaces of a manuscript (e.g. pages or scroll wraps) and then sample the voxels around these meshes to create a 2D image of the manuscript's contents. Volume Cartographer includes many tools and utilities. In this tutorial we’ll be looking at the main VC GUI as well as the vc_render tool. Volume Cartographer screenshots and recordings below are © EduceLab/University of Kentucky. The segmentation team uses a custom version of Volume Cartographer, initially forked by @RICHI and further enhanced by @spacegaier. These versions include significant improvements, such as Optical Flow Segmentation (OFS), substantial performance increases, ui improvements, and many other changes. The latest fork, maintained by @spacegaier, is available here: https://github.com/spacegaier/volume-cartographer. This guide uses this same version of VC. If you use a different version this guide will vary significantly from your experience, so it is highly recommended to use this version. ### Installing Volume Cartographer [section: /tutorial_VC#installing-volume-cartographer] To begin, let's install Volume Cartographer: Note (OS-specific instructions): 1. Install the [VcXsrv Windows X Server](https://sourceforge.net/projects/vcxsrv/) or a similar X Server (if you use the Chocolatey package manager: `choco install vcxsrv`). 2. Run *“XLaunch”* from the Start Menu, or from *“C:\Program Files\VcXsrv\xlaunch.exe”*. 3. Use the default settings, except: 4. Check that the X Server is running in the tray: 5. Install [Docker Desktop](https://docs.docker.com/desktop/install/windows-install/). 6. Pull the latest Docker image by running: ```bash docker pull ghcr.io/spacegaier/volume-cartographer:edge ``` Note: this does not install the fork of Volume Cartographer mentioned above. Install [Homebrew](https://brew.sh/). Run `brew install --no-quarantine educelab/casks/volume-cartographer`. * The GUI app will be installed to `/Applications/VC.app`. * The command line tools are installed to `\$(brew --prefix)/bin` and should be available in the terminal immediately (e.g. `vc_packager`) — if not, make sure you have `eval \$(/opt/homebrew/bin/brew shellenv)` in your shell profile and restart your terminal. If you prefer Docker, here are the steps: 1. Install XQuartz: https://www.xquartz.org/ 2. Log out and back into macOS. 3. Launch XQuartz. Under the XQuartz menu, select *“Preferences”*. 4. Go to the *“Security”* tab and ensure *“Allow connections from network clients”* is checked. 5. Quit XQuartz and restart it. 6. Install [Docker Desktop](https://docs.docker.com/desktop/install/mac-install/). 7. Pull the latest Docker image by running: ```bash docker pull ghcr.io/spacegaier/volume-cartographer:edge ``` 8. Then run: ```bash xhost +localhost ``` * We assume that you’re running the X Window System (if you’re unsure, you probably do). * First, install [Docker](https://docs.docker.com/engine/install/). Do *not* use Snap to install it. * Pull the latest Docker image by running: ```bash docker pull ghcr.io/spacegaier/volume-cartographer:edge ``` * Then run: ```bash xhost +local:docker ``` * First, install basic [build dependencies](https://github.com/educelab/volume-cartographer/blob/develop/README.md) like `build-essential`, `cmake`, and Qt6. * Then: ```bash # Recursive clone, so we get the vc-deps repo, which contains dependencies. git clone --recursive https://github.com/spacegaier/volume-cartographer.git # Build vc-deps. cd volume-cartographer/vc-deps mkdir build && cd build cmake -DCMAKE_BUILD_TYPE=Release .. make -j # Build main app. cd ../.. mkdir build && cd build cmake -DVC_PREBUILT_LIBS=ON -DCMAKE_BUILD_TYPE=Release .. make -j # Install, or skip this and refer directly to the executables in build/bin. make install ``` ### Gathering data [section: /tutorial_VC#gathering-data] Now let's gather our scroll data and setup our folders... We're going to start with Scroll 1 (PHerc. Paris 4) as this is the scroll that the 2023 Grand Prize segments were from, and is also the easiest of the current scrolls to segment. VC requires all of the folders listed under the PHercParis4.volpkg, in addition to the config.json and meta.json files. This is the recommended structure for the full_scrolls folder (with a full example given for Scroll1): ``` full_scrolls/ ├── Scroll1/ │ └── PHercParis4.volpkg/ │ ├── volumes/ │ │ └── 20230205180739/ │ │ ├── 00000.tif │ │ ├── . │ │ ├── . │ │ ├── 14375.tif │ │ └── meta.json │ ├── paths │ ├── renders │ ├── working │ └── config.json ├── Scroll2 │ └── PHercParis3.volpkg/ ├── Scroll3 │ └── PHerc332.volpkg/ └── Scroll4 └── PHerc1667.volpkg/ ``` And this is the recommended structure for your new_segments folder: ``` new_segments/ ├── Scroll1 ├── Scroll2 ├── Scroll3 ├── Scroll4 └── run_vc.sh ``` To download the data, first navigate to the `/volumes/20230205180739` directory. You can also place the files in `/volumes/20230205180739` after they are downloaded. Use this `rclone` command to download all of the Scroll 1 volumes quickly: ```bash rclone copy :http:/full-scrolls/Scroll1/PHercParis4.volpkg/volumes/20230205180739/ . --http-url https://dl.ash2txt.org/ --progress --size-only ``` If you wish to begin with a smaller portion of Scroll 1, rather than the entire scroll, you can download 1cm of scan data from the center using: ```bash for i in `seq 6000 7250`; do wget http://dl.ash2txt.org/full-scrolls/Scroll1/PHercParis4.volpkg/volumes/20230205180739/0\$i.tif; done ``` Be sure to have the config.json file at the root of the `.volpkg` directory, and the meta.json file in the `volumes` directory so that VC can work with it. More information can be found at the [Vesuvius Data Download Repo](https://github.com/JamesDarby345/VesuviusDataDownload). ### Running the Volume Cartographer GUI [section: /tutorial_VC#running-the-volume-cartographer-gui] We will use the main `VC` GUI app to perform segmentation: finding a surface of papyrus and exporting it as a 3D mesh. Note: This guide was written using Linux. Most of the commands are similar, but you may need to remove 'sudo' from the front of the commands depending on your operating system. The -v switch used below is mapping a local path (or volume) to the Docker container. To check if your paths have been created properly you can run the Docker container and initiate a list command by typing: ```bash docker run -v \path\to\full_scrolls\:/full_scrolls ghcr.io/spacegaier/volume-cartographer:edge ls ``` If you see your scroll folders, you’ve probably mapped this correctly. Open a terminal and run (replacing the paths with your folder paths to the same folders): ```bash sudo docker run -v /path/to/new_segments/:/new_segments -v /path/to/full_scrolls/:/full_scrolls -e DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix ghcr.io/spacegaier/volume-cartographer:edge VC ``` Let's take a moment to get oriented before continuing: 1. In the top left are the current segmentations, or paths, in the current volume package (from here on referred to as a volpkg) along with the file, edit, help and view buttons. 2. In the bottom left are the current segmentation runs and anchor information for the currently selected segment id. 3. On the right are your OFS Segmentation settings. 4. Located at the bottom is some navigation information. The primary number useful to you here will be the current slice number. ### Navigating a .volpkg [section: /tutorial_VC#navigating-a-volpkg] Now that we’ve oriented ourselves with the UI, let's open our .volpkg... 1. Open a .volpkg by clicking file, then open .volpkg, and select the .volpkg for the volume you wish to segment on, ensuring you select the .volpkg folder, and not one of the subfolders. Click choose, and the volume will open at slice 0. 2. Practice scrolling through the volume, using shift+scroll wheel to move up and down through slice layers, and ctrl+scroll wheel to zoom in and out. You can right click and drag to pan around the slice. Move through the layers until you find an area of the sheet that looks “easy” to segment. An ideal area has spacing on the inside face towards the center of the scroll, and maintains this spacing as you scroll through the layers for a time. You can increase the amount of slices you move through with the scroll wheel by pressing Q and E. The small number that shows up next to your cursor is the number of slices skipped each “click” of the scroll wheel. 3. Look now to the top left in the segments window; our VC shows some segmentations in the segmentation window, but yours at this point will be blank. ### Creating a segment [section: /tutorial_VC#creating-a-segment] We will now create our first segment. Click "New" in the Volume Package segmentation window on the top left to create a new segment path. Ensure "Display" and "Compute" are both checked. Click “Pen Tool”, and place points along the sheet by left clicking, placing as many points as necessary to keep the line on the surface of the sheet. Note that you cannot undo or delete points here. This part does not need to be particularly accurate, as you’ll be able to fix it in the next step much easier. When you are happy with the length of the line, click pen tool once again to exit the pen tool. You’ll notice now that the purple line becomes a series of points. This is your “segmentation line”. It is from this line that VC will create your final flattened surface volume. Ideally, you want this to be on the inside face of the sheet, as this is where we expect to find ink. Now, click “Segmentation Tool” (You can also enter the segmentation tool by pressing 'T'). Let’s configure our Segmentation settings in the right box to match the ones in this image. The primary parameter you could modify here and see if you have any improvement is 'smoothen curve at bright points'. If at this point your segmentation line is off the sheet, you can manipulate it in a few ways. The primary method for manipulating this line is to “snap” it to a point, by clicking. VC will take the X nearest points to the cursor (where X is the input range setting located in the bottom right, also in/decreased by hitting A and D respectively) and snap them to the cursor. You can also click and drag the line itself. Play around with this for a bit before continuing. In addition to just panning along the line with right click, you can press R+Scroll Wheel to follow the segmentation line automatically. This is also mapped to the front and back side mouse buttons, if you have them. Once you are happy with the location of the line, ensure your slice and anchor settings are correct. If you’re going “up” in the volume, you want forward slice and backward anchor, and conversely if you're going “down” in the volume, you want a forward anchor and “backward slice”. The number in the forward or backward slice is the number the segmentation run will finish at. It is recommended to start low here, between 30 and 50, and depending on how far the line diverges from the sheet, you can increase from there. In areas of particularly damaged papyrus values as low as 10 can be required. Click “Start” to begin the segmentation run. After a short period of time VC will drop you off at the slice indicated by your previous forward or backward slice setting. Your line of points will now be colored red, and may have wandered slightly from the sheet. VC has attempted to “follow” the sheet from your annotation (or anchor) line to the slice indicated in your forward slice setting. From here, click “segmentation tool” again, and then manipulate the line back onto the sheet. You’ll notice lines you have modified turn yellow, where ones you have not remain red. Pan through the layers a bit if you are having a hard time following the sheet, as it's easier to follow “in motion”. Press space to hide the line if it helps you see. Note: You can press T at any time within the segmentation tool to return to the slice you began the segmentation on. After you’ve guided the line along the sheet, hit “Start” again, and repeat the process. This is the general workflow for segments of any size, from the GP winners at over 100cm^2 to the smallest segments. Conceptually, it works something like this: Be sure to save it using *“File > Save volpkg”*. You can keep segmenting for a bit here to get the hang of VC, but keep the size manageable for your first few segments until you get more familiar. The process completed during this step looks like this in 3D. We've identified the sheet surface, but still would have a hard time finding ink on a single voxel sheet that is still wrapped in the scroll. In the video below, the sheet is on the visible outside, but most of our segments are completely surrounded by additional sheets. ### Flattening and texturing [section: /tutorial_VC#flattening-and-texturing] Ok, we've got a line...Now what? In order to see the content on the surface of our segment, we need to flatten and texture the segment. These steps can be run individually, but it’s highly suggested to use the following process so that you end up with the same format and files as the official segmentations. Let's create a bash script to combine a number of different VC apps into one single command: 1. Open a basic text editor (ex: Notepad) 2. Copy this code block into the editor ```BASH #!/bin/bash # Set environment variables export SEGMENT=20240227040603 #change to the segment number you've created export SCROLL="Scroll1/PHercParis4.volpkg" #change to whatever scroll you are currently working in # Navigate to the segment folder, create a directory named after \$SEGMENT cd \${SCROLL} mkdir -p "\${SEGMENT}" cd "\${SEGMENT}" # Copy necessary files from the scroll folder to the current directory cp "/full_scrolls/\${SCROLL}/paths/\${SEGMENT}/pointset.vcps" . cp "/full_scrolls/\${SCROLL}/paths/\${SEGMENT}/meta.json" . cp "/full_scrolls/\${SCROLL}/paths/\${SEGMENT}/pointset.vcano" . # Convert and render pointset, then generate layers and calculate area nice vc_convert_pointset -i pointset.vcps -o "\${SEGMENT}_points.obj" nice vc_render -v "/full_scrolls/\${SCROLL}/" -s "\${SEGMENT}" -o "\${SEGMENT}.obj" --output-ppm "\${SEGMENT}.ppm" --intermediate-mesh "\${SEGMENT}_intermediate_mesh.obj" --save-graph 0 --orient-normals mkdir -p layers nice vc_layers_from_ppm -v "/full_scrolls/\${SCROLL}" -p "\${SEGMENT}.ppm" --output-dir layers/ -r 32 -f tif --cache-memory-limit 50G vc_area "/full_scrolls/\${SCROLL}" \${SEGMENT} | grep cm | awk '{print \$2}' | tee area_cm2.txt # Set author name echo '' > author.txt ``` 3. Modify the environment variables at the top of the script, the ones that begin with `export`, and the author at the bottom. You'll want these values to reflect the scroll you're working in, the name of your segment, and who you'd like to list as the author. 4. Name the script `run_vc.sh` and save it to the 'new_segments' directory Once we have our script created and have the right values for the environment variables, we can now execute the flattening pipeline. Open a new terminal (not the one you have the GUI running in), and enter ```bash sudo docker run -it -v /path/to/new_segments/:/new_segments -v /path/to/full_scrolls/:/full_scrolls -e DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix ghcr.io/spacegaier/volume-cartographer:edge VC ``` The terminal for the container should open. Enter the following lines: ```bash cd /new_segments/ /bin/bash run_vc.sh ``` This command will render your points into a mesh, and then create the surface volume layers from it. This can take a long time depending on the size of your segment, but thankfully you will get some progress information on the console. Congratulations! You've completed your first segment! In the new_segments directory you set when you launched VC, you will now have a folder with the name of your new segment, and within that folder a folder called `layers/`, and a number of different files, the most important of which are detailed below. Much of this information was gathered from @Seth P. and @khartes_chuck on the discord: * `layers/` contains files numbered 00.tif to 64.tif (or 000.tif to 156.tif for 3.24um scans). These are slices of the surface volume, each of a thickness equal to the voxel size of the scroll you are currently segmenting, typically what we call “low res” are the 7.91um voxel spacing, and “high res” would be 3.24um voxel spacing. For a 7.91um volume, this means that each surface volume is 64 tifs * 7.91um, for about 506um thickness, or .506mm. * `.obj` this is a 3D image format that stores information about the geometry of a 3D model, such as vertex positions, texture maps, normals, and faces. This is a mesh created from the pointset created by your segmentation line and detailed further below. * `.tif` is a composite image of maximum intensity pixels from within the surface volume, it is also used for texturing in combination with the mtl file. * `.mtl` is a text file that contains information about the material, such as opacity, reflectivity, and points to the texture file (the tif in the previous line). * `.ppm` A simple way to think about this is to think of it as a super dense point cloud that for each voxel in the flattened volume contains a point representing the 3d location in the original volume that voxel came from, and some information about that point. A better explanation is that a .ppm is special case of an ordered pointset, where type = double and dim = 6. It is generated by flattening the segmented surface, discretizing the parameterization, and storing the corresponding 3D point and surface normal for each spot on the surface. Using slice notation, ppm[y, x, 0:3] stores the 3D point and ppm[y, x, 3:6] stores the surface normal. Because the surface does not fill the 2D array entirely, there is a *_mask.png file next to the PPM. It stores which pixels in the PPM have valid values. More info here: Volume Cartographer PPM file format (github.com) * `_mask.png` as detailed in the ppm description, just denotes areas that do not contain information from the scroll data. * `.vcps` this is the pointset created by your segmentation line. A .vcps file stores lists or 2D arrays of N-dimensional, numerical vectors. It starts with a header as described, then the points are written in sequence, usually in binary and rarely in ASCII. The type field in the header tells you the fundamental C++ type stored. * `.vcano` contains information about which points were manually moved, and their original locations. * `Author.txt` contains the name of the person who created it. * `Area_cm2.txt` is simply the size of the segment in cm^2. ### Outputs [section: /tutorial_VC#outputs] So, what did we just do? When looking for ink in the volume, we need to look at more than just the voxels that directly intersect the segment mesh we just created. We also need to look a little bit “above“ and “below“ the mesh, at the neighborhood of voxels that surround our segment. Conceptually, this neighborhood looks something like this (though this video is exaggerated): To generate the composite .tif file, called `.tif`, `vc_render` searched through this neighborhood, gathering the voxel intensities, and placed the results of that search in the flattened output image. The ppm file that we generated contains a mapping between our flattened output image and the original 3D surface. With this file, we transformed the 3D neighborhood into a simplified flattened volume. That process looks something like this: The result of this process are the 65 tifs in the /layers/ directory, also referred to as a "surface volume". Each of these .tif images is a "slice" of the surface volume, with 32.tif ideally representing the middle, or the area directly on your segmentation line. ===== PAGE: Virtual Unwrapping with VC3D ===== URL: https://scrollprize.org/tutorial_VC3D STATUS: current # Virtual Unwrapping with VC3D *Last updated: July 12, 2026* Note: VC3D is updated frequently. Follow along in Discord for the latest changes. In this tutorial, you will see how to open a CT scan of a scroll in VC3D, our specialized software for virtual unwrapping, and how to segment part of the papyrus surface. ## Installing VC3D [section: /tutorial_VC3D#installing-vc3d] Downloads for all operating systems are available on the [releases page](https://github.com/ScrollPrize/villa/releases) of the villa repository. - Download the macos .dmg file from the [releases page](https://github.com/ScrollPrize/villa/releases) of the villa repository. - Double click the .dmg file, and drag/drop it into applications (you may have to right click the dmg and click 'open'.) - Download the windows installer .zip file from the [releases page](https://github.com/ScrollPrize/villa/releases) of the villa repository. - Extract the contents of the .zip file to a folder of your choice. - Double click the install file, click "show more details" and then "run anyway" - Follow the prompts, clicking yes or next where necessary Currently, the application must be built from source on linux. There is an install script at the volume-cartographer root (villa/volume-cartographer/build_from_src_debian.sh) that will handle this build for you ```bash cd villa/volume-cartographer chmod +x build_from_src_debian.sh ./build_from_src_debian.sh ``` Prebuilt docker containers are hosted on the GitHub container registry. To use them, run the following command: ```bash docker pull ghcr.io/scrollprize/villa/volume-cartographer:stable ``` ## Launching the GUI [section: /tutorial_VC3D#launching-the-gui] Depending on your install method or operating system, the application may be launched in different ways. - Mac: Open the application from the Applications folder - Windows: Open the application from the Start menu - Linux: Navigate to the build folder and run the VC3D app. example: `cd build/bin && ./VC3D` ## Using VC3D [section: /tutorial_VC3D#using-vc3d] ### Viewing a scroll [section: /tutorial_VC3D#viewing-a-scroll] VC3D is intended as a viewer of scroll data and to assist in the virtual unwrapping of scrolls, so the fastest way to get familiar with it is to unwrap some part of a scroll. Let's start with PHerc1447. This scroll (as of July 13, 2026) has no public surfaces, so let's make one. You should see the open data catalog window in the VC3D gui when you launch it, and from here we can select our sample: *if the data catalog is not visible, you can reopen it* - File → Open Data Catalog… - Select PHerc1447 and either double click or press Open Sample After a brief wait to download any necessary data, you should see the scroll data in the xy and yz planes (the two viewers to the right) and a large blank window to the left. General navigation tips: - You can zoom in and out in any viewer by using the mouse wheel. - Use right click to pan the view, and either `ctrl+click` or `R` to move the focus point. When the focus point is moved, the other planes will all align with it, so you are seeing the same location in the scroll volume from different planes/orientations. - You can rotate the yz plane either by dragging the green handle in the xy view, or by pressing the mousewheel in and dragging the mouse in the yz view - You can slice through the planes by holding shift and moving the mousewheel up or down - You can increase the sensitivity of any navigation actions by changing the settings in `Viewer Controls → Navigation` PHerc1447 has recto surface predictions available from the open data catalog, and these should pre-populate in your overlay selector. Let's take a look at this volume with the surface predictions overlaid: ### Growing surfaces [section: /tutorial_VC3D#growing-surfaces] Now that we've got all our necessary data, we can create our first segmentation. Let's find a place on the volume we would like to see unwrapped, and use `ctrl+right click` to bring up the volume actions menu. From here, click `Create Segment (GrowPatch)`, and a dialog box will pop up. From the volume selector, ensure that the volume containing "surface" is selected, set your growth iterations to 35, and check that the output path is to the desired location (by default, this will go to your open data catalog folder in a "patches" folder for the selected volume, you do not need to change this). You should see another dialog box pop up, and it will show the progress of the current segmentation growth. After a brief wait, it should say "Successful". Click `OK` and then click on `Volume Package`, and you should see your segment. Click on it to show it in the flattened view on the left. You can also see how the 2D sheet surface is situated in the original CT volume in the xy and yz views -- the orange line in these views shows where they slice through the sheet you have segmented. A high quality segment should follow the sheets in the cross-section views, and also have the horizontal and vertical fibers clearly visible in the flattened view -- this indicates the segment is followimg the original written surface of the papyrus accurately. This segment, while currently small, can be used already either for [ink detection](/tutorial5), as an input to the [spiral fit](/tutorial_spiral), or for [training data](/2026_open_problems#surface-prediction). Any segment created by VC3D, regardless of how big, is in this same format. Growth tips: - the more iterations you have selected, the bigger the resulting segment, but the longer it will take to complete. Later iterations take longer due to the edges of the surface being longer. - Try and select an area that is on the surface predictions to get better results. If we want to make our segment larger, we can do this easily with the built-in segmentation tools. Click on `Segmentation` and `Enable Editing`. You can then use either the growth button or keybinds to grow in a desired direction. - `1` to grow left, `2` to grow up, `3` to grow down, `4` to grow right, `5` to grow in all directions - The `steps` spinbox in the segmentation tool can be used to increase or decrease the number of steps to take in each direction (a step being roughly 20 voxels) ## Winding Annotation [section: /tutorial_VC3D#winding-annotation] VC3D can be used to create winding annotations for the spiral fit (see [the inputs section](/tutorial_spiral#what-goes-in) of the spiral fitting document for more details on how these are used). VC3D outputs these primarily as *patches (segmentations)* or *point collections*. See [In-depth: Winding Constraints](/open_problems/winding_annotations) for more on why these annotations matter and how they're used. When generating data for the spiral, we can think of the inputs broadly as two types of annotations: - same-winding annotations (fibers, patches, kolleisis, points along surface preds, etc) - relative or different winding annotations (generally points which move outward radially *across* sheets rather than *along* them) If you've been following along with this guide, you've already created a same-winding annotation in the form of a patch (see the previous section). A same-winding annotation is simply some set of points which say "these points are all part of the same sheet of the scroll". Conversely, a relative or different winding annotation is a set of points which say "these points are part of different sheets of the scroll, and they are this many windings apart" These can be generated in an infinite number of ways. VC3D has built-in tools for generating a few examples of them: ### Fibers (*same-winding*) [section: /tutorial_VC3D#fibers-same-winding] A tool to manually add control points to a line annotation (which we often use to target fibers), with interpolation and extrapolation assistance via lasagna normals. - Note: lasagna normals must be present to use this tool To start a line annotation: Ctrl + Right click on your starting point in the 3D volume, then select Line Annotation. The first time, you will be prompted to load the lasagna normals. A line annotation workspace will launch, with 4 viewers: - Top left: XY plane - Top right: orthogonal plane, similar to the YZ plane - Middle: a flattened fiber view - Bottom: a flattened fiber view, orthogonal to the middle plane To pan along a fiber: - Move the mouse pointer over the middle or bottom view - Shift + Wheel while the mouse pointer is in one of the top viewers To annotate: - Press Spacebar to freeze panning via the mouse pointer - Left click to add a control point - A reoptimization takes place after each control point is added - To delete a control point, use Ctrl + Right click → Delete control point ### Manually created Point Collections (*relative or same-winding*) [section: /tutorial_VC3D#manually-created-point-collections-relative-or-same-winding] You can manually place points by enabling annotation and using `shift+click` in any of the volume views. Using this method, you can create either a relative or same-winding annotations easily. If you have a patch already loaded, these annotations can be even more influential in a later fit. You can think of them as extensions of the patch itself, and they can be used as edges in a patch graph if you want to connect sparse patches. *same winding* place points along the surface of the scroll, beginning partially inside a patch and extending outward place points outward radially, indicating the winding offset between points ### Same-winding using the wrap annotation tool [section: /tutorial_VC3D#same-winding-using-the-wrap-annotation-tool] You can use the same-wrap annotation tool to quickly create same-winding annotations along surface predictions. Each tool uses `shift+click` (or `shift+click+drag` for the manual tool) to place tentative points, which are then "commited" to point collections with `shift+e` ## Viewer Controls [section: /tutorial_VC3D#viewer-controls] - Focus point — hover the mouse in 3D; the keybinds Ctrl + Left click or r move the focus point to those coordinates - Intersection thickness — adjust segment line thickness in the 3D volume windows - Volume window — manually threshold/window the volume data - Show axis overlays in XY view — toggles visibility of the YZ axis plane adjustment tool - Max displayed resolution — increase if streaming is slow ===== PAGE: Tutorial: Ink Detection ===== URL: https://scrollprize.org/tutorial5 STATUS: current *Last updated: July 10, 2026* Ink detection is the last step of the pipeline: taking the flattened surface of a papyrus sheet ([segmented](/tutorial_VC3D) from the 3D X-ray scan) and identifying where the ink is, so that the text can be read. This is where one of the core difficulties of the Herculaneum Papyri comes in: the carbon ink and the carbonized papyrus have almost the same density, so in an X-ray scan the ink is nearly invisible to the naked eye. The problem is easiest to see on a *detached* fragment, where the writing is exposed and we can photograph it directly: in a color photograph the letters are faint, in 1000 nm infrared they are crisp and legible, but in the X-ray CT scan the ink contrast almost completely disappears. So why scan with X-rays at all? Because visible and infrared light can't see inside a *rolled* scroll — they don't penetrate the papyrus. X-ray CT does: it images the interior of an intact scroll at high resolution, but, as the fragment above shows, at the cost of the visible ink contrast. Ink detection exists to win that contrast back computationally. Not all of that contrast is lost, though. What does the surviving signal look like? In PHerc. Paris 4 in particular, ink can sit as a thin layer on the papyrus surface, and on the flattened surface volume it often shows up as a crackle — a texture like cracked mud, raised slightly above the papyrus. Crackle is one of several surface-morphology cues that can betray ink; on other scrolls the signal is more subtle and heterogeneous, and may instead depend on fine texture, local roughness, deposits, or deformation. This crackle is what first revealed [letters inside an intact scroll](/firstletters), spotted by eye in raw surface volumes. But it is the exception. Most scrolls show nothing so legible, so models trained on known ink learn to pick up traces the eye can't name. Several scrolls are still waiting for their first letters, and each is worth \$50,000 in the open [First Letters Prizes](/prizes#first-letters-prizes). Finding them takes a searching eye and a model's predictions. By the end of this tutorial you'll have both — and maybe you'll be the first person to read those words in 2,000 years. ### How ink detection works [section: /tutorial5#how-ink-detection-works] An ink detection model does signal recovery, not reading. The model looks at a small local patch of the surface volume (the stack of slices sampled around the papyrus surface) and predicts, for each pixel, the probability that there is ink at that location. Stitching these predictions together produces an image of the segment where the writing becomes visible to a human reader. We train the model by picking a pixel in a binary label image, sampling a subvolume around the same coordinates from the surface volume, and backpropagating the known label to update the model weights: We can then use the model to predict what a label image would have looked like, on data it has never seen: Where do the labels come from? The first ink labels came from detached fragments, where the exposed writing can be photographed in infrared and aligned with the surface volume. For the intact scrolls, labels are made iteratively: an existing model is run on a scroll segment, a human inspects the predictions, labels the regions where letter strokes are clearly visible, and the model is retrained on the enlarged dataset. Repeating this loop is how ink detection has improved from isolated letters to entire scrolls. This process recently achieved the complete virtual unwrapping and reading of PHerc. 1667: the first Herculaneum scroll to be fully digitally unrolled and read without physical opening. The methods, including the labeling and validation methodology this tutorial is based on, are described in detail in [the paper](https://arxiv.org/abs/2606.29085). Because the labels come from model predictions, the process is designed to avoid reinforcing the model's own errors: * The model only sees small local patches — smaller than a full letter — so it cannot learn to "draw" plausible letterforms. * Labeling is conservative: only regions where strokes are clearly and repeatably visible get labeled. * Validation regions are held out, so you can measure whether the model generalizes. * Final readings are always reviewed by papyrologists. Machine output is never treated as a substitute for reading. Now let's train a model. The rest of this tutorial is hands-on: you will set up the training pipeline, download a labeled dataset, train an ink detection model, and run inference on a scroll segment. It is written for Linux (Windows users are advised to use WSL2) and assumes an NVIDIA GPU with a working CUDA installation. ### The dataset [section: /tutorial5#the-dataset] The tutorial uses the [`ink-labels` dataset](/data_datasets#ink-labels-2026-07), which lives in the [`scrollprize/datasets` storage bucket](https://huggingface.co/buckets/scrollprize/datasets/tree/ink) on Hugging Face, organized by scroll. The full dataset is hundreds of GB, so the whole tutorial runs end-to-end on one segment of PHerc. Paris 4 (Scroll 1) — about 25 GB: ```bash uvx --from huggingface_hub hf buckets sync \ hf://buckets/scrollprize/datasets/ink/phercparis4/w00_20231016151002 \ ./ink-dataset/phercparis4/w00_20231016151002 ``` `hf buckets sync` works like `rsync`: re-running it resumes interrupted downloads and only transfers what changed. If you hit rate limits, create a free account, generate a read token under Settings → Access Tokens, and either run `uvx --from huggingface_hub hf auth login` once or set `HF_TOKEN=hf_...` in your environment. Each segment is a folder in the layout the training pipeline expects, containing the surface geometry (`.tifxyz`), the surface volume, and the labels: ``` ink-dataset/phercparis4/ └── w00_20231016151002/ ├── x.tif # surface geometry: 3D coordinates ├── y.tif # of every surface pixel ├── z.tif ├── meta.json ├── w00_20231016151002.zarr # surface volume (image data) ├── w00_20231016151002_inklabels.zarr # binary ink labels ├── w00_20231016151002_inklabels.tif # (and the editable TIFF original) ├── w00_20231016151002_supervision_mask.zarr # where the labels are trustworthy └── w00_20231016151002_supervision_mask.tif ``` The label files work together, and understanding them is the key to the whole pipeline: * Ink labels — a binary image aligned with the segment: white where there is ink, black where there is not. * Supervision mask — marks the regions where the labels can be trusted. Only pixels inside the supervision mask contribute to the training loss: white pixels there are positive (ink) examples, black pixels are negative (no ink) examples. Everything outside the mask is ignored, so unlabeled or ambiguous areas don't teach the model anything wrong. * Validation mask — some segments also have a `_validation_mask.zarr`: a held-out region, labeled the same way as the rest, but excluded from training and used only to measure the model's accuracy. A segment without one (like the tutorial segment) still trains — you just get no validation metrics for it. Here is what that looks like on a crop of the tutorial segment. First, the ink labels: strokes that a human labeler could clearly and repeatably see, painted on top of the surface volume: The supervision mask covers those strokes *plus* the clean papyrus around them. Those background pixels are the negative examples, and they matter just as much as the ink: Note: The filename prefixes must exactly match the segment folder name: a segment folder named `w00_20231016151002` must contain `w00_20231016151002_inklabels.zarr`, `w00_20231016151002_supervision_mask.zarr`, etc. The pipeline discovers segments and their labels by these names. ### Setting up the pipeline [section: /tutorial5#setting-up-the-pipeline] The ink detection pipeline lives in the [villa repository](https://github.com/ScrollPrize/villa), under `ink-detection/`. It uses [uv](https://docs.astral.sh/uv/getting-started/installation/) to manage its Python environment. ```bash git clone https://github.com/ScrollPrize/villa.git cd villa/ink-detection git checkout merge-ink-pipelines uv sync ``` `uv sync` creates a virtual environment and installs the exact locked dependencies (PyTorch, zarr, and friends). Verify that PyTorch sees your GPU: ```bash uv run python -c "import torch; print(torch.__version__, '| cuda:', torch.cuda.is_available())" ``` ### Training [section: /tutorial5#training] Training runs are configured with a single JSON file. Create `configs/ink_tutorial.json` (the `configs` folder doesn't exist yet; create it too), pointing `segments_path` at the folder containing your downloaded segments: ```json { "out_dir": "runs/ink_tutorial", "seed": 42, "mode": "flat", "model_type": "vesuvius_unet", "in_channels": 1, "model_config": { "autoconfigure": true, "z_projection_mode": "max" }, "targets": { "ink": { "out_channels": 1, "activation": "none", "z_projection_mode": "max" } }, "patch_size": [64, 256, 256], "patch_overlap": 0.5, "patch_min_labeled_coverage": 0.05, "batch_size": 2, "num_iterations": 20000, "learning_rate": 0.01, "mixed_precision": "fp16", "dataloader_workers": 4, "val_every": 500, "save_every": 1000, "datasets": [ { "segments_path": "/path/to/ink-dataset/phercparis4", "volume_scale": "0" } ] } ``` The important options: * `mode: "flat"` trains directly on the pre-rendered surface volume zarrs. This is the standard 2.5D setup: the model takes a 3D patch of the surface volume as input and predicts a 2D ink image as output. Nothing is rendered on the fly. (The pipeline also has native 3D modes — `full_3d`, `full_3d_single_wrap` — which instead sample patches on the fly from the original scroll volume using the `.tifxyz` coordinates; they get [their own section](#native-3d-training-and-inference) below.) * `z_projection_mode: "max"` is what makes it 2.5D — the network processes the patch in 3D, then the ink head collapses the depth axis with a max-projection to produce the 2D prediction. (`mean`, `logsumexp`, and `learned_mlp` are alternative projections to experiment with.) * `patch_size` is the `[z, y, x]` size of the patches sampled around the surface: 64 slices deep, 256×256 pixels across. Each dimension must be divisible by the network's pooling factors — the trainer prints the required factors and adjusts or complains if they don't match. * `patch_overlap: 0.5` means training patches are sampled with a half-patch stride across each segment. * `patch_min_labeled_coverage: 0.05` skips training patches whose ink labels cover less than 5% of the patch, so training focuses on labeled regions. * `val_every` controls how often validation metrics are computed on the validation-mask regions, and `save_every` how often checkpoints are written. * `segments_path` points at the *folder of segments*, not a single segment — the trainer picks up every valid segment it finds there, so the same config keeps working as you add more. One segment is enough for a real first model. Then start training: ```bash uv run python -m koine_machines.training.train configs/ink_tutorial.json ``` The trainer discovers your segments, finds all training patches inside the supervision masks (excluding the validation regions), and starts training. Patch discovery can take a while on large datasets; the result is cached as a JSON file in `out_dir`, keyed by patch size, overlap, and label version, so re-runs with the same settings skip it. With this config, the full 20,000-iteration run takes about an hour and a half on a single H100. While it runs you will see the loss printed to the console, and in `runs/ink_tutorial/` you will find: * `ckpt_001000.pth`, `ckpt_002000.pth`, ... — checkpoints, saved every `save_every` iterations. * `train_previews/` (and `val_previews/`, when there is a validation set) — periodic image previews of the model's predictions next to the labels. Watching the previews go from noise to letter strokes is the most satisfying part of the process. If your dataset includes segments with validation masks, the model is also evaluated on those held-out regions at each validation step, reporting balanced accuracy — how well it detects ink in areas it was never trained on. If training loss keeps dropping while validation accuracy stalls, the model is starting to overfit your labels. (The tutorial segment has no validation mask, so this first run reports training loss only.) You can stop training at any time with `ctrl+c` and use the most recently saved checkpoint. Note: If you run out of GPU memory, reduce `batch_size` to 1, or reduce the `patch_size` to `[64, 128, 128]`. For multi-GPU training, launch through Accelerate instead: `uv run accelerate launch --num_processes 2 --module koine_machines.training.train configs/ink_tutorial.json`. Note: To log metrics and previews to Weights & Biases, add `"wandb_project": "ink-detection"` and `"wandb_entity": "your-username"` to the config and run `uv run wandb login` once. ### Inference [section: /tutorial5#inference] To run your trained model on the same segment and produce an ink prediction image: ```bash uv run python -m koine_machines.inference.infer \ /path/to/ink-dataset/phercparis4/w00_20231016151002/w00_20231016151002.zarr \ runs/ink_tutorial/ckpt_020000.pth \ predictions/w00_20231016151002.tif \ --batch-size 4 ``` The three positional arguments are the segment's surface volume, the checkpoint (here the last one written by the 20,000-iteration run above), and the output path. The model slides across the whole segment in overlapping windows, blends the overlapping predictions, and writes a grayscale TIFF where each pixel's brightness (0–255) is the predicted probability of ink. Expect this to take on the order of an hour on a single GPU for a full segment. Open the result in any image viewer, and if all went well, you'll see letters, including outside the regions you had labels for. Note: For a faster first look, pass `--mask-path region.tif` — a grayscale TIFF the size of the segment where nonzero pixels mark the region to predict — to limit inference to an area of interest. Useful options: * `--gpus 0,1` — run on multiple GPUs. * `--tta-mirror` — average predictions over mirrored versions of each patch (slower, slightly better). * `--layer-start` / `--layer-end` — restrict which depth layers of the surface volume are used. Here is the result on the tutorial segment — the model's prediction in white, with the ink labels it was trained on overlaid in red: ### Native 3D: training and inference [section: /tutorial5#native-3d-training-and-inference] Everything above is the 2.5D path: pre-rendered surface volume zarr in, 2D ink image out. The pipeline can also work natively in 3D, skipping the rendered surface volume entirely: for every training patch it uses the `.tifxyz` coordinates to find where the segment passes through the original scroll volume, samples a 3D crop there on the fly, and projects the 2D labels into the crop around the surface. The model then predicts ink directly in scroll space. Two native 3D modes exist. `full_3d` trains on the raw crops; `full_3d_single_wrap` additionally feeds the model a second input channel marking which voxels belong to this segment's own wrap of papyrus, so the model isn't confused where neighboring wraps pass through the same crop — this is the mode to prefer. #### Native 3D training [section: /tutorial5#native-3d-training] Create `configs/ink_full3d.json`. It is the same shape as the 2.5D config with a few changes: the mode, no z-projection (the prediction stays 3D), a `full_3d` block controlling the label projection, an on-disk cache for the streamed volume chunks, and a dataset entry that gains a `volume_path` pointing at the original scroll volume and trains at pyramid level 2 instead of full resolution: ```json { "out_dir": "runs/ink_full3d", "seed": 42, "mode": "full_3d_single_wrap", "model_type": "vesuvius_unet", "model_config": { "autoconfigure": true }, "targets": { "ink": { "out_channels": 1, "activation": "none" } }, "patch_size": [80, 128, 128], "patch_overlap": 0.5, "patch_min_labeled_coverage": 0.05, "full_3d": { "label_projection_half_thickness": 16, "background_projection_half_thickness": 16 }, "batch_size": 8, "num_iterations": 20000, "learning_rate": 0.01, "mixed_precision": "fp16", "dataloader_workers": 8, "prefetch_factor": 2, "volume_cache_dir": "volume_cache", "volume_cache_max_gb": 120, "val_every": 500, "save_every": 1000, "datasets": [ { "segments_path": "/path/to/ink-dataset/phercparis4", "volume_path": "s3://vesuvius-challenge-open-data/PHercParis4/volumes/20260411134726-2.400um-0.2m-78keV-masked.zarr/", "volume_scale": "2" } ] } ``` * `volume_path` is where the 3D crops come from. The public `vesuvius-challenge-open-data` S3 bucket is read anonymously — no AWS account needed. You can also download the volume locally (or just the chunks your segments touch, with `koine_machines.preprocessing.download_required_zarr_chunks`) and point `volume_path` at the local copy instead. * `volume_scale: "2"` samples the crops from level 2 of the volume pyramid — 4× downsampled in each axis. That's enough for the tutorial; training at native resolution (`"0"`) can bring further gains, at the cost of a much longer run. Distances in the config are always given in full-resolution voxels regardless of `volume_scale` — the pipeline converts them to the trained level internally. * The `full_3d` block sets how far above and below the surface the 2D ink labels and supervision mask are projected into the crop, in full-resolution voxels (here ±16, so ±4 voxels at level 2). * `volume_cache_dir` enables an on-disk LRU cache (capped at `volume_cache_max_gb`) for the chunks streamed from `volume_path`: each chunk is downloaded once and re-read from local disk afterwards, which makes both re-runs and inference (which shares the cache) much faster. * There is no `in_channels` — the native 3D modes set it automatically before model construction. `full_3d_single_wrap` uses two input channels (the volume image and the reconstructed surface mask), as does `normal_pooled_3d`; plain `full_3d` uses one. Training starts the same way: ```bash uv run python -m koine_machines.training.train configs/ink_full3d.json ``` This run — 20,000 iterations at batch size 8 — takes about eight hours on an H100 with the tutorial segment and uses about 17 GB of VRAM. Note: You don't have to wait eight hours to see results. Checkpoints land in the run folder every `save_every` iterations, so while training continues you can run the inference command below on an intermediate checkpoint, say `ckpt_005000.pth`, and watch the predictions improve from checkpoint to checkpoint. #### Native 3D inference [section: /tutorial5#native-3d-inference] Native 3D checkpoints use a different inference script, `koine_machines.inference.infer_full3d_tifxyz`, which samples patches the same way and writes a sparse 3D OME-Zarr prediction volume instead of a 2D image. For inference the segment folder must contain a `volume_source.txt` — a single line with the path or URL of the original scroll volume: ```bash echo "s3://vesuvius-challenge-open-data/PHercParis4/volumes/20260411134726-2.400um-0.2m-78keV-masked.zarr/" \ > /path/to/ink-dataset/phercparis4/w00_20231016151002/volume_source.txt ``` Then, with your native-3D checkpoint: ```bash uv run python -m koine_machines.inference.infer_full3d_tifxyz \ /path/to/ink-dataset/phercparis4/w00_20231016151002 \ runs/ink_full3d/ckpt_020000.pth \ predictions/w00_20231016151002_ink.ome.zarr \ --resolution 2 \ --write-region occupied --chunk-halo 0 \ --batch-size 8 --num-workers 8 \ --cache-dir volume_cache --cache-max-gb 120 \ --overwrite ``` * `--resolution 2` must match the `volume_scale` the checkpoint was trained at. * At `--batch-size 8`, inference uses about 6.5 GB of VRAM. * `--num-workers 8` prepares patches in parallel worker processes, keeping the GPU supplied. * `--write-region occupied --chunk-halo 0` restricts the output to just the chunks that actually contain surface points, which is much faster than the default (which also writes a halo of neighboring chunks). Even at level 2 a single segment plans thousands of patches (hundreds of thousands at full resolution) — add `--plan-only` to preview the chunk/patch plan first, and only launch the full command when the printed patch count fits your compute budget. * For `full_3d_single_wrap` checkpoints, the script reconstructs the surface-mask input channel from the `.tifxyz` geometry automatically. The result is an ink prediction in scroll coordinates rather than a flattened image: To read it, render it through the segment geometry with VC3D's `vc_render_tifxyz` — the same tool that renders surface volumes from the scroll, just pointed at the prediction volume instead. You'll need a VC3D build on your `PATH`; see the [VC3D tutorial's installation instructions](/tutorial_VC3D#installing-vc3d). ```bash vc_render_tifxyz \ --volume predictions/w00_20231016151002_ink.ome.zarr \ --group-idx 0 \ --scale 1 \ --scale-segmentation 0.25 \ --segmentation /path/to/ink-dataset/phercparis4/w00_20231016151002 \ --num-slices 16 \ --slice-step 0.5 \ --cache-gb 16 \ --tif-output renders/w00_20231016151002_ink ``` This flattens the prediction into a stack of 16 slices spanning the surface, written as one TIFF per slice into the output folder. `--scale-segmentation 0.25` maps the segment's full-resolution `.tifxyz` coordinates into the 4×-downsampled level-2 prediction volume. At that level, `--slice-step 0.5` samples a focused band around the surface without accumulating as much papyrus texture as a wider step; use `--slice-step 1` if you need to search farther along the normal. `--scale 1` preserves the flat grid's output resolution. Finally, take a maximum over the slices to get a single readable image: ```bash uv run --with numpy --with tifffile --with imagecodecs python -c " import glob, numpy as np, tifffile stack = np.stack([tifffile.imread(p) for p in sorted(glob.glob('renders/w00_20231016151002_ink/*.tif'))]) tifffile.imwrite('renders/w00_20231016151002_ink_max.tif', stack.max(axis=0)) " ``` The model trained on a single segment, so the interesting test is a segment it has never seen. Here are the same two checkpoints rendered this way on the central region of `w05_4424`, elsewhere in the scroll: The run above is a starting point. For better results, give the trainer more segments and train longer; the next section covers where to get them. ### Scaling up: the full dataset [section: /tutorial5#scaling-up-the-full-dataset] Everything above ran on one segment; scaling up is mostly a matter of downloading more. Sync a whole scroll (or several) into the same folder: ```bash uvx --from huggingface_hub hf buckets sync hf://buckets/scrollprize/datasets/ink/phercparis4 ./ink-dataset/phercparis4 ``` The training config doesn't change — `segments_path` already points at the folder, and the trainer picks up every segment in it on the next run. More segments means more diverse training data, which is the single most reliable way to improve the model. For inference across many segments, use folder mode — it runs the checkpoint on every segment in the folder and writes each prediction into a `preds/` directory inside that segment: ```bash uv run python -m koine_machines.inference.infer \ --folder /path/to/ink-dataset/phercparis4 \ --checkpoint-path runs/ink_tutorial/ckpt_020000.pth \ --batch-size 4 ``` ### Improving the model: iterative labeling [section: /tutorial5#improving-the-model-iterative-labeling] A first model trained on a small dataset will reveal some letters clearly, others faintly, and miss some entirely. The way to make it better is the same loop that scaled ink detection to entire scrolls: 1. Run inference on your training segments (and new, unlabeled ones). 2. Inspect the predictions. Look for regions where letter strokes are clearly visible. 3. Extend the labels. In those regions, paint the visible strokes white in the ink label image, and extend the supervision mask to cover the region — both the strokes *and* the clean background around them, since the background pixels are the negative examples the model learns from. 4. Retrain on the enlarged labels, starting fresh or from your last checkpoint (add `"checkpoint": "runs/ink_tutorial/ckpt_020000.pth"` and `"weights_only": true` to the config). 5. Repeat. Labels are ordinary image files, so you can edit them in any image editor that handles large images (e.g. GIMP or Photoshop). If you edit or create labels as TIFF/PNG files, convert them to the `.zarr` format the trainer expects with: ```bash uv run python -m koine_machines.preprocessing.create_label_zarrs /path/to/ink-dataset/phercparis4 ``` The figure below shows this loop in action on PHerc. 1667: with each iteration the labels (row a) grow from a handful of strokes to dense coverage, the model's predictions (row b) get cleaner, and the reading improves even on a held-out region that was never labeled (row c). ### What's next [section: /tutorial5#whats-next] With segmentation and ink detection you now have the complete pipeline: from a 3D X-ray scan of an intact scroll to readable text. This exact loop — better segments, more careful labels, retrained models — is what produced the [complete reading of PHerc. 1667](https://arxiv.org/abs/2606.29085), and there are hundreds of scrolls to go. Join the [Discord](https://discord.gg/V4fJhvtaQn) to see what the community is working on, check the open [prizes](/prizes), and help us read the rest of the library. ===== PAGE: FAQ ===== URL: https://scrollprize.org/faq STATUS: current ### What is Vesuvius Challenge? [section: /faq#what-is-vesuvius-challenge] Vesuvius Challenge is a machine learning, computer vision, and geometry competition to read the Herculaneum scrolls. The scrolls were buried and carbonized by the eruption of Mount Vesuvius in 79 AD. After their discovery in the 1750s, some were opened physically, mostly destroying them but revealing some Greek philosophy and Latin works. A few hundred scrolls were excavated that were never opened, and remain rolled up with their contents sealed away. Our community is building methods to read these scrolls using micro-CT and an algorithmic pipeline using machine learning and computer vision. We've awarded in prizes and broken through twice: in 2023 the first passages of Greek were revealed inside a closed scroll, and in 2026 [PHerc. 1667](/firstscroll) became the first scroll ever read from beginning to end. Now we want to read them all — starting with the [2027 Grand Prize](/prizes#2027-grand-prize). Join us to win prizes and be a part of history! ### Why is there a Vesuvius Challenge team? [section: /faq#why-is-there-a-vesuvius-challenge-team] Vesuvius Challenge runs an open competition and also employs an independent team that works on the same problems. This might look like we are competing against our own contest, but the team exists to make the community faster, not to race it. * The current team is not eligible for prizes. * Everything the team does is open source. Tools like [VC3D](https://github.com/ScrollPrize/villa/tree/main/volume-cartographer) and the [`vesuvius`](https://github.com/ScrollPrize/villa/tree/main/vesuvius) library, data releases, labels, and trained models are published for everyone. When the team makes progress, it raises the baseline that every contestant builds from. * The team keeps the competition moving. Scanning new scrolls, releasing data, and maintaining infrastructure are ongoing work that has to happen between community breakthroughs. * The team does the unglamorous manual work that contestants are unlikely to take on, such as labeling, segmentation review, and data preparation, so that prize submissions can focus on breakthroughs. * The team adjudicates prizes. Judging submissions requires a deep technical background, and with many submissions each month it is a substantial amount of work. The project has settled into a rhythm: prizes spark breakthroughs from the community, and the team carries them forward between major prize offerings. The 2026 milestones, including [the first complete reading of a scroll](/firstscroll), were almost entirely team driven, built directly on methods that contestants pioneered. Many of the team first arrived as contestants, won prizes, and [were then recruited](/firstscroll). Hiring from the community is how the team was built. ### What dates do I need to know? [section: /faq#what-dates-do-i-need-to-know] The [2027 Grand Prize](/prizes#2027-grand-prize), [First Letters](/prizes#first-letters-prizes), and [PHerc. Paris 4's Title](/prizes#first-title-prize) prizes all close on June 25th, 2027 (11:59pm Pacific). [Progress Prizes](/prizes#progress-prizes) are awarded every month — including \$20,000 guaranteed for the best submission. See [Open Prizes](/prizes) for everything in one place, and [join the community](/get_started) to stay tuned! ### What's the historical background of Herculaneum and the scrolls? [section: /faq#whats-the-historical-background-of-herculaneum-and-the-scrolls] The story of the villa and its scrolls is told in [Our story](/#our-story) on the landing page! ### Where can I read the texts Vesuvius Challenge has uncovered? [section: /faq#where-can-i-read-the-texts-vesuvius-challenge-has-uncovered] Recovered text is collected in the [Data Browser](/data_browser) — each scroll's page shows its readings and ink predictions. Highlights: [PHerc. 1667](/data_browser/PHerc1667), the first scroll read end to end; [PHerc. 172](/data_browser/PHerc0172) (Philodemus, *On Vices*, Book 1 — the first title found); and [PHerc. 139](/data_browser/PHerc0139) (Philodemus, *On Gods*, Book 8). Here are the scholarly publications so far resulting from Vesuvius Challenge: * [Complete virtual unwrapping and reading of a rolled Herculaneum papyrus](/pdf/main.pdf) ([arXiv](https://arxiv.org/abs/2606.29085)) — the 2026 PHerc. 1667 results * [Ink Detection from Surface Topography of the Herculaneum Papyri](https://www.nature.com/articles/s41598-026-58467-1) — Angelotti et al., *Scientific Reports*, 2026 * [Revealing Text from a Still-rolled Herculaneum Papyrus Scroll (PHerc. Paris. 4)](https://www.iris.unina.it/handle/11588/959427) (2023 First Letters results) * [The final columns of PHerc.Paris. 4 revealed through virtual unwrapping](https://www.iris.unina.it/handle/11588/985203) (2023 Grand Prize results) Also of interest: * [An entire Herculaneum scroll has been read](/firstscroll) * [Vesuvius Challenge 2023 Grand Prize awarded](/grandprize) ### What about other texts from the physically opened Herculaneum scrolls? [section: /faq#what-about-other-texts-from-the-physically-opened-herculaneum-scrolls] Most are by Philodemus. This is a list of English translations we have found so far: * [Philodemus: On Anger. (2020), David Armstrong & Michael McOsker. SBL. ISBN 1628372699](https://en.wikipedia.org/wiki/Special:BookSources/1628372699) * [Philodemus: On Death. (2009), W. Benjamin Henry. SBL. ISBN 1-58983-446-1](https://en.wikipedia.org/wiki/Special:BookSources/1-58983-446-1) * [Philodemus: On Frank Criticism. (1998), David Konstan, Diskin Clay, Clarence, E. Glad. SBL. ISBN 1-58983-292-2](https://en.wikipedia.org/wiki/Special:BookSources/1-58983-292-2) * [Philodemus, On Piety, Part 1. (1996). Critical Text with Commentary by Dirk Obbink. Oxford University Press. ISBN 0-19-815008-3](https://en.wikipedia.org/wiki/Special:BookSources/0-19-815008-3) * [Philodemus, On Poems, Book 1. (2001). Edited with Introduction, Translation, and Commentary by Richard Janko. Oxford University Press. ISBN 0-19-815041-5](https://en.wikipedia.org/wiki/Special:BookSources/0-19-815041-5) * [Philodemus, On Poems, Book 2, with the fragments of Heracleodorus and Pausimachus. (2020). Edited with Introduction, Translation, and Commentary by Richard Janko. Oxford University Press. ISBN 9780198835080](https://en.wikipedia.org/wiki/Special:BookSources/9780198835080) * [Philodemus, On Poems, Books 3-4, with the Fragments of Aristotle, On Poets. (2010). Edited with Introduction, Translation, and Commentary by Richard Janko. Oxford University Press. ISBN 0-19-957207-0](https://en.wikipedia.org/wiki/Special:BookSources/0-19-957207-0) * [Philodemus, On Property Management. (2013), Voula Tsouna. SBL. ISBN 1-58983-667-7](https://en.wikipedia.org/wiki/Special:BookSources/1-58983-667-7) * [Philodemus, On Rhetoric Books 1 and 2: Translation and Exegetical Essays. (2005). Clive Chandler (editor). Routledge. ISBN 0-415-97611-1](https://en.wikipedia.org/wiki/Special:BookSources/0-415-97611-1) * [David Sider, (1997), The Epigrams of Philodemos. Introduction, Text, and Commentary. Oxford University Press. ISBN 0-19-509982-6](https://en.wikipedia.org/wiki/Special:BookSources/0-19-509982-6) * Philodemus: On Methods of Inference. 2nd edition. (1978). Phillip Howard De Lacy, Estelle Allen De Lacy. Bibliopolis. ### Where can I find more background on this effort? [section: /faq#where-can-i-find-more-background-on-this-effort] #### Academic papers [section: /faq#academic-papers] * For the current end-to-end technical overview of the pipeline — and where you can help — see [Open Problems: Why Reading Every Herculaneum Scroll Is Still a Challenge](/2026_open_problems). * 2026: [Complete virtual unwrapping and reading of a rolled Herculaneum papyrus](https://arxiv.org/abs/2606.29085) — the paper behind the first fully sealed scroll (PHerc. 1667) read end to end. * Data papers: * 2023: [EduceLab-Scrolls: Verifiable Recovery of Text from Herculaneum Papyri using X-ray CT](https://arxiv.org/abs/2304.02084) * 2023: [EduceLab Herculaneum Scroll Data (2023) Info Sheet](https://drive.google.com/file/d/1I6JNrR6A9pMdANbn6uAuXbcDNwjk8qZ2/view?usp=sharing) * [Hard-Hearted Scrolls: A Noninvasive Method for Reading the Herculaneum Papyri](https://uknowledge.uky.edu/cs_etds/138/) (Stephen Parsons’ PhD dissertation) * [From invisibility to readability: Recovering the ink of Herculaneum](https://journals.plos.org/plosone/article/file?id=10.1371/journal.pone.0215775&type=printable) * [From damage to discovery via virtual unwrapping: Reading the scroll from En-Gedi](https://www.science.org/doi/10.1126/sciadv.1601247) * [Reading the Invisible Library: A Retrospective](/img/faq/retro.pdf) (history preprint) For a comprehensive overview of the field, see [this list by EduceLab](https://educelab.gitlab.io/publications/bibtex-refs/). #### Talks [section: /faq#talks] * [Reading the Herculaneum Papyri: Yesterday, Today, and Tomorrow](https://www.youtube.com/watch?v=g-7-Xg75CCI&t=4928s) * [Digital Restoration Initiative: Reading the Invisible Library](https://www.youtube.com/watch?v=NPy0potyh4c) * [Reading the Invisible Library: Virtual Unwrapping and the Scroll from En-Gedi](https://www.youtube.com/watch?v=mwe9sHZ58A0) * The Digital Restoration of Herculaneum Papyri: [Day 1](https://www.youtube.com/live/bw34hAiTOO0), [Day 2](https://www.youtube.com/live/agw3axR9bYE) #### Books [section: /faq#books] The best book we have found is David Sider’s [The Library of the Villa dei Papiri at Herculaneum](https://en.wikipedia.org/wiki/Special:BookSources/9780892367993). Here are some other excellent books we recommend: * [Herculaneum: Italy's Buried Treasure](https://en.wikipedia.org/wiki/Special:BookSources/9780060912055), Joseph Jay Deiss * [Buried by Vesuvius: The Villa dei Papiri at Herculaneum](https://en.wikipedia.org/wiki/Special:BookSources/9781606065921), Kenneth Lapatin (ed.) * [Rediscovering Antiquity: Karl Weber and the Excavation of Herculaneum, Pompeii, and Stabiae](https://en.wikipedia.org/wiki/Special:BookSources/9780521646642), Christopher Charles Parslow * [Scribes and Scholars: A Guide to the Transmission of Greek and Latin Literature](https://en.wikipedia.org/wiki/Special:BookSources/9780198721468), Leighton D. Reynolds & Nigel Guy Wilson * [24 Hours in Ancient Rome](https://en.wikipedia.org/wiki/Special:BookSources/9781789291278), Philip Matyszak * [Die Papyri Herkulaneums im Digitalen Zeitalter](https://en.wikipedia.org/wiki/Special:BookSources?isbn=9783110766233), Kilian Fleischer * Contains an estimate of how much text we hope to find when we read the scrolls, which we [translated into English](/img/faq/page72to79.pdf). * [Opera incerta sugli Dèi](https://cispe.org/philodemus-opus-incertum-pherc-89-1301-1383/), Marzia D’Angelo #### Videos [section: /faq#videos] * [Secrets of the Villa of the Papyri](https://www.youtube.com/watch?v=nm8Y8fDYKEc) * [History of Pompeii: Villa of the Papyri](https://www.wondrium.com/pompeii-daily-life-in-an-ancient-roman-city) * [Reading the Papyrus Scrolls found at Herculaneum](https://www.youtube.com/watch?v=rcWpzqzefV4) * [Out of the Ashes: Recovering the Lost Library of Herculaneum](https://www.youtube.com/watch?v=98W-j545-0Y) * For more videos see [this page](https://www2.cs.uky.edu/dri/videos/) #### Previous media coverage [section: /faq#previous-media-coverage] * [Mysterious Tombs](https://www.imdb.com/title/tt20234948/) — The UnXplained, 2022 * [The Scrolls of Herculaneum](https://www.cbsnews.com/news/deciphering-the-ancient-scrolls-of-herculaneum-60-minutes-archive/) — 60 Minutes, 2018 * [Buried by the Ash of Vesuvius](https://www.smithsonianmag.com/history/buried-ash-vesuvius-scrolls-are-being-read-new-xray-technique-180969358/) — Smithsonian Magazine, 2018 * [More articles and videos](https://www2.cs.uky.edu/dri/news/) — Digital Restoration Initiative ### What if I would like to contribute, but don’t have time to compete for the Grand Prize? [section: /faq#what-if-i-would-like-to-contribute-but-dont-have-time-to-compete-for-the-grand-prize] * Join our [Discord](https://discord.gg/V4fJhvtaQn) to learn about current efforts and how you can pitch in. * You can make smaller open source contributions, which would benefit the whole community. Everyone in the community will be grateful for your work, and you might even be able to win a prize - see those [already awarded](/winners)! ### Can I share my progress on social media? [section: /faq#can-i-share-my-progress-on-social-media] Yes, in fact we encourage you to share your progress. Be sure to also post in our Discord, to get feedback from the community. The only exception: if you are competing for a prize that involves reading new text (the [Grand Prize](/prizes#2027-grand-prize), [First Letters](/prizes#first-letters-prizes), or [PHerc. Paris 4’s Title](/prizes#first-title-prize)), do not make your discovery public — e.g., entire words or passages — until the prize is officially announced. We will work with you to announce your findings. ### I’m outside the United States, can I participate and win prizes? [section: /faq#im-outside-the-united-states-can-i-participate-and-win-prizes] Absolutely! As long as we can legally pay you (no US sanctions) you can win prizes. ### Do I have to pay taxes on my prize earnings? [section: /faq#do-i-have-to-pay-taxes-on-my-prize-earnings] This depends on the jurisdiction you live in, but generally yes, you do have to pay taxes. Consult your tax advisor. ### I’m a researcher or student. Can I publish my results? [section: /faq#im-a-researcher-or-student-can-i-publish-my-results] Generally yes, with the conditions that are specified in the [Data Agreement](https://forms.gle/HV1J6dJbmCB2z5QL8): * Any publications and presentations must cite the dataset(s) used. See the [How to Cite](/data#how-to-cite) section on the data page. * You won’t publish any revelation of hidden text (or associated code) without the written approval of Vesuvius Challenge. We very much encourage researchers and students to work on this! Be sure to reach out to us [on Discord or by email](/get_started). ### I have some ideas but need help. Who can I ask? [section: /faq#i-have-some-ideas-but-need-help-who-can-i-ask] Definitely ask the [Discord](https://discord.gg/V4fJhvtaQn) community! You are also welcome to reach out to our [team](mailto:team@scrollprize.org) directly; though as contest organizers we can only provide limited information regarding specific ideas or submissions and will largely point you towards public resources such as this FAQ or the public Discord channels. ### I have made some progress, who do I inform about this? [section: /faq#i-have-made-some-progress-who-do-i-inform-about-this] Please email us at team@scrollprize.org. We will keep it confidential. We appreciate you keeping us in the loop! If you're open to sharing your improvements publicly (and be eligible for progress prizes), you can post in Discord. ### What scan resolution do we really need? These data files are huge! [section: /faq#what-scan-resolution-do-we-really-need-these-data-files-are-huge] We don't know yet what the minimum resolution necessary to detect ink is. [This paper](https://journals.plos.org/plosone/article/file?id=10.1371/journal.pone.0215775&type=printable) suggested 7.91µm may suffice, and the first scroll scans were made at that resolution. Since then the catalog has grown: recent full-scroll scans reach 2.4µm, small regions have been imaged down to 1.1µm — where ink is markedly easier to read — and each scroll's scan parameters are listed in the [Data Browser](/data_browser). ### Can machine learning models hallucinate letters that aren't there? [section: /faq#can-machine-learning-models-hallucinate-letters-that-arent-there] This is a risk for models that are trained on letterforms. We strongly recommend that participants guard against the risk of hallucination in their models, and will review all submissions with this in mind. ### What is papyrus and how is it made? [section: /faq#what-is-papyrus-and-how-is-it-made] [Papyrus](https://en.wikipedia.org/wiki/Papyrus) is a grassy reed that grows along the banks of the Nile in Egypt. It can grow up to 4.5 meters tall and 7.5cm thick. The tough outer rind is peeled away. The green inner pith is peeled or sliced into strips. The strips are laid out in two layers in a grid pattern. They are pressed together until the layers merge like velcro. And then left out in the sun to dry, where they turn light brown. The sheets – called kollemata – are smoothed out with an ivory or seashell ruler. The kollemata are then glued together with paste made of flour and water. Then the areas where they are joined are hammered smooth. This forms a long piece of papyrus, usually 15-30 feet, comprised of up to 20 kollemata. The Papyrus is rolled up around a dowel called an umbilicus. Portions of it are unrolled for writing. The first section, called the protokollon, is usually left blank. Text is written in columns with a quill and inkwell. Inks are made of varied substances. There are two ways you can write on papyrus: horizontally (“volumen”) or [vertically](https://en.wikipedia.org/wiki/Rotulus) (“rotulus”). All of the Herculaneum papyri are horizontal scrolls. For some good videos about how papyrus is made see: * [Nat’s post](https://twitter.com/i/status/1703422593670541437) * [Meet Some Of The Last Papyrus Makers In Egypt Keeping A 5,000-Year-Old Craft Alive](https://www.youtube.com/watch?v=SBdVhvo2UUM) * [Myriam Krutzsch papyrus workshop](https://www.youtube.com/watch?v=3AaZ5C-U-jE) ### How big are the letters, and where can we expect to find text? [section: /faq#how-big-are-the-letters-and-where-can-we-expect-to-find-text] Letter sizes vary, and of course we don’t know what’s inside the unopened scrolls, but we expect the opened fragments to be fairly representative. You can measure how big the letters are by looking at the aligned surface images, which have a voxel resolution of approximately 3.24µm, like the original CT data (though there can be some local variation due to the registration / flattening process). For example, open a fragment page in the [Data Browser](/data_browser) — say [PHerc. Paris 2 Fr 47](/data_browser/PHercParis2Fr47) — measure a letter size in pixels on its surface image, and multiply by the pixel size. There are also some measurements in [this paper by Richard Janko](http://www-personal.umich.edu/~rjanko/how-to-read-and-reconstruct-a-herculaneum-papyrus.pdf), though it’s a little hard to infer actual letter sizing from it. If someone wants to do a more thorough review of the range of letter sizes found in all the Herculaneum papyri, we’d happily include your results here! From our first [Q&A with the Papyrology Team](https://www.youtube.com/watch?v=gielO5WHdu4), we learned (summary courtesy of [Santiago Pelufo on Discord](https://discord.com/channels/1079907749569237093/1108134343295127592/1111352271809302558)): * 2 orthogonal layers of fibers in a sheet. * ~100um sheet thickness * Scroll outer layer of a sheet = back of a sheet = vertical fibers. * Scroll inner layer of a sheet = front of a sheet with writing = horizontal fibers (text written here). * Sheet layers unlikely to delaminate with carbonization * Carbonization likely fuses multiple sheets (big issue IMO) * 10-20cm blank at start and end of scroll. * 4.5-6cm columns, 1/6 of column space between columns * ~1/8 height paddings top and bottom * Text typically written on the inside (to protect against damage), and on the side with horizontal fibers (easier to write on). ### How can we get more ground truth data? Can I make my own carbonized scrolls? [section: /faq#how-can-we-get-more-ground-truth-data-can-i-make-my-own-carbonized-scrolls] Yes! Just buy [this papyrus on Amazon](https://www.amazon.com/gp/product/B005D75WYE/), roll it up, and put it inside a Dutch oven at 500F+ (260C+) for a few hours. This is very instructive and we highly recommend doing it! You will see how fragile the charred scroll is, how it blisters in the heat, how the layers can separate, how it turns to dust as you handle it. Of course, for it to be useful as ground truth data, you will need to find someone to let you image it in their CT scanner. ### What software is available currently that might help me? [section: /faq#what-software-is-available-currently-that-might-help-me] The main tools maintained by the team live in the [villa monorepo](https://github.com/ScrollPrize/villa): * [VC3D](https://github.com/ScrollPrize/villa/tree/main/volume-cartographer) — the interactive segmentation and virtual-unwrapping toolkit (the much-evolved descendant of Volume Cartographer, originally built by Dr. Seales’ lab). * The [`vesuvius`](https://github.com/ScrollPrize/villa/tree/main/vesuvius) Python library — access scroll data in a couple of lines. There is also a growing body of open source software built by the community. To learn more, check out the [previous prizes](/winners) that have been awarded to many of these efforts and our list of [community projects](/community_projects). ### Where can I find collaborators? [section: /faq#where-can-i-find-collaborators] Join our [Discord](https://discord.gg/V4fJhvtaQn)! ### What would the papyrus scrolls look like when unrolled? [section: /faq#what-would-the-papyrus-scrolls-look-like-when-unrolled] Something like this: ### Why are there no spaces in the text? [section: /faq#why-are-there-no-spaces-in-the-text] In ancient Latin and Greek, they didn’t use spaces! Spaces were added later to aid foreign language learners. ### How does CT-scanning work exactly? [section: /faq#how-does-ct-scanning-work-exactly] We take X-ray photographs of the object from different angles. Typically this is done by having an X-ray source on one side of the object, and an X-ray camera on the other side, and rotating the object on a platform. If the object doesn’t fully fit in the frame of the camera, it can be moved around as well. Just like with any digital camera, there are a lot of settings and parameters. The most important for you to know are: * Resolution: the dimensions of each pixel in an X-ray photo, typically denoted in µm (micrometers or “microns”). Lower is better. The first scrolls were scanned at 7.91µm (and the fragments at 3.24µm); recent full-scroll scans reach 2.4µm. Renting beam time on a particle accelerator is expensive, but resolutions keep improving. * Energy level: the energy of the X-ray electrons, typically expressed in keV (kilo electronvolts). For particle accelerators this is one precise number, whereas for bench top scanners this is more of a range. We think lower is better, since carbon responds better to lower energy levels. The first scans were made at 54keV and 88keV; the catalog now spans roughly 53–137keV depending on the scroll (see each scroll's page in the [Data Browser](/data_browser)). At high resolutions the field of view of the camera is too small to capture the object in its entirety, so multiple passes have to be made. Typically these are stitched together as part of the scanning process. From the X-ray photos from different angles we can reconstruct a 3D volume, using a clever algorithm called [tomographic reconstruction](https://en.wikipedia.org/wiki/Tomographic_reconstruction) (which is where “CT scanner” gets its name; ”computed tomography”). This is typically done by software that comes with the scanner. The resulting 3D volume is like a 3D image. Each unit is called a “voxel” (instead of “pixel”), and has a particular brightness (it’s greyscale). This 3D volume is typically represented as a “.tif image stack”. This is just a bunch of .tif images where each image (called a “slice”) represents a different layer the z-direction, typically starting at the bottom and moving upwards. ### How does CT reconstruction work? [section: /faq#how-does-ct-reconstruction-work] [Tomographic reconstruction](https://en.wikipedia.org/wiki/Tomographic_reconstruction) is used to convert the initial X-ray projection images into the cross-sections we are used to seeing from computed tomography (CT). For the recent scroll scans on the BM18 beamline at the ESRF, projections are acquired in a helical trajectory at up to four laterally offset positions, tiling partially overlapping annular regions so that objects larger than the detector field of view can be covered. After flat-field, detector-distortion, and overlap-alignment corrections, single-distance Paganin phase retrieval is applied to enhance contrast, and the final volume is reconstructed with a GPU-accelerated hierarchical backprojection algorithm adapted to the helical geometry. For more information about the reconstruction method, check out: * The tomographic reconstruction section in the Methods of ["Complete virtual unwrapping and reading of a rolled Herculaneum papyrus"](https://arxiv.org/abs/2606.29085) * The [night_rail_bm18](https://gitlab.esrf.fr/night_rail/applications/mirone/night_rail_bm18) reconstruction pipeline used for the BM18 scans Reconstruction methods are out of scope for Vesuvius Challenge, which focuses on processing the reconstructed images. That said, if you have specific ideas you would like to share with us, please do so by reaching out to team@scrollprize.org! ### How should the intensity values in the CT scans be interpreted? [section: /faq#how-should-the-intensity-values-in-the-ct-scans-be-interpreted] The intensity values should be considered relative: within a CT scan, a higher value indicates higher [radiodensity](https://en.wikipedia.org/wiki/Radiodensity) compared to a lower value from the same scan. There are not units attached to these values that have an absolute physical interpretation, or that allow direct density comparisons between scans. These forms of data are sometimes called qualitative (for relative values) and quantitative (for absolute values with units), even though they're both "quantitative" in the sense we often think of, in that they are numerical. Relative values like this are typical in CT due to the nature of the imaging technique. The medical CT community has a convention called the [Hounsfield unit](https://www.ncbi.nlm.nih.gov/books/NBK547721/) (HU) that approaches quantitative data, but has caveats. The HU is calculated based on a linear ramp using baseline attenuation measured from distilled water (defined as zero HU) and air (-1000 HU). Certain tissues then tend to occupy particular ranges, for instance bone can commonly reach 1000 HU. This can be helpful in the right application, but the HU is still [considered unreliable](https://pubmed.ncbi.nlm.nih.gov/6981306/) as an absolute value, particularly between different scans. Seth Parker described this with respect to our data using an analogy to photography: > Filtered back projection doesn't set a mean explicitly- every voxel is calculated as the weighted sum of projections of that voxel, with the weights derived analytically. So in general the intensity scale is all relative. A loose analogy here is determining the element of an object by taking its color photograph: color in the image is a function of the object's chemistry, but also the color of the incident light, ambient light bouncing around the scene, the exposure properties of the camera, the light response of the sensor/film, etc. Not only that, but multiple materials may have the same color under a specific lighting condition. If you don't have some way of disentangling those effects (for example, controlling lighting, capturing under multiple exposure conditions, having known samples in the FOV to use for calibration), then it's hard to say much beyond what the color is. The ensuing discussion is also informative and can be found [on our Discord](https://discord.com/channels/1079907749569237093/1079907750265499772/threads/1087098128110469141). Based on this, the raw reconstruction values for a scan do not have units or physical interpretations attached to them. These 32-bit float values are typically in the range [-0.1, 0.1] or smaller. Some earlier scan releases also included .hdf files with the original reconstruction float values, so you can experiment with your own intensity windowing; current volumes are released as cloud-optimized OME-Zarr (see each scroll’s [Data Browser](/data_browser) page for available formats). For the 16-bit integer .tif slices that we release, we map the float range to [0, 2^16-1] by choosing a minimum and maximum in the raw float range and scaling accordingly. For those tif releases, the fragments and later scans used the 0.01 percentile and 99.99 percentile as the window min and max. Scroll 1 and Scroll 2 used 0.1 and 99.9, to achieve visually comparable output since they have so much more papyrus in the field of view. Reconstruction outputs should be nonnegative by the principles of backprojection (there can't be negative X-ray attenuation). But noise and other processes lead to some negative values in the reconstructions. This is typical with CT. To remove these negative values, the window min could just be clamped at zero. This would result in an image where air would be black, and there would be more visual contrast. We did not clamp the minimum at zero, instead using percentiles. Air therefore does not appear black in the .tif slices, but is gray and has some noise. For ink detection, we are looking for something subtle, and are training models to detect it. Removing all negative values from the reconstructed image makes the output visually resemble expectations, but is inherently destructive. We don't yet know if there might be any subtle ink signal in the "noise" of the negative values, and so leave the data as unaltered as possible so the models can decide for themselves what to look for. If you want to experiment with comparing scans across energies, there are some materials of known composition in the field of view that are consistent between scans, and you may wish to use them as a sort of baseline. For example, air is present in all scans, and the scroll cases are made of Nylon 12. ### What signals might be present in the 3D X-ray scans for ink detection? [section: /faq#what-signals-might-be-present-in-the-3d-x-ray-scans-for-ink-detection] There remain open questions, but we do know the ink is sometimes directly visible as a "crackle" pattern, a texture resembling cracked mud that appears where the ink sits proud of the surface and appears to have dried. There may be other patterns present that are detectible by machine learning. We suspect that ink might be filling in between the grid pattern of papyrus, kind of like syrup filling in gaps in a waffle. Ink might also be sitting on top of the papyrus, causing a slight bump on the surface. In [Tutorial 5](/tutorial5) we show several examples of where the ink is directly visible in slices of 3D X-ray scans, which is promising. The [talks](#talks) earlier on this page also go into some details. There might be some effect of indentation of the writing instrument, but it’s probably not very significant. The thought has generally been that any indentation effect would be even smaller than ink w.r.t. the scan resolution and maybe not significant when compared against the natural relief of the papyrus fibers. However, this has not been explored in detail on this type of material (look at the paper "Revisiting the Jerash Silver Scroll" for work on an etched metal scroll), so we don’t know for sure. It could be worthwhile to try to reverse engineer what machine learning models are seeing, so that perhaps we can see it more directly. Perhaps this could influence other ink detection methods or future scanning efforts. ### Does segmenting and flattening need to happen before ink detection? [section: /faq#does-segmenting-and-flattening-need-to-happen-before-ink-detection] This ordering is largely historical and due to the way our label sets were constructed, which relied on doing the segmentation and flattening first. It is no longer the only way: alongside surface-conditioned ink detection, direct 3D ink segmentation is now in use — on PHerc. Paris 4, ink is segmented directly in the 3D volume. See [Ink recovery](/2026_open_problems#3-ink-recovery-reading-the-scrolls) and [Direct 3D ink segmentation](/2026_open_problems#direct-3d-ink-segmentation) in the Open Problems post, and the released [ink\_3d\_dino\_guided](https://huggingface.co/scrollprize/ink_3d_dino_guided) checkpoint. Sampling model inputs directly from the original 3D X-ray volume avoids the loss of resolution that resampling into a differently oriented surface volume introduces. The trade-off is data scale: full-scroll volumes are teravoxel-sized, which is why current releases are cloud-optimized OME-Zarr streamed from S3 so tools read only the region they need — see [Data scale](/2026_open_problems#4-data-scale-the-infrastructure-bottleneck). ### Fiji/ImageJ crashes, what can I do about that? [section: /faq#fijiimagej-crashes-what-can-i-do-about-that] Fiji/ImageJ doesn’t work well with extremely large datasets such as our scrolls or fragment volumes. For viewing and working with scroll data we recommend the purpose-built tools instead: [VC3D](https://github.com/ScrollPrize/villa/tree/main/volume-cartographer) for interactive viewing, segmentation, and unwrapping; the Neuroglancer links on each scroll’s [Data Browser](/data_browser) page for in-browser volume exploration; and the [`vesuvius`](https://github.com/ScrollPrize/villa/tree/main/vesuvius) Python library for programmatic access. If you specifically want Fiji/ImageJ, downsampling might help, and you can increase its memory limit under *“Edit > Options > Memory and Threads”*. ### How are the scroll slices oriented? [section: /faq#how-are-the-scroll-slices-oriented] *The conventions below describe the original tif-stack releases of Scrolls 1–5. Newer volumes (see the [Data Browser](/data_browser)) are released as OME-Zarr with per-volume metadata.* #### Scroll 1 [section: /faq#scroll-1] The orientation of Scroll 1 follows the above image. When viewing one of the TIF cross-sections from the scan, the image number increases from the screen toward the viewer’s eye. Based on the counterclockwise spiral direction in the middle of Scroll 1, the released scans are of the top of the scroll: Slice 0 is in the middle and Slice 14000+ is the top. Lastly, all of the Herculaneum papyri are known to be "volumen"/horizontal scrolls (see [What is papyrus and how is it made?](#what-is-papyrus-and-how-is-it-made)). Therefore, the direction of a given line of writing should be clockwise around the TIF cross-sections. The bottom of the letters should be on the lower-numbered images, and the top of the letters should be on the higher-numbered images. #### Scroll 2 [section: /faq#scroll-2] Relatedly, we can likely assume handedness is consistent between the scans of Scroll 1 and Scroll 2 (the TIF cross-section image number increases from the screen toward the viewer’s eye). There's a region in Scroll 2 where the scroll center appears to have drifted/squished its way outside of the center scanning artifact. Only a few slices are as clear as this example (Slice 4680). The center spiral of Scroll 2 appears to be clockwise, unlike Scroll 1's counterclockwise spiral. Assuming consistent handedness, a counterclockwise spiral suggests the released half of Scroll 2 is the bottom half of the scroll: Slice 0 is in the middle and Slice 14000+ is the bottom. The direction of a given line of writing in Scroll 2 would be counterclockwise around the TIF cross-sections, with the bottom of the letters on higher-numbered images and the top of the letters on lower-numbered images. ### What happened to the people when Mount Vesuvius erupted? 😢 [section: /faq#what-happened-to-the-people-when-mount-vesuvius-erupted-] We recommend starting with the only surviving eyewitness account: [Pliny the Younger, Letters 6.16 and 6.20](https://www.yorku.ca/pswarney/2100/pliny-6-16-20.htm). The story of the eruption of Mount Vesuvius has captured imaginations for centuries. The cities of Pompeii and Herculaneum are unique in how well they were preserved. A great introduction to this story is [A Timeline of Pompeii](https://www.youtube.com/watch?v=nwB8sBHZzQc). Some more resources: * Wikipedia * [Mount Vesuvius](https://en.wikipedia.org/wiki/Mount_Vesuvius) * [Eruption of Mount Vesuvius in 79 AD](https://en.wikipedia.org/wiki/Eruption_of_Mount_Vesuvius_in_79_AD) * [Herculaneum](https://en.wikipedia.org/wiki/Herculaneum) * [Pompeii](https://en.wikipedia.org/wiki/Pompeii) * Books: [Recommended reads on Pompeii](https://www.elodieharper.com/post/recommendedreadsonpompeii) * [Pompeii](https://en.wikipedia.org/wiki/Special:BookSources?isbn=9781846684715), by Mary Beard * [Complete Pompeii](https://en.wikipedia.org/wiki/Special:BookSources?isbn=9780500290927), by Joanne Berry * [Life and Death in Pompeii and Herculaneum](https://en.wikipedia.org/wiki/Special:BookSources?isbn=9780714122823), by Paul Roberts * Movies * [Pompeii: The Last Day](https://www.imdb.com/title/tt0369838/) * [Pompeii (2014)](https://www.imdb.com/title/tt1921064/) ### Why did you decide to start this project? [section: /faq#why-did-you-decide-to-start-this-project] Nat read [24 Hours in Ancient Rome](https://www.amazon.com/24-Hours-Ancient-Rome-People-ebook/dp/B0758BFFFX) during the 2020 COVID lockdown. He fell into an internet rabbit hole that ended up with him reaching out to Dr. Seales two years later to see how he could help speed up the reading of the Herculaneum Papyri. They came up with the idea of Vesuvius Challenge. Daniel was intrigued by this idea and decided to co-sponsor it with Nat. ### I have a lot of money! Can I help sponsor this? [section: /faq#i-have-a-lot-of-money-can-i-help-sponsor-this] Scroll Prize, Inc. is a 501c3 non-profit organization that was formed solely to solve the puzzle of the Herculaneum Papyri. It is currently funded by [the sponsors listed on the homepage](/#sponsors), and by many hours of volunteer contributions. If you want to contribute money to support our operational costs or to increase the prize amounts, please [get in touch](mailto:nat@nat.org)! ### I’m a journalist and I would like to interview someone from Vesuvius Challenge! [section: /faq#im-a-journalist-and-i-would-like-to-interview-someone-from-vesuvius-challenge] Please see our [Press page](/press). ### Do you have a scroll that looks like the Nintendo logo from GoldenEye N64? [section: /faq#do-you-have-a-scroll-that-looks-like-the-nintendo-logo-from-goldeneye-n64] Of course (🔊 sound on). ### Do you have a super-cringe, over-the-top, and factually questionable trailer video for the competition? [section: /faq#do-you-have-a-super-cringe-over-the-top-and-factually-questionable-trailer-video-for-the-competition] [Naturally.](https://www.youtube.com/watch?v=u9WCapDeKsQ) ===== PAGE: Livestreams ===== URL: https://scrollprize.org/livestream STATUS: current Be sure to check [Discord](https://discord.gg/V4fJhvtaQn), [Substack](https://scrollprize.substack.com/), and [X](https://x.com/scrollprize) for livestream announcements! ### June 25, 2026 - Press Conference [section: /livestream#june-25-2026---press-conference] ### July 31, 2024 - Office Hours [section: /livestream#july-31-2024---office-hours] ### May 22, 2024 - Office Hours [section: /livestream#may-22-2024---office-hours] ### May 14, 2024 - X Spaces Q&A [section: /livestream#may-14-2024---x-spaces-qa] On [X](https://x.com/natfriedman/status/1790379272873623743) and [our recording](https://dl.ash2txt.org/other/vesuvius-challenge-spaces-2024-05-14.mp3). ### Apr 29, 2024 - 2023 Grand Prize 1st place presentation [section: /livestream#apr-29-2024---2023-grand-prize-1st-place-presentation] ### Mar 16, 2024 - 2023 Grand Prize Celebration talks [section: /livestream#mar-16-2024---2023-grand-prize-celebration-talks] ### Oct 15, 2023 - X Spaces AMA [section: /livestream#oct-15-2023---x-spaces-ama] On [X](https://twitter.com/i/spaces/1eaJbgEkEnrxX?s=20) and [our recording](https://dl.ash2txt.org/other/vesuvius-challenge-spaces-2023-10-15.m4a). ### Oct 12, 2023 - First Letters Prize announcement [section: /livestream#oct-12-2023---first-letters-prize-announcement] More videos from the symposium can be found [here](https://www.herculaneum.ox.ac.uk/node/262). ### May 25, 2023 - Papyrology team Q&A [section: /livestream#may-25-2023---papyrology-team-qa] ### Apr 14, 2023 - Announcing first open source prize winners [section: /livestream#apr-14-2023---announcing-first-open-source-prize-winners] With accompanying [newsletter](https://scrollprize.substack.com/p/first-prizes-awarded-open-source). ### Mar 23, 2023 - Vesuvius Challenge team Q&A [section: /livestream#mar-23-2023---vesuvius-challenge-team-qa] ===== PAGE: $700k/$100k/$50k Grand Prize (Dec 31) ===== URL: https://scrollprize.org/grand_prize STATUS: archived Note (ARCHIVED): This page has been archived and is kept for historical reference: the prizes it describes have concluded. See [Winners](/winners) for the results and [Prizes](/prizes) for what is open today. _The 2023 Grand Prize has been awarded — see [the announcement](/grandprize)._ The \$700,000 Grand Prize will go to the first team to read four passages of text from the inside of the two intact scrolls. We also have prizes for second place (\$100,000) and third place (\$50,000). More details on the qualifying criteria are available [here](#qualifying-criteria). Here are the scrolls in question: We have provided you with 3D X-ray scans of each of these scrolls, which you can find [here](/data). Your job is to extract the text from these scans. You can approach this challenge through any means necessary: machine learning, computer vision, or machine-assisted tools operated by humans. #### Why is this difficult? [section: /grand_prize#why-is-this-difficult] As you will read in the [tutorials](/tutorial), advanced tools and techniques exist for virtually unwrapping papyrus scrolls. This was demonstrated in 2015 when Dr. Seales's team [unwrapped the En-Gedi scroll](https://www2.cs.uky.edu/dri/the-scroll-from-en-gedi/), and in their recent result [identifying ink from 3D X-ray scans in the Herculaneum scrolls](https://arxiv.org/abs/2304.02084). But the Herculaneum scrolls have proved more challenging. The remaining challenges include: - Segmenting the scrolls. The Herculaneum scrolls are especially long, tightly wrapped, damaged, and distorted. To date, no one has successfully done a large-scale segmentation of these scrolls to identify the surfaces of all the rolled layers. - Finding the ink. The ink used in the Herculaneum scrolls is [radiolucent](https://en.wikipedia.org/wiki/Radiodensity), making it difficult to see in the scans. Recently, Dr. Seales's team has trained a machine learning model which can detect the ink from subtle patterns in the 3D X-rays. This works in the fragments, but these models are not yet perfect and will probably need to be improved to work at the scale of an entire scroll. - Putting it all together. Applying the ink detection models to the segmented scroll has not yet been successfully demonstrated. Based on the [landmark results](https://arxiv.org/abs/2304.02084) that Dr. Seales and his team have recently produced, we believe that it is possible to read the Herculaneum scrolls using the [scans](/data) that we already have and the tools and techniques that they have developed. And that is Vesuvius Challenge! The Grand Prize deadline is 11:59pm Pacific, December 31st, 2023. ### Qualifying criteria [section: /grand_prize#qualifying-criteria] A [Review Team](#review-process) made up of technical experts and [papyrologists](https://en.wikipedia.org/wiki/Papyrology) will assess all Grand Prize submissions to ensure that they can: - Read at least 4 passages from the available full-scroll data, each containing at least 140 characters of contiguous text (e.g. within the same column) - Verify that each passage contains no more than 15% of characters which are missing or illegible - The 140 characters per passage include the 15% of characters which may be missing or illegible, so 119 characters must be legible. Legible characters only count as legible when identified on a letter-by-letter basis without papyrological interpolation. - Confirm that submissions contain legitimate and linguistically plausible text. - Independently reproduce and verify your results using your code and documented techniques. If no team meets the criteria by the deadline, we reserve the right to award the prizes to the teams that came closest. This is not a guarantee — we will only award prizes if we believe the spirit of the prize has substantially been met and if a submission comes very close to the objective threshold. This is entirely at our discretion. If you are very very close to meeting the bar, we encourage you to submit your work before the deadline. Prizes are awarded in the order that qualifying submissions are made: - 1st place: \$700,000 - 2nd place: \$100,000 - 3rd place: \$50,000 To qualify for the Grand Prize, you must have registered at the time you downloaded the data. The registration form can be found on the [data page](/data). We will work with the Grand Prize winners to verify their results, put them in a historical context, and co-publish them in academic venues. The winning code will be made public under a permissive open source license, so that others can reproduce and build on your work. ### Submitting your result [section: /grand_prize#submitting-your-result] If you have a qualifying result, submit it for consideration by sending an email to [grandprize@scrollprize.org](mailto:grandprize@scrollprize.org) and provide the following: * Images. Submissions must be in the form of images of the virtually unwrapped papyrus, showing visible and legible text. * Submit a single static image for each text region. Images must be generated programmatically, as direct outputs of CT data inputs, and should not contain manual annotations of characters or text. * Specify which scroll each image came from. * Specify where in the scroll they were found: include information about the position of the text vertically as well as radially within the scroll. One easy way to do this is to provide images showing the 3D position of the text surface inside the scroll. * Include scale bars showing the size of 1cm on each submission image. * Methodology. A detailed technical description of how your solution works. We need to be able to reproduce your work, so please make this as easy as possible: * For fully automated software, please create a Docker image that we can easily run to reproduce your work, and please include system requirements. * For software with a human in the loop, please provide written instructions and a video explaining how to use your tool. We’ll work with you to learn how to use it, but we’d like to have a strong starting point. It should take us no more than an hour to perform the human tasks to get your software working. * Either attach your code/video directly to the email, or include an easily accessible link from which we can download it. * Hallucination mitigation. * If there is any risk of your model hallucinating results, please let us know how you mitigated that risk. Tell us why you are confident that the results you are getting are real. * We strongly discourage submissions that use window sizes larger than 0.5x0.5 mm to generate images from machine learning models. This corresponds to 64x64 pixels for 8 µm scans. If your submission uses larger window sizes, we may reject it and ask you to modify and resubmit. * Other information. Feel free to include any other things we should know. If you’re competing as a team, please have your team leader submit your results. We will communicate with the team leader exclusively, and any prize money will be distributed according to the instructions of the team leader. You’d have to sort out within your team how to split any prizes. ### Review process [section: /grand_prize#review-process] All submissions will be assessed by the Review Team, which consists of a technical team to review your methodology, and an independent team of papyrologists to review your results. Note that the technical team also judges the Open Source Prizes. Technical team - Dr. Brent Seales - Nat Friedman - Dr. Stephen Parsons - Seth Parker - JP Posma - Daniel Havíř Papyrology Team - Robert Fowler, Fellow of the British Academy; Professor Emeritus of Classics, Bristol University - Tobias Reinhardt, Corpus Christi Professor of the Latin Language and Literature, Oxford - Richard Janko, Professor of Classics, University of Michigan - Federica Nicolardi, Professor of Classics, University of Naples Federico II - Gianluca Del Mastro, Professor of Papyrology, l’Università della Campania «L. Vanvitelli» - Daniel Delattre, Emeritus Research Director and Papyrologist, CNRS and IRHT We will process your submission as follows: 1. Technical assessment. The technical team will look at your method, and try to reproduce your results independently. We may also try to apply your techniques to the held-back part of the scrolls to see if they are able to generate new results there. * We want to make sure that your method doesn’t hallucinate, so please let us know how you mitigated this risk. * We will work with you on reproducing your solution. We might have questions, such as how your code works, how to use your manual tools (if applicable), and so on. Please make it as easy for us to run your code as reasonably possible, but also don’t wait until your solution is perfect. If you have any questions, or if you’re wondering if you’re ready to submit, just reach out! * We will acknowledge having received your submission within a week. Depending on the difficulty of verifying your methodology, it might take longer until we are able to make our final assessment. * In case there are multiple teams that submit qualifying results, the team that submitted first will win (independent of how long our assessment takes). 2. Papyrological assessment. Once we are reasonably confident that your solution is technically valid and appears to meet the qualifications, we will share your results with the papyrology team, who will judge if the text is plausible and legitimate. ===== PAGE: $100,000 Ink Detection (June 14th) ===== URL: https://scrollprize.org/ink_detection STATUS: archived Note (ARCHIVED): This page has been archived: the 2023 Kaggle competition it describes has concluded. See [Winners](/winners) for the results and [Prizes](/prizes) for what is open today. As you will learn in the [tutorials](/tutorial), one of the big challenges of reading the Herculaneum Papyri is detecting the ink in the 3D X-ray scans. For this important subproblem, we are offering a \$100,000 [Ink Detection Progress Prize](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/). This progress prize is hosted on Kaggle, and the final submission deadline is June 14th, 2023. ===== PAGE: Winners ===== URL: https://scrollprize.org/winners STATUS: current Vesuvius Challenge has awarded in prizes since the competition started in 2023! This page lists all the prizes awarded so far. ### \$33,500 Progress Prizes (July 2026) [section: /winners#33500-progress-prizes-july-2026] Goal: Improve the tools and training methods needed to read the scrolls. [\$20,000 ScrollFiesta : Ben Kyles / @hari_seldon Continued development of the automatic surface mesher: now villa-compatible (zarr in, tifxyz out), snaps to papyrus in the CT scan, and produces constraints for spiral fitting.](https://github.com/Hob3rMallow/scrollfiesta_public) [\$2,500 Optimising patch connectivity : William Stevens Identifies and removes problem areas that cause sheet switching, leaving a scaffolding of known-good patches; run across all of Scroll 4.](https://github.com/WillStevens/scrollreading/tree/main/pipeline9) [\$1,000 Portable GPU kernels for ScrollFiesta : Alan Thompson A Rust/CubeCL driver for ScrollFiesta's MLS-midpoint projection hotspot that runs on AMD, NVIDIA, and WGPU.](https://github.com/altommo/scrollfiesta-mls-cubecl) [\$1,000 Zarr 3 read fixes : Prasad Khake Fixes multiscale zarr 3 reads in the Python vesuvius Volume and restores an opt-in chunk cache.](https://github.com/ScrollPrize/villa/pull/1177) [\$1,000 Ink detection validation harness : Hyojun Kwon A reworked ink-detection tutorial with proper held-out validation splits, plus an upstream OOM fix.](https://github.com/khj1222/vesuvius-challenge) [\$1,000 windcheck : Josep Carreras Detects self-intersections in tifxyz surfaces, catching silent wrap-crossing errors for large-scale filtering.](https://github.com/joe-carr-data/windcheck) [\$1,000 TIFXYZ Doctor : Aviad Cohen A deterministic QA and triage tool for tifxyz surface grids: metadata, consistency, distortion, and topology checks, plus a merged VC3D bounds fix.](https://github.com/aviad12g/tifxyz-doctor) [\$1,000 Faster decohesion augmentation : J. Miguel Giraldo Vectorized the DecohesionTransform training augmentation, replacing a per-iteration GPU kernel loop.](https://github.com/ScrollPrize/villa/pull/1072) [\$1,000 Reproducibility fixes & ROI inference : TAUIL Abd Elilah Assorted merged fixes and ROI inference support, plus a negative-result analysis of cross-scroll ink-signal measurement.](https://github.com/TAUIL-Abd-Elilah/vesuvius-repro) [\$1,000 Spiral fitting on consumer GPUs : Shuhan Yang Makes the official spiral fitter run on 12 GB cards and without the native vc C++ extension.](https://github.com/7jycwjmbfn-eng/spiral-fit-consumer-gpu) [\$1,000 tifxyz repair & tracing fixes : Erwin Nieuwlaar Fixes tifxyz meta.json bounding boxes and rescales neural-tracing displacements for non-training voxel sizes.](https://github.com/ScrollPrize/villa/pull/1284) [\$1,000 scroll-data-audit : Matteo Bulloni Defect-hunting across the open-data catalog and volume-cartographer, with catalog metadata checks and merged VC3D fixes.](https://github.com/Bullo27/scroll-data-audit) [\$1,000 fit_spiral fixes : Nicolas Dolegieviez Four merged fixes making fit_spiral work on Windows and turning silently zeroed losses into loud failures.](https://github.com/ScrollPrize/villa/pull/1268) ### \$3,000 Progress Prizes (June 2026) [section: /winners#3000-progress-prizes-june-2026] Goal: Improve the tools and training methods needed to read the scrolls. Announcement: [Blog post](https://scrollprize.substack.com/p/a-new-1m-grand-prize-for-2027) [\$2,000 3D augmentations & ScrollFiesta speedups : Paulo Sergio Camillo / @pscamillo More CT-scan-artifact-inspired augmentations for training 3D segmentation models, plus performance improvements to ScrollFiesta.](https://github.com/ScrollPrize/villa/tree/main/vesuvius) [\$1,000 Fiber format converter : Joseph Balmaceda Converts skeleton-annotated fibers from NML into CSV, JSON, and SWC, with length, branching, and orientation analysis.](https://github.com/abundantjoe/vesuvius) ### \$12,000 Progress Prizes (May, 2026) [section: /winners#12000-progress-prizes-may-2026] Goal: Improve the tools and training methods needed to read the scrolls. Announcement: [Blog post](https://scrollprize.substack.com/p/the-hard-parts-are-getting-clearer) [\$10,000 Scroll Fiesta : Ben Kyles / @hari_seldon An automatic mesher of surface predictions that attempts to fix topological mistakes.](https://github.com/Hob3rMallow/scrollfiesta_public) [\$2,000 3D augmentations : Paulo Sergio Camillo / @pscamillo Scroll Decohesion, Realistic Warp, and Squeeze transforms for training ML models on CT scans.](https://github.com/ScrollPrize/villa/tree/main/vesuvius) ### \$200,000 Kaggle Surface Detection (March, 2026) [section: /winners#surface-detection-kaggle-winners] Goal: Optimize topologically accurate papyrus surface detection methods. Announcement: [Blog post](https://scrollprize.substack.com/p/we-are-cooking) / [Kaggle competition](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/overview) / [Kaggle leaderboard](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/leaderboard) [\$60,000 1st: Vesuvius Team](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/writeups/1st-place-solution-for-the-vesuvius-challenge-su) [\$40,000 2nd: risk of overfitting](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/writeups/2nd-place-solution-vesuvius-challenge-a-postproc) [\$30,000 3rd: W & A](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/writeups/quick-preview-of-the-3rd-place) [\$20,000 4th: Starry](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/writeups/4-th-place-solution) [\$15,000 5th: Dieter](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/writeups/5th-place-solution) [\$10,000 6th: #hui](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/writeups/6-th-place-solution) [\$10,000 7th: DECEM](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/writeups/7st-place-solution-for-the-vesuvius-challenge) [\$5,000 8th: lingyundev](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/writeups/8th-place-solution) [\$5,000 9th: 阿對對對對隊](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/writeups/9th-place-solution) [\$5,000 10th: Vibes & Scrolls Trade-off](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/writeups/10th-place-solution) ### \$1,000 Open Source (March, 2026) [section: /winners#1000-open-source-march-2026] Goal: Improve virtual unwrapping for the Surface Detection challenge. Announcement: [Blog post](https://scrollprize.substack.com/p/we-are-cooking) [\$1,000 Scroll Slab Viewer : Paul Geiger / @PaulG A user-friendly 3D viewer tailored to the Kaggle Surface Detection challenge.](https://github.com/Paul-G2/ScrollSlabViewer) ### \$1,000 Open Source (July, 2025) [section: /winners#1000-open-source-july-2025] Goal: Improve virtual unwrapping Announcement: [Blog post](https://scrollprize.substack.com/p/unveiling-the-mystery-of-compressed) [\$1,000 Data handling and ball-spring method : William Stevens / @Will Stevens](https://github.com/WillStevens/scrollreading/blob/main/report8.pdf) ### \$2,500 Open Source (June, 2025) [section: /winners#2500-open-source-june-2025] Goal: Improve virtual unwrapping Announcement: [Blog post](https://scrollprize.substack.com/p/summer-haze-comes-with-ink) [\$2,500 Stress metrics : William Stevens / @Will Stevens ](https://github.com/WillStevens/scrollreading/blob/main/report7.pdf) ### \$7,000 Open Source (May, 2025) [section: /winners#7000-open-source-may-2025] Goal: Updates to tooling Announcement: [Blog post](https://scrollprize.substack.com/p/may-progress-prizes-and-updates-to) [\$5,000 VC3D stability improvements : Philip Allgaier / @spacegaier ](https://github.com/ScrollPrize/villa/tree/main/volume-cartographer) [\$1,000 Volume masking pipeline : Marcel Roth / @_mvrcii ](https://github.com/mvrcii/mask_2d_tif_volume) [\$1,000 neuroglancer-mini : Hsiao Yao and Dalufish / @.yaohsiao and @dalufish](https://github.com/tomhsiao1260/neuroglancer-mini) ### \$60,000 First Title Prize (May, 2025) [section: /winners#60000-first-title-prize-may-2025] Goal: Discover the end title of a sealed Herculaneum scroll. Announcement: [Blog post](https://scrollprize.substack.com/p/60000-first-title-prize-awarded) - $60,000 — Winner — Marcel Roth and Micha Nowak (https://github.com/mvrcii/vesuvius_first_title_prize) ### \$7,000 Open Source (April, 2025) [section: /winners#7000-open-source-april-2025] Goal: Get us closer to reading entire scrolls Announcement: [Blog post](https://scrollprize.substack.com/p/april-progress-prizes-updates) - $2,500 — Further work on ball and spring surface growing and analysis — Will Stevens (https://github.com/WillStevens/scrollreading/blob/main/report6.pdf) - $2,500 — Mask-3D fork and work on synthetic data generation — Lachlan Parker (https://github.com/lcparker/synthetic-pages/tree/main) - $1,000 — Surface refinement in khartes — Stephane Gouttebroze (https://github.com/sgoutteb/khartes_segmata) - $1,000 — Simplified fork of neuroglancer — Yao Hsao (https://github.com/tomhsiao1260/neuroglancer-mini) ### \$10,500 Open Source (February, 2025) [section: /winners#10500-open-source-february-2025] Goal: Get us closer to reading entire scrolls. Announcement: [Blog post](https://scrollprize.substack.com/p/february-progress-prizes-and-updates) [\$2,500 vesuvius-gui developments : Johannes Rudolph / @jrudolph ](https://github.com/jrudolph/vesuvius-gui) [\$2,500 Improved FASP segmentation : Hendrik Schilling / @waldkauz ](https://dl.ash2txt.org/community-uploads/waldkauz/fasp/v4/layers_hr/) [\$2,500 VC3D improvements : Hendrik Schilling / @waldkauz ](https://discord.com/channels/1079907749569237093/1286341523570688121/1343521735105843242) [\$1,000 Masked scroll Zarrs : Forrest McDonald / @verditelabs ](https://discord.com/channels/1079907749569237093/1079907750265499772/1345262156060561469) [\$1,000 Particle-based flattening : William Stevens / @Will Stevens ](https://github.com/WillStevens/scrollreading/blob/main/report5.pdf) [\$1,000 Ink detection refinements : Hendrik Schilling / @waldkauz ](https://discord.com/channels/1079907749569237093/1315006782191570975/1325148105858879488) ### \$60,000 First Automated Segmentation (December, 2024) [section: /winners#60000-first-automated-segmentation-december-2024] Goal: Reproduce the 2023 Grand Prize segmentation result, but faster. Announcement: [Blog post](https://scrollprize.substack.com/p/awarding-the-amazing-autosegmentation) [\$30,000 Gold Aureus++ : Hendrik Schilling / @waldkauz, Sean Johnson / @sean (bruniss) ](https://github.com/hendrikschilling/FASP) [\$30,000 Gold Aureus++ : Paul Henderson / @pmh47 ](https://docs.google.com/document/d/1ZOIqtG7IbgaW4moWmjYCIeBsyQRNoonQe_KtAnQp8gw/view) ### \$13,500 Open Source (December, 2024) [section: /winners#13500-open-source-december-2024] Goal: Increase the probability we read 90% of four scrolls in 2024. Announcement: [Blog post](https://scrollprize.substack.com/p/vesuvius-challenge-progress-prizes-ee5) [\$2,500 Volumetric segmentation model : Tim Skinner / @Tim S, Lachlan Parker, John Skinner ](https://github.com/tspersonalgithub/december_2024_progress_submission) [\$2,500 Ink labels : Nicola Bodill / @polytrope ](https://github.com/Bodillium/Herculaneum-Scroll-Labels) [\$2,500 Interactive mesh refinement : James Darby / @james darby ](https://docs.google.com/document/d/1tMHUAsGEfHNDRNeUVjNMR1RHOLeFQmiMulIIbV0iWXQ/edit?usp=sharing) [\$1,000 vesuvius-render : Johannes Rudolph / @jrudolph ](https://github.com/jrudolph/vesuvius-gui?tab=readme-ov-file#vesuvius-render) [\$1,000 Electric field-based flattening : Yao Hsiao / @Yao Hsiao, Dalufishe / @Dalufish ](https://discord.com/channels/1079907749569237093/1312623336739831878/1323487224293101568) [\$1,000 Data overlays in Khartes : Chuck / @khartes_chuck ](https://github.com/KhartesViewer/khartes/blob/khartes3d-beta/overlays.md) [\$1,000 Optimized ink detection : Hendrik Schilling / @waldkauz ](https://discord.com/channels/1079907749569237093/1315006782191570975) [\$1,000 Supervoxel-based segmentation methods : Forrest McDonald / @verditelabs ](https://discord.com/channels/1079907749569237093/1079907750265499772/1323439459018211338) [\$1,000 Segmentation tools : William Stevens / @Will Stevens ](https://github.com/WillStevens/scrollreading/blob/main/report4.pdf) ### \$29,000 Open Source (November, 2024) [section: /winners#29000-open-source-november-2024] Goal: Increase the probability we read 90% of four scrolls in 2024. Announcement: [Blog post](https://scrollprize.substack.com/p/vesuvius-challenge-progress-prizes) [\$10,000 Segment patch generation : Hendrik Schilling / @waldkauz ](https://discord.com/channels/1079907749569237093/1312490723001499808) [\$10,000 vesuvius-c library : Forrest McDonald / @verditelabs ](https://discord.com/channels/1079907749569237093/1312615268270342184/1312615268270342184) [\$2,500 Electric potential scroll flattening : Yao Hsiao / @Yao Hsiao, Dalufishe / @Dalufish ](https://github.com/tomhsiao1260/field-based-visualization?tab=readme-ov-file) [\$2,500 Various datasets : Sean Johnson / @sean (bruniss), Hendrik Schilling / @waldkauz ](https://discord.com/channels/1079907749569237093/1312691096169484398/1312691096169484398) [\$1,000 phalanx : Marcel Roth ](https://github.com/mvrcii/phalanx?tab=readme-ov-file) [\$1,000 2D -> 3D labeling tool : James Darby / @james darby ](https://github.com/JamesDarby345/labels_2D_to_3D/tree/main?tab=readme-ov-file) [\$1,000 zarr_to_ome script : Chuck / @khartes_chuck ](https://github.com/KhartesViewer/scroll2zarr/blob/main/README.md#user-guide-for-zarr_to_ome) [\$1,000 New segment in title region : Elian Rafael Dal Prá / @err, Sean Johnson / @sean (bruniss) ](https://discord.com/channels/1079907749569237093/1079907750265499772/1307007350086959104) ### \$18,500 Open Source (October, 2024) [section: /winners#18500-open-source-october-2024] Goal: Increase the probability we read 90% of four scrolls in 2024. Announcement: [Blog post](https://scrollprize.substack.com/p/new-tools-to-use-with-new-scroll) [\$2,500 Segmentation models : Sean Johnson / @sean (bruniss) ](https://discord.com/channels/1079907749569237093/1079907750265499772/1301027968830931038) [\$2,500 Optimizing surface models : Hendrik Schilling / @waldkauz ](https://discord.com/channels/1079907749569237093/1301139262422646926) [\$2,500 Surface mesh refinement : Hendrik Schilling / @waldkauz ](https://discord.com/channels/1079907749569237093/1290364437836075231/1290364437836075231) [\$2,500 C library : Forrest McDonald / @verditelabs ](https://github.com/SuperOptimizer/volcano) [\$2,500 Zarr support in vesuvius-gui : Johannes Rudolph / @jrudolph ](https://github.com/jrudolph/vesuvius-gui) [\$1,000 Self-supervised pretraining for ink detection : Jorge García-Carrasco / @jgcarrasco ](https://drive.google.com/drive/folders/1My6RH0-V_4DUYPieyg6aUHbCXMx6bhvE) [\$1,000 Interactive segmentation improvements in Volume Cartographer : Hendrik Schilling / @waldkauz ](https://discord.com/channels/1079907749569237093/1294185795221065802) [\$1,000 Segmentation toolkit improvements : William Stevens / @Will Stevens ](https://github.com/WillStevens/scrollreading/blob/main/report3.pdf) [\$1,000 Umbilicus Maker : James Darby / @james darby ](https://github.com/JamesDarby345/Umbilicus_Maker/tree/main) [\$1,000 Meshing high curvature segmentations : James Darby / @james darby ](https://github.com/JamesDarby345/Volumetric_Instance_to_Mesh/wiki/Isomap-manifold-non%E2%80%90self%E2%80%90intersecting-surface-meshes-in-high-curvature-regions) [\$1,000 Visualization canvas : Yao Hsiao / @Yao Hsiao, Dalufishe / @Dalufish ](https://discord.com/channels/1079907749569237093/1301795732541411328) ### \$48,500 Open Source (September, 2024) [section: /winners#48500-open-source-september-2024] Goal: Increase the probability we read 90% of four scrolls in 2024. Announcement: [Blog post](https://scrollprize.substack.com/p/exciting-acceleration-in-community) [\$20,000 Fiber following : Sean Johnson / @sean (bruniss) ](https://github.com/bruniss/vesuvius-fibers) [\$10,000 Inkalyzer : Youssef Nader / @YoussefNader ](https://github.com/younader/Inkalyzer) [\$2,500 Fragment ink labeling : Youssef Nader / @YoussefNader ](https://discord.com/channels/1079907749569237093/1279263442913591349) [\$2,500 Fast meshing and flattening : Hendrik Schilling / @waldkauz ](https://github.com/hendrikschilling/volume-cartographer/tree/dev-zarr) [\$2,500 Meshes from volumetric labels : James Darby / @james darby ](https://github.com/JamesDarby345/Volumetric_Instance_to_Mesh) [\$2,500 vesuvius-gui improvements : Johannes Rudolph / @jrudolph ](https://github.com/jrudolph/vesuvius-gui) [\$2,500 Self-supervised ink detection : Jorge García-Carrasco / @jgcarracsco, Andoni Irazusta-Garmendia / @theleprechaun25 ](https://drive.google.com/file/d/1wAEMLT3dd1bHMhL-UNKREKi2vVhQB-Ux/view?usp=drive_link) [\$1,000 Segmentation optimization : Hendrik Schilling / @waldkauz ](https://discord.com/channels/1079907749569237093/1290364437836075231) [\$1,000 Volumetric labeling improvements : James Darby / @james darby ](https://docs.google.com/document/d/1wM0yOsfJRqmB_8Bfr8eWChPL5DhHP_f8SX5DfwQdH9c/edit?usp=sharing) [\$1,000 Scroll Sleuth : Paul Geiger / @PaulG ](https://github.com/Paul-G2/ScrollSleuth) [\$1,000 Small surface segmentation : William Stevens / @Will Stevens ](https://github.com/WillStevens/scrollreading/blob/main/report2.pdf) [\$1,000 Data streaming in Khartes : Chuck / @khartes_chuck ](https://github.com/KhartesViewer/khartes/tree/khartes3d-beta) [\$1,000 Vesuvius Ink Generator : Seth Stewart ](https://github.com/StewartSethA/VesuviusInkGenerator) ### \$41,000 Open Source (August, 2024) [section: /winners#41000-open-source-august-2024] Goal: Increase the probability we read 90% of four scrolls in 2024. Announcement: [Blog post](https://scrollprize.substack.com/p/41000-in-progress-prizes-awarded) [\$10,000 Segment Browser : Johannes Rudolph / @jrudolph ](https://github.com/jrudolph/vesuvius-browser) [\$10,000 Volumetric instance labeling : James Darby / @james darby ](https://github.com/JamesDarby345/Volumetric_Vesuvius_Labelling/tree/main) [\$10,000 Khartes3D : Chuck / @khartes_chuck ](https://github.com/KhartesViewer/khartes) [\$2,500 Rescaled fragment surface volumes : Johannes Rudolph / @jrudolph ](https://dl.ash2txt.org/community-uploads/jrudolph/rescaled-fragments/) [\$2,500 Flood fill for segmentation : Will Stevens / @Will Stevens ](https://github.com/WillStevens/scrollreading) [\$2,500 Convert volumetric segmentations to meshes : James Darby / @james darby ](https://github.com/JamesDarby345/Volumetric_Instance_to_Mesh/tree/main) [\$2,500 Ink detection patch aggregation report : Arefeh Sherafati / @arefeh, Lou Schlessinger / @ls_96 ](https://drive.google.com/drive/folders/1HM_aWmZBfCbaX9tNYgy6iC8nWkEUZzrj?usp=drive_linkx) [\$1,000 wj-wt-ftt : Yao Hsiao / @Yao Hsiao, Dalufishe / @Dalufish ](https://github.com/tomhsiao1260/wj-wt-ftt/) ### \$11,000 Open Source (July, 2024) [section: /winners#11000-open-source-july-2024] Goal: Increase the probability we read 90% of four scrolls in 2024. Announcement: [Blog post](https://scrollprize.substack.com/p/it-has-never-been-easier-to-look) [\$2,500 3D instance segmentation improvements : James Darby / @james_darby ](https://discord.com/channels/1079907749569237093/1268406489471520792/1268406489471520792) [\$2,500 Vesuvius GP+ : Jared Landau / @tetradrachm ](https://github.com/jaredlandau/Vesuvius-Grandprize-Winner-Plus) [\$2,500 DINO ink detection : Jorge García Carrasco / @jgcarrasco ](https://github.com/jgcarrasco/dino-ink-detection) [\$2,500 Hraun updates : Forrest McDonald / @verditelabs ](https://github.com/SuperOptimizer/Hraun) [\$1,000 Web volume annotator : Yao Hsiao / @Yao Hsiao, Dalufishe / @Dalufish ](https://github.com/tomhsiao1260/wj-wt-ftt/) ### \$12,500 Open Source (June, 2024) [section: /winners#12500-open-source-june-2024] Goal: Increase the probability we read 90% of four scrolls in 2024. Announcement: [Blog post](https://scrollprize.substack.com/p/june-progress-prizes) [\$2,500 Volumetric segmentation tools : James Darby / @james_darby ](https://github.com/JamesDarby345/Volumetric_Vesuvius_Labelling) [\$2,500 Volume Cartographer improvements : Philip Allgaier / @spacegaier ](https://discord.com/channels/1079907749569237093/1245402789027254393/1256742790356795413) [\$2,500 Segmentation pipeline : Santiago Pelufo / @spelufo ](https://github.com/spelufo/stabia/blob/main/docs/sheet_adjustment_and_assembly.pdf) [\$1,000 Scroll volume alignment : Paul Geiger ](https://github.com/Paul-G2/VesuviusScrollAlignment) [\$1,000 Updated 3D ink detection volume : Sean Johnson / @Bruniss ](https://discord.com/channels/1079907749569237093/1079907750265499772/1256034838969061376) [\$1,000 Web volume viewer : Huang Cheng Jiun / @pocper1, Yao Hsiao / @Yao Hsiao ](https://github.com/pocper1/visual-volume) [\$1,000 Seam carving for densification : James Darby / @james_darby ](https://github.com/JamesDarby345/3D_sheet_carving) [\$1,000 Mesh chunking : James Darby / @james_darby ](https://github.com/JamesDarby345/3D_mesh_chunking) ### \$29,000 Open Source (May, 2024) [section: /winners#29000-open-source-may-2024] Goal: Increase the probability we read 90% of four scrolls in 2024. Announcement: [Blog post](https://scrollprize.substack.com/p/may-progress-prizes) [\$10,000 Volume Cartographer improvements : Philip Allgaier / @spacegaier ](https://github.com/spacegaier/volume-cartographer) [\$10,000 Khartes improvements : Chuck / @khartes_chuck ](https://github.com/KhartesViewer/khartes) [\$2,500 Scroll 2 segments : Sean Johnson / @Bruniss ](https://discord.com/channels/1079907749569237093/1079907750265499772/1245553260362858577) [\$2,500 vesuvius-gui : Johannes Rudolph / @jrudolph ](https://github.com/jrudolph/vesuvius-gui) [\$1,000 Scroll compression and masking : Oliver Daubney / @O_D ](https://github.com/OliverDaubney/vesuvius_basic_compression) [\$1,000 Volumetric segmentation architecture investigation : James Darby / @james_darby ](https://docs.google.com/document/d/1SX83Dhz5sJXHhSRbADcNxUmuH53BypLRny01rbizK8I/edit?usp=sharing) [\$1,000 Browser-based scroll viewer : Yao Hsiao / @Yao Hsiao ](https://discord.com/channels/1079907749569237093/1246129199304151052/1246129199304151052) [\$1,000 3D segmentation prototype : Forrest McDonald / @VerditeLabs ](https://github.com/SuperOptimizer/Hraun) ### \$35,000 Open Source (April, 2024) [section: /winners#35000-open-source-april-2024] Goal: Increase the probability we read 90% of four scrolls in 2024. Announcement: [Blog post](https://scrollprize.substack.com/p/35000-in-april-advancements) [\$20,000 3D ink detection : Ryan Chesler / @emel_ryan ](https://github.com/ryanchesler/3d-ink-detection) [\$2,500 Mesh merging : Giorgio Angelotti / @Jordi ](https://discord.com/channels/1079907749569237093/1234943853459669002/1234943853459669002) [\$2,500 Instance segmentation labels : James Darby / @james darby ](https://github.com/JamesDarby345/Vesuvius_3D_datasets) [\$2,500 Unsupervised pretraining : Ryan Chesler / @emel_ryan ](https://github.com/ryanchesler/LSM/blob/main/README.md) [\$2,500 New segments : Sean Johnson / @Bruniss ](https://discord.com/channels/1079907749569237093/1234969334535946303) [\$1,000 Volumetric processing tools : Forrest McDonald / @VerditeLabs ](https://github.com/SuperOptimizer/Hraun) [\$1,000 Point cloud comparison : Giorgio Angelotti / @Jordi ](https://github.com/giorgioangel/vesuvius-compare/) [\$1,000 Instance segmentation experiments : James Darby, Ryan Reszetnik, Liamo Pennimpede, Lucas Nelson ](https://discord.com/channels/1079907749569237093/1235042673899995176/1235042673899995176) [\$1,000 Meshing and chunking : Santiago Pelufo / @spelufo ](https://discord.com/channels/1079907749569237093/1232307086952501313) [\$1,000 Pipeline Visualize : Yao Hsiao / @Yao Hsiao ](https://github.com/tomhsiao1260/pipeline-visualize) ### \$42,500 Open Source (March, 2024) [section: /winners#42500-open-source-march-2024] Goal: Increase the probability we read 90% of four scrolls in 2024. Announcement: [Blog post](https://scrollprize.substack.com/p/42500-in-progress-prizes-awarded) [\$20,000 Rendering improvements : Giorgio Angelotti / @Jordi ](https://github.com/schillij95/ThaumatoAnakalyptor/pull/6) [\$10,000 Multiresolution chunked volumes : Chuck / @khartes_chuck ](https://discord.com/channels/1079907749569237093/1193446455504011316) [\$2,500 Volumetric ink detection : Jorge Villaescusa / @mojonero ](https://discord.com/channels/1079907749569237093/1204133327083147264) [\$2,500 Volumetric segmentation labels : Tim Skinner / @Tim S ](https://github.com/tspersonalgithub/march_2024_progress_submission) [\$2,500 Data improvements : James Darby / @james darby ](https://github.com/JamesDarby345/VesuviusDataDownload) [\$1,000 Segment-to-segment label mapping : Oliver Daubney / @O_D ](https://github.com/OliverDaubney/s2slabmap) [\$1,000 Cell viewer and segmentation comparison : Yao Hsiao / @Yao Hsiao ](https://discord.com/channels/1079907749569237093/1162822294415097907/threads/1167722091781554290) [\$1,000 Superpixels and cells : Santiago Pelufo / @spelufo ](https://discord.com/channels/1079907749569237093/1221902373887279226) [\$1,000 Other segmentation axes, 3D ink labels : Sean Johnson / @Bruniss ](https://discord.com/channels/1079907749569237093/1079907750265499772/1223357870762889308) [\$1,000 Colab notebook and ink labels : Nicola Bodill / @polytrope ](https://discord.com/channels/1079907749569237093/1223849912467460116) ### \$850,000 Grand Prize 2023 (December 31, 2023) [section: /winners#850000-grand-prize-2023-december-31-2023] Goal: Reveal four passages within the scrolls. Announcement: [Announcement page](/grandprize) [\$700,000 Winner : Youssef Nader, Luke Farritor, and Julian Schilliger ](https://github.com/younader/Vesuvius-Grandprize-Winner) [\$50,000 Runner up : SQ Mah ](https://github.com/SQMah/Vesuvius-Grand-Prize-Submission/) [\$50,000 Runner up : Lou Schlessinger and Arefeh Sherafati ](https://github.com/lschlessinger1/vesuvius-grand-prize-submission) [\$50,000 Runner up : Elian Rafael Dal Prá, Sean Johnson, Leonardo Scabini, Raí Fernando Dal Prá, João Vitor Brentigani Torezan, Daniel Baldin Franceschini, Bruno Pereira Kellm, Marcelo Soccol Gris, and Odemir Martinez Bruno ](https://github.com/erdpx/vesuvius-grand-prize) ### \$12,000 Open Source (December 31, 2023) [section: /winners#12000-open-source-december-31-2023] Goal: Increase the probability the Grand Prize gets awarded. Announcement: [Blog post](https://scrollprize.substack.com/p/open-source-prizes-awarded) [\$3,000 Segment maps by Yao Hsiao / @Yao_Hsiao ](https://github.com/tomhsiao1260/segment-viewer) [\$3,000 Large segments and colab notebook by Sean Johnson / @Bruniss ](https://scrollprize.substack.com/p/open-source-prizes-awarded) [\$3,000 Crackle Viewer by Julian Schilliger / @RICHI ](https://github.com/schillij95/Crackle-Viewer) [\$3,000 Segment maps by Youssef Nader / @YoussefNader ](https://dl.ash2txt.org/community-uploads/luke/youssef_uploads/scroll_4/) ### \$25,000 Open Source (November 30, 2023) [section: /winners#25000-open-source-november-30-2023] Goal: Increase the probability the Grand Prize gets awarded. Announcement: [Blog post](https://scrollprize.substack.com/p/many-open-source-prize-winners-25) [\$8,000 Next-gen Volume Cartographer : Philip Allgaier / @spacegaier ](https://github.com/spacegaier/volume-cartographer) [\$5,000 Segment Browser : Johannes Rudolph / @jrudolph ](https://github.com/jrudolph/vesuvius-browser) [\$5,000 Ink Detection Masks : Anton Repushko / @repushko ](https://discord.com/channels/1079907749569237093/1177039383375912990/1177039383375912990) [\$1,000 Sharkbite fix : Chuck / @khartes_chuck ](https://github.com/educelab/volume-cartographer/issues/43) [\$1,000 Vesuvius Kintsugi : Giorgio Angelotti / @jordi45698 ](https://github.com/giorgioangel/vesuvius-kintsugi) [\$1,000 Crackle Labels : Sean Johnson / @bruniss ](https://dl.ash2txt.org/community-uploads/bruniss/) [\$1,000 Omit : Timo Meireman / @timo_71099 ](https://tinyurl.com/Omit-1) [\$1,000 Segment Viewer by Yao Hsiao / @Yao_Hsiao and Dalufishe / @Dalufish ](https://github.com/tomhsiao1260/segment-viewer) [\$1,000 Single-sheet Segmentation : Brett Olsen / @brett_olsen ](https://discord.com/channels/1079907749569237093/1179216516697296906/1179216516697296906) [\$1,000 Multiple Contributions : Santiago Pelufo / @spelufo ](https://scrollprize.substack.com/p/many-open-source-prize-winners-25) ### \$60,000 First Letters & Ink (October 12, 2023) [section: /winners#60000-first-letters--ink-october-12-2023] Goal: Find the first letters within the scrolls. Announcement: [Announcement page](/firstletters) [\$40,000 First Letters : Luke Farritor / @lukeboi ](https://github.com/lukeboi/scroll-first-letters) [\$10,000 First Letters, 2nd place : Youssef Nader / @YoussefNader ](https://github.com/younader/Vesuvius-First-Letters) [\$10,000 First Ink : Casey Handmer / @cjhandmer ](https://caseyhandmer.wordpress.com/2023/08/05/reading-ancient-scrolls/) ### \$45,000 Segmentation Tooling 2 (October 3, 2023) [section: /winners#45000-segmentation-tooling-2-october-3-2023] Goal: Help the [segmentation team](/segmentation) do larger and harder areas. Announcement: [Blog post](https://scrollprize.substack.com/p/segmentation-tooling-2-winners) [\$10,000 VA Sheet Tracer by Trevor, Tom, Babak, and Boaz ](https://github.com/teeohem96/VA-Sheet-Tracer) [\$10,000 Extremely Fast Segmentation by Julian Schilliger / @RICHI ](https://github.com/schillij95/volume-cartographer-papyrus) [\$10,000 Khartes by Chuck / @khartes_chuck ](https://github.com/KhartesViewer/khartes) [\$5,000 CT scanning campfire scrolls by Ahron Wayne / @WayneWayneHello ](https://discord.com/channels/1079907749569237093/1079907750265499772/1150930251824779424) [\$5,000 Segment Viewer by Yao Hsiao / @Yao_Hsiao and Dalufishe / @Dalufish ](https://github.com/tomhsiao1260/segment-viewer) [\$5,000 Ilastik integration by Santiago Pelufo / @spelufo ](https://github.com/spelufo/vesuvius-build/blob/main/docs/ilastik_top_pipeline_segmentation.md) ### \$12,000 Ink Detection Followup (September 8, 2023) [section: /winners#12000-ink-detection-followup-september-8-2023] Goal: Take the models from the [Ink Detection Prize](#100000-kaggle-ink-detection-july-14-2023) (see below) and apply them to the scrolls, to find letters. Announcement: [Blog post](https://scrollprize.substack.com/p/ink-detection-followup-prize-winners) [\$3,000 Top Ink Detection Model Analysis by Ryan Chesler / @emel_ryan ](https://github.com/ainatersol/Vesuvius-InkDetection/blob/main/additional_findings.md) [\$3,000 Fine Tuning by Luke Farritor / @lukeboi ](https://github.com/lukeboi/scroll-fourth-second/blob/master/README.md) [\$1,500 Crackle Viewer by Julian Schilliger / @RICHI ](https://github.com/schillij95/Crackle-Viewer) [\$1,500 Resolution Analysis by Team OverthINKingSegmenter ](https://github.com/MIC-DKFZ/OverthINKingSegmenter/blob/master/vesuvius_followup_writeup.pdf) [\$1,500 Scroll Pretraining by Youssef Nader / @YoussefNader ](https://github.com/younader/VesuviusPretraining) [\$1,500 Vesuvius Challenge Whiteboard by Yao / @Yao_Hsiao and Dalufishe / @Dalufish ](https://github.com/tomhsiao1260/vc-whiteboard/tree/dev) ### \$45,000 Segmentation Tooling (June 27, 2023) [section: /winners#45000-segmentation-tooling-june-27-2023] Goal: Help the [segmentation team](/segmentation) do larger and harder areas. Announcement: [Blog post](https://scrollprize.substack.com/p/ink-detection-followup-prize-winners) [\$10,000 Optical Flow Segmentation by Julian / @RICHI ](https://github.com/schillij95/volume-cartographer-papyrus/) [\$10,000 Khartes by Chuck / @khartes_chuck ](https://github.com/KhartesViewer/khartes) [\$5,000 Masked data by James / @thatGuy ](https://dl.ash2txt.org/full-scrolls/Scroll1/PHercParis4.volpkg/volumes_masked/20230205180739/) [\$5,000 Volume Viewer by Yao / @Yao_Hsiao ](https://github.com/tomhsiao1260/vc-whiteboard/tree/demo-3) [\$5,000 VolumeAnnotate by Moshe / @moshelevy ](https://github.com/MosheLevy20/VolumeAnnotate) [\$5,000 Scroll Viewer by Luke Farritor / @lukeboi ](https://github.com/lukeboi/scroll-viewer) [\$5,000 vesuvius-build and vesuvius-blender by Santiago / @spelufo ](https://github.com/spelufo/vesuvius-build) ### \$100,000 Kaggle Ink Detection (July 14, 2023) [section: /winners#100000-kaggle-ink-detection-july-14-2023] Goal: Optimize fragment-based ink detection methods. Announcement: [Blog post](https://scrollprize.substack.com/p/12000-ink-detection-followup-prize) / [Kaggle competition](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/overview) / [More info](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/leaderboard) [\$25,000 1st: ryches ](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417496) [\$20,000 2nd: RTX23090 ](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417255) [\$15,000 3rd: wuyu ](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417536) [\$10,000 4th: POSCO DX - Heeyoung Ahn ](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417779) [\$5,000 5th: Aksell ](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417642) [\$5,000 6th: chumajin ](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417274) [\$5,000 7th: OverthINKingSegmenter ](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417430) [\$5,000 8th: Luck is all you need ](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417383) [\$5,000 9th: still 1 fold, 2 net ](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417361) [\$5,000 10th: Feng Qilong ](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417363) ### \$10,000 Open Source (April 14, 2023) [section: /winners#10000-open-source-april-14-2023] Goal: Increase the probability the Grand Prize gets awarded. Announcement: [Blog post](https://scrollprize.substack.com/p/first-prizes-awarded-open-source) / [Live stream](https://www.youtube.com/watch?v=_LBI0DtTl80) [\$2,500 Scroll Viewer by Luke Farritor / @lukeboi ](https://github.com/lukeboi/scroll-viewer) [\$2,500 2.5D Segmentation Baseline by Ryosuke Tanaka ](https://www.kaggle.com/code/tanakar/2-5d-segmentaion-baseline-inference) [\$2,500 VolumeAnnotate by Moshe Levy / @moshelevy ](https://github.com/MosheLevy20/VolumeAnnotate) [\$2,500 Countless community contributions by Brett Olsen / @caethan ](https://scrollprize.substack.com/p/first-prizes-awarded-open-source) ### EduceLab tools [section: /winners#educelab-tools] Before and during the competition, EduceLab has put out various works. With these tools, they have laid the foundation for the community. While EduceLab members are ineligible for prizes, we want to recognize their efforts. [Quick Segment by Bruno, Sydney, and Drew. © EduceLab/University of Kentucky. ](https://github.com/educelab/quick-segment) [Hard-Hearted Scrolls (PhD dissertation) by Stephen Parsons. © Stephen Parsons. ](https://uknowledge.uky.edu/cs_etds/138/) [Volume Cartographer by Seth Parker and many others. © EduceLab/University of Kentucky. ](https://github.com/educelab/volume-cartographer) [ink-id by Stephen Parsons. © EduceLab/University of Kentucky. ](https://github.com/educelab/ink-id) ===== PAGE: Community Projects ===== URL: https://scrollprize.org/community_projects STATUS: current # 📜 Awesome Scroll Tools [](https://awesome.re) Here are all the awesome awarded open source contributions from our community that will allow us to read the scrolls! 📚✨ Contributions are divided into four categories: _Data access/visualization_, _Segmentation_, _Ink Detection_, and _Other_. Every category is subdivided in classes: 🌟 _Highlighted_ (for popular contributions), ⚙️ _Tools_, 📦 _Materials_, 📝 _Reports_, and 📊 _Visualization_. Some highlighted contributions are added to this repository as submodules. We keep this repository updated as much as we can, but research moves _fast_! 🏃💨 For state-of-the-art updates join our [Discord server](https://discord.com/invite/uTfNwwecCQ) 💬⏰ ## 📊 Data access/visualization [section: /community_projects#-data-accessvisualization] ### 🌟 Highlighted [section: /community_projects#-highlighted] - [vesuvius](https://github.com/scrollprize/vesuvius): Python library for accessing Vesuvius Challenge data. Allows direct access to scroll data without managing download scripts or storing terabytes of CT scans locally. - [VC3D](https://github.com/ScrollPrize/villa/tree/main/volume-cartographer): the team’s interactive tool for viewing, segmenting, and virtually unwrapping scroll volumes. - [Segment browser](https://github.com/jrudolph/vesuvius-browser) is a web-based tool to browse layers and open source ink detection results of all released segments. By Johannes Rudolph ### 🛠️ Tools [section: /community_projects#️-tools] - [vesuvius-c](https://github.com/ScrollPrize/villa/tree/main/vesuvius-c): C library for accessing Vesuvius Challenge data (deprecated — prefer the [`vesuvius`](https://github.com/scrollprize/vesuvius) Python library or VC3D). - [vesuvius-gui](https://github.com/jrudolph/vesuvius-gui) is a single binary GUI to render volumes and segments on-the-fly. By Johannes Rudolph - [vesuvius-phalanx](https://github.com/mvrcii/phalanx): Python library / CLI for accessing Vesuvius data. Allows flexible access to volume and fragment scroll data. By Marcel Roth - [llfio-chunkloader](https://github.com/climbmax123/LLFIOCunkloadingTestingAndBenching): A method to access data in chunks of (x,y,z) that is much faster and more compute-efficient than Zarr. (Written in C++ but it is possible to integrate in Python). - [preprocessed-data](https://github.com/usc-caisplusplus/scroll-data-preprocessing): Data preprocessing code and a fully processed version of the dataset in .zarr format to allow for faster training of ink detection models. - [scroll-data-audit](https://github.com/Bullo27/scroll-data-audit) by Matteo Bulloni. Integrity auditor for the open-data: reconciles the catalog (`metadata.json`) against the actual Zarr arrays, filenames and scan metadata, and verifies multiscale pyramid value-correctness. Reported a Scroll 5 (PHerc0172) catalog shape error ([#1211](https://github.com/ScrollPrize/villa/issues/1211)) and certified the rest of the open-data consistent. - [vesuvius-repro](https://github.com/TAUIL-Abd-Elilah/vesuvius-repro): Regional reproducibility spot-checks of one selected 256³ region (central 128³ scored) from each of 41 m7 artifacts across 36 scrolls. Forty TTA-off checks match at Dice 0.9983–1.0000; PHerc. Paris 4 matches at 0.9999 with TTA on. The audit exposed previously missing configuration provenance; [#1253](https://github.com/ScrollPrize/villa/pull/1253) now records TTA, and maintainers backfilled existing artifacts. Also resolves each artifact's CT level. By TAUIL Abd Elilah - [vesuvius-catalog](https://github.com/Schurkai/vesuvius-catalog): scriptable catalog CLI/library for the open-data bucket - answers which samples have segments, ink outputs or surface predictions at which resolutions, resolves S3/HTTPS data URLs (JSON/CSV output for scripting), and includes working openers for the bucket's OME-Zarr v2 stores under zarr-python 3. ## Segmentation [section: /community_projects#segmentation] ### 🌟 Highlighted [section: /community_projects#-highlighted-1] - [Khartes](https://github.com/KhartesViewer/khartes) by Chuck is a tool to manually create and visualize segment meshes, while also visualizing a preview of the rendered segment. ### 🛠️ Tools [section: /community_projects#️-tools-1] - [Volume Cartographer](https://github.com/educelab/volume-cartographer): the OG virtual unwrapping toolkit. Includes a graphical interface to annotate scroll segments. First built by [EduceLab](https://educelab.engr.uky.edu/); an [active fork](https://github.com/spacegaier/volume-cartographer) by Philip Allgaier contains many community contributions and is currently used by the segmentation team. - [Thaumato Anakalyptor](https://github.com/schillij95/ThaumatoAnakalyptor/tree/main) is an automatic tool that combines classical methods such as threshold gradient operator based edge detectors and Deep Learning based instance segmentation of point clouds to detect, merge and render segments. It was built by Julian Schilliger (part of Grand Prize winning submission). - [Fast Segment Rendering](https://github.com/schillij95/ThaumatoAnakalyptor/blob/main/ThaumatoAnakalyptor/sheet_to_mesh.py) by Julian Schilliger. Fast rendering of segments with GPU acceleration. Capable of saving the surface volume to multiple file formats. - [CPU rendering](https://github.com/schillij95/ThaumatoAnakalyptor/commit/bcd382a0ef59b2a8566ec62a474479ea9d1bb8c2) by Julian Schilliger and Giorgio Angelotti - [Volumetric Vesuvius Labelling](https://github.com/JamesDarby345/Volumetric_Vesuvius_Labelling) by James Darby. Provide custom tooling the [napari](https://napari.org/stable/) 3d viewer that will help manually annotate volumetric masks of the scrolls to train ML models for 3D segmentation. - [Autosegmentation preprocessing pipeline](https://github.com/giorgioangel/vesuvius_autoseg_preprocess) (work in progress) collection of scripts to pre-process volumes for autosegmentation. By Giorgio Angelotti - [Segment2Voxel](https://github.com/giorgioangel/vesuvius-segment2voxel) by Giorgio Angelotti. Tool to create 1-voxel thick volumetric segment labels starting from mesh .obj files. - [Volumetric Instance Labels to obj](https://github.com/JamesDarby345/Volumetric_Instance_to_Mesh/tree/main) by James Darby. Tools to create .obj mesh files from volumetric instance labels. - [Hraun](https://github.com/SuperOptimizer/Hraun) is a collection of python tools for handling volumetric scroll data by Forrest McDonald. - [windcheck](https://github.com/joe-carr-data/windcheck) by Josep Carreras. Finds where a traced surface passes through itself, from mesh geometry alone, and emits transverse-clean `tifxyz` outputs plus a VC3D overlay. - [Scroll compression and masking](https://github.com/OliverDaubney/vesuvius_basic_compression) by Olivier Daubney. Script to compress and mask scroll data, greatly reducing storage requirements! - [Mesh merging](https://github.com/schillij95/ThaumatoAnakalyptor/blob/main/ThaumatoAnakalyptor/mesh_merger.py) by Julian Schilliger. Merges multiple overlapping meshes into one continuous mesh. Flattening not included. - [Mesh merging prototype](https://gist.github.com/giorgioangel/b4cc56a5514335a2947adb058af2982b) by Giorgio Angelotti. Different attempt to merge existing mesh of segments by projecting them in 2D and retriangulating in the plane. - [Meshing and chunking](https://discord.com/channels/1079907749569237093/1232307086952501313) by Santiago Pelufo - [Volumetric segmentation model with labels](https://github.com/tspersonalgithub/march_2024_progress_submission), deep learning 3D model to separate papyrus from air, by Tim Skinner - [Superpixels and cells](https://discord.com/channels/1079907749569237093/1221902373887279226) by Santiago Pelufo - [Segment Flattening](https://github.com/schillij95/ThaumatoAnakalyptor/blob/main/ThaumatoAnakalyptor/slim_uv.py) by Julian Schilliger and Giorgio Angelotti. Improved flattening of scroll segments. - [Slim-Flatboi](https://github.com/giorgioangel/slim-flatboi) previous implementation of the SLIM algorithm with minimization of isometric distortion to flatten scroll segments. Later included in ThaumatoAnakalyptor. By Giorgio Angelotti. - [Single Sheet Segmentation attempt](https://discord.com/channels/1079907749569237093/1179216516697296906/1179216516697296906) by Brett Olsen - [vesuvius-blender](https://github.com/spelufo/vesuvius-blender) by Santiago Pelufo. Explore the X-ray scans in Blender. - [vesuvius-build](https://github.com/spelufo/vesuvius-build/tree/main) by Santiago Pelufo. Scripts to build files for progressive loading of the data. Convert the tif stack to grid cells or to h5 format that can be used by Ilastik. - [Volume Annotate](https://github.com/MosheLevy20/VolumeAnnotate) A partial reimplementation of Volume Cartographer in Python by Moshe Levy. - [VA-Sheet Tracer](https://github.com/teeohem96/VA-Sheet-Tracer) by Trevor, Tom, Babak and Boaz - [vesuvius-image](https://github.com/caethan/vesuvius_image) by Brett Olsen. Tool for storing and viewing data, including efficient Zarr loading of stack of tif images later included in Khartes. - [Quick Segment](https://github.com/educelab/quick-segment) Created by EduceLab for annotating a large air gap in Scroll 1, and then projecting from that gap to either side to create two large segments, colloquially referred to as the “Monster Segment”. Hasn’t been used for more segmentation, since it was the only large air gap we could find. - [scrollreading](https://github.com/WillStevens/scrollreading) by Will Stevens. Experiments with using algorithms based on flood-fill to extract non-intersecting surfaces from scrolls. - [VC with OME-Zarr & more](https://github.com/hendrikschilling/volume-cartographer) by Hendrik Schilling: - fast interactive OME-Zarr access and live slicing & flattening [thread](https://discord.com/channels/1079907749569237093/1286341523570688121) - instant flattening from VC segments without meshing (10s for one slice) [thread](https://discord.com/channels/1079907749569237093/1289946915269509251) - segment surface refinement (also works on obj segments) [thread](https://discord.com/channels/1079907749569237093/1290364437836075231) - fiber based segmentation efforts using an optimizing physics inspired surface meshing approach based on ceres-solver [thread](https://discord.com/channels/1079907749569237093/1301139262422646926) - non-destructive large scale interactive segment viewing and editing [thread](https://discord.com/channels/1079907749569237093/1294185795221065802) - automatic patch generation pipeline: vc_grow_seg_from_seed, vc_render_tifxyz, vc_tifxyz2obj: [thread](https://discord.com/channels/1079907749569237093/1312490723001499808) - segment tagging, segment masking, POIs, segment filters (all/filter by focus point/filter by POIs), display intersections scaling to thousands of segments [message](https://discord.com/channels/1079907749569237093/1286341523570688121/1312537855846907974) - low memory tiled rendering to enable GP-sized an full scroll rendering https://github.com/hendrikschilling/volume-cartographer/blob/dev-zarr/apps/src/vc_render_tifxyz.cpp - large segment tracing based on patch consensus: vc_grow_seg_from_segments, as documented in the [FASP submission](https://github.com/hendrikschilling/FASP?tab=readme-ov-file#vc_grow_seg_from_segments) - consistent winding number estimation by winding number diffusion: [vc_tifxyz_winding](https://github.com/hendrikschilling/FASP?tab=readme-ov-file#51-winding-number-assignment) - segment fusion & inpainting: [vc_fill_quadmesh](https://github.com/hendrikschilling/FASP?tab=readme-ov-file#vc_fill_quadmesh) - [fast and low memory inference for the GP ink detection](https://discord.com/channels/1079907749569237093/1315006782191570975) 1/5 the memory consumption and 20x the speed compared to the baseline GP ink detection for large segments to allow GP and full scroll size ink detection and fast preview. - [vesuvius-render](https://github.com/jrudolph/vesuvius-gui?tab=readme-ov-file#vesuvius-render) by Johannes Rudolph: - Fast self-contained CPU-based rendering of segments from obj files downloading data on-the-fly. - [segmata](https://github.com/sgoutteb/segmata) by Stephane Gouttebroze: - Improve the segmentation process by sharpening the layers rendering, this is based on optimizing the layer 32, a further objective is to link this optimization on a inference loop (optimizing on the detected ink instead of only layers) - [Synthetic instance labels and volume generation](https://lcparker/synthetic-pages) by lcparker - Generate artificial 3D volumes with corresponding instance labels for use in pretraining instance segmentation networks - [Mask3D for instance segmentation on scroll volumes](https://lcparker/Mask3D) by lcparker - SOTA instance segmentation network, configured to work with scroll volumes - [Effects of pretraining on synthetically generated data](https://github.com/lcparker/pretraining-advantage), plus pretrained and finetuned weights for the Mask3D network - [Affinity Prediction with Unet](https://discordapp.com/channels/1079907749569237093/1407379961417039953) by Ayush Mishra - Unet trained on affinity labels using pytorch_connectomics and experiments with watershed - [Gabor Filter for surface prediction](https://www.kaggle.com/code/bluetriad/scroll4-gaborfilters/notebook?scriptVersionId=265957590) by Ayush Mishra - [ScrollFiesta -- virtual meshing & unwrapping for the Herculaneum papyri](https://github.com/Hob3rMallow/scrollfiesta_public) by HariSeldon and friends - now with parameterization and GPU acceleration! - [GPU-accelerated MLS projection for ScrollFiesta](https://github.com/pscamillo/scrollfiesta_public/blob/cuda-mls/BENCHMARKS.md) by pscamillo — OpenMP + CUDA FP32 acceleration, byte-identical, ~6x throughput. (Note: GPU acceleration through CubeCL is now part of the main ScrollFiesta repository) - [Scroll-specific augmentations](https://github.com/ScrollPrize/villa/pull/997) by pscamillo. GPU-native training augmentations modeling real scroll/CT distortions: Squeeze ([#997](https://github.com/ScrollPrize/villa/pull/997)), Decohesion + Warp ([#999](https://github.com/ScrollPrize/villa/pull/999)), Ring ([#1020](https://github.com/ScrollPrize/villa/pull/1020)), Streak ([#1021](https://github.com/ScrollPrize/villa/pull/1021)), Warp edge-padding fix ([#1025](https://github.com/ScrollPrize/villa/pull/1025)) (#201), each validated with ablation + benchmark. - [winding-ruler](https://github.com/pscamillo/winding-ruler) by pscamillo. Measures winding evidence for the spiral fit: where human annotations matter, why generation fails at the published resolution, and a collection-wide winding-pitch atlas (36 scrolls). Includes [qa_holescan](https://github.com/pscamillo/winding-ruler/blob/main/concordance/qa_holescan.py), a content-level detector for silent z-slice loss in predict3d output ([#1183](https://github.com/ScrollPrize/villa/issues/1183)). - [HIP/ROCm port of ScrollFiesta's MLS for AMD GPUs](https://github.com/altommo/scrollfiesta-mls-hip) by Alan Thompson (altommo) — clean-room HIP port of the MLS-midpoint kernel, validated on RX 9070 / gfx1201: ~16.8x kernel, ~5.8x multi-cube, topology-equivalent weld-safe mesh. ([upstream PR](https://github.com/Hob3rMallow/scrollfiesta_public/pull/4)) - [CubeCL port of ScrollFiesta's MLS (portable GPU: AMD/NVIDIA/WGPU)](https://github.com/altommo/scrollfiesta-mls-cubecl) by Alan Thompson (altommo) — Rust/CubeCL reimplementation of the same MLS kernel from a single source; validated on RX 9070 / gfx1201 against the HIP port, passing the 0.25-voxel weld-safety gate and 5-pass strict parity vs clean HIP. - [vesuvius-automesh](https://github.com/spencerdavis-tx/vesuvius-automesh) by spencerdavis-tx. Fully automated, QC-gated surface harvest: masks the public surface predictions against the CT, seed-sweeps the villa tracer, and accepts output per 25 mm window under a two-part quality gate plus an independent topology check - 279 cm2 of verified Scroll 3 surface with zero manual annotation, CPU only. Ships per-window QC records for all 157 windows (passes and failures) as a labeled set of tracer failure modes. - [Herculaneum Scroll Tools](https://github.com/axiosdevs/herculaneum-scroll-tools) by axiosdevs — CT-consistency QA for the published m7 surface predictions: voxel-exact phantom fractions measured for all 36 samples incl. all 13 grand-prize scrolls (43.3% of positives sit outside the masked CT), with a one-pass `clean` mode ([villa#1114](https://github.com/ScrollPrize/villa/issues/1114)); plus cross-scan registration (2023→2025 rescan, MAD 29 µm), a winding-constraint annotator/verifier in native spiral-input format, and dual-energy high-Z ink-candidate rendering. - [tifxyz-repair](https://github.com/Nieuwlaar/tifxyz-repair) by Nieuwlaar. Validates and repairs `tifxyz` patch metadata against VC3D's exact loader semantics: detects the stale-bbox corruption of [villa#1272](https://github.com/ScrollPrize/villa/issues/1272) (106 of 4,922 verified PHercParis4 spiral-input patches affected, independently reproducing the issue's counts), rewrites corrected bboxes in place (atomic, `--dry-run`, backups) and ships ready-to-apply boxes for every flagged patch; full-corpus audits certify all 40,782 unverified patches and all 817 published segment meshes clean. Companion PR [#1285](https://github.com/ScrollPrize/villa/pull/1285) stops the corruption at the source. - [winding-sync](https://github.com/abundantjoe/winding-sync) by Joseph Balmaceda. Generates relative winding constraints directly from CT via structure-tensor lamina orientation, then reconciles contradictions globally as L1 integer synchronization (totally unimodular LP, exact integer solutions). Complements winding-number diffusion over existing surfaces by working from the raw volume before a surface exists. Tolerates 15% gross measurement error before dropping below 95% accuracy, versus 2% for spanning-tree propagation. Absolute winding counts are not yet calibrated; see README. - [spiral-fit-consumer-gpu](https://github.com/7jycwjmbfn-eng/spiral-fit-consumer-gpu) by Shuhan Yang runs the spiral fitter in this repo on a 12 GB consumer GPU without the native VC extension. Drop-in replacements for the sparse CUDA cache, which otherwise raises before the first step, and for point-to-patch linking, where a measured 41-hour ETA drops to minutes. Both are checked for bitwise-identical output against the originals. Includes a scaling ladder and pool-tuning measurements from one gaming laptop. - [TIFXYZ Doctor](https://github.com/aviad12g/tifxyz-doctor) by Aviad Cohen — deterministic QA and triage for TIFXYZ surface grids, with sparse overlays and reproducible corpus/reader checks. v0.2 adds an overlap-component-isolated benchmark on 709 official human-reviewed PHercParis4 `same_wrap` patches; its frozen cue localizes abrupt synthetic normal-offset steps while byte-identical null controls and the reported gradual-transition miss rate bound the claim. - [spiralcheck](https://github.com/Nicodol/spiralcheck) by Nicolas Dolegieviez. Held-out evaluation for whole-scroll spiral fits: scores a finished run from its output meshes alone (CPU-only, no checkpoint, producer-agnostic) against verified patches withheld from that fit, and measures geometrically how much of the withheld evidence actually sits within touching distance of the fit's real inputs — on PHerc. Paris 4, 54.8% of a naive name-level split leaked that way, which no hash-level check can see. Also ships ground-truth-free winding-order checks around the umbilicus, a planted-defect matrix with computed null-control bounds, and `spiralcheck demo`, which runs the whole pipeline on a synthetic scroll with planted defects and needs no data. ### 📦 Materials [section: /community_projects#-materials] #### 🌟 Highlighted [section: /community_projects#-highlighted-2] - [Sheet instance annotation of cubes for Deep Learning models](https://dl.ash2txt.org/full-scrolls/Scroll1/PHercParis4.volpkg/seg-volumetric-labels/finished_cubes/) (work in progress) - [More cubes to annotate, help us!](https://dl.ash2txt.org/full-scrolls/Scroll1/PHercParis4.volpkg/seg-volumetric-labels/cubes/) - [Denoised and contrast enhanced volumes](https://discord.com/channels/1079907749569237093/1249316301273436320), download [here](https://dl.ash2txt.org/full-scrolls/Scroll1/PHercParis4.volpkg/volumes_denoised_ce/), same path pattern for other scrolls. #### Scroll Surface Predictions [section: /community_projects#scroll-surface-predictions] - [Scroll 1, and 3 Surface Predictions](https://dl.ash2txt.org/community-uploads/bruniss/p2_submission/) by Sean Johnson - [Scroll 4 Surface Predictions](https://dl.ash2txt.org/community-uploads/bruniss/Fiber-and-Surface-Models/Predictions/s4/) by Sean Johnson - [Scroll Surface Prediction Repository and Writeup](https://github.com/bruniss/VC-Surface-Models) by Sean Johnson #### 📜 Segments [section: /community_projects#-segments] -[Large Autosegmentation of Scroll5](https://dl.ash2txt.org/community-uploads/bruniss/p2_submission/s5_initial_trace/) by Hendrik Schilling and Sean Johnson -- Unsupervised, many switches -- check readme.md - [Scroll 2 segments](https://discord.com/channels/1079907749569237093/1079907750265499772/1245553260362858577) by Sean Johnson - [New segments](https://discord.com/channels/1079907749569237093/1234969334535946303) by Sean Johnson - [Large segments](http://dl.ash2txt.org/bruniss-uploads/) by Sean Johnson - [Rescaled to 7.91um fragment surfaces and labels](https://dl.ash2txt.org/community-uploads/jrudolph/rescaled-fragments/) by Johannes Rudolph #### 🏷️ Volumetric Labels [section: /community_projects#️-volumetric-labels] - [Instance segmentation labels](https://github.com/JamesDarby345/Vesuvius_3D_datasets) by James Darby ### 📝 Reports [section: /community_projects#-reports] - [Technical report on ThaumatoAnakalyptor](https://github.com/schillij95/ThaumatoAnakalyptor/blob/main/documentation/ThaumatoAnakalyptor___Technical_Report_and_Roadmap.pdf) by Julian Schilliger - [Physical equalization of scrolls' brightness](https://github.com/giorgioangel/vesuvius_autoseg_preprocess/blob/main/equalize/Scroll_Equalizer.pdf) by Giorgio Angelotti - [Volumetric segmentation architecture investigation](https://docs.google.com/document/d/1SX83Dhz5sJXHhSRbADcNxUmuH53BypLRny01rbizK8I/edit?usp=sharing) by James Darby - [Instance segmentation experiments](https://discord.com/channels/1079907749569237093/1235042673899995176/1235042673899995176) by James Darby, Ryan Reszetnik, Liamo Pennimpede, Lucas Nelson - [Probabilistic view on the offset for surface volume creation](https://discord.com/channels/1079907749569237093/1177617480366170162) by Giorgio Angelotti - [Creating segments from intersecting horizontal and vertical fibers](https://gist.github.com/jrudolph/3e0ebbd6e731f794733c236a86ff39fb) by Johannes Rudolph - [Phantom contamination audit of the published surface predictions](https://github.com/Schurkai/vesuvius-phantom-audit): chunk-listing-based measurement across all 36 samples with published m7 surface predictions (villa#1114) - every sample is affected, 16.9% of stored prediction chunks are certain phantoms; includes a voxel-exact-verified cleanup tool. - [Surface geometry failure diagnostic](https://github.com/Jinhojeong/vesuvius-surface-geometry-diagnostic) by Jinho Jeong. Geometry-stratified analysis of where surface models fail in compressed regions (villa #191): compressed sheets are fused rather than missed across three architectures, the CT carries no intensity dip between contacting sheets, and neither the model's probability field nor local CT geometry supplies a boundary either. Includes oracle measurements showing the official topometrics blend does not respond to repairing these merges, a patch-mode eval entry point and a 200-patch ground-truth pool so any surface model or splitter can be scored the same way. - [unmerge-cli](https://github.com/Jinhojeong/vesuvius-unmerge) by Jinho Jeong. Splits fused sheet instances by carrying identity through a contact from the resolved surroundings, using an anisotropic random-walk solve seeded from neighbouring instance labels. On raw predictions it refuses to split and flags the weld instead, since no boundary signal exists there. Applied to the published PHerc1218 instance labels it produced [pherc1218-topological-repair](https://www.kaggle.com/datasets/jhjeong0815/pherc1218-topological-repair), 54,377 repaired fusion sites in three tiers, listed as a companion dataset by [vesuvius-sheet-tools](https://github.com/IyanDopico/vesuvius-sheet-tools). That project independently cross-checked the flagged sites with its own intensity splitter and a matched spatial control, finding them 2.89x enriched for fused stacks over background. ### 📊 Visualization [section: /community_projects#-visualization] - [Browser-based scroll viewer](https://discord.com/channels/1079907749569237093/1246129199304151052/1246129199304151052) by Yao Hsiao - [wj-wt-ftt](https://github.com/tomhsiao1260/wj-wt-ftt) by Yao Hsiao and Dalufishe. Tool to view and annotate volumetric scrolls data. - [Crackle Viewer](https://github.com/schillij95/Crackle-Viewer) is a tool to browse and annotate surface volumes of rendered segments, by Julian Schilliger - [Point cloud extraction method comparer](https://github.com/giorgioangel/vesuvius-compare/) by Giorgio Angelotti. Tool to compare different point cloud extraction methods. - [Pipeline Visualize](https://github.com/tomhsiao1260/pipeline-visualize) by Yao Hsiao. Tool to visualize the first steps of the Thaumato Anakalyptor pipeline. - [Cell viewer and segmentation comparison](https://discord.com/channels/1079907749569237093/1162822294415097907/threads/1167722091781554290) by Yao Hsiao - [Volume Viewer](https://github.com/tomhsiao1260/vc-whiteboard/tree/demo-3) Used by the segmentation team primarily to see which segments they have worked on already. Hosted [here](http://37.19.207.113:5174/). By Yao Hsiao - [Vesuvius Challenge Whiteboard](https://github.com/tomhsiao1260/vc-whiteboard/tree/dev) by Yao Hsiao and Dalufishe - [Neuroglancer Mini](https://github.com/tomhsiao1260/neuroglancer-mini) A trimmed-down version of the Neuroglancer source code. By Yao Hsiao - [Scroll Viewer](https://github.com/lukeboi/scroll-viewer) by Luke Farritor. A lightweight, extensible tool for viewing volumetric data, which runs in the browser, and is very fast. - [Scroll Sleuth](https://github.com/Paul-G2/ScrollSleuth) by Paul Geiger. A web app that supports visual ink-searching in segment volumes via multiple display modes and segmentation tools. - [Scroll Slab Viewer](https://github.com/Paul-G2/ScrollSlabViewer) by Paul Geiger. A 3D viewer tailored for the [Kaggle Surface Detection challenge](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection). ## Ink Detection [section: /community_projects#ink-detection] ### 🏆 3D Ink Detection [section: /community_projects#-3d-ink-detection] #### 🌟 Highlighted [section: /community_projects#-highlighted-3] - [3D (volumetric) Ink detection model](https://github.com/ryanchesler/3d-ink-detection) by Ryan Chesler. Ink detection model that works on full scroll data in 3D, without segmentation nor flattening. - [Volumetric Ink Detection for Scroll 1, 2, 3, 4](https://dl.ash2txt.org/community-uploads/bruniss/3d%20Ink%20/) by Sean Johnson #### ⚙️ Tools [section: /community_projects#️-tools-2] - [Large Scroll Model](https://github.com/ryanchesler/LSM/blob/main/README.md) is a 3D Unet pretrained on scroll data, by Ryan Chesler - [UV predictions visualizer](https://gist.github.com/giorgioangel/6ae26b126f364dda751a10be0b90b36d) by Giorgio Angelotti. Script to quickly visualize the ink predictions output by Ryan Chesler's 3D model as a scatter pkot on segments. Needs the predictions Zarr for the full scroll. - [Volumetric ink detection attempt](https://discord.com/channels/1079907749569237093/1204133327083147264) by Jorge Villaescusa - [Inkalyzer](https://github.com/younader/Inkalyzer) by Youssef Nader. XAI package for Ink models to explain predictions and generate volumetric labels. #### 📦 Materials [section: /community_projects#-materials-1] - [3D Ink labels](https://discord.com/channels/1079907749569237093/1079907750265499772/1223357870762889308) by Sean Johnsonn - [3D Ink predictions](https://dl.ash2txt.org/community-uploads/ryan/) by Ryan Chesler. Predictions of 3D Ink models on full scrolls in Zarr format. ### 🖋️ Scroll segments-based Ink Detection [section: /community_projects#️-scroll-segments-based-ink-detection] #### 🌟 Highlighted [section: /community_projects#-highlighted-4] - [Grand Prize Winner Ink Detection model](https://github.com/younader/Vesuvius-Grandprize-Winner) by Youssef Nader, Luke Farritor and Julian Schilliger #### ⚙️ Tools [section: /community_projects#️-tools-3] - [ScrollMAE](https://github.com/jgcarrasco/ScrollMAE) by Jorge García. Contains the necessary code to pretrain a 3D ResNet on unlabeled data and then finetune it to perform ink detection. - [Unsupervised Ink Detection with DINO](https://github.com/jgcarrasco/dino-ink-detection) by Jorge García. Contains experiments related to detecting ink without labels, including a Colab notebook. - [Vesuvius AutoResearch](https://github.com/mojomast/vesuvius-autoresearch) by mojomast. Autonomous, evidence-gated experiment search for Vesuvius ink-detection research, with reproducible configs, metric contracts, synthetic demo data, and promotion checks. - [Vesuvius GP+](https://github.com/jaredlandau/Vesuvius-Grandprize-Winner-Plus) by Jared Landau. Updated version of the Grand Prize Ink Detection script with extra features. - [Segment-to-segment label mapping](https://github.com/OliverDaubney/s2slabmap) by Oliver Daubney - Runner Up Models, December, 2023 - [Ink detection model](https://github.com/SQMah/Vesuvius-Grand-Prize-Submission/) by SQ Mah - [Ink detection model](https://github.com/lschlessinger1/vesuvius-grand-prize-submission) by Lou Schlessinger and Arefeh Sherafati - [Ink detection model](https://github.com/erdpx/vesuvius-grand-prize) by lian Rafael Dal Prá, Sean Johnson, Leonardo Scabini, Raí Fernando Dal Prá, João Vitor Brentigani Torezan, Daniel Baldin Franceschini, Bruno Pereira Kellm, Marcelo Soccol Gris, Odemir Martinez Bruno - [Vesuvius Kintsugi](https://github.com/giorgioangel/vesuvius-kintsugi) is a tool to label floodfill surface volumes of rendered segments, by Giorgio Angelotti - [Omit](https://onedrive.live.com/?authkey=%21ALfVTOHQOkbecQ0&id=D6F698278C30CB3E%212310&cid=D6F698278C30CB3E) is a pipeline that tries to detect ink with classical approaches (not deep learning) by Timo Meireman - First Letters winning models, October 2023 - [Ink detection model](https://github.com/lukeboi/scroll-first-letters) by Luke Farritor - [Ink detection model, 2nd place but more accurate](https://github.com/younader/Vesuvius-First-Letters) by Youssef Nader - [Crackle Viewer](https://github.com/schillij95/Crackle-Viewer) is a tool to browse and annotate surface volumes of rendered segments, by Julian Schilliger - [Fourth placed Kaggle model finetuning](https://github.com/lukeboi/scroll-fourth-second/blob/master/README.md) on scroll data by Luke Farritor - [Scroll pretraining](https://github.com/younader/VesuviusPretraining) by Youssef Nader. Youssef’s original idea for pretraining on the scrolls and finetuning on the fragments, which led him to winning the First Letters Prize. - [pre-trained DINOv2 models](https://github.com/SergeyPnev/dinov2-vesuvius) by Sergei Pnev. Self-supervised model pre-trained on scrolls 1-5 with predictions. - [Ink detection validation harness](https://github.com/khj1222/vesuvius-challenge) by khj1222. The ink-detection tutorial trains with no held-out data, so improvements cannot be told apart from noise. This generates a `_validation_mask` for a labeled segment by holding out whole annotated regions (splitting by pixels cuts letters in half), scores predictions inside it (threshold sweep, DRD / pseudo-F-measure, per-region breakdown), sweeps checkpoints, and runs k-fold. Also includes a native-Windows walkthrough of the tutorial. #### 📦 Materials [section: /community_projects#-materials-2] - [Scroll 1 Ink Labels](https://discord.com/channels/1079907749569237093/1223849912467460116). Nicola Bodill produced more accurate labels for ink detection based on the prediction of the Grand Prize winner model - [Scroll 4 predictions](https://dl.ash2txt.org/community-uploads/luke/youssef_uploads/scroll_4/). Youssef Nader produced some predictions on Scroll 4 from his Grand prize winner model. No sure trace of ink yet - [Ink detection masks](https://discord.com/channels/1079907749569237093/1177039383375912990/1177039383375912990). Anton Repushko shared some ink labels for Scroll 1, these labels were used by many participants for their final submission in December 2023. - [Crackle labels on Scroll 1](https://dl.ash2txt.org/community-uploads/bruniss/) by Sean Johnson - [Ink Generator] (https://github.com/StewartSethA/VesuviusInkGenerator) by Seth Stewart, ink volume sample patches generated using gradient ascent - [Ink feature visualization] (https://github.com/StewartSethA/ink-seer) by Seth Stewart, ink feature vector clustering and visualization via t-SNE to distinguish ink from non-ink features - [Scroll 5 Ink Labels](https://github.com/Bodillium/Herculaneum-Scroll-Labels) by Nicola Bodill. Early ink labels for Scroll 5. #### 📝 Reports [section: /community_projects#-reports-1] - [Introduction to Ink Detection](https://medium.com/@jaredlandau/vesuvius-challenge-ink-detection-part-1-introduction-1cb125a56b21) by Jared Landau - [Grand Prize Presentation](https://www.youtube.com/watch?v=F5ak1pRaqVo&ab_channel=VesuviusChallenge) by Youssef Nader and Julian Schilliger - [First Ink on scroll 1](https://caseyhandmer.wordpress.com/2023/08/05/reading-ancient-scrolls/) by Casey Handmer #### 📊 Visualization [section: /community_projects#-visualization-1] - [Segment viewer](https://github.com/tomhsiao1260/segment-viewer). Used by the segmentation team primarily to see which segments they have worked on already. Hosted [here](http://37.19.207.113:5173/?mode=segment&segment=20230702185753) By Yao Hsiao and Dalufishe ### 📜 Fragment-based Ink Detection [section: /community_projects#-fragment-based-ink-detection] #### 🌟 Highlighted [section: /community_projects#-highlighted-5] - [Kaggle competition on Fragments](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/overview) - [1st place](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417496) by Ryan Chesler - [2nd place](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417255) by RTX2309 - [3rd place](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417536) by wuyu - [4th place](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417779) by POSCO DX -- Heeyoung Ahn - [5th place](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417642) by Aksell - [6th place](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417274) by chumajin - [7th place](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417430) by OverthINKingSegmenter - [8th place](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417383) by Luck is all you need - [9th place](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417361) by still 1 fold, 2 net - [10th place](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection/discussion/417363) by Feng Qilong - [2.5D fragment segmentation (ink detection) baseline](https://www.kaggle.com/code/tanakar/2-5d-segmentaion-baseline-inference) by Ryosuke Tanaka - [Ink ID](https://github.com/educelab/ink-id) by Stephen Parsons - [Iterative Labeling on fragments](https://discord.com/channels/1079907749569237093/1279263442913591349/1279263442913591349) by Youssef Nader. Applying the iterative labeling approach of the GP winning team to improve ink detection on fragments hidden layers. - [ink detection with rescaled fragments](https://discordapp.com/channels/1079907749569237093/1400138226269814785) by Ayush Mishra #### 📝 Reports [section: /community_projects#-reports-2] - [Kaggle Challenge top ink detection model analysis](https://github.com/ainatersol/Vesuvius-InkDetection/blob/main/additional_findings.md) by Ryan Chesler - [Ink detection model resolution analysis](https://github.com/MIC-DKFZ/OverthINKingSegmenter/blob/master/vesuvius_followup_writeup.pdf) by Yannick Kirchhoff, Maximilian Rokuss and Benjamin Hamm ## Other [section: /community_projects#other] ### ⚙️ Tools [section: /community_projects#️-tools-4] - [Efficient Data Downloader](https://github.com/JamesDarby345/VesuviusDataDownload): scripts to efficiently download data with rclone, by James Darby - [Improving scroll alignment with image registration](https://github.com/Paul-G2/VesuviusScrollAlignment) Scripts and a report showing how image registration can improve the alignment of scroll volumes scanned at different energies and resolutions, by Paul Geiger ### 📦 Materials [section: /community_projects#-materials-3] - [CT scanning campfire scrolls](https://dl.ash2txt.org/community-uploads/waynewaynehello/) Ahron Wayne replicated the carbonization process of a papyrus scroll and scanned it with his personal CT scanner ### 📝 Reports [section: /community_projects#-reports-3] - [Hard-Hearted Scrolls](https://uknowledge.uky.edu/cs_etds/138/), PhD Dissertation by Stephen Parsons # Contributions If you want to contribute and add any resource please submit a PR! 😊🚀 ===== PAGE: First word discovered in unopened Herculaneum scroll by 21yo computer science student ===== URL: https://scrollprize.org/firstletters STATUS: current Note (HISTORICAL MILESTONE): This announcement is from October 2023. The \$700,000 2023 Grand Prize it references has since been [awarded](/grandprize); see [Prizes](/prizes) for what is open today. First word discovered in unopened Herculaneum scroll by 21yo computer science student Vesuvius Challenge \$700,000 Grand Prize “now definitely achievable” October 12th, 2023 Code is on Github: [Luke](https://github.com/lukeboi/scroll-first-letters), [Youssef](https://github.com/younader/Vesuvius-First-Letters). The Herculaneum papyri, ancient scrolls housed in the library of a private villa near Pompeii, were buried and carbonized by the eruption of Vesuvius in 79 AD. For almost 2,000 years, this lone surviving library from antiquity was buried underground under 20 meters of volcanic mud. In the 1700s, they were excavated, and while they were in some ways preserved by the eruption, they were so fragile that they would turn to dust if mishandled. How do you read a scroll you can’t open? For hundreds of years, this question went unanswered. That is until Luke Farritor, a contestant of the [Vesuvius Challenge](/), became the first person in two millennia to see an entire word from within an unopened scroll this August. For that, we are thrilled to award Luke a \$40,000 First Letters Prize, which required contestants to find at least 10 letters in a 4 cm2 area in a scroll. Shortly after that, another contestant, Youssef Nader, *independently* discovered the same word in the same area, with even clearer results — winning the second place prize of \$10,000. These breakthroughs were both inspired by contestant Casey Handmer, who was the first person to find substantial, convincing evidence of ink within the unopened scrolls, as explained in his [blog post](https://caseyhandmer.wordpress.com/2023/08/05/reading-ancient-scrolls/) and [this video](https://photos.google.com/share/AF1QipPC8Z9P1MxxS6UdoCJWDGofjxSHfBYGgDp47gSOoJW1gtKBGeIeXzAc6AbOVyhsLQ/photo/AF1QipNlEs7d9PS5whLeu2EIdGcxBfgpUb4tvaIi1w5i?key=cHJ2ZDFmVVBfVG8tbV80WUkwREVIVTN1aUYxQXhR). His insights led directly to Luke’s discovery, as well as an improved understanding of the ink signal. We’re awarding him a \$10,000 First Ink Prize. Congratulations to Casey, Luke, and Youssef! So how did we get here, and how do these models work? Let’s start with a little history. ### EduceLab scans [section: /firstletters#educelab-scans] Our story starts in 2019, when professor Brent Seales at the University of Kentucky’s EduceLab [imaged Herculaneum scrolls](https://www.theguardian.com/science/2019/oct/03/ancient-scrolls-charred-by-vesuvius-could-be-read-once-again) in a particle accelerator, generating 3D CT-scans at resolutions as high as 4 µm. His team also scanned and photographed detached scroll fragments bearing visible ink, thus providing a ground truth dataset. Professor Seales’ graduate student, Stephen Parsons, worked on detecting ink from the CT-scans using machine learning models and [found success with the detached fragments](/tutorial5). That success caught the eye of tech entrepreneurs Nat Friedman and Daniel Gross, who started Vesuvius Challenge to accelerate this progress. They launched an open competition March of 2023, and — alongside a \$700,000 Grand Prize — awarded several smaller prizes for the development of open source tools and techniques. Early in the summer, a small team of annotators (the “segmentation team”) joined our effort. They began [mapping the 3D structure of the scroll](/tutorial3) using tools initially built by EduceLab and improved by our community. By July we had segmented and “virtually flattened” hundreds of cm2 of papyrus. ### Casey’s crackle pattern [section: /firstletters#caseys-crackle-pattern] In early August, contestant Casey Handmer, an ex-JPL startup founder and polymath, wrote a [blog post](https://caseyhandmer.wordpress.com/2023/08/05/reading-ancient-scrolls/) about his discovery of a “crackle pattern” that looks like ink. Casey found the pattern by staring at the segmented CT scans for hours on end. This was a major and surprising discovery. Stephen Parsons had seen [direct evidence of ink](/tutorial5) in detached fragments before, but not yet in the scrolls. Casey was the first person in 2,000 years to find ink — and a letter — inside an unopened scroll. ### Luke Farritor’s model [section: /firstletters#luke-farritors-model] After this discovery, several contestants looked for more crackle, but it seemed quite rare. Luke Farritor, a college student and SpaceX summer intern working at Starbase, had heard about Vesuvius Challenge from Dwarkesh Patel’s [podcast interview](https://www.youtube.com/watch?v=qcvMjoJdck4) with Nat. He saw Casey’s crackle pattern being discussed in the Discord, and began spending his evenings and late nights training a machine learning model on the crackle pattern. With each new crackle found, the model improved, revealing more crackle in the scroll — a cycle of discovery and refinement. He found a few dozen ink strokes — and some complete letters — that could be labeled and used as training data. Before long, the model was unveiling traces of crackle invisible to his own eye. Soon, these traces began to form letters and hints of actual words. Luke then made a submission to our First Letters Prize, which required contestants to find at least 10 letters in a 4 cm2 area. This was his first submission: When professor Seales showed this image to our team of papyrologists, scholars specializing in works on papyrus, they gasped: they could immediately read the word “porphyras,” despite the letters being faint. After thorough technical review, we sent a newer version of his picture to the panel of papyrologists. Independently and unanimously, they annotated 13 letters, albeit with varying levels of confidence: Indeed, the word held up to scrutiny. “Porphyras” is an exciting word: it means “purple” and is quite rare in ancient texts. One papyrologist noted: “The sequence πορφυ̣ρ̣ας̣ may be πορφύ̣ρ̣ας̣ (noun, purple dye or cloths of purple) or πορφυ̣ρ̣ᾶς̣(adjective, purple). Due to the lack of context it is not possible to exclude πορφύ̣ρ̣α ς̣κ[ or πορφυ̣ρ̣ᾶ ς̣κ[.” If you’re trying to find these letters in the image, keep in mind that our modern characters look a little bit different. The letters in this ancient script look more like this: ΠΟΡΦΥΡΑϹ. Note that texts from this time didn’t use spaces, making it harder to determine word boundaries. Luke’s First Letters Prize submission is available now on [GitHub](https://github.com/lukeboi/scroll-first-letters). ### Youssef’s discovery [section: /firstletters#youssefs-discovery] Meanwhile, another contestant, Youssef Nader, an Egyptian biorobotics grad student in Berlin, pursued a different approach. Motivated by Casey and Luke’s findings, he sifted through the winning entries of the [Ink Detection prize on Kaggle](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection) — which was focused on improving Stephen Parsons’ approach of machine learning in detached fragments. He used a domain transfer technique to adapt these models to the scrolls: [unsupervised pretraining](https://github.com/younader/VesuviusPretraining) on the scroll data, followed by fine-tuning on the fragment labels. He submitted his idea for an “Ink Detection Followup Prize” and won a small prize. The idea seemed promising, but as far as we knew, that was that. Several weeks later, Youssef made his own submission to the First Letters prize. He had seen Luke’s early results which had been shared on [X](https://twitter.com/natfriedman/status/1695870954734490003) and Discord and decided to focus on the same area within the scroll. With this modified model from the Kaggle competition, he managed to find some letters, though entirely without relying on Casey’s method of manually looking for crackle. He then annotated what looked like letter shapes to the label data. He repeated this pseudo-labeling iteratively, resulting in speculative labels for a number of segments within the scroll. Models trained on these labels were then capable of detecting ink from within the scroll and the training data from the detached scroll fragments were ultimately removed. The final models trained solely on internal scroll segments resulted in the image below, securing Youssef the prize. This time, the papyrologists agreed more strongly about the letters. They even began speculating on possible words above (ανυοντα / ANYONTA, “achieving”) and below (ομοιων / OMOIωN, “similar”). If these words are indeed what we think they are, this papyrus scroll likely contains an entirely new text, unseen by the modern world. Youssef’s First Letters Prize submission is available now on [GitHub](https://github.com/younader/Vesuvius-First-Letters). ### Why were we successful? [section: /firstletters#why-were-we-successful] There were many contributions from different people in the critical path for these discoveries. Our combination of competition and open source (through “progress prizes”) seems to work! To highlight a few key contributions: * Youssef used a model from the Kaggle competition and was inspired by Luke’s results to look in the same area. * Luke’s search for crackle was directly inspired by Casey’s work. * Casey was able to look through many sheets of papyrus because our segmentation team had mapped out hundreds of cm2. * The segmentation team was able to map out a lot of papyrus because of tooling built by contestants who worked on “Segmentation Tooling Prizes” (work by Julian Schilliger, Chuck, Yao Hsiao, and many others). * The segmentation tooling advances were possible because contestants built on top of existing open source tools by professor Seales’ team (work by Seth Parker, Stephen Parsons, and many others). And of course, the contest itself wouldn’t have been possible without the foundation that Dr. Seales and his team, along with their [funders](/#partners), have laid out and continue to support. Looking back at what got us to this point, it seems that almost every single thing we did in running this contest so far has been load-bearing. We’re not quite sure what to make of this! Perhaps that progress is more fragile and success is more contingent than it often seems in retrospect. ### What’s next? [section: /firstletters#whats-next] The segmentation team and contestants continue to make progress, and a few days ago Youssef’s model generated a new image of shocking clarity and size: In this image you can clearly see four and a half columns of text, separated by margins. Many more letters are now visible, though not all are immediately legible. Our papyrological team is working hard to further investigate this result, and we’ll have updates on this soon. These advancements demonstrate that the [\$700,000 Grand Prize](/grand_prize) is within reach. Our optimism is at an all time high. Now is the best time to get involved! Join our vibrant [Discord community](https://discord.gg/V4fJhvtaQn), sign up to receive [newsletters via Substack](https://scrollprize.substack.com/), or follow [@scrollprize](https://twitter.com/scrollprize) on X. To get started, download some [data](/data), walk through some of our [tutorials](/tutorial), and catch up on the progress made by contestants by looking at the [prize winners](/winners) and [community tools](/community_projects). Will you be the one unlocking the knowledge in hundreds of scrolls — doubling the amount of texts from antiquity — and potentially thousands more that are yet to be excavated, becoming the last hero of the Roman Empire and winning \$700,000 while you’re at it? The race is on. Code is on Github: [Luke](https://github.com/lukeboi/scroll-first-letters), [Youssef](https://github.com/younader/Vesuvius-First-Letters). ===== PAGE: $12k Open Source Prizes (Dec 31) ===== URL: https://scrollprize.org/open_source_prizes STATUS: archived Note (ARCHIVED): This page has been archived and is kept for historical reference: the prizes it describes have concluded. See [Winners](/winners) for the results and [Prizes](/prizes) for what is open today. In our tradition of progress prizes, we’re awarding four \$3,000 prizes for qualifying submissions by Dec 31st. This time, we do not award prizes specific to segmentation or ink detection. Anything that increases the probability of reading the scrolls this year qualifies. There are some conditions: * Your submission must substantially increase the probability of reading the scrolls this year, as judged by the Review Team. We may award more or fewer prizes at our discretion, depending on the number of qualifying submissions. * Your submission must be open source. * We are heavily favoring submissions that: * Are released early. Tools released tomorrow have a higher chance of being used for reading the scrolls than those released a day before the deadline. * Actually get used. We’ll look for signals from the community: questions, comments, bug reports, feature requests. Our Segmentation Team will publicly provide comments on tools they use. * Submissions are closed on December 31st 11:59pm PT, after which the Review Team will select winners. * Make your submission using [this form](https://forms.gle/A8eDKEJ8Xtm2J9u38). [Segmentation](/segmentation) is still a big focus, since for the Grand Prize we need multiple large segments. Large enough to contain continuous passages of at least 140 characters. Some ideas to get you started: * The Segmentation Team has put together a list of [feature requests](https://docs.google.com/document/d/1YFILhWVHyijU_Yky3lKPvGAjmYm2QnRTYzMM7VqcogA/edit) — be sure to tag @Hari_Seldon on Discord if you’re going to work on this. These include: * Many feature requests for Volume Cartographer (we’ve been using [@spacegaier’s fork](https://github.com/spacegaier/volume-cartographer/)) * Integration of ink detection models to help see if an area was segmented correctly * Real time papyrus visualization like Khartes * Segmenting “at an angle” for tilted papyrus surfaces * Tools for detecting overlap in segments, to avoid unwittingly running training and inference on the same data. * Tools for merging segments or laying out multiple related segments in 2D (like Marzia D’Angelo’s [fragment map](/faq#books); more explanation [here](https://discord.com/channels/1079907749569237093/1085972686158712892/1115918553602855002)). * Auto-segmentation of “mushy” areas: algorithms / models that can detect and follow the papyrus fibers, even where they are bunched up with other layers of papyrus. * Comparison of various ink detection model architectures. * Anything that comes up in Discord that the community broadly deems useful. ===== PAGE: $1000 Private Progress Pics Prize (Dec 15th) ===== URL: https://scrollprize.org/private_prizes STATUS: archived Note (ARCHIVED): This page has been archived and is kept for historical reference: the prizes it describes have concluded. See [Winners](/winners) for the results and [Prizes](/prizes) for what is open today. We’re extremely curious about everyone’s progress, and want to be optimally prepared for reviewing the Grand Prize. That’s why we’re awarding a tiny prize: 5x \$200 Private Progress Pics Prize for the best *confidential* submissions of ink detection pictures from the inside of the scrolls, by Friday Dec 15th 11:59pm PT. This is completely confidential: we will not share your submission with anyone, and prize winners are not announced publicly. If you’re working on the Grand Prize and have some promising early results, take 10 minutes out of your day to select the best pictures that you’ve produced so far, and send them to [progresspics@scrollprize.org](mailto:progresspics@scrollprize.org). Include a brief explanation of your method, and relevant context of the pictures (e.g. which scroll / segment). Don’t spend too much time on this — we want you to stay focused on the Grand Prize! Only 2.5 weeks left!! Good luck everyone! ===== PAGE: Grand Prize submissions now closed ===== URL: https://scrollprize.org/submissions_closed STATUS: archived Note (ARCHIVED): This page has been archived and is kept for historical reference: the prizes it describes have concluded. See [Winners](/winners) for the results and [Prizes](/prizes) for what is open today. Grand Prize submissions now closed The 2023 Vesuvius Challenge Grand Prize submission window has closed. Review teams are evaluating entries — stay tuned as we announce results and next stages. January 1, 2024 As of 12:00am Pacific, January 1st, 2024, the submission window for the Grand Prize has closed! The technical and papyrological review teams are working through the received submissions, and we are excited to share results as soon as we can. In 2023 we made history together by revealing, for the first time ever, hidden text from the inside of a rolled Herculaneum scroll. The community that emerged around Vesuvius Challenge has been incredible, and we want to take this opportunity to say thank you. We have accelerated progress on this amazing research problem, and we will read the scrolls! Vesuvius Challenge is not over. Along with Grand Prize results, we will soon announce the next stages. For now, please stay engaged in our [community on Discord](https://discord.gg/V4fJhvtaQn), where discussion and exploration are ongoing. The [datasets](/data) will also remain available on our data server. Happy New Year to all, and let's make 2024 as incredible as 2023! ===== PAGE: Vesuvius Challenge 2023 Grand Prize awarded: we can read the scrolls! ===== URL: https://scrollprize.org/grandprize STATUS: current Note (HISTORICAL MILESTONE): This announcement is from February 2024. The 2023 Grand Prize it describes has been awarded; see [Prizes](/prizes) for what is open today. Vesuvius Challenge 2023 Grand Prize awarded: we can read the first scroll! The 2000-year-old scroll discusses music, food, and how to enjoy life’s pleasures. February 5th, 2024 We’re announcing the winners of the Vesuvius Challenge 2023 Grand Prize. We’ll look at how they did it, what the scrolls say, and what comes next. *Join us for a celebration at the Getty Villa Museum in Los Angeles on March 16th, 4pm. [More information here](https://www.getty.edu/visit/cal/events/ev_4074.html).* _Looking for the original 2023 Grand Prize rules? See [the Grand Prize page](/grand_prize)._ ## Victory [section: /grandprize#victory] Two thousand years ago, a volcanic eruption buried an ancient library of papyrus scrolls now known as the Herculaneum Papyri. In the 18th century the scrolls were discovered. Hundreds of them are now stored in a library in Naples, Italy; these lumps of carbonized ash cannot be opened without severely damaging them. But how can we read them if they remain rolled up? On March 15th, 2023, Nat Friedman, Daniel Gross, and Brent Seales launched the [Vesuvius Challenge](https://scrollprize.org) to answer this question. Scrolls from the Institut de France were imaged at the Diamond Light Source particle accelerator near Oxford. We released these high-resolution CT scans of the scrolls, and we offered more than \$1M in prizes, put forward by many generous donors. A global community of competitors and collaborators assembled to crack the problem with computer vision, machine learning, and hard work. Less than a year later, in December 2023, they succeeded. Finally, after 275 years, we can begin to read the scrolls: [](/img/grandprize/text_bcb-smaller.webp) The thoughts of our ancestors, locked in mud and ash for 2000 years, hidden in darkness — now, with the light of a worldwide effort shining upon them, finally seen again. ## Grand Prize [section: /grandprize#grand-prize] We received many excellent submissions for the Vesuvius Challenge Grand Prize, several in the final minutes before the midnight deadline on January 1st. We presented these submissions to the review team, and they were met with widespread amazement. We spent the month of January carefully reviewing all submissions. Our team of eminent papyrologists worked day and night to review 15 columns of text in anonymized submissions, while the technical team audited and reproduced the submitted code and methods. There was one submission that stood out clearly from the rest. Working independently, each member of our team of papyrologists recovered more text from this submission than any other. Remarkably, the entry achieved the criteria we set when announcing Vesuvius Challenge in March: 4 passages of 140 characters each, with at least 85% of characters recoverable. This was not a given: most of us on the organizing team assigned a less than 30% probability of success when we announced these criteria! And in addition, the submission includes another 11 (!) columns of text — more than 2000 characters total. The results of this review were clear and unanimous: the Vesuvius Challenge Grand Prize of \$700,000 is awarded to a team of three for their excellent submission. Congratulations to Youssef Nader, Luke Farritor, and Julian Schilliger! All three winning team members have been strong community contributors since the very beginning of Vesuvius Challenge. You may remember Youssef. He is the Egyptian PhD student in Berlin who was able to read a few columns of text back in October, winning the second-place [First Letters Prize](/firstletters). His results back then were particularly clear and readable, which made him the natural lead for the team that formed. You might remember Luke as well: he is the 21-year-old college student and SpaceX intern from Nebraska, who was the first person in history to read an entire word from the inside of a Herculaneum scroll (ΠΟΡΦΥΡΑϹ, “purple”). This won him the first-place First Letters Prize, a few weeks before Youssef’s results. And finally, you might remember Julian. He is the Swiss robotics student at ETH Zürich, who won three Segmentation Tooling prizes for his incredible work on Volume Cartographer. This enabled the 3d-mapping of the papyrus areas you see before you. For the Grand Prize, they assembled into a superteam, crushing it by creating what was unanimously deemed the most readable submission. The submission contains results from three different model architectures, each supporting the findings of the others, with the strongest images often coming from a [TimeSformer](https://arxiv.org/abs/2102.05095)-based model. Multiple measures prevent overfitting and hallucination, including results from multiple architectures, a study across input/output window sizes, label smoothing, and varying validation folds. Like with all our prizes, this ink detection code has been made public as open source (on [GitHub](https://github.com/younader/Vesuvius-Grandprize-Winner)), leveling up everyone in the community. [](/img/grandprize/youssef_text_wbb-hq.webp) In addition to unparalleled ink detection, the winning submission contained the strongest auto-segmentation approach we have seen to date (more about the process of “segmentation” below). [ThaumatoAnakalyptor](https://github.com/schillij95/ThaumatoAnakalyptor) (roughly: Miracle Uncoverer) by Julian generates massive papyrus segments from multiple scrolls. Re-segmentations of well known areas validate previous ink findings, and entirely new segmentations reveal writing elsewhere, such as the outermost wrap of the scroll! Congratulations to Youssef, Luke, and Julian. You are the well-deserved winners of the 2023 Vesuvius Challenge Grand Prize! ## Runners up [section: /grandprize#runners-up] Of the remaining submissions, the scores from our team of papyrologists identify a three-way tie for runner up. These entries show remarkably similar readability to each other, but still stand out from the rest by being significantly more readable. Congratulations to the following teams, each taking home \$50,000! [](/img/grandprize/sq_text_wbb.webp) [](/img/grandprize/elian_text_wbb.webp) [](/img/grandprize/lou_text_wbb.webp) These teams each brought to the table new approaches to the subtleties of ink labeling and sampling. Be sure to check out their methods at the links above. Other teams may also now choose to share their approaches, so be sure to follow our [Discord community](https://discord.gg/V4fJhvtaQn) for updates. Joining our community also provides access to the CT data and more images under our data agreement, as well as a front-row seat to daily discovery and collaboration! ## What does the scroll say? [section: /grandprize#what-does-the-scroll-say] To date, our efforts have managed to unwrap and read about 5% of the first scroll. Our eminent team of papyrologists has been hard at work and has achieved a preliminary transcription of all the revealed columns. We now know that this scroll is not a duplicate of an existing work; it contains never-before-seen text from antiquity. The papyrology team are preparing to deliver a comprehensive study as soon as they can. You all gave them a lot of work to do! Initial readings already provide glimpses into this philosophical text. From our scholars: The general subject of the text is pleasure, which, properly understood, is the highest good in Epicurean philosophy. In these two snippets from two consecutive columns of the scroll, the author is concerned with whether and how the availability of goods, such as food, can affect the pleasure which they provide. Do things that are available in lesser quantities afford more pleasure than those available in abundance? Our author thinks not: “as too in the case of food, we do not right away believe things that are scarce to be absolutely more pleasant than those which are abundant.” However, is it easier for us naturally to do without things that are plentiful? “Such questions will be considered frequently.” Since this is the end of a scroll, this phrasing may suggest that more is coming in subsequent books of the same work. At the beginning of the first text, a certain Xenophantus is mentioned, perhaps the same man — presumably a musician — also mentioned by Philodemus in his work On Music. [Philodemus](https://plato.stanford.edu/entries/philodemus/), of the Epicurean school, is thought to have been the philosopher-in-residence of the villa, working in the small library in which the scrolls were found. Initial, rough draft transcriptions: [](/img/grandprize/col-8.webp) ``` col. -8, ll. 2-14: 2 ...]ι̣μ̣εν τοὺϲ̣ [πα]ρ̣[ὰ Ξ]ε̣- νοφάντωι το̣ιούτου[ϲ, ὃ καὶ ὑπ’ ἄ̣λλων δοκεῖ 5 γείνεϲθαι, παραπλη- ϲίωϲ δ̣’ ο̣ὐδὲ παρ̣’ ἑτέρωι ἴδι̣ον το̣ῦ δ̣οκοῦ̣ντοϲ̣ εἶναι καὶ παρὰ πλε̣ί- οϲ̣ι̣ν̣ ἥδιο̣ν, ἀλλ’ ὡ̣ϲ̣ καὶ 10 ἐ̣π̣ὶ τῶν βρω̣μ̣άτ̣ων ο̣ὐ̣κ ἤδ̣η τὰ ϲπάνια πάντωϲ̣ καὶ ἡδ̣ίω τῶν δ̣αψιλῶν̣ ε̣ἶναι̣ 14 νομίζ̣ο̣με̣ν· οὐ γ̣ὰρ̣ ``` [](/img/grandprize/col-7.webp) ``` col. -7, ll. 4-10: λ̣ει παρὰ τὰ δαψιλῆ. 5 θεωρηθήϲεται δὲ τὰ τοιαῦθ’ οὕτω{ι} πολ̣λά- κιϲ πότερον ὅ̣ταν πα- ρῇ τὸ δαψιλέϲτερον ἡ φύϲιϲ ἥδιον ἀπαλλάτ- 10 τει το̣ύ̣τ̣ο̣υ̣ καὶ πάλ̣ι̣ν̣ ̣ ̣ ``` Later in the scroll: In the closing section of the text our author takes a parting shot at his adversaries, who “have nothing to say about pleasure, either in general or in particular, when it is a question of definition.” [](/img/grandprize/col-2.webp) ``` col. -2, ll. 2-8: 2 ἑ̣κάϲτηϲ κριτηρίων θεωροῦνται. πρὸϲ δὲ οὔτε καθόλου περὶ 5 ἡδονῆϲ ἐχόντων τι λέγειν οὔτε περὶ τῆϲ κατὰ μ̣έ̣ρο̣ϲ̣, ὅ̣τε ὡ- 8 ριϲμένον τι, ἀλλ’ οὖν … ``` Finally the scroll concludes: “… for we do [not] refrain from questioning some things, but understanding/remembering others. And may it be evident to us to say true things, as they might have often appeared evident!” [](/img/grandprize/col-1.webp) ``` col. -1, ll. 1-6: 1 ὰρ ἀπ̣εχόμ̣ε̣θ̣α̣ τὰ μὲν κρίνειν, τὰ δὲ κατέχειν καὶ ἐμφαί νoιθ’ ἡμῖν ἀληθῆ λέ- 5 γειν ὥϲπερ πολλά̣κιϲ ἂν ἐ̣μφανε̣ίη̣{ι}. ``` [Richard Janko](https://lsa.umich.edu/classics/people/departmental-faculty/rjanko.html) writes: “Is the author Epicurus' follower, the philosopher and poet Philodemus, the teacher of Virgil? It seems very likely. Is he writing about the effect of music on the hearer, and comparing it to other pleasures like those of food and drink? Quite probably. Does this text come from his four-part treatise on music, of which we know Book 4? Quite possibly: the title should soon become available to read. Is the Xenophantus who is mentioned the celebrated flute-player, or the man famous in antiquity for being unable to control his laughter, or someone else entirely? So many questions! But improvements to the identification of the ink, which can be expected, will soon answer most of them. I can hardly wait.” [Federica Nicolardi](https://www.docenti.unina.it/federica.nicolardi) told us: “Epicureanism says hi, with a text full of music, food, senses, and pleasure!” From [Bob Fowler](https://www.thebritishacademy.ac.uk/fellows/robert-fowler-FBA/): “Like other Epicureans, he valued pleasure above all - but pleasure rightly understood, not mere indulgence. Living in ancient Rome - a society not known for abstinence - Philodemus could expect to meet with skepticism from his readers.” Scholars might call it a philosophical treatise. But it seems familiar to us, and we can’t escape the feeling that the first text we’ve uncovered is a 2000-year-old blog post about how to enjoy life. Is Philodemus throwing shade at the stoics in his closing paragraph, asserting that stoicism is an incomplete philosophy because it has “nothing to say about pleasure?” The questions he seems to discuss — life’s pleasures and what makes life worth living — are still on our minds today. We can expect many more works from Philodemus in the current collection, once we’re able to scale up this technique. But there could be other text as well — an Aristotle dialog, a lost history of Livy, a lost Homeric epic work, a poem from Sappho — who knows what treasures are hidden in these lumps of ash. And there is the hope of a much bigger library still in the ground, since two levels of the villa remain unexcavated. More about this below! ## How accurate are these pictures? [section: /grandprize#how-accurate-are-these-pictures] Machine learning models are infamous for “hallucinating”: making up text or pictures that look similar to their training data. Similarly, there might be ways for contestants to cheat by making up images themselves, e.g. by embedding those in the model weights. How do we know that that’s not happening here? There are a couple of answers: * Technical reproduction. The Vesuvius Challenge Technical Review Team reproduced the winning submissions manually. We made sure to clearly understand every part of the code, and that when we run it independently we get similar output images. Since all code and training data is now open source, you can do the same! * Multiple submissions of the same area. You might have noticed that all submission images above show the same area of the scroll. This is because we released 3d-mapped papyrus sheets within the CT-scan (“segments”) created by our segmentation team, which were then used by all contestants. The resulting output images — created by different ML models and training labels — have produced extremely similar results. This holds not just for the winners and runner ups, but also for the other submissions that we received. * Small input/output windows. The ink detection models are not based on Greek letters, optical character recognition (OCR), or language models. Instead, they independently detect tiny spots of ink in the CT scan, the writing appearing later when these are aggregated. As a result, the text appearing in the images is not the imagined output of a machine learning model, but is instead directly tied to the underlying data in the CT scan. ## How does the unwrapping work? [section: /grandprize#how-does-the-unwrapping-work] Roughly, virtual unwrapping works in [three steps:](/tutorial) 1. Scanning: creating a 3D scan of a scroll or fragment using X-ray tomography. 2. Segmentation: tracing the crumpled layers of the rolled papyrus in the 3D scan and then unwrapping, or flattening, them. 3. Ink Detection: identifying the inked regions in the flattened segments using a machine learning model. These scrolls were scanned at Diamond Light Source, a particle accelerator near Oxford, England. The facility produces a parallel beam of X-rays at high flux, allowing for fast, accurate, and high-resolution imaging. The X-ray photos are turned into a 3D volume of voxels using tomographic reconstruction algorithms, resulting in a stack of slice images. The next step is to identify individual sheets of papyrus in 3D space. For this we primarily use a tool called [Volume Cartographer](https://github.com/educelab/volume-cartographer), created by Seth Parker and others in Brent Seales’ lab, and augmented by our contestants, primarily Julian Schilliger (Grand Prize winner) and Philip Allgaier. Volume Cartographer is operated by our team of full-time segmenters: Ben Kyles, David Josey, and Konrad Rosenberg. They use a combination of automatic algorithms and manual adjustments to map out large areas of papyrus. This is still a painstaking process, with lots of room for improvement if we’re going to segment all the scrolls. Finally, ink detection. Stephen Parsons at Brent’s lab had [shown](https://uknowledge.uky.edu/cs_etds/138/) that Herculaneum ink could theoretically be detected in CT scans, but so far only using smaller fragments — detecting ink in the larger scans of complete scrolls had yet to be achieved. For months this part proved elusive, until progress was made on two separate tracks: 1. Crackle pattern. Last summer, Casey Handmer [discovered](https://caseyhandmer.wordpress.com/2023/08/05/reading-ancient-scrolls/) a strange pattern of “crackle” by looking at raw flattened surface volumes. This pattern appeared to form letters. Casey won the First Ink Prize for this monumental discovery and shared it with the community, and a flurry of activity followed. Luke Farritor (Grand Prize winner), immediately started hunting for more crackle in flattened surface volumes produced by the segmentation team. He then trained a machine learning model on the shapes he found, which led directly to him winning the [First Letters Prize](/firstletters) in October. 2. Kaggle competition. Separately, [hundreds of teams](https://www.kaggle.com/competitions/vesuvius-challenge-ink-detection) tried building the best machine learning model for detecting ink in open fragments — pieces that had broken off during the physical unrolling process of scrolls, hundreds of years ago. Instead of labeling crackle (which wasn’t known yet), they had the benefit of ground truth data directly from photos of these fragments. This resulted in excellent models, but they did not seem to work on the flattened segments which the segmentation team produced. That was, until Youssef Nader (Grand Prize winner) used domain adaptation techniques on them, the start of a technique that ultimately won him the second place First Letters Prize. After the success of the First Letters Prize, the Grand Prize seemed within reach. Youssef, Luke, and Julian teamed up, with several other teams putting in strong submissions as well. ## What did it take? [section: /grandprize#what-did-it-take] With Vesuvius Challenge, we hope not only to solve the problem of reading the Herculaneum Papyri, but also to inspire similar projects. For that, it’s helpful to know what has contributed to our success in 2023. Here are some things we believe were important: 1. An inspiring goal and a clear target. There are many worthy causes in the world, so it helps that our goal is unusual for a computing competition. It drew more press and donations early on, it attracted an intrinsically motivated community, and it increased our probability of success to begin with (emerging research area => a higher marginal utility of dollars spent). We’d love to see more projects that are “out there,” for exactly these reasons! 2. A solid starting point. The foundation was laid by [Dr. Seales and his team](https://www2.cs.uky.edu/dri/). They spent two decades making the first scroll scans, building [Volume Cartographer](/community_projects#volume-cartographer), demonstrating the [first success](https://www2.cs.uky.edu/dri/the-scroll-from-en-gedi/) in virtual unwrapping, and [proving](https://uknowledge.uky.edu/cs_etds/138/) that Herculaneum ink can be detected in CT. 3. Blending competition and cooperation. A Grand Prize on its own would suffer from information “hoarding”: no one would share their intermediate work, because others could take it and use it to beat them to the finish line. Without information sharing, the probability of a single team solving all the puzzle pieces to win the Grand Prize would be dramatically lower. Instead, we blended competition and cooperation by adding [“progress prizes”](/winners) along the way. These were smaller prizes (often in the \$1,000-10,000 range) every ~2 months. To win a progress prize, you had to publish your code or research as open source, thereby benefiting the entire community. Besides “leveling up” the entire community, this had several side benefits. We generated buzz and excitement in the community, which was motivating for everyone. It allowed winners to re-invest their winnings into better equipment, compute time, or even reduced hours at work or study to dedicate more to the competition. And it allowed people to find each other and form teams — like we saw with the Grand Prize winners. 4. Hiring an in-house segmentation team. Every week we asked ourselves: what is the best thing we can do now to maximize the chance that someone wins the Grand Prize? In early summer, this led to the (then somewhat controversial) decision of hiring a full-time team of data labelers to manually trace the papyrus inside the scrolls and open source the flattened segments. An alternative was to leave the problem of segmentation to the contestants, or even to award separate prizes for segments, but this had several downsides. First, it’s hard to judge segment quality before knowing what to look for (we didn’t have working ink detection yet). Incentivizing segment quantity would automatically penalize quality. Second, labeling work is tedious and time consuming, and turned out to have a long learning curve, so it’s desirable to guarantee some compensation, which can’t be done with a prize. Third, the feedback loop with prizes can be pretty long. We were not dogmatically attached to just being referees; we were willing to run out onto the field and kick the ball a little. So we did what we thought would maximize success, and for the critical bottleneck of segmentation, that meant hiring a team. Ultimately, this decision worked out great. It led directly to Casey Handmer’s [discovery](https://caseyhandmer.wordpress.com/2023/08/05/reading-ancient-scrolls/) of the “crackle pattern” — the first directly visible evidence of ink and letters within the complete scrolls. The in-house segmentation expertise also turned out to be invaluable throughout the rest of the competition, discovering areas with potentially high ink signal, and figuring out the intricacies of the structure of the scrolls. And the segmenters worked closely with community contestants, which led to much better segmentation software. It was the best of both worlds! 5. Maximizing surface area for breakthroughs. Our success was the result of many smaller breakthroughs by a broad group of people. It’s remarkable how many things had to come together to make this happen. Remove any of these, and we would not have succeeded, at least not within this timeframe. There are many more contributions than we can list here - even ideas and discoveries landing outside the critical path were still important, because a massive search space had to be exhausted to find the ideas that worked. Given the right framework, the collective intelligence of a community like this is very powerful. ## What’s next? Announcing the 2024 Vesuvius Challenge Grand Prize. [section: /grandprize#whats-next-announcing-the-2024-vesuvius-challenge-grand-prize] When we started the competition, most of us estimated that we had a less than 30% probability of success within the year. At that point, no letters had yet been discovered inside of a scroll. On top of that, the scrolls had barely been segmented at all. We had doubt as to whether the project could succeed, especially by the deadline we set. Was the ink signal present? Were the scans high-resolution enough? Could the techniques used to identify ink in the fragments be transferred into a scroll? None of this was known at the time. But we knew it was worth trying! In Stage 1 of Vesuvius Challenge, we answered all of these questions, extracting 15 columns of never-before-seen text from inside a lump of carbon. We now have proven techniques for virtually unwrapping the papyrus scroll and recognizing ink using machine learning. ### Vesuvius Challenge Stage 2 [section: /grandprize#vesuvius-challenge-stage-2] In 2023 we got from 0% to 5% of a scroll. In 2024 our goal is to go from 5% of one scroll, to 90% of all four scrolls we have scanned, and to lay the foundation to read all 300 scrolls. The primary goal for 2024 is to read 90% of the scrolls, and we will issue the 2024 Grand Prize to the first team that is able to do this. More details on the exact grand prize judging criteria will be available in March. The bottleneck to achieve this milestone is the process of tracing the surface of the papyrus inside the scroll. Today this is extremely manual. It cost us more than \$100 per square centimeter in manual labor to produce the text we can read today. At this price, it would cost hundreds of millions or maybe even billions of dollars to segment all of the scrolls. While improvements to our segmentation tools have increased our efficiency, it is still far too manual and expensive. What we need is automation. And so our primary goal for stage 2 is to perfect autosegmentation. Done right, this will also allow us to read the most challenging regions within the scroll – areas where the scroll was heavily compressed, cracked, delaminated, or otherwise damaged – which in many cases our current tools cannot even penetrate. In 2023 we were amazed by the community contributions. We loved the competition for the grand prize, which brought out the best in the contestants, but we were also thrilled to see the community collaborate towards intermediate goals. In 2024 we are leaning into that, still offering a grand prize, but allocating even more of the prize pool towards community contributions – a pool that will grow as we raise more money. We’re also planning to help speed things along ourselves, balancing prizes and in-house expertise to continue the collaboration that worked so well in 2023. To this end, we’ll hire a small software/ML team, in addition to the full-time segmentation team, who will work in the open with our community to advance the state of the art. If you are interested in contributing to our funding, and joining the craziest archeological project in existence, please contact us. ### And after that? [section: /grandprize#and-after-that] After that, we will scan and read every scroll. We estimate that the scrolls we have in Naples contain more than 16 megabytes of text. Some members of our papyrology team say that revealing this text will be the greatest revolution in the classics since the Renaissance. However it goes, it will certainly be fun to try! And as if the prospect of reading hundreds of scrolls isn’t good enough, there might be an even bigger payoff at the end of all of this (as Nat said on the [Dwarkesh podcast](https://youtu.be/qcvMjoJdck4?t=646): “there is gold in this mud”). Dr. Garrett Ryan ([toldinstone](https://www.youtube.com/@toldinstone)) writes it best: “The scrolls we have now may be just the beginning. When part of the Villa of the Papyri was cleared in the 1990s, archaeologists realized that the building was much larger than previously thought, with two unexcavated levels. At the very least, these floors likely contain more papyri in cabinets and carrying cases. And it’s probable that they conceal a far greater treasure. We have not yet found the villa’s main library, which would have contained a much wider range of Greek and Latin literature. That library, with its thousands or even tens of thousands of scrolls, must still be buried. If those texts are discovered, and if even a small fraction can still be read, they will transform our knowledge of classical life and literature on a scale not seen since the Renaissance.” The potential of tens of thousands of scrolls, still buried, waiting to be discovered?! The most exciting days [still lay ahead](https://twitter.com/natfriedman/status/1712123310551548222). Read more detail about what comes next in our [Master Plan](/master_plan). ## Thank you [section: /grandprize#thank-you] This couldn’t have happened without the many, many people who contributed in various ways, and we’d like to say thanks to all of them: * Everyone who competed, shared insights, wrote code, made analyses, and brought energy to the project. * Our adventurous donors, all of whom are private individuals from the tech world, who supported this project when it was not at all clear that there was any chance of success. * The organizing teams (listed on our homepage): Vesuvius Challenge team, EduceLab team, and Papyrology team. * Our partners: EduceLab, Institut de France, Diamond Light Source, Biblioteca Nazionale di Napoli, the Getty, and Kaggle — and all their respective funders. * The professional and amateur papyrologists, historians, classicists, and other scholars — who helped answer countless questions in Discord. * The supporting staff on the Vesuvius Challenge side (Sean, Emily, Frank, Lulu), and on the University of Kentucky side (Lindsey, Eric). * The many contributors to the cause who came before us — who did excavations, wrote code, made scans, and built machines out of catgut and pig bladders to try to physically unroll the scrolls. * And of course the Grand Prize winners! Thank you all so much!! Now let’s get on with it and read the rest of the scrolls. The best is yet to come. *Join us for a celebration at the Getty Villa Museum in Los Angeles on March 16th, 4pm. [More information here](https://www.getty.edu/visit/cal/events/ev_4074.html).* ===== PAGE: Master Plan ===== URL: https://scrollprize.org/master_plan STATUS: archived Note (ARCHIVED): This page has been archived and is kept for historical reference — it reflects the project's plans as originally written. See [Open Problems](/2026_open_problems) for the current state of the pipeline and [Prizes](/prizes) for what is open today. July 25th, 2025 ## Vesuvius Challenge – Stage Two [section: /master_plan#vesuvius-challenge--stage-two] * In 2023, Vesuvius Challenge [made a breakthrough](/grandprize), extracting more than four passages of never-before-seen text from inside an unopened (and unopenable) carbonized scroll. We have proven techniques for virtually unwrapping the papyrus scroll and recognizing the ink using machine learning. It wasn’t clear it was possible until we did it. * In 2024, we proved that the results from 2023 were not a unicum by [extracting words](https://scrollprize.substack.com/p/first-letters-found-in-new-scroll) from a second unopened carbonized scroll, while we focused on making the [virtual unwrapping](/unwrapping) more efficient and automated. * In 2025, (as of July 2025) while still automating unwrapping, the focus shifted to optimizing the scanning protocol, with the aim of X-ray imaging and reading the 300 extant scrolls, mostly in Naples. By pioneering cutting‑edge X-ray scanning techniques—such as tetra‑, hexa‑, and octa‑helical acquisitions—on the [BM18 beamline at ESRF](https://www.esrf.fr/home/UsersAndScience/Experiments/StructMaterials/BM18.html), we can now scan a large scroll at 9.2 µm pixel size in under two hours. This more than halves the scan time compared to our previous sessions, while also improving effective resolution. More than thirty scrolls have been scanned under varied setups, altering both resolution and contrast mechanisms. So far, ink remains elusive in all our new data. Nevertheless, we extracted the title from one of the “readable” unopened scrolls, confirming that the author was [Philodemus of Gadara](https://scrollprize.substack.com/p/60000-first-title-prize-awarded). Two key technical problems remain: unwrapping at scale and ink identification. * Unwrapping at scale * The current bottleneck is tracing the papyrus surface inside the scan of the scroll (we call this “unwrapping”, and also “segmentation”). Currently we use semi-automated tracing aided by manual refinement. This method is still too time-consuming and affected by mistakes. Full manual tracing, as in 2023, can provide more accurate results at the expense of an even longer tracing process. * Full scrolls are 10cm-20cm wide and up to 15 meters long. With current techniques, it could cost \$1-5 million to unwrap an entire scroll. Given that there are 300 scrolls that need to be read, it could cost hundreds of millions or even more to unwrap all of them. Clearly impractical. Also, there are parts of the scrolls that are so compressed, current techniques cannot unwrap them at all. * A breakthrough is essential. We believe it’s possible to bring the cost of unwrapping an entire scroll to \$5000 or below. It might even be possible to fully automate it. * Our approach to solving unwrapping at scale will be to continue to leverage the community through a series of open source “progress prizes” we will award throughout the year, while hiring in full-time or part-time roles the most productive contributors to do the needed deep work. * Ink identification * The ink-detection breakthroughs of 2023 and 2024 do not appear to generalize to the entire collection. Why is that? We have evidence that the ink signal enhanced by the machine learning model in the two readable scrolls corresponds either to large morphological cracks or to brighter spots under X-ray, indicating a higher concentration of metals. Unfortunately, ink-detection models trained to amplify these signals are not currently performing well on the other scrolls. As a result, we are now looking for different ink characteristics to train our models on. * Analysis of fragments suggests that when ink is neither metal‑rich nor “cracked,” higher‑resolution scans may be required to enhance the amount of signal in the data. We are currently (July 2025) exploring this route. Improvements in both unwrapping at scale and ink identification are the main goals of 2025. ## Vesuvius Challenge – Stage Three [section: /master_plan#vesuvius-challenge--stage-three] * Once unwrapping will be entirely automated, and ink identification will generalize across the full collection, we’ll need to systematize and staff the scanning, segmenting, and reading pipeline. * We expect that scanning and reading all the remaining 300 scrolls in the collection can be done in 2-3 years, depending on what we learn about the maximum speed of scanning with a protocol that also maximizes ink signal in the data. ## Vesuvius Challenge – Stage Four [section: /master_plan#vesuvius-challenge--stage-four] * The final stage of the Vesuvius Challenge is inspiring the continued excavation of the Villa dei Papiri, and recovering in full the only surviving library from the ancient world. It is a near-certainty that there are more scrolls waiting for us in the dirt. Perhaps just a few, but there could be thousands of them. * Excavation is very expensive, but we expect this to be largely a political effort. Our hope is that the output of stages two and three above – previously unseen books from antiquity – will catalyze the will necessary to begin digging. If it does not, however, we will do whatever we can to make it happen. ## Costs [section: /master_plan#costs] * We believe Stage 2 will cost \$5-6M. Thanks to many individual donors and to a generous donation of \$2,084,000 from the Musk Foundation this stage is partially funded. * If an efficient particle accelerator protocol can be devised, we believe Stage 3 will cost \$4-8M. If it doesn’t, Stage 3 will cost \$15M+, depending on the cost of beam time we are able to negotiate. ## The Payoff [section: /master_plan#the-payoff] * Overfit stories of history get rewritten * Beautiful ancient literature is revealed * A new renaissance of the classics * Eternal glory ===== PAGE: Prizes ===== URL: https://scrollprize.org/2024_prizes STATUS: archived Note (ARCHIVED): This page has been archived: the 2024 prize cycle has concluded and submissions are closed. See [Winners](/winners) for the results and [Prizes](/prizes) for what is open today. This year, the community goal is to read 90% of our scanned scrolls. There are a number of prizes towards this goal: * \$200,000 - [2024 Grand Prize](#2024-grand-prize) - Read 90% of 4 scrolls from Scrolls 1-5 * \$100,000 - [First Automated Segmentation Prize](#first-automated-segmentation-prize) - Reproduce the 2023 Grand Prize result but faster * 4 x \$60,000 - [First Letters and First Title Prizes](#3-first-letters-prizes--first-title-prize) - Find the title of Scroll 1, or first letters in Scrolls 2, 3, or 4 * \$350,000 - [Monthly Progress Prizes](#monthly-progress-prizes) - Open ended prizes from \$1,000-20,000 Details below! This is a lot of information, and we want to help - bring your questions to our [Discord community](https://discord.com/invite/uTfNwwecCQ) or to [our team](mailto:team@scrollprize.org). ## 2024 Grand Prize [section: /2024_prizes#2024-grand-prize] The \$200,000 2024 Grand Prize will go to the first person or team to read 90% of 4 scrolls from Scrolls 1-5. In 2023, we got from 0% to 5% of one scroll. Reading 90% of four scrolls will lay the foundation to read all 300 scrolls. The 2024 criteria are designed to be as permissive, flexible, or favorable as possible within the high level objective of reading the scrolls. Favorable adjustments will be made if required (for example, if it is discovered conclusively that a scroll does not contain writing). Our mission is to read the scrolls. We want to award this prize!! Submission criteria and requirements 1. Segmentation * Identify the four scrolls in your submission. * Compute the total surface area (in cm2) of papyrus sheets present in all four complete scrolls combined. * We may compute and specify this value ourselves as the year progresses, in which case you can skip this step. * Compute the same measure for the papyrus sheets actually segmented in your submission. You must segment 90% or more of the total from all scrolls (not per-scroll). * Segments should be flattened and shown in 2D as if the scroll were unwrapped. Each scroll is ideally captured by a single segmentation (or each connected component of the scroll) rather than separate overlapping segmentations. * Segments should pass geometric sanity checks; for example, no self-intersections. We will evaluate [stretch metrics](https://arxiv.org/abs/2007.15551) to measure distortion. 2. Ink detection * Generate ink predictions on the segments. * The entire submission is too large to transcribe quickly, so the papyrological team will evaluate each line as: * ✅ readable (could read 85% of the characters), * ❌ not readable (couldn't), * 🟡 maybe (would have to stop and actually do the transcription to determine), or * 🔷 incomplete (line incomplete due to the physical boundaries of the scroll) * 90% of the total complete lines (incomplete lines will not be judged) must be either 🟡 maybe or ✅ readable. Multiple papyrologists may review each line, in which case ties will be broken favorably towards the submission. As a baseline, here's how the 2023 Grand Prize banner would have scored: Total lines: 240. Complete lines: 206. Passing lines: 137. Pass rate: 137 / 206 = 67% (needs to be 90%). More and larger segmentations are needed, as well as improvements to ink recovery. Already both fronts are moving forward! Multiple submissions are permitted, and we can provide feedback for early or partial submissions. If no team meets the above criteria by the deadline, Vesuvius Challenge may award the prize to the team(s) that were closest. These and other awards are at the sole discretion of Vesuvius Challenge. The deadline is 11:59 pm Pacific December 31, 2024. When you are ready, see the [submission instructions](/2024_gp_submissions). ## First Automated Segmentation Prize [section: /2024_prizes#first-automated-segmentation-prize] We're awarding \$100,000 to the first team to autosegment the 2023 Grand Prize region in Scroll 1, with quality matching or exceeding the manual segmentation from 2023 (comparable legibility and number of letters recovered). A second place \$12,500 prize is also available for the second team to achieve this. The [2023 Grand Prize](/grandprize) showed that we can extract significant regions of text from inside a sealed Herculaneum scroll - but to scale up, these methods need to be significantly faster and cheaper. This prize asks you to reproduce a year of work in much less time. We believe this is possible using improved automation! Submission criteria and requirements We will judge the segmentation by the following criteria: * Inputs. Maximum 4 hours of human input and 48 hours of compute (in any order). Existing 2023 Grand Prize segments (and overlapping ones) represent significant human input, so can only be used as inputs or training data if memorization is eliminated. Reach out to us for approval if you want to do this. Segments from elsewhere in the scroll can be used! * Outputs. Our Segmentation, Technical, and Papyrological Teams will evaluate the segmentation: * Geometric checks: Single continuous segmentation. Manifold. No self-intersections. Can exceed 2023 Grand Prize banner, but must cover 95% of the 2023 Grand Prize banner. * Segmentation accuracy. Assessed by the Segmentation Team and the Technical Team. * Flattening. You don’t necessarily have to implement flattening (it is provided in at least Volume Cartographer), but if you do, it should be comparable to 2023 Grand Prize results. * Ink detection. Comparable or better ink detection as determined by our Papyrological Team. You can use the open source 2023 Grand Prize winning solution for this. A submission requires: * Ink detection image. Submissions must include an image of the virtually unwrapped segment, showing visible and legible text. * Submit a single static image showing the text region. Images must be generated programmatically, as direct outputs of CT data inputs, and should not contain manual annotations of characters or text. Using annotations as training data is OK if they are not memorized by the model, for example if you use k-fold validation. * Include a scale bar on the submission image. * You may use open source methods (for example the 2023 Grand Prize winning submission) for ink detection. * Texture image. Include a texture image showing the papyrus fiber structure of the segmented region. * You may use Volume Cartographer’s `vc_render` or other existing tools to do this. * This image must be aligned with the above ink detection image and have the same dimensions. * Segmentation files. Provide the actual segmentation. * Expected format: A mesh file along with a UV map defining the flattening. If your approach uses another representation or parameterization, that is probably fine - feel free to ask us! * Proof of work. Your result should be reproducible using approximately 4 hours of human input and 48 hours of compute time. * Provide evidence of this. For example, a video recording the manual parts of your process. * Methodology. A detailed technical description of how your solution works. We need to be able to reproduce your work, so please make this as easy as possible: * For fully automated software, consider a Docker image that we can easily run to reproduce your work, and please include system requirements. * For software with a human in the loop, please provide written instructions and a video explaining how to use your tool. We’ll work with you to learn how to use it, but we’d like to have a strong starting point. * Please include an easily accessible link from which we can download it. Submissions must be made by 11:59pm Pacific, December 31, 2024. Make your submission using [this form](https://forms.gle/PyrriG8XFut7kqJeA). ## 3 First Letters Prizes + First Title Prize [section: /2024_prizes#3-first-letters-prizes--first-title-prize] We’re issuing 3 more First Letters prizes, as well as a First Title Prize! * First Title in Scroll 1: \$60,000 1st place, \$15,000 2nd place * First Letters in Scroll 2: \$60,000 1st place, \$15,000 2nd place * First Letters in Scroll 3: \$60,000 1st place, \$15,000 2nd place * First Letters in Scroll 4: \$60,000 1st place, \$15,000 2nd place For Scrolls 2, 3, and 4, \$60,000 will be awarded to the first team that uncovers 10 letters within a single area of 4 cm2, and open sources their methods and results (***after*** winning the prize). \$15,000 is also available for the second team to meet this bar. We are also awarding \$60,000 to the first team to unveil the title of Scroll 1, and \$15,000 to the second team to find it before it is announced. For more information about where to look for the title, see the [announcement of the First Title prize](https://scrollprize.substack.com/p/30k-first-title-prize). The purpose of these prizes is to close the gap between our current state of the art and the seriously challenging 2024 Grand Prize. Last year we showed it is possible to recover text from a single rolled scroll. Generalizing these methods across multiple scrolls and scans will make them more robust, which will be needed to read the complete library. Submission criteria and requirements * Image. Submissions must be an image of the virtually unwrapped segment, showing visible and legible text. * Submit a single static image showing the text region. Images must be generated programmatically, as direct outputs of CT data inputs, and should not contain manual annotations of characters or text. * For the First Title Prize, please illustrate the ink predictions in spatial context of the title search, similar to what is [shown here](https://scrollprize.substack.com/p/30k-first-title-prize). You do not have to read the title yourself, but just have to produce an image of it that our team of papyrologists are able to read. * Specify which scroll the image comes from. For multiple scrolls, please make multiple submissions. * Include a scale bar showing the size of 1 cm on the submission image. * Specify the 3D position of the text within the scroll. The easiest way to do this is to provide the segmentation file (or the segmentation ID, if using a public segmentation). * Methodology. A detailed technical description of how your solution works. We need to be able to reproduce your work, so please make this as easy as possible: * For fully automated software, consider a Docker image that we can easily run to reproduce your work, and please include system requirements. * For software with a human in the loop, please provide written instructions and a video explaining how to use your tool. We’ll work with you to learn how to use it, but we’d like to have a strong starting point. * Please include an easily accessible link from which we can download it. * Hallucination mitigation. If there is any risk of your model hallucinating results, please let us know how you mitigated that risk. Tell us why you are confident that the results you are getting are real. * We strongly discourage submissions that use window sizes larger than 0.5x0.5 mm to generate images from machine learning models. This corresponds to 64x64 pixels for 8 µm scans. If your submission uses larger window sizes, we may reject it and ask you to modify and resubmit. * Other information. Feel free to include any other things we should know. Your submission will be reviewed by the review teams to verify technical validity and papyrological plausibility and legibility. Just as with the Grand Prize, please do not make your discovery public until winning the prize. We will work with you to announce your findings. Submissions must be made by 11:59pm Pacific, December 31, 2024. Make your submission using [this form](https://forms.gle/hQtXEtG95zpvfKDd6). ## Monthly Progress Prizes [section: /2024_prizes#monthly-progress-prizes] We’re awarding an estimated \$350,000 this year in monthly progress prizes for submissions that get us closer to reading 90% of four scrolls. These prizes are more open-ended, and we have a wishlist to provide some ideas. If you are new to the project, this is a great place to start. Progress prizes will be awarded at a range of levels based on the contribution: * Gold Aureus: \$20,000 (estimated 4-8 per year) – for major contributions * Denarius: \$10,000 (estimated 10-15 per year) * Sestertius: \$2,500 (estimated 25 per year) * Papyrus: \$1,000 (estimated 50 per year) We favor submissions that: * Are released or open-sourced early. Tools released earlier have a higher chance of being used for reading the scrolls than those released the last day of the month. * Actually get used. We’ll look for signals from the community: questions, comments, bug reports, feature requests. Our Segmentation Team will publicly provide comments on tools they use. * Are well documented. It helps a lot if relevant documentation, walkthroughs, images, tutorials or similar are included with the work so that others can use it! Our Wish List (progress prize ideas!) These encompass a wide range of award levels. Check back as we’ll update this list! * Ink refinement: Other prizes target *new* ink findings, but we also want to see improvements to existing passages where ink recovery is poor * 3D/volumetric ink detection: and other creative approaches * Improved documentation: updates to tutorials and introductions * Pull requests to [our website](https://github.com/ScrollPrize/scrollprize-website) or standalone resources both accepted! * Volume Cartographer - [EduceLab](https://github.com/educelab/volume-cartographer), [spacegaier fork](https://github.com/spacegaier/volume-cartographer) * Multi-axes viewports & segmentation * Enable 3D (XYZ) inspection of scroll volume (similar to [Khartes](https://github.com/KhartesViewer/khartes)) * Allow free-3D (not just XYZ) rotation with updating viewports * Ability to continue segmentation at any angle of rotation * Flattened preview of editable/extendable segments * Live or near-live rendering from OME-Zarr volume * Enable live or near-live inspection of fiber continuity (similar to [Khartes](https://github.com/KhartesViewer/khartes)) * Ink detection preview of editable/extendable segments * Live or near-live rendering from OME-Zarr * Live or near-live updated ink detection viewport, similar to the flattened segment preview * Interchangeable ink detection models * Import and Display pointclouds in VC * For inspection * For segmentation * Novel segmentation algorithms * GUI improvements * Bug fixes * Eliminate dot residue: dots that were moved occasionally appear to remain in their original location until a view reset * Ability to save active changes to disk while Segmentation Tool is active * Disable re-saving for display-only segments; ask the user whether to save changed segments upon leaving "compute" mode * [ThaumatoAnakalyptor](https://github.com/schillij95/ThaumatoAnakalyptor): * Better solution for sheet stitching * Improved point cloud extraction * Improved mesh reconstruction * More information in the [roadmap](https://github.com/schillij95/ThaumatoAnakalyptor/blob/main/documentation/ThaumatoAnakalyptor___Technical_Report_and_Roadmap.pdf) * Compressed areas: improved segmentation methods for regions of compressed papyrus * Live previews: show live segment previews during segmentation and allow refinements to update the preview * Scan analysis: analyze multi-energy/multi-resolution scans to identify optimal scan settings * Volume registration: automated deformable techniques to align different scans (resolution, energy) of the same object * Visualization tools * Segmentation inspection tools * Performance improvements: so these steps can handle larger segmentations: * Segmentation * Flattening * Rendering * Ink detection Submissions are evaluated monthly, and multiple submissions/awards per month are permitted. The next deadline is 11:59pm Pacific, December 31, 2024! When ready, please submit using [this form](https://forms.gle/oCmaaAMrZuAEQ68W6). ## Terms and Conditions [section: /2024_prizes#terms-and-conditions] Prizes are awarded at the sole discretion of Scroll Prize Inc. and are subject to review by our Technical Team, Segmentation Team, and Papyrological Team. We may issue more or fewer awards based on the spirit of the prize and the received submissions. You agree to make your method open source if you win a prize. It does not have to be open source at the time of submission, but you have to make it open source under a permissive license to accept the prize. Submissions for the First Automated Segmentation Prize, each First Letters Prize, the First Title Prize, and the 2024 Grand Prize will close once the winner is announced and their methods are open sourced. Scroll Prize Inc. reserves the right to modify prize terms at any time in order to more accurately reflect the spirit of the prize as designed. Prize winner must provide payment information to Scroll Prize Inc. within 30 days of prize announcement to receive prize. ===== PAGE: 2024 Grand Prize Submission Instructions ===== URL: https://scrollprize.org/2024_gp_submissions STATUS: archived Note (ARCHIVED): This page has been archived: submissions for the 2024 Grand Prize are closed. See [Prizes](/prizes) for what is open today. ### Submitting your result [section: /2024_gp_submissions#submitting-your-result] If you have a qualifying result, submit it for consideration by sending an email to [grandprize@scrollprize.org](mailto:grandprize@scrollprize.org) and provide the following: * Images. Submissions must be in the form of images of the virtually unwrapped papyrus, showing visible and legible text. * Submit a single static image for each scroll. If necessary, the image can be tiled to reasonable dimensions. Images must be generated programmatically, as direct outputs of CT data inputs, and should not contain manual annotations of characters or text. * Specify which scroll each image came from. * Specify where in the scroll they were found: include information about the position of the text vertically as well as radially within the scroll. One easy way to do this is to provide images showing the 3D position of the text surface inside the scroll. * Include metric scale bars on each submission image. * Methodology. A detailed technical description of how your solution works. We need to be able to reproduce your work, so please make this as easy as possible: * For fully automated software, please create a Docker image that we can easily run to reproduce your work, and please include system requirements. * For software with a human in the loop, please provide written instructions and a video explaining how to use your tool. We’ll work with you to learn how to use it, but we’d like to have a strong starting point. It should take us no more than an hour to perform the human tasks to get your software working. * Either attach your code/video directly to the email, or include an easily accessible link from which we can download it. * Hallucination mitigation. * If there is any risk of your model hallucinating results, please let us know how you mitigated that risk. Tell us why you are confident that the results you are getting are real. * We strongly discourage submissions that use window sizes larger than 0.5x0.5 mm to generate images from machine learning models. This corresponds to 64x64 pixels for 8 µm scans. If your submission uses larger window sizes, we may reject it and ask you to modify and resubmit. * Other information. Feel free to include any other things we should know. If you’re competing as a team, please have your team leader submit your results. We will communicate with the team leader exclusively, and any prize money will be distributed according to the instructions of the team leader. You’d have to sort out within your team how to split any prizes. ### Review process [section: /2024_gp_submissions#review-process] All submissions will be assessed by the Review Team, which consists of a technical team to review your methodology, and an independent team of papyrologists to review your results. Note that the Review Team also judges the progress prizes. We will process your submission as follows: 1. Technical assessment. The technical team will look at your method, and try to reproduce your results independently. * We want to make sure that your method doesn’t hallucinate, so please let us know how you mitigated this risk. * We will work with you on reproducing your solution. We might have questions, such as how your code works, how to use your manual tools (if applicable), and so on. Please make it as easy for us to run your code as reasonably possible, but also don’t wait until your solution is perfect. If you have any questions, or if you’re wondering if you’re ready to submit, just reach out! * We will acknowledge having received your submission within a week. Depending on the difficulty of verifying your methodology, it might take longer until we are able to make our final assessment. 2. Papyrological assessment. Once we are reasonably confident that your solution is technically valid and appears to meet the qualifications, we will share your results with the papyrology team, who will proceed with papyrological evaluation. ===== PAGE: Jobs ===== URL: https://scrollprize.org/jobs STATUS: current # Jobs Our mission is simple and bold: read the Herculaneum scrolls. We don’t have open roles right now, but we’re always excited to meet exceptional people who can move this mission forward. Even when we’re not hiring, a great way to catch our attention is to start as a contributor: work on the [open prizes](/prizes), win one, and join the community on [Discord](https://discord.gg/V4fJhvtaQn) — many of the people working with us today started exactly that way. If that’s you, send a brief note with your CV and how you could help to jobs@scrollprize.org *** ===== PAGE: Virtual Unwrapping ===== URL: https://scrollprize.org/unwrapping STATUS: archived # Virtual Unwrapping Note (ARCHIVED): This page has been archived and is no longer maintained. It describes an earlier generation of the Vesuvius Challenge pipeline — tools, data layouts, and results referenced here may have been superseded. See [Open Problems](/2026_open_problems) for the current state of the pipeline and [Prizes](/prizes) for what is open today. The image data of the Herculaneum scrolls (PHerc 172) look like this: It's a mess! The scrolls, that survived a volcanic eruption and were buried under lava and mud for centuries, are carbonized, damaged, frayed and, most importantly, still wrapped! To read a scroll, we first need to unwrap it... virtually! If, within the chaotic 3D image you are observing, you can isolate a contiguous region of the papyrus sheet, you can approximate it with a 2-manifold—specifically, an orientable genus-0 developable surface. This allows you to construct a bidimensional isometric parametrization[^1] on the manifold, thereby defining a local basis. The 2-manifold is typically represented as a non-watertight triangular mesh. When rendered in the coordinate frame established by its local basis, the surface appears flat, provided that the parametrization is derived from an isometric mapping from 3D to 2D. In this case, local distances, shapes, and angles are preserved, ensuring geometric fidelity in the transformation. By rendering the mesh in 2D and observing the now-flattened papyrus sheet, faint letters begin to emerge — appearing as brighter regions in the figure. These weak ink traces are captured by machine learning, that can enhance their visibility and improve text recovery. ## The Open Question [section: /unwrapping#the-open-question] Virtual unwrapping is essential to read the scrolls, but far from trivial. The open question that has been puzzling our community for more than one year, and Dr. Seales’ research for over twenty-five years, is the following: > Can we find an automated way to isolate the 2-manifold that represents the rolled scroll in the 3D images? We were awarding \$100k to anyone that could solve this problem by the end of 2024. The prize was left unclaimed. However, both the community and the team worked on two approaches that are currently the state-of-the-art in virtual unwrapping attempts: - Spiral Fitting - Surface Tracer On a very high level, both methods apply two major steps: 1. Extract from the raw data a more manageable intermediate representation (via ML or classic filters). 2. Process this representation into a surface mesh (via either top-down or bottom-up strategies). Top-down approaches solve a global optimization problem: they try to fit a complete surface representing the scroll to the intermediate representation at once. Bottom-up approaches solve a local optimization problem, building small patches that are then stitched together coherently. All approaches rely also on the information about the scroll umbilicus. Unfortunately, no method currently manages to fit the intended surface to the data! Let us delve into the details of how the current state-of-the-art methods work. ## Top-down methods [section: /unwrapping#top-down-methods] ### Spiral Fitting [section: /unwrapping#spiral-fitting] (Overview) This method leverages the idea that the scroll, in its original form, was a 2D spiral extruded in a 3D shape with approximate cylindrical symmetry. Once flattened, the papyrus sheet is nearly rectangular, with locally perpendicular fibers. The approach attempts to find the transformation that deformed this canonical spiral into the observed data. #### Intermediate Representations [section: /unwrapping#intermediate-representations] The method extracts useful intermediate representations from the raw 3D images using machine learning–based semantic segmentation, more specifically nnUNet[^2], to isolate characteristic features that can be used in the fitting step. Specifically, the extracted intermediate representations are: - Surface sheets predictions: $\mathcal{S}$ - Vertical papyrus fibers predictions: $\mathcal{F}_v$ - Horizontal papyrus fibers predictions: $\mathcal{F}_h$ These representations are not free from mistakes (e.g., fake mergers or false positives), but they still make the geometry easier to handle than raw data alone. #### Geometry Processing [section: /unwrapping#geometry-processing] Given surface predictions $\mathcal{S}$, vertical papyrus fibers $\mathcal{F}_v$, horizontal papyrus fibers $\mathcal{F}_h$, and a canonical non-deformed spiral $\mathcal{S}_0$, the goal is to find a 3D diffeomorphism, i.e. a differentiable and invertible transformation from $\mathcal{S}_0$ to $\mathcal{S}$. We can represent this transformation as an integrable, parametrized flow field $\mathbf{u}(\mathbf{x})$ in the full 3D volume. The canonical spiral $\mathcal{S}_0$ is displaced by the flow vectors $\mathbf{u}$. To find the best flow field, we minimize a global objective that aligns the deformed canonical surface to the intermediate representation while enforcing fiber directions. For example, by an abuse of notation: $$ \min_{\mathbf{u}(\mathbf{x})} \Bigg[ \int_{\Omega} d\Omega \underbrace{\big\| (\mathcal{S}_0(\mathbf{x}) + \mathbf{u}(\mathbf{x})) - \mathcal{S}(\mathbf{x}) \big\|^2}_{\text{data fidelity}} + \underbrace{\lambda R(\mathbf{u}, \mathcal{F}_v, \mathcal{F}_h)}_{\text{fiber base regularization}} \Bigg] $$ where $\mathcal{S}_0(\mathbf{x}) + \mathbf{u}(\mathbf{x})$ represents the canonical spiral displaced by the flow field, $\Omega$ is the domain in the 3D volume, and $R(\mathbf{u}, \mathcal{F}_v, \mathcal{F}_h)$ enforces that vertical/horizontal fibers in $\mathcal{S}$ match up properly when flattened. #### First Automated Segmentation Prize Submission [section: /unwrapping#first-automated-segmentation-prize-submission] Spiral fitting was submitted by Prof Paul Henderson for the First Automated Segmentation Prize of 2024. Although it did not meet the needed quality criteria to win, it was the most elegant solution according to the Vesuvius Challenge Team. [](/img/virtual-unwrapping/fasp-spiral-fitting.webp) For more information, visit [this repository](https://github.com/pmh47/spiral-fitting). ## Bottom-up methods [section: /unwrapping#bottom-up-methods] ### Surface Tracer [section: /unwrapping#surface-tracer] (Overview) Surface Tracer recognizes that, physically, the papyrus sheet is relatively continuous and should not bend abruptly from one point to the next. Instead of a global approach, it grows a surface mesh locally by “tracing” the sheet. #### Intermediate Representation [section: /unwrapping#intermediate-representation] As with Spiral Fitting, a semantic segmentation of the surface sheet is obtained using nnUNet[^2]. The predictions may contain fake mergers, holes, and other errors, but they focus on identifying likely surface voxels. #### Geometry Processing [section: /unwrapping#geometry-processing-1] Starting from one or multiple small patches on the intermediate representation, the method iteratively expands these patches. In each step, a new point on the fringe is chosen to minimize a local objective. A typical local objective might be: $$ \min_{\mathbf{x}_{new}} \Big[ \underbrace{\lambda_{\text{data}} \, d(\mathbf{x}_{new}, \mathcal{S})}_{\text{data fidelity}} +\underbrace{ \lambda_{\text{dist}} \, \|\mathbf{x}_{new} - \mathbf{x}_{\text{fringe}}\| + \lambda_{\text{bend}} \, B(\mathbf{x}_{new}, M_{\text{current}})}_{\text{physical inspired term}} \Big] $$ where: - $d(\mathbf{x}_{new}, \mathcal{S})$ measures how well the new point sits on the surface predictions, - $\|\mathbf{x}_{new} - \mathbf{x}_{\text{fringe}}\|$ prevents large jumps, - $B(\mathbf{x}_{new}, M_{\text{current}})$ measures how adding the new point affects the mesh local curvature (flatness). Every *n* iterations, the mesh is smoothed to better approximate a developable surface. Because growing a single mesh is slow, multiple patches are grown in parallel and then merged via a consensus algorithm. Finally, human annotators should manually further refine the results to reduce mistakes in the obtained mesh. #### First Automated Segmentation Prize Submission [section: /unwrapping#first-automated-segmentation-prize-submission-1] The surface tracer was submitted by Dr Hendrik Schilling and Sean Johnson for the First Automated Segmentation Prize of 2024. Although it did not meet the needed quality criteria to win, it was very close to the target! [](/img/virtual-unwrapping/fasp-surface-tracer.jpg) More information [here](https://github.com/hendrikschilling/FASP). --- ## Conclusion [section: /unwrapping#conclusion] Both methods—Spiral Fitting and Surface Tracer—share *at a very high level* a similar pipeline of extracting an intermediate representation and then building a surface mesh via geometry processing. However, each takes a different path to deal with errors and ambiguities in the data: - Spiral Fitting uses a global approach to align a canonical shape to the segmented surface and fiber directions. - Surface Tracerlocally expands a mesh from patches, carefully balancing data fidelity and smoothness. Despite these advances, the problem is still unsolved. No method so far manages to perfectly fit the wanted surface to the data. The most common error is sheet switching, i.e. when the fitted surface jumps a winding, resulting in a distorted, non realistic shape. We need your help to virtually unwrap the Herculaneum scrolls. --- ## References [section: /unwrapping#references] [^1]: Rabinovich et al. (2017). _Scalable Locally Injective Mappings_. ACM Transactions on Graphics (TOG), 36(4), 1. [^2]: Isensee et al. (2024). _nnU-Net Revisited: A Call for Rigorous Validation in 3D Medical Image Segmentation_, International Conference on Medical Image Computing and Computer-Assisted Intervention (pp. 488-498). Cham: Springer Nature Switzerland. ===== PAGE: The Villa dei Papiri in LEGO® ===== URL: https://scrollprize.org/villa_model STATUS: current We commissioned a model of the Villa dei Papiri, made using LEGO® bricks, designed by [Belle-Ve Bricks](https://bellevebricks.com/)! You can find the build instructions here: * [Download build instructions (.pdf)](https://drive.google.com/file/d/1vIp-fIOYOh8ukCI6HSrSfBP-nAel7AII/view?usp=sharing) Here are some bonuses: * [3D model (.dae)](https://drive.google.com/file/d/1M66Mth8BBaEA9vDFZzyP3PuU8_TpxJIy/view?usp=drive_link) * [CAD file (.ldr)](https://drive.google.com/file/d/19mWyPmxUkGZDcNYq97MesiavrAZVZQA4/view?usp=drive_link) 3D model viewer and some renders below: ===== PAGE: Open Prizes ===== URL: https://scrollprize.org/prizes STATUS: current Vesuvius Challenge is ongoing and YOU can win the below prizes and help us make history! *** ## 2027 Grand Prize [section: /prizes#2027-grand-prize] \$800,000 to the first team or individual to fully unroll and make readable a scroll from the set below. We also have prizes for second place (\$100,000), third place (\$50,000), and fourth place (\$50,000) — \$1,000,000 in total. Prizes are awarded according to the rules listed below. Prizes will be awarded to any team or individual that fully digitally unrolls and makes readable (according to the conditions and requirements specified below) one of the eligible CT scans of carbonized scrolls from Herculaneum: Eligible scroll volumes (13) 1. [PHerc. 125](/data_browser/PHerc0125) — [20250720091415-9.362um-1.2m-113keV](https://neuroglancer-demo.appspot.com/#!%7B%22layers%22%3A%5B%7B%22type%22%3A%22image%22%2C%22source%22%3A%22zarr2%3A//https%3A//vesuvius-challenge-open-data.s3.us-east-1.amazonaws.com/PHerc0125/volumes/20250821151825-9.362um-1.2m-113keV-masked.zarr%22%2C%22name%22%3A%22125_9.362um%22%2C%22shader%22%3A%22%23uicontrol%20invlerp%20normalized%5Cnvoid%20main%28%29%20%7B%20emitGrayscale%28normalized%28%29%29%3B%20%7D%22%7D%5D%2C%22layout%22%3A%224panel%22%7D) 2. [PHerc. 191](/data_browser/PHerc0191) — [20250720024445-9.362um-1.2m-113keV](https://neuroglancer-demo.appspot.com/#!%7B%22layers%22%3A%5B%7B%22type%22%3A%22image%22%2C%22source%22%3A%22zarr2%3A//https%3A//vesuvius-challenge-open-data.s3.us-east-1.amazonaws.com/PHerc0191/volumes/20250821151635-9.362um-1.2m-113keV-masked.zarr%22%2C%22name%22%3A%22191_9.362um%22%2C%22shader%22%3A%22%23uicontrol%20invlerp%20normalized%5Cnvoid%20main%28%29%20%7B%20emitGrayscale%28normalized%28%29%29%3B%20%7D%22%7D%5D%2C%22layout%22%3A%224panel%22%7D) 3. [PHerc. 211](/data_browser/PHerc0211) — [20250720140115-9.362um-1.2m-113keV](https://neuroglancer-demo.appspot.com/#!%7B%22layers%22%3A%5B%7B%22type%22%3A%22image%22%2C%22source%22%3A%22zarr2%3A//https%3A//vesuvius-challenge-open-data.s3.us-east-1.amazonaws.com/PHerc0211/volumes/20250821151803-9.362um-1.2m-113keV-masked.zarr%22%2C%22name%22%3A%22211_9.362um%22%2C%22shader%22%3A%22%23uicontrol%20invlerp%20normalized%5Cnvoid%20main%28%29%20%7B%20emitGrayscale%28normalized%28%29%29%3B%20%7D%22%7D%5D%2C%22layout%22%3A%224panel%22%7D) 4. [PHerc. 257](/data_browser/PHerc0257) — [20250720113058-9.362um-1.2m-113keV](https://neuroglancer-demo.appspot.com/#!%7B%22layers%22%3A%5B%7B%22type%22%3A%22image%22%2C%22source%22%3A%22zarr2%3A//https%3A//vesuvius-challenge-open-data.s3.us-east-1.amazonaws.com/PHerc0257/volumes/20250821151750-9.362um-1.2m-113keV-masked.zarr%22%2C%22name%22%3A%22257_9.362um%22%2C%22shader%22%3A%22%23uicontrol%20invlerp%20normalized%5Cnvoid%20main%28%29%20%7B%20emitGrayscale%28normalized%28%29%29%3B%20%7D%22%7D%5D%2C%22layout%22%3A%224panel%22%7D) 5. [PHerc. 268](/data_browser/PHerc0268) — [20250511054932-8.640um-1.2m-116keV](https://neuroglancer-demo.appspot.com/#!%7B%22layers%22%3A%5B%7B%22type%22%3A%22image%22%2C%22source%22%3A%22zarr2%3A//https%3A//vesuvius-challenge-open-data.s3.us-east-1.amazonaws.com/PHerc0268/volumes/20251110183117-8.640um-1.2m-116keV-masked.zarr%22%2C%22name%22%3A%22268_8.64um%22%2C%22shader%22%3A%22%23uicontrol%20invlerp%20normalized%5Cnvoid%20main%28%29%20%7B%20emitGrayscale%28normalized%28%29%29%3B%20%7D%22%7D%5D%2C%22layout%22%3A%224panel%22%7D) 6. [PHerc. 358](/data_browser/PHerc0358) — [20250719150703-9.362um-1.2m-113keV](https://neuroglancer-demo.appspot.com/#!%7B%22layers%22%3A%5B%7B%22type%22%3A%22image%22%2C%22source%22%3A%22zarr2%3A//https%3A//vesuvius-challenge-open-data.s3.us-east-1.amazonaws.com/PHerc0358/volumes/20250821151737-9.362um-1.2m-113keV-masked.zarr%22%2C%22name%22%3A%22358_9.362um%22%2C%22shader%22%3A%22%23uicontrol%20invlerp%20normalized%5Cnvoid%20main%28%29%20%7B%20emitGrayscale%28normalized%28%29%29%3B%20%7D%22%7D%5D%2C%22layout%22%3A%224panel%22%7D) 7. [PHerc. 800](/data_browser/PHerc0800) — [20250510225703-8.640um-1.2m-116keV](https://neuroglancer-demo.appspot.com/#!%7B%22layers%22%3A%5B%7B%22type%22%3A%22image%22%2C%22source%22%3A%22zarr2%3A//https%3A//vesuvius-challenge-open-data.s3.us-east-1.amazonaws.com/PHerc0800/volumes/20250521135224-8.640um-1.2m-116keV-masked.zarr%22%2C%22name%22%3A%22800_8.64um%22%2C%22shader%22%3A%22%23uicontrol%20invlerp%20normalized%5Cnvoid%20main%28%29%20%7B%20emitGrayscale%28normalized%28%29%29%3B%20%7D%22%7D%5D%2C%22layout%22%3A%224panel%22%7D) 8. [PHerc. 813](/data_browser/PHerc0813) — [20250720160015-9.362um-1.2m-113keV](https://neuroglancer-demo.appspot.com/#!%7B%22layers%22%3A%5B%7B%22type%22%3A%22image%22%2C%22source%22%3A%22zarr2%3A//https%3A//vesuvius-challenge-open-data.s3.us-east-1.amazonaws.com/PHerc0813/volumes/20250821151723-9.362um-1.2m-113keV-masked.zarr%22%2C%22name%22%3A%22813_9.362um%22%2C%22shader%22%3A%22%23uicontrol%20invlerp%20normalized%5Cnvoid%20main%28%29%20%7B%20emitGrayscale%28normalized%28%29%29%3B%20%7D%22%7D%5D%2C%22layout%22%3A%224panel%22%7D) 9. [PHerc. 826](/data_browser/PHerc0826) — [20250720174915-9.362um-1.2m-113keV](https://neuroglancer-demo.appspot.com/#!%7B%22layers%22%3A%5B%7B%22type%22%3A%22image%22%2C%22source%22%3A%22zarr2%3A//https%3A//vesuvius-challenge-open-data.s3.us-east-1.amazonaws.com/PHerc0826/volumes/20250821151701-9.362um-1.2m-113keV-masked.zarr%22%2C%22name%22%3A%22826_9.362um%22%2C%22shader%22%3A%22%23uicontrol%20invlerp%20normalized%5Cnvoid%20main%28%29%20%7B%20emitGrayscale%28normalized%28%29%29%3B%20%7D%22%7D%5D%2C%22layout%22%3A%224panel%22%7D) 10. [PHerc. 1203](/data_browser/PHerc1203) — [20250720004030-9.362um-1.2m-113keV](https://neuroglancer-demo.appspot.com/#!%7B%22layers%22%3A%5B%7B%22type%22%3A%22image%22%2C%22source%22%3A%22zarr2%3A//https%3A//vesuvius-challenge-open-data.s3.us-east-1.amazonaws.com/PHerc1203/volumes/20250820131727-9.362um-1.2m-113keV-masked.zarr%22%2C%22name%22%3A%221203_9.362um%22%2C%22shader%22%3A%22%23uicontrol%20invlerp%20normalized%5Cnvoid%20main%28%29%20%7B%20emitGrayscale%28normalized%28%29%29%3B%20%7D%22%7D%5D%2C%22layout%22%3A%224panel%22%7D) 11. [PHerc. 1218](/data_browser/PHerc1218) — [20250510170249-8.640um-1.2m-116keV](https://neuroglancer-demo.appspot.com/#!%7B%22layers%22%3A%5B%7B%22type%22%3A%22image%22%2C%22source%22%3A%22zarr2%3A//https%3A//vesuvius-challenge-open-data.s3.us-east-1.amazonaws.com/PHerc1218/volumes/20250521120456-8.640um-1.2m-116keV-masked.zarr%22%2C%22name%22%3A%221218_8.64um%22%2C%22shader%22%3A%22%23uicontrol%20invlerp%20normalized%5Cnvoid%20main%28%29%20%7B%20emitGrayscale%28normalized%28%29%29%3B%20%7D%22%7D%5D%2C%22layout%22%3A%224panel%22%7D) 12. [PHerc. 1447](/data_browser/PHerc1447) — [20250509011039-8.640um-1.2m-116keV](https://neuroglancer-demo.appspot.com/#!%7B%22layers%22%3A%5B%7B%22type%22%3A%22image%22%2C%22source%22%3A%22zarr2%3A//https%3A//vesuvius-challenge-open-data.s3.us-east-1.amazonaws.com/PHerc1447/volumes/20250521151220-8.640um-1.2m-116keV-masked.zarr%22%2C%22name%22%3A%221447_8.64um%22%2C%22shader%22%3A%22%23uicontrol%20invlerp%20normalized%5Cnvoid%20main%28%29%20%7B%20emitGrayscale%28normalized%28%29%29%3B%20%7D%22%7D%5D%2C%22layout%22%3A%224panel%22%7D) 13. [PHerc. 1545](/data_browser/PHerc1545) — [20250720045926-9.362um-1.2m-113keV](https://neuroglancer-demo.appspot.com/#!%7B%22layers%22%3A%5B%7B%22type%22%3A%22image%22%2C%22source%22%3A%22zarr2%3A//https%3A//vesuvius-challenge-open-data.s3.us-east-1.amazonaws.com/PHerc1545/volumes/20250821151648-9.362um-1.2m-113keV-masked.zarr%22%2C%22name%22%3A%221545_9.362um%22%2C%22shader%22%3A%22%23uicontrol%20invlerp%20normalized%5Cnvoid%20main%28%29%20%7B%20emitGrayscale%28normalized%28%29%29%3B%20%7D%22%7D%5D%2C%22layout%22%3A%224panel%22%7D) Deadline: June 25th, 2027 (11:59pm Pacific) Submission criteria and requirements General conditions * Pipeline fully reproducible and code shared under an open source license (e.g. MIT), published publicly on GitHub. It does not have to be open source at the time of submission, but you have to make it open source under a permissive license, publicly on GitHub, to accept the prize. * Pipeline should be seamlessly integrated in the [VC3D](https://github.com/ScrollPrize/villa/tree/main/volume-cartographer) software. * 100% of the papyrus recto surface unrolled. If the scroll possesses flakes or detached patches, they should also be segmented and unrolled either in a single or in a sequence of separate tifxyz meshes. It is permissible to skip disconnected outer patches if they constitute less than 10% of the total scroll surface. * Ink detection or renders with ink should be produced from or on top of the flattened images. Columns of text should be visible everywhere. Verify that at least 70% of each counted column's preserved characters are legible. Legible characters only count as legible when identified on a letter-by-letter basis without papyrological interpolation. If text is not displayed, that area will be counted as "non legible" unless an explanation for the lack of ink is provided — an explanation is valid only if the Vesuvius Challenge Team acknowledges it as valid. * No overlap between training and prediction regions. Overlap leads to the memorization of annotated labels — ink model outputs should not overlap with any training data used. * In case multiple eligible submissions are concurrently evaluated, a ranking will be determined counting the number of legible lines in the submitted images, abiding by the legibility criteria defined before. * You may use any information or resource that is publicly available (published scholarship, other scrolls' data, segments, or models, third-party pretrained models, etc.), provided that use is permitted by that resource's own license or terms. Data derived from higher resolution scans of the submitted scroll volume cannot be used. Compute and data conditions * Unlimited time, compute, and manual effort may be spent creating generic ML datasets to train ML models. * Any dataset created or used to train ML models must be published publicly, under a CC-BY-NC 4.0 license. * If pseudo-labeling (or iterative labeling) is used to improve and train ink detection models, the datasets and checkpoints at every stage must be released under a CC-BY-NC 4.0 license. * If any part of training or inference is stochastic, random seeds must be fixed and reported, for both training and inference. * For any trained model, the full experiment-tracking run (e.g. Weights & Biases) must be shared publicly, for both training and inference. * The unrolling pipeline should be fully automated; up to 8 documented hours of human annotation / input are tolerated. Submitting your result If you have a qualifying result, submit it for consideration by sending an email to [grandprize@scrollprize.org](mailto:grandprize@scrollprize.org) and provide the following: * Meshes. The submission must contain a set of meshes in tifxyz format whose union corresponds to the totality of the scroll surface to be virtually unwrapped. Each tifxyz must already include a low-distortion isometric 2D parametrization (flattening). At most one mesh per full column of text (plus its margins) will be accepted; smaller meshes are not considered valid unless they localize regions where the papyrus is broken, or detached patches. Name each mesh with a sequential column number (e.g. `column_01.tifxyz`, `column_02.tifxyz`, ...) following the order of the windings, so every mesh is identifiable by its column. * Images. Submissions must include images of the virtually unwrapped papyrus, showing visible and legible text. * Submit a single static image for each column or sequence of consecutive wraps. Images must be generated programmatically from the reconstructed CT scan volume and the corresponding mesh submitted in the same package, and should not contain manual annotations of characters or text. * Specify which scroll each image came from. * Name each image after the tifxyz mesh (from the same package) used to generate it — carrying the same sequential column number — so every image is traceable to the exact surface it was rendered from. * Include scale bars showing the size of 1cm on each submission image. * Also include a single banner image spanning the full unrolled scroll, showing ink detection results across all columns, with each column's number overlaid on it — so the whole submission can be checked against the numbered meshes and images at a glance. * Methodology. A detailed technical description of how your solution works. We need to be able to reproduce your work, so please make this as easy as possible: * Please create a Docker image that we can easily run to reproduce your work, and please include system requirements. * Attach your code/video directly to the email, or include an easily accessible link from which we can download it. * False-positive mitigation. If there is any risk of your model producing spurious patterns — apparent letterforms that are not actually supported by the data — please let us know how you mitigated that risk. Tell us why you are confident that the results you are getting are real. * We strongly discourage submissions that use window sizes larger than 0.5x0.5 mm to generate images from machine learning models. If your submission uses larger window sizes, we may reject it and ask you to modify and resubmit. * Held-out validation. Run your method on the public input renders/volumes with known ground truth (using k-fold validation if you trained on them) and include the results. We may also run your method, following your instructions, on held-out data with known ground truth. * Other information. Feel free to include any other things we should know. If you're competing as a team, please have your team leader submit your results. We will communicate with the team leader exclusively, and any prize money will be distributed according to the instructions of the team leader. You'd have to sort out within your team how to split any prizes. Review process All submissions will be assessed by the Review Team, which consists of a Technical Team to review your methodology, and an independent Papyrology Team to review your results. 1. Technical assessment. The Technical Team will look at your method, and try to reproduce your results independently. We may also try to apply your techniques to other scrolls to see if they are able to generate new results there. * We will work with you on reproducing your solution. We might have questions, such as how your code works, how to use your manual tools (if applicable), and so on. Please make it as easy for us to run your code as reasonably possible, but also don't wait until your solution is perfect. If you have any questions, or if you're wondering if you're ready to submit, just reach out! * We will acknowledge having received your submission within a week. Depending on the difficulty of verifying your methodology, it might take longer until we are able to make our final assessment. * In case there are multiple teams that submit qualifying results, the team that submitted first will win (independent of how long our assessment takes). 2. Papyrological assessment. Once we are reasonably confident that your solution is technically valid and appears to meet the qualifications, we will share your results with the Papyrology Team, who will judge if the text is legitimate and meets the required legibility standards. Each submitted column is distributed to one or more papyrologists, who independently attribute a legibility score to it; a column counts toward the legibility thresholds above only once it is scored as legible. Additional terms * To qualify, you must have registered on the [Vesuvius Challenge Discord](https://discord.gg/V4fJhvtaQn) at the time of the submission. * Do not make your discovery public until winning the prize is officially announced. We will work with you to announce your findings. * If no team meets the criteria by the deadline, we reserve the right to award the prizes to the teams that came closest. This is not a guarantee — we will only award prizes if we believe the spirit of the prize has substantially been met and if a submission comes very close to the objective threshold. This is entirely at our discretion. * We will work with the winners to verify their results, put them in a historical context, and co-publish them in academic venues where applicable. * The general [Terms and Conditions](#terms-and-conditions) at the bottom of this page also apply. How to get started This is a big prize, and it breaks into two stages: first segmentation (unrolling the whole scroll into a flat surface), then ink detection on that surface. The two stages need quite different skills, so this is a great prize to tackle as a team — one person who enjoys unwrapping, one who enjoys ink detection. Stage 1 — segment the whole scroll. We'd tackle large-scale whole-scroll segmentation first. Our current state of the art for this is the spiral fitter, but you don't have to use it — we'd love for someone to build something better. * If you do use the spiral fitter, follow the [spiral fitting tutorial](/tutorial_spiral) to get started. * The spiral needs evidence and constraints to fit to: annotations of points that lie on the same winding versus different windings, fibers, the umbilicus, and so on. See [winding constraints](/open_problems/winding_annotations) for how these annotations work and how to create them. * Run the fit, then inspect the result in VC3D ([VC3D tutorial](/tutorial_VC3D)) to see how good the unrolling is, and iterate on the constraints. In particular, check if you can visually follow horizontal papyrus fibers across the page -- this is an indication the segmentation is good (and not jumping between sheets). Stage 2 — detect ink. Once you can unroll large areas, render them and try detecting ink on them. This is the same problem as the [First Letters prize](#first-letters-prizes) below — start there — except now you need it to work well across most of the scroll rather than a single 4 cm² patch. [Submission Form](https://forms.gle/wvNK7DkNKuRKjHJdA) *** ## First Letters Prizes [section: /prizes#first-letters-prizes] One of the frontiers of Vesuvius Challenge is finding techniques that work across multiple scrolls. While we’ve discovered text in some of our scrolls, others have not yet produced legible findings. These prizes bridge ink detection on fragments to the much harder problem of reading intact scrolls: we want to prove that ink detection works on scrolls where nothing has been read yet. The review bar is deliberately high — we’d rather be slow than wrong. First Letters: \$50,000 per scroll, for any of the [scroll volumes eligible for the 2027 Grand Prize](#2027-grand-prize). \$50,000 to the first team that uncovers 10 letters within a single 4 cm² area of that scroll — and open sources their methods and results (after winning the prize). First Letters prizes will be awarded for a maximum of 10 scrolls — up to \$500,000 in total. Deadline: June 25th, 2027 (11:59pm Pacific) Submission criteria and requirements * Meshes. The submission must contain the mesh(es), in tifxyz format, of the surface region containing the letters, already including a low-distortion isometric 2D parametrization (flattening). * Image. Submissions must be an image of the virtually unwrapped segment, showing at least 10 visible and legible letters within a single 4 cm² area. * Submit a single static image showing the text region. Images must be generated programmatically from the reconstructed CT scan volume and the mesh(es) submitted in the same package, and should not contain manual annotations of characters or text. This includes annotations that were then used as training data and memorized by a machine learning ink model. Ink model outputs of this region should not overlap with any training data used. * Specify which scroll the image comes from. For multiple scrolls, please make multiple submissions. * Include a scale bar showing the size of 1 cm on the submission image, and the pixel and millimeter dimensions of a few representative letters. * Name each image after the tifxyz mesh (from the same package) used to generate it, so it is traceable to the exact surface it was rendered from. * Annotate the rows of text. Usually, letters in read samples run overwhelmingly parallel to the horizontal papyrus fibers — where possible, overlay your ink predictions on a fiber-visible rendering. Annotate rows without obscuring the visible text — e.g. by drawing a horizontal baseline through each row or a rectangle around it, rather than overwriting the letters themselves. Misaligned text or text without clear rows does not immediately disqualify a submission, but it does make it less likely that you found valid text. * Methodology. A detailed technical description of how your solution works. We need to be able to reproduce your work, so please make this as easy as possible: * For fully automated software, consider a Docker image that we can easily run to reproduce your work, and please include system requirements. * For software with a human in the loop, please provide written instructions and a video explaining how to use your tool. We’ll work with you to learn how to use it, but we’d like to have a strong starting point. * Please include an easily accessible link from which we can download it. * False-positive mitigation. If there is any risk of your model producing spurious patterns — apparent letterforms that are not actually supported by the data — please let us know how you mitigated that risk. Tell us why you are confident that the results you are getting are real. * We strongly discourage submissions that use window sizes larger than 0.5x0.5 mm to generate images from machine learning models. If your submission uses larger window sizes, we may reject it and ask you to modify and resubmit. * Do not include overlap between training and prediction regions — this leads to the memorization of annotated labels. * Held-out validation. Run your method on the public input renders/volumes with known ground truth (using k-fold validation if you trained on them) and include the results. We may also run your method, following your instructions, on held-out data with known ground truth. * Other information. Feel free to include any other things we should know. * Your submission will be reviewed by the review teams to verify technical validity and papyrological plausibility and legibility. * As with the Grand Prize, you must not make your discovery public until the prize is officially announced. We will work with you to announce your findings. How to get started Here's one way in. This is a suggested path, not a requirement — anything that produces a qualifying image counts. 1. Pick a scroll from the [eligible list](#2027-grand-prize). 2. Open it in VC3D from the built-in open data catalog, and grow a segment on the scroll's recto surface prediction with `Create Segment (GrowPatch)`, refining it by hand where the automatic growth goes wrong. See the [VC3D unwrapping tutorial](/tutorial_VC3D) for opening the catalog and growing patches, and the [segmentation tutorial](/segmentation) for more on growing and manually refining meshes. 3. Render the flattened segment and run ink detection on it, following the [ink detection tutorial](/tutorial5). 4. Repeat on other regions (and other scrolls) until you find 10 legible letters within a single 4 cm² area. A few things worth knowing: * We don't yet know whether our existing ink models will work on these scrolls. They might, or they might not — it may be necessary to train a scroll-specific model. * Sometimes ink is visible directly in the flattened render, with no model at all (usually it shows up as bright areas). If that's already enough legible letters, that by itself qualifies for the prize. * If you can see a little ink but not enough, that's a foothold: train a model on it — or fine-tune one of our [latest ink detection models](https://huggingface.co/scrollprize) — and then use [iterative labeling](/tutorial5#improving-the-model-iterative-labeling) to grow from a few visible strokes to complete words. [Submission Form](https://forms.gle/TM5ao8GwC2mDrdLk9) *** ## PHerc. Paris 4’s Title Prize [section: /prizes#first-title-prize] Discovering a scroll’s title tells scholars what — and whom — they have been reading, and helps contextualize the entire work. We have already recovered the titles of [PHerc. 172](/data_browser/PHerc0172) and [PHerc. 139](/data_browser/PHerc0139) — but the title of Scroll 1, the scroll where the first passages were read, is still missing. PHerc. Paris 4’s Title: \$50,000 to the first team to discover the title of [PHerc. Paris 4](/data_browser/PHercParis4) (Scroll 1), using any of its scans — including the 2.4 µm volumes. Scroll 1 is one of our most-read scrolls: substantial continuous Greek text of an Epicurean prose work has been recovered, yet its author and title remain unknown. The expected title region has shown no detectable ink so far — possibly a different ink, and the top rows are physically missing — so finding it may take better methods, higher resolution, or looking somewhere new. Deadline: June 25th, 2027 (11:59pm Pacific) Submission criteria and requirements * Mesh. The submission must contain the mesh, in tifxyz format, of the surface region containing the title, already including a low-distortion isometric 2D parametrization (flattening). * Image. Submissions must be an image of the virtually unwrapped region, showing the title visibly and legibly. * Illustrate the ink predictions in the spatial context of the title search, similar to what is [shown here](https://scrollprize.substack.com/p/30k-first-title-prize). You do not have to read the title yourself — you have to produce an image of it that our team of papyrologists is able to read. * Images must be generated programmatically from the reconstructed CT scan volume and the mesh submitted in the same package, and should not contain manual annotations of characters or text. Ink model outputs of this region should not overlap with any training data used. * Specify which scan the image comes from — any of Scroll 1’s published volumes qualifies, including the 2.4 µm ones. * Include a scale bar showing the size of 1 cm on the submission image, and the pixel and millimeter dimensions of a few representative letters. * Name the image after the tifxyz mesh (from the same package) used to generate it, so it is traceable to the exact surface it was rendered from. * Methodology. A detailed technical description of how your solution works. We need to be able to reproduce your work, so please make this as easy as possible: * For fully automated software, consider a Docker image that we can easily run to reproduce your work, and please include system requirements. * For software with a human in the loop, please provide written instructions and a video explaining how to use your tool. We’ll work with you to learn how to use it, but we’d like to have a strong starting point. * Please include an easily accessible link from which we can download it. * False-positive mitigation. If there is any risk of your model producing spurious patterns — apparent letterforms that are not actually supported by the data — please let us know how you mitigated that risk. Tell us why you are confident that the results you are getting are real. * We strongly discourage submissions that use window sizes larger than 0.5x0.5 mm to generate images from machine learning models. If your submission uses larger window sizes, we may reject it and ask you to modify and resubmit. * Do not include overlap between training and prediction regions — this leads to the memorization of annotated labels. * Held-out validation. Run your method on the public input renders/volumes with known ground truth (using k-fold validation if you trained on them) and include the results. We may also run your method, following your instructions, on held-out data with known ground truth. * Other information. Feel free to include any other things we should know. * Your submission will be reviewed by the review teams to verify technical validity and papyrological plausibility and legibility. * Submissions remain open until the prize is won: if we discover months from now that your method was right all along, you will then win. * As with the Grand Prize, you must not make your discovery public until the prize is officially announced. We will work with you to announce your findings. [Submission Form](https://forms.gle/4zeVPPBtNdSCAQa88) *** Note: The prizes above feel too ambitious? There are plenty of other ways to contribute! ## Progress Prizes [section: /prizes#progress-prizes] In addition to milestone-based prizes, we offer monthly prizes for open source contributions that help read the scrolls. These prizes are more open-ended, and we have a wishlist to provide some ideas. If you are new to the project, this is a great place to start. Best Submission of the Month: \$20,000, guaranteed every month, to the single best submission — selected by the Vesuvius Challenge team. Beyond that, progress prizes will be awarded at a range of levels based on the significance of the contribution, typically \$20,000, \$10,000, \$5,000, \$2,500, \$1,000 or \$500. We favor submissions that: * Are released or open-sourced early. Tools released earlier have a higher chance of being used for reading the scrolls than those released the last day of the month. * Actually get used. We’ll look for signals from the community: questions, comments, bug reports, feature requests. Our Annotation Team will publicly provide comments on tools they use. * Improve results quantitatively and/or qualitatively on real data. If you are working on [ink detection](/data_datasets#ink-labels-2026-07) or [surface prediction](/data_datasets#surface-labels-2026-07) your method should be evaluated on our public datasets. If you are working on virtual unwrapping, show visually that papyrus fibers are visible on your output surface, and it doesn't jump across sheets in cross-section. * Resolve outstanding bugs in tools that people are using, and that you are using yourself, evidenced by before/after screenshots, logs, etc. * Reveal insightful, actionable information. If you are building analytic tools, show how they facilitated improvements to unwrapping or ink detection, for example by detecting failure-cases of existing methods on real scroll data, or producing information that resulted in better model results for the relevant task (see above). * Are well documented. It helps a lot if relevant documentation, walkthroughs, images, tutorials or similar are included with the work so that others can use it! Any contribution that makes any of the [Open Problems](/2026_open_problems) easier to address will be eligible for a Progress Prize. We maintain a [public wishlist](https://github.com/ScrollPrize/villa/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22help%20wanted%22) of ideas that would make excellent progress prize submissions. [Improvements to VC3D](https://github.com/ScrollPrize/villa/issues?q=is%3Aissue%20state%3Aopen%20label%3AVC3D) can be also considered for progress prizes! Some are additionally labeled as [good first issues](https://github.com/ScrollPrize/villa/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22good%20first%20issue%22) for newcomers! Submissions are evaluated monthly, and multiple submissions/awards per month are permitted. The next deadline is 11:59pm Pacific, August 31st, 2026! Submission criteria and requirements Core Requirements: 1. Problem Identification and Solution * Address a specific challenge using Vesuvius Challenge scroll data * Provide clear implementation path and a demonstration of its use * Demonstrate significant advantages over existing solutions 2. Documentation * Include comprehensive documentation * Provide usage examples 3. Technical Integration * Accept standard community formats (e.g. OME-Zarr or Zarr arrays, tifxyz quadmeshes, triangular meshes) * Maintain consistent output formats * Designed for modular integration [Submission Form](https://docs.google.com/forms/d/e/1FAIpQLSev2vJobu521iB6OuyehDktzYTEo131F4iUGwt3Qxa9a1fk6A/viewform) *** ## Terms and Conditions [section: /prizes#terms-and-conditions] Prizes are awarded at the sole discretion of Scroll Prize, Inc. and are subject to review by our Technical Team, Annotation Team, and Papyrological Team. We may issue more or fewer awards based on the spirit of the prize and the received submissions. You agree to make your method open source if you win a prize. It does not have to be open source at the time of submission, but you have to make it open source under a permissive license to accept the prize. Submissions for milestone prizes will close once the winner is announced and their methods are open sourced. Scroll Prize, Inc. reserves the right to modify prize terms at any time in order to more accurately reflect the spirit of the prize as designed. Prize winner must provide payment information to Scroll Prize, Inc. within 30 days of prize announcement to receive prize. ===== PAGE: Tutorial: Segmentation ===== URL: https://scrollprize.org/segmentation STATUS: archived Note (ARCHIVED): This page has been archived and is no longer maintained. It describes an earlier generation of the Vesuvius Challenge pipeline — tools, data layouts, and results referenced here may have been superseded. See [Open Problems](/2026_open_problems) for the current state of the pipeline and [Prizes](/prizes) for what is open today. *Last updated: February 20, 2025* Table of Contents ### Installation Instructions [section: /segmentation#installation-instructions] Due to a complex set of dependencies, it is *highly* recommended to use the docker image. We host an up-to-date image on the [github container registry](https://github.com/ScrollPrize/villa/pkgs/container/villa%2Fvolume-cartographer) which can be pulled with a simple command : ```bash docker pull ghcr.io/scrollprize/villa/volume-cartographer:edge ``` If you want to install vc3d from source, the easiest path is to look at the [Dockerfile](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/Dockerfile) (and the shared [install_build_deps.sh](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/scripts/install_build_deps.sh) it uses) and adapt for your environment. Building from source presently requires a *nix like environment for atomic rename support. If you are on Windows, either use the docker image or WSL. [installation instructions for docker](https://docs.docker.com/engine/install/) [running docker as a non-root user](https://docs.docker.com/engine/install/linux-postinstall/) Note: if you are using Ubuntu, the default open file limit is 1024. You may encounter errors when running VC3D. To fix this, run `ulimit -Sn 750000` (or some other high number) in the terminal you plan to launch VC3D/Docker from before doing so. ### Data formatting [section: /segmentation#data-formatting] VC3D requires a few changes to the data you may already have downloaded. All data must be in OME-Zarr format, of dtype uint8, and contain a meta.json file. To check if your zarr is in uint8 already, open a resolution group zarray file (located at /path/to.zarr/0/.zarray) look at the dtype field. "|u1" is uint8, and "|u2" is uint16. The meta.json contains the following information. The only real change from a standard VC meta.json is the inclusion of the `format:"zarr"` key. ```json {"height":3550,"max":65535.0,"min":0.0,"name":"PHerc0332, 7.91 - zarr - s3_raw","slices":9778,"type":"vol","uuid":"20231117143551-zarr-s3_raw","voxelsize":7.91,"width":3400, "format":"zarr"} ``` Your folder structure should resemble this: ``` . └── scroll1.volpkg/ ├── volumes/ │ ├── s1_uint8_ome.zarr -- this is your volume data/ │ │ └── meta.json - REQUIRED! │ └── 050_entire_scroll1_ome.zarr -- this is your surface prediction/ │ └── meta.json - REQUIRED! ├── paths ├── normal_grids - REQUIRED! └── config.json - REQUIRED! ``` There is only one additional requirement with the latest updates , which is the computation of a normal grid. These can be computed using the `vc_gen_normalgrids` tool , and should be placed at the root of your volpkg in a folder called `normal_grids`. Scroll 5 (PHerc172) has precomputed versions of direction fields and normal grids, available at the following links: - [normal_grids](https://dl.ash2txt.org/full-scrolls/Scroll5/PHerc172.volpkg/normal_grids/) - [fiber-directions](https://dl.ash2txt.org/full-scrolls/Scroll5/PHerc172.volpkg/representations/direction_fields/s5-fiber-directions.zarr/) - _the horizontal fiber field was only computed from z2000:z8000, the vertical covers the entire height_ - [structure-tensor-normal](https://dl.ash2txt.org/full-scrolls/Scroll5/PHerc172.volpkg/representations/direction_fields/s5-structure-tensor/) ### Launching VC3D [section: /segmentation#launching-vc3d] If you're using docker : ```bash xhost +local:docker sudo docker run -it --rm \ -v "/path/to/data/:/path/to/data/" \ -v /tmp/.X11-unix:/tmp/.X11-unix \ -e DISPLAY=$DISPLAY \ -e QT_QPA_PLATFORM=xcb \ -e QT_X11_NO_MITSHM=1 \ ghcr.io/scrollprize/villa/volume-cartographer:edge ``` From source : ```bash /path/to/build/bin/VC3D ``` ### Navigation [section: /segmentation#navigation] First , click `File -> Open volpkg` and select the volpkg you wish to work with (select the folder ending in `.volpkg`) On the left side of the UI, you have a few dock widgets. The first being the Volume Package / Surface List. The most important things to note here are the `Volume` dropdown list, which selects the currently displayed volume, and the `paths` surface list, which selects the currently displayed segment. Selecting a `Surface ID` should populate the `Surface` volume view in the top left, and initialize the rest the volume viewers. ### Widgets [section: /segmentation#widgets] Most actions in VC3D are grouped into similar sets of actions controlled by a widget. Volume Package - `Reload Surfaces` : checks for new segmentations in the currently selected directory (by default, this is `{volpkg}/paths` - `Filters` : Apply a single (or multiple) filters to show or hide specific surface ids from the current set - the most important one to remember here is `Current Segment Only` , which will hide the intersection overlays of all other segmentations in the volume viewers (this can greatly speed up ui interaction) - `Approved`, `Defective`, `Reviewed`, `Revisit`, `Inspect` : tags which can be applied to the surface meta.json , and filtered against - `Generate Surface Mask` and `Append Surface Mask` : Create a binary mask representing the valid surface, and optionally append the current selected volume to it as a multipage tif Location - `Focus` : Displays the current location of the focus point (in XYZ) -- also can be used to set the focus point by modifying the values in the text box - `Zoom` : Can be used in place of scroll wheel based zooming , mostly exists to alleviate touchy track pad zooming - `Overlay Volume` : Selects the volume to overlay onto the base volume - `Overlay opacity` : Modifies the opacity of the overlay volume - `Axis overlay opacity` : Modifies the opacity of the plane slice axis overlays - `Overlay threshold` : The value of the overlay array below which will not be rendered on the base volume (useful for removing background) - `Overlay colormap` : The colormap to use for the overlay volume - `Use axis aligned slices` : by default, vc3d attempts to align your XZ and YZ planes orthogonal to the normal of the current selected surface, this checkbox will instead use the plane normal as the axis to slice along - `Show axis overlays in XY view` : if you do not wish to view the axis overlays in the XY view, this checkbox will disable them _Keybinds:_ > - `Right mouse + drag` : pans the current viewer > - `Scroll wheel` : zooms the current viewer > - `Ctrl + left mouse button` : centers the focus point on the cursor position > - `Scroll wheel click + drag` : rotates the slicing pane in the XZ or XY volume viewers > - `Spacebar` : toggles the overlay on / off > - `C` : toggle a composite view of the current surface in the segmentation window (parameters of which can be located in the "composite" dock tab, next to the location tab) Segmentation - `Enable editing` : Must be checked to enable any of the actions in this widget. Creates a copy of the base surface upon which we perform any of the following actions - `Surface Growth` - grouping of settings mostly pertaining to the `Grow` action - `Steps` : The number of "generations" the growth action will undertake - `Allowed Directions` : Limits the directions of growth _relative to the flattened 2d quad surface!_ (i.e if you look in the segmentation window in the top left, and you set 'up' it will grow towards the top of the window) - `Limit Z range` : Constrains the growth to a selected `Z` range - `Volume` : the volume to pass to the `tracer()` call _should be a surface prediction volume!_ - `Editing` - grouping of settings which mostly apply to drag/push/pull actions for mesh deformation. All mesh deformation-type actions are performed on a gaussian-like area which has a circular shape centered at the current mouse location and whose strength is reduced as we reach the edges. _Radius is in quad vertices in the 2d flattened surface._ - `Max Radius` : the maximum radius of the area to be affected by the action - `Sigma` : the _strength_ of the push/pull on affected vertices other the original one (aka how quickly the influence tapers as we step away from the original point) - `Push Pull Step` : The number of "offset steps" to take along the surface normal (in voxels) for each push/pull action (this parameter only affects the push/pull in the segmentation window that is applied with `F` and `G`) - `Direction Fields` - `Zarr folder` : the path containing the direction field you want to use for optimization (ex: `/path/to/scroll.volpkg/fiber-directions.zarr/horizontal`) _these are optional_ - `Orientation` : the orientation/type of the direction field (from horizontal, vertical, or normal) - `Scale level` : the zarr resolution from which these were computed - `Weight` : the weight to apply to the field when optimizing. - `Corrections` : group which controls / manages the "correction points" for the current growth session - `New correction set` : creates a new point collection containing a single "correction" _Keybinds:_ > - `F` or `G` : push/pull the current surface in a positive or negative direction along the surface normal (only works in the surface > - `1`, `2`, `3`, `4`, `5` : select a direction to grow in -- left, up , down, right , all , respectively > - `T` : create a new correction set Seeding - `Switch to point mode` : toggles the seeding widget into draw mode (not recommended) - `Source Collection` : the source point collection to use as seed points (will autofill if you draw/analyze) - `Parallel processes` : the number of processes to run seeding with - `OMP Threads` : limits the amount of threads each process can use (recommend to set this to 1) - `Intensity threshold` : mostly unused, can leave default - `Peak detection window` : how closely each peak detected along a path/raycast can be - `Expansion iterations` : how many iterations to run expansion mode on after initial seeding - `Show Preview Points` : unused , can ignore - `Clear` (both) : clears current points , paths, or raycasts - `Analyze Paths` : after drawing paths, detect peaks along the line segment on which to place seed points - `Run seeding` : creates segmentations from the current seed points - `Expand seeds` : expands the current seed points to the given number of iterations - `Clear all paths` : clears any user drawn paths / points (use this over the clear buttons most of the time) - `Start label wraps` : this is used for absolute or relative wrap labels , is not used during the seeding step, will detail in another document ### Creating an initial segmentation [section: /segmentation#creating-an-initial-segmentation] For all growth or editing actions, you'll need an initial mesh to start from. This can be done either through the GUI or the CLI. *From the GUI* - Launch VC3D and open a .volpkg - Select the seeding widget (on the right side dock) - If not already selected, click `switch to draw mode` and draw a path _across_ a surface prediction (or multiple) - Click `analyze paths` , and you should see a seed point (or multiple) on the surface prediction - Ensure your seed.json exists in the .volpkg root - Click `run seeding` - Click `refresh surfaces` and you should see your segmentation in the surface list on the left side of the UI *From the terminal -- adjust for your own locations* ```bash /home/sean/Documents/villa/volume-cartographer/build/bin/vc_grow_seg_from_seed \ -v /mnt/raid_nvme/volpkgs/PHerc172.volpkg/volumes/s5_105.zarr \ -t /mnt/raid_nvme/volpkgs/PHerc172.volpkg/paths \ -p /mnt/raid_nvme/volpkgs/PHerc172.volpkg/seed.json \ -s 1674.9 3066.41 6915.49 ``` ### Growing an existing segmentation [section: /segmentation#growing-an-existing-segmentation] An existing segmentation can be semi-automatically grown utlizing the tracer optimization process by setting your direction in the widget and hitting `Grow`, keybinds exist for each growth direction or `all`, these are noted in the [widget section](#widgets) above, under `segmentation widget` ### Correcting errors in a segmentation [section: /segmentation#correcting-errors-in-a-segmentation] There are a few ways to fix errors which occurred during segmentation. All parameters controlling these actions are in the `segmentation` widget , and have tooltips which will appear on mouse hover. Note: Most actions can be undone with the keybind `ctrl+z` ### Erasing / invalidating portions of the mesh [section: /segmentation#erasing--invalidating-portions-of-the-mesh] If you encounter a region in which your mesh has become degenerate/warped or just horribly out of place, sometimes it can be easier to simply erase it and grow back into the region. This can be done while editing is active by pressing `Shift` and dragging the left mouse button. If you are happy with the drawn path, press `E` to erase the mesh along this path. ### Growing large meshes [section: /segmentation#growing-large-meshes] The typical growth process looks something like this : 1. Seed an initial point in the region you wish to segment 2. Grow this segmentation some small-ish number of generations at a time, somewhere between 10-30 is a reasonable number 3. Check for errors, and fix ones that appear 4. Repeat steps 1-3 until you feel like stopping ### Growing large meshes with the "tracer" method [section: /segmentation#growing-large-meshes-with-the-tracer-method] The above steps mostly detail how to grow and correct meshes in a semi-supervised manner. This is in contrast to the "tracer" method, which attempts to piece together large meshes in a more automatic manner, by connecting overlapping patches. The tracer method requires a "seeded" volume , containing thousands of overlapping segmentations with some metadata marking which ones overlap eachother. There are two steps to this method : 1. Fully seed the volume with patches 2. Run the tracer on these patches Seeding the volume You have two options for doing this , either through the CLI or through the GUI. This doc will cover the GUI. Open the segmentation widget, and draw paths along the intersections of the surface predictions to place seed points, and run seeding on those points. Place these manual seeds until you've covered a decent portion of the volume, such that if these patches were grown, they could reasonably cover the entire volume. Click 'expand seeds' to grow new seeds from these patches, which overlap with existing ones Let this expansion mode run until your volume is densely seeded. It should look like this : Running a trace To run a trace, simply right click an existing segmentation, and from the context menu select `Run trace` , you can keep the default settings for now, but they are available in the dialog box if you wish to experiment with them. You can monitor its growth by selecting the `traces` folder in your volume widget, by clicking on `paths` on the volume package widget and selecting `traces` The tracer will run for an indeterminate amount of time , until it runs out of area in which it can continue to grow. This could be 10cm^2 , or it could be 2800cm^2 -- it completely depends on the surface prediction and patch quality. This is a 53cm^2 segmentation from PHerc0172 which completed in about a minute. ### Editing traces [section: /segmentation#editing-traces] You can edit or continue growth on a trace with any of the methods detailed in [growing an existing segmentation](#growing-an-existing-segmentation) , and correct them with any of the methods in [correcting errors in a segmentation](#correcting-errors-in-a-segmentation) , do note that these traces will have to have been produced _after_ the recent VC3D changes, as prior ones did not include a `generations.tif`, which is necessary for that growth method. ===== PAGE: An entire Herculaneum scroll has been read for the first time ===== URL: https://scrollprize.org/firstscroll STATUS: current Note (HISTORICAL MILESTONE): This announcement is from June 25th, 2026. See [Prizes](/prizes) for what is open today. We read an entire scroll — without ever opening it PHerc. 1667, sealed since the eruption of Vesuvius in 79 AD, has been virtually unwrapped and read from beginning to end. June 25th, 2026 Read the preprint: [Complete virtual unwrapping and reading of a rolled Herculaneum papyrus (PDF)](/pdf/main.pdf) and on [arXiv](https://arxiv.org/abs/2606.29085). The data is openly available at [scrollprize.org/data](/data), and the code on [GitHub](https://github.com/ScrollPrize/villa). For almost 2,000 years, the carbonized library of Herculaneum has kept a cruel bargain: its scrolls survived the eruption of Mount Vesuvius, but only by becoming too fragile to open. To read one was to destroy it. Hundreds of rolls have therefore remained sealed, their contents preserved yet unreachable. Today that changes. We have completely virtually unwrapped and read PHerc. 1667 — the scroll the Vesuvius Challenge community knows as Scroll 4 — without ever touching its pages. It is the first Herculaneum papyrus to be digitally unrolled and read in full, end to end, and made available for sustained scholarly study. ## From a sealed lump to a readable book [section: /firstscroll#from-a-sealed-lump-to-a-readable-book] PHerc. 1667 began as a blackened, rolled mass of carbonized papyrus. To read it, we never unrolled it physically. Instead, we scanned it with high-resolution X-rays, reconstructed the wound sheet inside the volume, flattened it into a readable surface, and used machine learning to bring out the faint traces of ancient ink. ## Three sealed scrolls, three milestones [section: /firstscroll#three-sealed-scrolls-three-milestones] The work reaches beyond a single scroll. Alongside the complete reading of PHerc. 1667, the research establishes a method that holds up under independent checks and scales to other rolls. ### PHerc. 1667 — read in full [section: /firstscroll#pherc-1667--read-in-full] PHerc. 1667 is what survives of a larger roll: earlier attempts to open it by hand — in the nineteenth century, and again in 1969 and the 1980s — destroyed its outer layers and left only the compact inner core, about 8 cm of an original height of 19–24 cm. From that surviving portion we have now recovered and read the text in full — the lower parts of some twenty-two columns, transcribed and reviewed by papyrologists. It is the first time the preserved text of a rolled Herculaneum scroll has been read continuously, end to end, rather than in isolated words or patches. The recovered text is a philosophical treatise on ethics, and the evidence points to a Stoic work: it turns on human nature, impulse, and the moral progress of human beings, and its final preserved column names Aristocreon — nephew and disciple of the great Stoic Chrysippus — which, together with the language and themes of the text, places it in a Stoic context and dates it to the 2nd century BC. Because the papyrus is damaged, the readings are fragmentary, with gaps where the surface is lost. Even so, several passages can be read clearly for the first time in two thousand years: “…we will inquire into something, but we will not grasp it, if in some way we depart from ourselves and from our own nature…” “Having…strained ourselves to the utmost through research and learning…possessing the same practical wisdom…” “…such being the goods for us, even from the opposite evils there will be neither anything good — let alone beautiful — nor anything bad — let alone ugly — nor happiness…” Translated from the Greek; the full column-by-column transcription is in the [preprint](/pdf/main.pdf). ### PHerc. Paris 4 — ink made visible by higher resolution [section: /firstscroll#pherc-paris-4--ink-made-visible-by-higher-resolution] In a second scroll — PHerc. Paris 4, the scroll the Vesuvius Challenge community knows as Scroll 1 — a higher-resolution imaging technique makes the ink directly visible inside the scroll itself, in the three-dimensional X-ray data, for the first time. Segmented in 3D and projected back onto the unwrapped page, that ink matches the text read in the 2023 Grand Prize one-to-one — an independent confirmation, from better data, that the reading is real. ### PHerc. 139 — a title, and an author [section: /firstscroll#pherc-139--a-title-and-an-author] In a third scroll, PHerc. 139, we recover the scroll's title and author attribution: the work is identified as Philodemus, _On Gods_, Book 8 — a treatise by the Epicurean philosopher whose works fill so much of this library. Reading the title of a closed scroll tells scholars what a roll contains before a single column of its body is studied. ## How it was done [section: /firstscroll#how-it-was-done] The scans were acquired with high-resolution phase-contrast X-ray microtomography on the BM18 beamline at the [European Synchrotron Radiation Facility (ESRF)](https://www.esrf.fr/) in Grenoble — an instrument able to resolve the wafer-thin, densely packed layers of a Herculaneum roll. The work was carried out in collaboration with the National Library of Naples “Vittorio Emanuele III”, which safeguards the Herculaneum papyri. From those volumes, the team reconstructed the scroll's geometry, traced and flattened its surface into a readable sheet, and trained machine-learning models to detect ink that is almost indistinguishable from the carbonized papyrus beneath it. Each reading was then examined and transcribed by papyrologists. Crucially, all of this is open. The tomographic data, reconstructed surfaces and transcriptions are released under a Creative Commons licence at [scrollprize.org/data](/data) and archived at the ESRF, and the code is on [GitHub](https://github.com/ScrollPrize/villa). Anyone can check the work, build on it, and apply it to the scrolls that remain. ## A victory for open, global science [section: /firstscroll#a-victory-for-open-global-science] This is what open science makes possible. The virtual unwrapping of the Herculaneum scrolls was pioneered at EduceLab by its principal investigator, Professor Brent Seales. In 2023 Seales opened his lab's imaging and software technology to the Vesuvius Challenge — a public, donation-funded effort he co-founded with Nat Friedman and Daniel Gross to read the scrolls in the open — and from there a global community took up the problem. The [first letters](/firstletters) and the [2023 Grand Prize](/grandprize) were won by contestants from across the world. What is less widely known is what happened next. Most of the Vesuvius Challenge research team first arrived as contestants. They entered the open competition, won prizes for the breakthroughs they made, and were then recruited onto the team that has now read an entire scroll. The people behind this breakthrough are, in large part, the global community the Challenge itself created. ## What's next [section: /firstscroll#whats-next] PHerc. 1667 is one scroll. Hundreds more remain sealed — an entire library of philosophy, poetry and prose waiting to be read for the first time since antiquity. The method shown here is built to scale, and everything needed to apply it is open. If you want to help read the rest of the library: - Read the science: the [preprint (PDF)](/pdf/main.pdf), also on [arXiv](https://arxiv.org/abs/2606.29085). - Get the data and code: [scrollprize.org/data](/data) and [GitHub](https://github.com/ScrollPrize/villa). - Join the effort: [get started](/get_started) and become part of the community reading the scrolls. The thoughts of the ancient world, sealed in darkness for two millennia, are coming back into the light — a whole scroll at a time. ===== PAGE: Open Problems: Why Reading Every Herculaneum Scroll Is Still a Challenge ===== URL: https://scrollprize.org/2026_open_problems STATUS: current *Last updated: July 10, 2026* In 2026, PHerc. 1667was virtually unwrapped and read without physically opening the scroll (see [References](#references-and-implementation-links)). We are no longer asking whether a sealed Herculaneum scroll can be read. It can. The harder question is how to make the same process work automatically, reliably, and at scale for every scroll. ### 🙋 How you can help [section: /2026_open_problems#-how-you-can-help] This post doubles as a technical map of the whole pipeline and an onboarding document for anyone who wants to work on it. There are six concrete ways to contribute introduced as we go — look for the 🙋 callouts in Sections [2](#2-unwrapping-turning-disconnected-voxels-into-a-surface)-[4](#4-data-scale-the-infrastructure-bottleneck)\! Write on [Discord](https://discord.com/invite/V4fJhvtaQn) for more information\! ### 📊 Where is the data [section: /2026_open_problems#-where-is-the-data] - Data Browser — [https://scrollprize.org/data\_browser](https://scrollprize.org/data_browser): each scroll links to a page containing the available scanned CT volumes and the virtually unwrapped papyrus “segments” produced by the Vesuvius Challenge team, together with useful representations (to be defined later in this blog post) and ink detection predictions. - Direct access (S3 bucket) — [https://vesuvius-challenge-open-data.s3.us-east-1.amazonaws.com/index.html](https://vesuvius-challenge-open-data.s3.us-east-1.amazonaws.com/index.html) - Curated datasets (ink and spiral) — hosted on Hugging Face: [https://huggingface.co/buckets/scrollprize/datasets](https://huggingface.co/buckets/scrollprize/datasets) - Model checkpoints — hosted on Hugging Face: [https://huggingface.co/scrollprize](https://huggingface.co/scrollprize) ### 🧑‍💻 Where is the code [section: /2026_open_problems#-where-is-the-code] Most of the code is publicly available in the GitHub [ScrollPrize](https://github.com/ScrollPrize) account, especially in the [villa](https://github.com/ScrollPrize/villa) monorepository. ### 🎓 Related tutorials [section: /2026_open_problems#-related-tutorials] Hands-on guides for every stage of the pipeline described in this post: Tutorials Up to date: - [Volume Cartographer 3D (VC3D)](/tutorial_VC3D) — installing the software, loading scroll data, navigating volumes, and annotating fibers and windings (early draft) - [Spiral Fitting](/tutorial_spiral) — fitting the global spiral prior to a scroll - [Ink Detection](/tutorial5) — training and running ink-detection models Archived (describe earlier tooling and data layouts): - [Scanning](/tutorial1) · [Representation](/tutorial2) · [Segmentation](/segmentation) · [Segmentation and Flattening](/tutorial3) ## The pipeline [section: /2026_open_problems#the-pipeline] Reading a scroll is a chain of complex problems: 1. Scanning: producing a 3D X-ray volume that preserves the relevant physical signal. 2. Unrolling: inferring the hidden papyrus sheets from that 3D volume and flattening them. 3. Ink recovery: detecting or segmenting the ink signal on, or near, the recovered writing surface. The most important thing to understand is what we actually get after scanning. We do not get sheets. We do not get a mesh, a graph, or a map of which layer connects to which. We get a 3D grid of voxels. A voxel is the 3D version of a pixel: a tiny cube with an intensity value. The scan gives us billions or trillions of these cubes. What it does not contain is information about mappings to different physical objects in the scroll, or any information about what each voxel represents. To reconstruct a scroll, the first step then is to find efficient and descriptive “representations” of this scan volume which capture the important properties — such as where individual papyrus sheets are — that allow us to unwrap it and read it. That is why the pipeline is difficult. We are reconstructing geometry and extracting text from a damaged carbonized object whose internal structure and connectivity is not given to us. *** ## 1\. Scanning: capturing the signal [section: /2026_open_problems#1-scanning-capturing-the-signal] The scrolls are scanned using synchrotron X-ray micro-computed tomography, or X-ray micro-CT. The primary difference between a medical CT and the type used to image the scrolls is that we require a significantly higher resolution. To achieve this, we must use a very high power source. The source we use is known as a synchrotron – a type of particle accelerator – which takes electrons and fires them at very high speeds, generating a beam of X-rays, which is shot through the scroll. As the beam moves through the scroll it is differently affected by the materials composing it, which have different densities and properties. Some materials absorb the beam more, some less, and these differences are measured at the detector. This is known as attenuation contrast, and can reveal fine details when materials differ in absorbency (e.g. papyrus vs air). The eruption of Vesuvius carbonized these scrolls — papyrus and ink alike. Unfortunately for us, carbon ink on carbonized papyrus (both rich in the same element, carbon) provides very little of attenuation contrast, so ink is often not simply "bright" or "dark" in the raw scan. There is, however, still a signal to be found. Ink may affect the scan in more subtle ways. Texture, morphology, and phase shifts (derived from the refractive index). Frequently, in some combination of all of them. Teasing out these subtle differences is difficult, and is the primary reason we scan at such high resolutions, and why we continue to invest research time into ensuring our scans are as good as we can reasonably achieve. A micro-CT cross-section of a carbonized Herculaneum scroll: hundreds of tightly wound, deformed papyrus windings packed into a few centimeters (scale bar: 5 cm). The subtle differences that distinguish ink from papyrus must be teased out of data like this. ### The compressed-region problem [section: /2026_open_problems#the-compressed-region-problem] For as long as we’ve been working on these scans, it’s been apparent that some regions of a scroll look worse than the resolution used to scan them would suggest. These crops come out blurred, foggy, "compressed" — papyrus layers that should be cleanly separable become hard to tell apart. When panning through layers, the sheets could almost be seen “behind” this fog. Recent scanning experiments conducted at very high resolutions (0.55 µm detector pixel size) have finally given us an answer to the question of why these areas exist. The explanation starts at the fiber level. Carbonized papyrus fibers contain small internal cavities and tubular structures, and when many of them pack together densely, these microscopic structures disturb the X-ray beam enough to deviate it a little bit. This effect results into a local haze-like degradation in the scan. The likely culprit is the carbon itself: carbonized fibers are probably close to graphite, and graphite is a strong decoherer — a material that scrambles the X-ray wavefront rather than passing it through cleanly. The effect is worst in the most densely packed regions, where many fibers contribute to the haze at once. Cross-section of PHerc. 500P2 at 0.55 µm pixel size (ESRF beamline ID11). Each fiber is surrounded by a cell wall enclosing a hollow lumen cavity — the same structures implicated in the compressed-region scattering effect described above. A visual analogy for the compressed-region problem: the same view of Naples and Mount Vesuvius on a clear day and shrouded in haze. In compressed regions of a scan, papyrus sheets can almost be seen “behind” this kind of fog. The same compressed region of PHerc. Paris 4, imaged with two protocols. With a suboptimal protocol, layer boundaries blur into haze and adjacent sheets become hard to tell apart; with a more optimized protocol, individual windings become far easier to separate. DLS, 7.91 µm / ESRF, 2.4 µm The difficulty of unwrapping scrolls begins here. Blur the boundaries in the scan, and every downstream step gets harder: surface localization (finding the writing surface within the volume) turns noisier, mesh tracing turns less stable, and ink recovery may miss information it needs. The main point is that scan quality is local. A scan can hold excellent regions and nearly-impossible-to-unwrap ones in the very same volume. ### Three coupled scan parameters [section: /2026_open_problems#three-coupled-scan-parameters] Scanning is controlled by several parameters, but three are especially important: | Parameter | Meaning | Why it matters | | :---- | :---- | :---- | | Voxel size | The physical size represented by each voxel in the reconstructed 3D volume. | Smaller voxels can preserve finer structures, but increase scan time, reconstruction hardships, and data size. | | X-ray energy | The energy of the X-rays used for imaging. | Energy affects penetration, contrast, phase behavior. | | Sample–detector distance | The distance between the scroll and the detector after X-rays pass through the object. | This controls how phase shifts develop fringes before detection. | To understand why the third parameter matters, we must explain phase contrast. X-rays behave like waves. Passing through a material doesn't just absorb them; it also shifts their phase. Different shifts can be induced by different refractive indices of materials in the sample. As the wave-front travels away from the sample and towards the detector, it interferes with itself, generating interference fringes at the detector corresponding to the position where the accumulation of shift in phase started or ended: interface boundaries. The fringes act as a natural “edge enhancement”, and this effect is known as phase contrast. In objects with very little attenuation contrast – like our scrolls – this can be especially useful. A computational step called phase retrieval can turn those phase contrast fringes into a higher-contrast reconstruction; the [Paganin algorithm](https://pubmed.ncbi.nlm.nih.gov/12000561/) is one commonly used method for it. But more phase contrast isn't always better. Push sample-to-detector propagation distance (a knob that usually is tuned to optimize phase contrast) too far and the same effect can turn against you, blurring the volume and reducing clarity rather than contributing to it. The scanning problem is a balance: * enough phase contribution to reveal useful structure; * not so much that the scan becomes dominated by haze or decohesion; * enough X-ray energy to penetrate the object and separate layers; * not so much that useful absorption contrast disappears; * and voxels small enough to resolve the structures that matter, without shrinking so far that scanning a full scroll stops being practical. For recent full-scroll scans (ESRF/BM18), a practical regime has been around 2.4 µm isotropic voxels, 22 cm propagation distance, and about 78 keV average incident energy. This isn't a universal recipe. Scrolls which are very large or very small may benefit from some tweaks, but we’ve found that this recipe works well in the samples we have scanned to date. We scanned many samples with a lower resolution configuration which seemed to be "optimal" (but not as good as the first): around 9 µm isotropic voxels, 1.2 m propagation distance, and about 110 keV average incident energy. ### Why resolution helps, but does not solve everything [section: /2026_open_problems#why-resolution-helps-but-does-not-solve-everything] The most reliable direction so far has been to reduce voxel size. Smaller voxels help in several ways: * they preserve finer papyrus structure; * they are less affected by the beam decohesion (haze); * they reduce ambiguity between adjacent layers; * they may preserve more of the ink-related morphology; * they induce cleaner absorption and phase contrast. Given these benefits, it seems fair to ask “why not just scan everything at the highest possible resolution?” The curse of dimensionality is why. Perhaps counterintuitively (for those not familiar with 3D volumes) if voxel size is halved in each dimension, you might think the number of voxels is simply doubled, but in actuality it is eight times the voxel count for the same physical volume\! As an example, moving from 8 µm to 2 µm is not a 4× data increase; it is roughly a 64× increase. Moving toward 1 µm for a whole scroll becomes a data, scan-time, motion, and beamline problem. Small regions can be scanned at higher resolution. Full scrolls cannot yet be scanned everywhere at sub-micron resolution in a practical production workflow. Current failures have to be read carefully. Ink not recovered from a scroll doesn't necessarily mean the signal isn't there. It may be absent, or it may be present but not yet exploitable by the current surface placement, labels, model architecture, or training data. Right now we do not always know which part of the pipeline is limiting us and the limiting factor is to be assessed on a scroll-by-scroll basis. Note (Open problem): Some regions leave the scanner already degraded: densely compressed papyrus scatters the beam into haze that no downstream algorithm may fully undo — and scanning whole scrolls at sub-micron resolution is not yet practical. When ink fails to appear, we do not always know which part of the pipeline is limiting us; the limiting factor has to be assessed scroll by scroll. *** ## 2\. Unwrapping: turning disconnected voxels into a surface [section: /2026_open_problems#2-unwrapping-turning-disconnected-voxels-into-a-surface] After scanning, we have voxels, packed together into a *volume* – a large 3D cuboid. The volume is a sort of 3D photo: it does not tell us which voxels belong to the same sheet. It does not tell us where one wrap — one full revolution of the papyrus around the roll — ends and another begins. It does not provide a graph of connectivity. And it does not tell us whether two distant points are part of the same papyrus layer. (This post uses "wrap," "winding," "sheet," and "layer" more or less interchangeably for the same idea: one continuous turn of the papyrus as it spirals from the outside of the roll toward the center.) So the first step in unwrapping a scroll is surface localization – finding the writing surface inside a 3D voxel volume. ### Surface prediction [section: /2026_open_problems#surface-prediction] A common starting point for surface localization is semantic segmentation: assigning a class label to every voxel — either it’s the recto surface of the papyrus, or the “background”. However, a model trained this way doesn't hand back a finished scroll surface. It outputs a dense 3D prediction that later steps can use as geometric cues. In papyrus terminology, two sides of a sheet are often distinguished. The recto is the written surface, its fibers running horizontally, and it's always rolled facing inward, toward the center of the scroll. The verso is the back of the papyrus, where the fibers run vertically instead. The architecture usually chosen for this job is a [3D U-Net](https://arxiv.org/abs/1606.06650). The model learns local and contextual patterns in the CT data and produces a voxelwise surface probability. Two checkpoints built on this idea anchor the current pipeline: [surface\_recto\_3dunet](https://huggingface.co/scrollprize/surface_recto_3dunet), a checkpoint for the recto-surface predictor (recto — the papyrus's written surface, defined below) used in the pipeline behind the project's technical paper (see [References](#references-and-implementation-links)); and [surface\_m7\_nnunet](https://huggingface.co/scrollprize/surface_m7_nnunet), the nnU-Net ("m7") component — nnU-Net is defined just below — of the [1st-place solution](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/writeups/1st-place-solution-for-the-vesuvius-challenge-su) to the Kaggle competition described below. Surface prediction was the subject of a dedicated Kaggle competition, "Vesuvius Challenge – Surface Detection," with a \$200,000 prize pool in November 2025\. The competition's scoring metric was deliberately topology-aware rather than voxel-accuracy-based: it rewarded connected, gap-free predictions and penalized exactly the failure modes described later in this section — holes, mergers, and sheet switches — rather than treating them as small per-voxel errors. The winning approaches converged on [nnU-Net](https://doi.org/10.1038/s41592-020-01008-z), a self-configuring 3D U-Net framework that automatically adapts its own architecture and training pipeline to a given dataset's geometry and voxel spacing, instead of requiring a human to hand-tune it. Here's the winning recipe condensed to a single sentence: take an off-the-shelf nnU-Net model configured for a couple of patch sizes, train it for a very long time (*well over the default 1,000 epochs)*, and average their predictions together (a process known as ensembling). A recto-surface prediction (red) overlaid on a CT cross-section: the binarized model output marks the written side of each papyrus wrap — the mask that downstream mesh tracing consumes (scale bar: 0.5 cm). Note (How you can help): Create datasets with labels better localized on the papyrus’ recto or train ML models that can better preserve the sheets’ topology in the predictions. The open question is reaching a high level of topologic accuracy in densely packed regions, regions affected by high curvature or in spots where the papyrus is damaged. Different representations are also worth investigating, like using a Distance Transform rather than a Binary Segmentation (e.g. [https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/writeups/5th-place-solution](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/writeups/5th-place-solution)) Surface predictions are useful, but they are not usable as the final geometry for unwrapping. Dense predictions often contain holes, local deviations, false positives, or accidental mergers between nearby layers. In a normal image/volume segmentation task, a small local error may be tolerable. Here, a small local error can send a traced mesh onto the wrong wrap entirely, with no easy way to recover. Finally, to virtually unwrap the localized surface, we need to represent it explicitly as a mesh. ### Meshes: adding connectivity [section: /2026_open_problems#meshes-adding-connectivity] The purpose of the meshing step is to determine the geometrical connectivity of the scroll. It supplies the necessary information we cannot recover from the voxel grid alone: the ability to say "this point is next to that point, on the same surface." The current workflow uses surface predictions as guidance, then builds or refines explicit meshes that can be inspected and corrected. Imagine trying to follow a trail which is not well defined. It’s difficult to see where it continues in the forward direction. It has many areas in which you’re not sure whether it continues left, right, or some other direction. This is the type of path given by surface predictions. The mesh is then a map of the path you’ve chosen to take, whether right or wrong. If the map is wrong in one place, you’ll end up off-course, and it may be difficult to find the correct path to recover. The areas we most often see this type of problem are: * mergers, where two nearby sheets are joined by mistake; * holes, where the predicted surface disappears; * sheet switches, where a traced mesh jumps from the intended sheet to a neighboring wrap; * compressed regions, where the image itself gives weak or ambiguous evidence; * damaged regions, where the physical papyrus is torn, folded, or missing. These errors determine whether a flattened rendering shows a coherent writing surface or a corrupted one. The community has since built automatic tools that specifically target this failure list: Note (How you can help): If you know geometry processing, optimization algorithms, or C++, this is one of the highest-leverage places to contribute. Many errors in the surface predictions can be fixed during or mitigated during the meshing step with either subsequent optimization or post-processing algorithms. Community contributions building alternative, scalable meshing algorithms that attack the current failure modes are encouraged (e.g. [github.com/Hob3rMallow/scrollfiesta\_public](https://github.com/Hob3rMallow/scrollfiesta_public)) ### Surface mesh representations [section: /2026_open_problems#surface-mesh-representations] The unwrapping software used by our team, [VC3D](https://github.com/ScrollPrize/villa/tree/main/volume-cartographer), uses a custom format called 'tifxyz,' an alternative to widely-used 3D formats such as .obj or .stl. Its key benefit is that it enforces grid topology on the surface mesh — meaning, again, a single flat sheet. The flat coordinate system on the surface is carried explicitly exploiting a 2D grid structure. Indeed, the surface mesh (QuadSurface in the C++ code; Tifxyz in Python, via vesuvius.tifxyz.Tifxyz/read\_tifxyz()) is represented by a 2D array of 3D vertex coordinates: the array's shape determines the mesh's grid structure, and the vertices define its actual shape in space. That grid of coordinates is saved as three separate TIFF images, one each for x, y, and z coordinates (as float32). The format can also mark a given cell as missing, either by setting each coordinate to \-1 or via an optional sidecar mask image. Converter scripts move between tifxyz and .obj in both directions ([vc\_tifxyz2obj](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/apps/src/vc_tifxyz2obj.cpp), [vc\_obj2tifxyz](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/apps/src/vc_obj2tifxyz.cpp)); going from .obj to tifxyz requires an accompanying .griduv sidecar file specifying the intended grid structure (a [legacy converter](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/apps/src/vc_obj2tifxyz_legacy.cpp) without this requirement also exists, but is not recommended for new work). The core representation itself lives in [QuadSurface.cpp](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/core/src/QuadSurface.cpp). ### Visualizing a mesh [section: /2026_open_problems#visualizing-a-mesh] [VC3D](https://github.com/ScrollPrize/villa/tree/main/volume-cartographer) makes it possible to visualize the CT scans, meshes, and annotations all in one tool. The CT data for the large scrolls, which can reach dozens of terabytes, is streamed remotely and synchronized from the S3 Open Data bucket, generously provided to the project by AWS. A hands-on [VC3D tutorial](/tutorial_VC3D) walks through installing the software, loading scroll data, and annotating fibers and windings. VC3D - At start, the Catalog of data available in S3 Open Data Bucket opens up. VC3D - The Volume Package panel to list available patches/segments. ### Normal grids, GrowPatch, and local tracing [section: /2026_open_problems#normal-grids-growpatch-and-local-tracing] We have several different tools that all attack the same underlying task — turning a surface prediction into a trustworthy mesh — with different tradeoffs between speed, automation, and reliability. To trace a surface [VC3D](https://github.com/ScrollPrize/villa/tree/main/volume-cartographer) produces meshes (internally can be called also 'patches') based on a recto surface prediction volume, i.e. a volume produced by a surface segmentation model that is '1' everywhere that's on the papyrus surface. VC3D - Opening up the Segmentation panel to Grow the patch / segment. VC3D needs local orientation information to trace surfaces well. A normal is simply a vector perpendicular to a surface — for a papyrus sheet, that means it points straight "out of" the sheet. Stack a coarse 3D field of these local orientations together and you get a normal grid, which helps guide mesh growth. A dedicated tool, [vc\_gen\_normalgrids](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/apps/src/vc_gen_normalgrids.cpp), generates, converts, and builds resolution pyramids of these normal grids from the CT volume. The workflow can then use routines such as GrowPatch. A GrowPatch-style routine starts from a seed point or an existing patch and extends a local mesh along the predicted surface. Recall the trail discussed in the [previous section](#meshes-adding-connectivity). GrowPatch attempts to follow this trail, iteratively. Mathematically, this means optimizing concurrently for a combination of objectives: to follow the predicted papyrus surface, keep the local geometry smooth, hold mesh spacing to something reasonable, follow whatever local orientation evidence is available, and resist the pull of a nearby sheet it could easily jump onto instead. A 4-panel VC3D screenshot (Surface auto_grown_20250602213649661) showing freehand-drawn correction curves (purple, yellow, green, red) manually added on top of an already auto-grown surface, across the main view and three synchronized slice views. Shown here: the manual-correction stage only. This works well when the prediction is clean and the layers are separable. But it fails when the prediction topology does not match the real papyrus topology (e.g. because some predicted sheets incorrectly merge in the surface prediction volume). In practice, automatic growth still needs human inspection and correction. The current system is therefore best described as semi-automated. ### Copy Out/In: exploiting neighboring wraps [section: /2026_open_problems#copy-outin-exploiting-neighboring-wraps] Once one wrap has been traced well, nearby wraps further in or out may have similar local curvature. The Copy Out/In workflow exploits that fact. It uses an existing mesh as a geometric reference and tries to transfer or offset the tracing to a neighboring layer, implemented in [vc\_grow\_seg\_from\_seed.cpp](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/apps/src/vc_grow_seg_from_seed.cpp) and [GrowPatch.cpp](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/core/src/GrowPatch.cpp). This is powerful because adjacent wraps often resemble each other. But it is also risky: if the source mesh contains a local error, that error can propagate. So Copy Out/In is useful as an acceleration tool, not as an unchecked replacement for validation. A "neural" learnt version of the copy out/in also exists, implemented in [infer\_rowcol\_triplet\_wraps.py](https://github.com/ScrollPrize/villa/blob/main/vesuvius/src/vesuvius/neural_tracing/inference/infer_rowcol_triplet_wraps.py) and released as the [copy\_displacement\_latest](https://huggingface.co/scrollprize/copy_displacement_latest) checkpoint on Hugging Face (trained on 2.4 µm data downscaled once → 4.8 µm). This method is exposed in the VC3D interface through a dedicated Neural Tracer panel. A baseline checkpoint, [ps256\_copy\_baseline](https://huggingface.co/scrollprize/ps256_copy_baseline), is also available for comparison against the actively used copy\_displacement\_latest, and the panel itself is implemented in [SegmentationNeuralTracerPanel.cpp](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/apps/VC3D/segmentation/panels/SegmentationNeuralTracerPanel.cpp). ### Lasagna: smoother optimization of one or more sheets [section: /2026_open_problems#lasagna-smoother-optimization-of-one-or-more-sheets] The lasagna is an alternative to GrowPatch and copy out/in. It provides a more flexible optimization framework for solving the same problem of creating surface meshes semi-automatically. It can better fit complex, curved regions of the scroll, at the expense of being somewhat more computationally intensive. The lasagna can (optionally) optimize several stacked sheets at the same time, so they are all consistent with each other; as such it can be used similarly to GrowPatch followed by copy out/in. Other modes include making local corrections so a 'draft' surface is moved closer to the true surface while keeping certain points fixed. In all cases, surfaces (represented as a stack of non-intersecting quad-meshes — quad-faced grids of vertices, more on why below) are iteratively adjusted to agree with prediction volumes as closely as possible, and also with user-provided 'correction points' that define locations known to be on the papyrus surface. VC3D workspace showing semi-global optimization of multiple adjacent mesh layers linked together (the lasagna's multi-sheet joint optimization), across four synchronized views, with “true”/“false” annotations marking a correction in progress. The lasagna needs richer prediction volumes than a plain recto surface prediction can offer: a dense normal volume predicted by a U-Net, and a surface density (called 'gradient magnitude') volume that represents how closely spaced the papyrus windings are. The second one works like this: a second U-Net predicts a fractional winding position field for every voxel — essentially "how much further out in the scroll do we get, moving from one side of this voxel to the other point, expressed as a fraction of one full winding." That field is built from distance transforms to sheet skeletons, then normalized into a monotone field via iterative weighted averaging. Gradient magnitude tells how fast winding position changes as you move through space. Integrate this along a short strip between two points and you get the number of windings crossed to go from one to the other — which is why it doubles as a proxy for winding spacing. High gradient magnitude means sheets are packed tightly together locally; low means they're far apart. Technically, the lasagna can do a global optimization of the entire local surface (or surfaces), implemented using PyTorch. GrowPatch, by contrast, uses [Ceres](http://ceres-solver.org) — a classical nonlinear least-squares solver of the kind widely used in robotics and computer vision — inside an iterative growth loop that adds quads progressively and repeatedly re-optimizes an outer fringe. The predicted volumes (normals, etc.) that are used as input to the main lasagna surface optimization can also be used to trace fibers, i.e. to semi-automatically follow the lines of papyrus fibers through the 3D volume, given sparse human-specified keypoints. The full lasagna codebase lives at [github.com/ScrollPrize/villa/tree/main/lasagna](https://github.com/ScrollPrize/villa/tree/main/lasagna). ### 2D Parameterization and Flattening [section: /2026_open_problems#2d-parameterization-and-flattening] Flattening takes each point on the 3D mesh and assigns it a 2D coordinate. The same trick as making a flat map from a curved globe, but in our case we are aiming to preserve local distances as much as possible: we are looking for a transformation from 3D \-\> 2D which is isometric. VC3D preview of 3D ink recovery on a segment before and after flattening. Flattening aims for a low-distortion parametrization. VC3D's current production flattening tool is [flatboi](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/libs/flatboi/flatboi.cpp), which uses [SLIM](https://igl.ethz.ch/projects/slim/) (Scalable Locally Injective Mappings), minimizing the Symmetric Dirichlet Energy (which is small the lower the isometric distortion induced by the map). ### Fibers as connectivity clues [section: /2026_open_problems#fibers-as-connectivity-clues] Papyrus is made of fibers. These fibers carry geometric information. If you recall from the flattening step, to get a mapping from 3D space to 2D space, we can map our 3D points in rows and columns in the correct order (preserving distances) – in the parameterized space these rows and columns “axes” are usually called U and V. Conveniently, a papyrus sheet has these axis “physically” defined\! Within each sheet are vascular bundles oriented vertically or horizontally and each one – if perfectly segmented – could be used directly as an individual row or column. Amazing\! The papyrus sheet itself is providing a direct way to parametrize its surface\! If we can manage to trace the fibers, we can directly obtain oriented axes in the papyrus. This information can not only help us to flatten the segmented sheets, but also to segment the surface itself\! Unfortunately, if you recall the Scanning section, beam decohesion on fibers is also what makes the volume blurrier. So fibers can be both a blessing and a curse. A 3D rendering of individually segmented papyrus fibers, each color a separate instance. The crossing horizontal and vertical bundles physically define the row-and-column (U and V) axes that can parameterize the sheet’s surface. In VC3D we have a fiber tracer tool, which is part of the Lasagna optimization ecosystem. It is not fully automated, and the line annotation widget inside VC3D is what drives it. Once fibers are annotated, [atlas.py](https://github.com/ScrollPrize/villa/blob/main/lasagna/atlas.py) can pair fibers / skeleton annotations and optimize a “patch” through them. This is not the only way to trace fibers. Some of the project's most valuable fiber-skeleton labels were traced by hand years ago in [WebKnossos](https://doi.org/10.1038/nmeth.4331) (a web-based tool for tracing and annotating skeleton-like structures voxel by voxel in large volumetric datasets), against older [EduceLab](https://arxiv.org/abs/2304.02084)-era scans taken at Diamond Light Source, a synchrotron facility distinct from ESRF — the facility behind the more recent scans discussed throughout this post. These annotations were voxelized and used to train a semantic segmentation model for fibers. We provide a checkpoint named [fiber\_hz\_vt](https://huggingface.co/scrollprize/fiber_hz_vt) — weights of an nnUNet model trained on "horizontal/vertical" fibers manually traced by annotators on the older 7.91 µm scans. Since we rescanned some of the old scrolls with the new protocol at ESRF, it can be important to match both labels and predictions. With cross-frame training we can work with volumes that live in different coordinate frames at once, bridged by an affine transform — a combination of rotation, scaling, and translation. A new dataset class, CrossFrameZarrDataset ([cross\_frame\_dataset.py](https://github.com/ScrollPrize/villa/blob/main/vesuvius/src/vesuvius/models/datasets/cross_frame_dataset.py)), does so using a transform.json sidecar file that records the map between the old annotation's frame and the new scan's. The main problem is obtaining, either through direct tracing or through semantic/instance segmentation, a way to identify and separate long fibers with the right connectivity. The same problem is shared in connectomics — the field that reconstructs a brain's wiring diagram by tracing individual axons and dendrites through teravoxel-scale 3D electron-microscopy volumes. Note (How you can help): If you know classical computer vision or point tracking techniques, robust fiber tracing is exactly this kind of problem. The goal should be reliable connections — a tracer that confidently follows fewer fibers correctly is more useful than one that follows more fibers with a higher error rate. ### Spiral fit: a global prior [section: /2026_open_problems#spiral-fit-a-global-prior] Local tracing can drift. Fibers can help, but they are also local or semi-local. There is another source of information: the scroll was originally a spiral. Call it a prior: an assumption used to guide a reconstruction. Here, it's that before damage and carbonization, the papyrus was rolled into a roughly cylindrical spiral. The real scroll is damaged, compressed, and deformed — but it's not an arbitrary tangle. A spiral fit starts from an idealized spiral and deforms it to match evidence from the scan, and that evidence can come from almost anywhere else in the pipeline: traced patches (small parts of the surface produced by GrowPatch or lasagna), fiber skeletons (created semi-manually using the lasagna workflow), surface prediction skeletons (automatically derived from the surface prediction volume), point constraints (e.g. "these points are one winding apart", "this patch is on winding 20", "these points are on the same surface"), and normal fields (the same dense normal-prediction volumes the lasagna produces, described above). Each of these sources of information provides a hard (verified) or soft (unverified) constraint on where the spiral windings should be. The spiral tries to satisfy as many of these constraints as possible, deforming the spiral as needed, and preferring the hard constraints. The spiral prior, illustrated: an idealized rolled scroll (left) is related to the damaged, deformed scroll observed in the scan (right) by a smooth spatial deformation — the transformation the spiral fit estimates. One way to represent the deformation is through a stationary velocity field. In simple terms, this is a smooth 3D field that tells points how to move from the ideal spiral toward the observed scroll. If the transformation is smooth and does not tear or fold the coordinate system onto itself, it preserves the global structure of the spiral while still adapting to damage. The fitting process itself is implemented in [fit\_spiral.py](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/scripts/spiral/fit_spiral.py), and there is a [full tutorial](/tutorial_spiral) on running it. A global prior can organize and regularize geometry, allowing a single consistent result to be produced from disconnected annotations, bridging small gaps and interpolating windings. But where annotations are sparse or the volume is highly ambiguous, spiral fitting is still under-constrained, and won't necessarily follow the true sheet surfaces. Note (How you can help): Devise better evaluation suites and loss functions to fit the spiral. Increase its expressivity and reduce the number of needed annotations. Most importantly, relative [winding number annotations](/open_problems/winding_annotations) seem to have a great impact on the spiral fit. Automating these procedures will boost scalability by a great extent\! ### Label quality: one of the main unwrapping bottlenecks [section: /2026_open_problems#label-quality-one-of-the-main-unwrapping-bottlenecks] Machine learning needs labels. For surface models, those labels often come from human-generated meshes or annotations — enormously valuable, but approximate. They may wiggle. They may drift slightly off the true surface. They may avoid the most ambiguous regions. This is also valid for manually or semi-automatically traced fibers. They may represent the best usable tracing rather than exact truth. This creates a subtle problem: the model isn't always learning the physical feature itself. It's learning from an imperfect representation of that feature. Why did we move forward with these datasets instead of fixing them first? The labels were not bad; they were good enough to support major progress in the previous phase of the project. However, as the pipeline becomes more ambitious, label quality has started to become one of the limiting factors. Note (Open problem): No method yet traces a complete, correct surface through a scroll automatically — and the labels used to train surface models are themselves approximate. The model isn't always learning the physical feature itself, but an imperfect representation of it: label quality is now one of the main unwrapping bottlenecks. Two real examples of label imprecision on a traced segment: the red line marking the recto surface runs visibly offset from the true fiber boundary in places (first pair, z=120), and drifts across fiber layers rather than tracking one sheet (second pair, z=200). A useful direction is label snapping: using the raw CT signal and local geometry to move approximate labels back onto the most plausible papyrus surface / fiber. Another direction is active learning, where the model identifies the most uncertain or valuable regions and asks humans to correct only those. Note (How you can help): If you have experience with 3D annotation, active learning, or data-quality workflows, this is a place where careful, small-scale work can matter more than scale. The next major gains in unrolling may come from better labels rather than simply larger models — a smaller set of precise labels in hard regions may be more useful than a larger set of approximate labels in easy regions. *** ## 3\. Ink recovery: reading the scrolls [section: /2026_open_problems#3-ink-recovery-reading-the-scrolls] Once the surface is traced and flattened, the next question is: where is the ink? The phrase ink detection is widely used, but there are two related tasks: * Ink detection: decide whether ink is present in a region. * Ink segmentation: locate the ink precisely, ideally in 3D. For an ideal pipeline, ink segmentation is the cleaner target. We would like to say: these voxels correspond to ink, these do not. But usually, the ink signal is too subtle for direct voxel-level annotation. That is why the current pipeline often uses models that work on surface-conditioned renders (also called surface volumes). A surface-conditioned render, or a surface volume, is a flattened 3D subvolume centered on a segmented sheet surface. Using the mesh’s 2D flattened coordinates, each point on the sheet is mapped back into the original CT volume. The center layer corresponds to the sheet surface, while additional layers are sampled at positive and negative voxel offsets along the local surface normal. This produces an image stack where the curved papyrus surface is represented as a flat layer, making nearby material and possible ink easier to inspect or process. ### Fragment-trained ink models [section: /2026_open_problems#fragment-trained-ink-models] Detached fragments are pieces of scroll where the writing surface is exposed. Some of these fragments exist because early researchers tried to physically open sealed Herculaneum scrolls: starting in the 1750s, first with Antonio Piaggio's mechanical unrolling device — a frame of weights and silk threads — and later with a range of chemical treatments, gas exposure, and slicing. These methods often cracked or shattered a scroll; some survived well enough to be read this way, many others were damaged or destroyed outright. Because the ink on a detached fragment's exposed surface is visible, the fragment can be photographed, often with infrared imaging. The same fragment can also be CT-scanned. That creates a training pair: * input: CT data around the papyrus surface; * label: visible ink from the photograph. The two halves of a fragment training pair: (a) a max-projection composite of the fragment’s CT data, where the ink is not apparent, and (b) the aligned infrared photograph of the same fragment, where the ink is clearly visible (scale bars: 5 mm). The model learns from fragments and is then applied to sealed scrolls. Generalization is not straightforward\! Working on surface-conditioned renders of the fragments’ outer sheet, the model receives a local 3D neighborhood and predicts a 2D ink probability map on the flattened surface. How a fragment becomes a training pair: the fragment (a) is photographed in infrared (e) and CT-scanned (b); a mesh of its exposed surface (c) extracts a flattened surface volume used as the model input (d), while the aligned IR photograph provides the 2D ink labels (f, g). However, fragment labels are 2D: the photograph tells us where ink appears on the exposed surface, but not exactly where the ink signal sits in depth inside the CT volume. The model is not OCR. It is not given Greek words, transcriptions, dictionaries, or language-model targets. It learns local CT texture and morphology associated with ink labels. ### Pseudo-labeling: bootstrapping weak signals [section: /2026_open_problems#pseudo-labeling-bootstrapping-weak-signals] Sometimes a fragment-trained model reveals faint but coherent ink traces inside a sealed scroll. When that happens, one can create pseudo-labels. A pseudo-label is a provisional label created from model output and human review rather than direct photographic ground truth. The loop is: 4. Train on fragments. 5. Run the model on a sealed scroll. 6. Identify plausible ink traces. 7. Create conservative pseudo-labels. 8. Fine-tune the model. 9. Run inference again. 10. Repeat. The pseudo-labeling loop in action on PHerc. 1667: six models (iterations 0–5) trained with progressively denser pseudo-label coverage, from a cross-segment baseline up to the densest available label set. Row (a) shows the training labels, row (b) predictions on a training segment (magenta = training label), and row (c) predictions on a held-out segment, which grow steadily cleaner and more legible. A concrete record of this loop exists in the six PHerc.1667-iteration-0 through \-5 checkpoints released alongside the project. Each of the six shares an identical architecture (a [ResNet3D-50](https://arxiv.org/abs/1711.09577) backbone initialized from [Kinetics-700](https://arxiv.org/abs/1907.06987) weights, feeding a 2D U-Net decoder) and an identical training budget, differing only in how much pseudo-labeled data it was fine-tuned on — from a cross-segment baseline at iteration 0 up to the densest available label set at iteration 5\. Why initialize from a video dataset? A video clip and a CT volume are both fundamentally 3D data — two spatial axes plus a third (time for one, depth for the other) — so a 3D-convolutional network pretrained on one transfers surprisingly well to the other. All six checkpoints are released on Hugging Face: [iteration-0](https://huggingface.co/scrollprize/PHerc.1667-iteration-0), [iteration-1](https://huggingface.co/scrollprize/PHerc.1667-iteration-1), [iteration-2](https://huggingface.co/scrollprize/PHerc.1667-iteration-2), [iteration-3](https://huggingface.co/scrollprize/PHerc.1667-iteration-3), [iteration-4](https://huggingface.co/scrollprize/PHerc.1667-iteration-4), and [iteration-5](https://huggingface.co/scrollprize/PHerc.1667-iteration-5). Note (Open problem): This process helped recover readable text in PHerc. 1667\. But it is not guaranteed to work everywhere. In some scrolls, predictions improve and then plateau. In others, current models show little or no convincing ink. The current ink detection model, which works on 2.4 µm data, is [https://huggingface.co/scrollprize/ink\_canonical\_2um](https://huggingface.co/scrollprize/ink_canonical_2um), inference code: [https://github.com/ScrollPrize/villa/tree/main/ink-detection/optimized\_inference](https://github.com/ScrollPrize/villa/tree/main/ink-detection/optimized_inference) We have evidence that working on 1.1 µm data yields cleaner results than 2.4 µm data. But scanning at high resolution is impractical. At 1.1 µm: \]οὐδὲ γὰρ \]τὰ μέλλοντα τελεῖϲθαι πρ\[ At 2.4 µm: τὰ μέλλοντα The square brackets follow classics and papyrology's standard "Leiden Convention" for transcribing damaged text: they mark text that is missing or illegible at that point in the original, not a typo or a transcriber giving up. An open bracket with nothing closing it, as in "πρ\[", means the word is simply cut off there by damage. What happens if the models don’t generalize? The right conclusion here is neither "the scan failed" nor "the model failed." At the moment, several explanations remain possible: * the scan may not capture the relevant signal strongly enough; * the surface may be slightly misplaced (suboptimally localized); * the ink labels may not match the true location of the ink signal; * the model architecture may not be exploiting the right features; * the ink morphology or chemistry may differ across scrolls; * the signal may be present but below the current pipeline's ability to use it. This is why better diagnostics matter just as much as better models — without them, it's hard to know which of these failure modes you're even fighting. ## 4\. Data scale: the infrastructure bottleneck [section: /2026_open_problems#4-data-scale-the-infrastructure-bottleneck] A full-resolution scroll volume is huge — too huge to just download to a laptop and work with as a local folder. So the project increasingly depends on chunked, cloud-friendly formats instead. One important format is [OME-Zarr](https://doi.org/10.1038/s41592-021-01326-w), which stores large multidimensional arrays in chunks and often at multiple resolutions, letting software read only the region it needs rather than loading an entire scroll. Getting the data format right turns out to matter as much as the algorithms built on top of it, because it determines what research is practical at all. A model that requires copying tens of terabytes locally shuts most contributors out before they start. An interface that can't stream small regions interactively leaves annotators waiting instead of working. And predictions that aren't saved in formats VC3D can inspect are hard to validate. Useful community contributions should therefore be cloud-native from the beginning: * read chunks directly from OME-Zarr; * run tiled inference; * write outputs in inspectable formats; * preserve coordinate metadata; * avoid unnecessary full-volume copies; * make predictions visible inside the geometry tools. But a list of good habits only matters if the infrastructure to support them exists. It does: VC3D already supports streaming volumes directly from our open data bucket at s3://vesuvius-challenge-open-data/. It's hosted for free via the AWS Open Data Program, browsable at https://vesuvius-challenge-open-data.s3.us-east-1.amazonaws.com/index.html, and stored as cloud-optimized OME-Zarr so tools can read only the region they need instead of downloading full volumes. ## Future directions [section: /2026_open_problems#future-directions] Densely labeled 3D training data is the bottleneck. The CT volumes are enormous and trusted voxel-level labels are scarce. Several future directions try to work around that bottleneck: first by learning useful 3D representations without dense labels, then by using those representations (often via frozen teacher models) to generate better training targets, and finally by directly segmenting ink when the CT signal is strong enough. ### Self-supervised 3D representations [section: /2026_open_problems#self-supervised-3d-representations] A major direction is self-supervised learning. In supervised learning, a model learns from direct supervision, which usually is provided via human annotated labels. In self-supervised learning, a model learns structure from raw data without needing a human label for every voxel/pixel. It is given a training objective that forces it to build useful internal representations. [DINO](https://arxiv.org/abs/2104.14294) is one family of self-supervised methods. A 3D DINO-style model can be trained on CT chunks so that similar 3D structures have similar internal embeddings. An embedding is a vector representation learned by the model. If ink-like voxels form a recognizable cluster in embedding space, a small number of expert-selected examples may help generate many candidate labels. This is especially attractive for our data because the volumes are enormous and labels are scarce. The project's 3D DINO implementation, [dinovol](https://github.com/ScrollPrize/dinovol), is open-source, with two trained checkpoints released on Hugging Face: [dinovol\_v2\_ps8\_with\_paris4\_352500](https://huggingface.co/scrollprize/dinovol_v2_ps8_with_paris4_352500) and [dinovol\_v2\_ps6\_step032350](https://huggingface.co/scrollprize/dinovol_v2_ps6_step032350). DINO-guided segmentation targets Labels derived from DINO embeddings in the scroll domain are usually either coarse or noisy. Still, they can be used as segmentation targets to train UNet models. The convolutional layers inside the UNet will learn a finer and accurate representation, and will likely be able to perform precise segmentation. Sometimes, before training directly an UNet, it could be worth “reinforcing” the embedding of the feature you want to label, using a minimal amount of manual input. For instance, one can use supervised contrastive learning: using a small set of labels (e.g, air, fiber, and an "ignore" class) to pull same-class embeddings together and push different-class ones apart. We did it on the PHerc. Paris 4 2.4 µm scan, and the fine-tuned DINO model is shared here: [dinovol\_v2\_ps8\_supcon3class\_step362500](https://huggingface.co/scrollprize/dinovol_v2_ps8_supcon3class_step362500) We used this frozen checkpoint to guide a 2-class background/fiber segmentation model.[fiber\_dinoguided\_2class\_step010000](https://huggingface.co/scrollprize/fiber_dinoguided_2class_step010000). "DINO-guided" doesn't mean what it might sound like: DINO isn't wired into this model's own architecture or forward pass. It's used externally, as a similarity signal for building the model's own training target. The training target itself is regenerated dynamically at every step. It can be blended with cosine similarity between each voxel's DINO generated embedding and a reference fiber embedding. A 10-panel debug figure from step 11900 of training. Top row: the raw CT image; the input mask; the teacher's pre-mask; the teacher's sigmoid output; the teacher binarized. Bottom row: the cosine-similarity map; the same map binarized by Otsu's method (labeled "Sim bin (Otsu=0.503)" in the original figure — 0.503 is simply this step's dynamically computed threshold, not a fixed setting); the soft union of the two signals; the binarized training target; and the student's own prediction. ### Direct 3D ink segmentation [section: /2026_open_problems#direct-3d-ink-segmentation] In recent high-resolution scans of PHerc. Paris 4, ink-bearing deposits become visible enough to support direct volumetric segmentation (see [this paper](https://arxiv.org/abs/2606.29085)). a) XY slice of PHerc. Paris 4, 2.4 µm scan. b) Ink segmented in 3D. c) Virtually unwrapped PI (no ink detection, the letter is directly visible). d): the flattened region with the recovered ink overlaid in red on the actual papyrus surface — multiple full lines of clearly legible Greek letters running the width of the sheet, not an isolated word or two. Not every scroll will behave like PHerc. Paris 4 — but direct 3D ink segmentation is possible under favorable scan and preservation conditions, and it gives us a cleaner target for future models. The checkpoint behind panel (d) in the previous image, [ink\_3d\_dino\_guided](https://huggingface.co/scrollprize/ink_3d_dino_guided) is trained specifically for PHerc. Paris 4 and is released on Hugging Face. Careful\! The 3D UNet segmentation model for ink segmentation was not only DINO guided, but it also used self-distillation from another 3D ink detection model (not discussed here) to clean up the DINO embedding during UNet training. Note (How you can help): If you work in 3D deep learning — segmentation, self-supervised learning, U-Nets — this is a natural fit. When ink is visible or can be localized confidently, as in PHerc. Paris 4 above, the cleanest formulation is voxel-level ink segmentation: it could reduce the ambiguity that 2D-projected labels otherwise introduce, giving the model a direct target instead of an indirect one. ### Self-distillation without ground truth [section: /2026_open_problems#self-distillation-without-ground-truth] Not every fiber- and ink-modeling effort in this pipeline starts from labels at all. A trainer at [scripts/fiber\_5class/](https://github.com/ScrollPrize/villa/tree/main/scripts/fiber_5class), specifically its [label\_generator.py](https://github.com/ScrollPrize/villa/blob/main/scripts/fiber_5class/label_generator.py), trains a 3D U-Net for 4-class semantic segmentation — background, vertical fiber, horizontal/angular fiber, and ink — directly on raw CT, with no ground-truth labels of any kind (in PHerc. Paris 4). Instead, two already-trained teacher networks generate the labels themselves. A teacher, here, is simply an ordinary, already-trained 3D U-Net — one estimating fiber probability, one estimating ink probability — kept completely frozen (its weights are never updated during this training run). Both teachers generate a fresh pseudo-label for every training crop, live, entirely on the GPU, and a student network is trained to reproduce it. Training a network this way — to reproduce another model's output rather than a hand-made label — is called self-distillation. Each training crop's label is assembled in five steps, confirmed by reading label\_generator.py: * The fiber and ink teachers each produce a voxelwise probability map. * The fiber probability map is thresholded into a fiber mask and run through a GPU watershed-from-minima — an image-processing technique that floods an image outward from its low points until separately-flooded regions meet, the way water fills separate basins in a landscape. Here, it splits touching or crossing fibers into distinct instances. * A principal component analysis (PCA) on each instance's own voxel coordinates finds its dominant axis: instances running mostly vertically become class 1 (vertical fiber); everything else becomes class 2 (horizontal/angular fiber). * The ink teacher's probability map overrides the fiber classes wherever it's confident — ink wins over fiber, becoming class 3\. * Voxels too dark in the raw, pre-augmentation scan are forced back to class 0 (background) regardless of what either teacher said, as a final safety guard. An 8-panel debug figure from step 26000 of training, with noticeably cleaner class separation than at earlier steps. Top row: the raw CT crop, cutting across several parallel fiber bundles; the pseudo-label overlaid on it; the pseudo-label alone; and the student model's own prediction, which closely tracks it. Bottom row: the fiber teacher's probability map, dominated by one long fiber bundle; the ink teacher's probability map, showing two distinct elongated streaks rather than one ambiguous blob; the watershed instances before the vertical/horizontal PCA split — each color is one instance, now legibly separated, including two compact, cleanly isolated cross-sections where a fiber runs roughly vertically through the slice; and the difference between the student's prediction and the pseudo-label it was trained on, mostly black, meaning close agreement. Legend: 0 = background, 1 = vertical fiber, 2 = horizontal fiber, 3 = ink. The result is released as [fiber\_ink\_4class\_selfdistill](https://huggingface.co/scrollprize/fiber_ink_4class_selfdistill), alongside the frozen fiber teacher that helped produce it, [fiber\_selftrain\_teacher\_epoch30](https://huggingface.co/scrollprize/fiber_selftrain_teacher_epoch30). ### Six ways you can help, recapped [section: /2026_open_problems#six-ways-you-can-help-recapped] Sections [2](#2-unwrapping-turning-disconnected-voxels-into-a-surface) and [3](#3-ink-recovery-reading-the-scrolls) above introduced mesh tracing, approximate labels, fiber connectivity, and 3D ink segmentation — and along the way, six 🙋 callouts pointed out where the community can make the most difference: * Create datasets with labels better localized on the papyrus’ recto or train ML models that can better preserve the sheets’ topology (See the 🙋 callout in ["Surface prediction"](#surface-prediction), Section 2.) * If you know classical geometry, optimization, or C++: help with automatic topology repair — building tools that catch mesh-tracing errors like holes, mergers, and sheet switches without a human checking every traced piece of surface by hand. (See the 🙋 callout in ["Meshes: adding connectivity"](#meshes-adding-connectivity), Section 2.) * If you have experience with 3D annotation, active learning, or data-quality work: help improve surface supervision. The labels 3D models learn from are still approximate, and a smaller set of precise labels in the hardest regions may matter more than a larger set of easy ones. (See the 🙋 callout in ["Label quality: one of the main unwrapping bottlenecks"](#label-quality-one-of-the-main-unwrapping-bottlenecks), Section 2.) * If you know classical computer vision or fiber/curve-following techniques: help with conservative fiber tracing — following individual papyrus fibers reliably across long distances to give the pipeline connectivity clues it otherwise lacks. (See the 🙋 callout in ["Fibers as connectivity clues"](#fibers-as-connectivity-clues), Section 2.) * Devise better evaluation suites and loss functions to improve the global spiral fit, or find efficient and automated ways to introduce exploitable prior information. * If you work in 3D deep learning (segmentation, self-supervised learning, U-Nets): help with direct 3D ink segmentation, or with self-supervised representation learning that could sharpen nearly every stage of the pipeline at once. (See the 🙋 callout in ["Direct 3D ink segmentation"](#direct-3d-ink-segmentation), Section 3; self-supervised learning as a cross-cutting direction is discussed further) *** ## 5\. Bottlenecks [section: /2026_open_problems#5-bottlenecks] The pipeline works, but not without a person checking its output at almost every stage — and it keeps failing in the same handful of spots. | Bottleneck | What it means | Current approach | What would help | | :---- | :---- | :---- | :---- | | Compressed or highly curved regions | Some regions lose effective separability between layers. | Better scan regimes, smaller voxel size, shorter propagation distance, phase retrieval. | Scan-quality metrics, and scroll-specific acquisition recipes. | | No built-in connectivity | CT gives voxels, not sheets or graphs. | Surface prediction plus mesh tracing. | Better geometry priors, fiber tracing, and topology-aware tools. | | Approximate surface labels | Human-created meshes are useful but not voxel-exact. | Train 3D surface models from approximate annotations. | Label snapping, active learning, self-supervised approaches. | | Sheet switches | Meshes can jump from one wrap to another. | VC3D inspection and manual correction. | Stronger local continuity constraints and conservative failure detection. | | Ink depth ambiguity | Fragment photos give 2D labels, not exact 3D ink positions. | Surface-conditioned 3D input with 2D output. | Direct 3D ink segmentation where possible. | | Cross-scroll generalization | Ink models may work on one scroll but not another. | Fragment training plus scroll-specific pseudo-labeling. | Multi-scroll training, better labels, stronger diagnostics. | | Data scale | Scroll volumes are too large for ordinary local workflows. | OME-Zarr, chunked processing, cloud storage. | Reproducible streaming pipelines and cheaper compute/storage paths. | One step forward on cross-scroll generalization came from an unusual source: an autonomous agent swarm, inspired by the open-source karpathy/autoresearch project (released March 2026\) and adapted internally for ink-detection model architectures. Running several agents continuously, the system found a configuration that nearly doubled the validation Dice score (computed on pseudo-labels) on PHerc. 1667 while training only on PHerc. 139 data — a genuine cross-scroll generalization improvement. *** ## 6\. What’s next? [section: /2026_open_problems#6-whats-next] We cant claim final victory. What's changed is that the bottlenecks are now much clearer. We know that a sealed Herculaneum scroll can be virtually unwrapped and read. We know that high-resolution scanning can make previously elusive ink more visible. We know that direct volumetric ink segmentation is possible in favorable cases. We know that fragment-trained models can generalize far enough to bootstrap scroll-specific reading. We know that semi-automated geometry tools can drastically accelerate tracing, even though human correction remains necessary. But the next goal is harder to name than any single breakthrough: making all of this reliable, on any scroll, without someone catching every failure. Can we choose scan parameters that preserve useful signals across scrolls? Can we infer surfaces from voxels without months of correction? Can we reduce the dependence on approximate labels, and reliably tell "no ink" apart from "no ink recovered yet"? And can we make the whole workflow reproducible enough for collection-scale reading? With the help of the community, we are confident that we can drive these points home. The target of the Vesuvius Challenge for June 2027 is to demonstrate that these questions have a positive answer. And whomever will provide that answer will win prizes, obtain eternal glory and write history with us. *** ## Appendix A: Methods we tried [section: /2026_open_problems#appendix-a-methods-we-tried] Not every method in the [villa monorepository](https://github.com/ScrollPrize/villa) is production-ready or actively growing. Two neural approaches to tracing were put “on-hold”. Neural tracer — extrapolation mode. The neural tracing system supports two related displacement-prediction approaches: a "copy" mode (already described above, in Copy Out/In) and an "extrapolation" mode, which instead predicts how the surface displaces as it grows outward beyond its current edge, without reference to a neighboring wrap. Neural mesh autoregression. Rather than proposing individual candidate points for the classical optimizer, this approach treats a tifxyz surface as a 2D lattice of 3D vertices and predicts an entire continuation of that lattice, one vertex at a time, conditioned on frozen 3D DINO features and a narrow "frontier" band of already-known geometry. Its own documentation calls it "a first MVP,". It is not currently wired into the production GrowPatch tracing loop: it generates mesh patches as a standalone alternative rather than feeding candidates into the classical geometric optimizer. The code lives at [neural\_tracing/autoreg\_mesh](https://github.com/ScrollPrize/villa/tree/main/vesuvius/src/vesuvius/neural_tracing/autoreg_mesh). Slow inference and rollout drift, for both. Two severe limitations apply to both approaches above, independent of the method-specific caveats already noted. Inference is slow at the 2.4 µm resolution the pipeline runs at, for both the neural tracer and the autoregressive mesh model. And running either model over a multi-step rollout — feeding each step's predicted geometry back in as the input to the next step, rather than making one isolated prediction — surfaces a drift problem: small errors compound across steps instead of staying bounded. That matters more than it might sound, because a long, multi-step rollout is the regime real production use needs: tracing a large, continuous span of a scroll, not one isolated local step. Neither problem is solved yet. *** ## Appendix B: Surface morphology and ink signal [section: /2026_open_problems#appendix-b-surface-morphology-and-ink-signal] An optical profilometer can image a fragment in a way that resembles a photograph, but instead of recording color, each pixel records surface height. The result is a heightmap: a high-resolution map of the fragment’s topography. Studies on opened Herculaneum fragments show that this surface shape alone carries usable information for telling inked regions from uninked ones. The finding comes from training machine learning models on three-dimensional optical profilometry of mechanically opened fragments ([Angelotti, Nicolardi, Henderson & Seales, 2026](https://www.nature.com/articles/s41598-026-58467-1) — see [References](#references-and-implementation-links)), which also measured how detection quality degrades as the lateral resolution of the height-map is coarsened: a direct, empirical link between spatial resolution and how much of the morphological ink signal survives. But ink doesn't always show up as simple raised relief — the signal is more subtle and heterogeneous, and may depend on fine texture, local roughness, cracks, deposits, deformation, or other small-scale surface changes. Figure 2 from the cited surface-topography paper: three papyri (PHerc. 248, PHerc. 250, PHerc. 500P2), each shown as (left) topographic heightmap converted to a uint16 image, (middle) the nnU-Net model's binary ink prediction, (right) the aligned brightfield photograph showing the actual visible ink — directly demonstrating that surface morphology alone predicts ink location. High effective resolution matters here too: some ink information may live at very small spatial scales. That's one more argument for smaller voxel sizes and better phase-retrieval regimes — and a reminder that no single contrast mechanism explains every scroll. *** ## References and implementation links [section: /2026_open_problems#references-and-implementation-links] ### Publications [section: /2026_open_problems#publications] * G. Angelotti, S. Parsons, F. Nicolardi, Y. Nader, S. Johnson, D. Josey, P. Henderson, H. Schilling, J. Rudolph, F. McDonald, E. R. Dal Prá, P. Tafforeau, A. Mirone, C. S. Parker, J. P. Posma, B. Kyles, C. Vergara, A. Lavorante, R. Villa, M. C. Robustelli, M. D'Angelo, G. Del Mastro, M. McOsker, K. Fleischer, C. Chapman, N. Friedman, and W. B. Seales, "Complete virtual unwrapping and reading of a rolled Herculaneum papyrus," arXiv:2606.29085, 2026. [https://arxiv.org/abs/2606.29085](https://arxiv.org/abs/2606.29085) * G. Angelotti, F. Nicolardi, P. Henderson, and W. B. Seales, "Ink Detection from Surface Topography of the Herculaneum Papyri," *Scientific Reports*, 2026. [https://www.nature.com/articles/s41598-026-58467-1](https://www.nature.com/articles/s41598-026-58467-1) * S. Parsons, C. S. Parker, C. Chapman, M. Hayashida, and W. B. Seales, "EduceLab-Scrolls: Verifiable Recovery of Text from Herculaneum Papyri using X-ray CT," arXiv:2304.02084, 2023. [https://arxiv.org/abs/2304.02084](https://arxiv.org/abs/2304.02084) ### Methods cited [section: /2026_open_problems#methods-cited] * nnU-Net — F. Isensee, P. F. Jaeger, S. A. A. Kohl, J. Petersen, and K. H. Maier-Hein, "nnU-Net: a self-configuring method for deep learning-based biomedical image segmentation," *Nature Methods* 18:203-211, 2021. [https://doi.org/10.1038/s41592-020-01008-z](https://doi.org/10.1038/s41592-020-01008-z) (preprint: [arXiv:1809.10486](https://arxiv.org/abs/1809.10486)) * U-Net — O. Ronneberger, P. Fischer, and T. Brox, "U-Net: Convolutional Networks for Biomedical Image Segmentation," MICCAI 2015. [https://arxiv.org/abs/1505.04597](https://arxiv.org/abs/1505.04597) * 3D U-Net — Ö. Çiçek, A. Abdulkadir, S. S. Lienkamp, T. Brox, and O. Ronneberger, "3D U-Net: Learning Dense Volumetric Segmentation from Sparse Annotation," MICCAI 2016. [https://arxiv.org/abs/1606.06650](https://arxiv.org/abs/1606.06650) * ResNet3D pretraining — K. Hara, H. Kataoka, and Y. Satoh, "Can Spatiotemporal 3D CNNs Retrace the History of 2D CNNs and ImageNet?," CVPR 2018. [https://arxiv.org/abs/1711.09577](https://arxiv.org/abs/1711.09577) * Kinetics-700 — J. Carreira, E. Noland, C. Hillier, and A. Zisserman, "A Short Note on the Kinetics-700 Human Action Dataset," arXiv:1907.06987, 2019. [https://arxiv.org/abs/1907.06987](https://arxiv.org/abs/1907.06987) * DINO — M. Caron, H. Touvron, I. Misra, H. Jégou, J. Mairal, P. Bojanowski, and A. Joulin, "Emerging Properties in Self-Supervised Vision Transformers," ICCV 2021. [https://arxiv.org/abs/2104.14294](https://arxiv.org/abs/2104.14294) * Adam optimizer — D. P. Kingma and J. Ba, "Adam: A Method for Stochastic Optimization," ICLR 2015. [https://arxiv.org/abs/1412.6980](https://arxiv.org/abs/1412.6980) * Ceres Solver — S. Agarwal, K. Mierle, and the Ceres Solver Team, "Ceres Solver" (software), 2023. [http://ceres-solver.org](http://ceres-solver.org) * SLIM (Scalable Locally Injective Mappings) — M. Rabinovich, R. Poranne, D. Panozzo, and O. Sorkine-Hornung, "Scalable Locally Injective Mappings," *ACM Transactions on Graphics* 36(2), 2017. [https://igl.ethz.ch/projects/slim/](https://igl.ethz.ch/projects/slim/) * Phase retrieval (Paganin method) — D. Paganin, S. C. Mayo, T. E. Gureyev, P. R. Miller, and S. W. Wilkins, "Simultaneous phase and amplitude extraction from a single defocused image of a homogeneous object," *Journal of Microscopy* 206(1):33-40, 2002. [https://pubmed.ncbi.nlm.nih.gov/12000561/](https://pubmed.ncbi.nlm.nih.gov/12000561/) * WebKnossos — K. M. Boergens, M. Berning, T. Bocklisch, et al., "webKnossos: efficient online 3D data annotation for connectomics," *Nature Methods* 14:691-694, 2017. [https://doi.org/10.1038/nmeth.4331](https://doi.org/10.1038/nmeth.4331) * OME-Zarr / OME-NGFF — J. Moore, C. Allan, S. Besson, et al., "OME-NGFF: a next-generation file format for expanding bioimaging data-access strategies," *Nature Methods* 18:1496-1498, 2021. [https://doi.org/10.1038/s41592-021-01326-w](https://doi.org/10.1038/s41592-021-01326-w) (spec: [https://ngff.openmicroscopy.org/](https://ngff.openmicroscopy.org/)) ### Competition [section: /2026_open_problems#competition] * Vesuvius Challenge – Surface Detection (Kaggle competition): [overview](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/overview) · [1st-place writeup](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/writeups/1st-place-solution-for-the-vesuvius-challenge-su) · [5th-place writeup](https://www.kaggle.com/competitions/vesuvius-challenge-surface-detection/writeups/5th-place-solution) ### Code [section: /2026_open_problems#code] * villa monorepository (VC3D / Volume Cartographer, lasagna, neural tracing): [https://github.com/ScrollPrize/villa](https://github.com/ScrollPrize/villa) * VC3D / Volume Cartographer app code: [https://github.com/ScrollPrize/villa/tree/main/volume-cartographer/apps/src](https://github.com/ScrollPrize/villa/tree/main/volume-cartographer/apps/src) * lasagna code: [https://github.com/ScrollPrize/villa/tree/main/lasagna](https://github.com/ScrollPrize/villa/tree/main/lasagna) · lasagna fiber tracer: [atlas.py](https://github.com/ScrollPrize/villa/blob/main/lasagna/atlas.py) * Spiral fit code: [fit_spiral.py](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/scripts/spiral/fit_spiral.py) * Ink detection inference code: [ink-detection/optimized_inference](https://github.com/ScrollPrize/villa/tree/main/ink-detection/optimized_inference) * Neural tracing inference service (heatmap / dense-displacement / copy modes): [trace_service.py](https://github.com/ScrollPrize/villa/blob/main/vesuvius/src/vesuvius/neural_tracing/trace_service.py) * Neural mesh autoregression (MVP): [neural_tracing/autoreg_mesh](https://github.com/ScrollPrize/villa/tree/main/vesuvius/src/vesuvius/neural_tracing/autoreg_mesh) * 3D DINO implementation: [https://github.com/ScrollPrize/dinovol](https://github.com/ScrollPrize/dinovol) * ScrollFiesta, community automatic mesher: [https://github.com/Hob3rMallow/scrollfiesta_public](https://github.com/Hob3rMallow/scrollfiesta_public) ===== PAGE: Tutorial: Spiral Fitting ===== URL: https://scrollprize.org/tutorial_spiral STATUS: current *Last updated: July 9, 2026* Most of our segmentation tools work bottom-up. [GrowPatch](/2026_open_problems#normal-grids-growpatch-and-local-tracing), [lasagna](/2026_open_problems#lasagna-smoother-optimization-of-one-or-more-sheets), and [manual segmentation in VC3D](/tutorial_VC3D) all produce *patches* — pieces of papyrus surface that you grow bigger and bigger until they hit a tricky region and stall. Other tools trace individual fibers. Either way you end up with a big pile of small pieces: segments, fibers, point annotations. What we really want is the *whole scroll* — one surface covering every winding of the original papyrus sheet, from the center to the outer shell. However, gluing the pieces together directly is hard, especially where there are gaps between them. [^tracer] That is what the spiral fit does. It takes the whole pile of partial evidence — surface patches, traced lines, winding annotations, volumetric predictions — and fits a single, globally coherent surface for the entire scroll that agrees with as much of that evidence as possible. Where the evidence is dense, the fitted surface follows it closely; where there are gaps, the spiral bridges them smoothly instead of stopping or leaving a gap. The core idea: we know the scroll was originally one long rectangular sheet, rolled up into a neat spiral. The eruption of Vesuvius deformed that spiral into the crushed shape we see in the CT scan. Instead of reconstructing the surface piece by piece, we search for the combination of *ideal scroll shape* and *smooth deformation* that best explains everything we observe. Once we have those, virtual unrolling comes almost for free: any point in the scan can be mapped back onto the original flat sheet. The [last section](#how-it-works) of this tutorial goes into how it works internally; first, the practical part — [what goes in](#what-goes-in), [what comes out](#what-comes-out), and [how to run it](#how-to-run-it). [^tracer]: The [surface tracer](/segmentation#growing-large-meshes-with-the-tracer-method) is an earlier attempt at this problem: it stitches overlapping patches into large segments automatically. But it requires the patches to physically overlap or touch, and it becomes unreliable at whole-scroll scale. ### What goes in [section: /tutorial_spiral#what-goes-in] The spiral is flexible about its inputs: it consumes many kinds of evidence, in almost any combination, and each kind can be created manually or automatically. - Surface patches — small pieces of scroll surface, stored as `tifxyz` meshes (the grid-of-3D-points format used by VC3D). These can come from [GrowPatch](/2026_open_problems#normal-grids-growpatch-and-local-tracing), [lasagna](/2026_open_problems#lasagna-smoother-optimization-of-one-or-more-sheets) (direct growth, or growth around fibers), neural [Copy In/Out](/2026_open_problems#copy-outin-exploiting-neighboring-wraps), or any other segmentation method. Patches are split into two groups, verified and unverified: the fit places strong weight on the human-checked verified patches, and treats the unverified ones as weaker hints. The verified patches are also used to calculate evaluation metrics. - Strips and lines of points that follow the surface of a single sheet — either *point collections* drawn in VC3D, or *fibers* traced in VC3D. - Relative winding annotations — sets of points lying on different windings, annotated with how many windings apart they are (e.g. "these two points are exactly one wrap apart"). Represented as VC3D point collections with relative-winding annotations. - Absolute winding annotations — points annotated with the absolute winding number they lie on (e.g. "this patch is on winding 20"). Also VC3D point collections. - Coarser volumetric guidance derived from machine-learning predictions: predicted surface normals (from lasagna, stored as zarr volumes), predicted gradient magnitude (which captures the local radial density of windings), and skeletonised surface-prediction *tracks* (created with `extract_surface_tracks.py`). - Scroll-level structure: the *umbilicus* (the scroll's central axis, as a function of z — required), and optionally a mesh of the scroll's outermost surface, which pins down where the spiral must end. None of these individually needs to cover the scroll. Sparse, scattered evidence — a patch in one region, a fiber in another, a few relative-winding annotations in an ambiguous area — is combined by the fit into one consistent global solution, and annotations placed where the scroll is most damaged contribute the most. ### What comes out [section: /tutorial_spiral#what-comes-out] The output is one `tifxyz` mesh per winding of the scroll — a full set of surfaces that conform to the input constraints, covering the whole fitted region including places no patch ever reached. Two variants are written for each winding: `wNNN`, the pure fitted spiral surface, and `wNNN_spliced`, where the geometry of verified patches is spliced into the fitted surface wherever the fit and the patch agree — more locally accurate wherever trusted geometry exists. Since these are ordinary `tifxyz` meshes, everything downstream works as usual: you can load them in VC3D, flatten them, and [render surface volumes for ink detection](/tutorial5). The repo also includes a tool ([`render_ink.py`](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/scripts/spiral/render_ink.py)) that concatenates the windings into fixed-width chunks, flattens them, and renders ink predictions as a series of horizontal strips — more on that [below](#rendering-ink). Alongside the meshes, a fit writes a model checkpoint, overlay images showing the fitted windings drawn over scan slices, and *satisfaction metrics* — per-input-type statistics of how much of the evidence the final surface actually honors. ### How to run it [section: /tutorial_spiral#how-to-run-it] The code lives in the villa repository under [`volume-cartographer/scripts/spiral`](https://github.com/ScrollPrize/villa/tree/main/volume-cartographer/scripts/spiral); the main entry point is [`fit_spiral.py`](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/scripts/spiral/fit_spiral.py). You'll need Python ≥ 3.14 and an NVIDIA GPU. ```bash git clone https://github.com/ScrollPrize/villa.git cd villa/volume-cartographer uv pip install torch torchvision # pick the build matching your CUDA version uv pip install -e scripts/spiral # the spiral scripts' Python dependencies uv pip install -e . # volume-cartographer python bindings ``` The spiral scripts declare their dependencies in their own [`pyproject.toml`](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/scripts/spiral/pyproject.toml) — only `torch` is left for you to install, so you can pick the right build for your CUDA version. The last line builds the volume-cartographer Python bindings, which the fit uses to link point annotations to patches; it compiles C++, so you'll need cmake and VC's build dependencies (see the [segmentation tutorial](/segmentation#installation-instructions) if it fails). #### Get the dataset [section: /tutorial_spiral#get-the-dataset] Ready-made inputs are published in the [`spiral-input` dataset](/data_datasets#spiral-input-2026-07), which lives on the dl.ash2txt.org data server : [Spiral Datasets](https://dl.ash2txt.org/datasets/spiral_datasets/PHercParis4/) (~90 GB): ```bash rclone copy :http: ./spiral_datasets/phercparis4 \ --http-url https://dl.ash2txt.org/datasets/spiral_datasets/PHercParis4/ \ --transfers 32 -P ``` `hf buckets sync` works like `rsync`: re-running it resumes interrupted downloads. The dataset contains verified and unverified patches, tracks, fibers, the outer shell, winding annotation JSONs, the umbilicus, and the volume inputs — see the [dataset README](/pathname:///data/datasets/spiral-input-PHercParis4-README.md) for the exact layout. #### Configure [section: /tutorial_spiral#configure] Configuration is straightforward: the input paths and fitting region are plain variables at the top of `fit_spiral.py`. Edit them to point at your download: - `dataset_path` — the root of the dataset; the per-input paths below it (`verified_patches_path`, `unverified_patches_path`, `pcl_json_paths`, `fibers_path`, `shell_path`, `tracks_dbm_path`, the normals/grad-mag zarr paths, …) default to locations inside it. Set any of them to `None` to fit without that input. - `z_begin, z_end` — the slice range (in full-resolution voxels) to fit. Consider starting with a small range: the whole written region of Scroll 1 is roughly z 4,000–17,000, and fitting all of it needs a lot of GPU memory (around 60 GB). A ~1,000-slice range is a good first run on a smaller GPU. Per-step sample counts are scaled automatically to the size of the z-range, so hyperparameters don't need retuning when you change it. Everything else — loss weights, resolutions, step counts — lives in the `default_config` dict just below, with one entry per knob. You can override any of them without editing the file via a JSON environment variable, and a few other environment variables control the run: | Variable | Effect | | --- | --- | | `FIT_SPIRAL_CONFIG_OVERRIDES` | JSON dict of `default_config` overrides, e.g. `'{"num_training_steps": 10000}'` | | `FIT_SPIRAL_OUT_DIR` | Output directory (default `./out`) | | `FIT_SPIRAL_CACHE_DIR` | Cache for preprocessed inputs (default `../cache`) — speeds up subsequent runs a lot | | `FIT_SPIRAL_RUN_TAG` | Tag appended to the output folder and mesh names | | `FIT_SPIRAL_RESUME_PATH` / `FIT_SPIRAL_RESUME_STEP` | Resume from a checkpoint | | `WANDB_MODE` | Set to `online` to log losses and visualizations to Weights & Biases (default `disabled`) | #### Fit [section: /tutorial_spiral#fit] ```bash python fit_spiral.py ``` That's it — the script loads the inputs (caching the expensive preprocessing), then runs 30,000 optimization steps, printing the loss breakdown every 200 steps. Multi-GPU is supported via `torchrun --nproc-per-node=N fit_spiral.py`, which splits each step's work across GPUs. When it finishes, you get a self-contained run folder: ``` out/2026-07-08_s1_slice-10500-11500_27399-patch_/ ├── checkpoint_fitted.ckpt # fitted model (resumable) ├── spiral_on_*_fitted.png # fitted windings overlaid on inputs ├── satisfied_fitted.json # how much of each input the fit honors └── meshes/mesh/ ├── w010/ # one tifxyz mesh per winding... ├── w010_spliced/ # ...plus the patch-spliced variant ├── w011/ └── ... ``` #### Rendering ink [section: /tutorial_spiral#rendering-ink] To get from per-winding meshes to readable images, use `render_ink.py`. It groups the `_spliced` winding meshes into winding-range chunks, concatenates each chunk into a single mesh (written to a `concat/` folder — useful for loading the geometry behind each strip as one mesh), SLIM-flattens it, renders it through an ink-prediction volume with `vc_render_tifxyz`, and composites the result into one JPEG strip per chunk: ```bash python render_ink.py /path/to/run/meshes/mesh --volume /path/to/ink_prediction.zarr ``` You'll need a [VC3D build](/segmentation#installation-instructions) on your `PATH` for the rendering and flattening binaries (`vc_render_tifxyz`, `flatboi`, …), and an ink-prediction zarr for the scroll. The output `ink/` folder fills with strips named by winding range (e.g. `w010-027.jpg`). #### Ink metrics [section: /tutorial_spiral#ink-metrics] The script `get_ink_metrics.py` computes some metrics based on the amount of letter-like ink signal detected in the ink renders. By default it uses the model `scrollprize/ink-coverage-32um` from HuggingFace; this is a 2D nnUNet operating on small patches, trained to do binary segmentation of clearly-identifiable ink. The script measures the total area of ink detected, as well as evaluating whether columns are coherent and have approximately the expected width, and lines are locally coherent (based on sliding windows) and have approximately the expected pitch. Note: The ink-coverage model was only trained on PHerc. Paris 4, so it may not give accurate results for other scrolls with significantly different writing styles. ### How it works [section: /tutorial_spiral#how-it-works] Up to this point we treated the fit as a black box; here is what is actually inside it. (There are more math details in the paper [*Virtually Unrolling the Herculaneum Papyri by Diffeomorphic Spiral Fitting*](https://arxiv.org/abs/2512.04927), though for a slightly older version of the algorithm.) #### An ideal scroll... [section: /tutorial_spiral#an-ideal-scroll] Originally, a scroll was one nearly rectangular sheet of papyrus, rolled up (often around a central rod). In cross-section that is a spiral — specifically, we model it as a perfect archimedean spiral, extruded into the plane. Treating it as arbitrarily large, the ideal scroll has just *one* free parameter: the tightness of its windings, $\omega$. A point on the ideal sheet is addressed by two curvilinear coordinates — the angle $\theta$ along the spiral and the height $z$ along the axis — and sits at radius $$ r(\theta) = \tfrac{\omega}{2\pi}\,\theta, $$ so each full turn moves the sheet outward by one sheet-to-sheet spacing $\omega$. Plug in any $(\theta, z)$ and you get a 3D point on the ideal sheet. #### ...horribly deformed [section: /tutorial_spiral#horribly-deformed] The eruption turned that neat spiral into the crumpled shape in the scan. We model the damage as a diffeomorphic transformation: a smooth, differentiable, *invertible* map of 3D space. That choice buys us exactly the guarantees we need: - It cannot tear the sheet, make it pass through itself, or squish it to a point — it preserves topology. If it starts as a spiral, after deformation it is still a spiral, just a messed-up one. - It is invertible: a point on the ideal scroll maps to a point in the scan, and — just as importantly — any point in the scan maps back to a point on the ideal (i.e. flattened) scroll. That inverse map *is* the virtual unrolling. The deformation is composed of three parts applied in sequence: a coarse global scale and shear, the integral of a stationary velocity field (the most important one), and a local scaling of the gap between windings, defined everywhere on the sheet (this lets windings locally squeeze together or spread apart without disturbing anything else). Each part is smooth and invertible, so the composition is too. The middle term deserves a closer look. Imagine a little 3D arrow attached to every point in space — a velocity field $u$. Every point of the ideal spiral flows along these arrows, like dust in a (smooth, steady) wind. Mathematically, the trajectory $\phi_t(x)$ of a point $x$ is defined by the ODE $$ \frac{\mathrm{d}\phi_t(x)}{\mathrm{d}t} = u\big(\phi_t(x)\big), \qquad \phi_0(x) = x, $$ and the transformation is where the flow ends up after one unit of time: $T_{\text{flow}}(x) = \phi_1(x)$. Don't worry too much about the equation — the intuition is what matters: every point rides smoothly along the flow, so the whole spiral deforms smoothly into a new shape, and running the flow backwards gives the exact inverse. This is the same machinery used in diffeomorphic medical image registration; in the code, the ODE is integrated with a few Runge–Kutta steps ([`flow_fields.py`](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/scripts/spiral/flow_fields.py), [`transforms.py`](https://github.com/ScrollPrize/villa/blob/main/volume-cartographer/scripts/spiral/transforms.py)). #### Fitting as an inverse problem [section: /tutorial_spiral#fitting-as-an-inverse-problem] Fitting is then an inverse problem: find the winding tightness $\omega$ and the deformation parameters (the velocity field, plus the scaling terms) such that the deformed spiral explains what we see in the scan. We don't fit to the raw CT intensities directly. Instead, every input from [What goes in](#what-goes-in) becomes a differentiable loss term saying what the deformed spiral should look like: - points from a same-sheet strip should all land on *some* winding surface (and the same one); - two points annotated as $k$ windings apart should land exactly $k$ windings apart; - a verified patch should coincide with a single winding across its whole extent — with unverified patches pulled in more gently; - tracks, normals, and gradient-magnitude volumes nudge the surface orientation and winding density; - the innermost winding should wrap the umbilicus, and the outermost should follow the outer shell; - and regularization terms keep the sheet parameterization from distorting. All parameters are optimized *jointly*, with plain Adam, minimizing the weighted sum of these losses (the weights are the `loss_weight_*` entries in `default_config`). In effect, we tell the machine "here are all the constraints humans and models have gathered — find the deformation that squishes the ideal spiral so that they are all met", and gradient descent does the rest. At the end, we sample each winding of the fitted ideal spiral on a regular $(\theta, z)$ grid, push the samples through the fitted deformation into scan coordinates, and write each winding out as a `tifxyz` mesh — the outputs described above. One caveat when reading [the paper](https://arxiv.org/abs/2512.04927): it describes a fully automatic setup that fits only raw surface-prediction tracks and fields derived from them. The current code fits the much richer curated evidence described in this tutorial — verified patches, fibers, and winding annotations — which is what makes it accurate enough to target whole-scroll segmentation. The underlying model and optimization are still very similar. ===== PAGE: In-depth: Winding Constraints ===== URL: https://scrollprize.org/open_problems/winding_annotations STATUS: current *Last updated: July 12, 2026* Winding constraints are sparse geometric evidence: points, lines, fibers, or surface patches whose relationship to the scroll's windings is known. The [spiral fit](/tutorial_spiral) combines these constraints with other evidence and deforms an ideal spiral into a single, globally coherent model of the damaged scroll. ## Why we are focusing on winding constraints [section: /open_problems/winding_annotations#why-we-are-focusing-on-winding-constraints] Given our recent work on PHerc. Paris 4, and the flexibility/sparsity afforded by the spiral fit, we believe that the fastest way to unroll scrolls at scale is to develop methods for creating winding constraints that are precise and fast enough to use widely We think that the spiral fit is flexible enough to unroll most scrolls given sufficient winding constraints. We don't know the exact minimum amount of winding evidence necessary for a given scroll ahead of time, but we know it is certainly *much less than full wrap segmentation*. It's important to emphasize here how much this changes the goal of anyone who wishes to unroll scrolls at scale. Rather than focusing on methods which produce large multi-winding segmentations (often by combining patches, using a "bottom up" style approach), and eventually must handle a more global idea of a fit if they wish to address inevitable surface prediction mistakes/sheet skips/etc -- often an extremely difficult task when starting from these bottom-up methods -- we now can focus on methods which prioritize local, accurate constraints, leaving the more global understanding to the spiral fit. There is no required annotation tool or generation method. Winding constraints can be drawn manually, inferred from fibers or meshes, produced by classical computer vision, proposed by a learned model, transferred from another representation, or generated by a new method we have not yet tried. An ideal winding constraint generator should be: - Accurate (or have some way to measure its confidence/accuracy) - Fast enough to process entire scroll volumes in a reasonable amount of time - Easy to verify - General enough to integrate into "global fitters", like the spiral fit ## Types of winding constraints currently used by the spiral fit [section: /open_problems/winding_annotations#types-of-winding-constraints-currently-used-by-the-spiral-fit] The spiral fit currently consumes annotations that encode three kinds of winding constraint. The constraints are best classified by the information they provide, not by the tool that made them or the feature they follow. - Same-winding constraints say that a collection of points lies on the same wrap of the papyrus sheet. A traced fiber, a line following the surface, or a verified surface patch can all provide this constraint. - Relative-winding constraints say how many complete wraps separate observations—for example, that one point lies exactly one winding outward from another. A multi-winding line can provide several such relationships at once. - Absolute-winding constraints assign an observation to a numbered winding. These anchor the solution's global numbering when that number is known. These constraints do not need to form a dense surface or cover the entire scroll. They tell the optimizer how disconnected pieces of local evidence relate to the scroll's global rolled structure. ## Some examples of winding constraints, and some promising areas to work on [section: /open_problems/winding_annotations#some-examples-of-winding-constraints-and-some-promising-areas-to-work-on] ### Things we have used [section: /open_problems/winding_annotations#things-we-have-used] #### Surface patches [section: /open_problems/winding_annotations#surface-patches] A surface patch traces a locally connected area of a single winding. It can be created manually or by a segmentation method, then used as same-winding evidence by the spiral fit. An interesting avenue would be identifying methods to automatically crop "good" regions of the spiral fit, and using these as surface patch inputs to a subsequent run. The patch in this image is cropped from a large trace which had sheet switches, but still contained many large areas which were high quality. #### Same-winding point line collections [section: /open_problems/winding_annotations#same-winding-point-line-collections] These point collections follow individual sheet surfaces. All points in one collection assert that they belong to the same winding. These can be spread out a fair distance (though not too far) across the surface and do not need to follow any particular scroll feature. #### Relative-winding point collections [section: /open_problems/winding_annotations#relative-winding-point-collections] Relative-winding annotations cross the layers rather than following one sheet. The numbered points record how many complete windings separate each observation from the reference point. #### Absolute winding numbers [section: /open_problems/winding_annotations#absolute-winding-numbers] When a winding's global identity is known, its points can be assigned an absolute winding number. These annotations anchor the numbering of the whole fitted solution. #### Fiber and line annotations [section: /open_problems/winding_annotations#fiber-and-line-annotations] A visible papyrus fiber can provide a natural path along one winding. Fiber annotations range from a carefully traced line with many control points to a small number of high-confidence observations along the same fiber. ### Things we have not tried [section: /open_problems/winding_annotations#things-we-have-not-tried] While we have used a few different types of winding constraints, there are many more things left to try. Here are some ideas we have thought about but have not yet had the time to implement: #### Drawn paths [section: /open_problems/winding_annotations#drawn-paths] Long paths drawn by hand or automatically across a flattened surface or within the volume can be made very quickly and could provide better connectivity than disconnected fibers. Should be easy to do manually very quickly, and likely learnable or doable with other classical computer vision methods. Points on the 2d flattened surface can be trivially mapped back to 3d. #### Ink as same-winding evidence [section: /open_problems/winding_annotations#ink-as-same-winding-evidence] Easily identifiable correct letters, rows, or columns are a natural source of same-winding constraints (and are likely the most easily verified). #### Intercolumnar gaps [section: /open_problems/winding_annotations#intercolumnar-gaps] The blank vertical spaces between columns of text can form long, recognizable paths across the papyrus surface. Like ink, they could provide same-winding evidence that is easy to identify and verify. #### Kolleisis [section: /open_problems/winding_annotations#kolleisis] Kolleiseis -- the joins where papyrus sheets were pasted together -- could be used as relatively large, full height same-winding constraints. They stand out well in the CT scan, and should be a good candidate for a deep learning model to excel at. ## Start here [section: /open_problems/winding_annotations#start-here] - [Create winding annotations in VC3D](/tutorial_VC3D#winding-annotation) - [Understand and run the spiral fit](/tutorial_spiral) - [Browse the current `spiral-input` dataset](/data_datasets#spiral-input-2026-07) - [Read the dataset layout and annotation files](/pathname:///data/datasets/spiral-input-PHercParis4-README.md) - [Inspect the spiral-fitting code](https://github.com/ScrollPrize/villa/tree/main/volume-cartographer/scripts/spiral) Join the [Discord](https://discord.gg/V4fJhvtaQn) ===== PAGE: Press ===== URL: https://scrollprize.org/press STATUS: current # Press For press and media inquiries, please email [press@scrollprize.org](mailto:press@scrollprize.org). To keep our public messaging accurate and consistent, only Vesuvius Challenge's Project Lead and co-founders are authorized to initiate contact with press and media on the project's behalf. You can find out who currently holds these roles on our [team page](/#team). We read every message and will do our best to get back to you. *** ===== PAGE: Data Browser — Scroll & Fragment Catalog ===== URL: https://scrollprize.org/data_browser STATUS: current Carbonized by the eruption of Mount Vesuvius in AD 79 and buried in the Villa of the Papyri at Herculaneum — the only library to survive from classical antiquity. Recovered in excavations begun in 1752; too fragile to open physically, it is read non-invasively via X-ray tomography and virtual unwrapping. The Data Browser catalogs every released Vesuvius Challenge sample — 45 in total (35 scrolls, 10 fragments) — each with its own page under https://scrollprize.org/data_browser/. ## PHerc. 9B (fragment) Sample page: https://scrollprize.org/data_browser/PHerc0009B Available pixel sizes: 2.401 µm / 8.64 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 125 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0125 Available pixel sizes: 9.362 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 139 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0139 Available pixel sizes: 1.129 µm / 2.399 µm / 2.403 µm / 9.362 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ Note: Title and author recovered — On Gods, Book 8, by the Epicurean philosopher Philodemus. About 20% virtually unrolled. ## Scroll 5 — PHerc. 172 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0172 Available pixel sizes: 7.91 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ Note: About 70% geometrically unrolled as of November 2025. ## PHerc. 175A (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0175A Available pixel sizes: 8.64 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 175B (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0175B Available pixel sizes: 8.64 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 191 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0191 Available pixel sizes: 9.362 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 211 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0211 Available pixel sizes: 9.362 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 257 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0257 Available pixel sizes: 9.362 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 268 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0268 Available pixel sizes: 8.64 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 306B (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0306B Available pixel sizes: 8.64 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## Scroll 3 — PHerc. 332 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0332 Available pixel sizes: 2.399 µm / 3.24 µm / 7.91 µm Licenses: CC BY-NC 4.0 (covers all other data) — https://creativecommons.org/licenses/by-nc/4.0/; EduceLab Data License (covers the 3.24 µm and 7.91 µm DLS scans) — https://dl.ash2txt.org/LICENSE.txt ## PHerc. 343 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0343 Available pixel sizes: 8.64 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 343P (fragment) Sample page: https://scrollprize.org/data_browser/PHerc0343P Available pixel sizes: 2.215 µm / 8.64 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 358 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0358 Available pixel sizes: 9.362 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 483A (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0483A Available pixel sizes: 8.64 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 483B (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0483B Available pixel sizes: 8.64 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 490A (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0490A Available pixel sizes: 8.64 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 490B (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0490B Available pixel sizes: 8.64 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 500P2 (fragment) Sample page: https://scrollprize.org/data_browser/PHerc0500P2 Available pixel sizes: 0.55 µm / 2.215 µm / 4.317 µm / 9.362 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 800 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0800 Available pixel sizes: 8.64 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 813 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0813 Available pixel sizes: 9.362 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 814 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0814 Available pixel sizes: 1.129 µm / 2.399 µm / 9.362 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 826 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0826 Available pixel sizes: 9.362 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 841 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0841 Available pixel sizes: 2.403 µm / 9.366 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 846A (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0846A Available pixel sizes: 2.403 µm / 9.362 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 846B (scroll) Sample page: https://scrollprize.org/data_browser/PHerc0846B Available pixel sizes: 9.362 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 1203 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc1203 Available pixel sizes: 2.403 µm / 9.362 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 1218 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc1218 Available pixel sizes: 8.64 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 1299 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc1299 Available pixel sizes: 2.399 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 1447 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc1447 Available pixel sizes: 8.64 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 1451 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc1451 Available pixel sizes: 2.399 µm / 8.64 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 1545 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc1545 Available pixel sizes: 9.362 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## Scroll 4 — PHerc. 1667 (scroll) Sample page: https://scrollprize.org/data_browser/PHerc1667 Available pixel sizes: 1.129 µm / 2.399 µm / 3.24 µm / 7.91 µm Licenses: EduceLab Data License (covers the 3.24 µm and 7.91 µm DLS scans) — https://dl.ash2txt.org/LICENSE.txt; CC BY-NC 4.0 (covers all other data) — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. 1667Cr1Fr3 (fragment) Sample page: https://scrollprize.org/data_browser/PHerc1667Cr1Fr3 Available pixel sizes: — Licenses: EduceLab Data License (covers all data — the DLS scans) — https://dl.ash2txt.org/LICENSE.txt ## PHerc. 51Cr4Fr8 (fragment) Sample page: https://scrollprize.org/data_browser/PHerc51Cr4Fr8 Available pixel sizes: — Licenses: EduceLab Data License (covers all data — the DLS scans) — https://dl.ash2txt.org/LICENSE.txt ## PHerc. MAN 5 (scroll) Sample page: https://scrollprize.org/data_browser/PHercMAN5 Available pixel sizes: 2.399 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. MANB (scroll) Sample page: https://scrollprize.org/data_browser/PHercMANB Available pixel sizes: 2.399 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. MANBp (fragment) Sample page: https://scrollprize.org/data_browser/PHercMANBp Available pixel sizes: 1.129 µm / 2.399 µm Licenses: CC BY-NC 4.0 — https://creativecommons.org/licenses/by-nc/4.0/ ## PHerc. Paris 1Fr34 (fragment) Sample page: https://scrollprize.org/data_browser/PHercParis1Fr34 Available pixel sizes: — Licenses: EduceLab Data License (covers all data — the DLS scans) — https://dl.ash2txt.org/LICENSE.txt ## PHerc. Paris 1Fr39 (fragment) Sample page: https://scrollprize.org/data_browser/PHercParis1Fr39 Available pixel sizes: — Licenses: EduceLab Data License (covers all data — the DLS scans) — https://dl.ash2txt.org/LICENSE.txt ## PHerc. Paris 2Fr143 (fragment) Sample page: https://scrollprize.org/data_browser/PHercParis2Fr143 Available pixel sizes: — Licenses: EduceLab Data License (covers all data — the DLS scans) — https://dl.ash2txt.org/LICENSE.txt ## PHerc. Paris 2Fr47 (fragment) Sample page: https://scrollprize.org/data_browser/PHercParis2Fr47 Available pixel sizes: — Licenses: EduceLab Data License (covers all data — the DLS scans) — https://dl.ash2txt.org/LICENSE.txt ## Scroll 2 — PHerc. Paris 3 (scroll) Sample page: https://scrollprize.org/data_browser/PHercParis3 Available pixel sizes: 2.4 µm Licenses: CC BY-NC 4.0 (covers all data) — https://creativecommons.org/licenses/by-nc/4.0/ ## Scroll 1 — PHerc. Paris 4 (scroll) Sample page: https://scrollprize.org/data_browser/PHercParis4 Available pixel sizes: 1.129 µm / 2.4 µm / 7.91 µm / 45.532 µm Licenses: CC BY-NC 4.0 (covers all other data) — https://creativecommons.org/licenses/by-nc/4.0/; EduceLab Data License (covers the 7.91 µm DLS scans) — https://dl.ash2txt.org/LICENSE.txt Data access and publication notice. These terms are a modification of the CC BY-NC 4.0 license (additional terms) under which these materials are provided. The publication-reservation period runs until 25/06/2027. The raw scan data, virtually unwrapped segments, ink-enhanced data, ink identifications, and related derived materials for this ancient scroll are being made available to support open examination, study, verification, and technical experimentation. Access to these materials is provided on the express condition that they are not used for scholarly publication during the temporary publication-reservation period. For one year from the public release of these data, scholarly publication rights are reserved for the research teams designated by the Vesuvius Challenge or by the custodial institution holding the physical scroll. Those teams have been granted the right to prepare the first scholarly analyses because they were designated by the Vesuvius Challenge or by the institution responsible for the original material. This publication reservation was a condition of the imaging of the scroll and must be respected by all users. During this period, users may examine, study, test, and analyze the data, but may not publish scholarly claims, transcriptions, translations, editions, interpretations, or formal analyses based on the data without permission from the Vesuvius Challenge, the custodial institution, or the designated scholarly teams. After the one-year restriction has expired and the designated teams have published their analyses, the data will be released from this publication restriction and will be available for unrestricted scholarly use. ===== PAGE: Vesuvius Challenge Team ===== URL: https://scrollprize.org/#team STATUS: current The people behind the Vesuvius Challenge, grouped as on the site's Team section. Created by: - Nat Friedman — Project conception, resources, open-science strategy. - Daniel Gross - Brent Seales — Initiated and pioneered the project; overall strategic guidance. Led by: - Giorgio Angelotti — Project lead since June 2025; conceived the improved CT scanning protocol; contributed to photogrammetric acquisition, case design, ink segmentation models, mesh parametrization algorithms, and cloud scaling. ## Tech Team - Sean Johnson — Developed mesh tracing software; mesh algorithms, ink detection, annotation. - Hendrik Schilling — Conceived and developed mesh tracing software; mesh algorithms. - Paul Henderson — Supervises machine learning and geometry research; mesh fitting algorithms. - Elian Rafael Dal Prá — Fiber and ink detection models, annotation. - Johannes Rudolph — Conceived cloud architecture scaling; data pipelines and optimization. ## Papyrology Team - Federica Nicolardi — Leads papyrological efforts; contributed to photogrammetric acquisition and multispectral imaging. - Marzia D'Angelo — Papyrological review and manuscript annotation. - Kilian Fleischer — Papyrological review and manuscript annotation. - Alessia Lavorante — Papyrological review and manuscript annotation. - Michael McOsker — Papyrological review and manuscript annotation. - Maria Chiara Robustelli — Papyrological review and manuscript annotation. - Claudio Vergara — Papyrological review and manuscript annotation. - Rossella Villa — Papyrological review and manuscript annotation. ## Annotation Team - David Josey — Leads annotation efforts since February 2025; contributor since May 2023. - Kendra Brown - Laura Trojak ## EduceLab Team (Partners) - Brent Seales — Initiated and pioneered the project; overall strategic guidance. - Seth Parker — Pioneered CT scanning protocols and mesh algorithms; photogrammetry. - Christy Chapman — Coordinates institutional relationships, permissions, and conservator interactions. - Mami Hayashida - James Brusuelas - Beth Lutin - Roger Macfarlane ## Advisors & Alumni - JP Posma — Led the Vesuvius Challenge online contest January 2023–February 2024. - Stephen Parsons — Project lead February–June 2025; pioneered ink detection pipelines; contributed to photogrammetry, case design, and scan protocol research. - Youssef Nader — Ink detection models and pseudo-labeling. - Ben Kyles — Led annotation efforts May 2023–February 2025. - Julian Schilliger - Forrest McDonald — Mesh tracing software. - Adrionna Fey - Cooper Miller - Eric Thvedt - Konrad Rosenberg - Raymond Gasper - Sarah Morejohn - Sergei Pnev - Techjays - Daniel Havíř - Ian Janicki - Chris Frangione - Garrett Ryan - Dejan Gotić - Jonny Hyman ## Papyrology Advisors - Daniel Delattre - Gianluca Del Mastro — Papyrological review and manuscript annotation. - Robert Fowler - Richard Janko - Tobias Reinhardt Roles summarized from the Author Contributions of [the PHerc. 1667 paper](https://arxiv.org/abs/2606.29085).