Utilisation de DevIL avec Qt

DevIL est une librairie cross-plateforme qui s'occupe de lire et d'écrire des images.

Elle essaye par sa structure de se rapprocher de OpenGL : trois parties la composent.

DevIL (ou IL), la partie centrale, des fonctions de très bas niveau, qui permettent la lecture de pixels.

DevILU (ou ILU), la partie des outils de la librairie, comme la lecture de plusieurs pixels.

DevILUT (ou ILUT), la boîte à outils, des fonctions de haut niveau qui permettent d'effectuer facilement des opérations complexes, comme la superposition d'images.

Il existe deux types de plugins pour Qt : ceux de haut niveau, qui étendent les fonctionnalités de Qt ; et les bas niveau, qui étendent les fonctionnalités d'une application. Nous nous intéresserons à ceux de haut niveau, vu que nous voulons étendre les capacités de Qt.

Les plugins sont rangés dans un répertoire plugins. Celui-ci peut se situer à différents endroits : dans le répertoire de votre application, dans le répertoire de Qt (s'il est installé sur la machine), mais vous pouvez aussi désigner un ou plusieurs répertoires où les plugins sont rangés, à l'aide de la fonction statique setLibraryPaths(), ou bien utiliser un fichier de configuration qt.conf.

Avant de charger un plugin, Qt fait quelques recherches pour vérifier que le plugin peut être utilisé sans risque : il ne peut pas être compilé avec une version postérieure de Qt (pour éviter que des fonctions inexistantes soient utilisées), ni avec une version majeure antérieure (il existe d'énormes différences entre deux versions majeures de Qt), et, si présente, la buildkey doit être identique.

La buildkey est une clé qui identifie une compilation de Qt : deux compilateurs (ou deux versions) ne produisent pas le même code, et cela peut engendrer des problèmes ; deux configurations de Qt différentes peuvent produire des binaires incompatibles ; on peut préciser une buildkey lors de la configuration de Qt : cette chaîne est concaténée aux informations précédentes, pour éviter qu'un plugin compilé pour une application soit utilisé avec une autre.

Ce processus de validation peut être très coûteux en temps, c'est pourquoi un cache est établi. Ce cache se base sur la date de modification du fichier (ce qui réduit les comparaisons à une seule). Si le fichier est modifié après son entrée dans le cache, il est validé de nouveau.

#include <QImageIOHandler>
#include "devil-qt-handler.hpp"

Une seule explication : le fichier devil-qt-handler.hpp est l'en-tête du handler, c'est lui qui proposera le prototype des fonctions de lecture et d'écriture.

III-B-1. Le prototype▲

class DevILPlugin : public QImageIOPlugin
{
public:
    DevILPlugin();
    ~DevILPlugin();

    QStringList		keys			()
			const;
    Capabilities	capabilities	(QIODevice *device, const QByteArray &format)
			const;
    QImageIOHandler	*create			(QIODevice *device, const QByteArray &format = QByteArray())
			const;
};

III-B-2. Constructeurs et destructeurs▲

III-B-3. keys()▲

QStringList DevILPlugin::keys() const
{
	QStringList	supported;
	supported << "act";
	supported << "bmp";
	/*
	...
	*/
	supported << "tga";
	supported << "vtf";
	return supported;
}

III-B-4. capabilities()▲

QImageIOPlugin::Capabilities DevILPlugin::capabilities
	(QIODevice *device, const QByteArray &format)
		const
{
	QImageIOPlugin::Capabilities cap;
	
	if (format.isEmpty()
	|| !( device->isOpen() )
		)
	{
		return cap;
	}
	
	if(		format == "bmp"
	/* ... */
		||	format == "tga"	)
	{
		cap |= CanRead;
		cap |= CanWrite;
		return cap;
	}
	else if (format == "act"
		/*
		...
		*/
		||	 format == "vtf"	)
	{
		cap |= CanRead;
		return cap;
	}
	else
	{
		return cap;
	}
}

III-B-5. create()▲

QImageIOHandler *DevILPlugin::create(QIODevice *device, const QByteArray &format)
		const
{
    QImageIOHandler *handler = new DevILHandler;
    handler->setDevice(device);
    handler->setFormat(format);
    return handler;
}

III-B-6. Les macros de fin▲

Q_EXPORT_STATIC_PLUGIN	(DevILPlugin				)
Q_EXPORT_PLUGIN2		(devil-qt,		DevILPlugin	)

DevILHandler::DevILHandler()
{
	ilInit();
	iluInit();
}

On initialise DevIL et ILU. Le dernier ne sert que pour la gestion des effets gamma.

void DevILHandler::setFormat(ILenum _Format)
{
	this->I_Format = _Format;
}
void DevILHandler::setFormat(const QByteArray & format)
{
		 if(format == "cut")
		this->I_Format = IL_CUT;
	else if(format == "dcx")
	/*
	...
	*/
	else if(format == "vst")
		this->I_Format = IL_TGA;
	else
		this->I_Format = this->I_Format = IL_TYPE_UNKNOWN;
}

Pourquoi deux implémentations ? La première permet d'utiliser directement un type DevIL. La seconde se base sur les extensions, le principe de base de Qt.

void DevILHandler::setDevice(QIODevice *device)
{
	this->Size		= device->size		();
	this->Lump		= (char *) malloc	(Size);
					  ilLoadL			(IL_TYPE_UNKNOWN, this->Lump, this->Size);
	this->Width		= ilGetInteger		(IL_IMAGE_WIDTH);
	this->Height	= ilGetInteger		(IL_IMAGE_HEIGHT);
	this->Depth		= ilGetInteger		(IL_IMAGE_DEPTH);
	this->Size_wh	= QSize				(this->Width, this->Height);
	this->Palette	= ilGetInteger		(IL_PALETTE_BASE_TYPE);
	this->NumImages = ilGetInteger		(IL_NUM_IMAGES);
	this->DurImage	= ilGetInteger		(IL_IMAGE_DURATION);
	this->Gamma		= 1.0;
	this->Data		= ilGetData();
	//Détermination du QImage::Format depuis la palette de DevIL (tout en dur)
	     if	(this->Palette == IL_RGB)
					this->Q_Format = QImage::Format_RGB32;
	else if	(this->Palette == IL_RGBA)
					this->Q_Format = QImage::Format_ARGB32;
	/*
	...
	*/
	else
					this->Q_Format = QImage::Format_Invalid;
}

On charge à partir du QIODevice tout ce dont nous avons besoin. Cette fonction est la seule qui agit avec ces QIODevice.

On récupère tous les paramètres qui nous seront importants pour la suite (dans l'ordre) : la taille (en octets), un lump, la hauteur, la largeur, la profondeur, la taille (en pixels), la palette, le nombre d'images (image animée), la durée de chaque image (image animée), le gamma (mis à 1.0, pour qu'il n'ait aucun effet), et les données, ainsi que le format.

IV-C-1. Lump et données▲

IV-C-2. Palette et format▲

bool DevILHandler::canRead()
		const
{
	if(this->device() == 0);
	{
		qWarning("DevILHandler::canRead() called with no device");
		return false;
	}

	return ilIsValidL(IL_TYPE_UNKNOWN, this->Lump, this->Size);
}

bool DevILHandler::canRead(QIODevice *device)
{
	if (!device)
	{
		qWarning("DevILHandler::canRead() called with no device or an unusable device");
		return false;
	}

	this->setDevice(device);
	
	return ilIsValidL(IL_TYPE_UNKNOWN, this->Lump, this->Size);
}

La logique est la même : on vérifie qu'un QIODevice est bien chargé (s'il est précisé, on le charge). Puis, on demande à DevIL la validité du fichier.

bool DevILHandler::read (QImage *image)
{
	this->Image = QImage (this->Size_wh, this->Q_Format);
	this->Image.fromData(this->Data, this->Size, 0);
	return true;
}

On crée un QImage avec les données dont nous disposons, puis nous y injectons les données.

bool DevILHandler::write (const QImage & image)
{
	if	(	ilSaveL(this->I_Format, this->Lump, 0)	== 0)
		return false;
	else
		return true;
}

On sauve dans le lump, tout simplement.

int DevILHandler::imageCount()
		const
{
	if(this->I_Format != IL_GIF)
		return 0;
	else
		return this->NumImages;
}

bool DevILHandler::jumpToImage(int imageNumber)
		const
{
	return false;
}

Si le format est bien animé (parmi les formats supportés par DevIL, le seul animé que je connaisse est le GIF), on renvoie la variable membre correspondante.

DevIL ne supporte pas d'aller directement à une certaine image : nous devons donc renvoyer un résultat qui sanctionne cette incapacité.

QVariant DevILHandler::option(QImageIOHandler::ImageOption option)
		const
{
		 if(option == QImageIOHandler::Size)
		return this->Size_wh;
	else if (option == QImageIOHandler::Gamma)
		return this->Gamma;
	else if (option == QImageIOHandler::Animation)
		if(this->I_Format == IL_GIF)
			return true;
		else
			return false;
	else
		return false;
}

void DevILHandler::setOption(QImageIOHandler::ImageOption option, const QVariant & value)
{
	if (option == QImageIOHandler::Gamma)
	{
		this->Gamma = value.toDouble();
		iluGammaCorrect(this->Gamma);
	}
}

bool DevILHandler::supportsOption(QImageIOHandler::ImageOption option)
		const
{
		 if(option == QImageIOHandler::Size)
		return true;
	else if (option == QImageIOHandler::Gamma)
		return true;
	else if (option == QImageIOHandler::Animation)
		return true;
	else
		return false;
}

option() renvoie le paramètre actuel de l'option en question.

setOption() met l'option à la valeur désirée. Toutes les options ne peuvent pas être modifiées (une image statique ne peut pas devenir animée, et l'inverse n'est pas beaucoup plus possible).

supportsOption() permet de vérifier si l'option est supportée.

DevIL est principalement prévu pour lire à partir de fichiers, et non de la mémoire. C'est pourquoi on peut aussi implémenter des fonctions spécialisées dans le traitement de fichiers, avec des QFile.

void DevILHandler::setDevice(QFile *device)
{
	this->fDevice	= device;
	this->fileName	= this->fDevice->fileName().toStdString().c_str();
	ilLoad			(IL_TYPE_UNKNOWN, this->fileName);
	/*
	...
	*/
}

Voici les seules lignes à commenter. Le pointeur pour le QFile ne peut pas être Device, vu qu'il est réservé aux QIODevice. On utilise donc fDevice.

La seule ligne un peu compliquée de tout le code prend l'objet sur lequel fDevice pointe, prend le nom de fichier, le convertit en std::string puis en char, type hérité du C, langage dans lequel DevIL est écrit.

Ensuite, on doit utiliser la fonction ilLoad(), qui prend en paramètre le type (inconnu) et le nom de fichier précédemment trouvé.

Ces modifications se trouvent dans toutes les autres surcharges pour QFile.

Il n'est pas prévu de base que les plugins puissent s'occuper directement des fichiers, il sont sensés passer par des QIODevice, comme les plugins de base de Qt. L'utilisation directe de fichiers par QImage sera donc limitée à ce plugin.