Skip to content
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

Resctructuring of API #2538

Open
adius opened this Issue Feb 24, 2017 · 3 comments

Comments

Projects
None yet
4 participants
@adius
Copy link

adius commented Feb 24, 2017

While I was building http://feram.co/scikit-image-cheatsheet I noticed several inconsistencies in the scikit-image API. I'll just layout how I would restructure the API. Sorry for any duplicates with other issues and this should probably be split into several issues later 😅😇.

Inconsistent argument names

image vs. img vs. im vs. …

Done in #2617

I think it should be image everywhere.

Outliers:

  • transform.hough_ellipse
  • transform.hough_line
  • transform.hough_line_peaks (@jni says: possibly won't fix — different type of input?)
  • transform.integral_image
  • draw.set_color
  • feature.daisy
  • feature.draw_multiblock_lbp
  • feature.multiblock_lbp

I probably missed a few ...

label vs label_image

I'm in favor of label_image, but I figured pythonistas like unreadable concise shortcuts. I guess label is good as well …
Or maybe it should also be just image?

Outliers:

  • segmentation.find_boundaries
  • segmentation.mark_boundaries

row vs. rvs.rowsvs.rr

Definitely row, rows, col & cols (Actually I'd prefer column and columns, but I guess that's too long for python =D)

There are definitely more inconsistent argument names I just can't remember them right now ...

Create new shapes module

There are so many shapes in the morphology module. I think they deserve their own module. I found kind of surprising to found the shape methods intermingled with the morphology operations.

This means we would have shape.{cube,diamond,disk,octagon,octahedron,rectangle,square,star}

Create new binarize module

Sciunto: See #2121 and #2490

While it makes sense to be able to retrieve the threshold generated by a certain thresholding algorithm, I think most people will simply want to use it to binarize their images. That's why a propose a module corresponding to the thresholds.

  • binarize.isodata(image)
  • binarize.li(image)
  • binarize.local(image)
  • binarize.niblack(image)
  • binarize.otsu(image)
  • binarize.sauvola(image)
  • binarize.triangle(image)
  • binarize.yen(image)
  • binarize.all(image)

They expect an (grayscale) image and return the binarized image. Simple as that.

Also the thresholds should probably be moved to their own module as well.
I mean you already prefix all of them with threshold_. Why not use threshold. and make it a proper module? 😄
Btw: The API of the thresholds is also kind of chaotic. Some return images, some simple values. There should be at least an argument flag for each one to always return an image.

[WIP] - I need to get back to work ... will fill out the rest later =P

@stefanv

This comment has been minimized.

Copy link
Member

stefanv commented Feb 24, 2017

I love your cheat sheet! And thank you for the API review; that's very helpful.

image vs. img vs. im vs. …

This should be image.

label vs label_image

This should be label_image.

row vs. rvs.rowsvs.rr

My feeling here is that we may want to go with rr, cc. "cols, rows" can be confusing, because it suggests "nr_of_cols, nr_of_rows", whereas we want "row_coords, column_coords".

/cc @jni @ahojnnes

Create new shapes module

I'm happy to do this via the standard deprecation path (2 releases).

Create new binarize module

I think the threshold applications should rather be updated to return binary_image, threshold_value. IIRC, there's a discussion about this elsewhere.

Would you be so kind as to file separate issues for all of these?

@tonysyu

This comment has been minimized.

Copy link
Member

tonysyu commented Mar 1, 2017

I love your cheat sheet!

Agreed! That's quite handy

row vs. r vs. rows vs. rr

Personally, I prefer i_row or i_rows (depending on whether it's an int or array of ints), and i_col or i_cols. It instantly distinguishes it from n_rows/n_cols and maps to normal indexing conventions.


Ok, I'll retreat back to my dark corner now. (Sadly, I don't do any image processing anymore, hence my long absence.)

@sciunto

This comment has been minimized.

Copy link
Member

sciunto commented Apr 19, 2017

I'm OK to change img to image in signatures, but I don't think it's necessarily a good idea for variable names in examples. In doctests for example, it's convenient to have a short variable name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.