改進 MINC 的初始行動專案清單

列出可用的程式碼/程式/包

我們需要生成一個列表，列出使用 MINC 編寫的、已建立的所有軟體工具（在 BIC 或其他地方）。對於列表中的每個專案，我們需要至少知道

軟體的名稱
簡要描述軟體的功能，功能列表，引數列表
軟體的作者是誰
誰維護軟體
軟體是否公開可用？如果不是，是否可以公開？
是否有文件可用？如果有，在哪裡
軟體是否穩定，還是仍在開發中（如果是前者，它可能在大型 MINC 包中）。
軟體的依賴項是什麼
minc1/minc2 相容性

需要為所有 minc 工具建立 makefile（Vlad 有一個構建所有 makefile）
需要 makefile 來僅構建 minc 庫（Vlad makefile 的子集）

一個初始的 minc 工具列表這裡

列出可用的文件

對於每份文件，

它記錄了哪個軟體或過程
誰編寫了文件，誰維護文件
使用者文件或技術文件
文件的評級（質量控制，由專業人員稽核）

需要未來文件計劃

wiki.bic.mni.mcgill - 應該對外部開放（我認為）

我不反對使用 BIC 託管的網站來存放文件，但我更喜歡一個最“中立”的託管網站，以鼓勵其他人貢獻。 - AJ

如果我們要使用 NITRC 作為 MINC 的主要宿主，為什麼不將 NITRC wiki 用作開發人員的 wiki，用於技術內容、早期文件草稿和討論頁面，例如“MINC 的未來”？我建議 MINC wiki 書籍應該保留用於乾淨、穩定和麵向用戶的文件。順便說一句，能夠生成 PDF 也很好。 - PB

需要好的文件示例作為指導

FSL 有很好的文件

SPM 在華夏公益教科書上 - https://wikibook.tw/wiki/SPM - AJ

檢視 NIAK 的 pdf 概述 - http://www.nitrc.org/frs/downloadlink.php/2726 - PB

還有其他例子嗎？

API 文件與使用者指南

它們服務於非常不同的目的。使用者可以參與編寫使用者手冊

需要找出哪些文件已經存在
培訓/課件

第一步將是為現有的 minc 使用者和開發人員舉辦一個研討會。我自願在 6 月份 HBM 之後或之前幫助建立它（可能是在之後）。在組織真正的 minc 課程之前，我們可能需要更好的文件和一個明確的概念，即哪些軟體可以被視為 MINC 套件的一部分，但這顯然可以在不久的將來實現。 - PB

需要一個好的 MINC 前言

為什麼 MINC 值得這麼麻煩？是什麼讓它如此出色？

wiki 書籍中有兩個“介紹”和“歷史”部分。最好將它們合併。 - PB

評估 NITRC 作為 MINC 工具開發的宿主

我們需要評估 NITRC（http://www.nitrc.org）來託管 MINC 開發專案。我們需要知道

NITRC 是否使用分散式版本控制系統

是的，GIT。我已經用 mincmorph 做了一個小測試專案，效果很好。GIT 還沒有整合到他們的原始碼檢視器中，但正在計劃中。至少使用 GIT，您可以克隆到多個儲存庫。(https://github.com/andrewjanke/mincmorph)

它是否允許論壇？wiki？

是的，是的。而且 NITRC 上的 wiki 將是一個很好的地方，可以託管像這樣的討論 -AJ 同意 - PB

是否有任何許可問題？

我看不出有什麼問題。此外，對您自己包使用的許可證沒有任何限制 -AJ

它有長遠的未來嗎？

我最近參與了一個關於 NITRC 未來狀況的電話會議。他們肯定會在未來幾年記憶體在。似乎 NIH 還沒有準備好長期全面支援他們，但他們正在積極尋求替代的經濟模式（也許涉及費用或廣告）來應對未來。他們顯然非常致力於長期存在為一種資源。 - PB

與 NeuroDebian（http://neuro.debian.net）有任何問題嗎？

沒有，你會注意到那裡已經有幾個 MINC 包（N3、mni_autoreg、minc、classify？）。多年前我幫助 Michael 做過這些，我一直想重新開始，因為我自己的打包工作。我認為 neurodebian 是 minc 包裝的未來，至少對於 debian/ubuntu 來說是如此。我的計劃是使用 alien 將它們轉換為 RPM，用於那些沒有安裝發行版的使用者。（CentOS、RedHat、Fedora） - AJ

MINC 工具開發的基本策略

程式碼開發/潛在的編碼指南需求
程式碼文件
測試套件
打包
MINC1 與 MINC2 支援

跨平臺開發

要支援的平臺
- Linux（ubuntu、debian、redhat？，還有其他嗎？）
- MAC
- Windows（見下文，下一項）

我認為原生 windows 包不值得我們為之付出努力。讓核心包正常執行是可以的，但我們很快就會發現自己要重新打包 ActiveState Perl（Windows 上的 Perl）的一部分，以便使各種 perl 指令碼正常工作。還有像 grid engine 這樣的東西，這是不可能的。這裡唯一真正可行的替代方案是 Cygwin，但它的打包系統還有待改進。首先，沒有辦法使用指令碼自動執行安裝，它必須是點按式的。然後，您可以手動安裝 apt-cyg 並從那裡開始指令碼化其餘操作。其他主要軟體包的方法是建議 Windows 使用者使用虛擬機器。現在大多數 CPU 的效能都足夠強大，可以做到這一點，而且這將為我們簡化很多事情。我們還可以借鑑 neurodebian 在這方面的努力。 -AJ

如何實現跨平臺支援
- CMAKE？Cpack？

MINC 已經支援 CMAKE，我承認讓 CMakeLists.txt 和 Makefile.am/Configure.ac 並行保持最新有點麻煩，但我一直在做。 -AJ

- 有哪些選擇？

沒有。automake/CMAKE 是首選。我仍然更喜歡 automake，因為它與 deb 的整合度更高。-AJ

如果你想在任何程度上支援 Windows，CMake 是一個更好的選擇，因為你只需要維護一個 CMakeLists.txt 檔案，然後 CMake 可以生成 Visual Studio 專案檔案（以及 Mac OS X 上的 Xcode 專案）。--匿名

生成的包必須易於安裝
生成的包不能與現有軟體衝突

關於這一點，還有其他軟體包（我指的是你，freesurfer）會在安裝過程中安裝整個 minc “發行版”，並給使用者造成各種各樣的麻煩，因為它們通常包含舊版本的 MINC。我們沒有真正的方法來控制這一點。唯一的“解決方法”是在 freesurfers 的路徑後面新增 /usr/local/bic/bin。也許如果我們讓自己的安裝變得更容易，freesurfer 就會使用我們的軟體包。-AJ

評估 MINC Windows .dll 的相關性

基本 MINC API 應該在 Windows 上得到支援
我們可能沒有資源來支援 Windows
Bert 已經做過了。請參閱 MINC CVS 中的 Makefile.msvc-win32。它仍然可以在 Visual Studio 中使用，但現在 Bert 不在了，我認為我們沒有這方面的本地專業知識。（Bert 是一位前 Windows 程式設計師，我們盡我們所能幫助他）。但我仍然質疑讓 minc API 在 Windows 上執行的動機。我能想到的唯一用途是讓 Windows 檢視器能夠載入 MINC 檔案。-AJ

在 Windows 中重複使用 minc：如果我們希望 minc 作為一種檔案格式得到廣泛使用，那麼它應該很容易在各種平臺上進行互動。對於 Matlab 來說，要麼我能夠訪問 mincheader、rawtominc 和 minctoraw，要麼我直接根據 netcdf/hdf5 編寫一些程式碼，但這會引起一些關於完全符合 MINC API 的問題。

確定 CBRAIN 如何融入其中

我不能代表 Alan 說話，但我更傾向於說 MINC 應該融入 Cbrain。Cbrain 為神經影像分析提供了一個分散式平臺。基於 MINC 的管道應該在其中可用（CIVET 已經實現了，NIAK fmri 管道很快也會實現）。但 Cbrain 不限於 MINC 工具（例如 SPM 已經某種程度上整合了，也許 PLS 和 NPAIRS 也一樣，我不確定。有些人正在討論基於 FSL 的管道）。我相信 Cbrain 基礎設施可能在未來為 MINC 相關軟體的開發做出貢獻。這在很大程度上取決於為繼續支援 Cbrain 而找到的資金型別，而這一點目前尚未確定。- PB

評估 MINC API 和 MINC 工具中 NIFTI 支援的級別

我們需要評估在 MINC 環境中支援 NIFTI 檔案的利弊

要點

需要驗證/測試 nii2mnc 以確保正確支援浮點數
我們是否希望使用 MINC{1,2} API 讀取 NIFTI 檔案
nii->mnc 和 mnc->nii 的轉換不是一個嚴重的開銷；但對於一些點選式使用者來說仍然很麻煩

優點

可以為 minc 提供大量使用者
volume_io 中已經有一個存根函式可以做到這一點。

缺點

強度對映中的檔案相容性問題
空間座標對映問題
使用者如何控制其檔案中的 L-R 神經/放射對映的理解方面存在重大問題。我不希望 MINC 進入，甚至不希望 MINC 考慮進入這個充滿痛苦和咬牙切齒的世界。我已經有使用者告訴我他們“不喜歡 MINC，因為影像顯示得‘奇怪’”。即：在神經方向上。-AJ