IOLink
IOL_v1.1.0_release
|
IOLink capabilities, for now and future.
What is available in IOLink for now...
IOLink provides some elementary containers (Vector, VectorX, Array, VariantDataValue) and also some basic types to handle data (Region, RegionX, DataType, Uri). It helps for inter-operability.
IOLink is able to handle all kinds of image data (2D, volumetric, multispectral, video, ...)
Data don't need to be fully loaded in memory and can be accessed region by region from a file, in local (disk) or remote (through HTTP)
User code is significantly reduced when upgrading to DataModel. It eases readability.
Users don't need to do specific conversion to read data, wherever data comes from and how it is encoded.
IOLink mechanisms should prevent users to do invalid operations (high-level methods are provided to support users in their data manipulation)
Initially, IOLink was designed for multithreaded environments. However, thread safety mechanisms are not active by default to avoid performances issues with certain customer codes.
In the same major version of IOLink, binary compatibility is ensured to avoid symbol conflict in a same application, and permit object sharing between the different versions.
Netherless, there are some possible issues with different versions of IOLink loaded by different components of a same application. See DLL issue chapter.
IOLink is now interoperable with NumPy arrays (>= v1.17.4) for Python users.
IOLink provides an interface for multi-resolution-image.
What should be available in IOLink soon...
IOLink is able to handle other kind of formats (meshes could be the next step)
IOLink could provide the origin of the data, whatever it is located. IOLink could handle GPU data.
Users of the same data could be informed of any modification done by a mechanism of listeners.
Interoperability with Imaging, OpenCV, OpenGL are seriously considered.
IOLink could provide services to handle images in GPU memory for better performances