missing features: film roll and sidecars?

[damonlynch]

@CarVac

I’m for whatever’s logical, ISO standard or not.

My thoughts on photo industry metadata standards and our community:

Free software and photo metadata — a chance to engage with the broader photography industry

I have just had a long conversation with an IPTC member about photographic metadata and the free software community. The starting point for the conversation was what could be done to get industry standards better embedded into free photography software. The great news: there is the possibility for our community to engage with the photographic metadata standards community so that (1) we can learn from their considerable expertise and experience and (2) they might learn how to better communicate …

[jorismak]

Maybe - to be sure - we need to clarify what I mean by tags. I mean the literal tags you can assign to aid in searching. I do not mean all the fields that can be written in a xmp block, like title, lens, date, etc…

Doing a search the term ‘tag’ is confusing since it’s also used for the field names (the keys if I see a xmp file as a simple key/value store concept).

So it seems the field ‘subject’ is what is used to store the taglist. And like I suspected, this was once envisioned as a list of subject names, and someone decided to hack a tree hiearchy in it be using a separator.

According to metadata - Is there a well-known way to store a taxonomy hierarchy in XMP, IPTC or EXIF? - Photography Stack Exchange (stack exchange and stack overflow are the world most contributing members of false info so take care checking :)) digiKam has a different way of doing it.

So, two things :

1. the pipe separator seems to be the most used. Why that way… I don’t know. Be compatible with programs that don’t want to implement a tree view?

2. It highlights the problem with xmp: you can write tons of stuff in it, and make up field names as you go. A lot of programs make custom field names prefixed with something (like lightroom’s ‘lr:’) which makes the list of field names to check and parse larger and larger and larger… And meanwhile users expect every program to read everything ‘because it is a standard’. It hardly is,it’s just xml.

So, if you write sidecars (with the intention of keeping users happy who want to migrate data in and out) xml is the most widely used. But even using a library like exiv2 or a tool like exiftool requires you to think about which fields to write and read.

---

About embedding xmp.This is safe IF the raw file is a container format which supports writing xmp. Since almost all raw files are based on tiff or other general containers this is no problem. If it’s a weird format without real xmp support, do not go crazy :).

But… In my mind source files from a camera are never ever to be modified.

And embedding xmp is not useful for the use case of most people wanting sidecar files, so I don’t see the use for now. But that’s just my opinion of course.

[paperdigits (Mica)]

@jorismak

Doing a search the term ‘tag’ is confusing since it’s also used for the field names (the keys if I see a xmp file as a simple key/value store concept).

We can start using the proper terminology: elements and attributes.

@jorismak

It highlights the problem with xmp: you can write tons of stuff in it, and make up field names as you go. A lot of programs make custom field names prefixed with something (like lightroom’s ‘lr:’) which makes the list of field names to check and parse larger and larger and larger… And meanwhile users expect every program to read everything ‘because it is a standard’. It hardly is,it’s just xml.

This is actually one of the strengths of xmp/xml. You can store your stuff in a custom namespace, but still access and store it alongside the standard xmp elements. The stuff you explicitly want to share goes into the commonly supported xmp namespace and the stuff that doesn’t need to be shared goes into the custom namespace.