MINC/未來/Tconf20110223

2011 年 2 月 23 日關於 MINC 未來發展狀況的電話會議記錄

出席人員

Patrick、Jim、Mallar、Marc、Samir（來自新加坡）、John、Jason、Pierre、Alex、Mishkin、Anka、Dniel、Simon D、Simon E、Vlad 和 Louis

議題

MINC 的目標是什麼？我們的目標是什麼？

• MINC 是一種複雜、功能強大的影像檔案格式，它具有自文件、自描述、可擴充套件、可移植以及針對 n 維醫學影像的特性。MINC 具有標準 API，確保始終按照 MINC 定義讀寫檔案。
• 我們的目標是在面對競爭檔案格式和軟體包的情況下，透過簡化 MINC 庫和工具的安裝和使用，來確保 MINC（和 MINC 工具）的未來。

來自使用者 - 主要請求是簡化

• 簡單的安裝、用於程式/文件的單一聯絡點
• 最新的文件
• 示例軟體
• 示例分析
• 使用者介面

支援的軟體發行版/計算機系統

• Linux（Debian、ubuntu、redhat 等）
• Mac
• Windows

這可能會開啟一個龐大的使用者群

但會存在努力/資源問題。與 GUI 相關

• 一個包 vs 許多小包
• 許可證問題 - 可以捆綁什麼，不能捆綁什麼（MINC vs GPL 許可證）
• 測試
  • 每個版本都需要進行全面測試
  • 儀表板式測試/報告？

I/O

• 繫結到
  • R（Jason 的 RMINC 和 Jim 的更新更好的 mincIO）
  • Python（Jason 的 https://launchpad.net/pyminc）
  • Octave、Matlab（Pierre 的 NIAK）
  • C/C++
    • Vlad 的 EZminc，
    • David 的 volumeIO
    • CImg 支援 minc (http://cimg.sourceforge.net/)
• MINC1 vs MINC2 API 支援和使用
• ITK & VTK - 目前支援有限。
• NIFTI 支援？
  • 乍一看，從使用者的角度來看有很多優勢，但是…
  • 缺點
    • 以檢視器為中心的定義資料排序（放射學 vs 神經學），而在檔案頭中沒有此資訊
    • 缺乏健壯的座標系資訊
    • 缺乏強度對映資訊
    • 使用者會起來反抗我們嗎？

要連結/關聯什麼

• Neurodebian（Michael Hanke 的 neuro.debian.net）

與其他軟體工具的整合

• Osirix、ITK-snap、Elastix、ANTS

軟體開發工具

• 需求
  • 包含/整合外部開發人員（誰可以提交/我們信任誰？）
  • 適當的錯誤跟蹤

（Jim）：真實的、活動的 minc 錯誤可以確保 minc-dev 已經注意到該錯誤，並且對修復狀態有一些瞭解。也許這樣的系統可以與補償模型整合，在該模型中，修復或（已批准的）功能請求將被分配一個貨幣價值，然後開發人員可以自由地“註冊”來處理給定的請求？

• • 還沒有使用分散式版本控制系統？（git、hg、bzr 等）
  • 可能性
    • MNI（或其他地方）的 CVS 儲存庫
    • NITRC（www.nitrc.org，他們很樂意讓我們加入，他們有 git 嗎？）
    • Launchpad（launchpad.net）
    • Google 程式碼，
    • 跟蹤

文件

• https://wikibook.tw/wiki/MINC/
• https://wikibook.tw/wiki/MINC/Tutorials
• 常見問題解答
• 示例程式碼

標準發行版中沒有的 MINC 工具

• 結構分割工具
  • 大腦提取 mincBET
  • ANIMAL 結構分割（Collins）
  • 海馬體 + MTL 結構融合標記（Collins）
  • 丘腦 + 基底神經節（Mallar）
  • 側腦室分割（V.Fonov）
• 表面分割
  • CLASP（Evans）
• 分析工具
  • fMRI stat
  • NIAK（Pierre B）
  • ITK Snap（Vlad 對 minc 的修改；如果 ITK 中正確支援 minc，則不需要此修改）
  • ElastiX（Dante）
• viewnup（Andrew）
• PVE（Jossi）

行動專案

• 誰想參加
• 誰負責什麼
• 下一步是什麼
• MINC 研討會/課程