What are
/r/PhotoStructure's
favorite Products & Services?
From 3.5 billion Reddit comments
The most popular Services mentioned in /r/PhotoStructure:
The most popular reviews in /r/PhotoStructure:
>Sharing of directories/images privately. This appears to be on the list, maybe.
Albums and directories will be implemented as hierarchical tags, and sharing will be via a token applied to a tag (so you can easily share a full directory, recursively, for example).
I'm thinking that sharing a single asset will still be via a tag (that's created automatically), just so all "shared" items only have one place to look.
I'd thought of putting share tokens on both tags and assets, but it adds complexity that the user is exposed to when there are several ways to acquire share tokens.
If you're interested in more details, send me an email and I'll link you to the design doc I've got.
Howdy! I want this too!
I'm currently using Caddy to share my PhotoStructure library with my family, configured to both do https and basic http auth. There are a ton of alternatives that are pretty easy to set up, too;
https://photostructure.com/faq/remote-access/#reverse-proxies
I will be building authentication/authorization in a future version soon: it's the fifth-most-voted-for feature.
https://forum.photostructure.com/t/secure-sharing-of-albums-and-assets/112
Howdy, welcome to PhotoStructure!
Try ./start.sh --expose to bind to all network ports. It only binds to localhost by default.
More details here:
It was added in the v0.9.1-beta.1 (v0.9.0-* alpha and beta builds won't be updated again, as v0.9.0 was released).
You should be able to pull the :beta tag and get v0.9.1-beta.3.
Please tell me if the correct image doesn't pull down for you.
Hit the "down" arrow in the bottom middle of the screen, or hit the s key: that shows the "streams" that asset is associated to.
The next version changes this icon to hopefully something a bit more intuitive.
See also:
If you delete all the file variations for an asset from the filesystem, and click "Re-sync this asset", the asset will go away and you'll be redirected to the home page.
In the next release, deleting is handled properly: https://photostructure.com/faq/archive-remove-delete/
Howdy!
Shut down PhotoStructure for Desktops, if it's running still.
Delete the system settings.toml file: https://photostructure.com/getting-started/advanced-settings/#system-settings
Restart PhotoStructure, and it will think it's starting on a new computer. On the welcome page, pick your existing library directory, and it should open up.
If you're using a network fileshare for your library directory, make sure you don't have your library open simultaneously on different computers: that can cause library data loss.
Cheers!
let me just get trough with the documentation and I will be back :).
thank you for the detailed feedback!
>PhotoStructure's UI is mobile-friendly HTML, but you need to set up remote access. https://photostructure.com/faq/remote-access/
I have a reverse proxy deployed for that and will be back with further questions if I need clarifications.
There are several great options for getting your files synced from your phone to your NAS at home: Synology and QNAP both have mobile apps, and there are these as well:
https://photostructure.com/faq/how-do-i-safely-store-files/#how-do-i-back-up-files-on-my-phone
(My family uses Resilio Sync on our iOS and Android devices, fwiw)
Sorry that it's taking too many resources on your NAS!
I've done several things to make sure PhotoStructure normally runs without affecting system responsiveness, so something in the following is amiss:
All the processes are
renicedto run under only low priority. Do you see this happening properly in your process table?PhotoStructure measures your system and schedules what it hopes is a reasonable number of concurrent
sync-filejobs. You can check this on the about page. Are these numbers seemingly too high?The default scheduling should keep the system at about 75% utilization during imports. You can set the
cpuLoadPercentto something like 50 or even 1, which will only schedule one file to be imported at any given time.
https://photostructure.com/getting-started/advanced-settings/
Thanks for taking the time to share!
(Sorry for the inexact quotes, the iOS Reddit client doesn't seem to support reply quotes)
> docker-documentation
I don't know if you saw the docker-compose instructions, but it's an annotated file as you suggested.
> ENOENT
I'll try to reproduce this. Thanks for the heads-up.
> ... Library is current empty ...
This should be fixed in beta.4
Users, sharing, titles, and descriptions are on my to-do list.
> [DNG and JPG with the same name]
These won't be grouped together unless PhotoStructure has determined that they have the same captured-at time. Smartphones and cameras happily create colliding-basename images all the time.
> [Navigation woes]
How would you improve this? Just skip over the intermediate folders?
Cheers!
Which Synology NAS are you using /u/waltonnerd? The docs say 2GB RAM is the recommended minimum, I was wondering how you find the performance with the NAS that you set it up on?
Sorry, this thread fell off my radar and I didn't back to you.
Know that the RPi will complete an import of any size library, it'll just be glacial.
If it only has to deal with new files, even if it's glacial (like, 10 seconds per image), it happens in the background, and will get done when it gets done.
What I'd do in your situation is "initialize" the library on a beefier box.
Make sure you've read about volumes, to make sure the import work from your beefy box is usable by your RPi. Especially read this caveat about pathnames.
Then, once this initial import is complete, copy the library to your RPi, and then let the RPi be the "authoritative" library from then on. No need to do any preview or library syncing: just copy new files to your RPi, and PhotoStructure sync will find and import those new files.
Howdy!
Metadata editing is absolutely going to be supported: it's on my todo list.
The next thing you should ask is: dude, why aren't you done with that yet? (possibly without the California interjection).
Oh man, am I glad you asked!
Editing metadata is trivial for one file: I tell ExifTool to make the change, and it happens.
But PhotoStructure's assets are backed by one or more asset file "variants" due to de-duping.
If, say, you delete a keyword from an asset, and one of the volumes that you've scanned into your library is unmounted, PhotoStructure won't be able to comprehensively fix all variants to not have that keyword anymore. The next time you mount that volume, PhotoStructure sync will check the formerly-missing variant, and the deleted keyword will be re-added to the asset. The same issue would happen if you newly import an old backup that has a variant of this asset with the old list of keywords.
To handle this, PhotoStructure will also persist a set of time-stamped "operations" (very similar to a CRDT), which it can then aggregate and "replay" when that asset is being re-imported, to ensure that user edits don't get quietly reverted.
(These will be stored in a sidecar, by default, just like all other metadata edits, but you'll be able to make metadata changes directly to the original file, if you understand the risks and don't like sidecars).
> re-embed that metadata
No: I try to keep original files untouched, in general, to lessen the chance of data loss.
> delete poorer quality files
Again, out of an abundance of caution, PhotoStructure doesn't have a "delete all duplicates" button. The heuristics seem to work well in most cases, but I'm sure there are edge cases that might miscategorize files.
If you've got backups, and are comfortable with the terminal, there's this, though: https://photostructure.com/server/tools/#show-me-all-the-duplicate-variant-filenames-for-each-asset
Hey there, sorry that PhotoStructure is misbehaving for you!
Unfortunately the current volume scanning code gets grumpy if any volumes are not available to readdir(), so read-only volumes can cause issues. I've fixed it in the main branch, but haven't pushed out a release yet.
If you don't think this is what's going on, feel free to email me your logs, and I can take a look. https://photostructure.com/faq/error-reports/#how-to-manually-send-your-logs
However, I'd suggest setting her up with Resilio Sync or SyncPhoto to automatically back up her phone, and set up PhotoStructure to scan the resilio directory on your NAS, then everything just happens automatically. It's what my wife and I do.
Yup. Self-hosting has driven probably most of PhotoStructure's architectural design decisions, and is a central tenant to this project. See https://photostructure.com/faq/why-photostructure/#-ownership for an explanation why.
Oof, that's no good. Can you restart PhotoStructure with debug logging, try to open that asset for again, and then email me your logs? Instructions are here: https://photostructure.com/faq/error-reports/#how-to-manually-send-your-logs
PhotoStructure always forces previews into the srgb colorspace, as a number of beta users had older images with invalid colorspace profiles which resulted in corrupt previews.
It looks like I could be a good deal more clever in handling ICC profiles, though: if the image has a ProfileDescription tag of Display P3 (like in an iPhone X image), the preview should actually properly render into P3 as long as I don't force the srgb colorspace anymore (!!) (if I'm reading this correctly).
I've just made this change, and added a new passthroughColorspaces library setting which defaults to "Display P3". This change will be in v0.9.1-beta.4 for testing.
After you pull in the beta (which, again, I haven't built yet), you'll need to "rebuild" your library to make this change take effect, as the previews are not normally rebuilt if they are not "stale" (newer than the source image).
Do you have an easy way to test that an image is actually in a P3 gamut?
Thanks for asking this: this wasn't on my radar!
Edit: I'm not going to be able to push out beta.4 tonight, but it'll go out tomorrow morning.
For features: https://photostructure.com/faq/why-photostructure/
There is no online demo yet. It's still in beta, available to try for free in exchange for feedback and assistance with fixing any bugs they find. If this is agreeable to you, feel free to use a disposable email to subscribe, and you'll get installation instructions emailed to you. https://photostructure.com/#mc_embed_signup
> can I see somewhere which version it is?
The version is on the About page (you can get to it via the navigation menu in the upper right: you may need to scroll down).
If you're on docker or the command line, you can also use --version.
> and it works as expected now :-)
Excellent. Thanks for the update!
🥳 v0.9 (and the next beta, 0.9-beta.6) will have a new hiddenHomeTags library setting. It default to hiding the "Type" root, which is still available via the navigation menu. It's case-insensitive, and applied server-side.
(it was only a couple lines of code, so I snuck it into the build just now).
I reimplemented the sync scheduler in beta.5, so that could be the issue. Are you now running beta.4, or 0.8.4 (:latest)?
Thanks so much for reporting this: DM or email () me a mailing address and I'll send you some stickers as a thank you!
Can you attach your docker-compose or list your bind mounts so I can try to reproduce the issue locally?
Also: if the json log files are as hard on your eyes as they are on mine, know that logcat and logtail will pretty-print them: https://photostructure.com/server/tools/#logging
I want this too! It's in this list.
While I've got your attention: how do you think a "file delete" should be handled?
Immediately delete the file. No undo.
Try to use the operating system's trash/recycle bin, if possible. Unfortunately, this reverts to option 1. for remotely-mounted NAS volumes.
Mark the file to be "deletedAt" some time (30 days?) in the future. This then requires some new frontend view/mode to see deleted files.
Some other great idea you come up with
That's an interesting idea. This would require two things:
- Knowing if a local volume was equivalent to the remote PhotoStructure server volume (which we could get with volume uuids).
Like you suggested, this could also just be manually set by the user, like "F:\ on the server is G:\ on this computer".
- To "open file in folder," I actually fork-exec finder or explorer or xdg-open to open the folder with the given file selected.
The browser used to be fairly well-isolated from the local filesystems, but there is a new, experimental native filesystem integration now: https://developer.mozilla.org/en-US/docs/Web/API/FileSystem
(Personally I'm terrified of the exfiltration that this API will enable, especially for the less technically savvy)
That said, this API still doesn't seem to let me "open the folder with the file selected" (for 2. above)
Crap. No, this is a docker configuration that tells the docker daemon to not be so hasty in SIGKILLing PhotoStructure.
Here's what PhotoStructure is doing on shutdown, btw: https://photostructure.com/faq/how-to-start-and-stop-photostructure/#why-does-it-take-so-long-to-shut-down
You can't hide streams (yet), but it's on my to-do list (along with customizing how large each "sample" is).
If you don't care about the camera, lens, or file type tags, those can be individually disabled via library settings. You'll then need to "rebuild" your library to have it take effect on existing assets (this will take a while).
>needs some sort authentication system to keep guests away from the admin bits.
Agreed, that's coming with sharing.
>It doesn't appear to be processing any images or videos.
Can you run ./start.sh --verbose, let it run for about a minute, and send the output to ? Alternatively, PS_LOG_LEVEL=debug ./start, let it run for a minute, and then tar up your logs dir (in ~/.config/PhotoStructure/logs).
I suspect it may be an issue with volume parsing. Another bit of helpful info would be to send what's in your About page (via the main menu nav), including the volumes table.
Another thing: if you're library is a remotely mounted filesystem, set PS_FORCE_LOCAL_DB_REPLICA=1. SQLite WAL mode uses a -shm shared-memory file which doesn’t work on remote filesystems, and this flag tells PhotoStructure to read and write from a local SQLite database replica (stored in /tmp) to work around this issue.
We'll get it going! 👍
>Am I looking at months? Years? Weeks?
I'm hoping to push a new version every couple months. Each new version implements something (or several somethings) from the list.
>Also is there something like a beta/nightly build/fast ring
There are prereleases, but know that they really are alpha, they may not even launch. Bug reports would be splendid, though.
I tend to release them as a new version is almost ready. V0.8.4, for example, has an alpha release currently, and I'm hoping to push a beta build today.
For the desktop version, there's a system setting to pull in these unstable releases. For docker, pull in the :beta tag. For node, check out the beta branch.
Undo those changes when the version is released, though, to make sure you're running a stable version.
>am I able to change that later?
Good question. Yes, absolutely.
If you change the value in the settings page from "no" to "yes," a "resync" (from the main menu) will result in all new photos and videos not already found in your library to be copied into your library.
Note that if you start with "yes" and change it to "no," PhotoStructure will not remove any files that it previously copied into your library.
(I'll update the instructions with these details, thanks!)
I haven't used capture one (and you're the first person to ask me about it)! I'd have to do a bit of research into how it stores metadata before I'd know how long it would take to integrate.
I will be adding integration plugins for other systems (like Apple Photos), but that's behind a bunch of other features on my to do list.
I think you're conflating "gallery" and "DAM," perhaps?
I was a committer on the OSS Gallery project, many years ago. It didn't auto-organize, infer missing metadata, auto-transcode videos, automatically scan all all volumes, validate photos and videos for corruption before importing, run on macOS, Windows, and Linux, or have portable, cross-platform libraries.
I'm using PhotoStructure for my family's library, and it is the "system of record" in my case, but unlike (all?) other DAMs, it handles either being a primary or secondary "source of truth" (instead of freaking out like most DAMs do when files change out from under them).
Ah, I didn't know how you were running PhotoStructure.
The tools require some level of comfort with the terminal. If you're ok with that, first install Git for Windows, then install PhotoStructure for Node.
If your photos are already organized how you want them on disk, say "no" to automatic organization.
I use that feature to "sweep everything into one pile", as I feed old backup drives into my NAS and have PhotoStructure copy new photos and videos into my library in datestamped subdirectories. (The subdirectory format is configurable via the PS_ASSET_SUBDIR_FORMAT environment variable. Use these tokens).
I haven't made one yet. I will soon (and if there are beta testers that want to share their setup, that'd be great!)
Several beta users have told me they've successfully used the Docker instructions for their Unraid boxen, fwiw.
Also, know that you can run ./photostructure sync [file or directory...] to import any directory on demand. Use --force to ignore prior-cached filesystem metadata. See https://photostructure.com/server/tools/#manually-importing-files-and-directories for details.
> Are there any plans ...
Yes! https://photostructure.com/about/whats-next/
> full screen shortcut
F11
> ScreenSaver
Yup, that's on the list.
> uses all monitors
Ooooh, that's a great idea, I hadn't thought of that. Thanks!
What os are you on, and what flavor of PhotoStructure (desktop, node, or server?)
If you go on to your About page, if you could share the Free memory, CPUs, and Concurrency values, that would help.
If you have a lot of videos, transcoding can take a while. You can disable transcodes if you're not interested in viewing your videos in a browser.
Writes to the library and the database can slow down imports if it's on slow disk. A local SSD is best. Spinning rust from a slow NAS mounted over WiFi is the worst.
> Cmd line options or something similar?
You can set the PS_CPU_LOAD_PERCENT environment variable to 100 (it defaults to 75). If your home directory (or if you're using Docker, your /ps/tmp volume) is on SSD and your library is on a slow disk, you could try setting PS_FORCE_LOCAL_DB_REPLICA to true, which should help speed up at least database I/O.
You can look at all the settings (there are a lot of them!) here: https://photostructure.com/getting-started/advanced-settings/#library-settings
The info and list commands will help. Instructions are here https://photostructure.com/server/tools/#which-files-in-a-directory-didnt-get-imported
Holler if anything didn't make sense or you need more details.