TagStudio
TagStudio copied to clipboard
TagStudioDev
[Feature request] Exporting files with tags to share with friends.
Whenever i have an image i want to share with a friend they currently have to manually add it to their library directory and then tag it themself. If i can select the image inside of the program and have it create a package i can share to them, then they could import that package and have the image along side the tags and have it ready to go.
This feature request relates to https://github.com/TagStudioDev/TagStudio/issues/3 as importing tags would be part of this feature, as when you import the package it would automatically create the tags if they did not exist yet.
Possible implementation
My first thought to go about it is to create an archive file (usually zip files) and inside here you would find the image(s) you want to share alongside the tag information. One way to handle the tags being added is to have a file containing all tags that need to be imported into your tag list and then have a sidecar tag file for each image that contains all of its tags. Another approach is to have a trimmed down version of the library file and use that to import the tags
After the images and tags are packed inside of the archive file can be given a (relatively) unique extension, for example .tsfp (TagStudio File Package). Then whenever tagstudio encounters a file with that name (most likely though an import action from the menu or a drag & drop into the program), it would know that it needs to unpackage it, import the files and add the appropriate tags.
The following is my idea on how this could be implemented, I would love some feedback before I start typing (especially from those who have a better overview over the entire project than me):
In TagStudio the user can select multiple files and click export. This will create an archive containing all of the selected files and a json file similar to the json file currently used to store the library. The json file would contain the metadata for the selected files and only the tags present on at least one selected file (+ their parent tags). (I would only include the "ts-version", "tags" and "entries" fields, since "macros" and "fields" seem unused, the collations feature seems like it's broken/not implemented and the extensions list doesn't really belong there imo.)
When the user clicks import they can select such an archive. TagStudio should then try to match the tags in the metadata file to existing tags and the prompt the user so they can customize per Tag whether they want an existing tag from their library or create a new Tag in the library. The version field in the JSON file could be used to insure that when the structure of the JSON changes, old exports are still correctly imported.
The following is my idea on how this could be implemented, I would love some feedback before I start typing (especially from those who have a better overview over the entire project than me):
In TagStudio the user can select multiple files and click export. This will create an archive containing all of the selected files and a json file similar to the json file currently used to store the library. The json file would contain the metadata for the selected files and only the tags present on at least one selected file (+ their parent tags). (I would only include the "ts-version", "tags" and "entries" fields, since "macros" and "fields" seem unused, the collations feature seems like it's broken/not implemented and the extensions list doesn't really belong there imo.)
When the user clicks import they can select such an archive. TagStudio should then try to match the tags in the metadata file to existing tags and the prompt the user so they can customize per Tag whether they want an existing tag from their library or create a new Tag in the library. The version field in the JSON file could be used to insure that when the structure of the JSON changes, old exports are still correctly imported.
Since work will need to be done creating a less relational and more sharable standalone tag format for #3, that could be leveraged here in addition to exporting files with their data associated to them in some serialized form. And the current JSON library is dying in favor of SQL (#332), so this whole serialization process does not (and probably should not) be tied to the structure of the existing JSON library. As far as sharing files alongside data to be imported elsewhere, I dare say that sidecar files zipped up with their respective files in one bunch may even work.
I'm still workshopping things like the sharable tag structure however, and once there's something I feel is decently robust I'll pass it around to get more input and feedback on.
a less relational and more sharable standalone tag format
what are you thinking of here? aren't tags the way that TagStudio does them fundamentally relational?
As far as I can tell any approach where Tags can be imported into an existing library would need to do some fuzzy matching between imported tags and existing tags to avoid duplication
what are you thinking of here? aren't tags the way that TagStudio does them fundamentally relational?
As far as I can tell any approach where Tags can be imported into an existing library would need to do some fuzzy matching between imported tags and existing tags to avoid duplication
Fuzzy matching with existing tags aside, the relational nature of the tags is what makes the problem tricky. There was some ooold conversations in the Discord about potential solutions to this, but I'm exploring the idea of public (or private) "tag packs" that people can create, potentially rank online, and then use as dependencies with each other. It introduces the fuzzy matching problem as well as hosting and moderation for this kind of stuff, but devising the format itself is the important part. I'm exploring ideas like namespacing packs, letting users create "synonyms" between tags in other packs, etc. I don't have a good or clean solution yet, but it's a messy problem to start with.
Fuzzy matching with existing tags aside, the relational nature of the tags is what makes the problem tricky. There was some ooold conversations in the Discord about potential solutions to this, but I'm exploring the idea of public (or private) "tag packs" that people can create, potentially rank online, and then use as dependencies with each other. It introduces the fuzzy matching problem as well as hosting and moderation for this kind of stuff, but devising the format itself is the important part. I'm exploring ideas like namespacing packs, letting users create "synonyms" between tags in other packs, etc. I don't have a good or clean solution yet, but it's a messy problem to start with.
Ok here is a possible approach that I came up with unrelated to the idea of tag packs:
Basically every tag is part of a tag group which is identified by a GUID, furthermore every library has a GUID as well, therefore identifying a Tag uniquely by the combination of group GUID and Library GUID. If two tags are part of a tag group that means that they mean the same thing (and are equivalent for the purpose of search), but were created in different libraries. When a user would now try to edit an external tag (a tag with a library GUID that doesn't match the current library) TS instead creates a new Tag (with the same group GUID, but with the library GUID of the currently open library) the user can then edit that tag and TS would replace the references to the external tag with the newly created one. It would also be possible to mark two tag (groups) as equivalent. A Tag would also have a modification timestamp, this way when the client sees conflicting information about a tag the client can simply pick the newer information.
(the following is optional and might be overkill) The library GUID could be derived from the public key of a per-library public/private key pair which could then be used to sign the data associated with tags. This way it would be possible to cryptographically verify that tag information (of Tags from that library not other Tags in the same Tag Group) wasn't modified by anyone other than the original creator. This would solve the problem of someone changing information of a tag that they didn't create and giving it a timestamp that is in the future, therefore locking the original author out of sharing an updated tag without using this manipulation themselves. (It wouldn't be desirable to throw data with weird timestamps away, because if the users system time is wrong this could lead to unexpected behaviour)
I tried my best to sum up my thoughts here, but I might have forgotten something.