[Development] Imageformats v2

[Иван Комиссаров]

Hello everybody!

Recently i’ve started a project of a new imageformats API. The reasoning is that there are a lot of limitations in the current API: no way to save file containing an array of images, bad error handling, no support for the EXIF. Implementing those features requires ABI breakage of the QImageIOHandler class (adding new virtual functions, at least). So i’ve decided to start from scratch.

Code is located here https://github.com/ABBAPOH/imagedocument/tree/master/src/lib <https://github.com/ABBAPOH/imagedocument/tree/master/src/lib> and is just an API rather working implementation.

Let me describe current API and the ideas behind it.

The core class is the ImageDocument - this is the replacement of the QImageReader/QImageWriter. Reader and writer has similar API and implemented in the same way, so i’ve decided to merge them into one class. ImageDocument inherits QObject so it can connect to the QIODevice signals and read image while it downloads from network, for example. So, device() and fileName() methods are similar to the corresponding methods in reader/writer.

Instead of QByteArray format() i choosed to use QMimeType. With mimetypes, we don’t need to iterate over handlers like we do now in attempt to find suitable one. This code is already written in mimetypes, so all we need is to find suitable mime type.

bool hasError()/QString error() - no comments.

bool open(OpenMode) is an attempt to get rid of the QImageReader::canRead() function. Unlike canRead(), open can not only check if data is valid, but also read the header of an image so we can know how many data acually present. OpenMode can be Read/Write or both; right now, WriteMode can only be checked by handler if it supports writing (i.e. can be used instead of QImageIOPlugin::CanWrite).

close() is symmetrical for open() not sure if it really needed.

capabilities() method returns capabilities (yep) of a format, see CapabilityFlag enum.

Conceptually, ImageDocument is a 2D array (of size is mipmapCount()*frameCount()) of ImageResources plus meta data (ImageMeta class). The first dimension of the array is mipmaps (SupportMipmaps flag - can be used by Ico, Icns, DDS image formats), the second dimension is the frame number (actually, that should be something like array index) - can be used by GIF, DDS (yes, dds have both mipmaps and frames).

ImageResource can be a single image, a cube texture (Capabilities::SupportSides flag) or a VoumeTexture (Capabilities::SupportSlices flag). Type is described by ImageResource::Type enum. In the first case, Resource contains a single image, in the second case - array of 6 images (for each side of a cube) and in the third case it contains array of images of size ImageResouce::depth.

Also, both ImageResource and ImageDocument have metadata associated with it (ImageMeta class). The duplication is needed for 2 reasons: first, some formats can support different meta for each resource (icns), some has the same meta for all resources (DDS); second, meta in document can be used if you don’t need to set meta for each resource separately.

ImageDocument::supportsOption() returns options supported by the document, supportsResourceOption() returns options supported by resources (typically, resource options depend on the subtype of a resource, at least for Icns).

What i dislike now is that the Document a 2D array. Maybe i should move mipmaps dimension to a separate class Mimpap {QVector frames;} ?

Next, i don’t have support for layered images (PSD?). With current API, they can be implemented in 2 ways - either ImageResource is a Layer containing list of elements with layer metadata (position on a layer, blending options, z-order). Or ImageResource is an element on a layer and the layer it belongs is an index/name in resource’s metadata.

So, i want to know an opinion of the people familiar with imageformats about the API - what should i change/add/remove?

Иван Комиссаров

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150519/68b41185/attachment.html>