メタデータクエリ言語の概要

[アーティクル]
06/13/2023

このトピックでは、Windows Imaging Component (WIC) のメタデータクエリ言語について説明します。メタデータクエリ言語を使用して、画像のメタデータ内の特定のデータ (メタデータ項目) と場所 (メタデータブロック) を検索する式を作成します。

このトピックは、次のセクションで構成されています。

前提条件
はじめに
パス式の構造
写真メタデータポリシー式
メタデータクエリ言語の概要
関連トピック

前提条件

このトピックを理解するには、「イメージメタデータの読み取りと書き込みの概要」で説明されているように、WIC メタデータの概要とメタデータへのアクセスに関するページで説明されているように、WIC メタデータシステムについて理解している必要があります。

はじめに

メタデータプラットフォームは、主に 2 つのコンポーネントオブジェクトモデル (COM) コンポーネント ( IWICMetadataQueryReader インターフェイスで表されるクエリリーダー)、および IWICMetadataQueryWriter インターフェイスで表されるクエリライターを使用して操作します。これらのコンポーネントを使用すると、メタデータクエリ言語を使用してメタデータの読み取りまたは書き込みを行うことができます。クエリ言語はパス式の構文を記述し、クエリコンポーネントはこのパス式を使用して目的のメタデータにアクセスします。このパス式は、メタデータブロックまたはアイテムの場所を表します。

メタデータブロックは、特定の形式のメタデータの名前付きグループです。メタデータブロックには、作成者や作成時刻などの個々のメタデータ項目と追加のメタデータブロックを含めることができます。メタデータブロックの名前は、その形式によって決まります。たとえば、App1 メタデータを含むメタデータブロックには"app1" という名前が付けられます。一般的なメタデータ形式には、App1、Exif、IFD、XMP があります。

メタデータ項目は、作成者、タイトル、評価などの特性を記述する名前と値のペアです。

パス式には、1 つ以上のメタデータブロック名が含まれています。また、メタデータブロック内でメタデータ項目を指定することもできます。次のパス式は、メタデータ項目を含む IFD ブロックを含む App1 ブロックを表します。

/app1/ifd/{ushort=18249}

次の図は、4 つのルートメタデータブロック (App0、App1、XMP、不明なブロック) を含む JPEG 画像の例の構成を示しています。強調表示されている各アイテムは、メタデータの種類 (ブロックまたは項目) と、データの取得に使用されるクエリ式をメモします。

メタデータ吹き出し付きの jpeg 画像

注意

この図の内容は、このドキュメント全体で参照されており、多くの例で使用されています。

パス式の構造

WIC API を使用してメタデータにアクセスするには、ほとんどの場合、完全修飾クエリ式を使用する必要があります。このトピックでは、メタデータにアクセスするための完全修飾式について説明します。完全修飾以外の式が使用されるケースに関する情報が必要な場合は、このドキュメントで後述する写真メタデータポリシー式に関するセクションを参照してください。

完全修飾クエリ式とは WIC では、完全修飾式は、パス文字スラッシュ (/) で始まり、その後にメタデータブロックまたは特定のメタデータ項目へのナビゲーションパスが続く文字列です。ナビゲーションパス内の各ステップはスラッシュで区切られ、メタデータブロックまたはメタデータ項目にアクセスするための式が形成されます。たとえば、App1 ブロックに入れ子になっている IFD ブロックの Microsoft Photo Rating にアクセスする完全修飾クエリ式を次に示します。

/app1/ifd/{ushort=18249}

WIC は、この式を解析するときに、まず画像のメタデータ内で App1 メタデータブロックを検索します。 App1 ブロックが見つかった場合は、入れ子になった IFD メタデータブロックを探して検索を続行します。 IFD ブロックが見つかった場合は、特定のメタデータ項目 (この場合はタグ 18249 の下の MicrosoftPhoto 評価) を IFD メタデータブロック内で検索します。 WIC がメタデータブロックまたはアイテムを見つけられない場合は、クエリを中止します。

ブロック選択

最も簡単な WIC メタデータクエリ式は、特定のメタデータブロックのクエリリーダー/ライターを取得する式です。クエリリーダー/ライターを取得すると、親ブロックを処理せずに、後続のクエリを入れ子になったメタデータブロックに直接送信できます。ブロック選択クエリ式は、目的のメタデータブロックへのナビゲーションパスです。たとえば、前の図には 5 つのメタデータブロックがあり、そのうちの 2 つのメタデータブロックは他のメタデータブロックに入れ子にされています。 JPEG の例の各メタデータブロックへのパス式を次に示します。

/app0
/app1
/app1/ifd
/app1/ifd/exif
/Xmp

クエリリーダー/ライターを使用してクエリを実行すると、指定されたメタデータブロックのスコープ内でクエリを処理する新しいクエリリーダー/ライターが返されます。たとえば、クエリ "/app1" を実行すると、新しいクエリリーダーが取得され、新しいリーダーに対するクエリは App1 ブロックに対して相対的になります。これは、App1 ブロックに IFD ブロックが含まれているため、クエリ "/ifd" が新しいリーダーに対して有効であることを意味します。ただし、この App1 ブロックには XMP メタデータブロックが含まれていないため、"/xmp" は機能しません。

クエリ言語では、インデックス表記もサポートされています。インデックス表記では、同じ型の複数のブロックが存在する場合に、特定のメタデータブロックにアクセスできます。 JPEG の例では、次のインデックス付きパス式を使用できます。

/[0]app1/[0]ifd

クエリ言語では、すべてのインデックスは 0 から始まります。前の式では、最初の App1 ブロックに対して最初の 0 個のクエリが実行され、2 番目のゼロが最初の入れ子になった IFD ブロックに対してクエリを実行します。同じ型の複数のブロックが存在しない場合でも、インデックス表記を使用できます。 JPEG の例に、埋め込み IFD ブロックを含む 2 つ目の App1 ブロックが含まれている場合は、式 "/[1]app1/ifd" を使用して 2 つ目の App1 ブロックにアクセスします。

PNG イメージに複数の tEXt チャンクが含まれる可能性が高いため、PNG tEXt チャンクを処理する場合、インデックス表記がより一般的になります。

注意

多次元配列インデックスはサポートされていません。

項目の選択

ブロック選択式に基づいて構築することで、メタデータブロック内のメタデータ項目にアクセスできます。 JPEG の例の XMP と Microsoft Photo の評価プロパティについて考えてみましょう。このメタデータは、App1/IFD ブロックと XMP ブロックの 2 つのメタデータブロックに存在します。そのため、複数の式を使用して同じデータにアクセスできます。次の式は、XMP ブロックの MicrosoftPhoto 評価にアクセスします。

/xmp/xmp:Rating

式の "xmp:" 部分はスキーマフレンドリ識別子です。 XMP は拡張可能な標準であり、サードパーティのエンティティが特定のメタデータ項目を格納する方法を定義する独自のスキーマを公開できるようにします。 XMP スキーマは URL によって完全に識別されますが、WIC には既知のスキーマのフレンドリ識別子のセットが用意されています。詳細については、「ネイティブイメージ形式のメタデータクエリ」トピックを参照してください。

JPEG 画像の場合は、App1 の入れ子になった IFD ブロック内に評価情報を格納することもできます。ただし、XMP 評価の例とは異なり、IFD ブロックはスキーマ名を使用して評価情報にアクセスしません。代わりにデータ式を使用します。次の式は、App1 の入れ子になった IFD ブロック内の MicrosoftPhoto 評価にアクセスするために使用されます。

/app1/ifd/{ushort=18249}

この式では、式の "/app1/ifd" 部分が IFD ブロックへのナビゲーションパスです (前述の「ブロックの選択」セクションで説明したように)。式 "/{ushort=18249}" の 2 番目の部分は、データにアクセスします。式のこの部分は、タグ識別子 18249 を持つ符号なし短いタグに埋め込まれているデータを検索するようにクエリパーサーに指示します。

注意

各イメージ形式でサポートされている一般的なメタデータ形式の一覧については、「ネイティブイメージ形式メタデータクエリ」トピックを参照してください。

{ushort=18249} はデータ式であり、いくつかの形式を取ることができます。データ式は、要求されたメタデータタグまたはキー (この場合は "18249") とキーのデータ型 (この場合は "ushort") を含む 2 つの部分式です。 2 つの部分は等号 (=) で区切ります。 WICsupports は、一般的な C/C++ データ型の大部分をサポートします。クエリ言語では、次のデータ型が受け入れられます。

char
uchar
short
ushort
long
ulong
INT
uint
longlong
float
double
str
wstr
guid
bool

注意

この一覧では、メタデータクエリ言語でサポートされているデータ型のみを指定します。 {ushort=18249} などのメタデータクエリデータ式を作成するときは、これらのデータ型を使用します。 WIC は、独自の型システムを定義する PROPVARIANT の形式でメタデータ項目の値を返します。

この例の "18249" はデータタグです。この特定の番号は、MicrosoftPhoto の評価を含めるために Microsoft によって定義されます。データタグには、探しているデータ項目に応じて、任意の数値、文字列、または GUID を指定できます。

XMP 評価の例とは異なり、App1/IFD ブロックの評価値に対する名前の競合はありません。これは、XMP の評価値が実際には別の ushort タグ (18246) の下に格納されるためです。したがって、App1/IFD ブロックの XMP 評価にアクセスする式は次のとおりです。

/app1/ifd/{ushort=18246}

注意

メタデータクエリ言語の正式な説明については、このドキュメントの後半の「メタデータクエリ言語の概要」セクションを参照してください。

Escape Character

クエリ言語では大文字と小文字は区別されず、すべての文字が小文字として扱われます。ただし、一部のメタデータ形式 (XMP など) では大文字と小文字が区別されます。大文字と小文字を区別するメタデータ形式を使用する場合は、大文字を指定するときに円記号 (\) 文字を使用します。

エスケープ文字は言語パーサーによって使用され、その後に続く次の文字が直接解釈されます。たとえば、式 {char=\\} は '\' として解決され、{char=\C} は大文字の C として解決されます。エスケープ文字がない場合、{char=\} は無効な式になり、{char=C} は小文字の c として解釈されます。大文字と小文字が区別されるメタデータ形式のすべての大文字の前には、必ず円記号エスケープ文字を使用してください。

式のサンプル

次の表に、クエリ言語パーサーによる式の例と解釈の説明を示します。

式	説明
ifd/xmp/exif:Author	次のナビゲーションパスに対応します。 IFD ブロック -> XMP ブロック -> "Exif" スキーマの "Author" プロパティ。
/[1]ifd/[0]xmp/exif:Author	このテーブルの最初の項目と同じですが、[#] プレフィックスには、名前の競合が発生した場合に移動する項目が記述されています。
/ifd/{ushort=700}/Author	このテーブルの最初の項目と同じですが、ブロック名 "xmp" ではなく、データ式を使用して XMP ブロックを参照します (XMP ブロックは、符号なし短いタグ識別子 700 の下に埋め込まれます)。また、"Author" プロパティはスキーマを指定しません。クエリパーサーは、すべてのスキーマでプロパティの照合を試み、最初の一致を返します。
/ifd/xmp	メタデータブロックへのナビゲーションパスを提供します。ブロックが見つかった場合は、新しいメタデータリーダー/ライターが返されます。
/[*]tEXt/Keyword	PNG チャンクの Keyword プロパティを取得または設定します。 PNG メタデータ仕様では特定の型の複数のチャンクが許可されるため、[*] 表記は適切なプロパティを持つデータ PNG チャンクを取得/設定します。 PNG 仕様に従って、同じプロパティを持つチャンクを 2 つ指定することはできません。

また、各メタデータブロックは、フレンドリブロック名の代わりに使用できるメタデータ GUID によって一意に識別されます。ブロック名を指定する代わりに、次の構文を使用できます: "/{guid=GUID}/[n]{guid=GUID}/schema:tagidentifier"

次の表に、無効な例と、それらが拒否される理由を示します。

式が無効です	却下の説明
/ifd/[0][2]exif/	多次元配列インデックスはサポートされていないため、拒否されます。
/ifd/{ushort=1}/{ushort=2}	IFD に tagID=2 を持つメタデータ項目を含むメタデータハンドラーである tagID=1 がない限り、拒否されます。
/{ushort=1}	クエリ処理がメタデータ階層の最上位レベルに対して相対的な場合は拒否されます。これは、最上位レベルにはメタデータブロックのみが含まれており、データ項目は含まれていないためです。

写真メタデータポリシー式

前述のように、完全修飾クエリ式はスラッシュ (/) で始まります。スラッシュで始まっていない式は、ポリシー式として評価されます。ポリシー式を使用すると、画像関連の Windows シェルプロパティの写真メタデータに対してクエリを実行できます。このドキュメントの前の「データ選択」セクションでは、式 "/xmp/xmp:Rating" を使用して XMP 評価プロパティにアクセスしました。このプロパティは、次のポリシー式を使用してクエリを実行することもできます。

System.SimpleRating

MicrosoftPhoto スキーマから rating プロパティにアクセスするには、次のクエリ式を使用できます。

System.Rating

写真メタデータポリシー式は、いくつかの注目すべき方法で、完全修飾メタデータクエリとは異なる動作をします。

まず、ポリシー式を使用してメタデータにアクセスする場合、WIC は、同じプロパティが複数のメタデータブロックで使用できる場合に、調停と競合の解決を実行します。たとえば、MicrosoftPhoto と XMP の両方の評価値は、App1/IFD ブロックと XMP ブロックの両方に格納されます。写真メタデータポリシーは、メタデータの読み取り時に返されるブロック値の優先順位を決定します。メタデータを記述する場合、写真メタデータポリシーによって、異なるブロック内の同じプロパティの一貫性が確保されます。 "/xmp/xmp:Rating" などのメタデータクエリを使用する場合は、さまざまなメタデータの場所間で仲裁を行う必要があります。

注意

サポートされているポリシー式とそのマッピングポリシーの一覧については、「 Photo Metadata Policies」トピックを参照してください。

2 つ目は、写真メタデータポリシー式はイメージ形式に依存しませんが、完全修飾メタデータクエリは独立しています。たとえば、"/xmp/xmp:Rating" クエリは JPEG 形式に固有です。 TIFF イメージでは XMP メタデータもサポートされていますが、JPEG とは異なる方法で格納されるため、TIFF クエリは "/ifd/xmp/xmp:Rating" になります。ただし、どちらの場合も、ポリシー式は "System.SimpleRating" になります。

写真メタデータポリシー式は、完全修飾メタデータクエリと比較して、より高いレベルの抽象化とシンプルさを提供するため、低レベルのメタデータアクセスが必要ない場合に推奨する必要があります。ただし、ポリシー式は限られた一連の画像メタデータへのアクセスのみを提供しますが、メタデータクエリ言語では、イメージファイル内に格納されているほぼすべてのメタデータにアクセスできます。