Hey thanks for writing back. I wrote my earlier response to your dilemma, because – after doing some testing - I wanted to reassure general users that DPP4 still seems to work pretty well with their older CR2 files and can be used to edit them. Your case is real too, of course, and that sounds like quite a dilemma. Per your question, I did review it one more time and, In my case, I do find CR2 files that were cropped in DPP3 where the cropping is still intact in DPP4. DPP4 does let me edit these files although it balked once when I tried to copy and past a .CR2 file back in the same directory. (in that case, Windows Explorer still worked.)
I reviewed some EXIF data from some of these images, and I notice that the CropTopMargin or CropLeftMargin fields as reported by ExifTool are showing up as 0 in my case. The cropping is defined, instead, by other fields, similar to what you noted in some of your other posts. This leads me to wonder if the fields that DPP4 may not be recognizing may be related to the specific camera and that some cameras populated different fields. In my case, I was pulling sample images that went back 12 years over two different cameras: a Canon 60D, a Canon 5D Mk IV.
In the sprit of honesty, I should note that I did not find a high proportion of images from that era in my work which had been cropped. It was not the majority for sure. I even found a JPEG that showed cropping while the CR2 file had no signs of the crop. My theory is that was a cases where I forgot to save my edits after generating the JPEG. That can happen sometimes. That’s my theory anyway. I should note too, that I was a little surprised how few of these were showing as cropped. I think that’s attributable to a change in practice, however. Nowadays, when I’m mostly boiling 3000 shots down to the savory-best 100 on a fast moving sports event, I crop every single thing in my “keeps” folder. About 3 percent of these are just my way of marking the fact that it got edited but generally, everything gets touched. A few years ago it hit me that absolute, true vertical says something about quality and realism and I leaned into that pretty hard from that point forward. I guess it kind of became part of my “brand”, so to speak. So, at first it was a little hard to believe how intermittent my cropping was from those days, but I think what I saw was an accurate sample, from a time when I didn’t fully “get” the subtle power of cropping and when I could frame the image in camera, because people weren’t always jumping around.
Using the ExifTool field assignments, I went ahead and pulled the cropping-related fields from three different images and printed them out in a table for you, in case that gives you some insight or ideas. There are as follows: 1) An old .CR2 image from the 5D Mk IV which I had recently cropped, edited and saved in DPP4, 2) A 5D Mk IV image which had been cropped in DPP3 with cropping still evident in DPP4 and 3) A old 60D image that was cropped long ago in DPP3 where the cropping is also visible in DPP4. None of these used the algorithm involving “Top” or Left” margins. All of them used the approach involving the starting point X, Y along with Width and Height. Again, I’m wondering if that might be a camera – specific thing. Below is the comparative table of fields:
| | File:FileName |
| | AF8A5785-DPP4.CR2 | _F8A6463.CR2 | IMG_6398.CR2 |
EXIF:Model | Canon EOS 5D Mark IV | Canon EOS 5D Mark IV | Canon EOS 60D |
ExifTool:ExifToolVersion | 13.33 | 13.33 | 13.33 |
File:FileSize | 41480447 | 42526597 | 18975482 |
MakerNotes:CropLeftMargin | 0 | 0 | 0 |
MakerNotes:CropRightMargin | 0 | 0 | 0 |
MakerNotes:CropTopMargin | 0 | 0 | 0 |
MakerNotes:CropBottomMargin | 0 | 0 | 0 |
MakerNotes:CroppedImageWidth | 6720 | 6720 | 3888 |
MakerNotes:CroppedImageHeight | 4480 | 4480 | 2592 |
MakerNotes:CroppedImageLeft | 0 | 0 | 0 |
MakerNotes:CroppedImageTop | 0 | 0 | 0 |
CanonVRD:CropAspectRatio | 2 | 4 | 4 |
CanonVRD:CropAspectRatioCustom | 1.5 1 | 1 1.5 | 1 1.5 |
CanonVRD:CropActive | 1 | 1 | 1 |
CanonVRD:CropRotatedOriginalWidth | 6797 | 4597 | 2592 |
CanonVRD:CropRotatedOriginalHeight | 4597 | 6797 | 3888 |
CanonVRD:CropX | 78 | 655 | 90 |
CanonVRD:CropY | 113 | 893 | 667 |
CanonVRD:CropWidth | 4367 | 3839 | 2147 |
CanonVRD:CropHeight | 4367 | 5759 | 3221 |
CanonVRD:CropRotation | 0 | 90 | 90 |
CanonVRD:CropAngle | 1 | -1 | 0 |
CanonVRD:CropOriginalWidth | 6720 | 6720 | 3888 |
CanonVRD:CropOriginalHeight | 4480 | 4480 | 2592 |
I’m not finding that DPP3 is readily available nowadays for Windows 11, so I didn’t try reviewing any files with DPP3 by installing that on my newly built Windows 11 machine. As you noted, that cross-platform stuff can get tricky nowadays.
In looking at the many crop fields above you can visualize some of the algorithms that might be used to describe a crop. In your case, if you’re trying to fill-in the CropX and CropY, keeping the Width and Height, you might try something like the simple algorithm modeled in the two strings of Python code below:
MetaDataDF[("CanonVRD:CropY")] = ( MetaDataDF[("MakerNotes:CropTopMargin")] + MetaDataDF[("CanonVRD:CropHeight")] )
MetaDataDF[("CanonVRD:CropX")] = MetaDataDF[("MakerNotes:CropLeftMargin")]
For safety’s sake you might also try zeroing out the “left” and “top” values in case they might compete:
MetaDataDF[("MakerNotes:CropLeftMargin")] = 0
MetaDataDF[("MakerNotes:CropTopMargin")] = 0
Obviously this would take some experimentation on your part. I haven’t tried tinkering with these fields myself since, they are working as is. Hopefully, however, this gives you some ideas. Again, I appreciate you reaching out to respond. Good luck with this and be well.
