メインコンテンツまでスキップ

画像

important

Databricks では、 バイナリ ファイル データソースを使用して、イメージ データを生のバイトとして Spark DataFrame にロードすることをお勧めします。 画像データの処理に推奨されるワークフローについては、 画像アプリケーションのリファレンス ソリューション を参照してください。

画像データソースは、画像表現の詳細から抽象化され、画像データをロードするための標準APIを提供します。画像ファイルを読み取るには、データソース format を imageに指定します。

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

APIsScala、Java 、およびRにも同様の が存在します。

ネストされたディレクトリ構造をインポートしたり (たとえば、 /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 タイプのいずれかにマップされることが想定されます (ただし、強制されません)。 OpenCV タイプは、1、2、3、または 4 チャンネルと、ピクセル値に対していくつかのデータ型に対して定義されます。 チャンネルの順序は、色が保存される順序を指定します。 たとえば、赤、青、緑のコンポーネントを含む一般的な 3 つのチャンネル画像がある場合、6 つの順序が可能です。 ほとんどのライブラリは RGB または BGR を使用します。 OpenCVの3種類はBGR(A)順になる予定です。

    OpenCVの数値へのタイプのマップ(チャンネルのデータ型x数)

    | タイプ | C1 | C2 | C3 | C4 | |-------|--|--|--|--| | CV_8U | 0 | 8 | 16 | 24 | | CV_8S | 1 | 9 | 17 | 25 | | CV_16U | 2 | 10 | 18 | 26 | 履歴書_16S | 3 | 11 | 19 | 27 | CV_32U | 4 | 12 | 20 | 28 | CV_32S | 5 | 13 | 21 | 29 | CV_64F | 6 | 14 | 22 | 30

  • data: バイナリ形式で保存された画像データ。 イメージ データは、次元形状 (height、width、nChannels) と mode フィールドで指定されたタイプ t の配列値を持つ 3 次元配列として表されます。 配列は、行優先の順序で格納されます。

画像データの表示​

Databricks display 関数は、画像データの表示をサポートしています。 「画像」を参照してください。

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

次のノートブックは、画像ファイルに対してデータの読み取りと書き込みを行う方法を示しています。

Image データソース ノートブック

Open notebook in new tab

画像データソースの制限事項​

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

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

これらの制限は、 バイナリファイル データソースを使用して画像データをロードし、必要な場合にのみデコードすることで回避できます。

に最終更新