Skip to main content

Connected components on 2D and 3D images. Supports multiple labels.

Project description

Build Status PyPI version DOI

cc3d: Connected Components on Multilabel 3D Images

Binary and multilabel connected components. (a) A binary image (foreground white,  background black) (b) 4-connected CCL of binary image (c) 8-connected CCL of binary image (d) A multilabel image (e) 4-connected CCL of multilabel image (f) 8-connected CCL of multilabel image
Fig. 1. Binary and Multilabel Connected Components Labeling (CCL) 2D images are shown for simplicity. (a) A binary image (foreground white, background black) (b) 4-connected CCL of binary image (c) 8-connected CCL of binary image (d) A multilabel image (e) 4-connected CCL of multilabel image (f) 8-connected CCL of multilabel image

Continuous value connected components (top) A three tone grayscale image with signed additive low magnitude noise (bottom) Extracted components using continuous value CCL with a delta value greater than the noise magnitude but smaller than the difference between tones
Fig. 2. Continuous Value Connected Components Labeling (CCL) (top) A three tone grayscale image with signed additive low magnitude noise (bottom) Extracted components using continuous value CCL with a delta value greater than the noise magnitude but smaller than the difference between tones

cc3d is an implementation of connected components in three dimensions using a 26, 18, or 6-connected neighborhood in 3D or 4 and 8-connected in 2D. This package uses a 3D variant of the two pass method by Rosenfeld and Pflatz augmented with Union-Find and a decision tree based on the 2D 8-connected work of Wu, Otoo, and Suzuki. This implementation is compatible with images containing many different labels, not just binary images. It also supports continuously valued images such as grayscale microscope images with an algorithm that joins together nearby values.

I wrote this package because I was working on densely labeled 3D biomedical images of brain tissue (e.g. 512x512x512 voxels). Other off the shelf implementations I reviewed were limited to binary images. This rendered these other packages too slow for my use case as it required masking each label and running the connected components algorithm once each time. For reference, there are often between hundreds to thousands of labels in a given volume. The benefit of this package is that it labels all connected components in one shot, improving performance by one or more orders of magnitude.

In general, binary images are much more common (usually resulting from image thresholding), but multi-label images crop up in instance segmentation and semantic labeling as a classifier may label touching clusters of adjacent pixels differently. If a gap between different labels is guaranteed, then the problem degenerates into the binary version.

Check out benchmarks to see a comparison with SciPy on a few different tasks.

Python pip Installaction

If compatible binaries are available for your platform, installation is particularly simple.

pip install connected-components-3d

If compatible binaries are not available, you can install from source as follows.

Requires a C++ compiler.

pip install numpy
pip install connected-components-3d --no-binary :all:

Occasionally, you may appear to successfully install cc3d, but on import you'll see an error that includes: numpy.ufunc size changed, may indicate binary incompatibility. You can either try upgrading numpy or compiling cc3d from source in this case.

Python Manual Installation

Requires a C++ compiler.

pip install -r requirements.txt
python setup.py develop

Python Use

The following functions are available with examples below:

  • Connected Component Labeling (CCL)
  • Removal of small objects ("dust")
  • Extraction of k largest objects
  • Fast extraction of all objects one-by-one
  • Calculation of contact surface area and contact network
  • Extraction of a per voxel connectivity graph
import cc3d
import numpy as np

labels_in = np.ones((512, 512, 512), dtype=np.int32)
labels_out = cc3d.connected_components(labels_in) # 26-connected

connectivity = 6 # only 4,8 (2D) and 26, 18, and 6 (3D) are allowed
labels_out = cc3d.connected_components(labels_in, connectivity=connectivity)

# If you need a particular dtype you can specify np.uint16, np.uint32, or np.uint64
# You can go bigger, not smaller, than the default which is selected
# to be the smallest that can be safely used. This can save you the copy
# operation needed by labels_out.astype(...).
labels_out = cc3d.connected_components(labels_in, out_dtype=np.uint64)

# If you're working with continuously valued images like microscopy
# images you can use cc3d to perform a very rough segmentation. 
# If delta = 0, standard high speed processing. If delta > 0, then
# neighbor voxel values <= delta are considered the same component.
# The algorithm can be 2-10x slower though. Zero is considered
# background and will not join to any other voxel.
labels_out = cc3d.connected_components(labels_in, delta=10)

# If you're working with an image that's larger than memory you can
# use mmapped files. The input and output files can be used independently.
# In this case an array labels.bin that is 5000x5000x2000 voxels and uint32_t
# in Fortran order is computed and the results are written to out.bin in Fortran
# order. You can find the properties of the file (shape, dtype, order) by inspecting
# labels_out.
labels_in = np.memmap("labels.bin", order="F", dtype=np.uint32, shape=(5000, 5000, 2000))
labels_out = cc3d.connected_components(labels_in, out_file="out.bin")

# You can extract the number of labels (which is also the maximum 
# label value) like so:
labels_out, N = cc3d.connected_components(labels_in, return_N=True) # free
# -- OR -- 
labels_out = cc3d.connected_components(labels_in) 
N = np.max(labels_out) # costs a full read

# You can extract individual components using numpy operators
# This approach is slow, but makes a mutable copy.
for segid in range(1, N+1):
  extracted_image = labels_out * (labels_out == segid)
  process(extracted_image) # stand in for whatever you'd like to do

# If a read-only image is ok, this approach is MUCH faster
# if the image has many contiguous regions. A random image 
# can be slower. binary=True yields binary images instead
# of numbered images.
for label, image in cc3d.each(labels_out, binary=False, in_place=True):
  process(image) # stand in for whatever you'd like to do

# Image statistics like voxel counts, bounding boxes, and centroids.
stats = cc3d.statistics(labels_out)

# Remove dust from the input image. Removes objects with
# fewer than `threshold` voxels.
labels_out = cc3d.dust(
  labels_in, threshold=100, 
  connectivity=26, in_place=False
)

# Get a labeling of the k largest objects in the image.
# The output will be relabeled from 1 to N.
labels_out, N = cc3d.largest_k(
  labels_in, k=10, 
  connectivity=26, delta=0,
  return_N=True,
)
labels_in *= (labels_out > 0) # to get original labels

# Compute the contact surface area between all labels.
# Only face contacts are counted as edges and corners
# have zero area. To get a simple count of all contacting
# voxels, set `surface_area=False`. 
# { (1,2): 16 } aka { (label_1, label_2): contact surface area }
surface_per_contact = cc3d.contacts(
  labels_out, connectivity=connectivity,
  surface_area=True, anisotropy=(4,4,40)
)
# same as set(surface_per_contact.keys())
edges = cc3d.region_graph(labels_out, connectivity=connectivity)

# You can also generate a voxel connectivty graph that encodes
# which directions are passable from a given voxel as a bitfield.
# This could also be seen as a method of eroding voxels fractionally
# based on their label adjacencies.
# See help(cc3d.voxel_connectivity_graph) for details.
graph = cc3d.voxel_connectivity_graph(labels, connectivity=connectivity)

Note: C and Fortran order arrays will be processed in row major and column major order respectively, so the numbering of labels will be "transposed". The scare quotes are there because the dimensions of the array will not change.

C++ Use

#include "cc3d.hpp"

// 3d array represented as 1d array
int* labels = new int[512*512*512](); 

uint32_t* cc_labels = cc3d::connected_components3d<int>(
  labels, /*sx=*/512, /*sy=*/512, /*sz=*/512
);

// The default template parameter for output type is uint32_t
uint64_t* cc_labels = cc3d::connected_components3d<int, uint64_t>(
  labels, /*sx=*/512, /*sy=*/512, /*sz=*/512
);

uint16_t* cc_labels = cc3d::connected_components3d<int, uint16_t>(
  labels, /*sx=*/512, /*sy=*/512, /*sz=*/512, 
  /*connectivity=*/18 // default is 26 connected
);

size_t N = 0;
uint16_t* cc_labels = cc3d::connected_components3d<int, uint16_t>(
  labels, /*sx=*/512, /*sy=*/512, /*sz=*/512, 
  /*connectivity=*/26, /*N=*/N // writes number of labels to N
);

#include "cc3d_continuous.hpp"

// For handling grayscale images. Note that the difference
// is the addition of the "delta" argument.
uint16_t* cc_labels = cc3d::connected_components3d<int, uint16_t>(
  labels, /*sx=*/512, /*sy=*/512, /*sz=*/512, 
  /*delta=*/10, /*connectivity=*/6 // default is 26 connected
);

#include "cc3d_graphs.hpp"

// edges is [ e11, e12, e21, e22, ... ]
std::vector<uint64_t> edges = cc3d::extract_region_graph<uint64_t>(
  labels, /*sx=*/512, /*sy=*/512, /*sz=*/512, 
  /*connectivity=*/18 // default is 26 connected
);

// graph is a series of bitfields that describe inter-voxel
// connectivity based on adjacent labels. See "cc3d_graphs.hpp"
// for details on the bitfield. 
uint32_t* graph = extract_voxel_connectivity_graph<T>(
  labels, /*sx=*/512, /*sy=*/512, /*sz=*/512, 
  /*connectivity=*/6 // default is 26 connected
);

26-Connected CCL Algorithm

The algorithm contained in this package is an elaboration into 3D images of the 2D image connected components algorithm described by Rosenfeld and Pflatz (RP) in 1968 [1] (which is well illustrated by this youtube video) using an equivalency list implemented as Tarjan's Union-Find disjoint set with path compression and balancing [2] and augmented with a decision tree based on work by Wu, Otoo, and Suzuki (WOS), an approach commonly known as Scan plus Array-based Union-Find (SAUF). [3] The description below describes the 26-connected algorithm, but once you understand it, deriving 18 and 6 are simple. However, we recently made some changes that warrant further discursion on 6-connected.

First Principles in 2D

In RP's 4-connected two-pass method for binary 2D images, the algorithm raster scans and every time it first encounters a foreground pixel (the pixels to its top and left are background), it marks it with a new label. If there is a preexisting label in its neighborhood, it uses that label instead. Whenever two labels are adjacent, it records they are equivalent so that they can be relabeled consistently in the second pass. This equivalency table can be constructed in several ways, but some popular approaches are Union-Find with path compression with balancing by rank and Selkow's algorithm (which can avoid pipeline stalls). [4] However, Selkow's algorithm is designed for two trees of depth two, appropriate for binary images. We would like to process multiple labels at the same time, making Union-Find preferable.

In the second pass, the pixels are relabeled using the equivalency table. Union-Find establishes one label as the root label of a tree, and the root is considered the representative label. Each pixel is then labeled with the representative label. Union-Find is therefore appropriate for representing disjoint sets. Path compression with balancing radically reduces the height of the tree, which accelerates the second pass.

WOS approached the problem of accelerating 8-connected 2D connected components on binary images. 8-connected labeling is achieved by extending RP's forward pass mask to the top left and top right corner pixels. In Union-Find based connected components algorithms, the unify step in the first pass is the most expensive step. WOS showed how to optimize away a large fraction of these calls using a decision tree that takes advantage of local topology. For example, since the top-center neighbor of the current pixel is also adjacent to the other mask elements, all of which have already been processed by virtue of the raster scan direction, if it is present it is sufficient to copy its value and move on. If it is absent, pick one of the remaining foreground pixels, copy their value, and use unify for the mask element on the right as it is now known to be non-neighboring with the left hand side. WOS's algorithm continues in this fashion until a match is found or all mask elements are processed at which point a new label is created.

For several years, this algorithm was the world's fastest, though it has been superceded by a newer work that exchanges the static decision tree for a dynamic one or precalculated generated one amongst other improvements. However, WOS's work is significant for both its simplicity and speed and thus serves as the inspiration for this library. For 2D 8-connected images, we provide a specialization using Wu et al's original decision tree for a slight performance boost.

We're interested in exploring the block based approaches of Grana, Borghesani, and Cucchiara ([5],[7]), however their approach appears to critically rely on binary images. We'll continue to think about ways to incorporate it. We also considered the approach of He et al [8] which is also supposed to modestly faster than than WOS. However, it substitutes the Union-Find data structure (one array) with three arrays, which imposes a memory requirement that is at odds with our goal of processing large images.

Extending to 3D

The approach presented below is very similar to that of Sutheebanjard [6]. To move to a 3D 26-connected neighborhood, the mask must be extended into three dimensions in order to connect neighboring planes. Observe that the 8-connected mask covers the trailing half of the neighborhood (the part that will have been already processed) such that the current pixel can rely on those labels. Thus the mask for the 26-connected neighborhood covers only two out of three potential planes: the entire lower plane (nine voxels), and a mask identical to WOS's (four voxels) on the current plane. While some further optimizations are possible, to begin, the problem can be conceptually decomposed into two parts: establishing a 9-connected link to the bottom plane and then an 8-connected link to the current plane. This works because the current pixel functions as a hub that transmits the connection information from the 9-connected step to the 8-connected step.

Fig. 1: Mask for an 8-connected plane. If J,K,L, and M are all eliminated, only N remains and a new label is assigned.

j k l
m n .
. . .

The very first Z plane (Z=0) the algorithm runs against is special: the edge effect omits the bottom plane of the mask. Therefore, as the remaining mask is only comprosed of the 8-connected 2D mask, after this pass, the bottom of the image is 8-connected. At Z=1, the 9-connected part of the mask kicks in, forming connections to Z=0, making the current plane now (8 + 9) 17-connected. At Z=2, the 9-connected bottom mask now forms connections from Z=1 to Z=2 on the top, making Z=1 (17 + 9) 26-connected. By induction, when this process proceeds to completion it results in a 26-connected labeling of the volume.

Following inspiration from WOS, we construct a decision tree on the densely labeled bottom plane that minimizes the number of unifications we need to perform.

Fig 2. The mask for the lower plane in 3D.

a b c
d e f
g h i

As e is connected to all other voxels, if present, it can simply be copied. If e is absent, b and h fully cover the mask. If b is absent, h, a, c comprise a covering. If h is absent, b, g, i are one. Below is a list of coverings such that each proceeding entry in the list assumes the first letters in the entries above are background.

  1. e
  2. k, (h | g, i)
  3. b, (h | g, i)
  4. h, a, c
  5. m, (f | c, i)
  6. d, (f | c, i)
  7. f, g, a
  8. a, c, g, i
  9. c, g, i
  10. g, i
  11. i

The decision tree is then constructed such that each of these coverings will be evaluated using the fewest unifications possible. It's possible to further optimize this by noting that e and b are both fully connected to the upper 2D mask. Therefore, if either of them are present, we can skip the 8-connected unification step. It's also possible to try the DF covering first if B is background, which would save one unification versus HAC given even statistics, but it seems to be slightly slower on the dataset I attempted. To move from binary data to multilabel data, I simply replaced tests for foreground and background with tests for matching labels.

In order to make a reasonably fast implementation, I implemented union-find with path compression. I conservatively used an IDs array qual to the size of the image for the union-find data structure instead of a sparse map. The union-find data structure plus the output labels means the memory consumption will be input + output + rank + equivalences. If your input labels are 32-bit, the memory usage will be 4x the input size. This becomes more problematic when 64-bit labels are used, but if you know something about your data, you can decrease the size of the union-find data structure. I previously used union-by-size but for some reason it merely reduced performance and increased memory usage so it was removed.

For more information on the history of connected components algorithms, and an even faster approach for 2D 8-connected components, consult Grana et al's paper on Block Based Decision Trees. [5,7]

Phantom Labels

In the course of thinking of improvements to several algorithms, we developed a technique we term "Phantom Labeling" for improving the SAUF method directly.

Definition: Phantom Labels are elements of a CCL mask that 
transmit connectivity information between other elements of the 
mask but cannot directly pass their value to the current pixel 
during the first pass of a SAUF derived algorithm.

Reproducing Fig. 1 again, but with new letters for the more limited problem, the standard SAUF mask appears like so:

Fig. 3: Mask for an 8-connected plane.

a b c
d x .
. . .

This results in a decision tree like so assuming x is a foreground pixel.

if b:
    x := b
elif a:
    x := a 
    if c:
        unify(a,c)
elif d:
    x := d
    if c: 
        unify(c,d)
elif c:
    x := c
else:
    x := new label

There is an opportunity here for eliminating up to half of the unify calls, one of the more expensive operations in modern CCL by slightly modifying the mask:

Fig. 4: 8-connected mask modified to include phantom label P.

. P .
a b c
d x .
. . .

This results in a modified decision tree.

if b:
    x := b
elif a:
    x := a 
    if c and not P: <--- change here
        unify(a,c)
elif d:
    x := d
    if c: 
        unify(c,d)
elif c:
    x := c
else:
    x := new label

The novelty of this technique is unclear, but it is very simple to apply and results in substantial speed ups for the 4 and 6 connected problems, a minor improvement for 8-connected, and is readily compatible with the multi-label approach unlike block based approaches.

4 and 6-Connected CCL Algorithm

Here is where the phantom label technique shines. It's a bit harder to find 4 and 6 connected algorithms in the literature, I assume because many of the techniques invented for the 8-way problem, such as the Union-Find data structure for the equivalency table and run-based approaches, are applicable to the simpler problem. However, the SAUF decision tree approach was lacking as every pixel required a unify call in the 4-way problem and two in the 6-way problem.

Fig. 5: 4-connected mask modified to include phantom label P.

P b .
a x .
if a:
    x := a
    if b and not P:
        unify(a,b)
elif b:
    x := b
else:
    x := new label

This gives a decent improvement on the order of 10-20%. If you're lucky, you might not incur even a single label merge operation. In the 6-way problem, there are three phantom labels that can be exploited and the improvement is closer to 50% on our data, a fairly substantial amount. Again, with luck you might avoid any unify operations at all.

Fig. 6: Mask for the 6-way problem with phantom labels P, Q, and R added.

P b
a x
. Q
R c

You can even use multiple routes to propagate information if a label is missing. For example, if path (a,P,b) is unavailable due to a missing P, you could potentially transmit information using path (a,R,c,Q,b).

Four Pass Algorithm

We introduce two additional passes over the image label prior to running the two-pass SAUF algorithm. These additional passes are used to collect statistcs for optimizing the SAUF passes.

Estimating Provisional Labels

The first additional pass is used to over-estimate the number of provisional labels generated by the first SAUF pass. A better estimation allows a smaller allocation for the Union-Find datastructure. For some operating systems, the reduced size of the allocation and improved caching recovers more time than is spent collecting statistics.

This can be computed by counting the number of transitions between labels along each row of the image. This scan is easily written such that the instructions can be vectorized to minimize the cost of the scan. The number of transitions is guaranteed to be larger than or equal to the number of provisional labels as all provisional labels are generated in this fashion and then reduced by stealing a label from a neighboring voxel.

A hierarchy of estimators can be written as:

0 <= provisional labels <= X transitions <= static estimate <= voxels

Binary images can also be estimated statically as voxels / 2 for 4 and 6-way, voxels / 4 for 8 and 18 way, and voxels / 8 for 26 connected. For multi-label images, the best static estimate is voxels as no assumptions can be made about how labels connect to each other (in the worst case all eight voxels in a cube have different labels).

It is also possible to check XY and XYZ transitions to get a tighter bound, but in experiments, the amount of time spent checking those directions exceeded the benefit obtained by checking the X pass. Often the X pass alone results in factors as high as voxels / 100.

Estimation of the number of labels also allows aborting processing before the first SAUF pass in the case of an all background cube.

Estimating Foreground Location

The second additional pass is estimating the location of the foreground. In the literature, this strategy is sometimes referred to as a "one-and-a-half pass" where the foreground location is computed during the first SAUF pass and then used to skip processing of background voxels during the relabeling pass.

Here we perform this check up front so that it can be performed minimally. Instead of integrating the calculation into the first pass which could force some computation on every voxel, we scan each row from the left to find the first foreground voxel and then scan from the right to the find the foreground voxel at the end. The results are tabulated in a uint32 table of starts and ends to each row of size 2 * sy * sz. This ensures that the volume is scanned at most once, and most likely much less if the shapes fill the space reasonably well. Then, both passes of the SAUF method scan only the part of each row indicated by this table.

Certain shapes and distributions defeat the efficiency of scanning only the starts and ends of the row (such as random images or an image with foreground on the start and end of each row and nowhere else). However, for a great many shapes, this provides substantial efficiencies and minimal downside for a dense multi-label image as only two YZ slices of the images are scanned before the table is completed.

Early Abortion Points

There are three locations in the algorithm at which further processing can be aborted early without changing the result.

  1. After estimating provisional labels if zero transitions are detected (an all zeros volume). A black image is returned.
  2. After the first SAUF pass if the number of provisional labels is zero or one. In this case, the provisional labels are guaranteed to be identical to final labels.
  3. After assigning final labels to each provisional label in a translation array. If the number of final labels equals the number of provisional labels, the provisional labels were accurately assigned and the relabeling scan can be skipped.

Papers Using cc3d

A number of papers are using cc3d now. Many of them seem to be deep learning applications as instance segmentation is liable to generate touching non-binary labels. Some are in geoscience, neuroscience, and medical fields. If cc3d is helpful to you, please feel free to email us and let us know. We might be able to offer some tips if its performance critical (though we can't guarantee timeliness of response). There are so many variations of the CCL problem, you might be surprised at what you can do.

https://scholar.google.com/scholar?as_ylo=2019&q=connected-components-3d&hl=en&as_sdt=0,31

References

  1. A. Rosenfeld and J. Pfaltz. "Sequential Operations in Digital Picture Processing". Journal of the ACM. Vol. 13, Issue 4, Oct. 1966, Pg. 471-494. doi: 10.1145/321356.321357 (link)
  2. R. E. Tarjan. "Efficiency of a good but not linear set union algorithm". Journal of the ACM, 22:215-225, 1975. (link)
  3. K. Wu, E. Otoo, K. Suzuki. "Two Strategies to Speed up Connected Component Labeling Algorithms". Lawrence Berkeley National Laboratory. LBNL-29102, 2005. (link)
  4. S. Selkow. "The Tree-to-Tree Editing Problem". Information Processing Letters. Vol. 6, No. 6. June 1977. doi: 10.1016/0020-0190(77)90064-3 (link)
  5. C. Grana, D. Borghesani, R. Cucchiara. "Optimized Block-based Connected Components Labeling with Decision Trees". IEEE Transactions on Image Processing. Vol. 19, Iss. 6. June 2010. doi: 10.1109/TIP.2010.2044963 (link)
  6. P. Sutheebanjard. "Decision Tree for 3-D Connected Components Labeling". Proc. 2012 International Symposium on Information Technology in Medicine and Education. doi: 10.1109/ITiME.2012.6291402 (link)
  7. C. Grana, D. Borghesani, R. Cucchiara. "Fast Block Based Connected Components Labeling". Proc. 16th IEEE Intl. Conf. on Image Processing. 2009. doi: 10.1109/ICIP.2009.5413731 (link)
  8. L. He, Y. Chao and K. Suzuki, "A Linear-Time Two-Scan Labeling Algorithm", IEEE International Conference on Image Processing, vol. 5, pp. 241-244, 2007.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

connected-components-3d-3.12.1.tar.gz (606.6 kB view details)

Uploaded Source

Built Distributions

If you're not sure about the file name format, learn more about wheel file names.

connected_components_3d-3.12.1-cp311-cp311-win_amd64.whl (350.1 kB view details)

Uploaded CPython 3.11Windows x86-64

connected_components_3d-3.12.1-cp311-cp311-win32.whl (383.4 kB view details)

Uploaded CPython 3.11Windows x86

connected_components_3d-3.12.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (3.0 MB view details)

Uploaded CPython 3.11manylinux: glibc 2.17+ x86-64

connected_components_3d-3.12.1-cp311-cp311-manylinux_2_17_i686.manylinux2014_i686.whl (3.0 MB view details)

Uploaded CPython 3.11manylinux: glibc 2.17+ i686

connected_components_3d-3.12.1-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (2.8 MB view details)

Uploaded CPython 3.11manylinux: glibc 2.17+ ARM64

connected_components_3d-3.12.1-cp311-cp311-macosx_10_9_x86_64.whl (534.8 kB view details)

Uploaded CPython 3.11macOS 10.9+ x86-64

connected_components_3d-3.12.1-cp311-cp311-macosx_10_9_universal2.whl (959.7 kB view details)

Uploaded CPython 3.11macOS 10.9+ universal2 (ARM64, x86-64)

connected_components_3d-3.12.1-cp310-cp310-win_amd64.whl (351.4 kB view details)

Uploaded CPython 3.10Windows x86-64

connected_components_3d-3.12.1-cp310-cp310-win32.whl (385.1 kB view details)

Uploaded CPython 3.10Windows x86

connected_components_3d-3.12.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (2.9 MB view details)

Uploaded CPython 3.10manylinux: glibc 2.17+ x86-64

connected_components_3d-3.12.1-cp310-cp310-manylinux_2_17_i686.manylinux2014_i686.whl (2.9 MB view details)

Uploaded CPython 3.10manylinux: glibc 2.17+ i686

connected_components_3d-3.12.1-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (2.7 MB view details)

Uploaded CPython 3.10manylinux: glibc 2.17+ ARM64

connected_components_3d-3.12.1-cp310-cp310-macosx_10_9_x86_64.whl (540.5 kB view details)

Uploaded CPython 3.10macOS 10.9+ x86-64

connected_components_3d-3.12.1-cp310-cp310-macosx_10_9_universal2.whl (963.4 kB view details)

Uploaded CPython 3.10macOS 10.9+ universal2 (ARM64, x86-64)

connected_components_3d-3.12.1-cp39-cp39-win_amd64.whl (355.1 kB view details)

Uploaded CPython 3.9Windows x86-64

connected_components_3d-3.12.1-cp39-cp39-win32.whl (388.8 kB view details)

Uploaded CPython 3.9Windows x86

connected_components_3d-3.12.1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (2.9 MB view details)

Uploaded CPython 3.9manylinux: glibc 2.17+ x86-64

connected_components_3d-3.12.1-cp39-cp39-manylinux_2_17_i686.manylinux2014_i686.whl (2.9 MB view details)

Uploaded CPython 3.9manylinux: glibc 2.17+ i686

connected_components_3d-3.12.1-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (2.7 MB view details)

Uploaded CPython 3.9manylinux: glibc 2.17+ ARM64

connected_components_3d-3.12.1-cp39-cp39-macosx_10_9_x86_64.whl (545.6 kB view details)

Uploaded CPython 3.9macOS 10.9+ x86-64

connected_components_3d-3.12.1-cp39-cp39-macosx_10_9_universal2.whl (972.1 kB view details)

Uploaded CPython 3.9macOS 10.9+ universal2 (ARM64, x86-64)

connected_components_3d-3.12.1-cp38-cp38-win_amd64.whl (357.7 kB view details)

Uploaded CPython 3.8Windows x86-64

connected_components_3d-3.12.1-cp38-cp38-win32.whl (391.3 kB view details)

Uploaded CPython 3.8Windows x86

connected_components_3d-3.12.1-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (3.0 MB view details)

Uploaded CPython 3.8manylinux: glibc 2.17+ x86-64

connected_components_3d-3.12.1-cp38-cp38-manylinux_2_17_i686.manylinux2014_i686.whl (3.0 MB view details)

Uploaded CPython 3.8manylinux: glibc 2.17+ i686

connected_components_3d-3.12.1-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (2.8 MB view details)

Uploaded CPython 3.8manylinux: glibc 2.17+ ARM64

connected_components_3d-3.12.1-cp38-cp38-macosx_11_0_universal2.whl (958.8 kB view details)

Uploaded CPython 3.8macOS 11.0+ universal2 (ARM64, x86-64)

connected_components_3d-3.12.1-cp38-cp38-macosx_10_9_x86_64.whl (539.0 kB view details)

Uploaded CPython 3.8macOS 10.9+ x86-64

connected_components_3d-3.12.1-cp37-cp37m-win_amd64.whl (337.3 kB view details)

Uploaded CPython 3.7mWindows x86-64

connected_components_3d-3.12.1-cp37-cp37m-win32.whl (381.1 kB view details)

Uploaded CPython 3.7mWindows x86

connected_components_3d-3.12.1-cp37-cp37m-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (2.8 MB view details)

Uploaded CPython 3.7mmanylinux: glibc 2.17+ x86-64

connected_components_3d-3.12.1-cp37-cp37m-manylinux_2_17_i686.manylinux2014_i686.whl (2.8 MB view details)

Uploaded CPython 3.7mmanylinux: glibc 2.17+ i686

connected_components_3d-3.12.1-cp37-cp37m-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (2.6 MB view details)

Uploaded CPython 3.7mmanylinux: glibc 2.17+ ARM64

connected_components_3d-3.12.1-cp37-cp37m-macosx_10_9_x86_64.whl (526.2 kB view details)

Uploaded CPython 3.7mmacOS 10.9+ x86-64

File details

Details for the file connected-components-3d-3.12.1.tar.gz.

File metadata

  • Download URL: connected-components-3d-3.12.1.tar.gz
  • Upload date:
  • Size: 606.6 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/4.0.2 CPython/3.11.3

File hashes

Hashes for connected-components-3d-3.12.1.tar.gz
Algorithm Hash digest
SHA256 e40445bccbea51bb8ba256411f9e8fc7e43226502af5a913f090ec81181daf1f
MD5 a1ccf89f98e84df845ceb10359f61274
BLAKE2b-256 8bdaad7df8ea4847dec4b9975d1259d1651d3f9068275532ddf758df922a9cf8

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp311-cp311-win_amd64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp311-cp311-win_amd64.whl
Algorithm Hash digest
SHA256 b5d573033bf912fe83f468fce75790d90037849e2cc294621d77a11a1427aed2
MD5 e698fa5793b0de1b3b5c6e5c8e7338a1
BLAKE2b-256 d2ae511f4c5126c3e448ecf31d40051a3504a88d2ced955719f53bab6ff988c8

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp311-cp311-win32.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp311-cp311-win32.whl
Algorithm Hash digest
SHA256 e885e2012221298bdae465a5dfcc57bb8bd61cac38aed49faf6507f31d8a6e15
MD5 b394d9551acbf52029b13890cdcb180d
BLAKE2b-256 6788190f43b975d2b4abc7f88cf3bbe5bc8c57747f5677a3adde39f869cd7e86

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
Algorithm Hash digest
SHA256 7b01a942f5623ec62c33d933f8fc471afb1eed7a1c233878be065e279746f4cf
MD5 9e2726ed67c8a5ea8e9e04379f48dacc
BLAKE2b-256 c92cee4ac33fed23ac8a19760ca0bf9bd4175c5e99ac0dd373a68cee23a46828

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp311-cp311-manylinux_2_17_i686.manylinux2014_i686.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp311-cp311-manylinux_2_17_i686.manylinux2014_i686.whl
Algorithm Hash digest
SHA256 1e838a2dd0edeac8c1d10482464bb771ba791cfae338b6bc93cfcd01566ff1a4
MD5 e2581d299440908cf1ef5d98c4762356
BLAKE2b-256 c9e0ec5c9a2331f299c23ab6133d57d405b47ea598aa33bc79c6df2bee3ff71b

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
Algorithm Hash digest
SHA256 b477d8533771295f306c2e97086409c8917537a10eb6d1b34e119cfcb98d0185
MD5 f30bcb5879ab1bea06c0541422551891
BLAKE2b-256 dbf977a052688b59209d93e40ebc42a00f25d9d3ee63012b5b4372dad385e063

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp311-cp311-macosx_10_9_x86_64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp311-cp311-macosx_10_9_x86_64.whl
Algorithm Hash digest
SHA256 459562c23a986cfc23f48b90bf06bde79214bc152185073a781c44a1817c6fb6
MD5 fe700d6556a2910fd0946596a8bc9ae9
BLAKE2b-256 88d94f45b1fddaa9dceae2c3ad94211d6e00f114b6f6cb4c146c303eba7a9e5b

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp311-cp311-macosx_10_9_universal2.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp311-cp311-macosx_10_9_universal2.whl
Algorithm Hash digest
SHA256 1d9a1ce07f6bf071179d850135f55f5046d2a12924f47d4844f8f3c8b411f16e
MD5 f6a18b4a49b93230eacabbbcab28a69a
BLAKE2b-256 58a0632ce5801c65236e056c91aa3322d94dacfb790f12238e7f6153a1945630

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp310-cp310-win_amd64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp310-cp310-win_amd64.whl
Algorithm Hash digest
SHA256 22d00b919a91341d8ac20d085d7194bef6b19ca03a7e370d37625f45807cd873
MD5 2af54cfbb92846434d9634e926c6028a
BLAKE2b-256 d66ce7768d213749184a7179d8d67a0b4b60d3d3eb5373ddb861b8f617eb01e7

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp310-cp310-win32.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp310-cp310-win32.whl
Algorithm Hash digest
SHA256 f1d0f284a4aa7b3d41587bd80fd0d6fdd64eb22222d0820f474a96155b522f91
MD5 87ea22714021844d2da5efda790d7f93
BLAKE2b-256 0ff4ce8e407bcd695c8e46ff25ed21ca3fa7997d7447ef6b90b2567adfbad379

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
Algorithm Hash digest
SHA256 7cb3f893557aeee504fa2c2a641046507e05b6777b13a91bae6400c3f27ad195
MD5 7bfd400261b363d061f5515e19b5fe82
BLAKE2b-256 eba1239d0c44fb54921980194a55dbe54e9c3d9d221536f94d6c8060fa181a71

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp310-cp310-manylinux_2_17_i686.manylinux2014_i686.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp310-cp310-manylinux_2_17_i686.manylinux2014_i686.whl
Algorithm Hash digest
SHA256 85c2a4782d0a9e29e34ed9768fcca8632dc2d6035b26c8af96761dc7d764891d
MD5 120fbe00716a08ef42f3ba4a35126ce3
BLAKE2b-256 903dbfe2ba88377ebd21d3054336410c01e998f5e373cd3b5bb80bf817b1530e

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp310-cp310-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
Algorithm Hash digest
SHA256 7c724255c42843a088266673150c47fc8cca8857ce878a4fad9561637f2b9866
MD5 f81d5df58ba0fe7b9e66af322c323996
BLAKE2b-256 a0987a1b886fffc75ff62e215ce853a855eef9761d667fb45ccfe5bd90c02e9b

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp310-cp310-macosx_10_9_x86_64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp310-cp310-macosx_10_9_x86_64.whl
Algorithm Hash digest
SHA256 03638e995f635fa3981b076eaf838b8020e7885266c26fb6db76431ce6c4cd4b
MD5 11df9f7f0696b33833b06463f60bb404
BLAKE2b-256 3576b1f43cae72ca38121480ead7e101ced4c5fd9023a3b28e4a7570898c00ed

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp310-cp310-macosx_10_9_universal2.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp310-cp310-macosx_10_9_universal2.whl
Algorithm Hash digest
SHA256 4bf25d98915f1d6b7792c4c264b00598fc16c4881345461dc755e7f74f435046
MD5 50610b0c3594b8b8234cc1e75e14aa91
BLAKE2b-256 3aa953fbad2536b16704b75dc86e4c9e3345119e67fb5ee4c95bcdb859862cd7

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp39-cp39-win_amd64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp39-cp39-win_amd64.whl
Algorithm Hash digest
SHA256 397ace8d52f6aa3c703c6e0524c12d95598f3701a193f2c15d3a8d8a9a63c8d1
MD5 db615a6d51bc0b0b46441bb626e1fcc0
BLAKE2b-256 e6b30c7a2ef8fc51caecb886bde750b457479c7969a2bb36a4014e18d0cd417a

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp39-cp39-win32.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp39-cp39-win32.whl
Algorithm Hash digest
SHA256 36f74322bdb028762a5e3e6e0dc3941a212aeb9aaefa232829165e141c893d5d
MD5 6bc3a7c2def29d4ac12625274af10b79
BLAKE2b-256 36571ac9b30ac5dd711f84f578a849af0e642f0cee9f0db9ae3c6a43d2aa1bb7

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
Algorithm Hash digest
SHA256 d7c436d77f6df88077dd592d4eb3be1fdc06bf1674ca7a6d0141cbd287aeb42c
MD5 119e7ddec382c6dc4a49ab5524d5ef6c
BLAKE2b-256 2f053efaba9fbe6e0464f3477559c3b0e93221870172580327b897a31e65e5ef

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp39-cp39-manylinux_2_17_i686.manylinux2014_i686.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp39-cp39-manylinux_2_17_i686.manylinux2014_i686.whl
Algorithm Hash digest
SHA256 ae66a90f506774aaf8580eb0b10e50bf13df815ec0a29328f79c2888f8fa8213
MD5 46ef39f069b93429da8f2b2263a73e77
BLAKE2b-256 6771ec20cbda2bdb0205f94071dcc4ef9e0576e22c24e94412a072e64f95d3b4

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
Algorithm Hash digest
SHA256 2269ef51926c25f4bbf702c9e3bd0497572eaddd12e13099e616a813778e7124
MD5 732ce2ee99471e85ffd4d4cfc772da41
BLAKE2b-256 c9f1bfe65f281edc95a617c669955be93a47678f4b50e4b093e59278cc9a56c1

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp39-cp39-macosx_10_9_x86_64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp39-cp39-macosx_10_9_x86_64.whl
Algorithm Hash digest
SHA256 571cdc628704006d2b0f342572e9913ecae05730677a4e3e69a678c097df799b
MD5 4e756ef6bbd6404d91a815e2305f8a2e
BLAKE2b-256 15ec78520f9db852016a2e284c356c7be6177165ab2ebcde782b449ab5f1b007

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp39-cp39-macosx_10_9_universal2.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp39-cp39-macosx_10_9_universal2.whl
Algorithm Hash digest
SHA256 a8de2a3015e6c3dcbde8fad3bff4b967537e96b4eee62df0bdbbc12f2f4ddfd4
MD5 fc2844a1bb5807b1caa44eab7b61c0ca
BLAKE2b-256 a6dad506d152183be73fcb466f66672c31b9893657971c097647279127972c18

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp38-cp38-win_amd64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp38-cp38-win_amd64.whl
Algorithm Hash digest
SHA256 fa7b304c583397c676a68506e2d948fa81a16c4de1ec4d2a059f7a3ac4456688
MD5 5dd991f8dd7e701d8ec831676f42beb2
BLAKE2b-256 61f44aa5bd67b862504643d7c7daf13b26346baaec9ed4ea47155b7abbc705f7

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp38-cp38-win32.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp38-cp38-win32.whl
Algorithm Hash digest
SHA256 2a0af6b89d7e9f6aa8d3cc73ecf2776f349fdeeae2e251bd07a1648f34d3f744
MD5 8595f364c4ff41708abdea28f4f49555
BLAKE2b-256 f7bff3e9753dba67bcc3eb9d7b7a6bb92fc1096d4f8c413a997919edb54522d6

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
Algorithm Hash digest
SHA256 51f122cac1427e73a1b0a17cf78caf38682aeaa4b52002edbbf3c9915caa4d09
MD5 02eed0cc2a69972de9d0930796ea2d20
BLAKE2b-256 4739e144a0d18d9c490e890a0945259cae0bd3e0dd0e0d3e8ef407943f0b5340

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp38-cp38-manylinux_2_17_i686.manylinux2014_i686.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp38-cp38-manylinux_2_17_i686.manylinux2014_i686.whl
Algorithm Hash digest
SHA256 e7c032e51e0cf7030366e16a76646cc11b9291ff4b420951d0162322e7abd670
MD5 07aa72c35d4dd274b07e32d555f5c032
BLAKE2b-256 0ff6730349834627e77c53136d6de8dfa21ebe82fdb1871c339e96cdfafb9ee6

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp38-cp38-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
Algorithm Hash digest
SHA256 95542936ee2463e09d1f57d39acdf23fd2df2412acf4efea58b7f8ea07e6b7a0
MD5 607e0dd4363a92e64bec1d7e510cd962
BLAKE2b-256 f1a78ba3c80262dc96a49cb50c4ce0e74626f601a3bc9c5d5ad44a615a4a8cc8

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp38-cp38-macosx_11_0_universal2.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp38-cp38-macosx_11_0_universal2.whl
Algorithm Hash digest
SHA256 cf1e2efeb16bb19f711c91243e44b7024d908ec519b6031dee367727c1657f3d
MD5 a8dd9be10c86b8561a6d5f261b4efd83
BLAKE2b-256 d81d56a47133e05a15bda6697a8202d1f49fc2f0639357ca8b3a7b9ec7a58b14

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp38-cp38-macosx_10_9_x86_64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp38-cp38-macosx_10_9_x86_64.whl
Algorithm Hash digest
SHA256 102408865aa19d360ebc1e0eddba3f4bc458ee83536982f09551c870bd044dc2
MD5 db654db133e17db5610dfafaa3d191b8
BLAKE2b-256 61696727ce6d37bfa30bcb98bca9ee3a8eb043d09d04f072aabe46c5fb122db4

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp37-cp37m-win_amd64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp37-cp37m-win_amd64.whl
Algorithm Hash digest
SHA256 c13be8c207e5b029a594e8676b17fdbcfb735ccfa6190dbb9dee01df2464cc2a
MD5 52b1ad674ecf3a1537605ecc51141072
BLAKE2b-256 72ad38c1eea9a3322ea1e04596c76bbf7e38932573ceb36b1e1c66e3acf3016c

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp37-cp37m-win32.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp37-cp37m-win32.whl
Algorithm Hash digest
SHA256 21318ba12733981db7e2e679ec334c63312accf17b36f8021ac5e8b746669ada
MD5 ef8511ee61ff0d0b0faab49baa2bb0ef
BLAKE2b-256 843432ef21be68d63b94737b62a7f108f34701614c93d54b6b345bfd27c84909

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp37-cp37m-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp37-cp37m-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
Algorithm Hash digest
SHA256 ecc966d9ae873ba36fc90b9e673ca89c1f91bde08255c0d44a055a050af4a3f7
MD5 c7cbef22e1c26648c1e2978fc8aa7d76
BLAKE2b-256 fbc42d6184a8fbc5f9655f85e07d8f2d2b686587637f538eb1d99c0b8c5dd590

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp37-cp37m-manylinux_2_17_i686.manylinux2014_i686.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp37-cp37m-manylinux_2_17_i686.manylinux2014_i686.whl
Algorithm Hash digest
SHA256 480f9adf68102c5c3660c84dab0537e5bff5e979e2af472054beae0a4779203b
MD5 aa88b1da7c0944f86a03b56654be06e1
BLAKE2b-256 c6d0776da067d939c0f6a5c74affea9e0aab074d9896c9fe9aa8c46b38f2d14b

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp37-cp37m-manylinux_2_17_aarch64.manylinux2014_aarch64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp37-cp37m-manylinux_2_17_aarch64.manylinux2014_aarch64.whl
Algorithm Hash digest
SHA256 b1cd8e279d8b52280c2916fcdb1ef0d0ab0a7bff661a7841c674d29dcddb4b82
MD5 30f38851995e20bc06d5359cf8b0dbdc
BLAKE2b-256 921aa054df1da6c865c7467a2cac68bfc4a7d85bbcd304bc1373c2dc3117cb37

See more details on using hashes here.

File details

Details for the file connected_components_3d-3.12.1-cp37-cp37m-macosx_10_9_x86_64.whl.

File metadata

File hashes

Hashes for connected_components_3d-3.12.1-cp37-cp37m-macosx_10_9_x86_64.whl
Algorithm Hash digest
SHA256 20d04bdc0e22170b7927823ec0ebaa0db6bd2822921cf0530cf9963c52fd9462
MD5 ba9cbd4194d57bb4a74e3c2e374faf6c
BLAKE2b-256 10494223836e77bff02e6084a864c5954fd9eab40b8672c94fa90171faf5a515

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page