IOLink's first goal is to provide generic interfaces allowing users to re-implement IOLink objects behavior to satisfy their specific needs. Even if IOLink provides default implementations for most common cases, users can create their own implementations to solve some inter-operability issues or to implement a case not yet identified by the IOLink dev team.

As an implementation example, IOFormat's library for format encoding/decoding, is a set of objects implemented on IOLink interfaces.

Views

There are no benefits to directly implement this interface, so it is considered as forbidden. But this interface is the basis for any new interface that aims to handle other types of data (Mesh, Sound, Text...).

ImageView

ImageView is the interface to re-implement if you need to handle an object toward a specific image data content.

In IOFormat, extractors used to decode a single-image format are based on the ImageView interface (with their appropriate capabilities).

The inter-operability with NumPy Python objects is done through a specific implementation of ImageView.

Internal mechanisms of adapters in IOLink can be based on a specific implementation of ImageView to transform/adapt an ImageView content or any kind of view content to a specific need.

MultiImageView

MultiImageView is an interface that represents a container for many ImageView instances. These images are stored in a specific order.

MultiImageView has the following capabilities:

READ: to access the frames.
WRITE: to add or modify frames.

Internal mechanisms of adapters in IOLink can be based on MultiImageView interfaces, so as to transform/adapt a view into a container of many ImageView instances.

In IOFormat, some extractors are based on these interfaces, to represent all formats that can contain multiple frames. For example, TIFF format in which each frame can have no relation with others.

LodImageView

The LodImageView interface represents a set of images with different levels of resolution. It has no implementation in IOLink, since there is no default behavior to provide to the customer. It's up to the user to determine the best method to go from an image resolution to another, according to their needs. A default implementation would only provide one specific use case which would be useless for all others.

In IOFormat, this interface allows the representation of some image visualization formats like LDM, VDS, or ZARR for example.

DataStorage

The DataStorage interface represents any kind of repository where data can be stored, for example a file system or an HTTP server. This is basically a factory identified by a source, a folder path in fileSystem case, that provides a way to access data from the storage.

DataAccess

The DataAccess interface is generic and basically represents an access to some byte data, wherever it is located, and however it can be accessed. The two existing interfaces to access data are:

RandomAccess
StreamAccess

A new implementation of the DataStorage interface needs to define at least one DataAccess for data to be relevant.

See the "Storage concept" chapter in the this user guide.

RandomAccess

The RandomAccess interface represents a random access to some data. RandomAccess handles capabilities (READ, WRITE, RESIZE) and thus you must implement all methods corresponding to the capabilities you need (see interface contract).

Actual capabilities of a RandomAccess are given to customers through a method which must return the appropriate enum value following implemented methods (available capabilities).

StreamAccess

The StreamAccess interface represents a stream access to some data. StreamAccess handles capabilities (READ, WRITE, SEEK, BUFFER_INFO) and thus you must implement all methods corresponding to the capabilities you need (see interface contract).

Actual capabilities of a StreamAccess are given to customers through a method which must return the appropriate enum value following implemented methods (available capabilities).

Interface Checker

The aim of these interfaces is to open IOLink to any needs, and to provide the same service in a common library. To achieve this, customers have to ensure their own implementations conform to a contract defined in IOLink.

A Checker static library is provided by IOLink to help developers to ensure the contract rules are fulfilled. Calling check methods for the interface to test with one object resulting of this interface implementation, will tell you if any major issue is detected.

Headers to include for each interface to check:

checker/ImageViewChecker.h
checker/ComposedViewChecker.h
checker/LodImageViewChecker.h
checker/MultiImageViewChecker.h
checker/DataStorageChecker.h
checker/RandomAccessChecker.h
checker/StreamAccessChecker.h

Example for the ImageView interface:

#include <checker/ImageViewChecker.h>
 
std::shared_ptr<ImageView> image = ... // one instance of your ImageView implementation
 
bool result = ImageViewChecker::check(image);

Remark: This checker is only available in C++ language so far.

Table of Contents