Main concept

If you already use IOLink, you know it allows to handle views from any origin. It also allows to create in-memory views to work efficiently on memory images. And it can be sufficient for mosts of your needs. But, with IOLink, Image data cannot be extracted from current formats (bmp, jpeg, tiff, ...) or proprietary formats. Same thing for exporting.

IOLink is just a set of interfaces with few implementations for general needs. As these interfaces are generic and theorically permit to handle any kind of Images, it's up to you to develop your own reader (we call them Extractor) to handle a specific format, by implementing IOLink interfaces. And thanks to this system of interfaces, any applications based on IOLink will be able to handle your specific format.

But you don't want to implement your own reader for any current formats. One implementation is sufficient, and it is often already done.

IOFormat is here to gather and provide image formats readers and writers.

IOFormat is an aggregator of extractors/writers for any ordinary formats and even for your custom formats.

Plugin System

IOFormat handles extractors and writers as plugins (two different plugins for a extractor/writer couple, most often in the same library) which are dynamically loaded. At start-up, each available plugin (in "ioplugins" folder) is loaded and interrogated to retrieve its list of managed formats and extensions.

Extractors

An extractor is a implementation of IOLink ImageView or MultiImageView or LodImageView interfaces for a specific set of formats.

This extractor has in charge of decoding data (on the fly or not) from a file or an accessor (a stream or/and through the network) and provides decoded data through interface methods (readRegion(), shape(), dataType(), properties(), metadata(), ...).

IOFormat simply creates an instance of this extractors (for given format and data) and provides it to user.

Custom extractor

Developer is free to implement an extractor as it wishes for its particular need (custom format, custom loading method...).

IOFormat handles extractors with a plugin system. Each available extractor in IOFormat is developed as a plugin.

To implement a new extractor, somes rules should be respected to maintain coherency:

• extractor should as little as possible read the file (or accessor) content at initialization. The view shall be created as fast as possible, and image content should not be read before user requires it (by specifically calling a readRegion method).
• extractor should inherit from ImageView (because read capacity is required, of course) at minimum for formats containing only one frame or one volume or one time series
• extractor should inherit from ImageView if direct writing operation is accepted by Image format. (formats can efficiently handle this operation)
• extractor should inherit from MemoryImageView if data needs to be fully copied in memory. This allows the user to directly know that its view is fully in CPU RAM.
• extractor should inherit from MultiImageView for formats containing multiple frames, and not necessarly with same shape (otherwise, it could be also considered as a volume, and extractor could inherit from ImageView).
• extractor should inherit from LodImageView for formats containing level of detail (LOD) images.

Writers

A writer is an implementation of IOLink Writer interface for a specific set of formats.

They are used when an ImageView content must be encoded into an output format.

By design, a writer owns the view which is exported, because it can need a full read access to Image content. All formats are not encoded line per line (which would be easier), and thus each implementation can use the best (more efficient) way to build its output data into desired format from view content.

Each writer is instantiated through its own factory, because each format has its own list of parameters (compression, mode, ...).