The technique at the heart of the story is X-ray computed tomography, or XCT, the same fundamental technology used in hospitals to image the human body. When a drill core arrives on the Chikyu’s core processing deck, it is loaded into an onboard medical-grade scanner, a Revolution Frontier VT1700 built by GE HealthCare. The machine rotates an X-ray source around the section and reconstructs a three-dimensional map of how strongly the material attenuates X-rays. Because attenuation depends on both density and elemental composition, the resulting images reveal features that are completely invisible from the outside: burrows left by seafloor organisms, the sharp bases of turbidite deposits, subtle faults and deformation bands, and even the ghostly outlines of gas-filled voids.

Physically, the scanner reconstructs the distribution of the linear attenuation coefficient, conventionally expressed as CT numbers in Hounsfield units, a scale on which water registers zero and air registers minus one thousand. Dense minerals or materials rich in heavy elements produce high values, so discontinuities defined by density contrasts pop out of the images. The Chikyu scanner produces two-dimensional slices of 512 by 512 pixels across a 90-millimetre field of view, giving a resolution of about 0.176 millimetres within each slice, with slices spaced 0.625 millimetres apart. A full-length core section of roughly 1.4 metres therefore consists of some 2,200 to 2,300 individual slices, each saved as a DICOM file — the standard format of medical imaging. The scanner is calibrated every 24 hours using mock-ups of air, water, and aluminium to keep the numbers honest.

Here lies the paradox that motivated the new study, led by Hanaya Okuda of the Japan Agency for Marine-Earth Science and Technology together with colleagues in Austria and France. Although XCT scanning is one of the very first measurements performed on every core, and although it captures the most complete and continuous record of the material before anything is cut away, the data were largely going to waste. The DICOM files are enormous — typically more than a gigabyte per section — the viewing software is unfamiliar to most geologists, and only a handful of dedicated computers on the vessel could even open them. As a result, the scans were consulted almost exclusively by designated watchdog scientists whose job was to flag intervals for time-sensitive whole-round sampling, such as interstitial water squeezing or microbiology work, before the core warmed and its chemistry drifted.

Okuda and her team, including Charlotte Pizer and Michael Strasser of the University of Innsbruck and Mai-Linh Doan of Université Grenoble Alpes, set out to democratize that data. They built a Python-based visualization workflow that runs on the ship’s existing computers and converts the raw DICOM stacks into a family of accessible images that any shipboard scientist can consult within minutes. From each three-dimensional section volume, the workflow generates four image types: slices along the split surfaces of both the archive half and the working half, a slice perpendicular to the split surface that reveals structures hiding beneath it, and an unwrapped image produced by sampling the volume along a circular path of about 22.5 millimetres diameter centred on the core axis — effectively flattening the curved outer surface of the core into a single panoramic strip, a scheme adapted from methodology developed during IODP Expedition 405.

Alongside the images, the workflow computes a depth profile of CT numbers by averaging pixel values within a 40-millimetre-diameter circular area, counting only voxels above 1,200 Hounsfield units to exclude liner material and air. These parameters can be tuned manually for different lithologies, and the profiles are exported both as images and as CSV files for quantitative analysis. The individual products are then assembled into three nested summaries. A section summary lines up all five products for one core section, ideal for pinpointing undisturbed, representative spots for sampling. A core summary aligns one image type across every section of a core, directly mirroring what scientists see on the core description tables. Finally, a hole summary stacks every core in the borehole into a continuous downhole image, generated for both of the programme’s depth scales, CSF-A and CSF-B, and vertically compressed to one-third length for the downhole views.

The practical payoff is immediate and concrete. A physical properties specialist hunting for a crack-free cube of sediment for P-wave velocity measurements can scan the perpendicular slice to dodge fractures that would sabotage the measurement. Sedimentologists describing the archive half can compare their observations against the split-surface images to spot burrows and event deposits that a knife might smear. Structural geologists can trace faults through the working half before sampling destroys the context. And because the summaries are saved on a local computer accessible to everyone, scientists on any shift, in any science team, can generate them independently rather than queuing for the few machines equipped with DICOM viewers.

Getting the software to run smoothly on a research vessel posed its own engineering challenges. The team chose a Mac mini running the open-source Horos DICOM viewer as the processing host, because Horos offers prompt access to the shipboard XCT server and can export data easily, unlike the locked-down Advanced Workstation used for watchdog duties. They also decompress the DICOM files into the standard uncompressed Explicit VR Little Endian format, ensuring the archives remain usable in post-cruise research with tools such as ImageJ. To sidestep the notorious difficulty of configuring Python environments on shipboard machines, the entire workflow is packaged in a Docker container — a self-contained digital ecosystem that can be deployed on any computer running the free Docker software. The code reads each section’s 18-digit J-CORES identification number, builds a look-up table automatically, and processes more than 2,000 DICOM files per section in parallel across all processor cores, finishing in a few minutes; the downhole summaries take about one minute each.

The workflow was implemented and tested during IODP³ Expeditions 502 and 503, and while the summaries cannot yet be produced before time-sensitive whole-round sampling — not all sections have been scanned by that point — they are ready well before non-time-sensitive sampling, section splitting, and visual core description begin. The authors are candid about the method’s limits: slicing a three-dimensional volume along fixed planes inevitably misses some structures, so an irregular, subvertical feature such as an injection structure near the core’s outer edge could escape detection. They therefore recommend complementing the summaries with examination in a full three-dimensional DICOM viewer. Looking ahead, they envision direct comparison of the unwrapped images with borehole logging data, and the integration of machine-learning techniques to automatically detect key features, potentially fusing XCT data with continuous core scan images and other track measurements for an unprecedented real-time picture of what the drill has recovered.

What makes this development resonate beyond one ship is its philosophy. The Chikyu’s scanner was already producing world-class data on every expedition; the bottleneck was not instrumentation but accessibility. By wrapping a robust visualization pipeline in a portable container and publishing both the Docker image and the Python scripts openly, the team has shown how a modest investment in software can multiply the scientific return of expensive, hard-won samples drilled from the seafloor. The same strategy, the authors note, can be transferred to any laboratory working with drill cores, promising rapid and consistent visualization of large tomographic datasets wherever scientists interrogate the Earth’s buried archives.

Subject of Research: Non-destructive X-ray computed tomography visualization of drill cores and its integration into the shipboard core workflow on the drilling vessel Chikyu

Article Title: Non-destructive core visualization using X-ray computed tomography scan and its implementation into the core workflow on D/V Chikyu

Article References: Okuda, H., Pizer, C., Doan, M.-L., & Strasser, M. (2026). Non-destructive core visualization using X-ray computed tomography scan and its implementation into the core workflow on D/V Chikyu. Scientific Drilling, 35(1), 119-125. https://doi.org/10.5194/sd-35-119-2026

Image Credits: AI Generated

DOI: 10.5194/sd-35-119-2026

Keywords: X-ray computed tomography, drill cores, D/V Chikyu, IODP, scientific drilling, DICOM, core visualization, Python workflow, Docker, marine geology, shipboard science, JAMSTEC

The problem the developers set out to solve is one that any practicing metabolomics researcher will recognise. Instruments from SCIEX, Agilent, Waters, Thermo, and Bruker each produce data in proprietary formats that lock laboratories into specific software ecosystems, complicating cross-laboratory harmonisation and restricting long-term accessibility and reuse under FAIR data principles. Converting files to the community-standard open format mzML is a necessary first step, but it is only the beginning. Metabolic phenotyping experiments are also vulnerable to systematic variation arising from sample preparation, instrument performance drift, and batch effects, and even the choice of processing tool and its parameterisation introduces additional variance. Robust, standardised quality-control procedures are therefore essential, yet until now no single open tool combined vendor file conversion, automated peak integration, full auditability, and a documented quality-control layer in one scriptable environment.

MStargetR, developed by Harrison Szemray, Luke Whiley, and colleagues at Murdoch University and collaborating institutions in Australia and Colombia, takes a pragmatic architectural approach: rather than reinventing established tools, it builds on them. The package is organised into three core modules that map directly onto the sequential stages of a targeted multiple reaction monitoring (MRM) or selected reaction monitoring (SRM) experiment. The first, msConvertR, interfaces with ProteoWizard’s msConvert tool to convert proprietary vendor files into mzML format, accepting raw data from SCIEX, Thermo, Agilent, Bruker, and Waters instruments as well as files already in open formats. The second, PeakForgeR, performs retention time alignment, peak boundary optimisation, and automated integration. The third, qcCheckR, handles missing value imputation, internal standard normalisation, concentration calculation, signal drift and batch correction, filtering, and reporting.

The technical heart of the pipeline lies in how PeakForgeR handles peak integration. For each analytical batch, a lightweight algorithm identifies the peak apex and boundaries for each transition window, using the median apex retention time localisation across quality-control samples to define a plate-wide reference. These pre-defined boundaries are then pushed to the Skyline command-line interface for peak area integration, ensuring that consistent integration windows are applied across all samples rather than executing independent per-sample peak detection that could introduce variable integrals. Crucially, this approach produces a fully populated .sky document for every analytical plate. That document preserves every chromatogram, retention time annotation, and peak boundary used to generate the result table, and it can be reopened directly in the free Skyline graphical interface, where analysts can visually inspect individual peaks, manually adjust integration boundaries where automated detection falls short, and re-export corrected results that qcCheckR reimports without rerunning any upstream steps.

This handoff between automation and human oversight is arguably the package’s most distinctive design choice. Automated peak picking becomes a transparent first pass that the analyst remains in control of, while the .sky document itself becomes a shareable, auditable record of every integration decision behind a reported concentration matrix. It is a deliberate attempt to bridge the gap between proprietary vendor platforms, which offer rich visual inspection but are platform-locked and licence-dependent, and open-source R packages, which offer scriptability but have traditionally left the audit trail behind. The developers also provide a standalone batch correction module, batchCorrectR, that exposes the signal drift and batch correction routines for use on any tabular metabolomics dataset, including data processed through other software entirely.

On the quality-control front, qcCheckR offers three well-established correction methods that laboratories can select according to their own practices: quality-control-based random forest signal correction (QC-RFSC), which captures non-linear drift that linear models cannot; quality-control-based robust LOESS signal correction (QC-RLSC); and ComBat, an empirical Bayes method suitable for datasets that lack QC samples altogether. Missing values below a user-specified instrumental limit of detection are handled by imputing half the minimum observed value for each feature, a strategy designed to maintain data integrity. The module generates comprehensive outputs in both HTML and Excel formats, with the HTML report including summary tables of key quality metrics and interactive visualisations such as principal components analysis plots and control charts that allow dynamic exploration of data quality at the level of individual metabolites.

Reproducibility is engineered into the package at the infrastructure level. All third-party tools, including msConvert and Skyline, are bundled within version-pinned Docker images, so that the exact software environment travels with the analysis and eliminates complex dependency management. For high-performance computing environments that prohibit Docker, MStargetR can be configured to use Apptainer instead. The pipeline runs natively on AMD64 architecture across Windows and Linux, with macOS and ARM64 users currently needing a virtual machine, a limitation the team is actively working to address. For analysts who prefer not to write code at all, a Shiny-based graphical user interface provides code-free access to the full pipeline, and a Windows installer delivers the application directly from the Start menu, requiring only a container runtime alongside it.

The performance evaluation is striking. Applied to a published targeted lipidomics dataset of 128 human plasma samples targeting 1,161 lipid species with 73 stable isotope-labelled internal standards, MStargetR processed all samples end-to-end, recovering all 1,161 targeted lipid features. Of these, 949 features (81.7 percent) were detected and returned a relative standard deviation below 30 percent across replicated long-term reference quality-control samples, and 823 features met the more stringent RSD threshold of 10 percent, a figure the authors emphasise reflects combined effects of biological absence, method sensitivity, and deliberately stringent quality criteria rather than detection failure. Because per-transition precision metrics and the corresponding chromatograms are both retained, the reason any individual target falls below threshold can be inspected directly rather than inferred.

Scalability testing on a standard workstation showed that total runtime grew linearly from 14.9 minutes at 84 samples to 302.5 minutes at 4,200 samples, with per-sample processing time falling to just 4.1 seconds at larger batch sizes as fixed overhead was distributed across more injections. CPU utilisation plateaued around 62 to 67 percent once enough plates were available to keep the parallel workers supplied, and memory consumption was dominated by per-plate parallelism overhead rather than per-sample data accumulation. Predictable, linear scaling means laboratories can reliably estimate processing time for large cohort studies from the reported per-sample rate, a practical consideration as metabolomics studies grow to thousands of specimens.

The developers are careful to position MStargetR’s contribution as integration rather than algorithmic superiority. Quantification currently relies on single-point internal standard calculation rather than multi-point calibration curves, and dedicated MRM processors remain more complete in that respect, while the browser-based MRMPro remains stronger for rapid multi-user manual curation of very large cohorts. But no existing open tool, the authors argue, combines vendor conversion, automated integration, a re-importable audit artefact, and a documented quality-control and batch correction layer within one version-pinned, R-native environment. Future work will expand supported input formats, add multi-point calibration for absolute quantification across wider dynamic ranges, and tighten integration with public repository deposition. For a field whose credibility increasingly depends on whether results can be independently reproduced, MStargetR represents a meaningful step toward making rigorous, auditable targeted metabolomics the default rather than the exception.

Subject of Research: A reproducible, containerised R workflow for end-to-end targeted MRM/SRM mass spectrometry data processing

Article Title: MStargetR: a reproducible, containerised workflow for end-to-end targeted (MRM/SRM) mass spectrometry data processing in R

Article References: Szemray, H., Nambiar, V., Hicks, D., Lodge, S., Wist, J., Lawler, N. G., & Whiley, L. (2026). MStargetR: a reproducible, containerised workflow for end-to-end targeted (MRM/SRM) mass spectrometry data processing in R. Metabolomics, 22(5), Article 160. https://doi.org/10.1007/s11306-026-02541-2

Image Credits: AI Generated

DOI: 10.1007/s11306-026-02541-2

Keywords: metabolomics, mass spectrometry, MRM, SRM, lipidomics, reproducibility, R software, quality control, batch correction, FAIR data, open-source software, Docker