Bringing photo documents into DT – a first mapping of IPTC & EXIF fields onto DT (its inbuilt metadata fields + UI)

[lerone]

Dear community,

find here a first, tentative list of Exif/IPTC metadata accessible directly in DT, i.e., in the app interface (as opposed to, say, via scripts). This is helpful in terms of bringing core info (some would even say ‘content’) of photos (and images) into DT and funnel this into DT’s index (for search or for use in smart rules, e.g.). It seems helpful in cases where one works more systematically with photos and DEVONthink (which has a lot on offer for use with photo documents).

I hope this is helpful, and in the best of all cases, this would probably be extended, corrected, and annotated by the team and the community. And also linked up with some practical workflows possible because of the existing affordances, or the collective identification of weak spots (as there are some).

This approach, I guess, also conforms with DevonTech’s policy to not suggesting and reliance on particular dependencies.

Intro / Rationale

Anyone working with images and photos can benefit from DEVONthink’s intelligent architecture for managing, organizing, and working with photos as a special form of ‘document.’

DT has many nice affordances that motivate and support such a use (like reading a photo’s GPS coordinates, displaying and working with some photo-specific metadata alongside general ‘file metadata,’ allowing swift conversion/short-circuiting of keywords and Mac system tags). But, DT also offers a lot of functionalities that can often match what a dedicated MAM can do, and in some respects even surpassing them (like the way DT allows to ‘interlace’ photo documents with other document forms, showing them alongside each other in the semantic search, powerful tagging system, allowing aliasing, managing photos between desktop and mobile, letting smart rules work on them, etc. – and lots more. Then, there are some ‘awkward’ aspects for anyone coming from a (semi-)professional photo-something background. Like DEVONthink’s ‘refusal’ to display sub-folder content alongside higher levels (something MAM users are accustomed to), the exclusion of metadata from ‘related content’ (see also), and simply missing some of the luxuries of a dedicated MAM/photo manager (like stacking, basic editing, etc.).

– Here are some semi-systematic thoughts around it. Anyone interested in the pure – short – mapping can forward to the bottom.

The ‘Practical Case’

I started mapping some of the IPTC and XMP metadata fields, available in photo management software, to the DT fields. It generally seems helpful in cases where one works more systematically with photos and DEVONthink (which has a lot on offer for use with photo documents.) (And, let’s be clear: ‘digital photos’ are – or should be regarded as a – prime member of the ‘digital document universe.’).

The good news is that some selected photo metadata are directly mirrored in DT, with a focus on IPTC and EXIF metadata, which will be familiar to anyone working more systematically with photos.

My short and initial ‘data-mapping’ came about because I couldn’t find any detailed and 100% clear mapping of DT-metadata to their counterparts in the photo world.

Part of the reason is that it is not fully documented anywhere (try a search for IPTC or EXIF in the help documents). But also, often these metadata go by slightly different labelings than the nomenclature of the IPTC/EXIF world. Also, metadata are spread out in different parts of the DT UI – though, luckily, the grind of IPTC and EXIF metadata seems to be concentrated in the ‘properties pane’ of the ‘info’ panel.

Partly, it has also to be said, this (relative) opacity is surely due to some ambivalences and complexities stemming from a somewhat splintered IPTC + EXIF metadata ‘system’ (like many aspects – like subject codes, ‘document titles’ vs. ‘headlines,’ geographical places being represented multiple times, etc.)

So what this is, an attempt at a first kernel for a very detailed list of Exif/IPTC metadata accessible directly in DT, i.e., in the app interface (as opposed to, say, via scripts), aiming for a definite, non-ambiguous localization within it.

This is helpful in terms of bringing core info (some would even say ‘content’) of photos (and images) into DT and funnel this into DT’s index (for search or for use in smart rules, e.g.).

This approach also conforms with DevonTech’s policy to not suggesting and reliance on particular dependencies.

The Broader Case: DT and the Rise of ‘Photo Documents’

DT’s ‘home turf’ is intelligently managing, organizing, and working with ‘documents.’

A particular document, actually one of growing importance for digital work since the early 2000s, is the digital photo document. It was already in the 1990s that the photo file became a ‘digital photo document’ by way of the introduction of IPTC (first version as ‘IPTC-IIM – Information Interchange Model’), a standardization of descriptive metadata, first for the facilitation of exchange within the news sphere. Then, reflecting the changing / growing relevance of standardized metadata for photos and images in the growing spheres of digital culture came an updated / modernized version in 2004 (‘IPTC Core’). Adobe was one of the key drivers of all this in terms of adoption in software (interface with ‘consumers’) and implemented IPTC-IIM in Photoshop as far back as 1994.

The Conceptual Case for Mapping This

The real ‘interface’ between photos as (content-)documents and DT are the photo-specific metadata. One could say, especially semantic metadata like ‘title,’ ‘description,’ etc., because they (often) verbalize what the photo is depicting – ‘especially’ also because DT solely relies on text as information and has no access to things like image semiotics or semantics.

So, if one really wants to bring photo documents into play with the DT game, one has to rely in big parts on IPTC, XMP, and EXIF metadata. Or better said: one better does, if he or she wants to work systematically with ‘photo content’ in the DT environment.

Very practically speaking, if one wants a direct, clear, and fast/efficient hand-off of the ‘metadata-ing’ one does in one’s photo workflows to DEVONthink, one best relies on the direct channels, those in which the metadata (IPTC/EXIF) directly make it into DT, without any intervention through additional dependencies. So, an ideal form of working surely is: I edit information attached to a photo (IPTC/EXIF metadata) and when I open DT … it ‘simply’ shows up, and is without further ado part of its intelligent mechanisms (like smart rules, powerful search, etc.).

The mapping (so far)

The mapping is based on Adobe Bridge. Given Adobes leading role in formulating/implementing IPTC in particular, it´s probably safe to assume their labels are kind of authoritative… or something.

• DT Info > Properties ↔ IPTC/EXIF (Adobe Bridge)

---

• Author / Autor ↔ Creator (IPTC Core)

• Title / Schlagzeile ↔ Headline / Überschrift (IPTC Core)

• Comment / Kommentar ↔ User comment / Benutzer-Kommentar (EXIF!)

• Description / Beschreibung ↔ Description / Beschreibung (IPTC Core)

• Keywords / Schlagwörter ↔ Keywords / Stichwörter ( )

• Copyright ↔ Copyright (IPTC IIM-old)

• Editor / Bearbeiter ↔ Description Writer / Verfasser der Beschreibung (IPTC IIM-old)

• …?!

Postroll

There are also other attributes that show up in other areas, like geolocation in the generic info sub-pane. But here I can’t find a systematic relation to the (different) location metadata fields of IPTC or EXIF, … though they may exist. For sure, I couldn’t edit the geolocation in DT for images.

As said initially: this is something to build upon, extend, revise, contextualize … etc.

PS - 1: I think, if this works kind of the way I expect it, I will surely go back and post-edit the list in light of additional insights).

PS - 2: there surely are some threads in the forums touching on image metadata and getting them ‘into’ DT. Reasons for this particular thread: 1) there is no one focusing on the combo of EXIF + IPTC; 2) there is no real systematic and detailed mapping; 3) most often these threads deal with scripts and dependencies, and ‘indirect’ ways to work with photo-specific metadata – I was/am interested in getting the most detailed map/overview possible, representing the direct and existing ‘pipelines’ (for different reasons; see above).

[Stephen_C]

I’ll comment briefly as I do a lot of photography and work all the time with EXIF and IPTC data. I also use DEVONthink, of course. As regular readers know, I have many thousands of daily diary entries and to some of those I add photos.

However, the reason for all of that precursor is to say, simply, that I very much tend to use "horses for courses”—so use Photo Mechanic Plus to complete metadata and to catalogue photos (and Capture One to process them). When I include photos in DEVONthink I’m (personally) not concerned to include the metadata because that is, of course, stored elsewhere.

No doubt there are those who would be interested in trying to adapt DEVONthink for photo metadata and I by no means belittle you for your detailed work—which is impressive. Maybe I’m taking a blinkered approach by using two apps where one would do—but I find it easier!

Thanks, anyway, for your detailed work and thoughts.

Stephen

[lerone]

thx @Stephen_C ,

good to also collect these captures how people generally go about it! this helps for setting the scene & understanding different general use contexts.

I am in particularly hoping there can be two things such a thread brings

1. getting more details about those ‘directly mapped’ IPTC/EXIF metadata fields here

2. get some specific workflows and ways ppl leverage these opportunities (– even though DT is no dedicated MAM)

I btw also of course do the bulk & heavylifting re metadata in other dedicated apps, like PM+ and Bridge.
I then looked for ways I could use DT as a kind of second eye and context, and thus needed to understand how & which detailed input in PM+/Bridge gets channeld to DT, and whereto…

so this really is about how to bring DT into a useful / effective ‘stereo’ w/ other dedicated apps, like the ones you mention also. this is, of course, to be able to leverage the additional benefits DT brings (in terms of powers but also extended document contexts) as a ‘plus’ in any ‘multimodal document work’, and also treat photos as documents, where it makes sense – and given the nature of DTs ‘natural scope’.
– in that sense, it is all about ‘horses for courses’, just in a combinatorial sense – and ‘raising the bar’.

so, its about adapting workflows and see where / to what extent DT already allows for / has inbuilt photometadata capacities, ‘as is’.
(– though, things can of course, alwas be improved further)

let’s see whether this whole axis can be enriched further…

[Stephen_C]

I hope I’m not de-railing the thread but I’m sure you’ll have looked at the wonderful ExifTool by Phil Harvey which is brilliant for manipulating EXIF and IPTC data. I’ve written a couple of small Alfred workflows using that and it’s possible the app may be useful in the context you are considering.

Stephen

[lerone]

no, it’s all helpful context.
(– though my motivational topic is not metadata manipulation per se, but how to leverage DT as document manager w/ photo documents in a cohesive / augmenting workflow)

and we know, there is a fine balance btw not relying on (too many) dependencies and the inbuilt need for tandem-apps w/ DT (as you initially pointed out).

yes, this, and for my cases sometimes EXIF Editor, and MetaImage (– for the GUI people). plus, not to be overlooked in metadata contexts: GraphicConverter; kind of like the ‘DT of photos’

[chrillek]

@lerone

Given Adobes leading role in formulating/implementing IPTC in particular, it´s probably safe to assume their labels are kind of authoritative

I have my doubts. Adobe is notoriously sloppy with seldom used IPTC data like “artist”, at least in PhotoShop.

Anyway, image metadata is a complicated thing. EXIF has some fields that seem to overlap with IPTC fields (eg XPAutor and ImageDescription). On a closer look, they have limitations (XPAuthor is Windows-specific, ImageDescription is limited to 8-bit characters).

DT, OTOH, has only a very limited set of built-in metadata like Author. With geo-data, it sets a literal location (“New York, USA”), and the coordinates are available in the scripting interface and via the “Coordinates” Smart Item Script.

Most EXIF data, though, are not mapped to anything in DT automagically. Notably all those that describe the physical aspects of the image like focus length, aperture, ISO value etc.

@lerone

get some specific workflows and ways ppl leverage these opportunities (– even though DT is no dedicated MAM)

My impression is that people hardly use IPTC/EXIF metadata with DT. There were some requests in the forum. I suppose that those who really need full support of IPTC/EXIF rely on other tools like exiftool, Bridge, GraphicsConverter etc.

[lerone]

thx, @chrillek.

I was aware all this is only for people interested in testing extended use of DT in context w/ photos.

again, my topic/motivation (or the one of this thread) is not ‘extended use’ of IPTC/EXIF per se (for itself).
the topic here is: given the (possible) presumption that DT is for managing different kinds of documents (like text based, pdf, now also audio, some video), and the additional presumption that photos are / can be part of a ‘document stack’ (which is exactly why there are metadata standards for photos), then a) how can I make use of it; b) what is there to know about how DT already treats photo metadata (I guess for a reason ); and c) how can this be mapped or documented even better; to then possibly d) discuss and exchange possible workflows in which I have metadata-rich photos, and want to use them in DT context.

another presumption: complex things call for mapping and clarification. otherwise they simlpy remain (overly) complex, in the sense of hard to handle (and with DT and IPTC/EXIF we exactly have the meeting of two very different but equally complex ‘systems’).

so, in a way this thread is for people interested in testing how this can be used to the fullest given ‘complex’ preconditions, and actually eludicate these preconditions – … while everyone is open to insert some scepticism.

---

@chrillek

My impression is that people hardly use IPTC/EXIF metadata with DT. There were some requests in the forum. I suppose that those who really need full support of IPTC/EXIF rely on other tools like exiftool, Bridge, GraphicsConverter etc.

this might change a) once the mapping of IPTC/EXIF becomes clear (explicit); and b) people learn use cases. – again, the very raison-d-etre for this thread
that is the nice thing about ‘Aufklärung’. it can shift / extend baselines of practice.

(– … though, I am also always a fan of making solid monitorings & reviews about actual and possible usage of any given affordance of an app, esp. if its such a complex one as DT. just, that is not the real topic/interest of this thread. but I´d look forward to see such a thing, also… )

[lerone]

@chrillek

I have my doubts. Adobe is notoriously sloppy with seldom used IPTC data like “artist”, at least in PhotoShop.

yeah, as I said in the initial post IPTC itself is a ‘fractured system’ – just as is DT.
we have to live with that and adapt as best as we can.

[see original post:]

@lerone

Partly, it has also to be said, this (relative) opacity is surely due to some ambivalences and complexities stemming from a somewhat splintered IPTC + EXIF metadata ‘system’ (like many aspects – like subject codes, ‘document titles’ vs. ‘headlines,’ geographical places being represented multiple times, etc.)

… in this context I am happy for anyone given other ‘authoritative’ or even ‘semi-authoritative’ reference points. actually, collectively collecting such data points and building shared understanding is the very reason of this thread…
even better would be, of course, any contributions to the mapping of the ways IPTC/EXIF metadata effectively show up in DT, especially by people who have additional knowledge. that would help the constructive cause.

@chrillek

Most EXIF data, though, are not mapped to anything in DT automagically.

… as also said previously: the opacities involved are the very reason for the (need of a) mapping.

[uimike]

Lerone, somewhat related - I use a lot a very nice app called “A Better Finder Attributes 7” - check the metadata insights it gives on a selected photo. I used it for a lot of batching needs, mainly correcting creation date in photos imported to Lightroom via iPhone.

[lerone]

thx @uimike – yeah! Alas! this is also an old classic of mine.
(and I think version #7 is years if not decades old – and still not easy to substitute).

that said, I feel, what all this shows:
there is both a lot of additional knowledge and obviously practical interest floating around in the community around how to manage the complex cliffy landscape of (these kind of) ‘metadata’ in general – and as related to tangential use around ones core DT interests/practices.

honestly, I think this deserves another dedicated thread (also: @Stephen_C, who could surely contribute here ), as this one really wanted to stay in the realm of a ‘direct mapping’ (EXIF/IPTC metadata fields ↔ (related) DT fields).

but, of course all this works only in / needs context. this was also the reason for the longish preroll/contextualization of the (rather) short list (mapping).
it´s intrinsically challenging, and hard to ‘contain’ any topical discussion, precisely because photo files are just an exemplary case, illustrating how complex and extensive things become, once one asks / confronts the question(s) ‘what are digital documents’, how are they related to / defined by (different systems of) metadata… and, how on earth can I handle that a) in my praxis, and b) in light of using DT as a (or: as the ultimate) ‘document manager’?

so, again, all related!
… but I think factoring different dimensions of this vast set of issues into different and dedicated threads might make sense, here.

[uimike]

@lerone

Alas! this is also an old classic of mine.

Yeah, I saw you also mentioned Graphic Converter

[uimike]

For me, a heavy user of Lightroom, I still need to figure a way to import “Comments” into DT - yep, it is not EXIF/IPTC. The other thing I do care a lot is location - but I have not been using the facilities for this, rather adding LR keywords to the images. And talking about keywords, I love how I can convert keywords to tags in Devonthink. So I often export large numbers of very light pngs to DT, with the tags being most of what I need. But I am baffled by the metadata mess, how messy it is across the landscape…

[lerone]

I hear you exactly!

location data and its (potential) interchange is something that also still buffles me.
hunch being it would work mostly via GPS coordinates in a DT context, but not really via location explicit IPTC/EXIF fields. but really this is a (relevant) question to me, still…

as to ‘comments’, I hear you as well.
this was part of the whole reason for my (initially personal) mapping. and, would say, it´s a reason why its good to talk about this in the community, and make things explicit and more clear.

… I have come to the insight/conclusion that for something like ‘comments’ the EXIF(!) field of ‘user comments’ directly transports into DT´s ‘comments’ (properties pane).

@lerone

• Comment / Kommentar ↔ User comment / Benutzer-Kommentar (EXIF!)

this was a surprise. but a very useful info at the same time.

… particularly bec I am in a phase where I newly set up and define my workflows re. this. so, the insight + takeaway for me is to use this EXIF field in Bridge to bind comments between my photo workflow and my documents workflow in DT.

of course, this is not easily doable if the case is for someone to retrofit all of his/her large-scale photo sets – and workflows – ‘just’ for the sake of using it more efficiently with DT; … or in the case where this clashes w/ other relevant/outside protocols (handovers in other ‘swim lanes’ etc.)
(… but as we also talked a lot about ‘good ol’ and helpful tools: with something like PhotoStation from Extensis this retrofitting – swapping entries from one field to another – might be perfectly doable; plus, as always, ‘there might be a script(ing case) for that’…)

so, yeah – these kind questions/challenges, when combining standard photo workflows with the realities of DTs document-metadata handling is just what this is all about…