-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Size of structuring elements a bit inconsistent #4536
Comments
I agree @sciunto, the inconsistency is even more visible looking at the API:
I would harmonize the API using the |
Hi all! I don't think Things like radius vs diameter are another story... We should pick one and stick to it. Given the side length argument for cubes, perhaps diameter is a better option. But, that is a lot of API churn for not a lot of gain. Perhaps something for the 1.0 transition? ;) |
Anisotropic shapes such as This issue can be linked to #4154 and #4464 will help to deal with the API churn ;-) |
Your face says it all. =P My personal preference is to use width/side length/diameter as the parameter. With |
My suggestion is to pass a size parameter for all, corresponding to the bbox:
|
Isn't education one of the goals of skimage? I personally didn't know what happens when selem shape is even, I had to dive in scipy code (which is used internally by skimage) to know what happens in this case: selem's center is shifted left... Not really obvious/intuitive... |
yep! We can educate by saying "diameter must be an odd number" in every docstring. =) |
Well,
Should we then check if What about considering "anisotropic" selem ( |
@jni and @sciunto, I just checked and found that We may then reasonably consider Now, decision have to be taken regarding the name of the parameter controlling the shape of the remaining selem functions to fix this issue and provide a consistent behavior for
As you already noticed, may preference goes to the second option :-). May be other @scikit-image/core members can take part to the decision... |
@rfezzani I found another argument against radius 😜: is the radius of a square the distance from the centre to the side, or to the corner? |
That's why I prefer a more generic word, for which the precise definition is provided in each docstring. |
@jni, seriously? Did I ever said that a square has a radius, (even if it is sometimes True: the 2D ball with L_inf norm is a square)? I really don't understand why this hurts you that much... @sciunto, |
An other argument in favor of |
Hey everyone, |
Please keep it friendly @rfezzani. We are all brothers and sisters trying to reach an optimal solution here 😊 |
@alexdesiqueira / @jni, sorry if you felt it not friendly, it was absolutely not my intention, please put on account of my poor english... |
Btw, irony is not what I call super friendly either ;-) |
You said this:
which was close enough. =) Absolutely agree with everything else that was said — there's no enmity, I absolutely love the work and proposals coming up here, we just need to find a consensus, and preferably have a good time doing it! =D Different people have different preferences, and even in objective cases, reasonable people can come to different conclusions. Eventually, we'll have to make a decision, but there is no urgency. Let's just have people voice their preferences and arguments and eventually we can decide on the least offensive option. =) Semi-exhaustive list of options:
|
Thank you @jni for this good summary.
I am not in favor of this option, since it leaves this issue unfixed...
Apparently not accepted...The API becomes
I am fine with this option, but IMHO we should not support even values.The API becomes with side_length/size
with
This option doesn't address the inconsistency pointed in this issue
|
I think that it is necessary to rethink |
I'm fine with both size and half_size (and half_somethingelse). Just to say also that in threshold_local, the block size must be odd and a check is performed. I don't say it is ever good or bad, it's just to feed the debate. |
I'm not happy with |
I missed out on all the fun :) Why are we providing rectangle and square in the first place? Can't those trivially be created using ones? The others seem not to be controversial, so throwing those out gives us a consistent interface. In terms of wording: radius implies the thing fits into a sphere. That's not always the case for selems. So, can we use size, and always generate square selems? Non-square selems seem like odd constructs anyway. |
(We may have to enforce size odd in most cases.) |
Non-square selems are necessary for lots of applications (e.g., segmentation of cells-like elements). I'd be sad if they cease to exist |
I did not say we should not support them; the question is more whether we provide pre-packaged non-square selems. |
Even if |
I didn't consider that as well. 😅
I think they are useful and should continue where they are. But hey, my two cents only. |
Damn, only |
The problem with the The use of |
Since there is deprecation going on for 0.20, perhaps we must consider this? |
Thank you @sciunto. Is the proposed solution above (introducing the |
Description
looking at the figure in #4528, it let me realize that the size of the structuring elements are a bit inconsistent, a fact I was not particularly aware of.
My use case is the following: while doing some processing, we might want to change the size and the shape of the structuring element. For instance, changing from square to circle, the user must be cautious to apply a factor two to get the same typical size.
Personally, I find this annoying.
The text was updated successfully, but these errors were encountered: