IOLink  IOL_v1.1.0_release
Overview

Main concepts

By design, IOLink provides an easy and efficient way to manipulate data and exchange them between software modules, using an unique interface. This library should allow to unify and centralize data accesses. This should lead to a safer data access and simplification of existing internal code.

IOLink is a set of interfaces (that customer can use for their own implementation) and contains some default implementation for in-memory usage.

IOLink interface provides following components:

  • basic types
  • views
  • factories
  • accessors
  • storages

Customer can use provided interfaces to implement their own file readers/writers, or simply use default implementation to work in memory.

Basic types

Some basic types were needed for IOLink API use and are delivered for any other utilization:

  • Array to represent multi-dimensional arrays of any basic types (to contain raw image data for example)
  • Vector, VectorX to represent multi-dimensional arithmetic vectors (to represent a multi-channel pixel value or a pixel/voxel position for example) of any basic types:
    • unsigned integers
    • signed integers
    • float
    • double (While Vector is compile-time-dimensioned, VectorX can be runtime-dimensioned)
  • Region, RegionX to represent multi-dimensional areas defined with origin and size. (While Region is compile-time-dimensioned, RegionX can be runtime-dimensioned)
  • DataType to provide introspective data types

Views

Main entry point to use IOLink.
A view points toward a data (wherever its origin, format, ...) and allows to access to it.

Many views can access to the same data, differently.

i.e. You can have a view onto an image, and another one onto a part of the same image.

Many views exists to differentiate their types (Image, Sound, Mesh, ...) and their capacities (Read, Write, Reshape, ...)

This may require to cast a view to some other view in order to access to each type functionality or capabilities. A view is strongly typed and follow the RAII paradigm: a View cannot be created empty (without type or size) and be initialized later.

As of now, IOLink focuses on images (N-dimension) by providing a specific view called ImageView.

IOLink implements the following kinds of ImageView :

  • a version which represents an in-memory N-dimensional image.
  • a user-memory version, almost identical to the previous one, but uses a memory buffer provided by the user.
  • a randomAccess version, an ImageView which data come from a RandomAccess. (see storage chapter)
  • a 'uniform' version, a memory-free ImageView in which every pixel has the same value (uniform content) defined at creation

For more details, please refer to View.

Accessors

Accessors abstracts image bytes stream from its physical location. Readers just have to interpret byte stream (as PNG or a DICOM) without taking care of data physical location.
A Accessors is different from a View because it does not contain any semantic, only bytes.

Storages

Storages are classes used to open new accessors relative to the storage.

Factories

To ensure binary compatibility and ease the usage, objects can only by allocated and transformed through Factories.