Skip to main content
Adobe Photoshop Family
F

8 Messages

 • 

140 Points

Fri, Nov 20, 2020 10:14 AM

Lightroom Classic: wrong handling of the conversion of original focal lengths?

[This bug occurs because LR isn't following the EXIF spec and recalculating FocalPlaneX/YResolution when it exports a resized image.  See here for details:

https://feedback.photoshop.com/conversations/lightroom-classic/lightroom-classic-wrong-handling-of-the-conversion-of-original-focal-lengths/5fb797112bd82446a3a60da4?commentId=5fc001008acbf10bdd87dec9 

- John R Ellis]

I have noticed a bug in the way Lightroom Classic handles the conversion of original focal length of the lens to focal length in 35 mm.
My Canon 50mm/1.8 for example is reported as 211mm instead of the correct 80mm. (1.6x50)
This happens when I export jpgs from the RAW-files and it´s the same problems with all my lenses and it´s not a new problem, since my old jpg files show the same problem.

The author of ExifTool, Phil Harvey gave this answer to a question about the problem:
"This is a common problem because other software often writes the FocalPlaneX/YResolution tags incorrectly."
Is there a way to solve this problem?

/Kjell

Responses

8 Messages

 • 

140 Points

2 months ago

To the above I would like to add that this conversion problem only apples to my CANON CAMERAS M50 AND M100!

I also sometimes shout m43 and they are OK - no conversion problem there.

I enclose info about lens focal info from my Canon M50 11 mm lens:

 

* Info from the original Canon CR3 file - where to focal lens in 35mm is correct:  17.1 mm

* info from a jpg-file exported från LRC 10.0 - where to focal lens in 35mm is totally wrong:  138.1 mm

/Kjell

8 Messages

 • 

140 Points

The screen dumps above are taken from the viewer/editor ApolloOne 

/Kjell

8 Messages

 • 

140 Points

My old(er) Canon M10 has got it quite right, though!  22mm = 1.6x22 = 35,2 mm

/Kjell

Champion

 • 

5.5K Messages

 • 

97.2K Points

2 months ago

Without seeing the actual .cr3 and exported .jpg, it's hard to know for sure, but the problem is as likely to be in ApolloOne as in LR.

 

Though there is an EXIF field FocalLengthIn35mmFilm, many cameras don't fill it in, so apps need to use the image pixel dimensions and the fields Focal Plane X/Y Resolution to compute  the crop factor and then the 35 mm focal length.

 

I downloaded sample Canon M50 .cr3s (focal lengths 32 and 15 mm) and exported JPEGs from them using LR 10.  The 35 mm focal lengths displayed by Exiftool and ApolloOne (which uses Exiftool) agreed with what I calculated from the metadata, and all three values were within 4% of the "true" value.

 

These small discrepancies arise from curious Focal Plane X/Y Resolution values that Canon wrote into the .cr3 and LR wrote into the .jpg.  Compared to "true" crop factor (computed from the sensor size published by Canon), Canon wrote X/Y values resulting in a crop factor 4% too low, while LR wrote values resulted in a crop factor 4% too high. Even more curiously, Canon wrote different values for X and Y, as if the pixels weren't square.

 

But these small discrepancies don't account for the huge discrepancies you're seeing.  We'd have to see the actual .cr3 and .jpg to know whether it's a bug in the Canon firmware (writing invalid metadata that's fooling LR's export), in LR, or in ApolloOne.

8 Messages

 • 

140 Points

No, ApolloOne converts 100% OK! 

 

/Kjell

Champion

 • 

5.5K Messages

 • 

97.2K Points

Yes, but LR may be including correct metadata in its exported .jpg and ApolloOne displaying it incorrectly.  Again, to determine "fault", we'd need to see the original .cr3 and .jpg.

8 Messages

 • 

140 Points

I forgot to mention that this jpg is converted in ApolloOne from the original Canon CR3-file that hasn´t been near LRC10. 

/Kjell

Champion

 • 

5.5K Messages

 • 

97.2K Points

Right. The question on the table is what LR puts in the metadata of your exported JPEGs. It could put in correct metadata that ApolloOne is misreading, or it could be putting in incorrect metadata.

Considering that sample M50 .cr3s downloaded from dpreview.com don't exhibit this misbehavior, I think it's very unlikely Adobe will investigate this without a simple way to reproduce the problem. If you upload a sample raw and the exported JPEG (both are important) to Dropbox or similar and post the sharing link here, it should become clear whether this is a LR bug or an ApollonOne bug and what in detail is causing it.

8 Messages

 • 

140 Points

Here is a zipped file containing the original CR3-file from my Canon M50 (actually a copy of the original which hasn´t been download to LRC) and a jpg-file from LRC made from the non-copy original CR3-file.

https://www.dropbox.com/s/aunnjzqcpobwoql/IMG_2849.zip?dl=0

Hope this works.......

/Kjell

Champion

 • 

5.5K Messages

 • 

97.2K Points

2 months ago

Your sample files helped me understand what you've been observing.  The anomalous effective 35 mm focal length values are caused by resizing the image when it was exported from LR.  While my reading of the EXIF spec is that apps should recalculate the EXIF fields recording sensor dimensions when resizing images, I haven't found any apps that actually do so, so LR is in good company.  The documentation for Exiftool warns about this:

 

"FocalLength35efl...this value may be incorrect if the image has been resized"

 

You didn't observe this behavior with ApolloOne because it doesn't resize images.

 

I've never poked into this corner of metadata before, which is why I didn't initially understand what you were seeing.

 

Gory Details

 

When a camera doesn't record a value in EXIF:FocalLengthIn35mmFilm, Exiftool and other apps must compute the effective 35 mm focal length from the width and height of the image in pixels and the size of the sensor, which is recorded in the EXIF fields FocalPlaneXResolution, FocalPlaneYResolution, and FocalPlaneResolutionUnit.   From these, an app can compute the crop factor, and from that, the effective 35 mm focal length.

 

FocalPlaneXResolutionUnit is either centimeters or inches, and FocalPlaneXResolution is the number of pixels per unit in the X direction (width). The width of the sensor in mm is thus:

 

sensorWidthMM = mm/unit * widthPixels / FocalPlaneXResolution

 

Ditto for the sensor height.

 

For the sample .cr3 you included, the calculated sensor dimensions are 23.4 x 15.1 mm (4% larger than the specs, 22.3 x 14.9). 

 

When LR exports a JPEG at 100% resolution, it changes the FocalPlaneX/YResolution fields slightly for unknown reasons, yielding a calculated sensor dimensions of 21.5 x 14.3 mm (4% smaller than the specs).  

 

Thus, the effective 35 mm focal lengths shown by Exiftool for the .cr3 and th exported .jpg aren't that much different, 32.2 mm and 36.8 mm.

 

But the sample JPEG you included was exported at a greatly reduced resolution of 1024 x 683, and Exiftool shows a huge effective 35 mm focal length of 215.8 mm. This is because when LR resized the image, it didn't change FocalPlaneX/YResolution accordingly. 

 

I would think that when an app resizes an image, it should change FocalPlaneX/Y Resolution, since there now a different number of pixels representing the width and height of the sensor. But I tested a number of random apps I have installed, and all either left the FocalPlaneX/YResolution unchanged or deleted the fields entirely:

 

LR (Mac), Photoshop (Mac), Faststone Image Viewer (Win), GIMP (Mac), Irfanview (Win), Photos (Win), Parallels Resize Images (Mac), Image Magick (Mac)

 

You didn't observe any misbehavior with ApolloOne because it doesn't have a resize command.

 

The EXIF 2-32 spec is not crystal clear about how those fields should be handled:

 

"Note on use of tags concerning focal plane resolution

 

"These tags record the actual focal plane resolutions of the main image which is written as a file [sic] after processing instead of the pixel resolution of the image sensor in the camera. It should be noted carefully that the data from the image sensor is resampled.

 

These tags are used at the same time as a FocalLength tag when the angle of field of the recorded image is to be calculated precisely."

 

My reading of this is that if a camera resizes an image in the camera ("resamples"), the fields should record the resolution of the resampled image, so that the angle of field of the recorded image can be calculated correctly.  (The angle of field is proportional to the crop factor.)

 

So if the spec says a camera should recalculate FocalPlaneX/YResolution when it resizes an image in-camera in order to allow correct computation of the angle of field, I would think this implies that apps should do so too.

 

But I don't know of any apps that actually do this. I've edited your initial post to make it clear to Adobe engineers where I think the problem is, but given how long the EXIF spec has been out and that we don't know of any apps that adopt my interpretation, I think it unlikely Adobe would act on this.

 

(edited)

Champion

 • 

5.5K Messages

 • 

97.2K Points

2 months ago

You could workaround this bug by using an Export post-processing action that invokes the Run Any Command plugin to use Exiftool to set FocalPlaneX/YResolution of the exported JPEG based on the dimensions of the original master and the exported JPEG.  

But beware that there is a steep learning curve for Exiftool. It would probably take me a couple three hours to get the details right.

8 Messages

 • 

140 Points

Thanks a lot for your interest and valuable information about this problem, John!

(edited)

/Kjell