Will sync update files in the library when better duplicate versions are discovered?

I have PhotoStructure set to organise its library. I am doing this as part of a multi-step tidying-up process, long overdue :wink:

What is the expected sync/organise behaviour when I add a new search path and it contains better versions of photos that already exist in PhotoStructure’s library folder?

  1. Do the “better” versions overwrite the files already present in the Library? or;
  2. the better versions are simply added to the versions list in the DB / info panel?

Hope the question is clear!

Thank you for this awesome software.

1 Like

Hey underdog! I’ve found for me I get both copies - so I have JPEGs and Canon RAW files of the same file both appearing in the library and both stored in the PhotoStructure master folder.

Thank you. Do these files appear in the UI as separate ones or as alternates?

I get both appearing as separate thumbnails in the main library view. For example:

image

These are both the same photo, and both from the same RAW file - the first thumbnail is the actual RAW file, the second is a lower-res JPEG.

PhotoStructure never overwrites (I’m too chicken risk averse).

Automatic organization will copy every unique SHA into your library that isn’t already in your library.

More details here:

(a future improvement could be to not bother copying any file that isn’t going to be picked as the “best” variation of an asset, but that would result in missing files if there’s any issue with the de-duplicator… Speaking of which…)

This is a bug, apologies! They should be aggregated into the same asset.

Are you running v0.9.1, or v1.0.0-beta.3? Can you email me those two images?

Using 0.9.1 stable. I’ll email example images now!

Thanks @tompagenet !

I was able to reproduce the (invalid) aggregation using v0.9.1:

mrm@speedy:~/src/photostructure-for-servers$ git checkout main
mrm@speedy:~/src/photostructure-for-servers$ ./start.sh info ~/Downloads/tom/*
...
{
  message: 'These files differ: Different lensId: LensID:Canon EF 50mm f/1.8 II != LensID:EF50mm f/1.8 II',
  similarImages: false,
  meanHamm: 0.99,
  labModesCorr: 0.93,
...

And, good news, everyone: this is fixed in the beta branch (I had added lens normalization in one of the first v1.0 pre-releases):

mrm@speedy:~/src/photostructure-for-servers$ git checkout beta
mrm@speedy:~/src/photostructure-for-servers$ ./start.sh info ~/Downloads/tom/*
...
{
  fileComparison: 'These two files will be aggregated into a single asset.',
  variant: true,
  imageHashComparison: {
    imageCorr: 0.84,
    aRotation: 0,
    colorCorr: 0.97,
    meanCorr: 0.88,
    greyscale: false
  },

If you upgrade to a beta build, your library will automatically rebuild, which will re-aggregate (and fix) these issues (and if they don’t, please tell me!)

Matthew, you’re amazing. Seriously. I’m still doing my (so far three day) initial library build. Is it best to wait until that’s finished before I upgrade to a beta build? And once I’m on a beta am I stuck there, or can I go back to stable?

1 Like

You can upgrade to the beta build at any time, but the library sync will need to restart. Currently synchronized assets will be retained and that work won’t be re-done.

I personally run the beta build for our Official Family Library (which would cause Consternation from Elders and Nieces if it broke, so that should give you an idea of how stable it is). I strongly suspect you’ll see fewer issues with v1.0.0-beta than v0.9.1: I’ve fixed a ton of bugs and added a ton of features since last November.

Also:

Thank you for the detailed reply Matthew. Makes sense to be on the safe side!

I suppose I can later run some other dedup app against the auto-organised library dir to later get rid of lower quality dupes (I use PhotoSweeper on Mac occasionally).