Add DensityFiltration

[gtauzin]

Adds DensityFiltration for binary images.

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• [x] I have read the guidelines for contributing.
• [x] My code follows the code style of this project. I used flake8 to check my Python changes.
• [x] My change requires a change to the documentation.
• [x] I have updated the documentation accordingly.
• [x] I have added tests to cover my changes.
• [x] All new and existing tests passed. I used pytest to check this on Python tests.

[gtauzin]

A general question I have is whether it is clear to the user what passing non-default metric_params means exactly. What is the "cosine distance" between pixels in an image? I haven't yet finished reading the code in detail but just from documentation I find it a bit obscure.

It's a fair point. I guess, most of the time, you won't need to pass non-default metric_params. As far as calculating cosine distances of pixels, I guess if your image have been obtained from a complex preprocessing/ measurement, pixel positions may have strong meaning and you might want to do that. But really, I have never used it. Same goes for point clouds actually (with the exception of our work xD).

[ulupo]

I guess, most of the time, you won't need to pass non-default metric_params

Again today, I didn't write what I meant. I meant "non-default metric", which is more important I guess. I'm playing the part of a user affected by intellectual misery who might not understand even what it means to use a metric in this context. Again, not having looked at the code (somewhat on purpose for my user simulation), I guess that the activated pixels are converted into an integer grid in 2D just as in ImageToPointCloud, and then the metric is just a metric in R^2 applied to these pixels seen as points with integer coordinates?

[gtauzin]

@ulupo I think it would be better to wait right before merging the PR to pull from master so that we have to handle the conflicts only once.

[gtauzin]

I guess, most of the time, you won't need to pass non-default metric_params

Again today, I didn't write what I meant. I meant "non-default metric", which is more important I guess. I'm playing the part of a user affected by intellectual misery who might not understand even what it means to use a metric in this context. Again, not having looked at the code (somewhat on purpose for my user simulation), I guess that the activated pixels are converted into an integer grid in 2D just as in ImageToPointCloud, and then the metric is just a metric in R^2 applied to these pixels seen as points with integer coordinates?

I have updated the transformer description. Is it more understandable now?

[gtauzin]

@ulupo The tests in tests/test_common.py are now failing. Any idea why?

[ulupo]

@gtauzin yes. See https://github.com/giotto-ai/giotto-tda/pull/473#discussion_r492203832

[gtauzin]

@ulupo Apart from your approval on the updated docstring, it's ready to merge for me :)

[gtauzin]

I'm a bit worried about the pybind11 submodule update which is included in this PR. Was it intentional? Could you explain?

No idea, but I reverted it.

I also added inline comments in the code.