missing features: film roll and sidecars?

Hi!

I’m enthusiastic about filmulator! It seems like the best of two worlds: simple to use yet powerful. I’m currently using Darktable with Rapid Photo Downloader and there are two features I’m worried I’d miss when switching over:

  • “film rolls”: RPD, when it imports photos, asks for a “name” for this import batch, which in turn in Darktable becomes a “film roll”. I was annoyed by this workflow in the past, but now I absolutely love it because it acts as a quick and dirty first pass at tagging things. is this something that’s planned? In my workflow, images end up in a folder like Photos/YYYY/MM/DD/TAG/
  • sidecar storage: Darktable, when I edit the rating of an image, writes that in a sidecar file. this is really useful to act as a backup of the Darktable database… even if I lose that database, I can restore image ratings from there (and synchronise them across devices)

Speaking of which… i don’t see “rejected” as a rating (only 0-5), is that planned as well?

Congratulations on the great project, and sorry if this “I want a poney” question is annoying. :wink:

1 Like
  1. There’s one main database, no “film rolls”. I’m planning on implementing tagging soon, and one thing I plan is to make it possible to apply a tag to every image as you import.
  2. There are no sidecars, because personally I just don’t like them. If you’d like to back up the database, it’s in ~/.local/share/filmulator. I might eventually make it possible to manually output a sidecar, but I think I won’t make it automatic. Maybe.
  3. Rejected is a rating; it’s not really easily settable in the Organize tab, but you can do it in the queue with the keyboard shortcut X to apply to the current image, or by right-clicking and selecting X from the list of ratings.
1 Like

I really liked the way Shotwell implemented “tagging”… It grouped images by shots automatically, first off, and then you’d drag and drop images onto a tree of tags… It worked quite well. Too bad that software kind of fell off the wayside…

I didn’t like them at first either, but now that I realized that DT can sync stuff across workstation with them, I can’t live without them.

Backing up the database isn’t really an option, unless it’s a magically distributed database which handles conflicts better than git (good luck with that)… :slight_smile:

And outputting a sidecar is only part of the equation… DT also reads from the sidecar on (re)import, so that’s also an important part in the magic sauce…

I see! I suspected as much when reading the manual, but couldn’t quite figure it out. Maybe it could be made more obvious… DT uses the r key by default (along with 1-5 for numbered ratings, with 0 to unset) which I find quite logical…

Anyways… sorry to be the “please be more like darktable” guy, but those seemed like fairly simple improvements that could be brought over without making the program too complex. (And all those don’t need to have much visibility: they don’t complicate the UI, if tagging is optional.)

Thanks for the fast response! :slight_smile:

When the Filmulate view is empty, it has a guide…

I can certainly make Filmulator read a sidecar if I do have them exist. I’ll definitely think about it.

1 Like

How will the tags be shared with other raw developer software, if not via XMP?

I hadn’t put any thought into sharing tags between software at all, since Filmulator is a mostly complete workflow starting from import.

But details like this are why I haven’t implemented tags yet; I don’t know all the use cases.

What sort of interoperability would you expect?

1 Like

The industry standard, i.e. XMP.

you rock. :slight_smile:

What functionality is expected?

Do you want to lock in user created tags into your program so that no other program understands them? Keep them in a database only your program reads.

Do you want tags created by your program be able to be read by other programs? Use XMP, including sidecar files.

It’s as simple as that.

Ugh, but I hate sidecar files…

Perhaps I’ll make them optional, and I won’t use them myself.

1 Like

What I get from Darktable is this:

  1. when I tag or rate an image, that information is written into the DT database (presumably so it can be shown fast in the GUI) but also to the sidecar
  2. when Darktable imports an image from disk, it also looks in the sidecar and prepopulates its internal database with that information if it’s not already set.

An example sidecar with ratings and tags:

<?xml version="1.0" encoding="UTF-8"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 4.4.0-Exiv2">
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about=""
    xmlns:exif="http://ns.adobe.com/exif/1.0/"
    xmlns:xmp="http://ns.adobe.com/xap/1.0/"
    xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:lr="http://ns.adobe.com/lightroom/1.0/"
    xmlns:darktable="http://darktable.sf.net/"
   exif:DateTimeOriginal="2019:01:01 17:20:55"
   xmp:Rating="-1"
   xmpMM:DerivedFrom="DSCF8015.JPG"
   darktable:xmp_version="3"
   darktable:raw_params="0"
   darktable:auto_presets_applied="0"
   darktable:history_end="0"
   darktable:iop_order_version="0">
   <dc:creator>
    <rdf:Seq>
     <rdf:li>Antoine Beaupre</rdf:li>
    </rdf:Seq>
   </dc:creator>
   <dc:rights>
    <rdf:Alt>
     <rdf:li xml:lang="x-default">CC-BY-SA-NC</rdf:li>
    </rdf:Alt>
   </dc:rights>
   <dc:subject>
    <rdf:Bag>
     <rdf:li>tree</rdf:li>
    </rdf:Bag>
   </dc:subject>
   <lr:hierarchicalSubject>
    <rdf:Bag>
     <rdf:li>tree</rdf:li>
    </rdf:Bag>
   </lr:hierarchicalSubject>
   <darktable:masks_history>
    <rdf:Seq/>
   </darktable:masks_history>
   <darktable:history>
    <rdf:Seq/>
   </darktable:history>
  </rdf:Description>
 </rdf:RDF>
</x:xmpmeta>

That photo was “rejected” (xmp:Rating="-1") and tagged with a single
keyword (tree). It has no post-processing performed, but that would
show up in the darktable:history and mask_history stuff,
presumably. Note that it also has dc:creator and dc:rights tags
for copyright stuff.

Obviously, it’s ugly as hell and XML. But it works, and interoperates
with even stuff like Lightroom, from what I understand (I presume
that’s what the lr: prefix stands for).

So from a cursory look at the xmp standard, it seems that what a program does with it isn’t standard, only the metadata format itself?

So for interoperability, I think I’d need to match what the other programs are doing with respect to tags, since that’s only a de-facto standard. Hmm…

It’s an ISO standard.

You keep saying this but all it means to me is “go buy the standard for 158 Swiss Francs” and even then I don’t even know if everything Lightroom does uses the standard schemas (above there’s dc:subject and lr:hierarchicalsSubject) so it might be a waste of money.

It means that tools like Exiv2 and ExifTool already understand XMP.

It means most of the hard work of figuring this stuff out has already been done by people who have deep experience with the topic at hand.

It means that there will inevitably be compromises affecting the purity of the XMP standard to account for how metadata was handled pre-XMP days. That’s life.

Carvac means that XMP can contain a ton of (arbitrary) data. What do you expect to work from a XMP file? Just tags? Date / import stuff?

I know of people who expect the edits from Lightroom to show up perfectly in another program because they are in a XMP.

Carvac: think about why you code. Do you get joy out of other people using your software? Then listen to ideas they have :). Do you use it for your own usage or workflow, do what makes you happy
you need to find a balance in this. I’m not going to say which way to go, but I find it helps a lot to know what the reason is to do it :).

Now…What I like about 'a database is that it k ows stuff from my pictures, even if they are not on the system.

Having one collection in online backup with a local copy on a NAS means that I don’t have all my files on all my laptops. I use multiple machines to ingest,multiple to edit.Depends in where I am at the moment :).

Having a database of everything, means I can search the database (with small thumbnails) to find files that are ‘in storage’, not on the system.

Having stuff (only) in sidecars makes it more difficult to search, since xmps need to be found and read. And if not everything is on my system,I can’t search sidecars that are online in storage.

So for speedier searches,programs often need some sort of database. Writing sidecars then feels somehow redundant. They always feel like clutter to me.
They help with transferring info from program to program… Yes. But that’s something I seldom do,so I don’t want them around.

Being able to write them helps to not be ‘locked in’ to a single program,so that is a big plus for sidecars.

Acdsee has a thing where they write the xmp section back into the files, so they are always with the file (and copying the file copies the metadata you added like tags). Sounds nice, but changing the source files seems wrong to me (the fact that they are hashed on my sotrage means they are not meant to change a single bit :)).

About ‘film rolls’ (or collections, or imports)…
I learned from Acdsee that hierarchical tags are good for everything. It doesn’t have a concept or albums,groups or collections. Just the folders how I ordered them.
But add a tag 'film rolls, and add a tag under that. Assign it to images (during import for example) and there you have it. Nothing is stopping you from adding images to more than one filmroll this way. And also you can still add tags for things like people, locations, etc…

So…Maybe keep the database and build it how you see fit. But add an option somewhere to export xmp files next to source files. As a single action to do when someone wants to transfer info to other software.
And maybe import xmp the same way (with an option to delete the xmp after import :grin:).

As for functionality, I think hierarchical tags and ratings are the basics.An exif block (or the same fields as basic exif copies) is also expected I think (gps, make,model,dates, title, author. . To name a few.

And I think people will expect it to use it as a backup or transfer to other computer kind of thing, so serializing the filmulator settings to it is probably also what people expect.

Personally, I’m glad my folder organizing is still enough for me… But the time will come I need more :s.

2 Likes

Hi,

As a kinda “tag obsessional” who has spent too much time trying to figure out how to correctly import/export my photo collections in various applications (digiKam, F-Spot, Shotwell, darktable, etc.) over the years , I totally agree with damonlynch: xmp compatibility is the way to go for features and interoperability.

Here’s the obvious, including apps supporting xmp (with more or less good implementation): https://en.wikipedia.org/wiki/Extensible_Metadata_Platform

Of course, with FOSS, it’s up to the developers to decide on how they want to spend their time, what features they want to include in their app., etc., but IMHO, relying on a “homegrown” solution would not be a wise choice on the long run (and in the interest of users who usually don’t appreciate any app lock down when they want to use more than one tool to deal with their collection or when they want to move it in another app).

My 2 cents!

1 Like

I definitely understand that people will have existing tag collections, and I definitely need to support that.

I can probably help you unfurl the XMP stuff, should you need help.