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 329040 - Import to directory structure
Import to directory structure
Status: RESOLVED WONTFIX
Product: f-spot
Classification: Other
Component: Import
WISHLIST
Other All
: Normal enhancement
: ---
Assigned To: F-spot maintainers
F-spot maintainers
gnome[unmaintained]
: 351624 412674 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-01-29 04:39 UTC by Bengt Thuree
Modified: 2018-07-12 00:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Adds support for custom directory structure (5.10 KB, patch)
2007-02-28 07:31 UTC, Michael Wayne Goodman
none Details | Review
Allows custom path formats for importing photos (now including the UI changes) (7.85 KB, patch)
2007-03-01 21:32 UTC, Michael Wayne Goodman
none Details | Review
Allows custom path formats for importing photos (now including the UI changes) (7.83 KB, patch)
2007-03-01 21:39 UTC, Michael Wayne Goodman
none Details | Review
Allow custom import path/filename format and roll names (33.86 KB, patch)
2008-06-14 15:59 UTC, Alessio Gaeta
none Details | Review
Import Options within Windows Gallery (48.37 KB, image/jpeg)
2009-02-09 17:23 UTC, Lu Timdale
  Details
Import Options within Windows Gallery (48.37 KB, image/jpeg)
2009-02-09 17:24 UTC, Lu Timdale
  Details
Import Options Dialog from WIndows Gallery (48.37 KB, image/jpeg)
2009-02-09 17:26 UTC, Lu Timdale
  Details
Core changes to support custom format and roll names (9.92 KB, patch)
2009-09-29 21:30 UTC, Alessio Gaeta
none Details | Review
UI changes to support roll names (3.71 KB, patch)
2009-09-29 21:30 UTC, Alessio Gaeta
none Details | Review
Extension to safely manage custom format (752 bytes, patch)
2009-09-29 21:31 UTC, Alessio Gaeta
none Details | Review

Description Bengt Thuree 2006-01-29 04:39:15 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.
Comment 1 Bengt Thuree 2006-05-18 02:49:00 UTC
Just a small update.
F-Spot stores the photos in YYYY/MM/DD structure.
Comment 2 Ulisse Perusin 2006-06-24 09:33:12 UTC
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...
Comment 3 dnovotny 2006-07-05 23:35:49 UTC
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

Comment 4 apater 2006-08-07 22:06:17 UTC
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?
Comment 5 Jason Switzer 2007-02-27 23:55:07 UTC
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.
Comment 6 Michael Wayne Goodman 2007-02-28 07:31:44 UTC
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!
Comment 7 Michael Wayne Goodman 2007-03-01 21:32:57 UTC
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.
Comment 8 Michael Wayne Goodman 2007-03-01 21:39:04 UTC
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.
Comment 9 Stephane Delcroix 2007-03-01 21:47:49 UTC
>  so I'm not sure but you might have to run autogen.sh before building.

you don't have to 

Comment 10 Bengt Thuree 2007-03-01 23:47:15 UTC
*** Bug 412674 has been marked as a duplicate of this bug. ***
Comment 11 Alessio Gaeta 2008-06-14 15:59:34 UTC
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.
Comment 12 Maxxer 2008-06-30 20:44:36 UTC
*** Bug 351624 has been marked as a duplicate of this bug. ***
Comment 13 Eirik Hektoen 2008-11-16 09:07:39 UTC
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.
Comment 14 David Prieto 2008-11-16 11:42:31 UTC
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
Comment 15 Maxxer 2008-11-16 18:13:24 UTC
(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.
Comment 16 Marcus Sundman 2008-11-18 23:02:58 UTC
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/
Comment 17 Lu Timdale 2009-02-09 17:15:40 UTC
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.
Comment 18 Lu Timdale 2009-02-09 17:23:01 UTC
Created attachment 128309 [details]
Import Options within Windows Gallery
Comment 19 Lu Timdale 2009-02-09 17:24:29 UTC
Created attachment 128310 [details]
Import Options within Windows Gallery
Comment 20 Lu Timdale 2009-02-09 17:26:32 UTC
Created attachment 128311 [details]
Import Options Dialog from WIndows Gallery
Comment 21 Márcio Vinícius 2009-02-09 19:40:26 UTC
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.
Comment 22 Flavio Tordini 2009-04-23 09:37:48 UTC
@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?
Comment 23 Lu Timdale 2009-04-29 04:56:12 UTC
> 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
Comment 24 Flavio Tordini 2009-04-29 15:46:49 UTC
> 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.
Comment 25 Lu Timdale 2009-04-29 22:35:41 UTC
(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.
Comment 26 Mike Gemünde 2009-05-11 07:33:26 UTC
(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.
Comment 27 Alessio Gaeta 2009-05-17 13:30:26 UTC
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.
Comment 28 Darin 2009-07-28 21:19:58 UTC
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
Comment 29 Alessio Gaeta 2009-08-08 13:03:29 UTC
(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.
Comment 30 theo 2009-08-10 20:19:11 UTC
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.
Comment 31 Alessio Gaeta 2009-09-29 21:28:14 UTC
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
Comment 32 Alessio Gaeta 2009-09-29 21:30:17 UTC
Created attachment 144304 [details] [review]
Core changes to support custom format and roll names
Comment 33 Alessio Gaeta 2009-09-29 21:30:58 UTC
Created attachment 144305 [details] [review]
UI changes to support roll names
Comment 34 Alessio Gaeta 2009-09-29 21:31:47 UTC
Created attachment 144306 [details] [review]
Extension to safely manage custom format
Comment 35 Matthew Rasnake 2010-06-24 02:31:46 UTC
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.
Comment 36 André Klapper 2018-07-12 00:12:13 UTC
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.