On Mon, Jun 10, 2013 at 8:09 AM, Willem Ferguson <
[email protected]> wrote:
> Alexander,
>
> Thank you very much for a long and thoughtful reply, and for the time it
> took you to write such a complete response.
>
> I am really new to this topic of metadata management and therefore I
> have had many misconceptions. I always thought that the XMP sidecars
> just contained the EXIF metadata as a separate file since we do not wish
> to modify the original RAW file and that, when exporting to JPG, the XMP
> metadata is written into the JPG image as EXIF. Clearly I am wrong.
>
> There are thus two separate sources of metadata: XMP and EXIF. For
> instance the EXIF can contain information such as Location which the XMP
> cannot. The XMP is restricted to the Simple Dublin Core (=DC) fields. I
> have three questions (Internet links please, I do not expect you
> yourself to spend a lot of time on this, let me do the legwork on the
> Internet):
>
> 1) Does this mean that the DC XMP-based metadata is written as something
> separate from the EXIF data block when creating a JPG copy of the master
> RAW image? Does this mean that many software packages are aware of the
> EXIF as well as the DC tagfields and can handle these?
>
> 2) If this is correct, in general, how readable are the XMP (=DC tag
> block) metadata by other software outside of dt?
>
libexiv2 reads and writes both those flavours (exif and xmp). that's also
what we use.
-jo
>
> 3) Then it should be relatively simple to use, within dt, more of the
> Simple Dublin Core tags, since this comprises 15 tags in total, allowing
> more dc fields for descriptors and tags. Use of more or all the simple
> DC tags would already make a large difference in the usability of
> metadata. Does this make sense at all?
>
> Kind regards,
> willem
>
>
> On 09/06/2013 21:31, Alexander Wagner wrote:
> >
> > On 06/08/2013 07:42 AM, Willem Ferguson wrote:
> >
> > Hi!
> >
> > [...]
> >> metadata into the JPG images. However, I have several issues.
> >>
> >> 1) The metadata on the right hand of the light table are
> >> not all shown in the image information block on the left
> >> hand of the light table. For instance the Title tag on the
> >> right is not shown on the left. Is there any way to show
> >> all the metadata fields in the image information block?
> >> My installation (V1.2.1) only shows Title, Creator and
> >> Copyright in the image information. Is there, within dt, a
> >> way to configure which tags are shown on the left?
> >
> > I think your problem here is that "left" refers to
> > Exif-metadata, and what you want to see there are actually
> > xmp-metadata. That's to my knowledge why they display on the
> > right hand side.
> >
> >> 2) When using standard Linux utilities, many metadata
> >> fields are not shown or have different names.
> >
> > Sure. dt only writes the dublin core block of xmp.
> >
> >> In Nautilus file properties, the only metadata shown are
> >> Description, Keywords, Creator and Copyright.
> >
> > Again, the dublin core block of the xmp. Note it's even
> > dublin core simple. That doesn't give you much fields and
> > the granularity is "limited" to be polite to the dublin core
> > ;)
> >
> >> Note that the 'Rights' field in dt becomes 'Copyright'.
> >
> > That's ok, IMHO as it is just dc:rights and this tag gets a
> > "proper" name for display. But it's just a name. Internally
> > its just alway the same.
> >
> >> A trivial detail, but
> >> I thought the Exif fields had standardised names??
> >
> > It's xmp what you see, not exif. It seems you mix those two.
> >
> >> In Image Viewer, the dt 'Creator' field becomes 'Author'
> >
> > Again interpretation of dc:creator from the dublin core (dc)
> > entity. Usually (though not quite correct) dc:creator is
> > interpreted as "author" as the dc field designations are
> > more or less invented for more bibliographic entities.
> > And usually if some bibliographic entity calls a creator it
> > is the author. Now, quite some tools do tihs as well and
> > don't think about why the h... the dublin core people called
> > it creator and not author ;) The used dc set (dc simple)
> > does not have "subdesignation" so you have no real roles.
> >
> > IMHO the main issue is, that dc (especially dc simple) is
> > nice, but to small for anyhting decent. Its useful to display
> > a real metadata scheme in a standardized, simplified way
> > only. But to rely on it for metadata storage is difficult.
> > Just way to few data. (Imagine entities like dc:identifier,
> > that have to hold anything like isbn, issn, doi and all
> > other identifer-like things e.g. even a local db counter.)
> >
> >> and there is a Location field that clearly is different
> >> from Longitude and Latitude in dt.
> >
> > Nope. dt does not support IPTC (unfortuantely) so you don't
> > have the IPTC-entities location, sublocation, country,
> > country code etc. And they are not part of the dublin core
> > simple so no entries in the dc: data eiter. This is really
> > difficult. The cleanest way to add them would probably be a
> > keyword chain like IPCT|locacion|country|Somewhere, but I
> > have to admit, trying this for entry in dt is a bit, hm,
> > well, PITA. :(
> >
> > gps coordinates on the other hand live in exif.
> >
> >> 3) If I wish to share images with a person (often using a different OS)
> >> there is not an easy and reliable way to predict which matadata that
> >> person will see.
> >
> > I think this is not true. Actually, the xmp block used by dt
> > is quite standardized. Main issue is that many programs
> > don't interpret xmp. They just expect it as this is a bit
> > new. They only expect IPTC which exists for a while as the
> > standard. And these blocks are just not there. So, they look
> > for something that does not exist and don't know about what
> > exists and you get nothing.
> >
> >> Is there any way to make sense of this?
> >
> > metadata are definitely one of the weakest spot of dt. This
> > is unfortunate, as the rest of dt is really great.
> >
> > As you're creating an jpg anyway you can resort to add the
> > metadata with another tool. I find mapivi very convenient
> > for this and it allows IPTC, XMP and exif, so you have
> > control of all fields relevant in the way it should be. What
> > I mainly do (might work for you as well):
> >
> > - Ingest from the camera to a direcory darkroom/
> > - Work on the raws there in darktable
> > - Ignore all metadata fields of darktable
> > - Export the results to JPG in the same darkroom/ dir.
> > Filname of jpg == filename of raw
> > - Ingest darkroom/ to my mapivi structure and add metadata
> > there
> >
> > Mapivi will collate raw, jpg and xmp and handle them as one.
> > Metadata will be written to the jpg only, however. But as
> > mapivi is in perl and has a very simple plugin interface a
> > call against exiftool libs would allow to add metadata from
> > IPTC to your xmp files from dt. They stay usable for dt as
> > dt will just ignore those unknown namespaces (mainly
> > photoshop and iptc.)
> >
> > Probably this helps a bit.
> >
>
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
> _______________________________________________
> Darktable-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/darktable-users
>
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Darktable-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/darktable-users
