Deepcell

🚀 Features

<details>
<summary>Improve error handling for `relabel_sequential_lineage` and `is_valid_lineage` willgraf (73)</summary>

`is_valid_lineage` only checks the lineage object itself. However, the lineage object is completely dependent on the `y` label mask. This function has been changed to require the `y` array, and is a much stronger validation of lineages. (Closes 72) This PR changes the `is_valid_lineage` signature, and should be considered a breaking change.

Additionally, `relabel_sequential` has been found to map unknown integers to 0. This caused some confusion that the original `.trk` file had a 0 as a daughter value. When this happens, `relabel_sequential_lineage` will warn the user that the value is getting mapped to 0. This will only happen with invalid lineages.

Finally, the `Track` object has been updated to only call `relabel_sequential_lineage` if the lineage is found to be valid. This should help reduce instantiation time by skipping the relabel step for invalid batches.

</details>

<details>
<summary>Migrate `Track` and `concat_tracks` to `deepcell.data.tracking`. willgraf (79)</summary>

These functions are being updated to use `tf.SparseTensors` to mitigate their memory footprint. However, `tensorflow` is not a dependency of `deepcell-tracking`, and is only used in the `deepcell` package. Fortunately, these functions are purely used in training pre-processing and are not actually used in this package.

This is a breaking change, to use the `Track` or `concat_tracks` functions, please use either `deepcell-tracking<0.5.0` or `deepcell>=0.11.0`.
</details>


🐛 Bug Fixes

<details>
<summary>Fix `norecursedirs` to ignore build directory willgraf (80)</summary>

Tests started failing due to a duplicate test event found in the `build` directory. This should be ignored in `pytest.ini`, but is an erroneous comma in the path. This PR fixes the `norecursedirs` setting.
</details>

<details>
<summary>Fix bad warning message in `is_valid_lineage` willgraf (77)</summary>

There is a bad label in one of the parent checks. This PR updates the message for accuracy.
</details>

<details>
<summary>Validate parent lineage field as well as daughters. willgraf (76)</summary>

73 updated `is_valid_lineage` to do better of all cells. However, there is no extra validation of the `parent` field, which is used in the `isbi_utils` functions.

This PR adds some basic validation of the `parent` lineage field to improve the validation of the lineage objects.
</details>




🧰 Maintenance

<details>
<summary>Drop support for Python 3.5 willgraf (74)</summary>

Python 3.5 has reached EOL. This PR removes support for it.
</details>

<details>
<summary>Bump version to `0.5.0`. willgraf (81)</summary>


</details>

🐛 Bug Fixes

<details>
<summary>Fix bad warning message in `is_valid_lineage` willgraf (77)</summary>

There is a bad label in one of the parent checks. This PR updates the message for accuracy.
</details>

<details>
<summary>Validate parent lineage field as well as daughters. willgraf (76)</summary>

73 updated `is_valid_lineage` to do better of all cells. However, there is no extra validation of the `parent` field, which is used in the `isbi_utils` functions.

This PR adds some basic validation of the `parent` lineage field to improve the validation of the lineage objects.
</details>

🐛 Bug Fixes

<details>
<summary>Validate parent lineage field as well as daughters. willgraf (76)</summary>

73 updated `is_valid_lineage` to do better of all cells. However, there is no extra validation of the `parent` field, which is used in the `isbi_utils` functions.

This PR adds some basic validation of the `parent` lineage field to improve the validation of the lineage objects.
</details>

🐛 Bug Fixes

<details>
<summary>`is_valid_lineage` should check if the daughter ID is valid. willgraf (70)</summary>

If a cell's daughter ID is not a valid track ID, then `is_valid_lineage` will crash due to a `KeyError`. Instead, it should catch this error and note the lineage as invalid.
</details>

🚀 Features

<details>
<summary>Support saving and loading trk/trks data to/from `BytesIO` msschwartz21 (68)</summary>

In the `data-registry`, we often read and write track data in memory in order to facilitate moving data to and from s3 buckets. This PR enables a `io.BytesIO()` object to be passed into `save_trks` and `load_trks` in place of a filepath. Additionally a new utility function `save_track_data` is introduced to serve as a base for `save_trks` and `save_trk` which are wrappers that allow saving to either `trk` or `trks`.
</details>

🚀 Features

<details>
<summary>Change `isbi_utils` from writing files to comparing in memory R-Ding (67)</summary>

What
* Replace writing to GT and result ISBI-style .txt files with saving an array of ISBI-style dictionaries and comparing those.
* Modifying `isbi_utils_tests` to test the new approach

Why
* Comparing in memory is quicker and allows for less chances of error
</details>


🐛 Bug Fixes

<details>
<summary>Cache the entire Python environment to speed up build times. willgraf (66)</summary>

What
* Cache the entire Python environment in the testing GitHub Action workflow.

Why
* [Drastically speed up build times](https://medium.com/ai2-blog/python-caching-in-github-actions-e9452698e98d).

</details>