IOLink
IOL_v1.1.0_release
|
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:
Customer can use provided interfaces to implement their own file readers/writers, or simply use default implementation to work in memory.
Some basic types were needed for IOLink API use and are delivered for any other utilization:
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 :
For more details, please refer to View.
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 are classes used to open new accessors relative to the storage.
To ensure binary compatibility and ease the usage, objects can only by allocated and transformed through Factories.