Controlling the Timeline from Media Pro

[jsrunnels]

Okay. I am still (frustratingly) trying to move over from Media Pro (MP) to PhotoSupreme (PSu). The program is crashing all the time and sending a zillion exceptions, so I am pretty depressed about that, but eternal optimist that I am, I am hoping that will settle now whenever I upgrade to Catalina.

Right now I am trying to figure out what the heck is going on with the Timeline. Where is PSu getting the dates for that function?? It seems to be creating and then using the import date/time for a large number of the files. I cannot tell what is going on.

I use MP to catalog my family photos, but I have slides/scans/etc going back to the early 1900's. In addition, most casual photographers were terrible about setting their camera dates so there were discrepancies even once most of the pictures are digital.

MP has a "Date Finder" function that I have invested a loooooooot of time into to organize the photos chronologically. Is there a way to export whatever that field is and map it onto PSu's Timeline? Is there a way to automate it at all. I have spent the last several hours trying to do this by hand and it is erratic, unreliable and takes forever. It just won't do for my 42K of images....

I am really struggling with PSu, but feel like it is so so close to being what I need (if I can ever get past all the crashing and stalling), but this is really, really frustrating me to no end.

Thanks in advance to anyone with any insight.

[Hert]

That is the photo date. The Photo Date is determined as follow:

1. If XMP Exists:
1a. Is there a exif:DateTimeOriginal? Then use it. If not
1b. exif:DateTimeDigitized exists? If not
1c. tiff:DateTime

2. If no XMP exists (yet) but Exif exists then:
2a. Date/Time original exists? If not then
2b. Date/Time digitized exists? If not then
2c. Tiff base date exists?

3. If *no* XMP and *no* Exif exists then
3a. Use the File Date/Time stamp modified; this is the most reliable because the OS changes the creation date when the file is copied or moved. but it won't change the modified date

[jsrunnels]

Okay. That makes sense. It sounds like I am out of luck unless I change the DateTimeOriginal by hand in all of my images that are scans (or otherwise in error). :/

Thanks so much for the clear answer.

Anyone here have any idea how to do that as a batch...?

If there was a programmer up for a tiny challenge --- all my files are named like so: YY-MM-DD HH-MM-SS.jpg based of the DateTimeOriginal (where it is known/correct) and YY-MM-DD somethingelse.jpg or YY-MM something else.jpg (where it is a scan or incorrect). Any way to script either PSu or my Mac somehow to write in appropriate DateTimeOriginal (for ones that are incorrect) or DateTimeDigitized (for scans) as a batch function...?

Regardless, thank you again, Hert for the explanation.

[Hert]

Here's a script that you can use.

Use with care, and try it on a few images first. Feel free to change it to your needs.

Code: Select all

  function DateStringToDateTime(ADateString: WideString): TDateTime;
  var
    ATokens: TTntStringList;
    ys, ms, ds, hs, ns, ss, msecs: WideString;
    y, m, d, h, n, s, msec: Word;
  begin
    result := 0.0;

    ys := ''; ms := ''; ds := ''; hs := ''; ns := ''; ss := ''; msecs := '';
    y := 1899; m := 1; d := 1; h := 0; n := 0; s := 0; msec := 0;

    ATokens := TTntStringList.Create;
    try
      Tokenize(ADateString, '-', ATokens);
      if ATokens.Count >= 1 then
      begin
        ys := ATokens.Strings[0];
        if not IsValidIntNumberString(ys, False) then
          exit;

        if Length(ys) = 2 then
        begin
          if StrToInt(ys) < 20 then
            ys := '20' + ys
          else
            ys := '19' + ys;
        end;

        y := StrToInt(ys);
      end;
      if ATokens.Count >= 2 then
      begin
        ms := ATokens.Strings[1];
        if not IsValidIntNumberString(ms, False) then
          exit;
        m := StrToInt(ms);
        if (m < 1) or (m > 12) then
          exit;
      end;
      if ATokens.Count >= 3 then
      begin
        ds := ATokens.Strings[2];
        if not IsValidIntNumberString(ds, False) then
          exit;
        d := StrToInt(ds);
        if (d < 1) or (d > DaysInMonth(m)) then
          exit;
      end;
      if ATokens.Count >= 4 then
      begin
        hs := ATokens.Strings[3];
        if not IsValidIntNumberString(hs, False) then
          exit;
        h := StrToInt(hs);
        if (h < 0) or (h > 24) then
          exit;
      end;
      if ATokens.Count >= 5 then
      begin
        ns := ATokens.Strings[4];
        if not IsValidIntNumberString(ns, False) then
          exit;
        n := StrToInt(ns);
        if (n < 0) or (n > 59) then
          exit;
      end;
      if ATokens.Count >= 6 then
      begin
        ss := ATokens.Strings[5];
        if not IsValidIntNumberString(ss, False) then
          exit;
        s := StrToInt(ss);
        if (s < 0) or (s > 59) then
          exit;
      end;

      result := EncodeDateTime(y, m, d, h, n, s, msec);
    finally
      ATokens.Free;
    end;
  end;

  function ExtractDateString(AFileName: WideString): WideString;
  var
    ATokens: TTntStringList;
  begin
    result := '';
    ATokens := TTntStringList.Create;
    try
      Tokenize(WideChangeFileExt(WideExtractFileName(AFileName), ''), ' ', ATokens);

      if ATokens.Count >= 1 then
        result := ATokens.Strings[0];

      if ATokens.Count >= 2 then
      begin
        if WideTextPos('-', ATokens.Strings[1]) > 0 then
          result := result + '-' + ATokens.Strings[1];
      end;
    finally
      ATokens.Free;
    end;
  end;

  procedure RedateImage(AImage: TImageItem; ADt: TDateTime);
  var
    ACatItem: TCatalogItem;
    AXMP: TXMP;
  begin
    ACatItem := TCatalogItem.Create(nil);
    AXMP := TXMP.Create(False);
    try
      if PublicCatalog.FindImageCombined(AImage, ACatItem,True, vptNone) then
      begin
        PublicCatalog.LoadXMPForItem(ACatItem, AXMP, PublicOptions.CachedXMP);
        AImage.WriteExifDateTime (ADt, [dteBase, dteOriginal, dteDigitized], TimeZoneOffset, False, AXMP);
        PublicCatalog._SaveXMPForItem(ACatItem, AXMP, PublicOptions.CachedXMP, False, True, True);
      end;
    finally
      AXMP.Free;
      ACatItem.Free;
    end;
  end;

  procedure HandleImage(AImage: TImageItem);
  var
    ADateString: WideString;
    ADt: TDateTime;
  begin
    {
       examples;

       1. YY-MM something else.jpg
       2. YY-MM-DD somethingelse.jpg
       3. YY-MM-DD HH-MM-SS.jpg

       A. find first part up to space
       B. Parse first part
       C. Redate the metadata
    }

    ADateString := ExtractDateString(AImage.FileName);
    //Say(ADateSTring);
    ADt := DateStringToDateTime(ADateString);
    if ADt <> 0.0 then
    begin
      //Say2(ADateString, DateTimeToStr(ADt));
      RedateImage(AImage, ADt);
      //sleep(1000);
    end;
  end;

var
  i: Integer;
  APro: TxomProgress;
begin
  APro := TxomProgress.Create(nil);
  try
    APro.Caption := 'Redate from file names';
    APro.Max := Selected.Count;
    APro.Pos := 0;
    for i := 0 to Selected.Count - 1 do
    begin
      APro.ProgressText := Selected.Items[i].FileNameOnly;
      APro.Pos := i + 1;
      HandleImage(Selected.Items[i]);
    end;
  finally
    APro.Free;
  end;
end;

[jsrunnels]

Wow!!! Thank you, Hert. I don't know what to say; thank you seems inadequate... That is a very intimidating (to me) script. I don't even know where/how to use it, but I am definitely going to try to figure it out!

In other news, I have discovered the "ReDate" function where you can manually change the date on a group of photos and once you do that, it does at least put them in the correct place in the timeline, so I have been using that. It is brute force, but it is better than nothing. My concern is will it "stick" (i.e. stay valid even if I need to import to a different catalog)

I am worried about this because I am noticing that PSu IS changing BOTH the created and modified date of my images basically every time it touches them, and clearly at some point it also wrote into the content created field for a bunch of the images (I think it was just those that were scans and did not have something already in the content created field. I don't understand why it is doing this or what is triggering it. I just want to get a handle on everything before I commit for sure. :/

[Hert]

You can run the script in the Scripter. Select one or more thumbnails, select Tools-Scripter from the hamburger menu. Copy/past the script and run it with the run button. This script will process the selected thumbnails.

Try it on a handful of files first

My concern is will it "stick" (i.e. stay valid even if I need to import to a different catalog)

Photo Supreme writes dates in the designated metadata fields as defined in the industry standards (XMP/IPTC-XMP/IPTC-IIM/Exif). This metadata is written to the files when you "sync" the images. By default this is done automatically when PSU finds a need for it, but this can be disabled. When auto-sync is disabled you'll have to do the sync yourself (right click thumb->Metadata->Save metadata to file. After sync to the file, the dates are part of the metadata and then of course they'll stick...not only in PSU but in every other tool that supports metadata reading.

FYI; Sync-Write means to get the data from the catalog to the file's metadata. Sync-Read means get the metadata from the file to the catalog.

[jsrunnels]

I just thought a would circle back here and say that this script works FLAWLESSLY for me. Thank you so much, Hert!

[jsrunnels]

Hert -- is there a way to have the script also adjust the XMP create date and modify date? I have been using an app called A Better Finder Attributes to change them all to match, but apparently once the file has been ingested into PSu, PSu goes for the XMP date over the actual file dates for both created and modified. Because the XMP dates are weird and wrong, I would like to change them all to equally weird but at least matching. I know this probably doesn't make sense and is compulsive overkill, but I would still like to do it.

Alternatively, can I easily strip that info for those fields out of the XMP data and force PSu to look at the file info to fill it in again?

Really what I want is a separate script that will make both the XMP create date and modify date match whatever the Content/Photo/Original date is...

Thank you in advance for any help you can offer.

[jsrunnels]

One last piece of data to add to this issue. Why does PSu change the CreateDate and the ModifyDate of the files when it syncs them. In finder, the dates for all the files that I am updating with metadata are having BOTH of those dates change. I am just so incredibly confused about what the heck is actually going on. :/

[sanphotgn]

One last piece of data to add to this issue. Why does PSu change the CreateDate and the ModifyDate of the files when it syncs them. In finder, the dates for all the files that I am updating with metadata are having BOTH of those dates change. I am just so incredibly confused about what the heck is actually going on. :/

If your preferences are set to write to the file during a sync (and you a writing to the file and not a sidecar file) and the files aren't read-only, the ModifyDate will always be changed because you are updating the file. The CreateDate may be taken along for the ride. Both of these dates are related to the file (as a file) and the operating system. Copy the file to another drive or operating system and the dates may be changed to the date one copied them. Can one preserve these dates forever and ever after a file is initially created ... maybe, but it is not easy.

Personally, I don't pay any attention to them. I pay attention to these: exif:DateTimeOriginal and exif:DateTimeDigitized.

A good discussion here:

https://www.organizingphotos.net/date-t ... me-stamps/

[Mke]

In my case the date is part of my file naming convention, so I rarely need to look at anything other than the file name. But as noted by sanphotgn, exif:DateTimeOriginal and exif:DateTimeDigitized are the most useful in the metadata.

[sanphotgn]

In my case the date is part of my file naming convention, so I rarely need to look at anything other than the file name.

I started doing this a couple of years ago. For me, I should have done it from the start.

[afatac]

That is the photo date. The Photo Date is determined as follow:

1. If XMP Exists:
1a. Is there a exif:DateTimeOriginal? Then use it. If not
1b. exif:DateTimeDigitized exists? If not
1c. tiff:DateTime

2. If no XMP exists (yet) but Exif exists then:
2a. Date/Time original exists? If not then
2b. Date/Time digitized exists? If not then
2c. Tiff base date exists?

3. If *no* XMP and *no* Exif exists then
3a. Use the File Date/Time stamp modified; this is the most reliable because the OS changes the creation date when the file is copied or moved. but it won't change the modified date

How about video file? The video captured by my Samsung Galaxy phone is in MP4 format. There is no XMP and Exif, but there is a Create Date embedded in the video under QuickTime section. From my test, this date is not read by PS (5.3.0.2624)

See the attached screenshots.

[Hert]

Please try this first;
1. Select the thumbnail
2. Right click and select Metadata -> Convert Metadata to XMP

Does that pull in the date?

If not, can you perhaps share a sample MP4 file? You can send the file (or a download link) to support@idimager.com
Tia

[Hert]

If not, can you perhaps share a sample MP4 file? You can send the file (or a download link)

No need for a sample file anymore. I've downloaded a sample MP4 file online that helped me reproduce this.