[Shotwell] [oliver at first.in-berlin.de: Re: Some More Suggestions (Re: suggestions)]
oliver
oliver at first.in-berlin.de
Wed Aug 3 12:06:26 UTC 2011
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 -----
More information about the Shotwell-list
mailing list