-table option missing for tabular output ? (ref to -listx and -X -t)

[user2014]

Hello Phil,

with the -listx option, tablename, id and index are returned for every tag.
So this triple is a unique identifier for each tag  (similar to a multi-column primary key).

The only other options where these unique identifiers (tablename, id, index)
are used / returned are -X -t (used like a foreign key). Right ?
But the output is in XML-format and several combinations with other options
are not possible.

For reading tags in the "standard" way I'm using options like  -G -a -s -t -c -b.
Here I get the results in tabular format (half the size of the XML-output and in every way faster).
But there is no option to get the unique identifiers, something like -table is missing.
Or have I missed the option ?

When -table is specified, group-names and tag-names are no longer
neccessary in the tabular output, because these informations I got already with -listx.

Is it possible to implement a -table option
to get the unique identifiers (tablename, id, index)
in standard/tabular output ?

Thank you

Bye
Erwin

[Phil Harvey]

Hi Erwin,

I would recommend using the family 1 group and tag name as an identifier.  True, these are not unique, but whenever they aren't the duplicate tags should contain identical information.

Maybe you aren't doing this because the family 1 group is dynamic for some metadata types (ie. different IFD's in EXIF information).  In cases like this it is an arbitrary decision to call this a different tag or not.  For simplicity, ExifTool re-uses the same actual tag definition for some tags in different locations like this.

But I'm not sure what your requirements are, so my suggestions may not help much.

- Phil

[user2014]

Hi Phil,

in the -listx output are all the relevant informations for the gui presentation of tags/values.

The  datatype for input validation and which gui-element (textfield, numericfield, dropdownlist for fixed values, ...) to use
writable - if the gui textfield, ... is editable
values -  for the dropdownlist
....

I've done a quick check of all identical/duplicate g1/tagname records of the -listx output.

There are 1498 different records with identical (duplicate) g1/tagnames.
They differ in various fields - type, values, writable, fields, count

So if I want to present for example a dropdownlist with the predefined values
based on g1/tagname I may show the wrong values.

Sure - these are a lot of MakerNotes tags - but ....
If you're interested I can send you the list with the differences.

Thank you

Bye
Erwin

[Phil Harvey]

Hi Erwin,

I assume the drop-down list is for new values to write.  But what good is this if you can't address the writable tags with the same coordinates?  The most control you have over writing is the family 1 group name (unless you get into using the instance number, but this varies from file to file).

I'm guessing that almost all of the duplicates are in the maker notes.

- Phil

[user2014]

Hello Phil,

>>But what good is this if you can't address the writable tags with the same coordinates?<<

You're right !!!
There's also no way to write tags via tablename/id/index.

But now I have an understanding problem.
Why then the two worlds ? g1/tagname vs tablename/id/index ?
Why is -listx producing so much information ?
The duplicates can be omitted, also the triple info -  table/id/index (g0,g1,g2 is already included).
Same for -X  -t.
Is it (table/id/index) just some kind of internal data, therefore not part of the public interface
and not to be used inside of an exiftool-based application ?

Thank you

Bye
Erwin

[Phil Harvey]

Hi Erwin,

Is it (table/id/index) just some kind of internal data, therefore not part of the public interface
and not to be used inside of an exiftool-based application ?

The table/id/index certainly started as purely internal data.  The addition of the -listx option exposed these internals, and I got requests to add similar information to the -X output, but so far this ability hasn't propagated to the writer side.

One problem is that this information is fairly volatile, and the table name and index may change with ExifTool releases.

Another problem is that I would need to add a new API function and a corresponding application feature to be able to specify a tag like this.  And some tag ID's contain very odd characters, so it could be problematic to do this via the command line.

A third problem is that I really don't think you want to specify tags like this when writing.  You have no way to know in advance which of the tags is valid for a given image.  And usually you would want to write all of the valid duplicates with the same value anyway, to keep them consistent.

- Phil