Avoid uneccesary copies in skimage.morphology.label

[grlee77]

Description

A user on the mailing list brought up an issue related to high memory usage in skimage.morphology.label
https://mail.python.org/pipermail/scikit-image/2017-July/005313.html

This PR makes minor tweaks to label_cython to avoid some unnecessary extra copies of the data.

Specifically, the following line will make three separate copies:

data = np.copy(input_corrected.flatten().astype(DTYPE))

(flatten returns a copy, astype returns a copy, and then np.copy will make another copy!)

I also renamed the variable input to input_ to avoid confusion with the built-in function of the same name. I don't think this should be a problem as label_cython is not exported as part of the public API.

For reviewers

(Don't remove the checklist below.)

• Check that the PR title is short, concise, and will make sense 1 year
  later.
• Check that new functions are imported in corresponding __init__.py.
• Check that new features, API changes, and deprecations are mentioned in
  doc/release/release_dev.rst.

[grlee77]

As each of the copies above is replacing each other, I don't expect this PR improves memory usage much if at all. It should improve performance a bit.

I rescaled the cameraman image up to size 4096x4096 and ran skimage.measure.label on it. Prior to this PR it took 773 ms and afterwards it takes 626 ms (as reported by %timeit).

I think the main reason for the high memory usage reported in that mailing list thread is that the labels are stored in int64 dtype. This means that the labels are 8 times the memory usage of a uint8 input. I don't think there is much way around that without rewriting the routines to allow the label array to mach the integer dtype of the input (perhaps via fused types?).

I don't intend to pursue that in this PR, but it is probably worth still merging it for the minor performance boost.

[grlee77]

There is some sort of PIL-related failure in the doctests that don't seem related to this PR:
https://travis-ci.org/scikit-image/scikit-image/jobs/253015063#L3314

[jni]

Note that the dtype of the labels in no way depends on the dtype of the input, but rather on the number of connected components of the input. This is bounded by input.size // 2, which is not much of a bound, especially if you are having memory issues in the first place. =P

[grlee77]

Note that the dtype of the labels in no way depends on the dtype of the input, but rather on the number of connected components of the input.

right, it is not related to input dtype. I misstated that above. I think 16 bit integers are probably sufficient for the majority of cases, but I guess the question would be whether to use a conservative value like input.size/2 to auto-select or expand the API to allow the user to select a dtype manually if desired.

[emmanuelle]

I would be in favor of having a dtype keyword argument to impose the type, with some warning in the case of overflow. Another trick might be to check the number of connected components at the end of the function, and down-cast the type if int64 was not needed: it will not improve the memory usage during the execution of the function, but it's useful if the user is manipulating the image of labels later on.

[stefanv]

This PR seems good to merge, and then we can start another issue for Emma's suggestion above (I think it's a good one).

[stefanv]

Why rename input to input_?

[soupault]

input is a reserved Python keyword. I endorse this renaming.

[soupault]

@grlee77 could you, please, rebase onto master so to check if the CI is green?

[soupault]

Thanks @grlee77 !