any feedback on the issues? What do you think about the repostitory-like structure? (pics + database in "local root")
Does that make sense to you? Ciao, Oliver On Wed, Aug 03, 2011 at 02:06:26PM +0200, oliver wrote: > Hey, > > > forgot to also send to the list... > > > > > ----- Forwarded message from oliver <[email protected]> ----- > > Date: Wed, 3 Aug 2011 14:00:55 +0200 > From: oliver <[email protected]> > To: Eric Gregory <[email protected]> > Subject: Re: [Shotwell] Some More Suggestions (Re: suggestions) > User-Agent: Mutt/1.5.20 (2009-06-14) > > Hi, > > > On Tue, Aug 02, 2011 at 04:58:28PM -0700, Eric Gregory wrote: > > Hi Oliver. > > > > Taking your suggestions one by one... > > OK. > > > > > > > On Tue, Aug 2, 2011 at 4:38 PM, oliver <[email protected]> wrote: > > > > > View: > > > - Rejected-only view [ at the moment it is All + rejected; btw: "All" is > > > a misnomer to be picky; > > > "All" would of course include "Rejected" ] > > > (that feature makes sense to view again the deselected files only, e.g. > > > as last > > > step before deleting them.9 > > > > > > - n-stars-only view (additionally to >= n-stars view) > > > [ this feature is not as important as the "Rejected-only view"; > > > maybe it could be part of an "expert view" or "detailed view menue"?? > > > ] > > > > > > > All of this is already possible using the saved search feature of Shotwell > > 0.10 or newer. Open Shotwell, hit Ctrl-S, and you can create just about any > > rating search criteria you'd ever need. > > Hmhh. I have 0.7.2 and nothing happens when I do "Ctrl-S". > Tried it on Ubuntu/Gnome. > I also maybe will try it on Arch with wmii later. > But Ctrl-S should work, and not be caught by the Desktop Environment > (Ctrl-S in terminal works) so it seems not to work in shotwell. > > > > > > > > > > > > > Data-Export: > > > - Export of Star-Numbers and Tags (and other kind of information?) for > > > the > > > files > > > (possibly as *.txt, *.csv, *.xml) > > > > > > > Agreed, this would be useful. I filed a new ticket on this here: > > http://redmine.yorba.org/issues/3909 > > It's not only for moving to a new machine. > It might also maybe make sense to have a c2v/text based output > so that parsing of that is easy. One might want to convert that to > HTML, LaTeX or read it in in R, to make some statistics about it. > > If Metadata like f-stops or focal length also can be exported, it is useful > too, > because fopr example based on that data I decided which new lense I would buy. > I used jhead for getting that kind of data out of my jpeg-files and > R to look at the focal length then. > > Then I decided to buy a certain lense, which has a certain focal length > (not zoom; fixed focal length). > > So, that kind of data can be useful ven if you not just want to > move to a different system. > > > > > > > > Also note that some information (tags, titles, etc.) can be stored in the > > image files themselves if you enable metadata writing in the preferences. > > At least in jpeg that works. > I don't know if shotwell also supports raw files. > I would not like to change the origianl files. > And a database external to the picture files, > but located close to the pictures would makie sense to me. > I will explain what I mean later, the topic also is what I mentioned in > the other points. > > > > > > > > > > > File-Comparison: > > > - compare files in the collection based on file-contents (byte-by-byte or > > > checksum) > > > - compare data-only (e.g. ignoring jpeg/exif-headers, just comparing the > > > picture data) > > > also as byte-by-byte or checksum > > > [ this makes sense for multiple copies of a file, which just have > > > different jpeg/exif > > > headers (maybe by adding jpeg-comments), but which is nothing new > > > regarding the > > > picture data itself ] > > > > > > This doesn't seem like something that would typically be found in a photo > > manager. We already scan for duplicates when importing. What would the > > use-case for this feature be? > > The use-case would - of course - be to detect duplicated. > If shotwell has this already, thats fine. :-) > > So let me emphasize on of the things I mentioned: it's possible to detect > a duplicate by comparing the whole files. But if the picture inside a jpeg > for example > is the same (same data), but the comments or other data in the jpeg-header > differ, > then comparing the whole file would say: these files differ. > But they only differ in the comments for example and contain the same picture > data. > > I would like to have then ONE file, maybe with both comments, not two files. > At least I would not like to have the file added to the database more than > once. > Adding comments / tags etc. and store them inside a picture file would mean > to have > many different files which just differ in the comments. > > With an external database (not storing tags inside the picture-file) > I also would like to have files with same picture-data stored only once. > > > Do you see what I mean? > > > > > > > > > > > > > > > Exporting Path: > > > - Exporting Path of one or more pictures by drag-and-drop; > > > for example if you drag&drop files into a terminal-application, > > > the terminal-application gets the paths of the files as pasted text. > > > [ This makes possible things like cp > > > <dragged-and-dropped-list-of-files> <working_dir> ] > > > > > > - The same via menue: "Copy location" (Ctrl-C) for one or more than one > > > file and then paste > > > (a la Ctrl-V) > > > > > > > We have an open ticket on this: > > http://redmine.yorba.org/issues/1563 > > Ah, nice. :-) > > As I work with terminal/shell often, support of drag&drop filepath to the > terminal > would be nice. > > > > > > > > > > > > Supporting Multiple File-Folders: > > > > > > - (1) Support more than one directory as file-repository > > > - (2) Support easy change of such repositories from one place to another > > > (e.g. files must be shipped from one disk to another) > > > - (3) Support changable media > > > > > > [ all these three might be possible, if the databases are held locally to > > > the > > > folders where the pictures reside; the shotwell-index then is a > > > collection > > > of links (or include's) to (of) the many possible picture-directories. > > > > > > (1)...(3) can be done via shotwell including/linking-in > > > picture-collections > > > as seperated files-plus-database-combinations; > > > shotwell-index then would be a meta-index that points to > > > directories of picture-files and a database in the "root" > > > of each of those picture-directories (like mounting-in a > > > complete repository > > > that also contains the index) ] > > > > > > > 1. We already support following links, which should be fine for most power > > users out there. > [...] > > > I did not meant links from the filesysteem (ln(1)). > The word link might be misleading here. > I try to explain again, what I meant. > > > > > 2. I'm not entirely certain what you mean by "repository" here. Are you > > referring to the database, the photo files, both...? > > 3. We have an open ticket for this: > > http://redmine.yorba.org/issues/2954 > > > OK I try again. > > > If I use subversion for sourcecode, then there is a centralized repository > somewhere else stored. It is "far away" from the source and the working > directory. > Even I have a local copy, the "official" repository is somewhere else. > > If I have pictures stored in > /home/photouser/my_pictures_1/ > /home/photouser/my_pictures_2/ > /home/photouser/my_pictures_3/ > /mnt/external_photographs/pics_1/ > /mnt/external_photographs/pics_2/ > > and so on, but the pictures are stored and imported into shotwell > maybe in /home/photouser/Shotwell-Pics, but the data is *always* > and *only* in > /home/photouser/.shotwell/data/photo.db > > Then I will get problems, if I unmount the external photographs. > > > If I use git as a repository for sourcecode, then the repository is > held inside the project-"root" and if I move the whole "project-root" > the database is included also. > > There will be no inconsistency if I move around those "picture-root" > directories. The database is always available. > > > So then one would have *many* file-directories / "project-root"-directories. > And the shotwell database would only be a Meta-Database, in which many other > databases / picture-root's / picture-"repositories" could be "imported". > > That "import" from meta-Database to "repository specific" database > is, what I meant with "linking in", because in the shotwell database > then there would only be stored a "link" / "pointer" to one of the > databases / project root-directories, and the 2real" database would be there. > > > Maybe one also could make a copy of external databases, and import it > directly into the shotwell-database; this would make sense, if one wants to > know, what kind of files are in which external picture-storage (e.g. DVD > or mountable device); but then also inconsistencies might occure, > if the external storage would have been changed. > Then there would be a need for a synchronisation (maybe not automaically, > but triggered by the user). > > I would prefer the git-like way, because then I would have not only > the pictures transportable (e.g. going to a friend, who has a better printer, > or who wants to add his comments/tags to my files, or let someone else > give stars for my pictures ("what do you think about my pictures? are they > worth > printing?")). > Then also the meta-data would be available together with the pictures. > > Otherwise, I can move around the picture-files but not show a selction to > others. > I would need to note the pictures with four and five stars by hand... > ...or use the export of that data. But this then must also be able to become > imported... > ...at least by shotwell. > And that looks like much additional work. > > > If the database is inside the picture-repository, then this would be much > easier. > > > To clarify this, I write down, how the directorystructure would look like: > > > /home/photouser/my_pictures_1/ > > This dir contains subdirectories with the files. > It also contains the "local" / "project-related" database: > > /home/photouser/my_pictures_1/.shotwell/data/photo.db > > > > /home/photouser/my_pictures_2/ > This dir contains subdirectories with the files. > It also contains the "local" / "project-related" database: > > /home/photouser/my_pictures_2/.shotwell/data/photo.db > > and so on. > > > Then instead of only > > /home/photouser/.shotwell/data/photo.db > > there might be also > > /home/photouser/.shotwell/meta.db > > > And the pictures for which > /home/photouser/.shotwell/data/photo.db > is responsible would be in subdirectories of > > /home/photouser/ > > > > So, what I'm asking for here, is a different way of how the > data will be handled. > This would need restructuring of the whole concept of the database. > > This would also mean: newer shotwell not necessarily would be able to read > the old databases. > But a converter script for old-style to new-style might be run once > and the work is done. > > So instead of the necessity of importing files and information in ONE > directory, the import could be done seperately into different > storages/"project repositories". > > > Then also operations like > "store all files with the tag 'birds' into /home/photouser/birds/ > repository" > and > "store all files with the tag 'dance' into > /mnt/external_photographs/dance-pics/" > > > In my *humble* opinion, this is a good idea. > > > > > > > > > Supporting big number of files efficiently: > > > - some thousands and some tenthousands of files should be handled > > > efficiently > > > and with high performance (of course reliable also) > > > > > > - to be honest: some hundred-thousand files might be the next step > > > > > > (which I did not reached so far; I just started with photography few > > > years > > > ago and the delimiting software possibilities were rather blocking > > > easy > > > photographing, > > > because software often made me thinking to much about the software, > > > and > > > how and where to store > > > the files... but bettr would be: this is transparent and most of the > > > time you think about > > > photography and the shot photographs 8which I hope are shot well > > > :-)) > > > ) > > > > > > > "Reliable" or "efficient" aren't very precise terms. > > Heheh, yes. > > But there are O-notations for algorithms. > If you store anything in a list, when an array or a tree would be better, > this works good for a hand of files, or for 100 files, but with 1,000 > 10,000 or 100,000 files, this will surely become very slow. > > So I'm asking for using appropriate algorithms for storage and > access. > > My experience with f-spot were: it becomes slow. > Also the way, how the thumbnails are handled > are not optimal in f-spot. The creation of not already > available thumbnails needs much ressources. > They should only be created for that part of the files, > which I'm looking at in the overview-window... > > If shotwell prforms well here, i don't know. > I have just some hundered files imported into shotwell so far. > > > > If you think there's > > something we could optimize more you're probably right! Contributions in > > this area, whether tests, code reviews, or patches are always welcome. > > I could halep with C-Code. > Not sure if this would help you; I did not looked at the language you use > for shotwell in detail. It seems to be a new language. I don't know if it > performs well. > But if there is an easy way of interfacing C with that language, > I might help there. But maybe there is no speed problem with that language. > I don't know. > > AFAIK there are already some libraries that provide tree structures available. > Maybe they can just be used and married with shotwell. > > > > > > > > > > One remark on speed/performance: Shotwell seems to be comparingly fast. > > I have to add: the first impoirt needed very long. > There seemed to be a bug, which after importing made shotwell > long and eatiung up much ressources. > I then killed it and started it again. The import was successful > and I could use shotwell. > > So I think the import was fast, but somehow, somewhere was a bug > that ate up the ressources. If this will be fixed, maybe it's > really fast. > > > > > But I have less than 500 pictures used in shotwell, and in my F-Spot > > > directory I have more than 30.000. > > > > > > If shotwell keeps scaling well, it will be faster than f-spot even with > > > that > > > number of pictures. I hope this holds true. I'm not sure here, because > > > f-spot also was "fast" with just a few files. > > > > > > > The startup speed will of course diminish with more files, but it shouldn't > > be unacceptably slow with collections of hundreds of thousands of photos. > > I talk aboout 30.000 and maybe 100.000 photos. > And maybe even more. > > Keep in mind algorithms and O-notation. > > > > We > > know we have users who have this many photos, and no complaints from them > > about speed -- so far! > > OK. > > If I could use shotwell with different external repositories (see above) I > could try it. > At the moment my HDD is full. So I will have some extra work to make my tests > with > much files. > > Ciao, > Oliver > > ----- End forwarded message ----- > _______________________________________________ > Shotwell mailing list > [email protected] > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
