ACDSee Pro

Back to Topic OverviewPost New Reply

Date time original/digitized

(25 posts)
1 2

  • Sam Dring
    Moderator

    A member reports and I confirm that Pro2 shows dates differing (for me) by an hour (for the member there are, apparently greater differences).
    I have tested these dates against one or two other apps AND against other ACD versions.
    For me and I suspect some others, this would be a very significant bug.

    Posted On September 10, 2007 - 03:48 AM (2 years ago) (Permalink to this post)

  • Tankred
    Moderator

    No doubt, that would be some very nasty bug! Is it possible that this is somehow related to the time zone?

    Posted On September 10, 2007 - 04:44 AM (2 years ago) (Permalink to this post)

  • Sam Dring
    Moderator

    That was my first thought also but it is not consistent. Just tried a new image taken this morning and date time was reported correctly.
    It may, of course, have been fixed in the release version although the OP seems to say that this is in the final version.

    Posted On September 10, 2007 - 04:58 AM (2 years ago) (Permalink to this post)

  • Sam Dring
    Moderator

    I have done some more checking and I don't think it is a Pro2 issue. I think what is happening (and why do we have SO many date time groups - original, digitised, camera) is that Adobe products are compensating for time zone? More work to do.

    Posted On September 10, 2007 - 10:09 AM (2 years ago) (Permalink to this post)

  • Chippy
    Moderator

    Sam,
    Marc mentioned in the original thread, about Adobe Converter maybe doing strange things.
    I use Downloader Pro, and writing a DNG automaticlly, as it is downloading, so they all go into one folder.
    As of this afternoon. all files have the same time stamp.

    The only time I have seen a change, is if the file is edited.
    Will experiment more, now I have the Pro 2-219, as you say, I have not seen this happen with ACDSee.

    Posted On September 10, 2007 - 06:02 PM (2 years ago) (Permalink to this post)

  • Chippy
    Moderator

    Investgating further,
    I have gone over past images that were cataloged before the final release of Pro 2.
    All time stamps were the same, including DNG.
    Now however, when converting PEF (Pentax) with Adobe DNG converter, using Downloader Pro,the date changes by 7 hrs , in my case, on the DNG file, although other software show the correct time with both files.
    So, I took Marc's advice in another thread, and just D/L the images, without the conversion, and had Pro 2 write an XMP file. Then converted with Adobe DNG, and the time stamps were the same.

    So then I tried with NEF (Nikon), using the same system with Downloader Pro, and the DNG recorded the same time as the NEF.

    So, could it be camera specific?
    Sam, does Canon report the same date, as well as Nikon? But Pentax is doing something?

    Or has something been changed between the beta and release version of Pro?

    Posted On September 18, 2007 - 07:40 PM (2 years ago) (Permalink to this post)

  • Marc Sabatella
    Moderator

    Chippy said:

    Or has something been changed between the beta and release version of Pro?

    This much does seem to be true. I'm still not sure about much here.

    Posted On September 19, 2007 - 12:55 AM (2 years ago) (Permalink to this post)

  • Sam Dring
    Moderator

    Chippy said:

    Sam, does Canon report the same date, as well as Nikon?

    I know Mark has said in the main thread that this is being investigated but I find the issue fascinating. With exiftool I can find no marker to show time offset from GMT in the original raw but when I involve Adobe the results (dng or LR conversion) produce a DTG appropriate to GMT. How does it know I am on British Summer Time? Curiouser and curiouser

    Posted On September 19, 2007 - 02:34 AM (2 years ago) (Permalink to this post)

  • Marc Sabatella
    Moderator

    samdring said:

    How does it know I am on British Summer Time? Curiouser and curiouser

    Windows knows your time zone, and Adobe products consult Windows for this information.

    Posted On September 20, 2007 - 05:03 PM (2 years ago) (Permalink to this post)

  • Sam Dring
    Moderator

    Marc Sabatella said:

    Windows knows your time zone, and Adobe products consult Windows for this information.

    I'm gobsmacked - Adobe will soon, no doubt, be suggesting a golf-style handicap rating based on DOB - Not a bad shot for an old 'un </forums.acdsystems.com/style_emoticons/<#EMO_DIR#>/smile.gif" style="vertical-align:middle" emoid=":)" border="0" alt="smile.gif" />

    Posted On September 21, 2007 - 02:45 AM (2 years ago) (Permalink to this post)

  • Sam Dring
    Moderator

    Connie
    I wonder if you could find out please whether or not we should be altering our Date time groups. If there is a patch due shortly and/or if any such patch would then compromise any manual alteration making it an hour wrong (for me) the other way, would be useful information for myself and to post on the forum.
    I did a wedding last weekend and the second camera was on jpeg (which, interestingly LR did not change!) and then to sort the proofs in time order without modifying the originals, was a lot of labour I could have done without.

    Posted On October 2, 2007 - 01:43 PM (2 years ago) (Permalink to this post)

  • Marc Sabatella
    Moderator

    I too am anxiously awaiting word - I've basically stopped processing photos until I know what's going on. Well, not completely stopped, but I'm holding off on my final archiving. For new pictures I'm taking, I am using the workaround I mentioned of generating XMP files first then converting to DNG, which suppresses the generation of time zone informatin and thus solves my problem. But I've the better part of a year's worth of converted DNG's that already have time zone info, and I am holding off on getting everything fully set up on my computer until I am sure of what is going on.

    I really really REALLY hope the answer is that a patch is forthcoming that would make the default behavior what we all seem to agree we expect it to be - local time is used. That should go for the display as well as any operations that use the EXIF date (sorting, setting database date to be EXIF date, etc). If they want to add an option to use time in GMT, that's fine, but as far as I'm concerned, I'd be just as happy without that capability - I doubt I'd ever use it.

    Meanwhile, I certainly *could* run a batch operation or two to reset the times. I'd have to do some experimenting to figure out what parameters to use to get the local time stored without the time zone - I don't really want to modify the files to claim they were shot 7 hours earlier just to get ACDSee to deal with the time as expected. But this would probably be a fair amount of work, as I'd have to identify which files had the problem, which were off by 7 hours and which were off by 6 (daylight savings time differences).

    Actually, perhaps the most elegant solution would be to figure out the right set of parameters to give ExifTool so that it would *copy* one of the the fields without the time zone info into the one field that DNG Converter modified (I think that was the XMP version of date/time digitized). I think this would always product the correct result, even on files that DNG Converter had not modified. Actually, it might well work to simply delete or clear out that field - it's not like there aren't a dozen other places where the time is recorded in the file. I don't have time to test this right now, but may do so later.

    Posted On October 2, 2007 - 02:37 PM (2 years ago) (Permalink to this post)

  • Marc Sabatella
    Moderator

    Marc Sabatella said:

    Actually, perhaps the most elegant solution would be to figure out the right set of parameters to give ExifTool so that it would *copy* one of the the fields without the time zone info into the one field that DNG Converter modified (I think that was the XMP version of date/time digitized).

    OK, I've been fooling around with this. I tried using ExifTool to copy the unadulterated EXIF:DateTimeOriginal to XMP:DateTimeDigitized and XMP:ModifyDate, which are the two fields that the DNG Converter creates and adds the time zone info to. As far as ExifTool is able to tell me, the end result of this is that all time-related fields are set to the same value: the local time. Actually, ExifTool explicitly appends "Z" to the XMP fields it updates, which I gather is kosher - it should have the effect of telling other applications not to apply any time zone adjustment when displaying this time.

    Unfortunately, ACDSee still insists on showing me Date/Time Original in GMT, although all other times are now reported as local time. It seems something is still telling Pro 2 it should apply the time zone to this field only, but I can't imagine what. Plus the database date is still showing the time in GMT if the file had already been cataloged. I have no idea why Date/Time Original would be reported in GMT in this case, but since I need to fix the database date anyhow, I can actually fix both at once, by running Batch Set Information with a preset that copies the camera Date/Time to both Database Date and Date/Time Original. I do have to run the ExifTool command to eliminate all traces of time zone info in order for this to work - if even one field has time zone info in it, ACDSee will apply it to all times, it seems. But for what it's worth, this two-step process does appear to set everything right, and should, I think, not screw things up if/when ACD releases a patch for this. But I'm *still* waiting for some sort of word from ACD. I've really been dead in the water for several weeks now.

    BTW, as I browse around my image catalog, I see all sorts of JPEG's I shot that also have time issues. Some of these were clearly a result of my having the wrong time set in my camera (not toggling daylight savings time, etc). Some are off by 6-8 hours, though, which is probably the range of differences between my local time and GMT. These are all files that would have been written with Batch Set Information around the time I installed the final version of Pro 2. I hadn't intended to alter the time stamps, of course, but it certainly seems possible that something may have gone wrong with some to these files, too. On the other hand, I'm willing to accept the possibility of user error.

    Posted On October 8, 2007 - 05:41 PM (2 years ago) (Permalink to this post)

  • Marc Sabatella
    Moderator

    On further experimentation, and realization that after having previously run Batch Set Information on my DNG, the GMT-corrected version of the time has actually now been copied into *all* relevant fields, it seems my best fix is to run Bacth Adjust Time Stamp to subtract the appropriate number of hours from the database date, then Batch Set Information to copy the db date to the various EXIF fields. I've been holding off on actually doing any of this because I kept hoping to hear some sort of word from ACD, but I've gone ahead and done this for all of my DNG images for the year (and I only started shooting DNG regularly this year) and all seems well. Meanwhile, for all new images I've shot for the last couple of months, I've been continuing to apply my workaround of running Batch Set Information before the DNG Converter to prevent the time zone info from being incorporated into the DNG file in the first place. In general, I like this workflow well enough that I'm liekly to keep doing this even if it becomes unnecessary after the next patch release. But I do wish I could figure out an easier way to run the DNG Converter on an entire folder full of files. Invoking it from as an external editor only works for up to 29 files at a time. Edit Image is not avalable for folders. Invoking the converter from the Favorites folder does not pass in the name of the current folder. So I end up selecting a single file in the folder, invoking the converter, and then, before the converter actually runs, telling it to actually go ahead and do the whole folder. More awkward than I'd like, but it works.

    Posted On November 6, 2007 - 09:28 AM (2 years ago) (Permalink to this post)

  • Sam Dring
    Moderator

    Mark
    I am still holding off in case the patch causes any corrections I make to need correction again or do you not think that will happen. I just wish we had news of what (and when) is likely to happen.

    Posted On November 6, 2007 - 09:50 AM (2 years ago) (Permalink to this post)

  • Marc Sabatella
    Moderator

    samdring said:

    I am still holding off in case the patch causes any corrections I make to need correction again or do you not think that will happen. I just wish we had news of what (and when) is likely to happen.

    I too wish we had word. But I am in the midst of a major web site redeisgn and really want to resume normal work with my pictures, plus I really to get proofs of everything onto my wife's computer so she can browse around whenever she wants. Basically, I got tired of waiting around.

    I am hopeful that any patch would not break what I have done. Really, I am bringing all of my DNG files to the same state as my straight-from-the-camera JPEG and PEF files: all time-related fields are set to local time with no time zone info appended. Actually, there is one difference: the XMP versions of the fields have the letter "Z" appended to the times, theoretically indicating that these these times actually are GMT, even though they aren't. That is, if I shot at 9:00 AM local time, the EXIF fields read 09:00:00, but the XMP fields read 09:00:00Z. So I suppose it is possible that a patch that forces ACDSee to display time as local might cause it to read 7 hours *earlier* for me (9:00 GMT is 2:00 Mountain time). But I'm guessing this won't happen - either it will display as I expect by default, or there will be options. And the worst case scenario is, I make corrections again later. And at least my database times are correct now so whatever I need to do should be even more straightforward. And it didn't take that long as it was - just a few minutes of my time, plus another hour or so of computer processing time, to fix a year's worth of photos. So I'm not so concerned about having to do it again. I do plan on holding off on burning "permanent" DVD backups until I see if I need to do anything else.

    Posted On November 6, 2007 - 02:06 PM (2 years ago) (Permalink to this post)

  • Sam Dring
    Moderator

    Found a major issue for me arising from Date Time Group (DTG). I use Lightroom for processing and yesterday I upgraded to the new version 1.3. On loading I noticed that the indicator which shows whether or not LR database matches the image metadata was showing false for many files.
    My mistake was to assume that LR was not up to date (Pro2 is my dam) and to resolve the meta conflict by overwriting LR.
    I did this at folder level for a couple of hundred files and got:
    </i201.photobucket.com/albums/aa181/samdring/2007-11-17_130435.jpg" border="0" class="linked-image" />
    My date ranges as can just be seen, were from the year 1617 to 3047 with dates conflicting even on the same image.
    My second mistake was to assume that LR new version was at fault and start a lengthy post (and email exchange with Peter Krogh) not blaming LR but certainly asking others to take care on update.
    However, the following screen dumps from exiftool may well point the problem towards the issue which this whole thread adresses. (The first 3 lines are exif and the latter 2 are xmp)

    </i201.photobucket.com/albums/aa181/samdring/2007-11-19_090431.jpg" border="0" class="linked-image" />

    </i201.photobucket.com/albums/aa181/samdring/2007-11-19_090757.jpg" border="0" class="linked-image" />

    </i201.photobucket.com/albums/aa181/samdring/2007-11-19_091522.jpg" border="0" class="linked-image" />

    On adding iptc keyword, notice that the seconds have been stripped

    </i201.photobucket.com/albums/aa181/samdring/2007-11-19_091739.jpg" border="0" class="linked-image" />

    Results of that in exiftool

    </i201.photobucket.com/albums/aa181/samdring/2007-11-19_092335.jpg" border="0" class="linked-image" />

    Sorry for the number of images but it may help. However, the effect of all this is that I now have to remember to tell LR to overwrite all meta conflicts. Am happily(!) working my way through the mass of changes required. These problems are not only manifest in Adobe products but in other apps as well. The leading '0' before the zulu renders the date unusable in 2 other apps I have.

    1. Any news of when the bug will be fixed please.
    2. For anyone using dng converter and subsequently iptc in Pro2, it appears no longer to be the case that Pro2 is just reading DTG incorrectly, it appears to actually scramble it. This is OK-ish for people who solely use Pro2 but if they ever migrated....
    3. Connie - if all the above is true, how do we tell the troops?

    Posted On November 19, 2007 - 03:50 AM (2 years ago) (Permalink to this post)

  • Sam Dring
    Moderator

    Well I am truly confused.
    I happened to add a second iptc keyword to the rogue file shown above and on importing again into LR the DTG no longer shows 1813 (or whatever year it was) but the correct date and time apart from the seconds which stay stripped out at '00' in the above example.
    I have now done this a few times with fresh images; downloaded and converted to dng; imported to both Pro2 and LR (no problems); added keyword in Pro2; all mayhem in LR; added another keyword and DTG apart from seconds shows properly. Other apps also show correct DTG (less seconds) following second keyword entry.
    There is no wonder I could not find a pattern yesterday - could not be expected to remember which images had one and which had more than one metadata entry done in Pro2!

    Posted On November 19, 2007 - 12:08 PM (2 years ago) (Permalink to this post)

  • Marc Sabatella
    Moderator

    My date ranges as can just be seen, were from the year 1617 to 3047 with dates conflicting even on the same image.

    Very odd. If I am following you correctly, you are saying the extra "0" added before the "Z" in the XMP info is what is causing LR to behave in this way, and that other applications are also confused by the extra "0"?

    I can certainly verify that there are situations in which running using ACDSee and the Adobe DNG converter will result in the seconds being stripped out, and also situations in which you can end up with a three-digit seconds field. And of course, situations in whih the time zone info is appended, and also situations in which the time is converted to GM and stored as Zulu time. But it seems the results differ according to what order you do in things in. I'm still confused enough about what the standard actually say and about what other applications may be expecting that I can't tell what's right and what's wrong. I can simply agree that the default behavior appears quite counterintuitive, and there does not appear to be enough control over the results.

    I would also say that whenever this mess does get straightened out, I very much hope there is a fairly detailed explanation included with any patch release to help people understand what is going on so they can fix anything that needs fixing in their existing images already processed with Pro 2, and understand what changes in their workflow might be in order.

    1. Any news of when the bug will be fixed please.

    Seems I recall hearing a date of November 19 as the projected "2.1" release date. This obviously didn't happen, but I hope perhaps it is close?

    Posted On November 25, 2007 - 11:17 AM (1 year ago) (Permalink to this post)

  • Sam Dring
    Moderator

    Marc
    Thanks for your reply and interest
    Very odd. If I am following you correctly, you are saying the extra "0" added before the "Z" in the XMP info is what is causing LR to behave in this way, and that other applications are also confused by the extra "0"?
    Yes I think that Pro2 is translating the DTG offset by adding that zero but I also have little idea what the correct convention is. However, when I sorted some of the rogue images, the following results showed in exiftool

    </i201.photobucket.com/albums/aa181/samdring/2007-11-18_111014.jpg" border="0" class="linked-image" />

    Images that have not had modification (keywords etc) in Pro2, show the +00:00 or +01:00 as appropriate for my time zone.

    Hope you are right that the fix is on its way

    Posted On November 25, 2007 - 11:49 AM (1 year ago) (Permalink to this post)

Subscribe to this topic via RSS

1 2

Reply »

You must log in to post.