GNOME Bugzilla – Bug 342138
re-import versions as one picture
Last modified: 2018-07-12 00:01:14 UTC
When you re-import modified pictures in f-spot, they show up as separate pictures. Way to test it: - import a picture - edit (crop, whatever...) - delete from catalogue - import again Now they are 2 separate images. Perhaps it's possible to add something in the metadatas saying 'I'm a version of the image called blah.jpg'. And at importing time, if the blah.jpg exists in the current repository, we can add the image as a version of blah.jpg. If it's not possible to write such a thing in the metadata, simply adding a way to say in f-spot 'this image is a version of that one'. Having a thing like this plus #342137 could be enough for having a real way to backup and restore...
We should be generating an uuid on import and storing that in the XMP metadata, versions should mark themselves with a new uuid and store the original uuid as the original. The XMP specs leaves the specifics of this type of versioning up to the implementation so that various content management can be used. This would also allow better duplicate verification and matching even for files modified outside of f-spot.
Generating new uuids is fine for new fixes, and probably something that should be done. However, I think this is also something worth fixing for old photos. My photo collections, for example, have this issue: I modified tons of photos, and now I have a lot of duplicates I wish weren't there in my library. I have lots the old photos.db file, and can't see a simple (or complicated) way to get around this issue. Anyway, In most cases, the filename "Filename (Modified).jpg" will only be generated by f-spot. But I realize that one can't just naiively merge these different photos as one. But what if one checked the EXIF data, and did merging based on that--ie. one merged photos with filenames that match under user request, but issued a warning if the EXIF data was super-different, or different at all. Would this be more useful / better done as an extension?
It will be useful in any way :) I've lost my photos.db, re imported all collections and now have over 5k images instead of 4k with versions.
Created attachment 102412 [details] Extension to fix this bug.
(Please note, that the above extension only works with patch from http://bugzilla.gnome.org/show_bug.cgi?id=508124 is applied).
Created attachment 102794 [details] Better (more efficient) verison of extension Extension fixes bug / works for latest svn. Responsible people want to review the extension, and then close this bug?
please provide source patch instead
The extension will be useful for people who have ALREADY imported pictures, and the pictures have ended up in the wrong place (makes re-importing, which can be slow, unnecessary). I will submit a source patch that fixes the problem at import-time, however.
*** Bug 519570 has been marked as a duplicate of this bug. ***
Created attachment 122291 [details] MergeVersions extension, zip-file with sources My version of the extension with sourcecode, based on a sample extension. See also: http://pholog.de/2008/11/fspot_mergeversions_plugin/ Comments or feedback welcome! Also feel free to improve it.
Created attachment 122295 [details] crash-log.txt None of the above works form me. The first one crashes f-spot 5.0.0.3 (check log in attachment) and the secound one can work only with files named as "img (Modified 1).jpg".
Created attachment 125711 [details] Update to guava's attachment for f-spot 0.5 Hi, I updated guava's extension (thanks guava, I was desperate to find something like that!) to work in f-spot 0.5. I have no mono skills, so I just fixed the compile time errors without any code review, but it seems to work on my f-spot 0.5.0.3, and I hope someone else would find it useful. Any feedback is welcome.
This does not work if original file is RAW (in my case cr2). Could you fix that please.
Милош, I tested it and it seems to work for me. Here's what I did: - Created two pictures, foo.cr2 and foo (Test).jpg - Imported them in f-spot - Run Tools/Fix Back Versions I ended up with a single items with two versions: - original (the cr2) - Test (the jpg) Did you test it with my version? which were the file names you used?
Yes, I tested it, but it doesn’t work. Here is the console output (originals are RAW files — *.CR2): FBV: Skipping orphaned photo IMG_7921 (veb2).jpg, no parent found. FBV: Skipping orphaned photo IMG_7921 (veb).jpg, no parent found. FBV: Skipping orphaned photo IMG_7921 (Developed in UFRaw (2)).jpg, no parent found. FBV: Skipping orphaned photo IMG_7913 (Developed in UFRaw).jpg, no parent found.
I'm sorry but I wasn't able to reproduce the problem. I created a folder with the following files: IMG_7921.CR2 IMG_7921 (Developed in UFRaw (2)).jpg IMG_7921 (veb2).jpg IMG_7921 (veb).jpg and imported them in f-spot. After running Fix Back Versions they were correctly merged as a single image. Here's the output: FBV: Match parent IMG_7921.CR2, with orphaned photo IMG_7921%20(veb2).jpg, reversioning as version 'veb2' FBV: Match parent IMG_7921.CR2, with orphaned photo IMG_7921%20(veb).jpg, reversioning as version 'veb' FBV: Match parent IMG_7921.CR2, with orphaned photo IMG_7921%20(Developed%20in%20UFRaw%20(2)).jpg, reversioning as version 'Developed in UFRaw (2)' If you confirm you're running version 0.2.2 of the plugin I'm a little lost here. Does it happen for every .cr2/.jpg pair? One strange thing is that in my orphaned photos warnings the whitespaces (' ') are replaced by '%20'. Could it be a locale issue? Which linux distribution/version/locale are you running?
Hm, I don’t know what’s going on. I alredy tried english locale, but it is the same. I am useing plugin version 0.2 and f-spot 0.6.0.0 (tried with 0.5 too). That’s the plugin from your attachment, right?
Distribution is Gentoo, and it happends to every cr2/jpg pair.
Created attachment 141929 [details] Slightly improved version of the fix - Better original image extension matching - Auto-refresh after the update - The new imported version is now set as the default version
Ok, I see what went on here, I was doing some more test on the extension and I forgot about it :-| I hope this works now, sorry for the waste of time.
This did not work for me, but new improvements are great. This plugin is now almost ready for integration in F-Spot. Anyway, I tried to understand the source code of plugin, and found my problem :) Plugin does not read the Exif date when photo was created, but the time of file modification. I replaced this lines: if (Matches(lastParent.Name, parentMatcher) && lastParent.Time == child.Time) { parent = lastParent; } else { parent = FindParent(child, parentMatcher); } with: parent = lastParent; Now, I just hope there are no orphand pictures with same name in my database :D It looks like everything is fine.
Found the real problem. See attachment.
Created attachment 141934 [details] png image
*** Bug 622621 has been marked as a duplicate of this bug. ***
F-Spot has moved to https://github.com/f-spot/f-spot/issues If this Bugzilla ticket is still valid in a recent version of F-Spot, please feel free to post this topic as a ticket in the F-Spot project on GitHub. Closing this report as WONTFIX as part of Bugzilla Housekeeping as we are planning to shut down GNOME Bugzilla in favor of GNOME Gitlab.