I want to be able to remove the blurry/ugly photos from my photostructure so that it becomes nicely curated over time.
Seconded. Especially with the deduplication logic, I’d like to be able to verify the duplicates in a side-by-side and then delete the “other” one (even better would be how Xcode handles deletion: Just the Reference or Move to Trash/Delete File).
I agree! I’ve wanted to add this feature for a while, but customer support and other bugfixes/more pressing features (like browse-by-filesystem) kept pushing this down the list.
My current thinking is that there should definitely be “exclude from library” (Xcode’s “just the reference”), and this is actually already implemented for images subsequently found in NoMedia directories.
Marking assets as “hidden” would require a new “only show hidden” assets view, which I’m currently thinking will just be a tagged search result (
/search?q=hidden:true), as would “excluded” assets.
You can do this by clicking the paths in the asset info panel, which will replace the currently-displayed variant with the file you just clicked on.
Here’s a reddit discussion about deleting photos from a while back: https://old.reddit.com/r/PhotoStructure/comments/jaiz06/suggestion_delete_files/
I took your advice and just let Photostructure scan all disks on my system for photos. I never realized just how many .JPG files exist that are NOT my photographs! I, too, would like to be able to delete pictures from the Photostructure library, “curating over time,” as another poster put it.
What’s the best advice for attacking the glut?
You might want to enable the filter that requires a Make and Model tag: that will let PhotoStructure omit all screenshots and downsamples (which commonly have removed EXIF metadata).
There are many other similar filters as well. They’re all library settings:
With the next version, you’ll be able to bulk-exclude by folder hierarchy, too.
I found the setting, but now that the “damage” is done, i.e., a bunch of unwanted jpg files have already been processed, what do I do to remove them, short of starting over from scratch? Thanks.
These files should be removed from your library automatically by running “sync” (via the navigation menu). If you were using “automatic organization”, through, they will remain in your library hierarchy: there isn’t an automatic way to delete them (although you can certainly get this list via the
I think keeping “automatic organization” on is a no-brainer. Otherwise, if I mounted a SD card with photos, PS processed them, and then I removed it… the next sync would remove those photos UNLESS “automatic organization” was on. Do I have that correctly? If “automatic organization” is on, once a photo is in the library, it STAYS there.
Yes, PhotoStructure won’t delete files out of your library if other variants are missing or deleted.
PhotoStructure, in general, tries to very conservative:
Once the feature that this topic is tracking, “delete,” is implemented, PhotoStructure will move files that you request into the trash.
Do you mean that if I set a filter and run a sync, it’ll remove items that get filtered out? If I’m using “automatic organization” and later change the filtering settings, will a sync then bring those files back?
While setting up PhotoStructure, I accidentally synced thousands of screenshots into my library, and now I want to remove all of them.
Yes. If you enable the require make and model setting, for example, if you just visit a screenshot, say “resync this asset,” and then navigate away, you’ll find that asset is no longer there.
I’ve updated the “info” tool in v1.0.0 to pull in the system and library settings so you can edit filters and verify, onsoe-twosie, what files will be added or excluded, but I’m sure there’s a nicer UX to handle this.
I was going to add a “recently added”, “recently updated,” and perhaps for library owners, a “recently deleted” view (just using the new search view), but this won’t include all assets that were recently filtered out: there’s no “asset” to show in many cases, so all I have to show are pathnames (which I currently don’t retain in the library database). Ideas around this are certainly welcome.
As a new user, I’m a bit confused by this conversation - right now I have imported my library and would like to clean it up (it contains lots of screenshots etc that I don’t need). Am I understanding correctly that there is currently no way to delete/hide such photos from PhotoStructure?
Yup, you’re not confused.
I’m building this feature now and it’ll be in the next version, though.
If you find that an entire directory should not have been imported, you can use NoMedia, but v0.9.1 doesn’t have a UI affordance to hide or delete individual photos.
Sorry to revive this topic, but I’m still a little confused.
If I delete an image in the photostructure library by hand (e.g., go into the directory and delete using file explorer in windows), will that break the browser?
Also, if I have auto organization turned on and delete the photo, will it be re-copied in the next sync?
No apologies necessary! This is the right place to ask.
It shouldn’t! If you resync that asset, and you removed all variants of that asset, PhotoStructure should remove the asset from your library automatically.
Here’s the situation I’m trying to solve for and wondering if this is going to help tackle that or not:
I have lots of photos in my library taken as bursts or just unnecessary extras which I’d love to clean up to save on space. Photostructure helps with this in one way by deduplicating images in the interface, but I’d actually like to go through and pick photos and files that I don’t want to keep and have them deleted from the drive. That way I’m not just curating my PS library but also the raw library of files underneath.
Is that what you mean by deleting here or are you just referring to deleting them from the PS library while the underlying assets remain untouched?
I mean both. Here’s the current terminology I’ve come up with, and what each term means:
“hiding” means the asset database references, thumbnails, and (if relevant) transcoded video remain on disk, but are only visible to library owners.
“excluding” means remove thumbnails and transcoded videos, but retain a SHA of the variants in an exclusion list so any subsequent copies don’t get re-added to your library
“deleting” means both remove references in your library, and delete the files and all variants from disk.
A user just asked me this over email:
I know a delete feature is not available yet; 1) will that be something available when 1.0 is released or will it be later in the future?
I’m trying to get at least initial support into v1.0.0. There will be subsequent improvements in future releases.
- with no official delete method, what is your recommended way? It looks like I can get the delete by the info button in the top right corner. If I manually delete that file, is there anything else I need to do like deleting thumbnail files, updating the database?
If you manually remove all image variants, or move them into a NoMedia directory, that asset will be removed from your library. When that happens, previews, thumbnails and transcoded videos are removed from your library automatically as part of the sync process.
I did some more research for file deletions.
I’m going to mark files for deletion in the DB, and then add an “empty trash” button in the nav menu that will use this technique as a safeguard, along with a link that opens a page listing all the paths about to be unlinked.
Why this solution and not some of the other discussed options?
Moving files into a platform-specific “trash can” only works on local drives, and only on macOS and Windows. Linux support for trash is spotty, but I could ask users to install trash-cli. A “trash can” doesn’t make sense for Docker users, as
~/.local/share/Trash/will be ephemeral to the image.
I tend to be susceptible to “ooooh, that’s clever” solutions, which tend to be too clever by half. I feel like a hidden local directory may be confusing for most users, especially because I don’t know of any software that does this sort of handling of deletions.
Moving files into a folder that you need to delete manually requires PhotoStructure to have a flawless view of volumes. It has a really good view of current volumes, but (especially on macOS) the APFS volume list is borked/shows duplicates that can be confusing. Loopback bind-mount folders, symlinks, and N other exotic filesystem constructs will get in the way of “what filesystem hosts this file” and “where should it go to delete it”.