pulsejet
Feature - show and filter exif tags and rating
This pull request intended to give the possibility to read and write Tags and Rating to and from exif tags. I use Digikam for managing my photos and found one of the most important functions the rating as well as tagging, especially when sharing fotos with others. For maximum compatibility Digikam writes its Tags into multiple fields (TagsList, HierarchicalSubjects, Subjects,...)- that is why this implementation will also evaluate various EXIF tags.
This PR includes the following features:
- it creates a new Table, for caching the embedded tags on a per user basis
- during indexing it will grab all tags (also hierarchical ones) and store them
- it will make rating and embedded tags visible in the Info Panel (unfortunately this can be confusing in combination with the collaborative tags -> don't know how to communicate both concept in an understandable manner to the user)
- Rating can be changed -> it will be stored within the exif data of the photo
- A Filter Panel provides a way to quickly filter by minimum rating and embedded tags (here we make use of the cached tags, that can be accessed through the API)
~~The Filter Panel currently is situated in the RowHeader -> which of course is completely wrong, but it somehow did not work to put it into the SearchBar -> will investigate into it, because this would be the right place probably, I'm also thinking of putting current filter configuration via query parameter for state management, now sometimes it really sucks, as the filter panel does not store it's state correctly if remounted - I need to understand global state management patterns within vue2 better in order to fix that or use the aforementioned method - any ideas?~~
Filter Panel now is situated next to the search field, where it should be:
Tags and Ratings are shown in overview and Slideshow if enabled in the settings:
As a final goal I would find it beneficial if we had the possibility to get a the following behavior concerning tags:
a user should get all embedded tags available from:
- all photos where he is the owner of
- all photos within group folders he has access to
- all photos that are shared at least read only with the user
Tags of other photos not visible to the user should not be accessible by the user as they can reveal sensitive information.
During development I tested it with a clean server and only a handful of photos from a single day - now that I tested it in a more real life scenario I recognize that the filtering is messy, on multiple days , because even though it correctly filters the photos based on search criteria it still shows all days with count = 1 as if those days had photos. Need to work on this and also the filter picker being shown next to every day is really messy....
This looks really interesting. Is it possible to read tags for photos already existing in Memories or do we have to re-scan the whole library?
What happens if tags in the file change themselves? For example, after re-uploading tags changed to Darktable. Tags removed, added, etc.
And can I leave system tags disabled or does the app need to be active?
This looks really interesting. Is it possible to read tags for photos already existing in Memories or do we have to re-scan the whole library?
What happens if tags in the file change themselves? For example, after re-uploading tags changed to Darktable. Tags removed, added, etc.
And can I leave system tags disabled or does the app need to be active?
The tags are read from the file on the fly -> they are in contrast to collaborative tags (which is not the feature of this PR) embedded into the EXIF data of the file and are read every time the photos are queried. The only thing that is being cached is the tags overall, so that when you want to filter for a specific tag it takes all tags that ever have been seen during indexing. This tag cache is user associated, so that users do not have to leak their possibly classified tags to all other users of the same nextcloud instance.
System Tags do not need to be enabled at all. I even thought, we somehow need to communicate this to users even better, because they might get confused with the technically different kinds of tags in their system.
The recent changes I have pushed, bring this PR in a direction of being ready to convert this Draft PR into an actual real PR. I cleaned up a lot of UI quirks - Tag and Rating Filtering is now where it should be - next to the search bar, where one would expect it. Some options have been introduced to allow for opt in of some features, like displaying tags and Rating in the Slideshow or in the Overview. Will document further soon with Screenshots.
Overall this looks very promising. I've started reviewing it but it'll need more time because of the sheer size and testing surface. Hopefully can get this landed this month.
Regarding this not working on mobile for local files, I think that should be expected - only indexed files will show up. Just need to make sure nothing breaks - otherwise local files are secondary priority.
Nice, I am looking forward to you review @pulsejet - I am willing to continue my work also on the mobile app - but I think it's better not to grow the amount of stuff that needs to be reviewed now. Adding the same functionality to the mobile app would be possible - but we will need to implement the exif filtering in an android native way - This will make the app consistent with the web based version. As a faraway vision, I really would like to tag/auto tag all images on my mobile and for example have them uploaded to various nextclouds or nextcloud folders in a federated way based on their tags and rating - including the ability to keep a local low res version for offline usage - but this of course needs to be seen as long term vision. In short term either we have to hide rating and tag filter in the mobile app or we need to put some effort in supporting it there. I am willing to do so but could need some initial assistance -getting this PR reviewed will already be motivation 😉
I just tested the memories app within an emulator and can tell that it is working better than I expected. I also produced some Quick testing setup in order to make it easier in the future to quickly test the app, I might contribute in another PR. I found one bug but this is not related to the app itself, but for the filtering in general. Unfortunately, the selected tags stay visible in the filter panel, even though Filters are cleared. The second bug is that when filtering for hierarchical tags, No results are displayed. Have to investigate further.
https://github.com/user-attachments/assets/01f6db04-a546-490b-bfad-ab7d13eeaf01
@pulsejet Is there anything missing so far? I will convert this into a real PR now ....
After some work on this I decide to give it still some time to fix some bugs and design issues, but it is close to PR
current issues:
- light / dark mode inconsistencies
- rating outline stars not shown
- tags not cleared correctly
- filter config not shown on remount of Filter component
- editing Embedded Tags
- Filtering for ags (currently OR logic -> we need AND logic by default)
Question for the community: Embedded vs Collaborative Tags UX
I'd like to gather feedback on how we should handle the distinction between embedded (EXIF) and collaborative tags. Here are some options I'm considering:
Display & Interaction:
- Show both types in a unified view with distinguishing icons?
- Allow converting embedded tags to collaborative tags (one-way or bidirectional)?
Synchronization:
- ~~Automatic sync between embedded and collaborative tags~~ Not recommended - collaborative tags are visible to all users, so auto-syncing from EXIF would create security/privacy issues by exposing potentially private metadata
- Optional setting to manually write collaborative tags back to EXIF metadata?
User Experience:
- Add tooltips/hints to help new users understand the difference between tag types?
Personally, I'm against automatic syncing due to the privacy concerns, but I'm open to other approaches. What would work best for your workflow?
Optional setting to manually write collaborative tags back to EXIF metadata?
This one seems to be the best compromise
Add tooltips/hints to help new users understand the difference between tag types?
I think this should be a hard requirement, because this tool should be usable and understandable also for casual users fot familiar (yet) with managing metadata.
Personally, I'm against automatic syncing due to the privacy concerns, but I'm open to other approaches. What would work best for your workflow?
Maybe some basic filters? Like "syncing selected tags for this directory"?
but it'll need more time because of the sheer size and testing surface
@bastiion
Maybe this would be a good idea to divide this PR into smaller chunks? ( To make it more reviewable for @pulsejet ).
For example the first PR could contain only extracting exiffs and displaying them as read-only fields, the second one with proper Edit/display GUI+filters and the third one with sync options? 2k lines is a bit too much for proper review.
After some work on this I decide to give it still some time to fix some bugs and design issues, but it is close to PR
current issues:
- light / dark mode inconsistencies
- rating outline stars not shown
- tags not cleared correctly
- filter config not shown on remount of Filter component
- editing Embedded Tags
- Filtering for ags (currently OR logic -> we need AND logic by default)
All of these issues are resolved in latest commits. Also editing tags feels quite convenient to my mind, especially when it comes to multiple photos being selected. Testing and optinios welcome.!
@pktiuk I see your point - and I understand that reviewing that much can take its time - but I am having difficulties to decide what to separate - there is already separation by the commits itself which incrementally lead the development to completion - and the different aspects are also (to my opinion) well organized into separate files and functions where possible and a lot of changes have been commented inline. I'd rather contribute to improve testing especially testing matrix with all supported database backends of the nextcloud, because this provokes most concern to my mind that certain database statements are untested due to my dev setup only testing ~~postgresql~~ MariaDB. If you have ideas on how to chunk the PR please tell me but most likely I won't have time to continue work on this until end of January 2026.
What I really would admire would be a planned online meeting/discussion about general aspects and plans for the plugin and how especially collaborative tasks could be made both usable and secure at the same time, following nextclouds group and user ACLs,... maybe there is some time doing it? @pulsejet could you organize that maybe in th discord development channel?
hey bastiion, this PR sounds very promising, but it seems it is not on the release radar of pulsejet. do you have maybe news on the status?
hey bastiion, this PR sounds very promising, but it seems it is not on the release radar of pulsejet. do you have maybe news on the status?
Unfortunately, no updates, because I had not time so far to break this PR into pieces, I guess it is like @pktiuk pointed out too big to be reviewed, on the other hand I'd really like to here pulsejets opinion on this ...I bump it up on my schedule for this month, but cannot guarantee on the other hand there is really not much to do other then breaking things up into smaller portions while reviewing again and testing with different database setups, ... so if anyone can spend time on this, it would be nice
@pulsejet
I guess it is like @pktiuk pointed out too big to be reviewed, on the other hand I'd really like to here pulsejets opinion on this
Could you tell us what do you think about this PR and that should be done next to let you easily deal with this code?