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

Issue:
Fix ..math:: syntax throughout our docs.
        > > It's as if ..math:: were ignored: Simply indenting a math formula produces the same rendering, as in
> 
> Hmm, that is odd. That math directive is still described in current sphinx docs and no deprecation is mentioned.

@lagru has figured it out: We need to stick with the proper syntax and add a space between `..` and `math`! :clap:

_Originally posted by @mkcor in https://github.com/scikit-image/scikit-image/issues/6544#issuecomment-1259866347_
      


Discussion:

Resolving patch:
diff --git a/skimage/metrics/simple_metrics.py b/skimage/metrics/simple_metrics.py
--- a/skimage/metrics/simple_metrics.py
+++ b/skimage/metrics/simple_metrics.py
@@ -195,7 +195,7 @@ def normalized_mutual_information(image0, image1, *, bins=100):
 
     The normalized mutual information of :math:`A` and :math:`B` is given by::
 
-    ..math::
+    .. math::
 
         Y(A, B) = \frac{H(A) + H(B)}{H(A, B)}
 


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

Issue:
Incorrect order of code and output in rendered applications/plot_thresholding.py
See https://forum.image.sc/t/incorrect-order-of-code-and-output-on-doc-page/73749

Gallery example images are not being placed in the right order. Could be a sphinx-gallery bug?

### Way to reproduce:

- Navigate to https://scikit-image.org/docs/dev/auto_examples/applications/plot_thresholding.html
- Note that the plot underneath the first code snippet is switched with the one for the next

Thanks to @pamitabh for reporting :pray: 


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

https://forum.image.sc/t/incorrect-order-of-code-and-output-on-doc-page/73749/2

Ha, solved it! It's because we have two gallery examples that use the same name. Renaming either [`applications/plot_thresholding.py`](https://github.com/scikit-image/scikit-image/blob/main/doc/examples/applications/plot_thresholding.py) ([HTML](https://scikit-image.org/docs/dev/auto_examples/applications/plot_thresholding.html)) or  [`segmentation/plot_thresholding.py`](https://github.com/scikit-image/scikit-image/blob/main/doc/examples/segmentation/plot_thresholding.py) ([HTML](https://scikit-image.org/docs/dev/auto_examples/segmentation/plot_thresholding.html)) fixes this behavior. 

This is because Sphinx Gallery uses only the file name of each example to name the output images, so those two clash and the output images are scambled. In this case `segmentation/plot_thresholding.py` takes preceedence over `applications/plot_thresholding.py`. We should have noticed, as the first plot contains three columns while the code only declares two. 

Honestly, this bug was kind of rewarding to figure out! :smile:

The quickest fix for the release is probably to rename one of the files; I'll do the PR tomorrow if nobody beats me to it. But long term we should probably make those examples more distinct from each other or merge them.
Yikes! Is it even possible for Sphinx gallery to identify this problem? Should we add a manual check for duplicate filenames? 

Resolving patch:
diff --git a/doc/examples/applications/plot_thresholding.py b/doc/examples/applications/plot_thresholding_guide.py
similarity index 100%
rename from doc/examples/applications/plot_thresholding.py
rename to doc/examples/applications/plot_thresholding_guide.py
diff --git a/doc/examples/segmentation/plot_thresholding.py b/doc/examples/segmentation/plot_thresholding.py
--- a/doc/examples/segmentation/plot_thresholding.py
+++ b/doc/examples/segmentation/plot_thresholding.py
@@ -9,7 +9,7 @@
 
 .. seealso::
     A more comprehensive presentation on
-    :ref:`sphx_glr_auto_examples_applications_plot_thresholding.py`
+    :ref:`sphx_glr_auto_examples_applications_plot_thresholding_guide.py`
 
 """
 


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

Issue:
RAG does not correctly merge weights
## Description

Hi there,
I have a question about the example of merging RAG 1. I just wondering how does the parameters are passed to the identified function max_edge. For example, I wanna merge the node of 1 and 3, as far as I concerned the ‘src’ and ‘dst’ are supposed to be 1 and 3, however, the result is 1 and 5. Moreover, after merging these 2 nodes, if we choose the max weights, the result should be 40 and 20 but we just got 40 and 10. Obviously there is some problems about this part. Here is the link of the [example code](https://scikit-image.org/docs/dev/auto_examples/segmentation/plot_rag.html#sphx-glr-auto-examples-segmentation-plot-rag-py) and the link from the [foum](https://forum.image.sc/t/question-about-the-example-of-merging-rag-from-the-tutorial/51946).



Discussion:
Thanks for raising @sjtugzx! Clearly there is a bug here in how the weights are handled.

Re the ID of the new node, (src, dst) indeed becomes dst if in_place=True, but otherwise, a new node is created, which requires a new node ID. So that bit is behaving as expected.

Resolving patch:
diff --git a/skimage/graph/_rag.py b/skimage/graph/_rag.py
--- a/skimage/graph/_rag.py
+++ b/skimage/graph/_rag.py
@@ -207,7 +207,7 @@ def merge_nodes(self, src, dst, weight_func=min_weight, in_place=True,
             self.add_node(new)
 
         for neighbor in neighbors:
-            data = weight_func(self, src, new, neighbor, *extra_arguments,
+            data = weight_func(self, src, dst, neighbor, *extra_arguments,
                                **extra_keywords)
             self.add_edge(neighbor, new, attr_dict=data)
 


Test patch:
diff --git a/skimage/graph/tests/test_rag.py b/skimage/graph/tests/test_rag.py
--- a/skimage/graph/tests/test_rag.py
+++ b/skimage/graph/tests/test_rag.py
@@ -1,3 +1,4 @@
+import pytest
 from numpy.testing import assert_array_equal
 import numpy as np
 from skimage import graph
@@ -46,6 +47,34 @@ def test_rag_merge():
     assert list(g.edges()) == []
 
 
+@pytest.mark.parametrize(
+    "in_place", [True, False],
+)
+def test_rag_merge_gh5360(in_place):
+    # Add another test case covering the gallery example plot_rag.py.
+    # See bug report at gh-5360.
+    g = graph.RAG()
+    g.add_edge(1, 2, weight=10)
+    g.add_edge(2, 3, weight=20)
+    g.add_edge(3, 4, weight=30)
+    g.add_edge(4, 1, weight=40)
+    g.add_edge(1, 3, weight=50)
+    for n in g.nodes():
+        g.nodes[n]['labels'] = [n]
+    gc = g.copy()
+
+    # New node ID is chosen if in_place=False
+    merged_id = 3 if in_place is True else 5
+
+    g.merge_nodes(1, 3, in_place=in_place)
+    assert g.adj[merged_id][2]['weight'] == 10
+    assert g.adj[merged_id][4]['weight'] == 30
+
+    gc.merge_nodes(1, 3, weight_func=max_edge, in_place=in_place)
+    assert gc.adj[merged_id][2]['weight'] == 20
+    assert gc.adj[merged_id][4]['weight'] == 40
+
+
 def test_threshold_cut():
 
     img = np.zeros((100, 100, 3), dtype='uint8')
Repository: scikit-image/scikit-image

Issue:
Invalid f-string in _warnings
### Description:

```
f4978b1149 skimage/_shared/_warnings.py (Jarrod Millman       2022-10-11 17:14:49 -0700 145)             msg = f"No warning raised matching:\n{{'\n'.join(remaining)}}"
c0a0490eed skimage/_shared/_warnings.py (Steven Silvester     2014-12-23 10:59:47 -0600 146)             raise ValueError(msg)
```

That f-string cannot render correctly.




Discussion:

Resolving patch:
diff --git a/skimage/_shared/_warnings.py b/skimage/_shared/_warnings.py
--- a/skimage/_shared/_warnings.py
+++ b/skimage/_shared/_warnings.py
@@ -142,5 +142,6 @@ def expected_warnings(matching):
             if strict_warnings and not found:
                 raise ValueError(f'Unexpected warning: {str(warn.message)}')
         if strict_warnings and (len(remaining) > 0):
-            msg = f"No warning raised matching:\n{{'\n'.join(remaining)}}"
+            newline = "\n"
+            msg = f"No warning raised matching:{newline}{newline.join(remaining)}"
             raise ValueError(msg)


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

Issue:
Misleading error message with invalid `morphology.skeletonize` method
### Description:

When using `skeletonize` on a 2d numpy array with an invalid method parameter, an error message is shown falsely stating that there is a mismatch in the array dimension. 

I would expect the error message to highlight the incorrect method as the issue rather than incorrect array dimensionality.

Let me know if I can provide any further detail :smi

### Way to reproduce:

```Python
import numpy as np
from skimage.morphology import skeletonize

result = skeletonize(np.ones((5, 5)), method='foo')
```


### Traceback or output:

```Shell
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\james\anaconda3\envs\skan\lib\site-packages\skimage\morphology\_skeletonize.py", line 87, in skeletonize
    raise ValueError(f'skeletonize requires a 2D or 3D image as input, '
ValueError: skeletonize requires a 2D or 3D image as input, got 2D.
```


### Version information:

```Shell
3.10.8 | packaged by conda-forge | (main, Nov 24 2022, 14:07:00) [MSC v.1916 64 bit (AMD64)]
Windows-10-10.0.19044-SP0
scikit-image version: 0.19.3
numpy version: 1.23.5
```



Discussion:
Thanks for the report @jamesyan-git!

This might make a good issue for a first-time contributor — we should add an if clause checking that the method is valid first, then do the dimensionality checks. (e.g. `if method not in {'lee', 'zhang'}: raise ValueError("<error message>")`)
I can confirm the bug. Thanks for the report @jamesyan-git, and I agree with @jni's assessment. :+1: 
Hey, Thanks for marking this as a good first issue, this seems like something I can do and I'll work on it!

Resolving patch:
diff --git a/skimage/morphology/_skeletonize.py b/skimage/morphology/_skeletonize.py
--- a/skimage/morphology/_skeletonize.py
+++ b/skimage/morphology/_skeletonize.py
@@ -73,7 +73,9 @@ def skeletonize(image, *, method=None):
            [0, 0, 0, 0, 0, 0, 0, 0, 0]], dtype=uint8)
 
     """
-
+    if method not in {'zhang', 'lee', None}:
+        raise ValueError(f'skeletonize method should be either "lee" or "zhang", '
+                         f'got {method}.')
     if image.ndim == 2 and (method is None or method == 'zhang'):
         skeleton = skeletonize_2d(image.astype(bool, copy=False))
     elif image.ndim == 3 and method == 'zhang':


Test patch:
diff --git a/skimage/morphology/tests/test_skeletonize.py b/skimage/morphology/tests/test_skeletonize.py
--- a/skimage/morphology/tests/test_skeletonize.py
+++ b/skimage/morphology/tests/test_skeletonize.py
@@ -27,6 +27,11 @@ def test_skeletonize_wrong_dim2(self):
         with pytest.raises(ValueError):
             skeletonize(im, method='zhang')
 
+    def test_skeletonize_wrong_method(self):
+        im=np.ones((5,5))
+        with pytest.raises(ValueError):
+            skeletonize(im, method='foo')
+
     def test_skeletonize_all_foreground(self):
         im = np.ones((3, 4))
         skeletonize(im)
Repository: scikit-image/scikit-image

Issue:
Typo in the formula of the documentation of skimage.restoration.wiener
### Description:

There seems to be a missing "1/..." in the formula of the Wiener filter displayed in the documentation of skimage.restoration.wiener compared to what the code does. The formula reads:
$(|\Lambda_H|^2 + \lambda|\Lambda_D|) \Lambda_H^\dagger$
while the codes does (line 127-128):
$\Lambda_H^\dagger / (|\Lambda_H|^2 + \lambda|\Lambda_D|)$

Hope that might help.




Discussion:
Good catch! Thank you for raising an issue about it. :) 

You're right there is a mismatch in the docstring and actual implementation. From briefly scanning the first linked source it looks like the implementation could be correct (see lines 3 and 4 in Fig. 9 in https://arxiv.org/abs/1004.5538). Not entirely sure though?
@RJournet, would you like to submit a fix updating the docstring? :slightly_smiling_face: 
@lagru I'm not sure about the ":bug: Bug" label here: A bug is something functional, it involves code which runs...
I don't don't have strong feelings on whether it involves code or not, rather if it is "Unexpected or incorrect behavior" of what we distribute to users. In that sense my gut feeling has usually been and is also in this case that outright false or misleading documentation is a bug. 

Though, our labels have always (and maybe intentionally) been a bit fuzzy and it's semantics. I'm happy to update the label name and description if you feel something else might be more fitting. :D But I like having a label that signals "this should be fixed" regardless if code, dependencies or docstrings are involved.
> 

I wish I knew how to do the correction, but I am afraid that it would be way more efficient if someone more used to git would take care of the correction. 

The code looked fine to me. The structure was what I expected to find for a Wiener filter. Anyway, thanks a lot for looking at the issue.

Resolving patch:
diff --git a/skimage/restoration/deconvolution.py b/skimage/restoration/deconvolution.py
--- a/skimage/restoration/deconvolution.py
+++ b/skimage/restoration/deconvolution.py
@@ -72,7 +72,7 @@ def wiener(image, psf, balance, reg=None, is_real=True, clip=True):
     unknown original image, the Wiener filter is
 
     .. math::
-       \hat x = F^\dagger (|\Lambda_H|^2 + \lambda |\Lambda_D|^2)
+       \hat x = F^\dagger \left( |\Lambda_H|^2 + \lambda |\Lambda_D|^2 \right)^{-1}
        \Lambda_H^\dagger F y
 
     where :math:`F` and :math:`F^\dagger` are the Fourier and inverse


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

Issue:
Existing "inpainting" gallery example could use a better (more specific) title.
Creating this issue so we don't lose track of what's been discussed in the conversation _Originally posted by @lagru in https://github.com/scikit-image/scikit-image/pull/6853#discussion_r1149741067_

> @mkcor, just wondering how this relates to [our existing inpainting example ](https://scikit-image.org/docs/dev/auto_examples/filters/plot_inpaint.html#sphx-glr-auto-examples-filters-plot-inpaint-py). I am assuming that the main benefit here is that it's a real world use case?

[...]

> Which prompts the idea that we should update the title of the existing example, so it's less generic than just "inpainting."


Discussion:

Resolving patch:
diff --git a/doc/examples/filters/plot_inpaint.py b/doc/examples/filters/plot_inpaint.py
--- a/doc/examples/filters/plot_inpaint.py
+++ b/doc/examples/filters/plot_inpaint.py
@@ -1,15 +1,16 @@
 """
-===========
-Inpainting
-===========
+===============================
+Fill in defects with inpainting
+===============================
+
 Inpainting [1]_ is the process of reconstructing lost or deteriorated
 parts of images and videos.
 
-The reconstruction is supposed to be performed in fully automatic way by
-exploiting the information presented in non-damaged regions.
+The reconstruction (restoration) is performed in an automatic way by
+exploiting the information present in non-damaged regions.
 
-In this example, we show how the masked pixels get inpainted by
-inpainting algorithm based on 'biharmonic equation'-assumption [2]_ [3]_ [4]_.
+In this example, we show how the masked pixels get inpainted using an
+inpainting algorithm based on the biharmonic equation [2]_ [3]_ [4]_.
 
 .. [1]  Wikipedia. Inpainting
         https://en.wikipedia.org/wiki/Inpainting
@@ -44,12 +45,12 @@
 mask[-180:-160, 70:155] = 1
 mask[-60:-20, 0:20] = 1
 
-# add a few long, narrow defects
+# Add a few long, narrow defects
 mask[200:205, -200:] = 1
 mask[150:255, 20:23] = 1
 mask[365:368, 60:130] = 1
 
-# add randomly positioned small point-like defects
+# Add randomly positioned small point-like defects
 rstate = np.random.default_rng(0)
 for radius in [0, 2, 4]:
     # larger defects are less common


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

Issue:
Outdated comment?
This comment mentions a local import due to timing reasons (#4039):

https://github.com/scikit-image/scikit-image/blob/00177e14097237ef20ed3141ed454bc81b308f82/skimage/data/_binary_blobs.py#L51

However, the import was made global in #5872. Is the comment outdated or should the import have remained local?


Discussion:
I think it's outdated as the replacing import `from .._shared.filters import gaussian` no longer imports `scipy.signal` (as far as I can see). But it does import `from scipy import ndimage as ndi` and I'm not sure if the same logic applies here. @grlee77  do you remember or can you deduct why you changed it this way?

@moi90, thanks for checking in!
Hey, there hasn't been any activity on this issue for more than 180 days. For now, we have marked it as "dormant" until there is some new activity. You are welcome to reach out to people by mentioning them here or on our [forum](https://discuss.scientific-python.org/c/contributor/skimage/22) if you need more feedback! If you think that this issue is no longer relevant, you may close it by yourself; otherwise, we may do it at some point (either way, it will be done manually). In any case, thank you for your contributions so far!

Resolving patch:
diff --git a/skimage/data/_binary_blobs.py b/skimage/data/_binary_blobs.py
--- a/skimage/data/_binary_blobs.py
+++ b/skimage/data/_binary_blobs.py
@@ -49,8 +49,6 @@ def binary_blobs(length=512, blob_size_fraction=0.1, n_dim=2,
     >>> blobs = data.binary_blobs(length=256, volume_fraction=0.3)
 
     """
-    # filters is quite an expensive import since it imports all of scipy.signal
-    # We lazy import here
 
     rs = np.random.default_rng(rng)
     shape = tuple([length] * n_dim)


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

Issue:
A typo in source code comment and document
### Description:

Check the [doc](https://scikit-image.org/docs/stable/api/skimage.transform.html#skimage.transform.EuclideanTransform) and the [source code](https://github.com/scikit-image/scikit-image/blob/441fe68b95a86d4ae2a351311a0c39a4232b6521/skimage/transform/_geometric.py#L1192).
For Eclidian Transform, the homogeneous transformation matrix should be like:

$$
\begin{bmatrix}
a_0&-b_0&a_1\\
b_0&a_0&b_1\\
0&0&1
\end{bmatrix}
$$

which equals to:

$$
\begin{bmatrix}
\cos\theta&-\sin\theta&t_x\\
\sin\theta&\cos\theta&t_y\\
0&0&1
\end{bmatrix}
$$

But now, in both of the source code comment and the document, it’s writen as this:

```
        [[a0  b0  a1]
         [b0  a0  b1]
         [0   0    1]]
```

Check the `__doc__`  in `Class SimilarityTransfrom`，it was written correctly:
```
        [[a0  -b0  a1]
         [b0  a0  b1]
         [0   0    1]]
```

I think maybe it’s a typo here. But it actually confused me for a minute :joy:

[First posted here](https://forum.image.sc/t/is-this-a-tiny-bug-in-source-code-comment-and-document-eclidian-transform-in-skimage-trasform-geometric/94605)


### Way to reproduce:

just found a little typo in code comment

### Version information:

```Shell
3.12.2 | packaged by conda-forge | (main, Feb 16 2024, 20:42:31) [MSC v.1937 64 bit (AMD64)]
Windows-11-10.0.22631-SP0
scikit-image version: 0.22.0
numpy version: 1.26.4
```



Discussion:

Resolving patch:
diff --git a/skimage/transform/_geometric.py b/skimage/transform/_geometric.py
--- a/skimage/transform/_geometric.py
+++ b/skimage/transform/_geometric.py
@@ -1263,9 +1263,9 @@ class EuclideanTransform(ProjectiveTransform):
 
     where the homogeneous transformation matrix is::
 
-        [[a0  b0  a1]
+        [[a0 -b0  a1]
          [b0  a0  b1]
-         [0   0    1]]
+         [0   0   1 ]]
 
     The Euclidean transformation is a rigid transformation with rotation and
     translation parameters. The similarity transformation extends the Euclidean
@@ -1413,9 +1413,9 @@ class SimilarityTransform(EuclideanTransform):
 
     where ``s`` is a scale factor and the homogeneous transformation matrix is::
 
-        [[a0  -b0  a1]
+        [[a0 -b0  a1]
          [b0  a0  b1]
-         [0   0    1]]
+         [0   0   1 ]]
 
     The similarity transformation extends the Euclidean transformation with a
     single scaling factor in addition to the rotation and translation


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

Issue:
invalid colour conversion raises error rather than warning
This seems like a bug in colour conversion.
```python
lab2rgb([0, 0,  28.0])
```
raises `TypeError: 'numpy.float64' object does not support item assignment`

while:
```python
lab2rgb([0, 0,  27.0])
```
works fine.

This difference is because the former results in a negative z-value in _lab2xyz conversion. The intended behaviour seems to be to assign this to 0 and return the n_invalid count back to the caller for warnings to be raised.

However, the attempt to reassign is performed by indexing on the z value (a numpy.float64 object) which raises the type error in the last line here.

https://github.com/scikit-image/scikit-image/blob/2336565966acdcf2bfd6e6a7322c6f1f477fca8e/skimage/color/colorconv.py#L1173C1-L1182C23

A simple fix is for this last line to read z=0 rather than z[invalid] = 0

Should I submit a pull request for this?


Discussion:
Thanks for the report! I can reproduce and this indeed looks like something we should fix. But I don't think `z=0` is the correct fix as `z` can be an array. E.g. 
```python
ski.color.lab2rgb([[0, 0, 28.0]])
```
passes "fine" and should continue to do so. So I think the solution is to ensure that `z` is always an array that can be assigned to. I'd be supper happy to review a PR if you want to submit one! :D Let me know if you need clarification or help with that. 
Hey, I labeled this as a good first issue, in case someone else wants to pick this up. ;)

Resolving patch:
diff --git a/skimage/color/colorconv.py b/skimage/color/colorconv.py
--- a/skimage/color/colorconv.py
+++ b/skimage/color/colorconv.py
@@ -1179,7 +1179,10 @@ def _lab2xyz(lab, illuminant, observer):
     n_invalid = invalid[0].size
     if n_invalid != 0:
         # Warning should be emitted by caller
-        z[invalid] = 0
+        if z.ndim > 0:
+            z[invalid] = 0
+        else:
+            z = 0
 
     out = np.stack([x, y, z], axis=-1)
 


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

Issue:
Consistently use lazy loading for all `skimage.*` submodules
### Description:

With `lazy_loader` successfully being used for `skimage`, `skimage.data` and `skimage.filters` why not use it for every of our public submodules? I see no significant disadvantage here (when using the approach with PYI files) and it is what is proposed in [SPEC 1](https://scientific-python.org/specs/spec-0001/).

Feel free to remove the good first issue label if there are concerns. Otherwise I would suggest to tackle this with separate PRs for each module that copy the examples mentioned above.


Discussion:
No reason not to. 

Resolving patch:
diff --git a/skimage/metrics/__init__.py b/skimage/metrics/__init__.py
--- a/skimage/metrics/__init__.py
+++ b/skimage/metrics/__init__.py
@@ -1,24 +1,3 @@
-from ._adapted_rand_error import adapted_rand_error
-from ._contingency_table import contingency_table
-from ._structural_similarity import structural_similarity
-from ._variation_of_information import variation_of_information
-from .set_metrics import hausdorff_distance, hausdorff_pair
-from .simple_metrics import (
-    mean_squared_error,
-    normalized_mutual_information,
-    normalized_root_mse,
-    peak_signal_noise_ratio,
-)
+import lazy_loader as lazy
 
-__all__ = [
-    "adapted_rand_error",
-    "variation_of_information",
-    "contingency_table",
-    "mean_squared_error",
-    "normalized_mutual_information",
-    "normalized_root_mse",
-    "peak_signal_noise_ratio",
-    "structural_similarity",
-    "hausdorff_distance",
-    "hausdorff_pair",
-]
+__getattr__, __dir__, __all__ = lazy.attach_stub(__name__, __file__)


Test patch: