Automated Import to Datarock: Drill Core Photography from Imago

The article outlines the process, requirements, and limitations of implementing the Imago API to transfer images and metadata from Imago to the Datarock Platform for data processing using computer-vision technologies.

Some of Datarock’s customers take drill core photography on site and use Imago Connect software to transfer the images and associated metadata to Imago.

Once available on Imago, Datarock copies the images and associated metadata into the Datarock Platform using the Imago API, then performs data processing using computer-vision technologies, to provide geological and geotechnical data products.

This document outlines the process, requirements, and limitations of the implementation of the Imago API to copy images from Imago to Datarock. 

Process

The following example outlines how Datarock interacts with data on Imago, using the Imago API.

Datarock queries new and updated Imagery data using the Imago API. The frequency of this query is flexible (e.g. hourly, weekly). 

Images associated with these Imageries are then exported from Imago and imported into Datarock.

Authentication

Image Rotation

EXIF stands for Exchangeable Image File Format and is a standard for storing supplemental metadata in digital photos, including rotation information. It is best practice to use this information to ensure images are displayed correctly, however, as outlined on this page (Imago Help and Resources), Imago ignores image EXIF (rotation) metadata which is not normal practice.

In order to ensure Datarock displays the images the same as they appear in Imago and minimise differences and therefore frustrations, Datarock modifies the EXIF rotation data on import.

Requirements

• Customers provide up-to-date core loss files to Datarock in the defined format and location (detailed in a separate document). If Datarock receives drill core imagery from Imago before core loss files, Depth Registration will run without the information contained within the core loss files, resulting in poorer performance. Depth Registration will need to be re-run if there is out-of-order core loss and image data availability in Datarock.

Customers ensure that core box numbers (start and end) are always reported as metadata when submitting images and metadata to Imago. Datarock relies on core box number sequences to ensure appropriate depth registration and to account for missing boxes during processing. If any new or updated imagery in Imago under the relevant imagery type and image type does not have box numbers, the import service will fail, awaiting metadata addition to the sources in Imago.

Limitations

• Uploading a new Image to an existing Imagery will not be copied into Datarock if the new Image is uploaded after more than one API query cycle.

• Editing metadata of an Imagery (e.g. Box, start and end Depths) in Imago would create an alternative image in Datarock, without deleting the original image. A user would have to manually delete the incorrect image in Datarock.

• There is a lag between creating an Imagery and assigning an Image to that Imagery in Imago. If a Datarock query to the Imago API identifies a new/updated Imagery but no associated new Image, the next query to the API will not be aware of the new Image. To mitigate this, Datarock adds a short time overlap between requests. This removes the effect of the lag between generation of an Imagery and an Image, however results in possible duplication of returned Images from Imago. In this scenario, the duplicate Image will be imported into Datarock, prompting new Image Preparation and Depth Registration runs.

• Datarock can not delete records that are in Imago. This includes metadata.

• Datarock can not set a date/time range to query for new or updated Imageries or Images. The Imago API only allows for querying of Imageries within a given time from the time that the API is called.

There is no way to filter Imageries by the Image Type of associated Images. If a Customer was to introduce a new Image Type, the query time could be impacted.

Document Version