Most Suitable Format for "Metadata Editor" (GUI)

[Cactus26]

I now succeeded showing the tags provided in a file using the tab-delimited format (see my previous post). That alone is already fine. Now I ponder where to go. If I have not overlooked anything, the XML format does not provide category group family, which I consider useful. I'm also thinking about to use ExifTool as "Low-Level-Metadata-Editor" in my application. Another question concerning this: Is there a format with the information if a tag is writable in the current file (without the need to use the listw and listwf in advance)?
--Cactus

[Phil Harvey]

Hi Cactus,

If I have not overlooked anything, the XML format does not provide category group family, which I consider useful.

Correct.  The family 0 and 1 groups are included by default, but there is no provision yet to return other groups in XML.  However, this is something that could be added.

Is there a format with the information if a tag is writable in the current file

There is no way to determine this without trying to write the file.  (ExifTool can't know this beforehand.)

- Phil

[Cactus26]

Thanks again 

Currently I think the most suitable formats for me are tab-delimited or XML. JSON is not ideal for me cause I currently have no parser and I prefer Windows-1252 in my old fashioned world.

I see this advantages for me using XML:
- I get both description and tag name
- there is a differentiation between et:prt and et:val which seems useful
- there is a safe way to get list-type-tags values (even if it is a little bit "tiring" to analyze the bags)

How would you plan to add the possibility to get other group families for XML? With the -G analogous Json?

What I miss a little is a classification of data types for values (like Integer, Float, DateTime, String, perhaps also complex formats like Coordinates (Lat/Lon/[Alt])). I'm not sure if the RDF-Concepts are ideal (https://www.w3.org/TR/2004/REC-owl-semantics-20040210/syntax.html#owl_built_in_datatypes), using XML everything seems to be so heavyweight)

What could be an alternative for me would be a drilled out tab-delimited-format. But I have the impression that you do not want to go in this direction. Also, I must admit that some concepts are still very nebulous for me and that it is not appropriate to wish for extensions before understanding everything.
-- Cactus

Addendum:
In the meantime I discouvered some possibilities of -listx. If I would cache this information many of my desires would be solvable. The only missing thing the tab-delimited format would not offer would be the distinction between prt and val. Btw.: The structure of the XML of the -listx is pretty simple (compared to RDF)).
--Cactus

[Phil Harvey]

Yes, -listx is meant to be used in conjunction with -X, and that does give you the family 2 group categories as you wanted.  I should have suggested this.

- Phil

[Cactus26]

Anyway. What would be the most efficient method for me, according to my current knowledge, is to use the tab-delimited format. What I would need there would be an additional 4th column which includes a distinction between presentation and internal format as it exists for json, php and xml (rdf:prt/rdf:val).

For example:

Code Select Expand

MakerNotes:Panasonic\tRotation\tHorizontal (normal)\t1
Spontaneous suggestion: An option -tab2 (or -t2) offers this 4th column.
-- Cactus

[Phil Harvey]

You can only get this by specifying the tags on the command line, ie)

exiftool -T -G0:1 -rotation -rotation# FILE

- Phil

[Cactus26]

That is a pity. I can hardly do this for all tags to be displayed individually, my goal was/is to have the best possible performance.
--Cactus

[Phil Harvey]

Honestly, I think JSON will give you that.  And it is a very simple format to parse.

- Phil

[Cactus26]

Now I have implemented an additional variant based on json. I've used Zserges jsmn-Parser. I tried to do a fair performance comparison between json and tab-delimited (that is I did not use the additional possibilities yet the json format offers).

For all tags of about 1000 files:
json: 40.8 s,
tab delimited: 28,6 s

That is better than I expected, and should be enough (thanks to jsmn, which I consider to be very fast).

What I noticed: For tab-delimited format some tags are missing compared with json and I have no idea why. This happens for most files, not for all. The options I use are:

Code Select Expand

-t -L -s -G:0:1:2:7 FILE
-j -l -G:0:1:2:7 FILE

For example in a Jpeg-file (having 195 tags) following tags are missing for tab-delimited:
ExifIFD:WhiteBalance, ExifIFD:Padding, GPS:GPSLatitude, GPS:GPSLongitude, IFD1:Orientation, IFD1:XResolution, IFD1:YResolution, IFD1:ResolutionUnit, IFD1:YCbCrPositioning, MPImage1:MPImageFlags, MPImage1:MPImageFormat, MPImage1:MPImageType, MPImage1:MPImageLength, MPImage1:MPImageStart, MPImage1:DependentImage1EntryNumber, MPImage1:DependentImage2EntryNumber

In case this is a bug I can give you more details if you want.
-- Cactus

[Phil Harvey]

Hi Cactus,

Send me the jpeg file in question and I'll take a look.  My email is philharvey66 at gmail.com

- Phil

[StarGeek]

The options I use are:

Code Select Expand

-t -L -s -G:0:1:2:7 FILE
-j -l -G:0:1:2:7 FILE

You will not see duplicated names unless you use -a (-duplicates) option.

Orientation and the three EXIF resolution tags are the ones that jumped out to me.  Your output most likely shows the IFD0 locations and you would not see the IFD1 locations without the -a option.

[Phil Harvey]

Ah.  StarGeek has hit on the difference.  From the -j option documentation:

    The -a option is implied when -json is used

- Phil

[Cactus26]

Thank you very much! I should have figured it out myself. I had seen the -a at some point and wanted to explore what it means to me later. Sorry.
-- Cactus