改进 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://wikibooks.cn/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