Mandatory tags and EXIF 3.0

Started by ywzc, March 03, 2025, 08:41:31 AM

Previous topic - Next topic

ywzc

Hi Phil,

Can you make it so that if the ExifVersion tag is set to 0300 the -validate option will show warnings only for the missing mandatory tags per the Exif 3.0 spec?
And also when writing Exif metadata and specifying -ExifVersion=0300 mandatory tags will be added according to Exif 3.0?
The X/YResolution, ResolutionUnit and FlashpixVersion are no longer mandatory.

Phil Harvey

This isn't as easy as it sounds.

The X/YResolution tags come in IFD0, which comes before the EXIF IFD in the file.  Unfortunately the EXIF version number is stored in the EXIF IFD, so by the time ExifTool knows the EXIF version it has already written the mandatory IFD0 tags.

But the validation is done after all of the metadata is extracted, so it is potentially feasible to check the ExifVersion at this time.  However, it would be tricky to handle the case where there are multiple EXIF records in a file (and potentially multiple ExifVersion tags).

The whole issue is a pain in the ass, and the whole idea of mandatory tags was seriously flawed from the start.  It would have better if the people who wrote the EXIF spec had a brain to share amongst themselves.

I'll think about this more when I get a chance, but I can guarantee that the ExifTool source code will be much uglier if I implement the necessary patches to deal with this.  It would be easier and maybe better in the long run for me to just punt on the whole mandatory tag issue and remove the existing already-ugly patches to deal with these.

- 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 ($).

Phil Harvey

#2
Actually, maybe the best solution is just to treat these 4 tags optional for all EXIF versions.

- Phil

Edit:  I'll implement this in ExifTool 13.23 and we'll see how it goes.
...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 ($).

LaurentG

I fully agree with you : "mandatory tag" is a concept that shouldn't exist !

The ONLY exception IMHO is for the ExifVersion tag, that HAS TO be mandatory, in case that definition of some tags evolve from one version to the other.

Example : Exif:GPSAltitudeRef has 2 acceptable values until rev 3, and 4 values beginning with rev 3
As a result, values 0 and 1 are OK in v2.3.2 and in v3.0, BUT DO NOT HAVE THE SAME MEANING in these two versions (above or below sea level in 2.3.2, above or below ellipsoid in 3.0), and values 2 and 3 are OK in rev 3, but "unknown" in rev 2.3.2

Moreover, 0 in rev 2.3.2 is the same than 2 in rev 3

I guess that it makes not a lot of REAL difference, but (at list theoretically), it is not possible to decode the value if the ExifVersion is not known.
Maybe there are other tags for which the change is even more "impacting"

For this reason, it's necessary to define ExifVersion as mandatory... 
But only this one...
For all other tags currently defined as mandatory, it would better to define a "default value" to take into account when they are missing (and that could even be different among Exif versions....)

Phil Harvey

Quote from: LaurentG on March 03, 2025, 12:02:30 PMExample : Exif:GPSAltitudeRef has 2 acceptable values until rev 3, and 4 values beginning with rev 3
As a result, values 0 and 1 are OK in v2.3.2 and in v3.0, BUT DO NOT HAVE THE SAME MEANING in these two versions (above or below sea level in 2.3.2, above or below ellipsoid in 3.0), and values 2 and 3 are OK in rev 3, but "unknown" in rev 2.3.2

I suspect that you are wrong about the values 0 and 1 changing meaning in version 3.0.  If true, the EXIF designers are not just brain dead, but actively sabotaging the specification.  I think it is more likely that the writers of the pre-3.0 specification never thought carefully about the definition of "sea level", and that they implicitly assumed this would be with respect to the GPSMapDatum.

QuoteFor this reason, it's necessary to define ExifVersion as mandatory...

I still disagree, but I will continue to keep the mandatory tags as mandatory in ExifTool, with just the 4 tags that changed in EXIF 3.0 being set to optional in ExifTool for all EXIF versions.

- 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 ($).

LaurentG

#5
Quote from: Phil Harvey on March 03, 2025, 01:07:50 PMI suspect that you are wrong about the values 0 and 1 changing meaning in version 3.0.

See attached extracts from
- CIPA DC- 008-Translation- 2012, Exif Version 2.3 and
2025-03-03 21_08_11-D__Users_Laurent_Documents_Documentations techniques_EXIF ver 2.3.pdf - [ディジタルスチ.png


- CIPA DC- 008-Translation-2024 Exif Version 3.0
2025-03-03 21_10_42-D__Users_Laurent_Documents_Documentations techniques_EXIF ver 3.0.pdf - [ディジタルスチ.png

StarGeek

I downloaded the most recent PDF (2024-12-12) from Cipa and under Revision History it does say "Corrected incorrect definition of GPSAltitudeRef"

What a PITA :(
"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

Phil Harvey

#7
Yes, Laurent.  I know what the specification says.  But what it says and what it means are two different things (an all-too-common occurrence with this specification).

As StarGeek points out, CIPA realized after 30 years that the original definition for GPSAltitudeRef was not specific enough.  The meaning of the original values haven't changed, but their definition is now clear.  And this is the note they added in Dec 2024:

Quote from: EXIF 3.0 Specification Dec 2024Note In Version 2.32 or before, only sea level was defined as a reference for altitude with values 0 and 1. This was found to be erroneous as GPS and other GNSS without adjustment by the local geoid height are based on the ellipsoid surface of each geodetic system. Therefore, the definition of values 0 and 1 was corrected to ellipsoidal height based on the ellipsoidal surface. Since various positioning systems are supported in this standard, the sea level is also still supported as the reference by adding definitions of values 2 and 3.

- 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 ($).

LaurentG

Hi Phil,

I agree with you, and moreover, to say that a given altitude is above Geoïd or above Sea level is not very different (and below precision given by a standard GPS receptor).
Moreover, we're talking of AltitudeRef because I detected that its definition evolves from 2.xx to 3.0, but maybe (no, surely !) there are also other evolutions I have not detected
The problem is not there.

I just say that to know ExifVersion is key to manage the tag GPSAltitudeRef (and maybe, likely, some other tags).
In particular, if ExifVersion is 2.xx, the values 2 and 3 should be rejected in input, and displayed as invalid in output, while they should be accepted in 3.0 and above.
Moreover, if ExifVersion is not present, it is not possible to give it a "default value".

It's the reason why, despite the fact that I am, generally speaking, against the very idea of mandatory tag (like you, if I have correctly understood your point), it seems to me that an exception has to be done for this ONLY tag, that should be mandatory.

Despite of my asumptiom, I nevertheless use the NoMandatory option when I add to a "free of tag" image the only DateTimeOriginal... (but no one should be forced into consistency...  ;) )

wywh

This thread prompted me to check my images from the last five years, and surprisingly a dozen images had GPSAltitudeRef 1 (Below Sea Level) although it is a long time since I did underwater photography. There were no GPSAltitudeRef 2 or 3 or ExifVersion 3 images.

exiftool -n -fileOrder5 FileName -if '$GPS:GPSAltitudeRef == 1' -p '$FileName' .
I moved such images to another folder to inspect them more closely:

exiftool -n -if '$GPS:GPSAltitudeRef == 1' '-Directory=./0_GPSAltitudeRef' .
Many such images were DJI P3P drone .dng images edited to .jpg with Lightroom. But there were a few iPhone images -- some of which were shot at about sea level so that might have been only slightly incorrect GPS data but one was shot 50 m Above Sea Level so maybe the iPhone just did not have good enough GPS signal then.

I might fix them with either in a separate folder with:

exiftool -m -P -overwrite_original_in_place -GPS:GPSAltitudeRef=0 .
Or in place:

exiftool -m -P -n -overwrite_original_in_place -if '$GPS:GPSAltitudeRef == 1' -GPS:GPSAltitudeRef=0 .
- Matti

Phil Harvey

Hi Laurent,

I understand your position, and will be leaving all of the existing mandatory tags in ExifTool as they were, except for the 4 tags which changed to optional in EXIF 3.0.

Matti:  I have had occasion in the past (before 3.0 was released) to recommend using GPSAltitude with GPSAltitudeRef=1 for actual underwater depth readings from a pressure transducer.  I was aware that this wasn't the actual purpose of this tag (although according to the word of the pre-3.0 EXIF specification, this would be valid), but it was a reasonable repurposing of this tag for other uses.  Now with EXIF 3.0 this use case may indeed be sanctioned, and would have GPSAltitudeRef=3, except it is impossible to say for sure because EXIF 3.0 (of course, and perfectly keeping in character) fails to define the term "sea level reference".

- 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 ($).

wywh

Is -n really needed when writing GPSAltitudeRef as 0 or 1? This seems to indicate so:

"Remember that the descriptive values are used when writing (eg. 'Above Sea Level', not '0') unless the print conversion is disabled (with '-n' on the command line or the PrintConv option in the API, or by suffixing the tag name with a # character)."

...but it seems to work without -n anyway:

exiftool -GPSAltitudeRef=0 image.jpg   
    1 image files updated

exiftool -a -G1 -s -GPSAltitudeRef image.jpg
[GPS]           GPSAltitudeRef                  : Above Sea Level

I did notice that -if...1 did need -n to work, though.

- Matti

StarGeek

It is needed. From the GPS tags page
QuoteExifTool will also accept number when writing this tag, with negative numbers indicating below sea level

This allows use of wildcards
-GPSAltitude*=-100

C:\>exiftool -P -overwrite_original  -GPSAltitudeRef=100 y:\!temp\Test4.jpg
    1 image files updated

C:\>exiftool -G1 -a -s -GPSAltitudeRef -n y:\!temp\Test4.jpg
[GPS]           GPSAltitudeRef                  : 0

C:\>exiftool -P -overwrite_original  -GPSAltitudeRef=-99 y:\!temp\Test4.jpg
    1 image files updated

C:\>exiftool -G1 -a -s -GPSAltitudeRef -n y:\!temp\Test4.jpg
[GPS]           GPSAltitudeRef                  : 1
"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

wywh

Quote from: StarGeek on March 04, 2025, 01:57:16 PMThis allows use of wildcards
-GPSAltitude*=-100

Thanks, that is quite handy.

I played with different options and my initial confusion seems to clarify a bit.

With -n negative numbers fail up to -1 but non-negative floating point numbers from 0- work. 0-1.4 are rounded to 0 or 1, and ≥1.5 are rounded as 'GPSAltitudeRef:Unknown (2)' etc.

Without -n negative numbers are forced to 1 and non-negative floating point numbers are forced to 0.

exiftool -n -GPSAltitudeRef=-99 image.jpg
Warning: Value below int8u minimum for GPS:GPSAltitudeRef
    0 image files updated
    1 image files unchanged

exiftool -n '-GPSAltitude*=-99' image.jpg
    1 image files updated
exiftool -a -G1 -s -GPS:All image.jpg   
[GPS]           GPSVersionID                    : 2.3.0.0
[GPS]           GPSAltitudeRef                  : Unknown (50)
[GPS]           GPSAltitude                     : 99 m

exiftool '-GPSAltitude*=-88' image.jpg
    1 image files updated
exiftool -a -G1 -s -GPS:All image.jpg
[GPS]           GPSVersionID                    : 2.3.0.0
[GPS]           GPSAltitudeRef                  : Below Sea Level
[GPS]           GPSAltitude                     : 88 m

exiftool '-GPSAltitude*=77' image.jpg
    1 image files updated
exiftool -a -G1 -s -GPS:All image.jpg
[GPS]           GPSVersionID                    : 2.3.0.0
[GPS]           GPSAltitudeRef                  : Above Sea Level
[GPS]           GPSAltitude                     : 77 m

exiftool -n '-GPSAltitude*=66' image.jpg
    1 image files updated
exiftool -a -G1 -s -GPS:All image.jpg  
[GPS]           GPSVersionID                    : 2.3.0.0
[GPS]           GPSAltitudeRef                  : Unknown (66)
[GPS]           GPSAltitude                     : 66 m

exiftool -n -GPSAltitudeRef=1.5 image.jpg
    1 image files updated
exiftool -a -G1 -s -GPS:All image.jpg   
[GPS]           GPSVersionID                    : 2.3.0.0
[GPS]           GPSAltitudeRef                  : Unknown (2)
[GPS]           GPSAltitude                     : 66 m

exiftool -n -GPSAltitudeRef=0.4 image.jpg
    1 image files updated
exiftool -a -G1 -s -GPS:All image.jpg   
[GPS]           GPSVersionID                    : 2.3.0.0
[GPS]           GPSAltitudeRef                  : Above Sea Level
[GPS]           GPSAltitude                     : 66 m

exiftool -n -GPSAltitudeRef=0.5 image.jpg
    1 image files updated
exiftool -a -G1 -s -GPS:All image.jpg   
[GPS]           GPSVersionID                    : 2.3.0.0
[GPS]           GPSAltitudeRef                  : Below Sea Level
[GPS]           GPSAltitude                     : 66 m

- Matti