Don't write into the location of the dummy pixel_indices coordinate

[GenevieveBuckley]

@jni and I talked about how pixel_indices in csr.py always contains a dummy "coordinate" [0, 0], regardless of whether that pixel coordinate is part of the skeleton or not.

@jni says it's supposed to be there in pixel_indices for padding, so you can directly index into it using the pixell id number. This doesn't hold if you use the default unique_junctions=True kwarg, but will be the case if unique_junctions=False.

Anyway, we shouldn't be using this dummy coordinate to write into arrays. Currently skan is overwriting a zero value with another zero, which doesn't matter much. It is confusing when you start to poke around into how we could make this work in a distributed context.

[GenevieveBuckley]

Tiny demo of what you get out of pixel_indices for some basic examples

Coordinate [0,0] is True in skeleton array

skel = np.array([
    [1, 1, 0],
    [1, 0, 0],
    [0, 0, 0]])

>>> pixel_indices
array([[0., 0.],  # dummy coordinate, should not be used for anything
       [0., 0.],  # repeats!
       [0., 1.],
       [1., 0.]])

Coordinate [0,0] is False in skeleton array

skel = np.array([
    [0, 1, 1],
    [0, 0, 1],
    [0, 0, 0]])

>>> pixel_indices
array([[0., 0.],  # dummy coordinate, should not be used for anything
       [0., 1.],
       [0., 2.],
       [1., 2.]])

EDIT: this is before any unique_junctions computation on the indices

[coveralls]

Coverage remained the same at 99.453% when pulling 2113671 on GenevieveBuckley:skip-padding-coord into dcf54da on jni:master.

[jni]

@GenevieveBuckley Will review later today, but see also #93 for more context.

[jni]

... where by "later" I meant "in exactly one minute" 😂