.CR2 files from Canon 5DSR not recognized in build 5716

[jr_ed]

Something has changed between Windows build 5560 and build 5716 that has caused my RAW processing programs to no longer recognize the .CR2 files from my Canon 5DSR to be recognized as valid RAW files.

I first discovered this because my last two ingests are not seen in Capture One 21.1 (my main RAW program). I then tried the same files in in Adobe Lightroom Classic (latest version) and have a similar issue there (no preview images available). Neither of this programs have any issues with files ingested with build 5560. Also note that this issue does not affect the .CR3 files ingested from my Canon R.

I am running Windows 10x64 (OS build 19041.928). Let me walk you through my debug process. I took 2 test photos with my 5DSR.

A)  Computer 1 running build 5716 - The ingested photos are not recognized by Capture One (or Lightroom).
B)  Computer 2 that still had build 5560 installed - The ingested photos load into Capture One with no issue.
C)  Computer 1, run the build 5716 installer with the repair option - The ingested photos are not recognized by Capture One.
D)  Computer 1, uninstall build 5716, install build 5560 - The ingested photos load into Capture One with no issue.
E)  Computer 1, run build 5716 installer to upgrade - The ingested photos are not recognized by Capture One.

Following the above ingest experiments I ran a hex compare on one of the images (using Beyond Compare):

• Both build 5560 image files are identical
• All three build 5716 image files are identical
• There are a few bytes near the end of the file that are different between the 5560 and 5716 ingests[\li]
  

I should note that I was not intending to manipulate these files during ingest (I'm not applying metadata templates or renaming), so I was expecting the ingested files to be the same as if I had just copied them using Windows Explorer (although doing a hex compare I can see that there are 3 bytes near the end of the file that changed followed by information appended by PM).

At any rate, given the above experiments between two builds and two computers, it seems like the problem is pointing to build 5716.

I ingest to two disks, and unfortunately this issue impacts both copies. I'm hoping we can find a fix for the previously-ingested files as some of the originals no longer exist on the memory card. (I've used PM for years without issue, so test loading the files into Capture One before deleting the originals wasn't part of my workflow.)

Here's a link to a zip file with the two test images from both a 5560 and 5716 build:

https://app.box.com/s/2itmphye4usoajpm8rmx8d4yn4pv73s7

Attached is a screenshot showing the differences I'm seeing between the files from the two versions. Hopefully that will give you a good pointer. If there's more I can do with logs or something to help trace down this issue, let me know.

[Kirk Baker]

Please see this post:

http://forums.camerabits.com/index.php?topic=14078.msg69713#msg69713

-Kirk

[jr_ed]

I had not seen that. I'm glad to hear the issue is understood, and thankfully the fix seems easy. (I've confirmed it on a sample of the impacted images--all looks good.)

So let me follow up with a workflow question: I normally ingest to two drives, and I would like to be able to do that without having the contents of the RAW file touched at all. The idea is that main drive is where I will follow up with naming/tagging/rating etc., while the backup drive remains the untouched original to cover me in the rare case something like this happens. Is there a way to set up PM to ingest without touching the contents of the image file (copy it like Windows Explorer would)? As I mentioned in my original post that's what I thought I was doing by not adding any metadata during ingest, but it appears that alone isn't sufficient.

Thanks. (And thanks again for building a solid, well-supported product. I've been using Photo Mechanic for 15 years now. The lack of issues over that time coupled with your responsiveness to questions/issues have been greatly appreciated.)

[Kirk Baker]

I had not seen that. I'm glad to hear the issue is understood, and thankfully the fix seems easy. (I've confirmed it on a sample of the impacted images--all looks good.)

So let me follow up with a workflow question: I normally ingest to two drives, and I would like to be able to do that without having the contents of the RAW file touched at all. The idea is that main drive is where I will follow up with naming/tagging/rating etc., while the backup drive remains the untouched original to cover me in the rare case something like this happens. Is there a way to set up PM to ingest without touching the contents of the image file (copy it like Windows Explorer would)? As I mentioned in my original post that's what I thought I was doing by not adding any metadata during ingest, but it appears that alone isn't sufficient.

Both the Primary and Secondary destinations are treated the same by Ingest.  There is no way to change that behavior.

-Kirk

[jr_ed]

I understand that both primary and secondary destinations are treated the same. But is there a way to ingest and have the file contents not modified at all from the original file on the card?

[Kirk Baker]

I understand that both primary and secondary destinations are treated the same. But is there a way to ingest and have the file contents not modified at all from the original file on the card?

When you Ingest, as the file is copied, Photo Mechanic stores the "frame number" of the image in the metadata of the image.  If it doesn't do this then there is no way to acquire the frame number (as originally shot) if you rename the image (the frame number is obtained from the four digits at the end of the original file name) later.

If you want your RAW files to never be modified, you'll have to use an XMP sidecar and instruct Photo Mechanic to never modify your RAW files.  This can be done in the IPTC/XMP page of the Preferences dialog.

-Kirk