Tags: What identifies What

Started by Cactus26, May 03, 2023, 08:12:13 AM

Previous topic - Next topic

Cactus26

I have/had trouble figuring out what identifies what. Especially I wondered how I have to qualify a tag to ensure the meta information will be stored in  the same place where it was found before.

My current assumption: location:tag-name (e.g. IFD0:XPTitle) is the best way to ensure this.

Is it necessary to qualify additionally with the Group-0-Identifier? I suppose it is not. That is: Do all Group-1-Identifier correspond exactly to one Group-0-Identifier (and will always do)?

Is it advisable to prefix the location qualifier with the family number (i.e. "1", eg. "1IFD0").

At first I thought the tag ID would be for something like this. But I think I understood that this must have another intention. I guess it has actually only internal meaning, in connection with the internal file format.
-- Cactus

Phil Harvey

You haven't mentioned the file format you are considering.

The tag ID group is necessary for some ambiguous QuickTime tags used in video formats.

Otherwise, the family 1 location should do the job.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

StarGeek

Quote from: Cactus26 on May 03, 2023, 08:12:13 AMMy current assumption: location:tag-name (e.g. IFD0:XPTitle) is the best way to ensure this.

My recommendation is to use the Group 0 names (EXIF, IPTC, XMP), if you use a group at all.  Especially with EXIF tags.  The subgroup names are not obvious and it can be really easy to assign a tag to the wrong group, especially if your source is bad.  There are several cameras that write EXIF tags to the wrong locations and looking at the data in them could lead you to writing the wrong group.  A common example is that some Sony cameras write the ModifyDate to IFD1 when it should be in IFD0.

I almost never write a specific subgroup unless absolutely needed, often not even including a group name.  Exiftool usually knows the best place to put the data.  It's usually only necessary when dealing with software that decides they need to create their own data standard (ACDSee, Excire).

The only real exception to this is the Quicktime tags.  Because they are such a mess, depending upon the apps you use, you may have to specify ItemList, Keys, or UserData.  But as far as I can recall, it's really only Apple that gets very specific with the Quicktime groups.

QuoteIs it necessary to qualify additionally with the Group-0-Identifier? I suppose it is not. That is: Do all Group-1-Identifier correspond exactly to one Group-0-Identifier (and will always do)?

I can't recall any case where the same group 1 name is duplicated in multiple group 0 names. It would have come up fairly regularly it did.

QuoteIs it advisable to prefix the location qualifier with the family number (i.e. "1", eg. "1IFD0").

I would definitely not recommend that unless you have a very problematic file.  I have several badly written files where they have up to 7 different IPTC blocks.  In cases like this, I think it's best just to re-write the data so you only have one location.

QuoteAt first I thought the tag ID would be for something like this. But I think I understood that this must have another intention. I guess it has actually only internal meaning, in connection with the internal file format.

There are only a few cases that I think you would need to specify the id and that is with some of the Quicktime tags.  For example, in the Quicktime:ItemList tags, there are three separate Description tags.
"It didn't work" isn't helpful. What was the exact command used and the output.
Read FAQ #3 and use that cmd
Please use the Code button for exiftool output

Please include your OS/Exiftool version/filetype

Cactus26

I think, now I have understood the necessity of Tag-ID for the first time. Many thanks!  I had a look here and the Tag description occurs with IDs desc, dscp or ©des. Even though I knew there isn't really a standard for metadata I didn't know how big the mess is.
-- Cactus

StarGeek

It finally clicked that you are using the tag names as part of your metadata editor.  That would change some of what I said.  My keep it simple approach that I talk about in the first paragraph probably wouldn't be the best in this instance.

So you'll have to make sure you put data in the right place.  And then there would be dealing with data in non-standard places like the Sony problem I mentioned.  Another example would be the Orientation and Resolution tags you mentioned in IFD1 in your json post.  Those are non-standard and wouldn't be edited unless explicitly assigned.
"It didn't work" isn't helpful. What was the exact command used and the output.
Read FAQ #3 and use that cmd
Please use the Code button for exiftool output

Please include your OS/Exiftool version/filetype

Cactus26

I suspected that you had not noticed the metadata editor idea. But your answer made it clear to me that this plan does not make much sense.

My goal for my next application release is to make visible the metadata that ExifTool can parse. Primarily, I would like to understand more myself what is actually going on internally and create an evaluation opportunity for myself. Then I thought: If I already display them, I can also have them edited, that's not a big problem then. That's how the metadata editor idea came about.

Currently my application uses IPropertyStore of Windows to read and write some prominent metadata (it is analogous to the Property dialogue of Windows) and stores them in the application database. A long-term plan is to use the ExifTool to expand these possibilities. For example, IPropertyStore does not handle coordinates for videos (I've already seen the thread here). Another long-term thought is to transfer the ExifTool metadata into the database in order to be able to evaluate it with SQL means. But to make a reasonable concept here, I need to understand the whole thing better.

So my next version will only offer a primitive editor. Thanks again for your support!
-- Cactus