Batch file that resets orientations and deletes thumbnails alters file sizes slightly even if no real change occurred

[Erik Maher]

This is an informational note for anyone who runs file synchronization software and also uses ExifTool.

Let's say you have a folder containing an assortment of different file types and you create another folder as a backup. Then you run exiftool commands to change the orientation of image files to horizontal and to delete any thumbnails on the first folder. You would expect the two folders to no longer be identical. However, you would not expect (or at least I did not expect) that ExifTool would slightly modify files even if it made no apparent change to a file. For example, you run commands on foobar.jpg to change the orientation to horizontal and delete thumbnails, but foobar.jpg was already oriented horizontal and already had no thumbnails. Then, you run file and folder synchronization software, the source file and destination file show a mismatch, you open both of them up in your favorite file manager, and the two files both look identical, but the software keeps telling you that they are different somehow. You look deeper and discover that the file sizes are ever so slightly off. Often it is only a fraction of a KB difference (say, 50.22 KB versus 50.12 KB). The solution is simply to run the same ExifTool commands on all the files in the backup folder.

From experience, I've discovered that when I run the orientation changing and thumbnail deleting commands on files that already had my desired characteristics, ExifTool increases the size of PNG files slightly whereas it decreases the size of JPG files slightly, with no harm done to any files. They still open and appear the exact same as they did before. I consider it a personality quirk of ExifTool rather than as a bug; ExifTool is altering the file header somehow without making any changes to the file contents.

I use Araxis Merge as my file and folder sync software (for 20+ years). The clue that files have real changes and not these phantom ExifTool changes is that if you have real changes, you will see a discrete integer in the changes column such as 2 or 5 or 17. The phantom ExifTool pseudo-changes appear as dozens of dozens of files showing an ambiguous >1 in the changes column (in other words, Araxis Merge knows something is different, but for whatever reason, can't define what is different and can't tell you how many changes there are, so it responds with "greater than one"). Once you run the ExifTool commands on the backup or destination folder and re-run Merge, the phantom changes disappear and you will see the narrowed-down list of files that have real changes.

When I import photos from my phone, I typically run ExifTool immediately. I then open the photos in FastStone Image Viewer (where I have the setting "Auto-rotate by EXIF orientation tag" unchecked) to check for any photos that are oriented wrong and losslessly rotate them using Ctrl-Alt-L or Ctrl-Alt-R. For reference, here is the batch file I use with my notes inserted at the start to remind myself of this peculiarity with ExifTool:

@echo off
echo.
rem Reminder for myself: For some reason, exiftool changes most file sizes slightly.
rem This occurs even if the file is not a JPG or JPEG, and even if it doesn't rotate the file or clear thumbnails.
rem Typically, but not always, PNG files increase slightly in size, and JPG or JPEG files decrease slightly in size.
rem I haven't found any difference in the appearance or usability of any files after this slight change.
rem To ensure that Araxis Merge treats folders as identical, run the batch file on source and destination.
echo Checking the original image file orientations...
echo Press any key to proceed.
pause > nul
exiftool -orientation . -r
echo.
echo Checking for thumbnails...
echo Press any key to proceed.
pause > nul
exiftool -preview:all . -r
echo.
echo Changing all orientations to horizontal...
echo Press any key to proceed.
pause > nul
rem The following command changes the orientation of all photos to normal horizontal.
exiftool -orientation=1 -n -m -P -r . -overwrite_original_in_place
echo.
echo Deleting any thumbnails...
echo Press any key to proceed.
pause > nul
rem The following command removes all thumbnails (if any) from the photos.
exiftool -thumbnailimage= -m -P -r . -overwrite_original_in_place
rem The -m ignores minor errors or warnings.
rem The -n turns all orientation values to numbers or extracts coordinates as signed (+ or -) decimal degrees.
rem The -P preserves the file modification date.
rem The -r (recursive) processes subfolders.
rem The . (space dot space) processes all files in the current folder.
rem -overwrite_original_in_place prevents creation of .jpg_original files.

[StarGeek]

For example, you run commands on foobar.jpg to change the orientation to horizontal and delete thumbnails, but foobar.jpg was already oriented horizontal and already had no thumbnails

You are running a command that changes the Orientation and ThumbnailImage. It doesn't matter that it is changing it to the exact same thing, you are still ordering exiftool to edit the files. The file sizes change due to FAQ #13, Why is my file smaller after I use ExifTool to write information?.

If you don't want to rewrite those files, then you have to use the -if option to skip those files

I think this will work (change to single quotes if on Linux/Mac)
-if "not $Orientation or $Orientation#!=1 or $ThumbnailImage"

Breakdown: not $Orientation checks to see if the Orientation tag doesn't exist.

$Orientation#!=1 checks to see if the raw value of Orientation is not equal to 1.

$ThumbnailImage checks to see if ThumbnailImage exists.

If any of these conditions are true, then exiftool will rewrite the file, writing Orientation with the raw value of 1 and removing the ThumbnailImage.

ExifTool increases the size of PNG files slightly

In this case, it's likely that exiftool is creating the EXIF block in the PNG file. PNG files rarely have EXIF data in them.

[StarGeek]

Looking further at your script, I didn't catch that you were running two separate exiftool commands. You can combine both of these edits into a single command so you don't have to make two passes over the files. Adding in the -if option, the result would be something like this:

exiftool -if "not $Orientation or $Orientation#!=1 or $ThumbnailImage" -thumbnailimage= -orientation=1 -n -m -P -r . -overwrite_original_in_place

Since you seem to be running the command on Windows, I would also suggest that you use -overwrite_original option instead of the -overwrite_original_in_place option. On Windows NTFS, there's no reason to use -overwrite_original_in_place unless the file has an ADS (Alternate Data Stream) attached to it. Using -overwrite_original_in_place doubles the amount of processing time, because exiftool creates the edited file, and then opens the original and copies the contents of the edited file back into the original file. With -overwrite_original, exiftool creates the edited file, deletes the original file and renames the edited file to the original name.

The main use of -overwrite_original_in_place is on a Mac file system, because Finder attributes (XAtt* and MDItem* file properties) will be lost by the -overwrite_original process.

See also FAQ #31, "Why does ExifTool rewrite the entire file when I am only changing one small thing?".