在评论我的“连接的组件标签 - 第6部分”帖子，Martin Isenburg问：“设计的设计背后的理由是什么？Bwlabel.n在各个像素上工作而不是在像素的运行时？“

优秀的问题。我很高兴回答“为什么他们这样做”算法问题 - 当我知道答案时，就是这样！

总结问题：Bwlabel.通过分析像素运行的邻接关系来执行二维连接的分量标记。Bwlabel.n另一方面，分析各个像素的邻接关系。

背景：在图像处理工具箱版本3的开发周期中晚期，我们根据用户反馈的上升潮汐决定为工具箱添加多维支持。万博1manbetx这是一项工作，我们只有几个月的时间来做。组件标记位于列表中。在工具箱中存在2-D标记，但我们需要为任意维度标记添加支持。万博1manbetx

Several toolbox functions, including connected-component labeling, depended upon some definition of pixel connectivity. 2-D functions that already existed accepted 4 or 8 as connectivity definitions. For 3-D, we could add 6, 18, and 26 to the list, but what should we do for arbitrary dimensions? We decided to add to support a very broad notion of defining connectivity. Specifically, to define the desired multidimensional connectivity, you could provide a connectivity array, called骗子在文档中。骗子是一个3×3逐个 - 3-3逻辑阵列，对对称的逻辑阵列对称。这使用户能够定义他们想要的任何连接。

作为整体多维发展工作的一部分，我们已经创建了执行任意维邻邻居迭代的代码（请参阅工具箱/图像/图像/私有/邻居.cpp for细节）。通过将该代码与Union-Find技术相结合，可以快速且稳健地实现任意维度任意连接标签，而无需太多的代码。

I thought about carrying over the run-length encoding idea to multiple dimensions, but I suspected the code needed to perform arbitrary-dimension arbitrary-connectivity adjacency analysis on runs would be complicated and error-prone. I was also pretty sure that there would be cases, depending on the dimensionality, the connectivity definition, and the specific image characteristics, where doing a run-length encoding pass would be counterproductive.

所以这一切都归功于判决。基于可用时间和资源，在某些情况下，需要多维实现的长期函数列表，以及运行长度技术可能效率低下的可能性，我们决定去寻找像素明智的联盟 - 找到实现。