次の方法で共有

Image

  • [アーティクル]

重要

Databricks では、バイナリ ファイル データ ソースを使用して、イメージ データを未加工のバイトとして Spark DataFrame に読み込むことが推奨されています。 イメージ データを処理するために推奨されるワークフローについては、「イメージ アプリケーションのリファレンス ソリューション」を参照してください。

イメージ データ ソースは、イメージ表現の詳細から抽象化され、イメージ データを読み込む標準的な API を提供します。 イメージ ファイルを読み取る場合は、データ ソース format を image として指定します。

df = spark.read.format("image").load("<path-to-image-data>")

Scala、Java、R にも同様の API が存在します。

入れ子になったディレクトリ構造をインポートできます (たとえば、/path/to/dir/ のようなパスを使用します)。また、パーティション ディレクトリ (つまり /path/to/dir/date=2018-01-02/category=automobile のようなパス) でパスを指定することで、パーティション検出を使用できます。

イメージ構造

イメージ ファイルは、次のフィールドで image と呼ばれる 1 つの構造体型の列を含む DataFrame として読み込まれます。

image: struct containing all the image data
  |-- origin: string representing the source URI
  |-- height: integer, image height in pixels
  |-- width: integer, image width in pixels
  |-- nChannels
  |-- mode
  |-- data

フィールドは次のとおりです。

  • nChannels: カラー チャネルの数。 一般的な値は、グレースケール イメージの場合は 1、色付きイメージ (RGB など) の場合は 3、アルファ チャネルを持つ色付きイメージの場合は 4 です。

  • mode: データ フィールドの解釈方法を示す整数フラグ。 データの種類と、データが格納されているチャネルの順序を指定します。 フィールドの値は、次の表に示す OpenCV 型の 1 つにマップすることが期待されています (ただし、強制ではありません)。 OpenCV 型は、1、2、3、または 4 チャネル用に定義され、ピクセル値にはいくつかのデータ型が定義されます。 チャネルの順序は、色が格納される順序を指定します。 たとえば、赤、青、緑のコンポーネントを含む一般的な 3 つのチャネル イメージがある場合、6 つの順序が可能です。 ほとんどのライブラリでは、RGB または BGR のいずれかを使用します。 3 (4) つのチャネルの OpenCV 型は、BGR(A) の順序であることが期待されます。

    OpenCV における型の数値へのマップ (データ型 x チャネル数)

    Type C1 C2 C3 C4
    CV_8U 0 8 16 24
    CV_8S 1 9 17 25
    CV_16U 2 10 18 26
    CV_16S 3 11 19 27
    CV_32U 4 12 20 28
    CV_32S 5 13 21 29
    CV_64F 6 14 22 30

  • data: バイナリ形式で格納されたイメージ データ。 イメージ データは、ディメンションの形状 (高さ、幅、nChannels) と、モード フィールドで指定された t 型の配列値を持つ 3 次元配列として表されます。 この配列は、行優先順で格納されます。

イメージ データの表示

Databricks display 関数では、イメージ データの表示がサポートされています。 「イメージ」を参照してください。

ノートブックの例: 画像ファイルへのデータの読み取りと書き込み

次のノートブックは、イメージ ファイルとの間でデータを読み書きする方法を示しています。

イメージ データ ソース ノートブック

ノートブックを入手

イメージ データ ソースの制限事項

イメージ データ ソースは、Spark DataFrame の作成時にイメージ ファイルをデコードし、データ サイズを増やし、次のシナリオで制限事項を導入します。

  1. DataFrame の永続化: アクセスを容易にするために DataFrame を Delta テーブルに保持する場合は、デコードされたデータの代わりに未加工のバイトを保持してディスク領域を節約する必要があります。
  2. パーティションのシャッフル: デコードされたイメージ データをシャッフルすると、ディスク領域とネットワーク帯域幅が増え、その結果、シャッフルが遅くなります。 可能な限り、イメージのデコードを遅らせる必要があります。
  3. その他のデコード方法の選択: イメージ データ ソースでは、javax の Image IO ライブラリを使用してイメージをデコードします。このライブラリを使用すると、パフォーマンスを向上させる他のイメージ デコード ライブラリを選択したり、カスタマイズされたデコード ロジックを実装したりできません。

これらの制限は、バイナリ ファイル データ ソースを使用してイメージ データを読み込み、必要に応じてのみデコードすることで回避できます。