exiftoogui v. 4.16.0.0, exiftool v. 8.60, win xp sp2
Sorry I am peppering you with bugs and suggestions, but the best time to do this is when one is a relatively new user.
In order to correct for my losing camera without orientation sensor, I used exiftoolgui to set the exif orientation tag. Then, I used exiftoolgui to autorotate those files. Although I have the option "preserve modified date of files" set, the modified date is nevertheless changed to the current time of the operation.
This is no doubt due to the fact that jpegtran changes the modifed date of the file. In fact, the only reason I was using exiftoolgui to do this, rather than jpegtran directly, was to avoid this issue, since I did not see a jpegtran option to revert the timestamp. I guess if you want to take care of it, you will have to remember the file timestamp, run jpegtran, and then reset the timestamp afterwards.
It may also be useful to know that besides the jpegtran that the exiftoolgui distribution (.zip) puts into its own directory, I also have jpegtran v. 6b installed, and in my path. My exiftoolgui version appears to have jpegtran v 8b, on the other hand. I mention this because I'm not sure that exiftoolgui is guaranteed to run its own jpegtran in this environment, and if not, then the problem may be coming from the version I have in my path. (In that case, the bug would be that exiftoolgui should only run its own version of jpegtran that is in the exiftoolgui directory, if it exists.)
I guess there is also another issue to consider, and that is whether the jpegtran operation was reversible, i.e. both image dimensions were multiples of 8. In the case where it is not reversible, I can see an argument for modifying the timestamp of the image, though in my case I personally would still leave it unchanged. However, in such a case it might pay to at least warn the user that the change will not be reversible if they are rotating in place and not keeping backups. (Maybe you already do that, I don't know, because I think all my files have multiple of 8 dimensions.) That would be especially insidious if the timestamp were left intact, so it might pay to remind the user.
I should add one more point about this, which is actually a separate bug or feature request, depending on point of view.
Namely, after all the rotations are finished, the file list display does not automatically refresh, thus showing the original timestamps rather than the new ones. This can lead to the user not noticing what has happened until much later (not just for timestamps, but for anything else which is not refreshed in that pane). I can see a performance argument to not refresh automatically, although you do appear to do so when one is viewing "about image" rather than "standard", which has a much larger performance penalty.
Meanwhile, I do not see any way to manually get exiftoolgui to refresh the file listing, other than perhaps moving around the file tree. However, some programs cache directory information, and a user would have no way of knowing whether exiftoolgui were doing that, and therefore no certainty that moving around the file tree did result in a re-read of directory info. So, unless I simply failed to find it, a "refresh" option somwhere would be a welcome addition.
Conversely, as I mentioned, there is a big performance penalty when exiftoolgui automatically refreshes an "about image" listing on a directory with thousands of images (or, obviously, any listing where it has to open and read each file). It might therefore be useful to let the user disable this, possibly with an indication that the listing might be stale. (If you want to do some fancy coding, you could immediately refresh only those files that are currently being displayed, and work on the others in the background, changing your queue if the user changes what is in his current pane.)
About AutoRotate.. because it's not supported by ExifTool (with a reason, IMO -but that's off topic), I see it just as "extra feature" -meaning, I don't plan to spend much time with that in future.. it simply isn't "worth" (that is, Orientation tag should be used instead). Saying that, I don't plan to work on 8bit boundary when rotating JPG images. Btw. from what I know, every straight from camera JPG conforms 8bit boundary.
jhead/jpegtran doesn't support preserving Date modified of files. But to give you at least something, in next GUI version Autorotate will be a bit "enhanced": If option Preserve Date modified.. is checked, then DateTime from Exif will be used for file Date modified, having following priority:
DateTimeOriginal
ModifyDate (is used if above doesn't exist)
CreateDate (is used if above doesn't exist)
If none of above exists, file Date modified will change to "today" date.
Refreshing filelist pane
-in next GUI version, if AutoRefresh.. is checked, then filelist will refresh regardless of Details state. In addition to this, Refresh button is added on filelist pane (for use in cases when AutoRefresh is unchecked).
If you have more than one jhead/jpegtran file, then they are used as specified by Microsoft. From GUI perspective, priority is as follows:
1. if file exist in the same directory where GUI is, then that file is used.
2. try to find file in system directory.
3. try to find file in Windows directory.
4. try to find file by using environment variables.
As written in GUI manual, I recommend copying jhead/jpegtran files to Windows directory (which should prevent having multiple versions of the same file in system).
That's it.. hopefully I didn't forget something important.
Bogdan
PS: be carefull when using a lot of files for AutoRotate -jhead/jpegtran don't support "limitless" file selection.
Thanks for all the improvements.
I'm a little bit uneasy about how you plan to handle date modified with jpegtran, though. I am worried that it will be mysterious as to how the date changed, and the user might not realize exactly what happened. For example, my practice is that if I modify the actual content of an image (for example, by cropping), then I allow the filesystem modified date to be the date I actually modified the file. But, if I only add/change something to/in exif, or rotate an image to correct for camera/viewer stupidity, then I leave the file modified date as it was originally. Usually, the original filesystem file modified date is almost the same as the exif dates (which tend to be when the file was first created in the camera, but the camera might not finish processing for a couple of seconds, so filesystem date might be a second or two later). So, using what you propose to do, an image file that I rotate that was not modified will end up with (approximately) the right timestamp, but an image that I have modified will end up with a wrong timestamp. Since the latter are rare -- because I don't usually do things to images until they are properly rotated for display -- I might not notice this until a month later, by which time it will be too late to correct it.
My suggestion would be to alert the user that you are going to use exif date to change the filesystem date in such cases. 99% of the time it will be the right thing for me, and also I think for other users, but the remaining 1% could be frustrating if one doesn't know it is happening.
I discovered that irfanview has a jpegtran plugin which allows lossless jpeg rotations, and he also has an option to preserve the modified timestamp of the file. Therefore, for me it is no longer important whether exiftoolgui preserves the filesystem modified timestamp, since I can instead do that operation with irfanview. You might want to reconsider whether to go to the trouble of coding the copying of various exif fields into the filesystem modified date in the "preserve" mode. However, I would then advise a user alert when jpegtran is used that tells the user that the filesystem timestamp will not be preserved.
I understand. In next update user will be notified, that Exif DateTime is used to "preserve" file Modify date. Thanks for suggestion.
Bogdan