GNOME Bugzilla – Bug 335935
Export to folder bugs when pictures bear same name
Last modified: 2006-07-25 21:30:52 UTC
Please describe the problem: The export to folder feature uses file names based on the image name. If one is to export pictures with same file name (but of course different paths), the last one to be exported clobbers the others. The filename is desirable as it is sometimes based on the topic of the image, and is memory-friendly for url ("look, this is at http://something/photos/funny_face.jpg"), but this prevents having pictures with the same base name to be exported together (and all of my panoramic pictures built with Hugin use panoramic1.jpg, panoramic2.jpg... beginning at 1 for each photo session). Steps to reproduce: 1. Open f-spot, select pictures that have the same name on disk 2. Export them to Folder 3. Open index.html Actual results: Index shows only one picture in multiple copies. Expected results: Index shows many pictures in one copy each. Does this happen every time? Yes Other information: Patch included. Rationale for using (DbItem).Id as complement to the image is as follows: when using more complex export destinations, image name should probably be a constant, therefore not something based on the order in which the photos were selected or with which photos they were selected. Something dependent on the complete path would be too long. The id in the db looks fine. Could be printed in hex form to make it shorter (or in base 36 mapped to 0-9a-z). Patch applies cleanly after applying patch for #335929, will be fuzzy else (only line numbers changed).
Created attachment 61967 [details] [review] Patch against f-spot-0.1.10 to solve the problem Applies cleanly if applied after patch to bug #335929. Fuzzy if applied without.
Created attachment 62108 [details] [review] revised patch Redo the patch against CVS+patch to bug #329685. Tested it.
Created attachment 62109 [details] [review] revised patch Redo the patch against CVS+patch to bug #329685. Tested it.
I am confirming this behavior. If there are no technical issues and it works, could this patch be accepted for the next release? I spent half an hour figuring out why there were 6 pictures missing when I exported some favorites for an online gallery using zenphoto. I had to export the first batch, use gthumb to rename them from their exif date, then export the rest, do the rename operation and remove the doubles.
Idea. This may sound crazy, but might I suggest f-spot automatically renaming files with a syntax like this? yyyy-mm-dd--hh-mm-ss-#.jpg where # is the instance number (if there are duplicates or modified versions). Or provide a preference for it? I think that could solve the problem by its roots. The import tool should do that on the fly and examine for dupes. When the date is incoherent (does not match the file creation date if using a digital camera, or has no date, or has something like dec31 1969). The thing I want to say is that, basically, keeping the filenames as what the camera named them seems a bit messy to me. Thoughts?
This is quite painful, because my camera restarts its numbering scheme every time I empty the memcard. So of a collection of 240 pictures, I only get the last 60. This happens when exporting to Folder and export to CD.
bumping
Jeff (Comment #5) and Frank (Comment #6): Bug #302566 and associated patch covers the possibility to rename the pictures in F-Spot Regarding renaming them by default during import to something else would probably cause some problems. 1) Some people import existing pictures from the hard disk. With existing names they do not want to change. 2) Some people want to correlate the F-Spot picture name with the original file name. 3) F-Spot is not the only photo organizing tool out there. 4) Importing and renaming would make it rather tricky with external file/database with tag information (like gthumb for instance) Possibility. To add a Preference for renaming scheme according to the patch in bug #302566, and add another preference enable renaming photos during import (not linking, but when copying). Otherwise, easiest to indicate which photos have original name (tag?) and be able to select whichever photos you want and rename them. The patch in bug #302566 has a future plan (if it ever gets accepted) to enable user to add special phrases based upon EXIF tags. Like _Canon_ or _Nikon_, or something like this.
Bengt (comment #8) and others. The point of all this is *NOT* having unique filenames in F-Spot. Think about importing images on locked storage, ... For me, Jean-Christopht (comment #3) was very close to the solution for this problem. May I suggest to add a serial number only if it's a duplicate ? More like: IMG1.jpg IMG2.jpg IMG2-1.jpg IMG2-2.jpg IMG3.jpg Keeping original names is very important. When you ask a friend to print a full-sized version of a picture he shoot and put on the web, you'll never ask for the picture with the little baby crying on a sunset background. You ask for the filename, and he will retrieve it with that filename. my opinion, for what it worth...
Stephane, true - Very true. Slightly of-topic But I for one, wanted (originally anyway, when I used a file browser a lot), to change the default very un-informative file name of IMG-0001 to YYYY-MM-DD-HH-MM-<something> which is a bit better for the eye. Back to this one, For sure, when exporting pictures, F-Spot should warn, or possible rename according to comment #9 suggestion, for the photos in question. Since user wants to export all 100 photos, not just the 67 that have unique file names.
(In reply to comment #9) > For me, Jean-Christopht (comment #3) was very close to the solution for this > problem. May I suggest to add a serial number only if it's a duplicate ? More > like (sample) I am not good enough in C# to do that (albeit I could have tried harder), but in perl, I would have written: foreach $image (@exports) { $name=$image->Name; if ($count{$name}) { $name=($count{$name})."-".$name; } $count{$name}++; } Putting the number of duplicate names in front instead of at the end avoids playing with the extension. It can be done, though. It will probably be necessary even for RAW or AVI formats.
The logic to pick a unique name based on the previous name is in a couple of places in f-spot I know ImportCommand:ChooseLocation has roughly what is needed. I'd really like to see a simple class whose goal was to build a path based on a prefix a modifiable assortment and IBrowsableItem metadata and which handled conflicts etc that could be shared between the import export and batch moving code. But this is basically the right idea thanks for the work.
Created attachment 67387 [details] [review] the same, re-using the logic of FileImporter This one simply re-use FileImportBackend.UniqueName as Larry said, it's probably no longer a good place for UniqueName...
Created attachment 67388 [details] [review] diff'ed with -u same as previous one, but diff'ed with -u. sorry
I re-open this one. the patch proposed and applied will cause serious problems with HtmlGallery. see bug #348342
read bug #348392 instead of 348342
Created attachment 69412 [details] [review] another try a new patch for this. The solution for 'export files only' remains the same, but now ImageName returns only a filename, not a complete path. For HtmlGallery, I re-use the same ImageName as in OriginalGallery. so, all images will be renamed. There's also a solution in the middle: always add an id at the end of the filename...
My thoughts on name schema.. Filename (and path) should be short, logical, rememberable and back-traceable. The YYYY-MM-DD -schema is logical and most oftentimes back-traceable. It's not short and is not very friendly for online use and is not very SEO -optimized. Making all filenames "img-{num}.jpg" is not back-traceable at all, it depends on image order in current selection. I think it also would need at least 0000 -padding to be correctly sortable in file viewer. A personal solution with an 'get-images-off-cf' -script was to append running number at the end of images basename. (I think handling basename is easy enough in C# + libraries to be warranted here) It would make into interesting option to have ImageName generate name based on tags and possibly 'details'. As I often use descriptive filenames for images that are hand-exported to web, they often get high placement on image-search-engines. This of course would ruin shortness of filename.
My first patch used the id in the f-spot database as an auxiliary identifier (to make all images distinct). It had the advantage of never changing for the same picture. I see this as a necessity : whatever the selection, an exported image must bear the same name. However, in the foreseeable future, one might be able to export several versions of an image, and they bear the same id in the db. So, in fact, keeping the id is a no. One possible scheme is exporting the name with a user-defined scheme. Default could be name-id, but a set of choice could build the chain: - file name - f-spot db id - yyyymmdd - mmdd - version id - tags separated by commas - ASCIIfied tags separated by dashes - number in selection - distinguishing number (if all the rest is equal for all picture, add -2 for second, -3 for third, etc.)
committed the new patch. We can discuss the version name choices in a different bug.