画像

重要

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

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

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

同様の APIs は、Scala、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のいずれかを使用します。 3 つのチャンネル OpenCV タイプが BGR(A) の順序になると予想されます。

    OpenCVの型から数値へのマッピング(データ型×チャンネル数)

    タイプ

    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) と、mode フィールドで指定された型 t の配列値を持つ 3 次元配列として表されます。 配列は行優先の順序で格納されます。

画像データの表示

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

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

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

画像データソースノートブック

ノートブックを新しいタブで開く

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

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

  1. DataFrame の永続化: アクセスを容易にするために DataFrame を Delta テーブルに永続化する場合は、ディスク領域を節約するために、デコードされたデータではなく生のバイトを保持する必要があります。

  2. パーティションのシャッフル: デコードされた画像データをシャッフルすると、より多くのディスク容量とネットワーク帯域幅が必要になるため、シャッフルが遅くなります。 画像のデコードはできるだけ遅らせる必要があります。

  3. 他のデコード方法の選択: イメージ・データソースは、javaxのイメージIOライブラリを使用してイメージをデコードするため、パフォーマンスを向上させるために他のイメージ・デコード・ライブラリを選択したり、カスタマイズされたデコード・ロジックを実装したりすることはできません。

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