Lightroom strips very valuable EXIF data - details

Question

Hey everyone - I've just been playing around with some EXIF stuff, and I noticed something very concerning.
I do a lot of macro photography, specifically with Canon's MP-E 65mm 1x-5x Macro. This lens records its macro magnification factor in the EXIF data, and does so far more accurately and conveniently than I can.
I know that Lightroom and Photoshop strip out A LOT of obscure EXIF data when processed, but this magnification data is extremely valuable when reviewing my photos at a later date.
I can provide sample files if needed, and here is my observations so far:
- data stays intact when converting from .CR2 to .DNG
- data is stripped when converting to JPG, TIFF, and other formats
- data is stripped by both Lightroom and Photoshop
Here is the EXIF data (from exiftool) right from the Canon CR2 or DNG file (both are identical):
http://don.komarechka.com/exif/exif-original.txt
Here is the EXIF data (from exiftool) from a jpg that has gone through Lightroom:
http://don.komarechka.com/exif/exif-lightroom.txt
You'll notice a HUGE amount of extra data in the original raw file. It is certainly worth noting that the EXIF data in a JPG, unaltered from the camera, contains all of the same data as the RAW file.
So, is this something that has been overlooked, is there any way to change this behaviour? Even though Lightroom might not be able to decode this data, I don't see a reason why it cannot be left intact.
Thank you.
- Don Komarechka
http://don.komarechka.com

Answer 1

donkom wrote:
clvrmnky, thanks for your response.
Here's an example for you, the one I've been giving:
I shoot with a special macro lensm the Canon MP-E 65mm f/2.8 1-5x Macro. This lens does not zoom, but the magnification can change from 1x to 5x.This lens communicates its magnification to one decimal point accuracy to the camera, which adds it to the maker notes.
This is important in reviewing images for a number of reasons, including calculating the effective aperture and depth fo field. This is a valuable piece of information that is stored within the makernotes that is removed from the image when sending it through LR, Photoshop, or ACR.
That isn't the only valuable information, however.
The makernotes will tell me if the image was captured using LiveView, if Mirror Lockup was used, if the shot is part of a bracketed set, what the internal camera temperature was, etc. etc.
I'm not sure you've justified your reasoning behind why this block of data shouldn't be blindly copied. If it is removed simply because it is not understood, I would like the option to understand this data on my own, using third-party tools, after the image has left LR.
I understand that this can be proprietary, but likely far less so than the RAW file formats that LR and ACR already understand. It would be trivial to understand where this block of data begins and ends and to leave it in the file on export.
I think this would allow for more in-depth searching based on metadata, for whoever wants to take up that torch. For example, what if I want to see all macro photos I took at a 4x magnification or higher. What if I want to see all photo I took using LiveView. Even if LR doesn't want to do this, stripping the data out prevents anyone else from doing it in the future.
Well, there is an SDK for metadata that has been around for awhile, which allows for custom metadata definitions. But, according to the SDK:
"Values stored in custom metadata fields are stored only in Lightroom's database. In the current release, a plug-in cannot link custom metadata fields to XMP values or save them with the image file."
So, this is more for searching and interfacing with tagset plugins.
Even so, using the SDK to get at maker notes is a losing proposition.
Note that some metadata is proprietary and will not be read into the database. This is to be expected. Lr is not an arbitrary metadata reading app, and there is no guarantee that any app could read all metadata. For example, Lr tries its best to get the serial number info, but this is because there is a lot of value in that for other Lr operations. So the contortions necessary to reliably get that is worth it. Another example is lens info (which is a twisty maze of passages; no app is ever guaranteed to actually retrieve lens info reliably in all cases) where there is a lot of value trying to extract the information that makers often store in very interesting ways. In some of those cases I think Lr will look in the maker notes, but only after exhausting other avenues, and with the caveat that it may never be able to get some information. The app does its best to get at the most valuable info it can get that fits with the standardized metadata models in place.
However, the key here is that maker note data is not in exported files that Lr makes, because it is not normalized data that belongs to the vendor. (This obviates the recommendation of using Metadata Wrangler, which can filter out only that metdata that exists in Lr; I had vaguely remembered a setting that referred to this section but was wrong.)
The field and data formats are not standardized, so you are asking Lr to understand most or all data from all or most lenses and bodies (all of it in varying degrees of similarity and difference) not just data from this lens and this body.
This is also not a trivial matter of "copying" the maker notes over, because copying implies parsing and duplicating what is essentially unknown formatted data containing proprietary data, possibly by custom serialization routines. Remember that maker notes were never intended to be editable, and could be composed of any number of data formats. Some cameras make maker notes that are megabytes of nulls and nothing else!
I think you are out of luck for this specific case.  Perhaps with EXIF 3 we will have a more standardized interface cameras and software can more easily interoperate on shared data. Makers need to stop using the maker notes! It was always an egregious hack.
One workaround I can think of is to have a post-export action that uses EXIFTool to update exported images. For those cases where it matters, you could create your own "sidecar" file that has only the maker notes, and then shove those into the JPEG after they are created, or just read it from the on-disk copy and then put it in the new file (possibly in the same directory and added back into the catalogue for convenience.)