我知道编辑这个网站吗？

报告问题

请通过 Image.sc Forum 报告错误：

  • 在“使用和问题”类别中开始一个新主题。
  • 添加至少一个标签：imagej、imagej2、fiji以及任何其他相关标签。
  • 包括说明问题的minimal working example。
  • 如果您知道谁负责维护软件的受影响部分，请@mention他们。

或者，如果您有 GitHub 帐户，欢迎在 ImageJ、ImageJ2、Fiji 存储库中报告 GitHub 上的问题。

谢谢你！ 😁

错误报告最佳实践

错误报告是描述问题的一组可重现的步骤。它们是用户和开发人员之间的通用通信媒介。用户愿意花时间编写有用的错误报告，从而推动软件开发，让每个人都受益匪浅。

TL;DR 总结

简洁

以下是有关 writing a shorter letter 的一些快速提示：

  • 使用要点进行总结。
  • 不要内联冗长的日志；使用 Gist 或 Pastebin 代替。
  • 使用 强调 和 code snippets 等格式使文本更易于阅读。
  • 使用 link syntax 而不是依赖 URL 自动链接。
  • 对于冗长的旁白使用脚注[1]。
  • 最重要的是，提供 Minimal, Complete and Verifiable example (MCVE)，最好作为独立项目。

[1] 对于技术问题，“太多”信息当然比“太少”信息更可取。但长段落也会破坏信息流，并使原本简洁明了的错误报告或问题陷入困境。因此，肯定需要取得平衡。

为什么要花精力进行错误报告

对于轻松阅读，有大量关于 how and why to write excellent bug reports 的指南和文章。用户应该意识到开发社区是多元化的：从公共资助的个人和团队到科学家和用户贡献者。对于像这样的大型开源社区，提交错误时需要考虑几个关键点：

  • 开发开源代码的团队通常规模较小，并且缺乏专门的测试团队。因此，开发人员依靠活跃且发声的社区来提供反馈，并通过确定需要关注的领域（投诉驱动的开发）来指导开发过程。
  • 如果您遇到错误，它可能会干扰您所需的工作流程，需要快速解决。错误报告越好，开发人员重现和解决问题的速度就越快。写得不好的错误报告更有可能得不到答复，这并不是因为开发人员认为问题不重要，而是因为在排满的时间表中设置优先级时，澄清错误报告本身所需的时间构成了重大障碍。
  • 当您发现错误时，您不太可能是唯一受其影响的人。通过以开发人员能够理解、识别和解决问题的方式报告错误，您正在为整个社区提供必要且有价值的服务。

完整错误报告的组成部分

错误报告包含三个关键组成部分。如果报告缺少任何这些组件，其用处可能会受到限制。

###环境信息

ImageJ 是一个灵活且可扩展的平台，因此实际的“ImageJ 环境”可能因用户而异。 bug 报告中的一个常见错误是仅报告 ImageJ 本身的版本（例如 1.49e）。这很有帮助，但没有说明正在使用哪些插件、更新站点等。

错误可能出现在软件的任何组件中，在某些情况下，两个插件可能单独工作，但彼此之间会产生一些负面影响。因此，必须全面了解 ImageJ 环境。如果您正在运行ImageJ2，则可以使用命令Edit › Options › ImageJ2生成已安装内容的完整报告。

最少且精确的重现步骤

当我们匆忙时，很容易提供错误的简要概述，而不实际描述如何重现错误。我们还容易提供太多信息，这可能会混淆问题并阻碍彻底阅读。 错误报告的实际文本应简洁地描述重现问题的最少步骤。例如：

1) 打开示例图像“blob”

2) 运行自动阈值命令

3) 运行减去后台命令

这时，一只邪恶的海妖出现并吞没了我的硬盘。

附加信息通常是不必要的……如果开发人员可以重现问题，他们将尽力解决它。

样本数据

开发人员通常拥有示例数据的缓存来测试他们的应用程序。也就是说，我们仍在努力重现错误的原始环境。拥有导致错误的原始图像是最好的测试方法。

如果您的测试数据很小并且是公开的，您可以将其附加到错误报告中。

如果您的测试数据很大，但可以共享，请使用云服务链接（Dropbox、Google Drive 等）。

如果您的测试数据无法公开，但您愿意与开发者私下分享，请这样做。

当你在等待时…

如果您遇到并报告了完全阻碍您工作的错误，您在等待问题解决时仍然可以选择。

禁用 SCIFIO

ImageJ2提供了ImageJ图像I/O的硬编码案例逻辑的替代方案：SCIFIO，基于插件的图像I/O。虽然SCIFIO的功能更加强大，但由于整改范围之广，不可避免地还存在一些问题。如果您的数据集过去可以正确打开，但更新后损坏，请禁用Plugins › Debug › System Information对话框中的“打开文件时使用 SCIFIO（测试版！）”选项。这将恢复为 ImageJ 的经典图像 I/O，直到 SCIFIO 驱动的 I/O 得到修复或改进。

注意：即使禁用 SCIFIO 可以解决您的问题，请仍然报告发现的错误。 ImageJ 的长期愿景是完全迁移到新的图像 I/O 范例，因此如果出现问题，我们需要了解它们。

禁用有问题的更新站点

Report a Bug对话框提供了几条关键信息。其中一些最重要的是：

  • 激活的更新站点
  • 文件不是最新的

default update sites旨在相当稳定，但如果您启用了其他更新站点，则可能存在依赖关系倾斜或过时的风险（由于核心库的更改），并且某些更新站点是故意实验性的。

此外，如果您有任何 LOCAL_ONLY 或 MODIFIED 文件，则无法保证它们的行为 - 因为它们与活动更新站点上的内容不匹配，因此无法自动更新以响应其依赖项的更改。

如果很清楚哪个类或哪些类导致了问题，您可以按如下方式删除有问题的组件：

  • 如果问题出在外部插件中，只需删除文件即可。

  • 如果问题出在更新站点上：

    1. 如有必要，识别包含有问题的类的 jar，例如在斐济使用 Help › Update…。
    2. 使用Plugins › Utilities › Find Jar for Class启动更新程序 3.切换到高级模式
    3. 查找有问题的组件。此处将列出其关联的更新站点。
    4. 选择 Manage Update Sites 并禁用 4 中确定的更新站点。
    5. 重复 1-5，直到问题得到解决。

注意： 在此过程中，请务必记住，更新站点在 order they are declared 中优先 - 列表中较低的更新站点将覆盖列表中较高站点中的组件。

通过外部插件进行二分搜索

如果不清楚哪些更新站点或外部插件导致您的安装出现问题，可以使用binary search 来帮助确定问题原因的简单技术。一般程序是这样的：

  1. 从当前安装开始
  2. 删除一半的非核心更新站点和/或本地插件。
  3. 测试错误行为是否已解决。
  4. 重复 1)，仅启用“坏”更新站点/插件池。

通过这种方法，您将继续将潜在不良候选者列表减少 1/2，直到找到罪魁祸首。

注意：如果“错误行为”catastrophic 到您无法启动 ImageJ 的地步，您可以从干净的构建开始并重新引入更新站点和本地插件（如上所述），直到确定问题为止。

灾难性的失败

我们在 Downloads page 上维护生命线 ImageJ 发行版。您可以使用它们，直到解决所有未决问题。