Change Timestamps fails after file without exif date
Posted: Mon Aug 11, 2014 9:22 am
As the title says. My typical workflow is to copy all photos from the iOS device to the Windows computer, then batch process their size/resolution, then change timestamps with all files at once. CT is used with Exif date as reference to set everything else.
Now there are 50 photos. The first 10 are true photos from the iOS device, jpg with Exif data. These are processed.
Then come two png - screenshots I made from a Skype conversation (look like photos...).
The bug: the function Change Timestamp will indicate that it processes all remaining 40 files, and also needs the same time as if it does real processing. But in reality nothing is done. So all files after the two pngs are not processed, and the function does not tell the user anything unusual. (Maybe they are processed but the date is set wrong...didn't check that).
So I mark only the remaining 38 and start Change Timestamps again. Unfortunately file 19 and 20 are JPGs that XnView says have EXIF, but they do not have any time information in there. Also the fields for that seem missing. That sort of files shows up when someone sends iMessage, or sends via Skype, Line or Facebook and then stores the pic to the Camera Roll. As the function can not read any Exif date it fails in the same way as described above under bug - the remaining 30 photos are unprocessed (or set to the wrong -current- date).
This bug is quite old, I stumbled over it when videos are selected as well. Each video file will break the sequence, so I learned the workaround to filter only images, select all, then use that function.
The reason that I described the bug in detail is to show that today it gets more and more cumbersome to work around the bug. A fix seems unavoidable. It takes too much time to sort out all the incompatible files first, then run the function over the rest. XnView should just jump over the not processible file and continue correctly with the next one. And might even inform the user that a file could not be processed...
Now there are 50 photos. The first 10 are true photos from the iOS device, jpg with Exif data. These are processed.
Then come two png - screenshots I made from a Skype conversation (look like photos...).
The bug: the function Change Timestamp will indicate that it processes all remaining 40 files, and also needs the same time as if it does real processing. But in reality nothing is done. So all files after the two pngs are not processed, and the function does not tell the user anything unusual. (Maybe they are processed but the date is set wrong...didn't check that).
So I mark only the remaining 38 and start Change Timestamps again. Unfortunately file 19 and 20 are JPGs that XnView says have EXIF, but they do not have any time information in there. Also the fields for that seem missing. That sort of files shows up when someone sends iMessage, or sends via Skype, Line or Facebook and then stores the pic to the Camera Roll. As the function can not read any Exif date it fails in the same way as described above under bug - the remaining 30 photos are unprocessed (or set to the wrong -current- date).
This bug is quite old, I stumbled over it when videos are selected as well. Each video file will break the sequence, so I learned the workaround to filter only images, select all, then use that function.
The reason that I described the bug in detail is to show that today it gets more and more cumbersome to work around the bug. A fix seems unavoidable. It takes too much time to sort out all the incompatible files first, then run the function over the rest. XnView should just jump over the not processible file and continue correctly with the next one. And might even inform the user that a file could not be processed...
