Sony A7R IVa EXIF Not Supported?

[jkm]

Someone is using an A7R IVa and there are a lot of blank EXIF data in the files I'm working with in PM. Four regular A7R IV bodies are already being used which have never had issues, and the slightly updated IVa model has been out since May 17th, six months and 10 days ago, so it's not a brand new camera. Does the version of exiftool used by PM need to be updated perhaps?

[Kirk Baker]

Someone is using an A7R IVa and there are a lot of blank EXIF data in the files I'm working with in PM. Four regular A7R IV bodies are already being used which have never had issues, and the slightly updated IVa model has been out since May 17th, six months and 10 days ago, so it's not a brand new camera. Does the version of exiftool used by PM need to be updated perhaps?

Photo Mechanic does not use ExifTool.

Can you post a sample image that does not display expected EXIF data, please?  Use the 'Attachments and other options' link when you're composing your reply to this message and there you'll be able to upload your sample image.

Thanks,

-Kirk

[jkm]

Attached file does not show several EXIF fields like white balance.

[Kirk Baker]

Thank you for the sample file.  We'll investigate and get back to you.

-Kirk

[jkm]

Thank you so much!

[Carlos Rodrigues]

Ii have the sme problem with the Canon R3 files with metadata IPTC

[dennis]

The missing Exif data is from the Sony maker note.  PM has to whitelist the different Sony models in order to parse the maker note.  The next release will have this A7R IVa camera (and other newer ones) whitelisted and will then show the missing Exif maker note values (e.g. white balance).

--dennis

[ejhutch]

The missing Exif data is from the Sony maker note.  PM has to whitelist the different Sony models in order to parse the maker note.  The next release will have this A7R IVa camera (and other newer ones) whitelisted and will then show the missing Exif maker note values (e.g. white balance).

--dennis

That’s ridiculous that you have to do that. I’ve noticed while looking at different kinds of images in different programs and also using image comparison software and hex editors that software developers and device manufacturers still seem to struggle with consistent use of the various metadata standards that we have.

Some read and write the EXIF fields, some the XMP fields, some older IPTC or Adobe fields, and many seem to do an inconsistent combination of the different standards.

I’m frankly quite impressed that PM+ keeps up with it as well as it does.

[jkm]

Thank you so much!

By the way, do you use your own in-house code to parse EXIF, etc., or something like jhead?

Just curious since you said that you do not use exiftool!

[Kirk Baker]

Thank you so much!

By the way, do you use your own in-house code to parse EXIF, etc., or something like jhead?

We have our own code that has been developed over more than twenty years.  Dennis is the metadata man.

-Kirk

[dennis]

Thank you so much!

By the way, do you use your own in-house code to parse EXIF, etc., or something like jhead?

We can't rely upon a 3rd party tool like Exiftool, no matter how useful it is, to be an essential part of Photo Mechanic.  They are a reference of course, but not "embedded" within PM

So our Exif data parsing is all custom but utilizing multiple sources (especially regarding the ugly maker note metadata). As you can appreciate, any maker note data is either non-standard (but willing to be disclosed), or is used by the manufacturer to hide their own internal bits they need for proper post processing with their proprietary software.  In any case, the maker note is proprietary data that can change in format from model to model, therefore we require a whitelisting of these models to make sure PM doesn't have problems with unseen models moving forward.

With regards to any Sony or other cameras, PM will read all the standard Exif metadata fine.  There are of course many "non-standard" fields like white balance that can only be discerned from each manufacturer's maker note.  We do our best to keep up.  In some cases the manufacturers will encrypt certain maker note metadata.  In these cases we will not attempt to decrypt.

--dennis

[jkm]

Thank you so much!

By the way, do you use your own in-house code to parse EXIF, etc., or something like jhead?

We can't rely upon a 3rd party tool like Exiftool, no matter how useful it is, to be an essential part of Photo Mechanic.  They are a reference of course, but not "embedded" within PM

So our Exif data parsing is all custom but utilizing multiple sources (especially regarding the ugly maker note metadata). As you can appreciate, any maker note data is either non-standard (but willing to be disclosed), or is used by the manufacturer to hide their own internal bits they need for proper post processing with their proprietary software.  In any case, the maker note is proprietary data that can change in format from model to model, therefore we require a whitelisting of these models to make sure PM doesn't have problems with unseen models moving forward.

With regards to any Sony or other cameras, PM will read all the standard Exif metadata fine.  There are of course many "non-standard" fields like white balance that can only be discerned from each manufacturer's maker note.  We do our best to keep up.  In some cases the manufacturers will encrypt certain maker note metadata.  In these cases we will not attempt to decrypt.

--dennis

That's so cool that you do all this! My respect for the depth of your coding went up even more!

It would be awesome if someday you can add lossless crop (for non-rotated crops at least) as an option to the save photos as / Cropping apply dialog. Saving crops is one of the things we do all the time, sometimes several different crops from the same photo, and it always destroys some of the data and lowers quality because of needing to re-encode with different 8x8 blocks, even though the person cropping rarely cares if the crop is exactly +/- 4 pixels one way or the other. We end up saving all the crops at a much higher JPEG quality than the original to avoid this which is mathematically so un-optimal because there is still some unavoidable loss plus the output takes up much more space than the original portion of the photo despite being a little lower in quality.

[jkm]

It also makes perfect sense that you need to whitelist the camera models like this. One small assumption that isn't valid anymore could do a lot of damage.