Custom implementation

Table of Contents

• Interfaces
  • Views
    • ImageView
    • MultiImageView
    • LodImageView
  • Storages
    • DataStorage
    • DataAccess
      • RandomAccess
      • StreamAccess
• Interface Checker

IOLink's first goal is to provide generic interfaces allowing users to re-implement IOLink objects behaviors 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.

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 ImageViewto 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. 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.

In IOFormat, some extractors are based on these interfaces, to represent all formats that can contain multiple frames (e.g. 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 (LDM, VDS, ZARR...).

Storages

DataAccess and DataStorage are 2 interfaces provided to support most of existing storages. (see Storage chapter)

DataStorage

The DataStorage interface represents any kind of repository where data can be stored (i.e.: fileSystem, HTTP server). This is basically a factory identified by a source (folder path in fileSystem case), that provides a way to access data stored in the storage.

DataAccess

The DataAccess interface is generic and basically represents an access to some data, wherever it is located, and however it can be accessed. The two existing methods 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 IOLink 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 no 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 ImageView interface:

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

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