After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 342138 - re-import versions as one picture
re-import versions as one picture
Product: f-spot
Classification: Other
Component: General
Other Linux
: Normal enhancement
: ---
Assigned To: F-spot maintainers
F-spot maintainers
: 519570 622621 (view as bug list)
Depends on:
Reported: 2006-05-17 15:17 UTC by Stephane Delcroix
Modified: 2018-07-12 00:01 UTC
See Also:
GNOME target: ---
GNOME version: ---

Extension to fix this bug. (3.91 KB, application/octet-stream)
2008-01-08 19:26 UTC, guava
Better (more efficient) verison of extension (4.16 KB, application/octet-stream)
2008-01-14 07:55 UTC, guava
MergeVersions extension, zip-file with sources (13.58 KB, application/octet-stream)
2008-11-09 22:07 UTC, Fabian Kneissl
crash-log.txt (1.78 KB, text/plain)
2008-11-09 23:09 UTC, Милош Поповић
Update to guava's attachment for f-spot 0.5 (6.62 KB, application/x-gzip)
2009-01-03 22:30 UTC, Antonio Frediani
Slightly improved version of the fix (6.72 KB, application/x-gzip)
2009-08-28 13:46 UTC, Antonio Frediani
png image (4.18 KB, image/png)
2009-08-28 14:53 UTC, Милош Поповић

Description Stephane Delcroix 2006-05-17 15:17:22 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...
Comment 1 Larry Ewing 2006-06-09 23:47:50 UTC
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.
Comment 2 guava 2007-11-15 01:47:57 UTC
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.

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?
Comment 3 Artur Flinta 2007-11-26 22:12:53 UTC
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.
Comment 4 guava 2008-01-08 19:26:38 UTC
Created attachment 102412 [details]
Extension to fix this bug.
Comment 5 guava 2008-01-08 19:47:29 UTC
(Please note, that the above extension only works with patch from is applied).
Comment 6 guava 2008-01-14 07:55:50 UTC
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?
Comment 7 Stephane Delcroix 2008-01-15 16:50:33 UTC
please provide source patch instead
Comment 8 guava 2008-01-16 06:30:31 UTC
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.
Comment 9 Maxxer 2008-09-09 20:10:29 UTC
*** Bug 519570 has been marked as a duplicate of this bug. ***
Comment 10 Fabian Kneissl 2008-11-09 22:07:30 UTC
Created attachment 122291 [details]
MergeVersions extension, zip-file with sources

My version of the extension with sourcecode, based on a sample extension.

See also:

Comments or feedback welcome! Also feel free to improve it.
Comment 11 Милош Поповић 2008-11-09 23:09:29 UTC
Created attachment 122295 [details]

None of the above works form me. The first one crashes f-spot (check log in attachment) and the secound one can work only with files named as "img (Modified 1).jpg".
Comment 12 Antonio Frediani 2009-01-03 22:30:20 UTC
Created attachment 125711 [details]
Update to guava's attachment for f-spot 0.5

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, and I hope someone else would find it useful.

Any feedback is welcome.
Comment 13 Милош Поповић 2009-06-29 17:00:54 UTC
This does not work if original file is RAW (in my case cr2). Could you fix that please.
Comment 14 Antonio Frediani 2009-08-18 18:05:15 UTC
Милош, 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?
Comment 15 Милош Поповић 2009-08-18 19:04:21 UTC
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.
Comment 16 Antonio Frediani 2009-08-19 22:18:35 UTC
I'm sorry but I wasn't able to reproduce the problem. I created a folder with the following files:
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?
Comment 17 Милош Поповић 2009-08-20 08:24:56 UTC
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 (tried with 0.5 too). That’s the plugin from your attachment, right?
Comment 18 Милош Поповић 2009-08-20 08:27:15 UTC
Distribution is Gentoo, and it happends to every cr2/jpg pair.
Comment 19 Antonio Frediani 2009-08-28 13:46:40 UTC
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
Comment 20 Antonio Frediani 2009-08-28 13:50:29 UTC
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.
Comment 21 Милош Поповић 2009-08-28 14:25:07 UTC
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);

parent = lastParent;

Now, I just hope there are no orphand pictures with same name in my database :D It looks like everything is fine.
Comment 22 Милош Поповић 2009-08-28 14:53:17 UTC
Found the real problem. See attachment.
Comment 23 Милош Поповић 2009-08-28 14:53:44 UTC
Created attachment 141934 [details]
png image
Comment 24 Ruben Vermeersch 2010-06-30 08:52:00 UTC
*** Bug 622621 has been marked as a duplicate of this bug. ***
Comment 25 André Klapper 2018-07-12 00:01:14 UTC
F-Spot has moved to

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.