Relative data location - Githubissues

saalfeldlab / paintera

GNU General Public License v2.0

100 stars 17 forks source link

Relative data location #343

Closed hanslovsky closed 4 years ago

hanslovsky commented 5 years ago

Fixes #207

hanslovsky commented 5 years ago

With this branch, datasets relative to the project directory can be loaded now, even if the project directory location is changed, e.g. download this project and open it with Paintera built from this branch.

Existing projects are still supported but cannot (currently) be updated automatically to support relative dataset locations. This can be a future milestone but is not a requirement for this feature branch, as far as I am concerned.

hanslovsky commented 5 years ago

Three more questions remain:

[x] Extend to
- [x] raw sources
- [x] channel sources
[x] add "converting" deserializers for
- [x] LabelSourceState
- [x] RawSourceState
- [x] ChannelSourceState
[x] Paths for arbitrary meshes should be relative to project, if appropriate.
[x] Test extensively in actual proof-reading!!
[x] Ask user if conversion is desired when loading a project
[x] Make backup copy of any attributes.json that is being modified

hanslovsky commented 4 years ago

This PR will be ready for testing, soon. I still need to add converting de-serializers for ChannelSourceState and move the source creation from the backend into the individual states. I expect that to be done tomorrow (Wednesday, 2019/11/27) and will deploy for testing ASAP.

hanslovsky commented 4 years ago

I tested with @cpatrickc and it worked for him, as well. This should be ready for a merge but I will add:

a dialog to ask the user if they would like to convert the project
backups of converted attributes files

hanslovsky commented 4 years ago

Now, users can choose if they would like to convert/update deprecated datasets when deserializing a project. Affected attributes files (Paintera proejct, label data if Paintera dataset format is used, and label-to-block-mapping inside label Paintera datasets) are backed up in the same directory as they exist, with a timestamp suffix (.bkp.yyyy-mm-dd_HH-mm-ss).

While implementing this, I found a few bugs in the ChannelSourceStateFallbackDeserializer that I fixed. I believe that this is ready for a merge now (after fixing the merge conflict).

hanslovsky commented 4 years ago

This should be ready for a merge now.