Open borger opened 3 years ago
Hi, first and foremost, thank you for your interest in Lychee. :smiley:
One thing to realize is that Lychee is being developed by enthusiast photographers with a main job on the side. As a result, adding features take a very long time (sorry for that). The team is quite small, but we are always open to pull request (hey there is Hacktoberfest coming :wink: ). Additionally, pretty much anyone who makes multiple contributions (of quality) is likely to be proposed to join the team. But back to the point, the way Lychee is developped, improved etc, really depends of the needs of each users. E.g. Matthias is working on an app for Lychee, as a result he significantly single-handedly improved our code base. Personally I am working on a new front-end (but until very recently, I didn't had time at all). So please understand that we appreciate ideas, but unless we find them either (1) simple to implement or (2) something we would love to use, they are quite unlikely to be added. Sad truth I know. But as said above, we are always open to Pull Requests. :smiley:
Now back to your suggestions.
if you've considered adding functionality to allow for file versioning
I think that might have been a suggestion just for pictures, but this will most likely complexify the code significantly, and the idea was dropped. :confused:
To me this is relatively similar to this (XKCD 1425):
RAW to JPEG conversions, it would be nice to be able to keep the RAW files in case one wants to revisit.
This is sadly not the goal to Lychee. One of the reason is that Lychee does not aim to be a photo editing software but more of a gallery of already edited pictures. While you can use it on a local network, it's main target is to be used on a remote server to display your work/share your pictures.
Furthermore adding such steps would pretty much open the door to a lot of request such as:
Keep different formats (sizes/orientation/crop) of the same photo, sort of ties with 1 and 2, though.
I think I already mentioned that. In a simpler word, what you would like is the ability to make a stack of similar pictures.
Do note that Lychee does not change the uploaded image (aside from the rotation functionality), all metadata such as tags etc are read once on import but then stored in the database. We do not update sidecar files (even though there was request to do it but nobody took the time to implement it).
Hello @ildyria!
Thanks for your reply!
I understand the flow, and I can definitely support it, however, the idea needs to be in line with the overall strategy of the project, or else, the contribution is just not going to be helpful, and maybe unwelcome really, so I decided to post, to measure if its something more people is interested while respecting the project's purpose.
Based on what you said, that's not something you're interested in. As I mentioned, I understand there's a thin line between just managing the files/metadata as I mentioned, and a full-blown photo editing software, which I believe is a fair concern.
With that being said, I'll be closing this Feature Request.
Based on what you said, that's not something you're interested in.
Just like you said, it is just my opinion. I am not necessarily talking for the full Lychee team. :)
Adding the option to stack pictures would be interesting though. Especially when you have multiple version of the same picture (e.g. color & B&W).
While I have been working on the way how files are handled (I try to move everything to data streams), I had an inspiration how this suggestion could be realized.
We already have decoupled the actual photo object from its actual size variants. We have something like this
+---------------+ +--------------------+
| photo | | size_variant |
+---------------+ +--------------------+
| id: string | 1 ----> 0..7 | id: int |
| title: string | | photo_id: string |
| ... | | type: int(0..7) |
+---------------+ | short_path: string |
| width: int |
| height: int |
| filesize: long |
+--------------------+
with a unique constraint on size_variants
for (photo_id
, type
), i.e. each photo can only own each type of size variant once.
In theory, it should be possible to add a version
-counter to size_variants
and change the unique constraint to (photo_id
, version
, type
). Every new version of a photo would simply create a new set of size variants with the most recent set being at max(size_variant.version)
.
+---------------+ +--------------------+
| photo | | size_variant |
+---------------+ +--------------------+
| id: string | 1 ----> 0..7 | id: int |
| title: string | | photo_id: string |
| ... | | version: int | <-- **new**
+---------------+ | type: int(0..7) |
| short_path: string |
| width: int |
| height: int |
| filesize: long |
+--------------------+
Of course, this is only a sketch and still much work. In particular, the frontend needs support for it, the REST API needs to be extended, etc. pp. I am not going to do it, because I don't need that feature myself. But if anyone would like to contribute, this is how I would do it and it should be doable without large changes to the architecture.
Hello team,
Congrats on the project! This is an awesome tool!
I was wondering if you've considered adding functionality to allow for file versioning, I see 3 use cases where this would be beneficial:
1) Say I'm scanning old photos of family, etc, and then from the scan, I can edit it, improve, etc, and eventually re-upload but it would be nice to keep the full hierarchy of those objects, perhaps even allowing for just specific versions to be public (?); This would be very helpful for family sharing, and you can always revisit it if you want to. Sort of keeping the original like the native services provided by the major phones; Another thing would be when it comes to metadata, similar to the photo itself, say I've adjusted the metadata, but I don't want to lose the original one for whatever reason, so if we had versioning builtin, it would be a nice way to control those changes;
2) RAW to JPEG conversions, it would be nice to be able to keep the RAW files in case one wants to revisit. and one could even use ZFS as a storage backend, to help reduce infrastructure needs because the data volume will start to be a problem. That's not to say we need to edit in the browser at all, but just keeping these versions would be a huge benefit.
3) Keep different formats (sizes/orientation/crop) of the same photo, sort of ties with 1 and 2, though.
I'm suggesting that, because I do believe Lychee is very close to me my choice of self-hosted photo/video management. And I'm looking to migrate my current platform while keeping the originals and metadata of the scan itself, and the adjusted ones, and don't end up with a cluttered dashboard you know?
And I understand perhaps I'm pushing the "boundaries" of the project here, but I would be very glad to help...