I’m planning a fairly large rewrite of the Filmulator database, to make it a more effective asset management system. I think I can satisfy my own needs, but I’m interested in hearing what people think of it.
So…
On import, you could either import in place (leave the photo where it is, have default output placed in the same folder), or copy into a folder structure. Right now, it only ever copies into a folder structure.
On import, you could select whether or not to back up the photo, and to which (possibly multiple) destination(s). Right now it only backs up to one folder, and the only way to disable it temporarily is to introduce a typo into the path in which case it assumes the backup drive isn’t present.
On import, you would tell it who took the photo. I’ll probably allow the field to be blank, and it’d assume it’s you. As you enter them, it would list existing photographers in the system; this’ll be nice for hiding photos that aren’t yours, such as samples from new cameras, raw editing challenges (PlayRaw, etc), or more.
You’d be able to tag photo files on import. Both by bulk-tagging all of a single import, or by snagging individual photos as they get imported and adding tags manually (I’ll add a view to the import tab).
That’s all for now.
Any thoughts? Comments? Suggestions? Obvious things I’ve missed? Explanations of your own workflows?
My personal view: I don’t expect my DAM/raw development tool to physically move files around during import as default. There are specialized solutions such as rapid photo downloader for this part, which provide the backup functionality as well. It would, however, make sense as an option (or at least an option for disabling this part would be reasonable). Furthermore, it would be great if it could coexist peacefully with other tools (darktable, rawtherapee, photoflow, photivo), at least not touching their sidecars or, even better, integrate with them somehow (e.g. when you set the author/title/tags etc., respect what’s in their xmp/pp3/whatever.
When filmulator is called with an image (e.g. at the command line), it would be great if the development process would be available, skipping the DAM part.
What I was always dreaming of was an integration of photo management (in my case darktable) with git and git-annex (https://git-annex.branchable.com/), since I have xmps in git and plan to put raws into git-annex. But that goes way beyond your question. I just could not resist
For me Filmulator is my full workflow DAM because I wanted it to be aware of the backup in a more intelligent way, syncing changes made to the edits with a database stored on the backup, to enable easy collaboration between different computers. Thumbnails too, probably.
I’d connect to the external, it says “oh these files got edited when Carlo was on his laptop, I better pull in those thumbnails” or something.
I understand that my backup scheme is probably very atypical though, being an interchange method between computers as well as a backup, maybe I’ll just do this part for me. It would have the benefit of better communicating albums and inter-image relations than simple sidecar files would be able to.
I’ve thought about how to make a standalone editing part, but it’ll be interesting, because of my intended separation of input and output stuff between the tabs, like having resizing, output sharpening, and color space transformations at the end. At the moment there’s nothing terribly hard about it, but I haven’t decided the table structure in there yet.
I’m thinking that individual SQLite databases might work nicely as sidecar files, given that despite being heavier than text files they’re still far smaller than the raw files they’d be stored alongside, and could hold more than one profile at once, and work more nicely with the rest of my code. Even if you tell it to leave sidecar files, I’d probably still have it primarily use the main central database and only check the sidecars when importing or opening in the editor.
Be much more ambitious with metadata then just simple flat “tags”.
Who. What. Where. When.
Who includes the image creator and the copyright.
What includes “tags” or keywords which can be hierarchical and/or specific to only a part of the image, ie individual faces or species.
Where is GPS and textual location information.
When is when the shuttle was pressed and when the image was scanned and when the image was modified and when metadata was added. GPS Date/Time data is also useful here.
The capture time is already there, as will the import time. There’s already space for GPS in the database, but the database is going to be completely redone, and I don’t have the importing from GPS implemented.
Filmulator doesn’t really work with anything but raws, so scanned images aren’t going to count. (Why simulate film if you’ve already shot real film?)
Hierarchical tagging is a bit more ambitious than I care to do…what’s the use-case?
There is more that I haven’t brought up yet, such as grouping of processing profile/image combinations into albums for batch upload and things.
In my experience (mostly with darktable), the raw development applications that aspire to do asset management only do part of the job. As soon as you’ve developed your raw image, you’re on your own again. But the tiff file I export so I can do further processing in gimp isn’t an end result, it’s still something that’s on its way to becoming the final image.
Ideally my asset management software would let me treat the raw file, the intermediate tiff file and the xcf file gimp produces as various stages of a single logical ‘Image’, without me having to worry about where on my disk the stages are stored beyond configuring the rules for that initially.
That’s an important point you make, since I’m definitely the same way with Filmulator: usually it does all the processing that I need (not much), but I go out to GIMP for any heavier manipulations. Then I’d be doing all my uploading manually still…you’re right that it should have some way to add derivative files and associate them.
Any more specific example where it would be helpful?
Any user-interface ideas so that it wouldn’t get too cluttered, having a way to tag tags (that is what you mean by hierarchical tagging, right? Cats and dogs and horses are all animals, cars and planes and trains are all vehicles…)
Check out how darktable deals with hierarchical tagging, IMO it’s a reasonable approach. Of course one could always find possibilities for improvement … Whenever you have to input a tag the hierarchy is represented by simple “path dividers”, in dt’s case the vertical bar. You would input “animals|dogs|beagle”, which is convenient given a suitable autocompletion mechanism. To find/collect images by tags the whole hierarchy is represented as a tree with expandable branches. I use it mainly for tagging people (people|friends|…, people|family|…, people|models|…) and places (country|[state|]|city|street number, country|[state|][city|]POI). Very useful in combination with boolean operators, e.g. to find all pictures with exactly child and grandmother and nobody else.
In that case, what’s the distinction from just entering them as separate tags? I don’t see any material difference for either the user or the database: if you enter “people|friends” then you might as well enter both “people” and “friends” individually.
First of all, searching for people/places becomes much simpler since you do not have to browse through a flat structure. Especially if you e.g. do not know the exact spelling of a name/city and therefore you have to browse a lot of entries since text search does not help. Furthermore, one can use the same tags multiple times. I have a tree for picture deployment tracking (who got which picture for what occasion) which contains names from the people list. A person can be on the picture or the recipient of the picture, and the hierarchy tells me which applies. Similar for places, there are e.g. about 25 Oxfords spread around the world (technically you don’t need the hierarchy here since you could search for Oxford AND England, but without the hierarchy I guess one could easily forget about tagging the country). Just some examples from my practice, there may be better examples.
What I mean is that, as far as I can tell, that’s something the user has to do themselves, there’s no need to provision for it in the software. You just have to be able to complete anything containing the string you’re typing, not just ones that begin with the string you’re typing.
Entering tags is only the first part, searching for tags is another. Please, tag a couple of photos in darktable hierarchically and check what the collect module offers you afterwards. I guess, then it makes sense to you as well.
Currently, it’s not, in Filmulator it’s based on DateTime, and I have you manually tell the program the time zone the camera is set to in order for it to compute the Unix time which is stored in the database.
I guess that’s a bug, since software does exist that modifies raws and that is apparently going to change the DateTime…
