[Techtalk] photo collection management software

[John Sturdy]

On Thu, Jan 24, 2013 at 7:08 PM, Akkana Peck <akkana at shallowsky.com> wrote:
> John Sturdy writes:
>> You mention "keywords file" above, do you mean the same format that
>> pho outputs (or rather, the part of it other than rotate commands
>> etc)?
>
> I started writing up how I use pho and Keywords files to tag photos,
> and it got to be long (especially if we're the only two people here
> interested) so I wrote up and checked it in:
> https://github.com/akkana/pho/blob/master/doc/keywords
>
> The quick summary is...

OK, that all looks good.  I was thinking of having one big keywords
file for the whole directory tree, but a separate one per directory
may be better.  The same code could probably handle either without too
much difficulty; maybe give (as command line options) a keyword file
name (or the just name of the directory to which names are to be
output as relative, and which presumably contains the keyword file)
and then the file names, which if that directory name occurs as a
prefix to them, are output relative to that prefix (the minimal case
being empty directory name and empty prefix, i.e. it's all in one
directory).

> We should talk about file format options. I don't use org mode
> myself (though I do use emacs for editing) but that doesn't mean I
> couldn't use the format. Or we could make the file's format configurable.
>
>> But whatever the file format is, I'd suggest being able to preload the
>> keywords from it, and write them back to it afterwards.  I'm happy to
>> have a go at this myself.
>
> Definitely. Been meaning to do that for ages, and just haven't gotten
> around to it. I've been lazy, and cat > Keywords is so easy.  :-)

The details of the format are presumably easy enough to make variable
(even allow sprintf and sscanf format strings as command line options,
on top of some prepackaged formats such as org and csv?) but a choice
which would take separate coding would be whether to list photos by
keyword entries (showing which files are under which keyword) or by
file entries (showing which keywords apply to each file).  Either way,
I'm sure one line per entry is the way to go.

>> I'd like something where I can categorize a run of related photos with
>> at most one keystroke per photo --- I'd probably put that onto the
>> return key, so the space bar means "go on to next photo" and return
>> means "tag this photo the same as the previous one, and go on to the
>> next one".
>
> Almost. From the Keywords dialog, you can tag with a keyword that
> already exists with Ctrl plus a number, e.g. <Ctrl>2. If you aren't
> going to add any more keywords, then you could keep your focus in
> the image window and just type 2 and not need the control key.
> There's no keystroke for "use same categories as last photo"
> though it would be easy enough to add.

If the program can read a keywords file from a previous run (and
particularly if it can read them for multiple directories, which might
not be a good idea for something that's simple and clean; or if it can
read one for a directory tree) I can see building up to more than ten
or twenty keywords.  Just off the top of my head (i.e. I haven't
prototyped this to see how well it works) I'd suggest allowing ten (or
twenty, if using Alt for +10) rows of keywords, and letters within the
rows.  The UI would show each row with an indication of which one in
the row was most recently used, then if you just use the digit,
followed immediately by a command that moves to another picture, or
use another digit thus selecting another row, it uses the latest tag
in that row; but if you then press a letter, it selects the tag on
that row that's associated with that letter.

How I'd use this would be that I'd have a row (or rows) of tags for
places, one or more for subjects, and one or more for named people.

>> If there were a thumbnail window, I'd want something like emacs'
>> numeric prefix, so I could tell it "tag the next 12 photos the same as
>> the previous one", and thus have even fewer keystrokes and be even
>> faster!
>
> That would be great in a thumbnail-based tagging program. My problem
> with thumbnails is that I can't see enough of what the photo is
> about (is that 3-pixel thing there in the center a lizard or a
> sparrow?) And choosing a photo, zooming in then getting back to the
> thumbnails almost always requires a lot of mousing around.

I was thinking of something like eog's interface, with the selected
photo taking up most of the display area, and an optional strip of
thumbnails along the bottom.  A lot of my photos are scenery, and
don't need looking at small detail; "lake", "mountain", "sunset" and
so on are often enough; or I may just be classifying things by
location, and have taken a lot in one place before moving on.

>> And the other thing I've thought of so far would be to have a
>> file-level rename command.
>
> Okay by me, though I doubt I'd use it myself -- I use the shell for
> anything like that.

Outputting "mv" commands to run separately would serve my needs there,
but I like not to have to copy or type the camera-generated filename
if I want give the file a descriptive name.  I also want to be able to
sort pictures from the time-ordered directories from the camera, into
subject-grouped directories; something like your tagging mechanism
would be good for this, but I'd want it to be a separate mechanism, so
that the software can track what name the file has been allocated to,
and output the tags as being associated with the final filename.

__John