internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: scikit-image/scikit-image

Issue:
data_dir always falling back to legacy_data_dir
## Description

I'm not sure if I'm misunderstanding how I'm supposed to access the new pooch-handled data... but it seems that if all goes according to plan with the download in `data.__init__`, the `data_dir` variable will always fall back on the `legacy_data_dir`.  (i.e. if there's no break statement in the following clause, it will go to the else statement):

https://github.com/scikit-image/scikit-image/blob/f5290e1d0f10426dc8c54dc3046f795b4c2016bc/skimage/data/__init__.py#L168-L175

am I missing something?

PS.  thank you and congrats on the new release!

## Version information
3.8.2 | packaged by conda-forge | (default, Mar 23 2020, 17:55:48) 
[Clang 9.0.1 ]
macOS-10.13.6-x86_64-i386-64bit
scikit-image version: 0.17.0
numpy version: 1.18.4




Discussion:
@hmaarrfk got any ideas on this?

Resolving patch:
diff --git a/skimage/data/__init__.py b/skimage/data/__init__.py
--- a/skimage/data/__init__.py
+++ b/skimage/data/__init__.py
@@ -54,8 +54,7 @@
            'shepp_logan_phantom',
            'stereo_motorcycle']
 
-legacy_data_dir = osp.abspath(osp.dirname(__file__))
-skimage_distribution_dir = osp.join(legacy_data_dir, '..')
+skimage_distribution_dir = osp.join(osp.abspath(osp.dirname(__file__)), '..')
 
 
 import pooch
@@ -169,11 +168,6 @@ def _fetch(data_filename):
 for filename in legacy_registry:
     _fetch(filename)
 
-else:
-    # Without pooch, fallback on the standard data directory
-    # which for now, includes a few limited data samples
-    data_dir = legacy_data_dir
-
 
 def download_all(directory=None):
     """Download all datasets for use with scikit-image offline.


Test patch:
diff --git a/skimage/data/tests/test_data.py b/skimage/data/tests/test_data.py
--- a/skimage/data/tests/test_data.py
+++ b/skimage/data/tests/test_data.py
@@ -1,7 +1,16 @@
+import os
+from urllib import request
+
 import numpy as np
 import skimage.data as data
 from skimage import io
-from skimage._shared.testing import assert_equal, assert_almost_equal, fetch
+from skimage._shared.testing import (
+    assert_equal, assert_almost_equal, fetch, skipif
+)
+
+
+# check whether github is reachable.
+OFFLINE = request.urlopen('https://github.com').getcode() != 200
 
 
 def test_astronaut():
@@ -107,8 +116,24 @@ def test_cell():
     data.cell()
 
 
+@skipif(OFFLINE, reason='No internet connection')
 def test_cells_3d():
     """Needs internet connection."""
     path = fetch('data/cells.tif')
     image = io.imread(path)
     assert image.shape == (60, 256, 256)
+
+
+def test_data_dir():
+    astro = data.astronaut()
+    datadir = data.data_dir
+    assert 'astronaut.png' in os.listdir(datadir)
+
+
+@skipif(OFFLINE, reason='No internet connection')
+def test_download_all():
+    datadir = data.data_dir
+    for filename in os.listdir(datadir):
+        os.remove(os.path.join(datadir, filename))
+    data.download_all()
+    assert len(os.listdir(datadir)) > 50
Repository: scikit-image/scikit-image

Issue:
slic float32 support regression
## Description

As reported by @jklaise in https://github.com/scikit-image/scikit-image/issues/4675#issuecomment-626794531, `slic` no more supports `float32`.

## Way to reproduce
```python
from skimage.segmentation import slic
import numpy as np
im = np.random.rand(28, 28).astype(np.float32)
slic(im)
```

## Version information

```python
3.8.2 (default, Mar 26 2020, 15:53:00) 
[GCC 7.3.0]
Linux-4.4.0-178-generic-x86_64-with-glibc2.10
scikit-image version: 0.16.2
numpy version: 1.18.1
```



Discussion:

Resolving patch:
diff --git a/skimage/segmentation/slic_superpixels.py b/skimage/segmentation/slic_superpixels.py
--- a/skimage/segmentation/slic_superpixels.py
+++ b/skimage/segmentation/slic_superpixels.py
@@ -272,14 +272,14 @@ def slic(image, n_segments=100, compactness=10., max_iter=10, sigma=0,
     n_centroids = centroids.shape[0]
     segments = np.ascontiguousarray(np.concatenate(
         [centroids, np.zeros((n_centroids, image.shape[3]))],
-        axis=-1))
+        axis=-1), dtype=dtype)
 
     # Scaling of ratio in the same way as in the SLIC paper so the
     # values have the same meaning
     step = max(steps)
     ratio = 1.0 / compactness
 
-    image = np.ascontiguousarray(image * ratio, dtype=np.double)
+    image = np.ascontiguousarray(image * ratio, dtype=dtype)
 
     if update_centroids:
         # Step 2 of the algorithm [3]_


Test patch:
diff --git a/skimage/segmentation/tests/test_slic.py b/skimage/segmentation/tests/test_slic.py
--- a/skimage/segmentation/tests/test_slic.py
+++ b/skimage/segmentation/tests/test_slic.py
@@ -1,5 +1,6 @@
 from itertools import product
 
+import pytest
 import numpy as np
 from skimage.segmentation import slic
 
@@ -463,3 +464,11 @@ def test_gray_3d_mask():
     assert_equal(len(np.unique(seg)), 9)
     for s, c in zip(slices, range(1, 9)):
         assert_equal(seg[s][2:-2, 2:-2, 2:-2], c)
+
+
+@pytest.mark.parametrize("dtype", ['float32', 'float64', 'uint8', 'int'])
+def test_dtype_support(dtype):
+    img = np.random.rand(28, 28).astype(dtype)
+
+    # Simply run the function to assert that it runs without error
+    slic(img, start_label=1)
Repository: scikit-image/scikit-image

Issue:
pyramid_gaussian doesn't support float32
## Description

This issue needs to be fixed to allow `ORB` to fully support `float32`

## Way to reproduce
```python
>>> from skimage.transform import pyramid_gaussian
>>> from skimage.data import coins
>>> from skimage import img_as_float32
>>> img = coins()
>>> img_f32 = img_as_float32(img)
>>> [x.dtype for x in pyramid_gaussian(img_f32)]
[dtype('float32'), dtype('float64'), dtype('float64'), dtype('float64'), dtype('float64'), dtype('float64'), dtype('float64'), dtype('float64'), dtype('float64'), dtype('float64')]
```

## Version information

```python
3.8.2 (default, May  7 2020, 20:00:49) 
[GCC 7.3.0]
Linux-4.4.0-178-generic-x86_64-with-glibc2.10
scikit-image version: 0.17.1
numpy version: 1.18.4
```



Discussion:

Resolving patch:
diff --git a/skimage/transform/pyramids.py b/skimage/transform/pyramids.py
--- a/skimage/transform/pyramids.py
+++ b/skimage/transform/pyramids.py
@@ -7,7 +7,7 @@
 
 def _smooth(image, sigma, mode, cval, multichannel=None):
     """Return image with each channel smoothed by the Gaussian filter."""
-    smoothed = np.empty(image.shape, dtype=np.double)
+    smoothed = np.empty_like(image)
 
     # apply Gaussian filter to all channels independently
     if multichannel:


Test patch:
diff --git a/skimage/transform/tests/test_pyramids.py b/skimage/transform/tests/test_pyramids.py
--- a/skimage/transform/tests/test_pyramids.py
+++ b/skimage/transform/tests/test_pyramids.py
@@ -1,4 +1,5 @@
 import math
+import pytest
 import numpy as np
 from skimage import data
 from skimage.transform import pyramids
@@ -6,7 +7,6 @@
 from skimage._shared import testing
 from skimage._shared.testing import (assert_array_equal, assert_, assert_equal,
                                      assert_almost_equal)
-from skimage._shared._warnings import expected_warnings
 
 
 image = data.astronaut()
@@ -135,3 +135,13 @@ def test_check_factor():
         pyramids._check_factor(0.99)
     with testing.raises(ValueError):
         pyramids._check_factor(- 2)
+
+
+@pytest.mark.parametrize('dtype, expected',
+                         zip(['float32', 'float64', 'uint8', 'int64'],
+                             ['float32', 'float64', 'float64', 'float64']))
+def test_pyramid_gaussian_dtype_support(dtype, expected):
+    img = np.random.randn(32, 8).astype(dtype)
+    pyramid = pyramids.pyramid_gaussian(img)
+
+    assert np.all([im.dtype == expected for im in pyramid])
Repository: scikit-image/scikit-image

Issue:
docs link to decorator rather than function itself
e.g. http://scikit-image.org/docs/dev/api/skimage.exposure.html#equalize-adapthist
the `[source]` link goes to the `adapt_rgb` decorator: https://github.com/scikit-image/scikit-image/blob/master/skimage/color/adapt_rgb.py#L35

A quick test locally suggests that at least Sphinx 1.4.5 on Python 3.5.2 is able to link to the inner decorator object instead.



Discussion:
We can test against different sphinx version. Nevertheless, if the latest sphinx versions have a correct behavior, I would say that we can drop this issue as fixed by upstream. As time goes, it's gonna to be fixed by itself (`self.fix()` :) ).

xref https://github.com/scikit-image/scikit-image/issues/1813

I just noticed this and came across this existing issue, so it seems the problem persists. It occurs for  the decorators `change_default_value` and `deprecate_kwarg` as well.

An example from the current dev docs for a function using `@change_default_value`:
https://scikit-image.org/docs/dev/api/skimage.color.html#skimage.color.label2rgb
where the [source] link goes to: https://github.com/scikit-image/scikit-image/blob/master/skimage/_shared/utils.py#L61

Fortunately, the places where those decorators are used aren't very extensive.
I think it's possible to solve this by patching 
https://github.com/scikit-image/scikit-image/blob/86c1d5e8bb06f17830f35f66692a69a14e9315fb/doc/source/conf.py#L395
with [`inspect.unwrap`](https://docs.python.org/3/library/inspect.html#inspect.unwrap) similar to [this example](https://gitlab.com/tud-mst/ptvpy/-/blob/0e1dce0389088004b4da69a2a95e6d70fbbc245d/doc/conf.py#L223-224).

Resolving patch:
diff --git a/doc/source/conf.py b/doc/source/conf.py
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -413,6 +413,9 @@ def linkcode_resolve(domain, info):
         except:
             return None
 
+    # Strip decorators which would resolve to the source of the decorator
+    obj = inspect.unwrap(obj)
+
     try:
         fn = inspect.getsourcefile(obj)
     except:


Test patch:
Repository: scikit-image/scikit-image

Issue:
sigma_range not used in denoiser calibration examples
The variable `sigma_range` is defined in both tutorials, but a different range and in-line instantiation of the sigma range is used when the `parameter_ranges` dict is defined:

https://github.com/scikit-image/scikit-image/blob/f71be82423e73cda4f3026a0eb656614db937bbc/doc/examples/filters/plot_j_invariant.py#L39-L41

https://github.com/scikit-image/scikit-image/blob/f71be82423e73cda4f3026a0eb656614db937bbc/doc/examples/filters/plot_j_invariant_tutorial.py#L44-L46 

In the latter "full" tutorial, this seems to be limited to just the wavelet denoiser calibration portion, which appears to be a copy/paste of the former "short" tutorial.


Discussion:
Hi @notmatthancock thanks for reporting this, it indeed looks like we had a copy and paste mistake here! Could you be interested in correcting this and submitting a pull request? Thanks either way :-).

Resolving patch:
diff --git a/doc/examples/filters/plot_j_invariant.py b/doc/examples/filters/plot_j_invariant.py
--- a/doc/examples/filters/plot_j_invariant.py
+++ b/doc/examples/filters/plot_j_invariant.py
@@ -36,8 +36,6 @@
 noisy = random_noise(image, var=sigma ** 2)
 
 # Parameters to test when calibrating the denoising algorithm
-sigma_range = np.arange(0.05, 0.5, 0.05)
-
 parameter_ranges = {'sigma': np.arange(0.1, 0.3, 0.02),
                     'wavelet': ['db1', 'db2'],
                     'convert2ycbcr': [True, False],
diff --git a/doc/examples/filters/plot_j_invariant_tutorial.py b/doc/examples/filters/plot_j_invariant_tutorial.py
--- a/doc/examples/filters/plot_j_invariant_tutorial.py
+++ b/doc/examples/filters/plot_j_invariant_tutorial.py
@@ -41,8 +41,6 @@
 noisy = random_noise(image, var=sigma ** 2)
 
 # Parameters to test when calibrating the denoising algorithm
-sigma_range = np.arange(0.05, 0.5, 0.05)
-
 parameter_ranges = {'sigma': np.arange(0.1, 0.3, 0.02),
                     'wavelet': ['db1', 'db2'],
                     'convert2ycbcr': [True, False],


Test patch:
Repository: scikit-image/scikit-image

Issue:
RuntimeWarning in blob.py (division by zero)
see for example the warning in https://scikit-image.org/docs/dev/auto_examples/features_detection/plot_blob.html#sphx-glr-auto-examples-features-detection-plot-blob-py 

The warning is initiated in the `_blob_overlap` function.

Also mentioned in the forum https://forum.image.sc/t/runtime-warning-with-blob-detection-when-threshold-is-too-low/37965


Discussion:
This issue has been mentioned on **Image.sc Forum**. There might be relevant details there:

https://forum.image.sc/t/runtime-warning-with-blob-detection-when-threshold-is-too-low/37965/5

Oh this `imagesc-bot` is nice :-). 
@emmanuelle when sigma of both the blobs are 0 (i.e., ``radius of blobs = sqrt(2) * sigma = 0``) we can return the _blob_overlap as 0.0 right? Please check below which would resolve the issue and let me know your comments.

```
if blob1[-1] == 0 and blob2[-1] == 0:
    return 0.0
elif blob1[-1] > blob2[-1]:
    max_sigma = blob1[-sigma_dim:]
    r1 = 1
    r2 = blob2[-1] / blob1[-1]
else:
    max_sigma = blob2[-sigma_dim:]
    r2 = 1
    r1 = blob1[-1] / blob2[-1]
```
@dsandeep0138 I think that fix would work! If you could open a PR (including a test), that would be wonderful!

Resolving patch:
diff --git a/skimage/feature/blob.py b/skimage/feature/blob.py
--- a/skimage/feature/blob.py
+++ b/skimage/feature/blob.py
@@ -115,7 +115,9 @@ def _blob_overlap(blob1, blob2, *, sigma_dim=1):
 
     # we divide coordinates by sigma * sqrt(ndim) to rescale space to isotropy,
     # giving spheres of radius = 1 or < 1.
-    if blob1[-1] > blob2[-1]:
+    if blob1[-1] == blob2[-1] == 0:
+        return 0.0
+    elif blob1[-1] > blob2[-1]:
         max_sigma = blob1[-sigma_dim:]
         r1 = 1
         r2 = blob2[-1] / blob1[-1]


Test patch:
diff --git a/skimage/feature/tests/test_blob.py b/skimage/feature/tests/test_blob.py
--- a/skimage/feature/tests/test_blob.py
+++ b/skimage/feature/tests/test_blob.py
@@ -1,3 +1,5 @@
+import pytest
+
 import numpy as np
 from skimage.draw import disk
 from skimage.draw.draw3d import ellipsoid
@@ -191,6 +193,20 @@ def test_blob_log():
     assert blob_log(img_empty).size == 0
 
 
+def test_blob_log_no_warnings():
+    img = np.ones((11, 11))
+
+    xs, ys = disk((5, 5), 2)
+    img[xs, ys] = 255
+
+    xs, ys = disk((7, 6), 2)
+    img[xs, ys] = 255
+
+    with pytest.warns(None) as records:
+        blob_log(img, max_sigma=20, num_sigma=10, threshold=.1)
+    assert len(records) == 0
+
+
 def test_blob_log_3d():
     # Testing 3D
     r = 6
Repository: scikit-image/scikit-image

Issue:
Pillow security alert
## Description

Github just gave us a notice that Pillow versions earlier than 7.1.0 have a security vulnerability involving out of bounds reads. See https://github.com/scikit-image/scikit-image/network/alert/requirements/default.txt/Pillow/open for details.

Question: do we want to bump up our dependency to something as recent as 7.1.2, or do we leave this as a "user beware" type of situation?


Discussion:

Resolving patch:
diff --git a/skimage/io/_plugins/pil_plugin.py b/skimage/io/_plugins/pil_plugin.py
--- a/skimage/io/_plugins/pil_plugin.py
+++ b/skimage/io/_plugins/pil_plugin.py
@@ -7,6 +7,17 @@
 
 from ...util import img_as_ubyte, img_as_uint
 
+# Check CVE-2020-10379
+from distutils.version import LooseVersion
+if LooseVersion(pil_version) < LooseVersion('7.1.0'):
+    from warnings import warn
+    warn('Your installed pillow version is < 7.1.0. '
+         'Several security issues (CVE-2020-11538, '
+         'CVE-2020-10379, CVE-2020-10994, CVE-2020-10177) '
+         'have been fixed in pillow 7.1.0 or higher. '
+         'We recommend to upgrade this library.',
+         stacklevel=2)
+
 
 def imread(fname, dtype=None, img_num=None, **kwargs):
     """Load an image from file.
diff --git a/skimage/io/collection.py b/skimage/io/collection.py
--- a/skimage/io/collection.py
+++ b/skimage/io/collection.py
@@ -8,7 +8,18 @@
 from copy import copy
 
 import numpy as np
-from PIL import Image
+from PIL import Image, __version__ as pil_version
+
+# Check CVE-2020-10379
+from distutils.version import LooseVersion
+if LooseVersion(pil_version) < LooseVersion('7.1.0'):
+    from warnings import warn
+    warn('Your installed pillow version is < 7.1.0. '
+         'Several security issues (CVE-2020-11538, '
+         'CVE-2020-10379, CVE-2020-10994, CVE-2020-10177) '
+         'have been fixed in pillow 7.1.0 or higher. '
+         'We recommend to upgrade this library.',
+         stacklevel=2)
 
 from tifffile import TiffFile
 


Test patch:
Repository: scikit-image/scikit-image

Issue:
Incorrect deprecation message for `draw.circle`
## Description

`draw.circle` is deprecated in favour of `draw.disk`. But the deprecation warning says that it's deprecated in favour of `disk.circle`! 🤦 Oops!

## Way to reproduce

```python
from skimage import draw
_ = draw.circle(5, 5, 5)  # r, c, radius
```

gives


```pytb
FutureWarning: circle is deprecated in favor of disk.circle will be removed in version 0.19
```

## Version information

```
skimage 0.17.2/master
```

Incorrect deprecation message for `draw.circle`
## Description

`draw.circle` is deprecated in favour of `draw.disk`. But the deprecation warning says that it's deprecated in favour of `disk.circle`! 🤦 Oops!

## Way to reproduce

```python
from skimage import draw
_ = draw.circle(5, 5, 5)  # r, c, radius
```

gives


```pytb
FutureWarning: circle is deprecated in favor of disk.circle will be removed in version 0.19
```

## Version information

```
skimage 0.17.2/master
```



Discussion:
I think it was supposed to say "circle is deprecated in favor of disk. circle will be removed in version 0.19"
I think it was supposed to say "circle is deprecated in favor of disk. circle will be removed in version 0.19"

Resolving patch:
diff --git a/skimage/draw/draw.py b/skimage/draw/draw.py
--- a/skimage/draw/draw.py
+++ b/skimage/draw/draw.py
@@ -174,9 +174,8 @@ def circle(r, c, radius, shape=None):
             This function is deprecated and will be removed in scikit-image 0.19.
             Please use the function named ``disk`` instead.
     """
-    warnings.warn("circle is deprecated in favor of "
-                  "disk."
-                  "circle will be removed in version 0.19",
+    warnings.warn("`draw.circle` is deprecated in favor of `draw.disk`."
+                  "`draw.circle` will be removed in version 0.19",
                   FutureWarning, stacklevel=2)
     return disk((r, c), radius, shape=shape)
 


Test patch:
diff --git a/skimage/draw/tests/test_draw.py b/skimage/draw/tests/test_draw.py
--- a/skimage/draw/tests/test_draw.py
+++ b/skimage/draw/tests/test_draw.py
@@ -215,7 +215,7 @@ def test_polygon_exceed():
 
 
 def test_circle_deprecated():
-    with expected_warnings(['circle is deprecated']):
+    with expected_warnings(['`draw.circle` is deprecated']):
         _ = circle(7, 7, 6)
Repository: scikit-image/scikit-image

Issue:
0.18.0 : Doc error for skimage.filters.prewitt_h/v
The documentation tells that skimage.filters.prewitt_h and skimage.filters.prewitt_v are using 3x3 filters
[[1 1 1] [0 0 0 ] [-1 -1 -1]] and [[1 0 -1][1 0 -1][1 0 -1]]
Actually, the implementation seems to only use [1 0 1] and [[1][0][-1]], which give different results.

For instance :
```
I = np.array([[4., 4., 4.],[3., 3., 3.],[2., 2., 2.]])
J = skimage.filters.prewitt_h(I) //returns unexpected [[-1. -1. -1.], [-2. -2. -2.], [-1. -1. -1.]]
```


Discussion:
Can you specify how this differs from your expected results? For such a small input, the result will vary a lot depending on which boundary `mode` is selected. Only the center pixel in your example does not involve inclusion of any boundary elements within the filter kernel and it appears correct to me.

At least since release 0.17.0, the `prewitt` function is a general n-dimensional implementation, that builds up an n-d difference kernel by broadcasting 1d kernels appropriately. In 2d this ends up being [1/3, 1/3, 1/3] along one axis and [1, 0, -1] along the other to give exactly the 3x3 kernel you have listed above (albeit scaled by 1/3). It is true that this factor 1/3 scaling is not reflected in the `prewitt_h` or `prewitt_v` docstrings, so I think that could be improved. 

For reference, the [n-dimensional kernel construction code is here](https://github.com/scikit-image/scikit-image/blob/v0.17.2/skimage/filters/edges.py#L173-L181).

I talked about the center element to exclude border effect and discussion about edges stategies.
But according to the doc, the center element should be (-1*4)+(-1*4)+(-1*4)+(0*3)+(0*3)+(0*3)+(1*2)+(1*2)+(1*2), aka -12+6=-6

[https://scikit-image.org/docs/dev/api/skimage.filters.html#prewitt-h](https://scikit-image.org/docs/dev/api/skimage.filters.html#prewitt-h)


Okay, so it is the factor of 3 difference you are referring to. It looks like it is just a matter of updating the docstring, to include the normalization factor. I checked and it looks like the Prewitt functions were introduced in release `0.14` and extended to n-dimensional in 0.17, but have always had this scaling since that time.

Let me know whether or not you want to make a documentation fix PR for that. If not, we can take care of it. Thanks
I am not a regular user, so I would not be very good at following the style.
I prefer that you write it the good way.
Sure, no problem. Thanks for reporting the issue

Resolving patch:
diff --git a/skimage/filters/edges.py b/skimage/filters/edges.py
--- a/skimage/filters/edges.py
+++ b/skimage/filters/edges.py
@@ -510,9 +510,9 @@ def prewitt_h(image, mask=None):
     -----
     We use the following kernel::
 
-      1   1   1
-      0   0   0
-     -1  -1  -1
+      1/3   1/3   1/3
+       0     0     0
+     -1/3  -1/3  -1/3
 
     """
     check_nD(image, 2)
@@ -540,9 +540,9 @@ def prewitt_v(image, mask=None):
     -----
     We use the following kernel::
 
-      1   0  -1
-      1   0  -1
-      1   0  -1
+      1/3   0  -1/3
+      1/3   0  -1/3
+      1/3   0  -1/3
 
     """
     check_nD(image, 2)


Test patch: