EXIF has TMI - Canon EOS 400D / Digital Rebel XTi and Focus Distance

[BogdanH]

I believe, for such comparison (450D vs 400D), it's better to have full raw files by hand. You can get some here:
http://www.imaging-resource.com/PRODS/XSI/XSITHMB.HTM

Anyway, to findout something usefull (for DPP), I would keep Adobe's software out of the game for now -they use their own "approximation" formula for their needs.

Bogdan

[Philnick]

I'm turning my hand to creating the batch file, which would run recursively through all my image file folder's subfolders. It would be located in the top image folder.

"::"  lines should be inactive comments, if I remember correctly from my old batch file programming days in the 1980s -
otherwise, use the less elegant "REM"

Rewrote this to use an explicit step counter and test for it, to avoid an interruption in the run from screwing the files up royally. I know ExifTool backs up the original, but would the second step replace the backed-up original with a backup of the result of the first step, etc? If so, I'd probably need to make a duplicate of the whole folder tree before beginning, just to be safe.

------------

:: See if the file is an XTi file that has not been repaired [FDU/FDLswapCounter doesn't exist], and if so copy the value
:: in FDU into FDU/FDLswap and create the counter with a value of 2
::
ExifTool -FDU/FDLswap=FocusDistanceUpper -FDU/FDLswapCounter=2 -if "$Model=Canon DIGITAL REBEL XTi" -if "not $FDU/FDLswapCounter" -r .
::
::If FDU/FDLswapCounter equals 2, copy the value in FDL into FDU and set the counter to 1
::
ExifTool -FocusDistanceUpper=FocusDistanceLower -FDU/FDLswapCounter=1 -if "$FDU/FDLswapCounter=2" -r .
::
::If the counter equals 1, copy the value in FDU/FDLswap  into FDL, delete the swap holder, and set the counter to 0
::to show that the values are no longer incorrectly swapped
::
ExifTool -FocusDistanceLower=FDU/FDLswap -FDU/FDLswapCounter=0 -FDU/FDLswap= -if "$FDU/FDLswapCounter=1" -r .

-------------

I'm not sure whether my syntax for testing for the absence of the counter in the first step is correct, and I'm also not sure about how to copy the value of one tag into another.

Would this work?

[Phil Harvey]

Maybe I missed something, but I have no idea what you are doing here.  The arguments like -FDU/FDLswap=FocusDistanceUpper make no sense to me, or where these tags are coming from.

- Phil

[Philnick]

Phil,

What I'm trying to do is automate exchanging the values in FocusDistanceUpper and FocusDistanceLower with a recursive batch file that would run through my whole photo folder tree.

The first step makes sure that it's an XTi file (I also have files from my G12 and my prior cameras, an XT and a G9). The XTi is the only one of these that has the swap bug. The XT doesn't write either of the swapped values at all, and the G9, like the G12, sets the lower value to 0 in all its files.

FDU/FDLswap is a temporary tag to hold the value of FocusDistanceUpper so that it's not lost when FocusDistanceUpper is given the value in FocusDistanceLower. Then the value in the swap tag is copied into FocusDistanceLower and the swap tag is deleted.

FDU/FDLswapCounter is flow control. It is left at a value of 0 at the end of the routine to flag an image as having had the swap completed so they won't be swapped back in a later run after I've added new pictures. It counts down from two to zero to say which stage in the processing that file has gotten through, so in the event of a run that's interrupted and then restarted, the process should skip that file until it gets to the next step for that file.

Both tags are my own invention. I may shorten them to FDswap and FDswapCounter for convenience.

I'm unclear on the syntax for copying the value of one tag into another, so that's why those arguments were meaningless. I had a hard time figuring out how to do that.

I also was not entirely clear on how to test to see if a tag exists at all (in the test for the counter in the first step).

Could you tell me how to phrase those instructions?

Phil Olenick

PS To make this useful for others, I may - in the first step - use the CanonModelID tag instead, since that value uses all three of the names this camera is known by and should thus be more universally-useful, if slower to run.

[Phil Harvey]

OK, thanks.  I think I understand now.  A temporary variable isn't necessary.

What about something like this?:

exiftool -n "-focusdistancelower<focusdistanceupper" "-focusdistanceupper<focusdistancelower" -if "$canonmodelID == 0x80000236 and $focusdistanceupper < $focusdistancelower" FILE

Where FILE can of course be one or more file names or directory names.

When copying tag values, the source value is always the one read from file, which means you don't need to use a temporary variable when swapping values.

- Phil

Edit: Now that I look at it, this command is a bit confusing because the less-than symbol is used for copying tag values in two of the arguments, but in the -if expression it is a numerical less-than operator.

[Phil Harvey]

I forgot to answer your question about the existence of a tag.  If the -if expression would generate any errors (as would happen with a missing tag), then the condition fails and the file is not processed..

- Phil

[Philnick]

Wow - I'm impressed. It looks like you've boiled my entire routine down to one command! In fact, since you're testing for the upper value being less than the lower, the swap should occur whenever that's true, so it isn't even necessary to test for the camera model!

My only concern is that if the two swaps occur sequentially, won't they both end up with the same value?

Or does "the source value is always the one read from file" imply that nothing is written back to the disk until the command completes and each tag has been updated by reading from the file on disk?

- PhilToo

[Phil Harvey]

nothing is written back to the disk until the command completes and each tag has been updated by reading from the file on disk?

Exactly.

- Phil

[Philnick]

Cool! I'm going to test this out on a sample folder tree tonight.

By the way, I learned something important about Adobe Camera Raw today - in CS4 it's shipped set to convert RAW files to 8-bits-per-color by default - but that's easily changed.

I won't bore you with the details of how I determined this, but I will tell you how to change it in CS4.

Have ACR open a RAW file - either by telling Bridge to send it to Photoshop or by using Photoshop's File|Open command - and at the bottom of the screen, look for a line that lists the color space, bit depth, and number of megapixels.

That's not what it's getting from the RAW file - it's what it's going to turn it into to send to Photoshop.

It looks like a web link - blue and underlined. Click on it and you'll get a panel for customizing ACR's workflow settings.

You can change any of those details and they'll stick for future images until you change them again.

I've set my copy to 16-bits per color - why shoot RAW files if you're going to edit them in the same bit depth as a JPEG?

[Philnick]

I copied part of my "Incoming" folder to a location outside my main Photos folder so I could run a recursive test on it - my 400D files are in several subfolders, and there are G12 files in yet other folders there.

I changed Phil Harvey's elegant one-line version of my routine very slightly:

1) Since it directly tests for the error condition, there's no need to test for the camera model - in fact, if any other camera makes the same error, its files should be corrected as well - so I deleted the first part of the -if expression.

2) I replaced "FILE" at the end with "-r . " to make it run recursively from the folder it starts in.

It now reads as follows:

exiftool -n "-focusdistancelower<focusdistanceupper" "-focusdistanceupper<focusdistancelower" -if "$focusdistanceupper < $focusdistancelower" -r .

I saved it as a text file and named it "SwapFD.bat" to make it into a batch file - it's attached for anyone who wants to use it - and copied it into the top folder of my test tree.

I clicked on it and it opened up a command window that showed its contents, and nothing else on the screen.

After several minutes, the command window closed.

I opened up Bridge and browsed through the files - they all showed the Subject Distance.

Now I just have to figure out how to get DPP to understand!

[Philnick]

Since the test run of SwapFD.bat was a success, I copied it to the top of my photo file tree and clicked on it in Windows Explorer as I went to bed.

When I got up, the command window had closed, and the size of the photo file tree had increased substantially, because ExifTool had not been told to skip doing a safety-rename of any original files it changed by adding "_original" to the end of their extensions.

While I haven't looked at all 8,800 files, it seems to have done what it was supposed to - and educated me in the process about which kinds of files don't have the focus distance EXIF data, like JPEGs, TIFFs, and PSDs created by Photoshop from 400D files that still had the FD bug, and TIFFs from my 400D written by Canon's Digital Photo Professional (until I get it to understand the distance info in 400D files).

On to putting the 400D's EXIF in shape for DPP to understand the focus distance!

[Phil Harvey]

It must be a bit of a pain to delete the "_original" files if they are scattered across many directories, but I have never received a request for this feature.  I have been toying with the idea of adding a -delete_original option to make this easier (along with a -restore_original option to un-do the changes), but I haven't implemented this yet.

- Phil

[Philnick]

There are not that many folders - maybe thirty or forty of them - so it's not that much of a chore. Sorting by Date Modified makes it easy enough to group the "_original" files and delete them.

By the way, the files' creation dates did survive the process on my Win XP Pro SP3 machine - the corrected files show today as the date modified, but their creation dates are contemporaneous with when the pictures were taken and copied to the computer.

[Phil Harvey]

There are not that many folders - maybe thirty or forty of them

Wow.  I guess I'm lazier than you.  I'm thinking seriously about adding these features now.  The -restore_original option would perhaps be more useful because renaming all the files is more work than deleting them.

- Phil

[Philnick]

If you sort on the File Type column, it treats CR2_original as a distinct file type, grouping them all together - same with JPG_original, etc., making grouping the originals for deletion much easier.