After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 543171 - Unexpected/Wrong EXIF information about "Focal length" shown
Unexpected/Wrong EXIF information about "Focal length" shown
Status: RESOLVED FIXED
Product: eog
Classification: Core
Component: image viewer
2.22.x
Other All
: Normal minor
: ---
Assigned To: EOG Maintainers
EOG Maintainers
: 543173 543175 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-07-15 20:59 UTC by Marcus Dapp
Modified: 2008-07-21 16:29 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
javascript example for 35mm-focal-length calculation (60.67 KB, text/plain)
2008-07-20 17:50 UTC, Marcus Dapp
  Details
show both focal length values (2.45 KB, patch)
2008-07-21 11:13 UTC, Felix Riemann
committed Details | Review

Description Marcus Dapp 2008-07-15 20:59:58 UTC
Please describe the problem:
The value given as "Focal length" is not what photographers expect to see. That value is a camera/hardware-specific value not used by photographers.

They need the (standardaized) value in [mm] given under Details|Camera|FocalLenghtIn35mmFilm.

Steps to reproduce:
1. Open any photos EXIF information and look at the Focal length tag.
2. Recognize it is not a familiar value at all to you.
3. 


Actual results:


Expected results:
That the focal length shows the focal length based on 35mm film, the standard value used for lenses, etc.

Does this happen every time?
Yes.

Other information:
Solution: Display the EXIF value of FocalLenghtIn35mmFilm instead.
Comment 1 Claudio Saavedra 2008-07-15 21:24:11 UTC
*** Bug 543173 has been marked as a duplicate of this bug. ***
Comment 2 Claudio Saavedra 2008-07-15 21:25:03 UTC
*** Bug 543175 has been marked as a duplicate of this bug. ***
Comment 3 Felix Riemann 2008-07-19 13:25:43 UTC
Well, the actual change is a one-liner.

But we should probably implement a fallback to the current value if the 35mm-tag is not present. Or we could try to display it like exiv2:

Focal length    : 5.8 mm (35 mm equivalent: 35.0 mm)
Comment 4 Marcus Dapp 2008-07-20 14:33:52 UTC
You probably know that, but just for reference:
http://www.exif.org/Exif2-2.PDF, page 31.

I do not know if the EXIF spec allows the 35mm value to be missing (should not be) because the "lens focal length" is a camera/lens specific value, not standardized AFAIK and therefore useless for comparisons.

Two general options:

A) If reporting both separately, I suggest:

Focal length (35mm film): 70.0
Lens focal length:        11.7


B) If reporting all on one line, the more important 35mm value should come first:

Focal length:    70.0 (35mm film), 11.7 (lens)

I also think the "mm" unit can be omitted as focal length is always given in mm.
Personally, I would prefer solution A) with the 35mm value given directly and the lens value hidden in metadata "details" for the argument given above.

Thanks.
Comment 5 Marcus Dapp 2008-07-20 14:45:18 UTC
For the fallback solution suggestion, see EXIF spec, p.43:

"FocalLengthIn35mmFilm
This tag indicates the equivalent focal length assuming a 35mm film camera, in mm. A value of 0 means the focal length is unknown. Note that this tag differs from the FocalLength tag."

So, in case the camera would only report thier own FL but not the standardized 35mm equivalent, the tag value would be 0. 

In that case, I would recommend to report "unknown" rather than "missing" or "0" in the metadata.
Comment 6 Felix Riemann 2008-07-20 17:29:59 UTC
(In reply to comment #4)
> You probably know that, but just for reference:
> http://www.exif.org/Exif2-2.PDF, page 31.
> 
Yes, I know. :-)

> I do not know if the EXIF spec allows the 35mm value to be missing (should not
> be) because the "lens focal length" is a camera/lens specific value, not
> standardized AFAIK and therefore useless for comparisons.
> 

Yes, both are theoretically optional (see PDF-Page 61, Table 15).

> Two general options:
> 
> A) If reporting both separately, I suggest:
> 
> Focal length (35mm film): 70.0
> Lens focal length:        11.7
> 
> 
> B) If reporting all on one line, the more important 35mm value should come
> first:
> 
> Focal length:    70.0 (35mm film), 11.7 (lens)
> 
> I also think the "mm" unit can be omitted as focal length is always given in
> mm.
>
Well, the mm is supplied by libexif already (unfortunately not for FocalLengthIn35mmFilm). But it should be possible to do this by interpreting the exif value ourselves, which we might need to do anyway as libexif calculates the 35mm value automatically for some Minolta cameras and returns a result string in similar fashion to the example I gave obove when requesting FocalLength.

> Personally, I would prefer solution A) with the 35mm value given directly and
> the lens value hidden in metadata "details" for the argument given above.
> 
I somewhat prefer the second one. It looks like a good compromise to me.

Comment 7 Marcus Dapp 2008-07-20 17:50:13 UTC
Created attachment 114866 [details]
javascript example for 35mm-focal-length calculation

See exif.js inside, search for "35mm"...

Taken from the "fxif" FIreFox plugin, from:
https://addons.mozilla.org/en-US/firefox/addon/5673
Comment 8 Felix Riemann 2008-07-20 17:51:55 UTC
Btw, the output would be more like

Focal length:    70 (35mm film), 11.7 (lens)

as the 35mm value is saved as a short integer value (at least if you don't add the .0 yourself).
Comment 9 Marcus Dapp 2008-07-20 17:57:01 UTC
(In reply to comment #6)
> (In reply to comment #4)
> Yes, both are theoretically optional (see PDF-Page 61, Table 15).

Oh, ok. 

> Well, the mm is supplied by libexif already (unfortunately not for
> FocalLengthIn35mmFilm). But it should be possible to do this by interpreting
> the exif value ourselves, which we might need to do anyway as libexif
> calculates the 35mm value automatically for some Minolta cameras and returns a
> result string in similar fashion to the example I gave obove when requesting
> FocalLength.

I had a look at some js code of the EXIF plugin I use in FireFox: https://addons.mozilla.org/en-US/firefox/addon/5673

It does calculate the 35mm equivalent out of EXIF data (CCD width and other parameters), which is clever and would be useful if only the camera-specific FL is reported in the jpg's EXIF... See attachment. I just do not know if the formula is correct and valid in general.

> > Personally, I would prefer solution A) with the 35mm value given directly and
> > the lens value hidden in metadata "details" for the argument given above.
> > 
> I somewhat prefer the second one. It looks like a good compromise to me.

Fine with me. Let's take the combined variant and have the 35mm value prominently visible.


Comment 10 Marcus Dapp 2008-07-20 18:14:33 UTC
(In reply to comment #8)
> Btw, the output would be more like
> 
> Focal length:    70 (35mm film), 11.7 (lens)
> 
> as the 35mm value is saved as a short integer value (at least if you don't add
> the .0 yourself).
> 

Yes. Meanwhile I realized from the formula in the FF plugin. From photography practice, fractions of focal length are nonsensical in almost all cases anyway. (Except some 10.5 mm fisheye lens...)
Comment 11 Felix Riemann 2008-07-20 19:02:41 UTC
(In reply to comment #7)
> Created an attachment (id=114866) [edit]
> javascript example for 35mm-focal-length calculation

Oh, that makes me know two tools that try to calculate the 35mm value if it's not shipped; the other one being exiftool. And of course they calculate different values on my images (would have been too easy if they would).

The JavaScript one looks pretty simple. Although I don't know why the FocalLength/CCDWith relation needs to be multiplied with 36. Furthermore it seems to have problems on Canon DSLRs:

    // don't calculate 35mm equivalent for Canon, some of their Digital SLRs
    // have a crop factor that's not specified in the EXIF anywhere

The one from exiftool is quite a bit bigger and takes more input data (and apparently tries to avoid the Canon problem) to just calculate the scaling factor. Here's just the initial comment for the calculation routine:

#------------------------------------------------------------------------------
# Calculate scale factor for 35mm effective focal length
# Inputs: 0) Focal length
#         1) Focal length in 35mm format
#         2) Canon digital zoom factor
#         3) Focal plane diagonal size (in mm)
#         4/5) Focal plane X/Y size (in mm)
#         6) focal plane resolution units (1=None,2=inches,3=cm,4=mm,5=um)
#         7/8) Focal plane X/Y resolution
#         9/10,11/12...) Image width/height in order of precedence (first valid pair is used)
# Returns: 35mm conversion factor (or undefined if it can't be calculated)

All in all it can take up to 14(!) parameters as input (there are three possible width/height pairs) in the worst case. You can take one less if you ignore the Canon zoom value, which requires getting several specific values from the MakerNote to determine, which is something currently not supported by EOG.

As this is quite some effort to calculate and I still don't know if it is right, I vote for not currently implementing this (yet).
Comment 12 Felix Riemann 2008-07-21 11:13:17 UTC
Created attachment 114914 [details] [review]
show both focal length values

So, this implements option B from above.
I made the 35mm value look the same as the lens value. There are also translator commments for each part to let them know what's going on.

In the long run we'll have to find a solution to bug 502023 to make this fully "enjoyable".
Comment 13 Felix Riemann 2008-07-21 16:29:02 UTC
Okay, it's in SVN trunk:

2008-07-21  Felix Riemann  <>

	* src/eog-properties-dialog.c: (eog_exif_set_focal_length_label),
	(pd_update_metadata_tab): Show the 35mm equivalent in addition to the
	lens focal length in the properties dialog (if it is provided by the
	camera). Fixes bug #534171.
-------------------------------------------------------------------------------
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.