Focus Distance in Panasonic Lumix DC-GH5

[David Ellsworth]

It appears that focus distance on the GH5 is only stored in raw photos, and not in JPEG photos or MP4/MOV videos. ExifTool does not currently parse this value, and the Panasonic Tags page doesn't list anything relating to distance.

I only have Canon lenses and a Metabones EF-M43-BT2 adapter to test with, and no native Micro Four Thirds lenses. What I found is that in the output of

Code Select Expand

exiftool -U -b -PanasonicRaw_0x0120 "filename.RW2" > "filename.bin"

the 16-bit unsigned little-endian word at offset 0x2A is the focus distance, measured in half-centimeters, where 65535 is infinity (so for example hex 7B 01 represents 1.895 meters). The preceding bytes (offsets 0x22-0x29) in hex are 01 11 03 00 01 00 00 00. I'd be glad to provide example files if necessary – if so, should they be the entire .RW2 files or just the 2048-byte outputs of the above command?


The following information, ExifTool doesn't need to concern itself with, but I wanted to know, so:

When compared to Canon .CR2 metadata (FocusDistanceLower and FocusDistanceUpper in CameraInfo7D), the formula is:

PanasonicFocusDistance = RoundToNearestInteger(sqrt(FocusDistanceLower*FocusDistanceUpper)*2)

where FocusDistanceLower and FocusDistanceUpper are in integer centimeters. I'm not sure whether it's the Metabones adapter or the GH5 doing this geometric mean; it would depend on whether the M43 protocol reports a Lower and Upper or just a single distance. Whichever is doing it, I suspect it's using an approximation for the square root, because for example:

• On the second-to-the-last focus distance of my EF 100mm USM Macro it's getting RoundNearest(sqrt(1117*65535)*2)=17110 instead of the correct value 17112.
• On the second-to-the-last focus distance of my EF 18-55mm IS and IS II it's getting RoundNearest(sqrt(527*65535)*2)=11751 instead of the correct value 11754.
• On the third-to-last focus distance of my EF-S 17-55mm f/2.8 IS USM it's getting RoundNearest(sqrt(1233*13623)*2)=8198 instead of the correct value 8197.

But in the smaller distances I've tested, the rounding works out exactly.

The last focus distance on all my lenses, sometimes beyond the infinity mark, sometimes just short of it, is reported as PanasonicFocusDistance=65535. I'm not sure how the Metabones adapter or GH5 is telling the difference between this and the distance before it; on all my lenses, the CameraInfo7D data for the last two focus points both show a non-infinite FocusDistanceLower and FocusDistanceUpper=65535 (infinity). On some of my lenses (EF-S 17-55mm f/2.8 IS USM, EF 100-400mm f/4.5-5.6L IS USM, and EF 100mm f/2.8 USM Macro) the last two focus points are even both identically reported in CameraInfo7D, as FocusDistanceLower=8191 and FocusDistanceUpper=65535, and yet somehow the GH5+Metabones is able to tell a difference between them.

[Phil Harvey]

Hi David,

Thanks!  PanasonicRaw_0x0120 is actually a full IFD that ExifTool is not yet decoding.  Tag 0x1101 in this IFD is your focus distance.  It isn't a standard TIFF IFD though because it uses format codes 0x101 and 0x102 which aren't standard TIFF.  But I'll see about decoding this.

It would be good to know if this decoding is valid for 4/3 lenses.

- Phil

Edit:  I have added this feature and tested it with all of my RW2 samples (most of which use 4/3 lenses), and the results look very good!  This will appear in ExifTool 10.61 (to be released within a week or so).

[David Ellsworth]

Awesome, thanks Phil!

I suspected it was in EXIF / TIFF tag format due to that familiar "II" at the beginning, but hadn't messed with that file format for 11 years (and then, it was only for writing TIFFs, not reading them). I didn't need to, because ExifTool is so powerful. :-)

Do other cameras besides the GH5 have a PanasonicRaw_0x0120 section?

Did you figure out what this IFD's data formats 257 and 258 mean? When I run the 2048 byte PanasonicRaw_0x0120 section through ExifTool, I get output that begins with

Code Select Expand

[ExifTool]      ExifTool Version Number         : 10.60
[ExifTool]      Warning                         : Bad format (257) for IFD0 entry 0
and does not decode any tags. When I delete that first tag or change its type to a known one, ExifTool decodes the rest, but still shows a Bad format (257 or 258) warning for the first format 257 or 258 tag it comes across, and doesn't show those tags in its output.

The ones with format 257 only take on the values 0 or 1 in the files I've looked at, so it seems to be a boolean. The ones with format 258 take on the values 0, 2, or 3 in the files I've looked at.

And rather odd is having Tag 0x1000 at the very beginning, with format 257 and value 0. Isn't that supposed to be RelatedImageFileFormat, with a string format? Or do manufacturer-specific IFDs like this not avoid collisions with standard tag numbers?


Is there a command-line option that can make ExifTool print the data format of each tag in its text output? I know -htmlDump includes it, but only on mouseover; it'd be useful to be able to see them all at once. Also, is there a way to change the length-in-bytes threshold at which -htmlDump does a [snip] to a long section? That'd be really useful; I've found it to be too eager to [snip] things.

[Phil Harvey]

Do other cameras besides the GH5 have a PanasonicRaw_0x0120 section?

Yes.  A number of them.  Some don't use the same IFD format though.

Did you figure out what this IFD's data formats 257 and 258 mean?

No, but for now I am just extracting them as int32u.

And rather odd is having Tag 0x1000 at the very beginning, with format 257 and value 0. Isn't that supposed to be RelatedImageFileFormat, with a string format? Or do manufacturer-specific IFDs like this not avoid collisions with standard tag numbers?

Right.  They don't care about collisions.  They use their on proprietary tag ID's.

Is there a command-line option that can make ExifTool print the data format of each tag in its text output?

There is -v2 (or -v3).  The new version with show int32u for these unknown formats.

Also, is there a way to change the length-in-bytes threshold at which -htmlDump does a [snip] to a long section?

Yes.  Increase the verbosity level (-v, -v2 ...).

- Phil

[David Ellsworth]

This functionality works perfectly in v10.61. (Also, the verbosity switch was exactly what I needed.) Thanks again, Phil!