Date   
Re: Homology for huge dataset

nukpezah@...
 

Hi Dmitry
Thanks for the clarification. 
Sincerely
Jonathan

Re: Homology for huge dataset

Dmitriy Morozov
 

Again, this depends on the specifics of your application, but if your
data is in 3D, then yes, you can most likely just replace the rips
step with the alpha shapes. In other words, you understood be
correctly.

On Sat, Oct 5, 2019 at 6:30 PM <nukpezah@...> wrote:

Hi Dmitri
I was using the rips filtration and trying to compute the persistence bar codes by passing the rips filtration to the dionysus.homology_persistence class and then using the dionysus.init_diagrams on the persistence and the rips filtration to obtain the bar codes. If I understand you right, I should use diode to compute the alpha shape filtration and then pass that into dionysus.homology_persistence class to compute the persistence homology? Thanks
Jonathan

Re: Homology for huge dataset

nukpezah@...
 

Hi Dmitri
I was using the rips filtration and trying to compute the persistence bar codes by passing the rips filtration to the dionysus.homology_persistence class and then using the dionysus.init_diagrams on the persistence and the rips filtration to obtain the bar codes. If I understand you right, I should use diode to compute the alpha shape filtration and then pass that into dionysus.homology_persistence class to compute the persistence homology? Thanks
Jonathan

Re: Homology for huge dataset

Dmitriy Morozov
 

What filtration are you using? I.e., what are you trying to compute?
If you have points in 3D, alpha shapes is a natural choice. 20K points
is nothing for alpha shapes, 20M would be doable on a laptop.

You can compute an alpha shape filtration using diode:
https://github.com/mrzv/diode

If you are after something else, you'll have to explain what it is.

Dmitriy

On Sat, Oct 5, 2019 at 10:45 AM <nukpezah@...> wrote:

Hi Dmitry
I wanted to find if the latest release of Dionysus is optimized for computing persistence homology for huge data sets. I have a huge dataset of morphology metrics (3 dimensions) of 20,000 cells, that is 20,000 points in 3D space. I was trying to calculate the persistence diagrams on a 16 core processor linux machine but the computation kept crushing. My assumption was that it could not handle the millions of simplexes it needs to calculate? Is there a workaround this if this is the issue? Thanks
Jonathan

Homology for huge dataset

nukpezah@...
 

Hi Dmitry
I wanted to find if the latest release of Dionysus is optimized for computing persistence homology for huge data sets. I have a huge dataset of morphology metrics (3 dimensions) of 20,000 cells, that is 20,000 points in 3D space. I was trying to calculate the persistence diagrams on a 16 core processor linux machine but the computation kept crushing. My assumption was that it could not handle the millions of simplexes it needs to calculate? Is there a workaround this if this is the issue? Thanks
Jonathan

Re: Homology groups for paths on 8-connected grids

o.lamarre7@...
 

Oh I see! Great, thank you very much for the help!

Re: Homology groups for paths on 8-connected grids

Dmitriy Morozov
 

The chains should be defined in terms of the indices in the filtration. Each entry should be a tuple of coefficient and index. So to make your code work, change the chain definitions to:

chain_red = d.Chain([(1,f.index(d.Simplex(s))) for s in [(1,4), (4,8), (8,9)]])
chain_green = d.Chain([(1,f.index(d.Simplex(s))) for s in [(1,5), (5,9)]])
chain_blue = d.Chain([(1,f.index(d.Simplex(s))) for s in [(1,2), (2,6), (6,9)]])

On Wed, Sep 18, 2019 at 11:06 PM <o.lamarre7@...> wrote:
Hi!
I've been playing around with this library and after going through the (great) documentation for it, I'm still stuck trying to implement what I believe to be rather basic: evaluate path homologies on already-known 8-connected grids.

Here's a sample problem to illustrate the situation: say we have an already-known 8-connected grid/map with known obstacles (shown in dark gray). Such a 2D map can be represented as a simplicial complex (containing k-0, k-1 and k-2 simplices). The space contained between the 2,5,6,9 vertices is a hole:

Now, I would like to compare different chains (with the same start and end vertices) and would like to tell whether they belong to the same homology group or not. In the following example, the red and green 1-chains should be considered homologous but the blue chain should belong to a different homology group:


I have attempted to implement this example in a very simply Dionysus example using Python:

import dionysus as d
 
# Create simplicial complex
simplices_k0 = [[0], [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]]
simplices_k1 = [[0,1],[1,2], [2,3], [0,4], [0,5], [1,4], [1,5], [2,5], [2,6], [3,6], [4,5], [4,7], [4,8], [5,7], [5,8], [5,9], [6,9], [6,10], [7,8], [8,9], [9,10]]
simplices_k2 = [[0,4,5], [0,1,5], [0,4,1], [1,4,5], [1,2,5], [2,3,6], [4,5,7], [5,7,8], [4,5,8], [4,7,8], [5,8,9], [6,9,10]]
 
# Create filtration and reduced boundary matrix
f = d.Filtration(simplices_k0 + simplices_k1 + simplices_k2)
f.sort()
m = d.homology_persistence(f)
 
# Chains to evaluate/compare
chain_red = d.Chain([(1,4), (4,8), (8,9)])
chain_green = d.Chain([(1,5), (5,9)])
chain_blue = d.Chain([(1,2), (2,6), (6,9)])
 
m.homologous(chain_red, chain_green)    # Returns False (but was expecting True)
m.homologous(chain_red, chain_blue)      # Returns True  (but was expecting False)
m.homologous(chain_green, chain_blue)  # Returns False (was expecting False)
As mentioned in the comments above, there is definitely something I am missing. First, am I creating the chains properly? I thought they were basically a list of 1-D simplices tuples, but this might not be the case (still confused after looking at the API documentation). Second - would anyone be able to tell if this is a proper usage for the "homologous" method? If not, how could I adapt the code above to successfully compare the red-green-blue chains from the example?

Thank you very much!

Homology groups for paths on 8-connected grids

o.lamarre7@...
 

Hi!
I've been playing around with this library and after going through the (great) documentation for it, I'm still stuck trying to implement what I believe to be rather basic: evaluate path homologies on already-known 8-connected grids.

Here's a sample problem to illustrate the situation: say we have an already-known 8-connected grid/map with known obstacles (shown in dark gray). Such a 2D map can be represented as a simplicial complex (containing k-0, k-1 and k-2 simplices). The space contained between the 2,5,6,9 vertices is a hole:

Now, I would like to compare different chains (with the same start and end vertices) and would like to tell whether they belong to the same homology group or not. In the following example, the red and green 1-chains should be considered homologous but the blue chain should belong to a different homology group:


I have attempted to implement this example in a very simply Dionysus example using Python:

import dionysus as d
 
# Create simplicial complex
simplices_k0 = [[0], [1], [2], [3], [4], [5], [6], [7], [8], [9], [10]]
simplices_k1 = [[0,1],[1,2], [2,3], [0,4], [0,5], [1,4], [1,5], [2,5], [2,6], [3,6], [4,5], [4,7], [4,8], [5,7], [5,8], [5,9], [6,9], [6,10], [7,8], [8,9], [9,10]]
simplices_k2 = [[0,4,5], [0,1,5], [0,4,1], [1,4,5], [1,2,5], [2,3,6], [4,5,7], [5,7,8], [4,5,8], [4,7,8], [5,8,9], [6,9,10]]
 
# Create filtration and reduced boundary matrix
f = d.Filtration(simplices_k0 + simplices_k1 + simplices_k2)
f.sort()
m = d.homology_persistence(f)
 
# Chains to evaluate/compare
chain_red = d.Chain([(1,4), (4,8), (8,9)])
chain_green = d.Chain([(1,5), (5,9)])
chain_blue = d.Chain([(1,2), (2,6), (6,9)])
 
m.homologous(chain_red, chain_green)    # Returns False (but was expecting True)
m.homologous(chain_red, chain_blue)      # Returns True  (but was expecting False)
m.homologous(chain_green, chain_blue)  # Returns False (was expecting False)
As mentioned in the comments above, there is definitely something I am missing. First, am I creating the chains properly? I thought they were basically a list of 1-D simplices tuples, but this might not be the case (still confused after looking at the API documentation). Second - would anyone be able to tell if this is a proper usage for the "homologous" method? If not, how could I adapt the code above to successfully compare the red-green-blue chains from the example?

Thank you very much!

Re: representatives of bars, homology classes. . . perhaps with better formatting

Dmitriy Morozov
 

Hi Ryan,

Your understanding is correct. I just want to add a couple of small things.

This persistent homology of our square has four H_0 bars that merge into one at length-parameter 2.  And it has a single H_1 bar that starts at length parameter 2, and dies as 2\sqrt{2}.  Here is how I merge this understanding with the Dionysus output, line-by-line:
 
<0> 0: 
<1> 0: 
<2> 0: 
<3> 0: 
 
These lines say the four vertices labelled <0>, <1>, <2>, <3> appear at length parameter 0.  The fact that there's nothing to the right of the colon indicates bars are created at length-parameter zero. 

That's right. If there is nothing to the right of the colon (i.e., if the respective column c (=hfp[i]) is empty), then you have a birth in the filtration, when you add that simplex. It's a little tricky to get the representative cycle that's born (it's much easier to get it when it dies). But in the 0-dimensional case, it's just the vertex.
 
The lines:
 
<0,1> 2: 1 * <0> 0 + 1 * <1> 0
<0,3> 2: 1 * <0> 0 + 1 * <3> 0
<1,2> 2: 1 * <1> 0 + 1 * <2> 0
 
say at length-parameter 2, the three edges <0,1>, <0,3>, <1,2> are created and they merge the four 0-cycles into one. 

Right. The precise meaning of the stuff after the colon is that it's the cycle that was non-zero before, but becomes zero after the addition of the simplex before the colon. Moreover, the cycle is reduced, i.e., it's the oldest such cycle. You can get its birth by taking the maximum birth time, or by looking at hfp.pair(i), which will give you the index of the simplex that gave birth to the cycle.
 
The line:
 
<2,3> 2: 
 
indicates the last edge <2,3> is creating a 1-cycle, at side-length 2.  So this helps me.  It's telling me that generally one has to combine these relations to discover the cycle representatives. 

If you want to find representative of the essential cycles, then you need to do extra work. But if you are only looking for representatives for finite bars, then it's best to just check at the time of death.
 
The remaining lines are relatively degenerate:
 
<0,2> 2.82843: 
<1,3> 2.82843: 
<0,1,2> 2.82843: 1 * <0,1> 2 + 1 * <1,2> 2 + 1 * <0,2> 2.82843
<0,1,3> 2.82843: 1 * <0,1> 2 + 1 * <0,3> 2 + 1 * <1,3> 2.82843
<0,2,3> 2.82843: 1 * <0,1> 2 + 1 * <0,3> 2 + 1 * <1,2> 2 + 1 * <2,3> 2
<1,2,3> 2.82843: 
<0,1,2,3> 2.82843: 1 * <0,1,2> 2.82843 + 1 * <0,1,3> 2.82843 + 1 * <0,2,3> 2.82843 + 1 * <1,2,3> 2.82843
 
This says at length 2\sqrt{2} two new 1-cycles are created and simultaneously destroyed, but then also a 2-cycle is created and simultaneously destroyed, i.e. bars of length 0. 

Right, but the line for <0,2,3> also tells you that you have a bar [2,2.82843], and specifically it gives you a cycle that was born when <2,3> entered the filtration and that got killed when <0,2,3> entered the filtration.
 
I hope this helps.
Dmitriy

representatives of bars, homology classes. . . perhaps with better formatting

Ryan Budney
 

Greetings, 
 
Say I've computed persistent homology of some RIPS complex in Dionysus.  How does one go the extra step to find a cycle representative in a homology class?  i.e. I would like to identify the bar, and determine which linear combination of simplices represent the bar. 
 
In the process of writing this question I likely have answered it.  But it would be nice to get confirmation, and perhaps this will be useful to others.
 
To make this concrete and fairly simple, let me use the vertices of a square of side-length two as my data set.
 
import dionysus as di
 
## generate square as a list
 
A = []
for i in [-1,1]:
    for j in [-1, 1]:
        cv = [i, i]
        cv[1] *= j
        A.append(cv)
 
## convert to numpy array
A = np.array(A, float)
 
## generate the associated RIPS complex
X = di.fill_rips(A, 3, 3.0)
 
## compute persistent homology
hfp = di.homology_persistence(X)
 
## here is where I get a bit fuzzy.  My understanding is hfp is a reduced
## matrix that describes the persistent homology.  But I'm not certain how 
## to read it.  Here is some code of Dmitriy's that I lifted from a 2018 thread.
 
for i,c in enumerate(hfp):
  print(X[i],end=': ')
  print(" + ".join(["%d * %s" % (x.element, X[x.index]) for x in c]))
 
If I execute the above code, I get this as output.
 
<0> 0: 
<1> 0: 
<2> 0: 
<3> 0: 
<0,1> 2: 1 * <0> 0 + 1 * <1> 0
<0,3> 2: 1 * <0> 0 + 1 * <3> 0
<1,2> 2: 1 * <1> 0 + 1 * <2> 0
<2,3> 2: 
<0,2> 2.82843: 
<1,3> 2.82843: 
<0,1,2> 2.82843: 1 * <0,1> 2 + 1 * <1,2> 2 + 1 * <0,2> 2.82843
<0,1,3> 2.82843: 1 * <0,1> 2 + 1 * <0,3> 2 + 1 * <1,3> 2.82843
<0,2,3> 2.82843: 1 * <0,1> 2 + 1 * <0,3> 2 + 1 * <1,2> 2 + 1 * <2,3> 2
<1,2,3> 2.82843: 
<0,1,2,3> 2.82843: 1 * <0,1,2> 2.82843 + 1 * <0,1,3> 2.82843 + 1 * <0,2,3> 2.82843 + 1 * <1,2,3> 2.82843
 
What I'd like to do now is see the bars from this output.  My initial impression is this "hfp" object represents the entire chain complex in reduced form. 
 
This persistent homology of our square has four H_0 bars that merge into one at length-parameter 2.  And it has a single H_1 bar that starts at length parameter 2, and dies as 2\sqrt{2}.  Here is how I merge this understanding with the Dionysus output, line-by-line:
 
<0> 0: 
<1> 0: 
<2> 0: 
<3> 0: 
 
These lines say the four vertices labelled <0>, <1>, <2>, <3> appear at length parameter 0.  The fact that there's nothing to the right of the colon indicates bars are created at length-parameter zero. 
 
The lines:
 
<0,1> 2: 1 * <0> 0 + 1 * <1> 0
<0,3> 2: 1 * <0> 0 + 1 * <3> 0
<1,2> 2: 1 * <1> 0 + 1 * <2> 0
 
say at length-parameter 2, the three edges <0,1>, <0,3>, <1,2> are created and they merge the four 0-cycles into one. 
 
The line:
 
<2,3> 2: 
 
indicates the last edge <2,3> is creating a 1-cycle, at side-length 2.  So this helps me.  It's telling me that generally one has to combine these relations to discover the cycle representatives. 
 
The remaining lines are relatively degenerate:
 
<0,2> 2.82843: 
<1,3> 2.82843: 
<0,1,2> 2.82843: 1 * <0,1> 2 + 1 * <1,2> 2 + 1 * <0,2> 2.82843
<0,1,3> 2.82843: 1 * <0,1> 2 + 1 * <0,3> 2 + 1 * <1,3> 2.82843
<0,2,3> 2.82843: 1 * <0,1> 2 + 1 * <0,3> 2 + 1 * <1,2> 2 + 1 * <2,3> 2
<1,2,3> 2.82843: 
<0,1,2,3> 2.82843: 1 * <0,1,2> 2.82843 + 1 * <0,1,3> 2.82843 + 1 * <0,2,3> 2.82843 + 1 * <1,2,3> 2.82843
 
This says at length 2\sqrt{2} two new 1-cycles are created and simultaneously destroyed, but then also a 2-cycle is created and simultaneously destroyed, i.e. bars of length 0. 
 
Thanks, 

representatives of bars, homology classes

Ryan Budney
 

Greetings, 

Say I've computed persistent homology of some RIPS complex in Dionysus.  How does one go the extra step to find a cycle representative in a homology class?  i.e. I would like to identify the bar, and determine which linear combination of simplices represent the bar. 

In the process of writing this question I likely have answered it.  But it would be nice to get confirmation, and perhaps this will be useful to others.

To make this concrete and fairly simple, let me use the vertices of a square of side-length two as my data set.

import dionysus as di

## generate square as a list

A = []
for i in [-1,1]:
    for j in [-1, 1]:
        cv = [i, i]
        cv[1] *= j
        A.append(cv)

## convert to numpy array
A = np.array(A, float)

## generate the associated RIPS complex
X = di.fill_rips(A, 3, 3.0)

## compute persistent homology
hfp = di.homology_persistence(X)

## here is where I get a bit fuzzy.  My understanding is hfp is a reduced
## matrix that describes the persistent homology.  But I'm not certain how 
## to read it.  Here is some code of Dmitriy's that I lifted from a 2018 thread.

for i,c in enumerate(hfp):
  print(X[i],end=': ')
  print(" + ".join(["%d * %s" % (x.element, X[x.index]) for x in c]))

If I execute the above code, I get this as output.

<0> 0:
<1> 0:
<2> 0:
<3> 0:
<0,1> 2: 1 * <0> 0 + 1 * <1> 0
<0,3> 2: 1 * <0> 0 + 1 * <3> 0
<1,2> 2: 1 * <1> 0 + 1 * <2> 0
<2,3> 2:
<0,2> 2.82843:
<1,3> 2.82843:
<0,1,2> 2.82843: 1 * <0,1> 2 + 1 * <1,2> 2 + 1 * <0,2> 2.82843
<0,1,3> 2.82843: 1 * <0,1> 2 + 1 * <0,3> 2 + 1 * <1,3> 2.82843
<0,2,3> 2.82843: 1 * <0,1> 2 + 1 * <0,3> 2 + 1 * <1,2> 2 + 1 * <2,3> 2
<1,2,3> 2.82843: 
<0,1,2,3> 2.82843: 1 * <0,1,2> 2.82843 + 1 * <0,1,3> 2.82843 + 1 * <0,2,3> 2.82843 + 1 * <1,2,3> 2.82843

What I'd like to do now is see the bars from this output.  My initial impression is this "hfp" object represents the entire chain complex in reduced form. 

This persistent homology of our square has four H_0 bars that merge into one at length-parameter 2.  And it has a single H_1 bar that starts at length parameter 2, and dies as 2\sqrt{2}.  Here is how I merge this understanding with the Dionysus output, line-by-line:

<0> 0:
<1> 0:
<2> 0:
<3> 0: 

These lines say the four vertices labelled <0>, <1>, <2>, <3> appear at length parameter 0.  The fact that there's nothing to the right of the colon indicates bars are created at length-parameter zero. 

The lines:

<0,1> 2: 1 * <0> 0 + 1 * <1> 0
<0,3> 2: 1 * <0> 0 + 1 * <3> 0
<1,2> 2: 1 * <1> 0 + 1 * <2> 0

say at length-parameter 2, the three edges <0,1>, <0,3>, <1,2> are created and they merge the four 0-cycles into one. 

The line:

<2,3> 2: 

indicates the last edge <2,3> is creating a 1-cycle, at side-length 2.  So this helps me.  It's telling me that generally one has to combine these relations to discover the cycle representatives. 

The remaining lines are relatively degenerate:

<0,2> 2.82843:
<1,3> 2.82843:
<0,1,2> 2.82843: 1 * <0,1> 2 + 1 * <1,2> 2 + 1 * <0,2> 2.82843
<0,1,3> 2.82843: 1 * <0,1> 2 + 1 * <0,3> 2 + 1 * <1,3> 2.82843
<0,2,3> 2.82843: 1 * <0,1> 2 + 1 * <0,3> 2 + 1 * <1,2> 2 + 1 * <2,3> 2
<1,2,3> 2.82843:
<0,1,2,3> 2.82843: 1 * <0,1,2> 2.82843 + 1 * <0,1,3> 2.82843 + 1 * <0,2,3> 2.82843 + 1 * <1,2,3> 2.82843

This says at length 2\sqrt{2} two new 1-cycles are created and simultaneously destroyed, but then also a 2-cycle is created and simultaneously destroyed, i.e. bars of length 0. 

Thanks, 

-ryan

Re: Wasserstein or Bottleneck Mapping

Dmitriy Morozov
 

In the case of the bottleneck distance, only the longest edge is uniquely defined -- there are many matchings that satisfy the constraints. There is a pull request [1] that provides a way to get this longest edge, but I haven't merged it. You could use that fork directly, if you like. But I do need to merge it as well.


In the case of the Wasserstein distance, Hera (the underlying library) doesn't expose this functionality. It's on our to-do list to fix it, but currently it's not available.

Dmitriy

On Fri, Jun 14, 2019 at 7:01 AM <K.A.Garside2@...> wrote:
Hi Dmitriy,

Is it possible to obtain, using the library, the optimal mapping of points for either the bottleneck or wasserstein distance?

Thanks!

Wasserstein or Bottleneck Mapping

K.A.Garside2@...
 

Hi Dmitriy,

Is it possible to obtain, using the library, the optimal mapping of points for either the bottleneck or wasserstein distance?

Thanks!

Re: Build Under Windows

Dmitriy Morozov
 

Ah, I see. So it's an issue with the distribution of MinGW. That makes sense, and not something that we can fix.

Thanks again for figuring all this out.
Dmitriy

On Thu, Jun 13, 2019 at 8:26 AM <micheal.shoemaker@...> wrote:

I went back and looked more into the MinGW version issue 8.2.0 issue.  Right now, I'm getting:

CMake Error at bindings/python/pybind11/tools/FindPythonLibsNew.cmake:122 (message):
  Python config failure: Python is 64-bit, chosen compiler is 32-bit

Even though gcc -v says it's x86_64.  This is 8.2 installed from MinGW's main page, but this version of gcc uses thread model win32, which causes all kinds of errors even with gcc 8.1.
If I could find a gcc 8.2 with x86_64 and posix thread model, then I believe it will work fine.

Re: Persistent-based segmentation

Dmitriy Morozov
 

I don't really understand your question. The linked messages give a way to get actual cycles (for example, sequences of edges, not just births/deaths). Do you want to do something else?

But I'm really not sure what you are asking. What is a "border of a cycle"? What are the pixels of the images belonging to a cycle? (Other than getting the cycles as described in the messages I linked.) It's also worth noting that there is no uniquely defined cycle that persistence finds. I think you need to try to formalize mathematically what you want to find, then it would be possible to figure out if it's something Dionysus computes.

I also don't understand the strategy you describe: if you want all pixels between value 5 and 22, you don't need Dionysus for that; NumPy can give you these pretty quickly.

In short, I don't think there is an optimized function in Dionysus to do what you want, besides extracting the representative cycles, as described in the messages I linked originally.

Dmitriy

On Thu, Jun 13, 2019 at 5:20 AM Jack <giacomo@...> wrote:
Hi Dmitriy,

did you have any time to think about my question?

Thanks

Re: Build Under Windows

micheal.shoemaker@...
 

I went back and looked more into the MinGW version issue 8.2.0 issue.  Right now, I'm getting:

CMake Error at bindings/python/pybind11/tools/FindPythonLibsNew.cmake:122 (message):
  Python config failure: Python is 64-bit, chosen compiler is 32-bit

Even though gcc -v says it's x86_64.  This is 8.2 installed from MinGW's main page, but this version of gcc uses thread model win32, which causes all kinds of errors even with gcc 8.1.
If I could find a gcc 8.2 with x86_64 and posix thread model, then I believe it will work fine.

Re: Persistent-based segmentation

Jack <giacomo@...>
 

Hi Dmitriy,

did you have any time to think about my question?

Thanks

Re: Build Under Windows

Dmitriy Morozov
 

This is fantastic. Thank you for these instructions. Building on Windows seems to be the most common question, and now we have this write-up to point people to.

Now if I could figure out how to get the conda script to follow these instructions automatically, it would probably eliminate the questions entirely.

I'm a little confused by the MinGW version issues. Can you say a little more about them? You mention version 8.1.0 and 8.2.0. Do you have a sense what the problem is with MinGW 8.2.0? That's probably worth addressing for future sanity.

Thanks again.
Dmitriy

On Wed, Jun 12, 2019 at 1:46 PM <micheal.shoemaker@...> wrote:
I've spent some time trying to get Dionysus 2 to build under Windows.  Here are my notes on getting it to build.  The versions listed are the ones that I used and I have some notes on versions that didn't work.  I hope this can help some people to get this working.

You'll need these dependencies:

MinGW 8.1.0 (The only other version I tried was 8.2.0, which will error on build.)  Download from: https://sourceforge.net/projects/mingw-w64/
- Install with these settings: Version: 8.1.0, Architecture: x86_64, Threads: posix, Exception: seh, Build version: 0
After installing, Copy C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\libexec\gcc\x86_64-w64-mingw32\8.1.0\liblto_plugin-0.dll to C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\lib\bfd-plugins

Boost 1.70 (Boost 1.69 requires a change to the CMakeLists.txt in dionysus.) Download from: https://www.boost.org/

Download and extract to C:\boost\
Add Variable 'BOOST_INCLUDE_DIR' with value 'C:\boost' to the environment variables.
This version of boost will give a warning on build:

BOOST_HEADER_DEPRECATED( "the facilities in <boost/timer/timer.hpp>" )

cmake 3.14.5 Download from: https://cmake.org/download/
Just install, no special notes.

Python 3.7.3 Download from: https://www.python.org/
Be sure to check the box to add to PATH

Build
Then, just clone the git (You may need to install git):

git clone https://github.com/mrzv/dionysus.git

Then run from the dionysus folder (from Powershell):

mkdir build
cd build
cmake -G “MinGW Makefiles” ..
 
mingw32-make.exe 

Then, you can copy the folder C:\path\to\dionysus\build\bindings\python\dionysus into your site-packages folder or project folder.

 

 

 

 

Build Under Windows

micheal.shoemaker@...
 

I've spent some time trying to get Dionysus 2 to build under Windows.  Here are my notes on getting it to build.  The versions listed are the ones that I used and I have some notes on versions that didn't work.  I hope this can help some people to get this working.

You'll need these dependencies:

MinGW 8.1.0 (The only other version I tried was 8.2.0, which will error on build.)  Download from: https://sourceforge.net/projects/mingw-w64/
- Install with these settings: Version: 8.1.0, Architecture: x86_64, Threads: posix, Exception: seh, Build version: 0
After installing, Copy C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\libexec\gcc\x86_64-w64-mingw32\8.1.0\liblto_plugin-0.dll to C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\lib\bfd-plugins

Boost 1.70 (Boost 1.69 requires a change to the CMakeLists.txt in dionysus.) Download from: https://www.boost.org/

Download and extract to C:\boost\
Add Variable 'BOOST_INCLUDE_DIR' with value 'C:\boost' to the environment variables.
This version of boost will give a warning on build:

BOOST_HEADER_DEPRECATED( "the facilities in <boost/timer/timer.hpp>" )

cmake 3.14.5 Download from: https://cmake.org/download/
Just install, no special notes.

Python 3.7.3 Download from: https://www.python.org/
Be sure to check the box to add to PATH

Build
Then, just clone the git (You may need to install git):

git clone https://github.com/mrzv/dionysus.git

Then run from the dionysus folder (from Powershell):

mkdir build
cd build
cmake -G “MinGW Makefiles” ..
 
mingw32-make.exe 

Then, you can copy the folder C:\path\to\dionysus\build\bindings\python\dionysus into your site-packages folder or project folder.

 

 

 

 

Re: Persistent-based segmentation

Dmitriy Morozov
 

I think you'll have to explain better what you are trying to do before I can help you.

You can get cycles (which are not unique) from Dionysus. That question has come up before on this list. For example, see


I'm not sure what you mean by pixels having persistence larger than a given threshold.

Dmitriy

On Wed, Jun 5, 2019 at 9:57 AM Giacomo Nardi <giacomo@...> wrote:

Hi,

I am using the dionysus package to compute persistent homology for images.  I was wondering if there is any function to perform segmentation based on persistence.

How can I select cycles/pixels having persistence larger than a given threshold ?

Thank you
Giacomo

--
Giacomo Nardi | Research Scientist TDI
Mauna Kea Technologies | 9 rue d Enghien – 75010 Paris 
Tel : + 33 1 48 24 03 45 | Fax : + 33 1 48 24 12 18 | www.maunakeatech.com
Cellvizio iPhone App | Follow us on Twitter | Follow us on LinkedIn 

logomaunakeatech.jpg

This message and any attached documents are CONFIDENTIAL and intended only for the use of the intended recipient.
Ce message et tous les documents attachés sont CONFIDENTIELS et à la seule attention du destinataire pour lequel ils ont été écrits.