[104][Thorlabs]tiff画像 処理ノード投入検証

[itutu-tienday]

Thoralbsシステムからexportされたtiffファイルを、suite2p, caiman で処理できるように検証・調整する。

• Input sample data

  • Thoralbs のexportデータは、標準でtiff形式となっている。

  • https://drive.google.com/drive/folders/1-f1U_jdDSm30vgoQv7OnMLfNsdIBfDdw

  • データに関する補足

  • [x] TODO：仕様確認

    • ThoralbsのRawデータに対する処理は、今回の対応対象外か？ （Thoralbsのデータ読み込み等に関する情報は、現在（12/12）時点 受領前）
    • → 要求面で、tiff形式（OME-TIFF） への対応のみでOKということを確認。

• ゴール

  • suite2p, caiman で Thoralbs tiffファイルをWorkflowへ投入し、ROI抽出まで処理成功させる

• 関連

  • 216

  • 237

  • 238

[ReiHashimoto]

提供データについて

• sample_TIFF

  • timelapse600 以下のフォーマットでA, B2つのチャンネルについて600枚ずつのデータが含まれている。
  • ChanA_001_001_001_XXX.tif
  • ChanB_001_001_001_XXX.tif

  各データは(600, 2, 512, 512)のshapeになっており、各データにも2つのチャンネル、600のframeが存在する→仕様について問い合わせ中

• Sample_RAW
  • 230725-3
  • Image_001_001.raw：おそらくsample_TIFFの生成元のデータ
  • ROIs.xaml
  • ROIMask.raw
  • Experiment.xml：メタデータ

解析可否について

• 各画像が複数チャンネルを持っているため、以下に保存したnotebookでチャンネルごとのデータを分離。
  • https://drive.google.com/drive/folders/1clz-_4ETLeaWJukcFkqAkOXAGkY3yABT
  • 分離した画像についてはcaiman, suite2p, lccdのいずれも解析が正常に動作した。
  • 分離後のデータをoutputsに保存している。
  • いずれにせよ、#172 でのハンドリングは必要になる。

[ReiHashimoto]

ドキュメント等を踏まえて調査を進めたところ、

• これらのtiffはOME-TIFF形式
• 配列のデータはどのファイルも同じ(すべてのチャンネル、frameのデータが含まれている)
  • np.array_equalでも実際に比較
• 異なるのはメタデータの部分
  • メタデータはOME-XML形式
  • 全体の配列の中でどのスライスを抽出するかの情報が含まれているため、MacOSなどのViewerでファイルを開くと対象のスライスの2次元画像のみが表示されている
  • PlaneタグのTheCがチャンネル番号、TheTがTimeSeries(frame)
  • 抽出したメタデータをドライブに追加済

そのため、workflowでの解析にあたってはいずれかのデータから配列を抽出すれば問題はない想定。

追加調査分のnotebookでの検証スクリプトを更新。

[ReiHashimoto]

• suite2pではthorlabsのraw fileをreadする方法として、hasuumeisterというライブラリを挙げている
  • https://suite2p.readthedocs.io/en/latest/inputs.html#thorlabs-raw-files
  • https://github.com/neurodroid/haussmeister/blob/master/haussmeister/thor2tiff.py
• ただし、現在PyPIにないようで、pipでのインストール不可のため、実装を参考にしてraw fileのreadを実装した方が良いかもしれない
• また、このライブラリ自体古いため、現在のthorlabsの仕様と合っていない可能性がありそう
  • https://github.com/MouseLand/suite2p/issues/740
  • 結局tiffを使うのが最善か

[itutu-tienday]

対応方針をユーザー側とすり合わせる

• [x] rawへ対応するか、またはtiffのみをサポートするか
  • → tiff形式（OME-TIFF） のみでOK.

[itutu-tienday]

thoralbsフォーマットの不明事項（OME-TIFFの仕様）について、追加確認した情報を以下記載。

• Q. seriesがフレーム毎に分割されたtiffファイル群がディレクトリ内に格納される構成は、OME-TIFFの仕様であるか？

  • A. 上記は OME-TIFF の仕様である。
  • https://docs.openmicroscopy.org/ome-model/6.3.1/ome-tiff/file-structure.html

    Single versus multiple files

• Q. seriesがフレーム毎に分割された各tiffファイル中に、seriesで共通のOME-XML(メタデータ)が格納されているが、これは想定通りの仕様であるか？（冗長ではないか？）

  • A. 上記は OME-TIFF の仕様である。
  • https://docs.openmicroscopy.org/ome-model/6.3.1/ome-tiff/specification.html#figure-tiff-header

    注記: 〜〜 複数の OME-TIFF ファイルに分散されたイメージ シーケンスの場合、各ファイルには OME-XML メタデータ ブロックのコピーが含まれます

• Q. pythonモジュール（imageioなど）で、分割された個別のtiffファイルをreadすると、各ファイルのデータ（numpy形式）が同一であるように見えるが、これはどのような挙動であるか？

  • imageio （内部でtiffflie利用？）で、分割されたOME-TIFFをreadすると、seriesとして自動認識する模様。
  • 仮にディレクトリ内にseriesのtiffファイルが欠損していた場合、以下のような例外となる。

    <tifffile.TiffFile 'ChanA_001_001_001_001.tif'> OME series failed to read 1190 files

[itutu-tienday]

Thorlabs画像投入の検証は実施済みのため、クローズする。 引き続き詳細な検証と実装は、 #286 にて実施。