Flutterby™! : testing Dan's picture management software 2004-10-06 22:26:48.263183+00

testing Dan's picture management software

2004-10-06 22:26:48.263183+00 by Dan Lyke 10 comments

To those of you who responded to my brash notions that I can redefine the world with offers of testing my picture management software, I'd like a little feedback so that I can prioritize. My goal here is to ship something as fast as possible, and to do that I need to find a few people whose needs I can hit quickly. So, if you'd do me a favor and answer these questions here and then email me contact info (danlyke@flutterby.com), I'll try to get something that's somewhat usable and from which we can migrate data to future versions as quickly as possible. This will not initially be software for novices, and while I'll do my best to make damned sure you don't lose any data, everything else may crash, and releases may be measured in hours. Please answer these questions even if that caveat scares you.

What's your current system for holding your photos? For instance, I use the Flutterby code to organize my images, on each of my computers I have an "images" directory, under that there are a series of directories, most of which are of the form "aaaa####", where "aaaa" is some identification of the source of the image (which camera, or "pcd" for PhotoCD scans) and "####" is a sequential number. In those directories are the files as they come off the camera, ie: "img_1234.jpg", with alternate sizes as "img_1234.sm.jpg" (and "sm" gets replaced with "md" and "lg"), although sometimes thumbnails exist as "img_1234.thm", especially where the original file isn't a JPEG. These files exist over at least 4 different machines, often redundantly, sometimes some machines (like the colo server and my laptop) only have smaller versions or crops (usually denoted "img_1234_crop.jpg") of the images.
Do you have a common naming scheme for thumbnails, crops and other transformations from the original image?
Are these images from digital camera sources, or scans?
Do you have a GPS device?
Windows or Linux? (not worrying about Mac yet, I'll get there)
If Linux, what's your desktop environment, KDE, Gnome, or something else? And do you have any databases like MySQL or PostgreSQL running?
Do you have or are you comfortable installing relatively recent versions of Python and GTK? (I'll offer some handholding on these, but I'm not yet to building self-contained Windows executables).
If you have a database running, do you expect to use this software in a multi-user environment? If so, describe it.

Still making no promises, and if I get the right offer to do something else I'll drop this, but we're re-structuring so that we can live cheaply and have a really tight grip on household finances, and if I can get a few other people who are willing to sit through some really horrid iterations, tell me when things suck, but who might find value in this software, maybe we can go somewhere.

And if you work with a hosting provider of some sort, either flat web hosting, photo sharing, "social networking", or even free email, let's talk. The hypertext editing features mean that sharing albums is going to be pretty high on the list, and because of the security issues I've talked about with the snippet manager, this means that there'll be room for some strategic relationships with web services providers who can offer portions of the publishing and sharing infrastructure.

And do you have text descriptions of images, either by directory or individual file, in any format, and do you have GPS tracks?

#Comment To expand that: made: 2004-10-07 16:36:20.086375+00 by: baylink

the most important thing for audience expansion is likely to be *extensible metadata*. You can interpret the parts of the metadata you recognize, and provide semantics for them, but permit other metadata as well, and don't restrict *it's* metadata.

This is a corollary (or perhaps an implementation) of my primary systems design philosophy statement: Get The Glue Right. If there's an outside-world interface necessary, and someone's already got one, use it; don't create your own.

#Comment Oh, and have you made: 2004-10-07 16:36:57.700251+00 by: baylink

*extensible metadata* is all well and good, but metadata extensions need to be managed by a standards group (or at least, search is focused on standards). If two users extend their metadata with different tags for the same information, then the metadata is useless.

#Comment Someone needs to standardize made: 2004-10-07 18:19:32.243659+00 by: baylink

the formats for that metadata certainly, but *my* point is that *his app* is not that thing. If it exerts any control over the metadata that isn't strictly necessary to it's internal operation, then it limits itself.

But if I impose no structure to the metadata, then the system is a construction kit, not an application. My limitations of structure so far are that the descriptions to images can be marked up with regions identifying a name ("Dan"), a location ("Fairfax, California"), an object or class of objects (I'm using it for "redwood" and "butterfly" as well as for "Dan's BMW 528e"), or an event ("Burning Man 1998"). The marked text can link to something different from the displayed text (so "Dan" can link to "Dan Lyke"), there'll be a lot of experimentation in trying to auto-fill those values.

And obviously the snippet manager

notions of security and presentation will eventually have to come into play.

It's been a loooong time since I've looked at Z39.50, but last time I did it was pre-RDF, so I guess I should refresh myself on both of those.

#Comment Re: Answering Dan's Questions made: 2004-10-07 21:38:05.57178+00 by: spc476

#Comment Re: Answering Dan's Questions Part II made: 2004-10-07 21:52:48.352457+00 by: spc476

I have a top level directory for the year, then beneath this is a directory in the form of MMDD where pictures I've taken that day are dumped. If there are multiple sets per day, I'll create another directory off the year, but something like MMDDa or MMDD-2; I'm not consistent in that reguard but it doesn't happen often. The filenames are what the camera gives them (pXDDnnnn.jpg where X is a number or letter designating month, DD is the day, and nnnn is the image number). I have a script (files are stored under Linux) that will go through and extract the thumbnail from the exif stored in the image, and give this a file name of t-original.jpg. This is so I can use xv to view the thumbnails and not kill my machine (it's an older machine).

As long as a I have a reasonable timeframe for when I took a picture I can be fairly sure I'll find it.

Thumbnails are typically in the form of t-original or thumb.original (the latter is what I use for posting thumbnails to my blog). I generally don't bother keeping the transformed images around (once posted) since they're stored elsehwere or I don't care to keep the results.

This structure is used to store only digital pictures; scans are stored elsewhere—I don't do enough scans for it to be an issue right now, but I could always use a similar format when I do.

I do use both Linux and Windows, depending upon what I need done, how quickly, and where I am.

I do not use KDE or Gnome (fvwm—I prefer a minimal windowing system and my Linux systems are a bit old but still usable). No databases running either, but if I had to use one, I'd probably select Postgres over MySQL.

I'm also relunctant to install Python or GTK since I don't use these products in my day-to-day life. If your software is compelling enough, I may break down and do it (and the Windows box has my home directory mounted).

And except for what's in the jpeg itself, no other metadata exists for any of my pictures.

I use fvwm too, my question about desktop was mostly based on drag-and-drop protocol, but it turns out that apparently both do things similarly enough that I don't have to worry about it. What I most wanted to avoid was writing yet another filesystem browser.

Final Windows version will be a self-packaged executable, and I think I'll impose on Meuon and Topspin sometime late next week (hopefully!) for my first pass, spare the rest of you the pain for a short time.

Ok, to clarify: You are *expected*, yes, to store some metadata concerning images yourself. You should, however, also *allow* the storing of other metadata which you may not even understand, merely as a repository.

I can't escape thinking that this may be a good place for the backend/frontend design pattern; the discipline of making an engine and a client that can talk to it will be useful in this juncture, I think.