Another question:
When changing a complete folder directory where the images are stored on my hard disc, will tropy be able to identify the whole folder and associate the items with the metadata, or does one have to set the link for every single file?
Thank you.
This is a good question!
First off, I should explain that we want to eventually add a second project variant which combines both metadata and the original photos in single location: i.e., if you import a photo, Tropy would make a full copy of the original and store it in a bundled folder, similar to how Apple Photos manages its library. This approach allows for more portable projects at the cost of flexibility (you can’t spread out the photos across disks or even devices, cater to the requirements of other tools, like an existing Apple Photos library etc.).
That said, we are planning to add detection of missing files (e.g., because you moved an original) and the possibility to fix the link for each photo individually. Obviously, this is only practical if you move the odd file, but not if you move your entire library.
Therefore, we are also planning to store the last known location of the project file in the project’s metadata: this way, if you move both the project file and your photos together, Tropy would be able to update the links automatically (as long as the relative paths between photos and project file stays the same).
Another possibility that we’ve been considering is to add a configurable ‘photo repository base’ path to each project: this way you could configure a base path independently of your project’s location. If you then move all your photos you could just update the base path for Tropy to find all photos again.
Finally, we could expose a kind of filter function, based on regular expressions, to be applied to all file paths in a project.
I think that sums up our current thoughts on the subject.
Ok, this sounds good.
What I found quite nice in testing the beta version is that you can perfectly work with the metadata and the images without the actual image library, e.g. if it is stored on an external hard drive or a server: even the preview quality of the images is sufficient to work with for many purposes. So I guess flexibility is an important issue, if you work with larger collections. The best solution would then be to define for each single project if you want tropy to copy the files or not – if this is possible, I have no idea.
Thank you for the very detailed comments!
Are there any updates on where this is at? I’ve recently been re-organizing my projects and run into some issues (I’m backed up so it’s ok).
I’m working on a workflow for using Tropy that I want to share with our project team and other researchers in my sub-field so need to decide on what is best practice for file and data management as we may be sharing Tropy projects at some point.
We’re currently working on many related issues of ‘portable’ projects (i.e., projects which are easy to share). We will introduce a number of connected project settings that will cover the most common usage scenarios; this is not finished yet, but you can already make a project use photo paths relative to the project file. What this means, in a nutshell, is that you can put your project file into a folder with all your photos, copy the whole folder to a different computer and open the project there (for more, see this thread).
Exactly the bare minimum option that I/we needed! Will update a current project and set up feature ones using the workflow laid out in the other thread. Thanks!