Compression de blocs
À compter de Windows 8.1, Direct2D prend en charge plusieurs formats de pixels compressés par bloc. En outre, Windows 8.1 contient un nouveau codec DDS wic (Windows Imaging Component) pour permettre le chargement et le stockage d’images compressées par bloc au format de fichier DDS. La compression de blocs est une technique permettant de réduire la quantité de mémoire graphique consommée par le contenu bitmap. En utilisant la compression de bloc, votre application peut réduire la consommation de mémoire et les temps de chargement pour les mêmes images de résolution. Ou, votre application peut utiliser des images de résolution plus ou plus élevée tout en consommant toujours la même empreinte mémoire GPU.
La compression de blocs a été utilisée par les applications Direct3D depuis longtemps, et avec Windows 8.1 est également disponible pour les développeurs d’applications standard et Direct2D.
Cette rubrique décrit le fonctionnement de la compression de blocs et comment l’utiliser dans WIC et Direct2D.
À propos de la compression de blocs
La compression de bloc (BC) fait référence à une classe de techniques de compression permettant de réduire les tailles de texture. Direct3D 11 prend en charge jusqu’à 7 formats BC différents selon le niveau de fonctionnalité. Dans Windows 8.1 Direct2D introduit la prise en charge des formats BC1, BC2 et BC3 qui sont disponibles dans tous les niveaux de fonctionnalités.
Fonctionnement de la compression de blocs
Les formats compressés par bloc utilisent tous la même technique de base pour réduire l’espace consommé par les données de couleur. Cette section résume l’algorithme le plus simple, BC1. Pour obtenir une explication plus détaillée, consultez Compression de bloc.
Tout d’abord, l’image est divisée en blocs de 4 par 4 pixels. Chaque bloc est compressé séparément.
Notes
Cela signifie que la largeur et la hauteur d’une image doivent chacune être un multiple de 4 pixels pour qu’elle soit compressée par bloc.
Cet exemple d’image montre un bloc de pixels 4x4 dans une image.
Ensuite, dans un bloc 4 par 4, deux couleurs « référence » sont sélectionnées et sont encodées sous la forme de deux valeurs de 16 bits (5 bits rouge, 6 bits vert, 5 bits bleu). Le choix de ces couleurs affecte considérablement la qualité de l’image et n’est pas dérivé. Deux couleurs intermédiaires sont calculées en interpolant linéairement entre les deux couleurs de référence dans l’espace de couleurs RVB. Cela produit un total de 4 couleurs différentes possibles ; une valeur d’index de deux bits est affectée à chaque couleur. Toutefois, notez que seules les deux couleurs de point de terminaison doivent être stockées lorsque l’interpolation est fixe.
Dans cette figure, les couleurs 0 et 3 sont sélectionnées comme couleurs de « référence » pour le bloc, tandis que les couleurs 1 et 2 sont calculées à l’aide d’une interpolation linéaire.
Enfin, chaque pixel du bloc est mappé à l’une des quatre couleurs calculées précédemment, et chaque pixel est encodé à l’aide de la valeur d’index de deux bits.
La quantité totale de données utilisée pour représenter ces 16 pixels est la suivante :
16 bits [to define a reference color] * 2 + 2 bits * 16 [number of pixels] = 64 bits
Il en résulte une densité moyenne de 4 bits par pixel. À titre de comparaison, le format de pixels DXGI_FORMAT_B8G8R8A8_UNORM courant consomme 32 bits par pixel.
Ce diagramme montre que chaque pixel est encodé sous la forme d’un index 2 bits. Le bloc entier est encodé en 64 bits.
Il existe des variantes pour prendre en charge les données alpha et un nombre variable de canaux de couleurs. BC6H et BC7 utilisent des algorithmes considérablement différents afin de prendre en charge le contenu HDR (High Dynamic Range) et d’améliorer la qualité de l’image, respectivement.
Format de fichier DirectDraw Surface (DDS)
Les données compressées par bloc sont généralement stockées dans des fichiers DirectDraw Surface (DDS). Vous êtes peut-être familiarisé avec les fichiers DDS si vous êtes développeur Direct3D. Notez que Direct2D prend uniquement en charge certaines fonctionnalités DDS ; Pour plus d’informations, consultez Configuration requise pour DDS.
Avantages de la compression de blocs
Les formats compressés par blocs diffèrent des formats courants de compression d’images du secteur, tels que JPEG, dans la mesure où les formats BC sont pris en charge en mode natif par les GPU modernes. Cela signifie que vous pouvez charger directement une image compressée par bloc sur le GPU sans décodage ni décompression. Les formats BC consomment de 4 à 8 bits par pixel en moyenne ; par rapport à une image bitmap BGRA non compressée classique de 32 bits par pixel, cela entraîne des économies de mémoire de 75 % à 87,5 %. En outre, comme il n’existe aucune étape de décodage, le temps de chargement d’une image BC est considérablement réduit par rapport aux formats tels que JPEG.
Quand utiliser la compression de blocs
Vous devez envisager d’utiliser des images compressées par blocs dans votre application à la place d’autres formats tels que JPEG si vous souhaitez réduire la consommation de mémoire des bitmaps ou réduire les temps de décodage et de chargement.
Toutefois, la compression de bloc n’est pas appropriée pour tous les cas et nécessite des compromis. Tout d’abord, les algorithmes de compression de bloc sont avec perte. La compression de blocs fonctionne bien avec le contenu photographique naturel, mais peut introduire des artefacts visuels indésirables dans des images avec des limites de contraste élevées et nettes, telles que des captures d’écran générées par ordinateur. Vous devez vous assurer que vos ressources d’image compressées par bloc ont une qualité d’image acceptable avant de les utiliser.
Deuxièmement, les fichiers DDS compressés par bloc consomment généralement plus d’espace sur le disque que les images JPEG comparables. Cela augmentera à son tour la taille du package de votre application et les besoins en bande passante réseau.
Utilisation de la compression de blocs
Cette section explique comment générer et utiliser des ressources compressées par bloc dans une application Direct2D.
Vue d’ensemble
Les fichiers DDS compressés par blocs sont un format optimisé pour le runtime, ce qui signifie qu’ils sont spécifiquement optimisés pour de bonnes performances au moment de l’exécution de l’application. Nous vous recommandons de continuer à utiliser votre pipeline de création et d’édition de ressources existants et de les convertir en format compressé par bloc uniquement lorsque vous les importez dans votre projet d’application ou au moment de la génération.
Conditions requises pour DDS
Le format de fichier DDS a été conçu pour prendre en charge un large éventail de fonctionnalités utilisées dans Direct3D. Direct2D utilise uniquement un sous-ensemble de ces fonctionnalités. Par conséquent, lorsque vous créez des images DDS à utiliser avec Direct2D, vous devez garder à l’esprit les restrictions suivantes :
- Seules les valeurs DXGI_FORMAT suivantes sont autorisées :
- DXGI_FORMAT_BC1_UNORM
- DXGI_FORMAT_BC2_UNORM
- DXGI_FORMAT_BC3_UNORM
- Les données alpha prémultipliées doivent être utilisées. Cela inclut les fichiers DDS hérités qui utilisent des formats qui définissent explicitement l’alpha prémultiplié (DXT1, DXT2, DXT4), ainsi que les fichiers DDS qui utilisent la structure DDS_HEADER_DX10 avec les valeurs DDS_ALPHA_MODE_OPAQUE et DDS_ALPHA_MODE_PREMULTIPLIED.
- Les dimensions X et Y doivent être des multiples de 4 pixels.
- Les textures de volume, les cubemaps, les mipmaps ou les tableaux de textures ne sont pas autorisés. Vous ne devez utiliser que des images sources à image unique.
Génération de ressources compressées par bloc
Il existe un large éventail d’outils de création DDS disponibles pour créer ou convertir des fichiers DDS compressés par bloc. Notez que tous les outils ne prennent pas en charge la configuration requise pour l’utilisation de fichiers DDS avec Direct2D, comme indiqué dans la section précédente.
À compter de Visual Studio 2013, vous pouvez faire en sorte que Visual Studio convertissent les ressources visuelles existantes, telles que JPEG et PNG, au format compressé de bloc DDS correct dans le cadre de votre processus de génération. Pour ce faire, utilisez l’étape de génération personnalisée de la tâche de contenu d’image.
Pour plus d’informations sur la configuration de ce paramètre pour votre projet, consultez Guide pratique pour exporter une texture à utiliser avec Des applications Direct2D ou Javascipt.
API Direct2D
Direct2D est mis à jour dans Windows 8.1 pour prendre en charge les formats de pixels suivants :
- DXGI_FORMAT_BC1_UNORM
- DXGI_FORMAT_BC2_UNORM
- DXGI_FORMAT_BC3_UNORM
Pour les formats précédents, vous devez utiliser l’alpha prémultipliée. En outre, ces formats ne sont valides qu’en tant que source, et non en tant que cible. Par exemple, cela signifie que vous pouvez créer une bitmap Direct2D à l’aide de BC1, mais pas d’un contexte d’appareil.
Les méthodes suivantes sont mises à jour dans Windows 8.1 pour prendre en charge les formats BC :
- ID2D1DeviceContext::IsDxgiFormatSupported
- ID2D1DeviceContext::CreateBitmap
- ID2D1DeviceContext::CreateBitmapFromDxgiSurface
- ID2D1RenderTarget::CreateSharedBitmap
- ID2D1RenderTarget::CreateBitmapFromWicBitmap
- ID2D1Bitmap::CopyFromMemory
- ID2D1Bitmap::CopyFromBitmap
- ID2D1Bitmap1::GetSurface
Notez que CreateBitmapFromWicBitmap prend IWICBitmapSource comme interface ; Toutefois, dans Windows 8.1 WIC ne prend pas en charge l’obtention de données compressées par bloc à partir d’IWICBitmapSource, et il n’existe aucun format de pixel WIC correspondant à DXGI_FORMAT_BC1_UNORM, etc. Au lieu de cela, CreateBitmapFromWicBitmap détermine si IWICBitmapSource est un IWICBitmapFrameDecode DDS valide et charge directement les données compressées en bloc. Vous pouvez spécifier explicitement le format de pixel dans le struct D2D1_BITMAP_PROPERTIES1 ou autoriser Direct2D à déterminer automatiquement le format correct.
API du composant d’acquisition d’images Windows
Le composant d’acquisition d’images Windows (WIC) ajoute un nouveau codec DDS dans Windows 8.1. En outre, il ajoute de nouvelles interfaces qui prennent en charge l’accès aux données spécifiques à DDS, y compris les données de pixels compressés de bloc :
Bloquer les formats de pixels WIC compressés
Il n’existe pas de nouveaux formats de pixels compressés de bloc WIC dans Windows 8.1. Au lieu de cela, si vous obtenez un IWICBitmapFrameDecode à partir du décodeur DDS et que vous appelez CopyPixels, vous recevrez des pixels non compressés standard tels que WICPixelFormat32bppPBGRA. Vous pouvez utiliser IWICDdsFrameDecode::CopyBlocks pour obtenir les données compressées de bloc brut sous la forme d’une mémoire tampon à partir d’un fichier DDS.
Accès DDS multi-images
Le format de fichier DDS permet de stocker plusieurs images associées dans un seul fichier. Par exemple, un fichier DDS peut contenir un cubemap, une texture de volume ou un tableau de textures, qui peuvent tous être appliqués par mipmapping. Dans Direct3D, ces images multiples sont exposées en tant que sous-ressources. Dans WIC, plusieurs images sont exposées sous forme de trames (IWICBitmapFrameDecode et IWICBitmapFrameEncode).
WIC prend uniquement en charge la notion d’un tableau d’images à une seule dimension, tandis que DDS prend en charge trois dimensions indépendantes (bien que seules deux peuvent être utilisées dans un seul fichier). WIC fournit des méthodes pratiques pour faciliter le mappage entre une sous-ressource DDS et une trame WIC. Pour le décodage, IWICDdsDecoder::GetFrame vous permet de spécifier l’index de tableau, le niveau mip et l’index de tranche de la sous-ressource, et retourne le frame WIC correct.
Pour l’encodage, IWICDdsEncoder::CreateNewFrame calcule l’index de tableau, le niveau mip et l’index de tranche résultants lorsque vous créez une trame. Vous devez d’abord avoir appelé IWICDdsEncoder::SetParameters pour définir les paramètres de fichier spécifiques à DDS.
Rubriques connexes