|
|
Post by BuckSkin on Sept 23, 2016 6:00:30 GMT
This is where it all began: photoshopelementsandmore.com/thread/2846/time-stamp-on-photosAt first, I was looking for blame everywhere else; however, after much investigating, I find that the Elements Organizer is to blame; so, I have started the rest of the story here. I can do whatever, whenever, in whichever program, so long as I never enter an image in the Elements Organizer, and the true exact date/time of capture will remain and carry through intact, regardless of which or how many image manipulating programs I may use, including the Elements Editor. However, once I enter images in the Organizer, a big portion, if not all, of those files will get exactly 5 hours added to the time of capture; the minutes and seconds will remain true. The Organizer will display the true time, yet file properties, Explorer, and every other program will display an erroneous time exactly five hours later than actual time of capture. This behavior is completely random and scattered throughout all folders of images that have been in the organizer; some folders display the entire group as having the five hours added; whereas, others may have two of every three images corrupted, and the next folder may contain 500 files and only three files be affected. If it were adding the five hours onto ALL files, I would simply back up the clock in the cameras five hours to compensate. This may not seem like such a big deal; but, when five hours is added to the clock, an image captured at 7:01:PM Friday the 23 of September will for now and all time to come be recorded as being taken on Saturday the 24; if these were images relied on as evidence in a court case, the discrepancy would be tough to explain. Has anyone else found this behavior in there Organizer files ? Is it restricted to earlier versions; or, do more recent versions also alter the time stamps ? Is there a fix, either by preventing the Organizer from doing it in the first place, or by changing back to true time in the metadata exif whatever ? Thanks for reading and thanks for bearing with my obsession for accuracy. I wish some software or other at the bank would start adding five thousand dollars to every deposit I made; I bet the program writers would be on that like a duck on a bug. On EDIT: I duplicated this behavior in two different desktops, each with their own version of Elements 7, both with brand new EMPTY Organizer catalogs; I started from the beginning of the process by off-loading the images from the memory card into each individual computer. Of the 600 image files involved, once renamed and numbered into Explorer, I examined every single files date/time stamp and all were perfect. I entered the files into each respective computers Organizer and re-examined the times again, at which point I discovered about 2/3 of the files to have five hours added. Thus, the Organizer is definitely the culprit. |
|
|
|
Post by BuckSkin on Sept 23, 2016 6:48:32 GMT
I found this; read all the way to the last posting where the Organizer changed his files exactly five hours EARLIER, whereas ours are exhibiting five hours LATER. He mentioned he suspected this had something to do with him being five hours offset from GMT; I live in the Central time zone but have no idea what my offset from GMT is. Here is that article : forums.adobe.com/thread/1186876Also read this: forums.adobe.com/thread/849108Note that in post #4 he pretty much says what I found in my own investigations; everything was fine right up until the images were entered into the Organizer. I notice some of these posters mention RAW files; the files I am having the difficulty with have all been jpegs; my version of Elements does not recognize/support my later version of Canon RAW. As bad as I hate to face up to it, if the Organizer insists on corrupting the time stamp in the file data, I am going to have to abandon using the organizer altogether. What peeves me is that the Organizer itself displays the true time, yet it screws things up so that no other program knows what the true time is. On EDIT : I just did a bit of research and found that my clock is five hours behind Greenwich Mean Time; thus, adding the five hours makes the affected time stamps agree with GMT; it may be purely coincidence and have nothing whatsoever to do with the problem. Empty space between ears begins to work a bit : .....If this scenario does in fact have something to do with GMT; common country boy sense tells me that my computer must be internet connected to have any inkling as to what GMT is; therefore, if I dis-connect the umbilical from the world wide web prior to and during any organizer operations, possibly the Organizer will not have any other time to work with other than the correct time provided in the original image data and maybe will not mess up the times. I am very obsessive about such things and I believe if this were happening all along, I would have caught it before now; I honestly think that this corrupted time business has only recently began messing with my files. I have had Windows updates disabled for a very long time, so I shouldn't have that to blame; yet, this has affected two computers/Organizers at the same time. |
|
|
|
Post by BuckSkin on Sept 23, 2016 8:22:19 GMT
Although it eats a lot of time that I shouldn't have to spend, I have discovered that the FREE program XNViewMP has an excellent feature that will rewrite exif data and will allow you to change date/time stamps right down to the second and select exactly which particular time stamps you wish to change.  |
|
|
|
Post by BuckSkin on Sept 23, 2016 23:28:56 GMT
Update on what I have learned so far :
This time of capture corrupting situation is prevalent over several versions of Elements and also affects some versions of LightRoom.
Like the random adding of the _TMP suffix to file names situation, there seems to be no fix for the problem and the general consensus is that Adobe does not care that the problem exists.
It is generally agreed that the amount of hours added or deducted to the time of capture is in agreement with however many hours difference there is in the Greenwich Mean Time offset one has the computer's clock set for.
I have did quite a bit of experimenting with loading jpegs into the Organizer and observing in Explorer and Fast Stone whatever changes get made to the details information after each operation performed in the Organizer. I dis-connected the internet connection during these tests to see if being connected may have had any bearing on the problem; I can say now that the problem remains even without an internet connection. I loaded several groups of files into the Organizer at different intervals and performed one task at a time while checking the outcome in Explorer and FastStone after every operation. Loading the files into the Organizer made no changes to the files during my tests. Adding keyword tags did not alter anything. Without doing File >Write keywords and properties to metadata, the keyword tags did not display in Explorer. Doing the write...to files made the tags display in Explorer and it was at this time that I saw the time of capture change exactly five hours later to random files; sometimes only 10% of the files would be affected; sometimes 90%. With every instance of using the "write...etc." command, at least one file would get the time changed and usually many files would be changed; one folder of 32 files had every file to be changed. Occasionally, I would see a file that had gained the _TMP-whatever suffix, so this problem is not restricted to adding captions. Added captions would show up in properties and other programs without using the "write...etc." command. Captions would result in about one in fifty files receiving the _TMP- suffix.
The only fix I have found AND the only program I have at my disposal that will PERMANENTLY write the correct time back into the exif data is to use the "change timestamp" tool in the FREE program XnViewMP to set the time to rights after the Organizer has messed it up. As I only ever care to know the precise moment of capture, you will notice in the screen-shot shown in my post above that I have opted to write the precise time of capture in all five available fields.
It is worth installing FREE XnViewMP to get this wonderful time-stamp tool.
The way I see it, I have my camera's internal clocks set to the exact time that I want to have associated with my images. This time gets embedded within the image file. If nobody monkeys around with it, every program that ever sees these image files are going to see the precise time of capture, right down to the hundredth of a second. This time information will stay with these image files for now and all time to come. There is absolutely no reason whatsoever for Elements to alter this information. The correct information is there; why not leave it alone ?
Please, when you guys have images to load into the Organizer or LightRoom, make note of the time-stamp prior to the Organizer ever seeing the files and then look for any changes after adding some tags and captions; the web is full of people seeking a solution to the problem and no one has found it yet.
|
|
|
|
Post by BuckSkin on Sept 24, 2016 9:23:55 GMT
Well, I may not have to give up on the organizer after all, as I found a workable solution that quickly easily corrects the erroneous time stamps. My first epiphany was that (and I may experiment with it just to see what occurs) , since the amount of time altered seems to be in agreement with the Greenwich Mean Time offset of the computer clock, whenever I planned to do the processes in the Organizer that corrupted the time stamps, I would first reset the computer's clock to exactly GMT; with no offset, then there should be no time-stamp corruption. The solution I mentioned in the opening sentence has to do with a wonderful feature in Fast Stone that, up until a few minutes ago, I did not know that it possessed. I had been using the "change date and time" command in FastStone ever since I got the program; the method I was using did not seem to be a permanent change and it seems like the next time I looked at the times, they would be reverted back to before I had thought I had fixed them. Whenever I had that time-stamp dialogue open, I had no idea that such a wonderful feature was lurking there just waiting to be turned out of it's cage. I was using the time-stamp dialogue and I happened to notice one of those little triangle buttons that, when clicked, cause a menu to flyout; I clicked the little triangle and another much more powerful dialogue box appeared. I was able to select the affected images, all of them at once, make my choice to roll the clock back by five hours using the "adjust by a set amount of time", and apply the change to the entire mess with a single click.  The wonderful EXIF time adjuster in XnView has more adjustment parameters, but is slower by far than FastStone; once set and ready, both FastStone and XnView can do an entire folder full with a single click. On EDIT: After more playing around with it, I have discovered that the XnView time adjuster DOES have the capability to rewrite times to a batch of selected images. Thanks for reading. |
|
|
|
Post by BuckSkin on Sept 25, 2016 7:16:20 GMT
Here is a screen-shot showing a folder of image files that the Organizer has randomly over-written the EXIF time of capture with a time value adjusted to agree with Greenwich Mean Time; five hours later that actual EXIF time of capture in my case. Notice that, of the 35 files visible (there are 161 in this folder), there are still five files displaying the correct time of 3:xx PM; the files displaying 8:xx PM are wrong by exactly five hours, which is my GMT offset. Although I have came up with a reasonably painless means of correcting the corrupted data, I am seriously thinking of just resetting the clocks on our computers to GMT time and leave it at that; is there any reason why I should not ?  Thanks for reading; I hope my experiences with this time-stamp business are helpful to others. |
|
|
|
Post by BuckSkin on Sept 25, 2016 19:03:51 GMT
I finally got the time-stamp scenario figured out; if one keeps after a problem, like a dog worrying a bone, after one explores enough possibles and what-ifs, they will sooner or later stumble upon a solution to the mystery.
The problem, we will call it a bug, is definitely connected to GMT (Greenwich Mean Time) and whatever offset one has programmed into their computer's clock display.
Windows calls it Coordinated Universal Time; but then, they probably do not know the significance of Greenwich and the prime meridian, longitude, navigation, and the Pennsylvania RailRoad (The Standard RailRoad of the World), standard time, and such.
The powers that be engineered a not really so desirable feature into Elements (and from what I have gathered in my quest to get to the bottom of this, many other Adobe programs, including LightRoom) that soon became bug-ridden; believe it or not, Elements Organizer will display an image's time-stamp adjusted for the time-zone one has their clock set for; so, if Aunt Isabel, who lives in San Diego, takes some pictures at 3:47 PM and sends them to cousin Sybil in Roanoke, when Cousin Sybil loads them in the Organizer, they will display in the Organizer as having been taken at 7:47 PM, although the EXIF and Explorer shows the correct time of 3:47 PM.
I discovered this when I set my computer clock to exactly GMT; six hours later in the day than good old Pennsylvania RR American Central Standard Time >>> not that Communist Daylight Savings foolishness which makes us only five hours earlier than GMT.
For my investigation, I had copied several folders of the same 100 virgin jpeg image files; these files had never been in any image cataloging or editing program other than Internet Explorer.
First, with the computer's clock still set for CDT, I loaded a folder in the Organizer, added several tags, and then wrote the tags to metadata; while Elements still displayed the correct time, it had now corrupted many of the files metadata and Explorer and ALL other programs, including Windows properties, displayed these corrupted files wrong time of capture.
Then, I set the clock to GMT and repeated my tag and write to metadata test.
When I loaded the first folder into the organizer, with the clock now set for GMT, instead of the 2:30ish time that the EXIF displayed, the Organizer was displaying 7:30ish; I thought "well, this is worse than ever"
I left it be and tagged and wrote to metadata this batch and checked what had happened to the time-stamp; the correct 2:30ish time was still there; I scrolled through the entire list and found nary a foul file.
I repeated this several times and could see no erroneous time manipulations at all.
With the Organizer still displaying these 2:30 files as 7:30, I then selected them all and performed Organizer's batch adjust time back five hours.
I was fearing that it might re-write the files to 9:30AM; but, when I investigated, all files were still displaying correctly.
So, if one is using the Organizer and finds their time-stamps are going haywire, if they will follow the following procedure exactly, a work-around is possible.
1. Set the clock for GMT and leave it there.
2. Load the images in the Organizer --- at which point Elements will adjust the displayed time equivalent to the GMT offset of the EXIF metadata.
3. Use the Organizers time adjust tool and reset however many hours it requires to agree with the actual EXIF time of capture.
; Elements should now display the time that matches the camera's time.
4. Now, you can write tags into the metadata to a fare the well and the time-stamps will remain true.
Oh, and by the way, this solution is done completely within Elements; no other programs are necessary.
Thanks for reading.
|
|
|
|
Post by michelb on Sept 26, 2016 16:09:13 GMT
Thanks for taking the time to experiment and report your findings.
I must say that I am not sure to understand all the ins and outs of the time zones managements. One of the posts you referred to showed sheer common sense: the time you want to be displayed is the one YOU want, and does not need to be GMT, your latitude or DST date...
I very rarely have such dates problems. If I have a batch of pictures taken with 6 hours lag, what is important for me is which time I was using whend taking the photos (generally set in my camera). So, whatever reason for which there is a time difference:
- I calculate the difference in hours to my target time
- I use the Organizer option to correct the time for the batch
- I write metadata to files.
|
|
|
|
Post by BuckSkin on Sept 26, 2016 19:31:42 GMT
Thanks for taking the time to experiment and report your findings. Thank you for taking the time to read through all of my ramblings. One other interesting situation that I noticed throughout this quest; I have a vast collection of image editing and image managing programs and use each of them for various features that other programs may not have or may not be as good at; of all these programs, Elements is the only one that I have ever found to replace entire files whenever you add tags or comments/captions; if you add tags to ten files in Elements, you will find those ten files in the recycle bin. Whatever tagging or captioning I may do in any of the other programs shows up immediately in the EXIF data, yet the images don't end up in the recycle bin. One lesson I learned throughout this debacle; set the clock for GMT and get in the habit of using a different clock to tell the time. |
|
|
|
Post by Sepiana on Sept 26, 2016 19:55:35 GMT
I have a vast collection of image editing and image managing programs and use each of them for various features that other programs may not have or may not be as good at; of all these programs, Elements is the only one that I have ever found to replace entire files whenever you add tags or comments/captions; if you add tags to ten files in Elements, you will find those ten files in the recycle bin. Whatever tagging or captioning I may do in any of the other programs shows up immediately in the EXIF data, yet the images don't end up in the recycle bin. BuckSkin, You may find the explanation in John R Ellis' FAQs. Photos appear in the recycle bin unexpectedlyAs a side note . . . I have been using the Organizer since Adobe revamped it in Elements 11. (I had used it before in Elements 4 but skipped it in Elements 7 and 10.) I have never had any problems with the "time" as the ones you describe. I am not really ready to declare the Organizer to be the culprit. I don't use any additional third-party image management software. I let the Organizer do its job (the same way I let Lightroom do its job). I wonder if this makes a difference. I remember some reports on such problems on the Adobe forums; they seem to involve the OP bringing third-party programs into the mix. |
|
|
|
Post by BuckSkin on Sept 27, 2016 1:40:34 GMT
I have a vast collection of image editing and image managing programs and use each of them for various features that other programs may not have or may not be as good at; of all these programs, Elements is the only one that I have ever found to replace entire files whenever you add tags or comments/captions; if you add tags to ten files in Elements, you will find those ten files in the recycle bin. Whatever tagging or captioning I may do in any of the other programs shows up immediately in the EXIF data, yet the images don't end up in the recycle bin. BuckSkin, I wonder if this makes a difference. I remember some reports on such problems on the Adobe forums; they seem to involve the OP bringing third-party programs into the mix. Thanks for the John R. Ellis link. The first stop for the majority of our images is usually the organizer before any other program gets a chance to have any influence on them. |
|
|
|
Post by BuckSkin on Sept 27, 2016 3:05:48 GMT
I found this on the John R. Ellis site :   |
|
|
|
Post by Sepiana on Sept 27, 2016 3:15:24 GMT
That's interesting! But, as he says, . . . it is a "sometimes" occurrence. Also, I don't use other "tools". This (and some luck) may explain why I have never encountered this problem.
|
|
