GNOME Bugzilla – Bug 329040
Import to directory structure
Last modified: 2018-07-12 00:12:13 UTC
It should be possible to specify (in preferences) which directory structure F-Spot should use as within the Photo Storage directory. As it is now, it is "hardcoded" to use YYYY/MM, but this should be changable from within the preferences. Possible structures are 1) YYYY/MM 2) YYYY 3) YYYY/<free text from import> 4) YYYY/MM/<free text from import> 5) <free text> 6) YYYY/MM/DD Also if you change the directory structure in the preferences, F-Spot should also ask if it should move the photos according to the new structure.
Just a small update. F-Spot stores the photos in YYYY/MM/DD structure.
I'd like this option too, or maybe just selecting the folder by hand as in Gthumb. It could be good either to config the path with a string, as in some CD-ripping tools like Grip, e.g.: %Y_%m_%d --> 2006_05_23/ %Y/%M/%d --> 2006/May/23/ But I don't know if this one would be so clear for most people...
I think a configurable path structure would be awesome, especially for people like me who already have several years of photos in a specific configuration. I personally would be looking for something like this: ~/Documents/Images/Photos/%Y_%m_%d
It looks to me like f-spot uses ~/Photos/YYYY/M/D/ not ~/Photos/YYYY/MM/DD/ (no leading 0's) I have an external Olympus S-HD-100 HD dedicated to Photos. It is part of the Olympus Dock&Done system. The manual says that it uses the path: /DIRECT00/YYYYMMDD.000/ I plan to see over the next few days how well that Olympus system and f-spot play together. As an end user of f-spot, I don't really care about the directory structure. It only starts to matter if I try to use different systems to manage the photos at the same time. Is there some general standard for the directory structure of digital image storage systems? Or does everyone implement what makes sense to them?
It would actually be better to provide specifiers like that for each EXIF field much like how Grip uses a different specifier for each ID3 field. There's no point in limiting the folder structure to simply just the date field.
Created attachment 83523 [details] [review] Adds support for custom directory structure This patch adds an entry field in the main preferences dialog for users to edit their directory structure. They can use the .NET/mono DateTimeFormat strings (eg. yyyy/MM/dd) and free text. It also prevents them from entering ".." (we don't want them putting photos in a directory higher than the f-spot photos directory). This directory-format string is stored in the Preferences file. (NOTE: I was having trouble getting Glade to not rewrite everything (and thus make my patch too large to attach). For the time being, I am only attaching the code changes. If you want to use this patch, you should load up f-spot.glade in Glade, then in MainPreferences add a HBox underneath the photosdir_chooser with size 2. On the left side add a label called "import_dir_label" and on the right side add a GtkEntry box named "photosdirformat_entry". It should work then) This patch does not take other exif data into account. That would be a great feature in the future, but for the time being I don't think it is necessary. Enjoy!
Created attachment 83684 [details] [review] Allows custom path formats for importing photos (now including the UI changes) This fixes the problem I had before Glade versions (thanks Stephane!), so now this patch should be fully usable. This is my first time updating the UI in a patch, so I'm not sure but you might have to run autogen.sh before building.
Created attachment 83687 [details] [review] Allows custom path formats for importing photos (now including the UI changes) Oops, my mistake. I accidentally left in some old code in Preferences.cs in the last patch. This one properly sets up your default path format preference.
> so I'm not sure but you might have to run autogen.sh before building. you don't have to
*** Bug 412674 has been marked as a duplicate of this bug. ***
Created attachment 112736 [details] [review] Allow custom import path/filename format and roll names Hi, I hope this feature will be implemented soon... In the meantime, I (hopefully) improved the good patch from Michael Wayne Goodman, adding to F-Spot these features: - ability to set custom import directory structure; - ability to set custom filename format; - ability to add to (custom) filename a descriptive roll name. The third feature added could be expanded adding support to descriptive roll names in the db, so that one could browse (and search) his photos not only with date or tags, but even for "shot sessions", as for real films... New features implies two textboxes in the main preference window (hidden in an "Advanced" expanding panel) and a textbox in import dialogs for roll name. I know these feature may seem redundant: F-Spot is a photo manager so one could think "Hey, there's no more need to keep my photos organized on the file system!". But one could desire to browse his photos with another program, or quickly find all photos from the last holiday only looking at roll name, or give photos to a friend with self-explaining filenames, or even stop to use F-Spot... (no, we hope no...). So, please, consider including this feature... In attach, a patch against revision 4065. Thank you for your work.
*** Bug 351624 has been marked as a duplicate of this bug. ***
User-configurable date-based paths for storing the pictures (under ~/Photos) is not enough. Like many others, I have many years' worth of pictures carefully organized in a hierarchical directory structure. Mine looks something like this (except the names are actually in another language): ~/Photos/Collection/{year}/{album} (for my own pictures) ~/Photos/Received/{source}/{album} (for pictures others give me) ~/Photos/Edited for e-mail/{name} ~/Photos/Projects/{name} (for special projects, e.g. panoramas) ~/Photos/Misc/{whatever} I can maintain this structure in F-spot by importing with "copy" off, but it's pretty useless when I don't have any way of viewing the photos by folder, and I can't use F-spot to import photos directly from my camera into this structure. I think the right fix is actually quite simple: 1. Enable browsing and other operations (slideshows, etc.) by folder (in a tree view). 2. On importing pictures, when the "copy" option is on (e.g. when importing from a camera), let the user optionally specify the destination folder explicitly. (The default may be some date-based format.) 3. Remember the import dialogue "copy" setting, and use a confirmation dialogue to prevent starting a large copy operation accidentally. 4. Implement basic folder operations (rename, move, ...) in F-spot, since renaming a folder directly in the file system apparently means F-spot will lose track of it.
I just want to emphasize how weird it seems that the import menu that you get when you click the import button, and the one you get when you insert a photo card, are so different. In one you can't choose where the photos will be copied to: http://img148.imageshack.us/img148/6292/pantallazo3ag2.png Yet, in the other you CAN: http://img148.imageshack.us/img148/1820/pantallazo5wf6.png
(In reply to comment #14) > I just want to emphasize how weird it seems that the import menu that > you get when you click the import button, and the one you get when you > insert a photo card, are so different. that's ubuntu only patch.
IMHO the format of the subdirectories-field should be that of strftime, since that's so very common. See e.g. here: http://www.manpagez.com/man/3/strftime/
This is really the same as bug #349403 Comments from bug #Bug #349403 (originally bug #544487 – Views should include folder...) Everyone organizes their large photo collections by date because 1) this is how the pictures are taken 2) this is how photo management programs group them on import typically 3) you need to be able to get at the folders from outside of the application. I cannot stress point 3 enough. This is critical for backup/recovery, passing to friends, etc. What I'm talking about is that on import, f-spot should by default create folders such Pictures/2008-07-01 Pictures/2008-07-05 This is the best starting point, since 90% of the time, each album is separated by day. The date should be pulled in from exif data. I actually organize my albums by year, then date + description. For example, Pictures/2008/2008-07-01 Birthday Party Pictures/2008/2008-07-05 Camping This should be configurable as everyone has their own preferences here. Yes, even the format Pictures/2008/07/01 Pictures/2008/07/05 should be supported. The point is that editing the folder name from outside of f-spot should allow f-spot to pickup the changes and continue without failing or requiring to reorganize. _____________________________________- Yes it should be viewable by folders as well from within FSPOT. Thanks.
Created attachment 128309 [details] Import Options within Windows Gallery
Created attachment 128310 [details] Import Options within Windows Gallery
Created attachment 128311 [details] Import Options Dialog from WIndows Gallery
Lu Timdale said it all! Most of software that comes with cameras works this way. This feature would be a great step forward. I don't use F-spot to organize my photos, I only try to use it to download them from my camera. I really miss this help to make my own organization. We must not forget that photos still are files in our systems. Simply load them into a random directory doesn't help anyone. Just because of this I still don't use f-spot (specially downloading photos). This is a key feature for F-spot.
@Lu Timdale > 2) this is how photo management programs group them on import typically Not true. I used Digikam and Picasa and they adapt to any existing directory structure > 3) you need to be able to get at the folders from outside of the application. You're able to get at the folders with any naming scheme based on events or places. I always used a directory structure based on places. I find it really useful. For a date-based view there are cool apps like F-Spot. When using a file manager yy/mm/dd is not so helpful. And btw your point "1)" does not make any sense to me. Could you elaborate?
> 2) ok, if you want to leave the structure as whatever is there, that's great. That should be an option. For newly imported images, presumably it would follow whatever structure you define. What do those programs do by default? What does windows photo gallery do? What does iPhoto do? Which program do we want to follow... in my opinion windows photo gallery has the best, most flexible, easiest import process. Currently it is being done the iPhoto way, which in my opinion is NOT the best way. > 3) not from outside of f-spot. If you use the file browser (nautilus) how do you get at it if it's organized as 2009/03/01? How do you know what event that belonged to (from nautilus)? > 1) I just meant that you typically take 1 set of pictures on 1 day. You may have a scenario where you take 2 sets of pictures on the same day or that the set spans multiple days. But in 95% of the cases (for me anyway) it's 1 set for 1 day. ... that's what I meant. Thanks. Lu
> 3) not from outside of f-spot. If you use the file browser (nautilus) how do you get at it if it's organized as 2009/03/01? How do you know what event that belonged to (from nautilus)? That's why I'm against a date based directory layout. Accessing your data from any app even with a basic file manager (maybe from a remote computer) is major feature that outweighs any fancy photo management feature f-spot may have.
(In reply to comment #24) > > 3) not from outside of f-spot. If you use the file browser (nautilus) how do you get at it if it's organized as 2009/03/01? How do you know what event that belonged to (from nautilus)? > > That's why I'm against a date based directory layout. Accessing your data from > any app even with a basic file manager (maybe from a remote computer) is major > feature that outweighs any fancy photo management feature f-spot may have. > I agree wholeheartedly. The key features of a photo managemnet app are: 1. accessible via file browser (ie. good directory structure) 2. autorotate & save based on exif data on import 3. rotate manually for pictures that may not be rotated properly all the rest is gravy. However, I like to have the best of both worlds. Having a layout like 2009-03-01 John Birthday 2009-04-27 Mike Birthday etc. allows you to search for folders that have "Birthday" in it within nautilus and simply by browsing it AND it also allows you to look at the pictures chronologically as well. BTW, I like to have my pictures be stored in a year folder as well, so it would actually be something like Pictures/2009/2009-03-01 John Birthday Anyway, the point is one size does not fit all. Everyone has their own way, and it should be configurable.
(In reply to comment #25) > ... actually be something like > Pictures/2009/2009-03-01 John Birthday > Anyway, the point is one size does not fit all. Everyone has their own way, > and it should be configurable. > I agree. I think the way Banshee handles the paths and filenames is very good. Together with the option to automatically change the path when metadata is changed. The same I would prefer for f-spot. But, if it should be possible to use paths like "John Birthday", you cannot use tags for it, because a photo can have more than one tag. So you need something like a "master tag" or "album" to do such things.
One year after my last comment (#11) I come back and this bug is still here. I refreshed my patch and made an Ubuntu package which does exactly what described in my previous comment (and desired in comment #25); also, a mitigation of UTC bug #340903 (using the patch there) is included. You can find the package in my PPA https://launchpad.net/~meden/+archive/ppa . Refreshed patch is not against svn, so I will not upload it here; you can find it at https://bugs.launchpad.net/ubuntu/+source/f-spot/+bug/204011/comments/6 . Regards.
Alessio, I tried the packages from your PPA. THANK YOU! I'm surprised this often requested feature has been ignored for so many years. It is a huge deterrent for many people who would like to use F-Spot. The folder structure feature works perfect. I set it to yyyy/MM MMM to test it out. I did have problems using the Roll naming feature. When importing locally from a selected folder, the Roll name was simply ignored. When importing from my camera, it would give a fatal error, and crash F-Spot. I'll post the error stuff below. Anyway, the directory structure feature works great. Thanks so much! The Roll feature, though, was a little confusing. I think it may be better to use Tags for such an idea, though it would probably require more work in different areas of F-Spot. It could require, as Mike said above, a master tag. Maybe the Roll name could simply be the master, or initial tag, though. When you put in a Roll name, maybe it could not only serve as a Folder/File naming mechanism, but also create and apply the Roll name as a tag to the photos being imported. I also found the way the Roll name works a bit confusing, in that it was applied automatically (according to the tooltip). It would be nice to see 'roll' as an option under the Folder and Filename formats instead of being appended automatically. For example, I could set my folder structure to yyyy/MM MMM - roll. So my files would be under 2009/07 July - My Birthday. -------------------------------------------------------------------- Errors using "Roll name" when importing from Camera: http://files.getdropbox.com/u/185397/FSpotError01.png http://files.getdropbox.com/u/185397/FSpotError02.png http://files.getdropbox.com/u/185397/FSpotError03.png An unhandled exception was thrown: System.NullReferenceException: Object reference not set to an instance of an object at ICoreProxy.Import (System.String ) [0x00000] at FSpot.Driver.Main (System.String[] args) [0x00000] .NET Version: 2.0.50727.42 Assembly Version Information: System.Configuration (2.0.0.0) FSpot.Widgets (0.0.0.0) System.Xml (2.0.0.0) NDesk.DBus.Proxies (0.0.0.0) gconf-sharp (2.24.0.0) System.Data (2.0.0.0) Mono.Data.SqliteClient (2.0.0.0) FSpot.Query (0.0.0.0) gdk-sharp (2.12.0.0) gnome-vfs-sharp (2.24.0.0) NDesk.DBus.GLib (1.0.0.0) NDesk.DBus (1.0.0.0) Cms (0.0.0.0) Mono.Posix (2.0.0.0) System (2.0.0.0) FSpot.Utils (0.0.0.0) FSpot.Core (0.0.0.0) atk-sharp (2.12.0.0) gtk-sharp (2.12.0.0) Mono.Addins (0.4.0.0) Mono.Addins.Setup (0.4.0.0) glib-sharp (2.12.0.0) gnome-sharp (2.24.0.0) f-spot (0.5.0.3) mscorlib (2.0.0.0) Platform Information: Linux 2.6.28-13-generic i686 unknown GNU/Linux Distribution Information: [/etc/debian_version] 5.0 [/etc/lsb-release] DISTRIB_ID=Ubuntu DISTRIB_RELEASE=9.04 DISTRIB_CODENAME=jaunty DISTRIB_DESCRIPTION="Ubuntu 9.04" ------------------------------------------------------------------------- Thanks a lot for the work on this, Alessio and Michael. And thanks for going the extra step and adding the PPA, Alessio. I'm not experienced in applying patches, so that made it a lot easier! It's really appreciated. Please let me know if there is anything more I can add or do to help. - Darin
(In reply to comment #28) > Alessio, I tried the packages from your PPA. THANK YOU! I'm surprised this > often requested feature has been ignored for so many years. It is a huge > deterrent for many people who would like to use F-Spot. Glad to have been useful. Sorry for the delay, but I'm quite busy. . > > The folder structure feature works perfect. I set it to yyyy/MM MMM to test it > out. I did have problems using the Roll naming feature. When importing locally > from a selected folder, the Roll name was simply ignored. When importing from > my camera, it would give a fatal error, and crash F-Spot. I'll post the error > stuff below. When importing from directory the roll name is ignored because I assume that the photos are already well in place. Maybe this behavior could be changed when "Copy to Photos folder" (or whatever it is called) option is set. I should investigate about the error: as said in a previous comment, I'm not a C# developer... I'll take a look. > > Anyway, the directory structure feature works great. Thanks so much! The Roll > feature, though, was a little confusing. I think it may be better to use Tags > for such an idea, though it would probably require more work in different areas > of F-Spot. It could require, as Mike said above, a master tag. Maybe the Roll > name could simply be the master, or initial tag, though. When you put in a Roll > name, maybe it could not only serve as a Folder/File naming mechanism, but also > create and apply the Roll name as a tag to the photos being imported. > > I also found the way the Roll name works a bit confusing, in that it was > applied automatically (according to the tooltip). It would be nice to see > 'roll' as an option under the Folder and Filename formats instead of being > appended automatically. For example, I could set my folder structure to yyyy/MM > MMM - roll. So my files would be under 2009/07 July - My Birthday. > I agree. By now, roll name is simply a file-system matter and I guess confusion arises from this "low level" aspect (I understand developers' doubts to fix that bug...); to use it as master tag is a good idea. My original aim was to add the roll name as new entity in the database (thus "Roll name", see my comment #11), but this would require (too) deep changes in f-spot; maybe in the next major release... Maybe a cleaner solution could be: - strip off all directory structure options from preferences, leaving them only as gconf settings (so to make happy basic users and developers :) ); - apply the "Roll name" (it could be renamed as "Album" or so, to avoid confusion); - append the "Roll name" to filename if a proper gconf key is set. As alternative, one could completely avoid the "Roll name" and append the first tag set (if set) to filenames and (last item of) path (lowest impact solution: no UI changes). I'll try to do it as soon as I get some spare time.
I just wanted to say that I also think F-Spot should be able to use directory structure. I don't want to tag all my photos to have them sorted, there are so many ... I cannot use F-Spot because of that. I would like to help but I don't know how. Thnak you.
Hello, I refactored the patch proposed by myself (and refreshed against git...), splitting it and minimizing UI changes. Now there are: 1. custom-path-format.diff: splitted; now it contains only the logic to support custom path and filename format 2. custom-path-format-UI.diff: contains UI changes (only the roll name entry in import window) 3. custom-path-format-extension.diff: adds an extension to safely set custom path and filename format, with much more stronger validation of pattern (and exception management... No more copy&paste programming... ;) ) If you want avoid UI changes at all, you can apply only 1 and 3, but of course you will lose the ability to set a suffix (the "roll name") to files and folder. An alternative to roll name could be a checkbox in the extension to which decide if the first tag set in import dialog should be also the roll name (see Comment #29). I'd like your comments about that. Prebuilt packages with patches applied are available in my PPA (see Comment #27). Regards
Created attachment 144304 [details] [review] Core changes to support custom format and roll names
Created attachment 144305 [details] [review] UI changes to support roll names
Created attachment 144306 [details] [review] Extension to safely manage custom format
This seems a very important bug, to have gone so long without being merged. Currently, I have to use other means to download photos from camera or card (exiflow, or Rapid Photo Downloader), then import them into f-spot afterwards. It would be much simpler if f-spot could simply handle custom renaming of files on import.
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.