[Shotwell] [oliver at first.in-berlin.de: Re: Some More Suggestions (Re: suggestions)]
oliver
oliver at first.in-berlin.de
Thu Aug 4 00:55:11 UTC 2011
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 <oliver at first.in-berlin.de> -----
>
> Date: Wed, 3 Aug 2011 14:00:55 +0200
> From: oliver <oliver at first.in-berlin.de>
> To: Eric Gregory <eric at yorba.org>
> 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 <oliver at first.in-berlin.de> 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
> Shotwell at lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
More information about the Shotwell-list
mailing list