This document details Datarock’s preprocessing workflow that includes the Image Preparation and Depth Registration Pipelines and produces out analytics ready depth registered strip imagery.
Contents
Dependent Models
The outputs of the preprocessing rely on the outputs of the following machine learning models.
Model Name | Model Type | Pipeline Name |
---|---|---|
Box Model | Instance segmentation | Image Preparation |
Row Model | Instance segmentation | Image Preparation |
Rock Coherent Model | Instance segmentation | Depth Registration |
Incoherent Rock Model | Semantic segmentation | Depth Registration |
Core block Model | Instance segmentation | Depth Registration |
Empty Tray Model | Instance segmentation | Depth Registration |
Depth Detection | Optical character recognition (OCR) | Depth Registration |
Dependencies
Data and metadata must be uploaded to the platform following the file name conventions described in these how-to articles in the Datarock knowledge base.
Image Preparation
The first step of the Preprocessing workflow uses the Image Preparation pipeline to convert the raw core box image into a cropped box and strip image.
Core box cropping
The raw core image may contain several core boxes or background material that is not required for analysis. The box cropping model aims to predict a polygon around each core box instance and can crop up to 4 boxes per image. After cropping, a black null padding region is added around each image to ensure the active image is not right at the margins of the image.
Core row cropping
The box-cropped imagery is then further cropped via a segmentation model that is trained to predict a rectangle around each row of the core within the box. From these, individual images of the box channel can be cropped and created (red polygons).
Configuration | Options | Description | |
---|---|---|---|
Dewarp Imagery | Dewarp can be turned on or off | Dewarp turned off will not modify original shape of the core box. Dewarp turned on will warp the original box shape into a vertically sided rectangle. |
Depth Registration
The aim of our depth registration process is to assign each pixel within rock material with an accurate depth position in the drill hole.
At a high level, the depth registration process aims to interpolate depth between known tie points such as core blocks, depth markers and box start and end depths, taking into account several factors including:
Adjustment and compaction of broken material
Core loss information
Optical character recognition to automatically read core blocks and depth marks
Measurement of detected rock within the tray (row models)
In this section, we will review the various inputs that feed into the depth registration process and explain at a high level how the final depth results are produced.
Compaction Factor
When rock material is broken, it can disperse in the box and occupy more length than it would have in situ in the ground. The depth registration process allows for zones of broken material to be compressed to better represent its original length in the ground.
Example: A compaction factor of 0.76 indicates that in order to optimise the depth interpolation, the incoherent material needed to have its measured length in the tray multiplied by 0.76. This will best match its actual downhole depth or length in the drill hole.
Core Loss
By providing core loss data through a csv file (refer to Uploading CSV Data ), the depth registration process can eliminate these missing depth intervals from specific locations.
Optical Character Recognition (OCR)
Using the machine learning technique called optical character recognition (OCR), depth marks and core blocks can be automatically extracted from the core. OCR reads all the text and numbers from the core image and then eliminates irrelevant information using specific rules. The OCR-identified depth markers appear in the depth registration tab and are used as depth tie points.
Row Detection Models
During the depth registration process, the position, length, and classification of different materials in each row of the core tray are identified. This information, along with the measured lengths of the rock materials, is utilized in the depth registration process and the following Depth Health Check workflows.
Coherent Rock
The Coherent Rock model identifies all pieces of cylindrical pieces of drill core, and draws a polygon around each piece (see below). A coherent piece of rock is defined as cylindrical with top and bottom edges that are approximately parallel to the core box row.
Incoherent Rock
The Incoherent Rock model predicts a polygon around regions that contain broken rock. Broken rock is defined as fragments of rock that are either non-cylindrical and irregular in shape or out of place.
Core block
The core block model predicts a polygon around each core block identified within the core tray.
Empty Tray
The Empty Tray model predicts a polygon around regions of core rows that do not contain rock material or core blocks. Empty tray is defined as a region where the base of the core tray is clearly visible. The Empty Tray class is also inserted in small (<1cm) spaces between the other row detection models (See bottom).
Depth Interpolation
The "depth tie points" are fixed points that cannot be altered, and the final calculation of depth involves interpolating the depth between these points. The rock between each fixed point is detected and measured, and core loss files are used to remove depth where necessary. If there is an excess of rock length in an interval, then compaction of the zones with detected broken rock can occur.
Estimate depth between tie points
Use OCR to identify core blocks and depth markers that align with the initial depth estimation
Discard OCR detections that do not align with initial depths
Perform secondary interpolation of depth using new tie points
Apply core loss, remove irrelevant depths, perform a third interpolation of depth, and apply compaction to optimize interval length.
Depth Health Check
The length of a given interval of rock within a drill hole is calculated in two different ways:
From depths supplied as metadata (client provided) - Image filename depths, .csv depth information
From measurement of detected rock material (Datarock calculated) -
Datarock reports these rock length/depth deviations as part of the Depth Health Check found in the notifications page under the Depth Registration Tab (see below).
Some level of depth error will be expected due to the accuracy of the drilling process and subsequent depth marking. For this reason we allow the user to set a Depth error tolerance value of depth different/deviation below which a Depth Health Check task will not be reported. The minimum size of the depth interval that can be reported as part of a Depth Health Check can also be set by using the Interval length tolerance configuration (described below).
Depth Registration Configuration Options
Configuration | Options | Description | |
---|---|---|---|
Dynamic row sampling | Dynamic row sampling can be turned on or off | Dynamic row sampling turned off uses a static sampling line that runs along the exact centre of the row image Dynamic row sampling turned on allows the sampling line to move up and down within the row image to best capture the predicted coherent rock polygons. | Example of row when dynamic sampling is turned off (line is along exact centre of the image) Example when dynamic row sampling is turned on (line is below the centreline of the box) |
Minimum width of coherent rock | Input of a percentage between 0 and 100% | The minimum width of coherent rock allows the user to define how much of the vertical height of a row is required to contain rock to be classified as coherent rock | Example of coherent rock with a low minimum width (~30%) due material obscuring the core. This would be classified as incoherent rock if the threshold was set too high. Example of coherent rock with a high minimum width (~90%) |
Depth error tolerance | Input of a number between 0 and n | Depth error tolerance value sets a threshold above which will trigger a Depth Health Check task. It is configured as a value of depth error per metre. i.e. if the error is set to 0.5m/m depth errors with less than 0.5m of length deviation per metre will not be reported. | |
Interval length tolerance | Input of a number between 0 and n | Interval length tolerance creates a threshold above which the user is alerted that the interval is above this threshold. This feature aims to alert the user to very long intervals with no pierce points that may not have a meaningful Depth Health Check. |
Product Limitations
A number of factors can control the simplicity and overall accuracy of the Datarock depth registration process. These factors are related to the accuracy and prevalence of known depth pierce points such as box depths, metre/feet marks and core blocks as well as core loss information.
Limitations | Comments |
---|---|
Known depth pierce points (Box depth, Core blocks, Depth marks) | Datarock depth registration performance will be highest where a high density of known depth pierce points are present in the form of box depths, core blocks and metre/feet marks. As the length between these pierce points increases so does the potential for depth errors to occur. |
Rock condition | Core that is highly broken and out of place can lower the accuracy of depth registration. Broken rock occupies more length in the core tray than its unbroken state. |
Core loss | Optimal depth registration performance requires complete located core loss to be accuracy measured over the entire drill hole. If located core loss is not collected then core recovery can be used but will result in lower less accurate depth registration. If no core loss is measured then localised depth errors will be present in regions of loss. |
Document Version
Version | Date | Author | Rationale |
---|---|---|---|
1 | 23 Aug 2023 | Brenton Crawford | Initial release |