[Change Request] Drop Tag Albums And Improve Real Albums Instead

[nagmat84]

Thoughts on Tag Albums

Finally, I managed to write up and consolidate my thoughts on tag albums vs. real albums. As you may know, I am in strong favor to drop tag albums as they complicate matters, have some flaws which cannot be fixed easily and will always interfer with real albums badly. We already had a discussion in issue #1123 wich was off-topic there and which I would like to pick up now.

However, for the course of discussion I would like to consider real albums in way how the should ideally be implemented and not how they are implemented right now. As it turns out, many of the actual reasons why people argue for tag albums are not that tag albums provide any legit advantage but because they use tag albums as a work-around for bugs with real albums.

Intro

From a theoretical point, any scheme which uses tag albums can be mapped to a scheme which uses real albums and vice versa. We have an (m:n)-relation between photos and tags albums using tags and a (m:n)-relation between photos and albums. In principle, there are two independent approaches how photos can be organized:

1. "Tag albums only": One has a huge pile of photos and one assigns tags to photos. Alongside one has a hierarchy of tag albums and photos appear in albums based on their tags.
2. "Real albums only": Photos are assigned to albums in a (m:n)-relation. Albums are organized hierarchically.

I am aware of the fact, that we neither fully support 1 nor 2 at the moment. With respect to 1, we don't support hierarchical tag albums. With respect to 2, we only have a "fake" (m:n)-relationship between photos and albums in the sense that the DB entry of a photo is duplicated but the actual media files are not. Anyway, if 1 or 2 were as they should be, then either 1 or 2 would fully suffice and cover all needs. In particular, any scheme you have with 1 can also be achieved with 2. I gave an example in issue #1123.

Discussion

Now, let's consider the reasons which are typically given to advocate for tag albums.

1. Tag albums allow to have the same photo in more than one album without actually duplicating it While it is true, this is not an advantage particular to tag albums. The media files of photos are not duplicated for albums either. Duplication of DB entries could be avoided, too, if we finally introduced a proper (m:n)-relation between photo and albums.

2. Tag albums are more convenient, because editing the meta data of one photo is reflected by all instances of this photos in all tag albums True, but see 1. This would also hold for real albums, if we finally introduced a proper (m:n)-relation between photo and albums. Actually, we have an inconsistent situation at the moment due to our "fake" (m:n)-relation between photos and albums. If some meta information of a photo in a real album are edited, than the change is not reflected by all copies of the photo. But if a photo is rotated, all instances of the photo in all real albums are updated, too, because the media file only exist once.

3. Tag albums are more convenient, because one can see from the information panel of a photo which tags are assigned to a photo True again, but this could also be solved by a proper (m:n)-relationship. Even with our "fake" (m:n)-relationship we could implement such a feature. This is something I really miss, too.

4. Tag albums are more convenient, because if one deletes a photo one can be sure that it is deleted from all tag albums Again, this can also be solved with true albums, especially if we had 3. If a photo is in more than one album and one deletes the photo, the warning dialog which is shown right now could be enhanced to show all other albums and ask for a decision whether only this single instance of the photo shall be delete or all instances of the photo.

5. Adding a tag to a photo is much faster than copying a photo to another (real) album This is essentially the claim of issue #1123. This is true at the moment, but the comparison is unfair because it compares apples with oranges.

   1. One adds tags to a photo by manually typing in a list of comma-separated tags via the keyboard. This is fast if one knows the tags by heart, but has the major disadvantage that it is error-prone. If one mistypes a tag, there is no feedback or error message. It silently fails in the sense that the photo won't appear in the desired album as expected, because the tags mismatch.
   2. Copying a photo to another album requires to pick the destination album from the web interface. This has the advantage, that one can browse to the targeted album and one does not need to know the exact name of the target album in advance. Moreover the GUI rules out errors, because it only allows to select albums which really exist. The drawback is that the GUI is rather slow for >1k albums.

   Actually, this problem is not about tag albums vs. real albums. For proper support of tag albums, there should be some kind of auto-completion for tags or an option to only select existing tags from a list which one has pre-filled earlier. To properly support copying between real albums, I envision a dialog which a) does not show the entire tree of albums fully expanded and b) also allows a "live filtering" through keyboard input. Especially a) will always be a pain in the ass for large installations.

Summary

I hopefully managed to argue that either a system which supports "tag albums only" or a system which supports "real albums only" is equally good. In particular, if both approaches were implemented properly, they wouldn't be so much differently at all. However, I am strongly against supporting both simultaneously, because the will always interfere with each other badly due to many aspects which a haven't mentioned above yet (e.g. access permissions, public visibility, etc.) So in the long run, I would either drop on of them and only support one. Given the fact that "real albums" are much more mature, I would keep that system. In particular, I whole permission and visibility system is based on the real albums. The only aspects which need to be fixed are a proper (m:n)-relation between photos and albums plus some adjustments to the front-end:

1. an info panel that also shows the other albums of a photo
2. an improved deletion dialog
3. an improved dialog for copying photos

Moreover, I would recall and old proposal of mine to rethink if we can come up with better names for some of the actions like "duplicate", "copy to", "delete", etc. I am convinced, that people want to have tag albums, because currently they don't know that "copying" photos to real albums does not actually duplicate the photo. This is some misconception with frequently comes up in the description of many issues.

[nagmat84]

Some related issues:

• Issue #1140 problem would be gone
• Issue #1095 covers/includes this idea
• Issue #937 problem would be gone
• Issues #367 Auto-completion of tags
• Issue #42 problem would be gone
• Issue #847 related idea also posted by me

[d7415]

Some points, in no particular order (but if I don't write them I'll never get around to it):

• Can someone think of a sensibly use-case for one photo with different sets of metadata? To me that's the main point against the (m:n) thing (I can't think of an example though).
• I would expect anyone seeing a photo to see which tags it has, but only albums that they have access to.
• Subject to permissions, a list of albums sounds like a really good idea.
• A tag album, as far as I can see is a saved search. This could still exist separately, but probably with clearer separation?
• Proposing existing tags when adding tags could be useful separate from tag albums.
• I'm not entirely opposed to changing verbs ("copy to", etc) but I think we'd be hard pushed to find ones that are clearer about that aspect without causing confusion elsewhere.

[nagmat84]

* Can someone think of a sensibly use-case for one photo with different sets of metadata? To me that's the main point against the (m:n) thing (I can't think of an example though).

Yes, I do: description. However, this can still be solved with a proper (m:n)-relation and attributes on this relation. For example, you may want to have an album-independent description of the photo. This could be something like "persons from left to right: bla, bla, blub". This description exists as part of the photo. Then there is an album-specific relation. This may occur, if you "tell" a certain story with the photos in a particular album and the description only makes sense for the photo in combination with the other photos in the same album. This description would exist as a column on the (m:n)-relation.

However, I would actually make both attributes available through the photo info panel and call them exactly like this: "photo description (album independent)" and "album-specific description".

* I would expect anyone seeing a photo to see which tags it has, but only albums that they have access to.

Surely true. But is this supposed to be an argument against or in favor of my proposition?

* A tag album, as far as I can see is a saved search. This could still exist separately, but probably with clearer separation?

Yes, I also consider tag albums as a "saved search". Of course, we can keep them separately with the same feature set we have right now. The only reason, I would like to get rid of them is that they are always a source for issues/wishes of improvement/complains, because they are simply there and people want to use them in a way how the cannot be used.

* Proposing existing tags when adding tags could be useful separate from tag albums.

Of course, but this requires to move all tags to an independent relation tags and then have two (m:n) relations between photos and tags and tags and albums. This reminds me on another argument I forgot. See next post.

[nagmat84]

One more argument why we might drop tag albums: efficiency.

At the moment it is not possible to eagerly load the thumbnails of all tags albums using a single SQL query due to the way how tags are implemented right now. The tags of a photo and an album are stored as strings of comma-separated lists in photos and albums (or tag_albums). In order to query for all photos in a tag album we need to manually construct an SQL query using string functions on the PHP level. Each SQL query is specific to for each tag album (i.e. the number of clauses in the WHERE-condition depends on the tag album).

If we wanted to improve that and also to solve the other issues I already have mentioned (like tag auto-completion) we would need a proper table tags and two (m:n)-relations: one from photos to tags and one from tags to albums. Then allows auto-completion and selecting covers for a list of tag albums could be properly implemented using a JOIN-query.

However, this train of thoughts clearly shows that tag albums and reals albums are not that very much different. The former requires two (m:n)-relations with the additional indirection of tags, the latter only a single (m:n)-relation.

[d7415]

Yes, I do: description.

:+1:

However, I would actually make both attributes available through the photo info panel and call them exactly like this: "photo description (album independent)" and "album-specific description".

I'd be inclined to hide these if empty (or combine if one is empty) except when editing, but that's a UX choice. Your proposal seems sensible.

Surely true. But is this supposed to be an argument against or in favor of my proposition?

Neither :)

Of course, but this requires to move all tags to an independent relation tags and then have two (m:n) relations between photos and tags and tags and albums. This reminds me on another argument I forgot. See next post.

I hadn't realised tags applied to "normal" albums. Or did you mean "doing this while keeping tag albums" (for the 2 relations)?

[nagmat84]

I hadn't realised tags applied to "normal" albums. Or did you mean "doing this while keeping tag albums" (for the 2 relations)?

The latter. I am clearly in favor to drop tag albums and only keep real albums. But if there were strong opinions to keep the tag album (why ever) and if we wanted to make them more useful by fixing some of the issues, then we would need two (m:n)-relations. However, IMHO this exactly is an argument why tag albums should be dropped.

[haivala]

I did not read this wall of text fully but maybe consider using tree structure for the real albums: https://github.com/LycheeOrg/Lychee/issues/383

[nagmat84]

I did not read this wall of text fully but maybe consider using tree structure for the real albums: #383

Thanks for your contribution. First of all, real albums can already be organized in a tree structure.

Issue #383 asks for mixed-ownership trees and/or a better ACL support for albums such that albums can also be shared with other users for joined writing. While I would really love to see something like that in Lychee at some future day, I don't see how this is anyway related to this issue.

If issue #383 is related in any way at all, I would take that as an argument for dropping tag albums, because a proper implementation of real albums with support for ACL in combination with tag albums is nearly impossible.

[kamil4]

This is a complicated topic and I haven't yet formed a firm opinion but here are my current thoughts:

• What exactly would we gain by removing tag albums? Intuitively, the permission/visibility issues are shared with smart albums or search, so it's not like we would be able to rip that code out when removing the tag albums implementation? @nagmat84, maybe you could expand on your points from the following sentence about tag albums: complicate matters, have some flaws which cannot be fixed easily and will always interfere with real albums badly?
• Yes, the current "Copy to" interface in the front end is ripe for improvements. No disagreements there.
• Yes, so is the current tags interface. I agree that they shouldn't be random strings but should be selected from a list.
• I believe that we would need both a "Link" and "Copy" functionality (or "Add" and "Duplicate" may be more intuitive names) for cloning photos. I don't buy arguments such as "nobody will need to have different metadata for different copies". Users always surprise us with what they want to do. description was already mentioned. title is another obvious one. Less obviously, people may want to edit _takenat (I've been meaning to add support for that since forever).
• In particular, what about two different users uploading the same photo? Clearly we shouldn't "link" them in that case...
• Would a proper (m:n)-relationship between photos and albums actually simplify permissions compared to what we currently have? Right now a photo has one parent album and it's that parent album that determines the permissions/visibility (see my next point regarding Unsorted). Tag albums do not interfere with that. But if we introduce proper (m:n)-relationship, a photo would be "owned" by multiple albums. What if one of those albums is private and the other is public -- is the photo accessible in the public mode or not? How is that determined?
• An aside: can we kill the whole "Unsorted" smart album? What's the use case for it? We could either require all photos to be in albums (it would certainly simplify our code a fair bit) or, alternatively, enable the displaying of photos at the top level (albums view), effectively eliminating the distinction between the albums and album view, which would certainly simplify the front end a fair bit.

383 brought up by @haivala is in principle a separate issue and I understand @nagmat84's reluctance to expand the scope of the discussion here, but I feel that a discussion of a major change of the internal structure must include the discussion of permission/visibility implications or improvements that could be made as part of such reorg. I already asked one question about visibility in the list above, but there are others:

• One recent example is #1135. If a user wants to make just a few photos from a large album public, then indeed copying them to another (public) album, as @nagmat84 suggests, sounds OK. But #1135 mentions the opposite case: a mostly-public album with just a few photos kept private. Copying everything but a few photos to a second album would of course still be possible but it seems like a hassle. Tag albums don't currently solve that use case either.
• We've had the concept of making individual photos public in a private album and we know that it's both a hassle from software maintenance standpoint and that the feature is not intuitive to users. Should we consider eliminating it altogether or doing the opposite -- expanding it so that it can also handle making individual photos private in a public album? It's a bit of a slippery slope because once we made visibility fully flexible, it begs the question why not the other features such as download/share/full-res? And making visibility flexible probably has all sorts of performance implications when it comes to the selection of thumbs, etc.

[d7415]

* An aside: can we kill the whole "Unsorted" smart album? What's the use case for it? We could either require all photos to be in albums (it would certainly simplify our code a fair bit) or, alternatively, enable the displaying of photos at the top level (albums view), effectively eliminating the distinction between the albums and album view, which would certainly simplify the front end a fair bit.

On this specific point, forcing an album is easier, but displaying at the root level means they could effectively be owned by a "root" album which could potentially have properties like a normal album...

[kamil4]

Good point, but now that I think about it, having photos at the top level would actually make things harder, especially in multi-user scenario (who owns that "root" album? Who controls its access permissions?).

[ildyria]

An aside: can we kill the whole "Unsorted" smart album?

Errrr I actually use it A LOT. :') E.g., when I need to share a picture with a friend without the need of creating an album for it.

[ildyria]

(who owns that "root" album? Who controls its access permissions?).

That is why you have ownership at album level and at photo level. :)

[kamil4]

Errrr I actually use it A LOT. :') E.g., when I need to share a picture with a friend without the need of creating an album for it.

You can create a real, permanent album (you can even call it "Unsorted" if you like) and put your photos there. The smart "Unsorted" album does nothing apart from complicating things! That permanent album could either be private (in which case you would make the photos public individually, just like now with the smart Unsorted) or it could be public but hidden (in which case every photo put inside would immediately be public -- a win over the smart Unsorted in terms of the number of clicks needed to share).

That is why you have ownership at album level and at photo level. :)

Yes, but at the photo level we can control only the visibility, not other properties like downloadable; for that we introduced the crutch of a config setting, which is obviously global (affects all users) and as such can be changed only by the admin.

And we know from Gitter and the issues on Github how confusing users find the whole concept of visibility controlled per-photo. "I made a photo public but I still don't see it anywhere in public mode". "What is the Public smart album for? Why isn't it actually public?" and so on. If we adopt the (m:n)-relationship with some sensible permission/visibility model, then I'm definitely advocating for ripping all of that out. It bothers me a whole lot more than the tag albums :smiley:.

[kamil4]

Another idea regarding album-level vs photo-level permissions. Basically, make it (nearly) all about photo-level permissions (which would need to be expanded to include downloadable, full-res photo, etc). Album-level would control album visibility and would act as the defaults for newly uploaded photos but other than that would not apply to the existing photos inside (well, I guess we could have an option in the GUI to recursively apply new album settings to the objects inside, possibly including subalbums -- the latter is something that users have been asking for). That would simplify permission checks a lot I think and would make "private photos inside public albums" trivial; it would also make (m:n)-relationships with albums with different visibility settings a non-issue as well.

[ildyria]

That would simplify permission checks a lot

I disagree on that one. Yes it would make the permission check easier when accessing directly a picture, but it does not change the access model for the albums. The only thing it would make simpler would be when someone wants to make a set of pictures private inside a public album (personally at that point, I would already have created 2 sub-album: one with the full set and one with the curated set).

Also we would need to consider things like: album 12345678 private, picture abcdef public. Should the picture be accessible or not via example.com/#12345678/abcdef ? I would be in favor of no (which is why there is example.com/view/abcdef).

In my opinion, the only problem of (m:n)-relelationship are for the search function and tag albums (which is why we are discussing it) where you have a conflict between two kinds of access public/private.

Moving to a (m:n)-album-photo-relationship gives us what ? album -(m:n)- photo -(m:n)- image variants which contains the paths as per #1055 . Now of photo what are the metadata that you want to be editable/hide-able per combination (album-photo) ? Title ? Tags ? Description ? Exif data ? Geo Data ? What are the data left? pretty much only access rights. :|

[kamil4]

Yes it would make the permission check easier when accessing directly a picture, but it does not change the access model for the albums.

Well, it's more than just accessing a picture directly (you mean example.com/view/abcdef, right?). It's also things like downloading an album. Currently, if it's a regular album, then it's pretty simple, but if it's a smart or tag album, then you need to test the downloadability status individually for each photo inside, by checking the actual parent album or, if they don't have one, the config variables. What should've been a one-liner test explodes to more like ten. It's a hassle.

So my suggestion above was to add properties such as is_downloadable to each photo; they would provide authoritative information on such attributes which would eliminate all the corner cases. We already should be appending such information to each photo object we return via the API, since the front end needs this information to determine whether to display buttons/menus such as "Download" (unsurprisingly, it can currently get it wrong for smart albums, tag albums, and search results, since it doesn't have the necessary information).

Also we would need to consider things like: album 12345678 private, picture abcdef public. Should the picture be accessible or not via example.com/#12345678/abcdef ? I would be in favor of no (which is why there is example.com/view/abcdef).

Well, I was sort-of wondering the same thing I think, only at the API level. Photo::get already doesn't take an album argument (only the photo ID) so anybody who knows the photo ID of a public photo can get all the info about it, correct? I believe that currently example.com/#12345678/abcdef won't display a photo in public mode if the album is private, but I think the way it works is that the front end first invokes Album::get on the album ID and if that fails, it doesn't try Photo::get (which would've worked). So, anyway, that wouldn't change with what I suggested, would it?

What I was wondering about is whether Photo::get should succeed or fail if the photo belongs to two albums, one private and the other one public? How would that be determined? I mean, you and @nagmat84 work in security so maybe for you the answer is obvious (if any parent album is public then the photo is public or something like that? Or would we have to always pass the parent album ID and the server would use that to determine the access?).

In my opinion, the only problem of (m:n)-relelationship are for the search function and tag albums (which is why we are discussing it) where you have a conflict between two kinds of access public/private.

Yes, that's where it would display itself most prominently. But example.com/view/abcdef would also be subject to the same conflict, no?

Moving to a (m:n)-album-photo-relationship gives us what ? album -(m:n)- photo -(m:n)- image variants which contains the paths as per #1055 . Now of photo what are the metadata that you want to be editable/hide-able per combination (album-photo) ? Title ? Tags ? Description ? Exif data ? Geo Data ? What are the data left? pretty much only access rights. :|

Personally, I don't think that any of these metadata should be editable per album-photo combination. They should belong to the photo, like currently. If somebody wants to have different metadata for the same picture, they should duplicate the photo object (the current Copy to functionality). That keeps things simple and predictable.

[nagmat84]

kamil4 wrote:

• What exactly would we gain by removing tag albums?

At the moment we have two variants for organizing photos and both miss some features which the other provides. If we advertise a feature, users naturally and legitimately file issues or ask to make it more usable. However, we don't have the man power to satisfactorily support both variants. As I showed, if both variants were implemented at the same commensurable level, then they were more or less identical. Hence, I encourage to focus on one variant, port the missing features which are provided by the other variant and then only follow a single path. As the real albums are more mature, I would drop tag albums.

But of course, we do not need to forcefully remove tag albums. We just can keep them and declare them "legacy" or something like that.

kamil4 wrote:

I don't buy arguments such as "nobody will need to have different metadata for different copies". Users always surprise us with what they want to do. description was already mentioned. [...]

This is not what I said nor suggested, actually I suggested album-specific descriptions myself. What I said is that there are clearly a lot of meta data which are intrinsic to a photo. It was you who claimed in this comment that one of the advantages of tag albums is that they reflect editing the meta data consistently. And I totally agree. But this should not be one of the reasons to keep tag albums. Instead real albums should behave the same. However this does not imply that there are no album-specific photo attributes at all.

For me there are two categories of attributes:

• Album independent photo attributes: created_at, updated_at, taken_at, focal, shutter, lens, make, model, altitude, latitude, direction, height, width, star rating and album-independent description. Any attributes whose true value can be determined by inspecting the photo is clearly album independent.
• Album-related photo attributes: album-specific description.

Album-independent photo attributes would only be stored once, album-related photo attributes would be stored as part of the (n:m)-relationship. As I already have suggested for description, it is also possible to have both flavors of an attribute. There should be an album-independent and an album-dependent description.

There is only a single (?) attribute for which I am uncertain and this is title. However, here I would take a resolute approach. First make it album-independent and if anybody complains and has a good use case why we need both an album-independent and an album-specific title we can still change it later. None of the decisions is set into stone.

kamil4 wrote:

Less obviously, people may want to edit _takenat

Sure thing. But how is that related to the topic?

kamil4 wrote:

• In particular, what about two different users uploading the same photo? Clearly we shouldn't "link" them in that case...

We already do that. At the moment we calculate the hash of a media file and check if we already have it in the DB. If that is the case, the existing row of the DB is duplicated and the media file is not saved a second time. Moreover, the existing media data (as given by the found DB row) and the "new" media data (as extracted from the uploaded file) are merged.

With the new approach we only had to create a new entry in the (n:m)-relation. It would actually become simpler.

kamil4 wrote:

• Would a proper (m:n)-relationship between photos and albums actually simplify permissions compared to what we currently have?

Yes it would. It would also simplify DB queries and simplify the the code for searching, uploading, rotating and deleting photos. Right now we have some kind of "pseudo" (m:n)-relationship, because copies of photos still share the same media file. We use the checksum of the media file to identify associated DB rows.

if a photo is deleted we must explicitly check if it was the last DB row for that photo and then also delete the media file. If a photo is uploaded a second time, we have a similar problem but with inverse logic, see above. If we rotate a photo we must search for all associated photo entries and update width, height and size of all entries, because the media file only exists once.

All this would be gone.

kamil4 wrote:

Right now a photo has one parent album and it's that parent album that determines the permissions/visibility. [...] But if we introduce proper (m:n)-relationship, a photo would be "owned" by multiple albums. What if one of those albums is private and the other is public -- is the photo accessible in the public mode or not? How is that determined?

It would work the same way as it does now: the photo would be public. Again, we already have a pseudo (m:n)-relationship because two different DB rows point to the same media file. If one of the DB rows claims the photo to be public, the photo (aka media file) is accessible. Nothing would change here.

kamil4 wrote:

• An aside: can we kill the whole "Unsorted" smart album? What's the use case for it?

With respect to permission/access rights/etc., the "Unsorted" album is just a mean to stash away photos which reside on the root level. Although, the "Unsorted" album is part of the back-end logic and explicitly reported to the front-end, it is only a UX feature in its heart. The alternative would be to show unsorted photos where they technically reside: in the root album, i.e. on the front page, together with all albums whose parent is null.

Personally, I would keep the smart album "Unsorted", because it helps to make the root level look "tidy". However, I don't see how it is related to the topic.

kamil4 wrote:

• One recent example is [Enhancement] Mixed (public/private) albums #1135. [...] Copying everything but a few photos to a second album would of course still be possible but it seems like a hassle. Tag albums don't currently solve that use case either.

Right. I would totally like to see some advanced ACL for albums and photos which offers the same feature as any modern file system. But as you said, this is currently neither implemented by real albums nor tag albums. But if we were implementing such a feature, then my gut feeling tells me that this will become a security nightmare if we still had tag albums.

kamil4 wrote:

• We've had the concept of making individual photos public in a private album and we know that it's both a hassle from software maintenance standpoint and that the feature is not intuitive to users. Should we consider eliminating it altogether or doing the opposite -- expanding it so that it can also handle making individual photos private in a public album?

I would really like to expand it, see above. But I don't see how it is related to the current discussion.

kamil4 wrote:

Another idea regarding album-level vs photo-level permissions. Basically, make it (nearly) all about photo-level permissions (which would need to be expanded to include downloadable, full-res photo, etc). Album-level would control album visibility and would act as the defaults for newly uploaded photos but other than that would not apply to the existing photos inside.

Exactly my thoughts on that topic and probably the way to go if we were ever implementing a full ACL scheme. But topic related?

ildyria wrote:

Now of photo what are the metadata that you want to be editable/hide-able per combination (album-photo) ? Title ? Tags ? Description ? Exif data ? Geo Data ?

See above.

[kamil4]

It was you who claimed in this comment that one of the advantages of tag albums is that they reflect editing the meta data consistently. And I totally agree.

Yep. Probably more often than not, people will want to keep the metadata in sync between the albums; agreed. But there will be circumstances when they don't. The point I was trying to make is that we shouldn't force them to. Either should be possible.

For me there are two categories of attributes:

* _Album independent photo attributes:_ `created_at`, `updated_at`, `taken_at`, `focal`, `shutter`, `lens`, `make`, `model`, `altitude`, `latitude`, `direction`, `height`, `width`, star rating and album-independent description. Any attributes whose true value can be determined by inspecting the photo is clearly album independent.

* _Album-related photo attributes:_ album-specific description.

I understand your point but I don't think that that should be a policy to force on users. For instance, I'm immediately sceptical about the star rating being album-independent. width and height are only independent until a photo is rotated (more on that particular point below). taken_at in principle should be independent (there is some ground truth about when a photo was taken) but what if a user wants to "lie" about it in a public album but keep the true value in a private "archival" album?

There is only a single (?) attribute for which I am uncertain and this is title. However, here I would take a resolute approach. First make it album-independent and if anybody complains and has a good use case why we need both an album-independent and an album-specific title we can still change it later. None of the decisions is set into stone.

In my opinion, title should definitely be album-dependent. Building on my example above, a user may want to keep the original crypic name from the camera (img_20210810_073135717) in the private "archival" album but use something more descriptive (Jerry on the beach) in a public version visible to others.

• In particular, what about two different users uploading the same photo? Clearly we shouldn't "link" them in that case...

We already do that. At the moment we calculate the hash of a media file and check if we already have it in the DB. If that is the case, the existing row of the DB is duplicated and the media file is not saved a second time. Moreover, the existing media data (as given by the found DB row) and the "new" media data (as extracted from the uploaded file) are merged.

With the new approach we only had to create a new entry in the (n:m)-relation. It would actually become simpler.

I haven't tested it but by the look of it, we don't duplicate metadata such as the description from the existing variant. And, in my opinion, we shouldn't. Description may contain private information that shouldn't be shared (the existing photo could, after all, be private and owned by a different user).

Yes it would. It would also simplify DB queries and simplify the the code for searching, uploading, rotating and deleting photos. Right now we have some kind of "pseudo" (m:n)-relationship, because copies of photos still share the same media file. We use the checksum of the media file to identify associated DB rows.

This may be nitpicking but I disagree with the description of what we currently have as a "pseudo" (m:n)-relationship. In my view, what we have is a space-saving micro-optimization to avoid duplicating the underlying media files. Nothing more.

If we rotate a photo we must search for all associated photo entries and update width, height and size of all entries, because the media file only exists once.

Well, that's how I implemented it because it made things like skip_duplicates easier but I'm no longer so sure about it myself. I mean, it's probably a reasonable default. But what if two users want the same photo in different orientations? You know, maybe it's an "artsy" photo that doesn't have an obviously "right" orientation. Why should one user be able to force it on the other? Right now I believe it's simply impossible for us to have two different orientations of the same photo in Lychee. That strikes me as an unreasonable limitation, but at least right now we could relatively easily fix it. We should make sure that a "proper" (m:n)-relationship doesn't make it impossible.

• An aside: can we kill the whole "Unsorted" smart album? What's the use case for it?

With respect to permission/access rights/etc., the "Unsorted" album is just a mean to stash away photos which reside on the root level. Although, the "Unsorted" album is part of the back-end logic and explicitly reported to the front-end, it is only a UX feature in its heart. The alternative would be to show unsorted photos where they technically reside: in the root album, i.e. on the front page, together with all albums whose parent is null.

Personally, I would keep the smart album "Unsorted", because it helps to make the root level look "tidy". However, I don't see how it is related to the topic.

Well, the thread is about reorganizing our album structure so I'm taking advantage of it to list some of my own album-related pet peeves. :wink:

What I actually dislike are album-less (root-level) photos. We support them on the server side, at a significant cost (they are a special case every time we have to deal with permissions and such), but we actually don't support them in the front end; instead, we opt to stash them in a special "Unsorted" smart album. Because, as you said, it helps to keep things "tidy". Well, my proposal is to bite the bullet and clean this mess up. Either we are not interested in displaying photos at the root level, in which case we should remove the costly support for them from the server, or we are interested and we should support them in the front end. What we currently have is the worst of both worlds.

[nagmat84]

Yep. Probably more often than not, people will want to keep the metadata in sync between the albums; agreed. But there will be circumstances when they don't. The point I was trying to make is that we shouldn't force them to. Either should be possible.

Understood, but here we disagree. "Either should be possible" means more work for us maintainer. Plus and that bothers me most is that I really miss the feature of synced meta data for real albums. If we are talking about choices, why do we force :smirk: people to use tag albums if they want to sync the meta-data across albums? In that case we had to offer four variants :see_no_evil:: real albums with synchronized meta data (my favorite), real albums with non-synchronized meta data, tag albums with synchronized meta data and tag albums with non-synchronized meta data. The latter might be a little bit esoteric and no I don't propose to do that.

I understand your point but I don't think that that should be a policy to force on users. [...] taken_at in principle should be independent (there is some ground truth about when a photo was taken) but what if a user wants to "lie" about it in a public album but keep the true value in a private "archival" album?

I am not sure if we should base or design decision on users needs to lie about something :laughing: However, I agree if we consider privacy. Maybe, users don't want to expose certain meta-data in a public album, but want to keep the the true meta-data in a private album. However, in this case we should rather implement a feature to hide certain attributes of the meta-data from the info panel. As a first step this could be a global configuration option. In the long-run this could be an album-specific setting (:see_no_evil:).

In my opinion, title should definitely be album-dependent. Building on my example above, a user may want to keep the original crypic name from the camera (img_20210810_073135717) in the private "archival" album but use something more descriptive (Jerry on the beach) in a public version visible to others.

As I said, I don't mind to make more attributes album-dependent, if necessary. However, in this particular case, I would rather add a new attribute and name it correctly: original_title alongside title. With the idea from above, users could even hide the original_title and only expose title publicly.

If we rotate a photo we must search for all associated photo entries and update width, height and size of all entries, because the media file only exists once.

That's how I implemented it [...] but I'm no longer so sure about it myself. [...] What if two users want the same photo in different orientations? [...] Maybe it's an "artsy" photo that doesn't have an obviously "right" orientation. Why should one user be able to force it on the other? Right now [...] it's simply impossible for us to have two different orientations of the same photo in Lychee. That strikes me as an unreasonable limitation [...] We should make sure that a "proper" (m:n)-relationship doesn't make it impossible.

Good point. Completely agreed. However, this could be solved: I envision some kind of warning/question dialog which pops up, when a user tries to rotate a photo which exists multiple times in different albums and then ask the user if he wants only rotate the single instance or all of them. (Bonus point: If we wanted to go over the edge, we could present check boxes for each instance of the photo and then let the user pick which ones should be rotated :see_no_evil:).

When a user wants to rotate only some instances of the photo, then the media file needs to be duplicated and the duplicate is rotated. Either only the rows of the selected copies are updated (current approach) or the (m:n)-relations of the selected copies are updated to point to the new rotated photo.

Well, the thread is about reorganizing our album structure so I'm taking advantage of it to list some of my own album-related pet peeves. wink

True. :hugs:

What I actually dislike are album-less (root-level) photos. We support them on the server side, at a significant cost (they are a special case every time we have to deal with permissions and such).

I actually don't see the "significant" costs, but anyway there is another thread regarding permission handling: #1150.

[nagmat84]

@Aleshus gave a good remark on Gitter at Nov 26h 2021, 19:34 which I would like to summarize here for the sake of persistency.

The main difference between tag albums and regular albums is that the former allows photos to be tagged without the need to create a respective album. The additional step of indirection allows to use tags for nearly everything which is on the photo and which may or presumably may become handy in the future. It allows to easily add albums in the future without cluttering Lychee with any possible album right away.

I deem that a very strong argument. For me it is strong enough to keep tag albums.

Nonetheless, I still would like to see a proper (n:m)-relation between photos and regular albums.