questions about timeline & re-date

[fbungarz]

Hi,
I am really confused about PSU's timeline feature and how it is supposed to be different from how the dates were previously shown.

First, which sense does it make to first show the years in descending order (2019, 2018, 2017 etc.), but the months and days for each year below the descending years, in ascending order (2019-01, 2019-02, etc.), (2019-01-11, 2019-01-14, 2019-01-17, etc.). I find this extremely confusing. It essentially means the timeline runs descending for the years, but ascending within each year...

timeline_ascending-descending.jpg (58.87 KiB) Viewed 2603 times

Why?


Then:
After a recent fresh import I do have quite a few images that in the timeline show up as from 1899. That obviously nonsense! And the file dates on the thumbnails show these photos were taken 9th of February 2019. Why are the images not placed correctly, where they belong in the timeline???

timeline_erroneous_1899-date.jpg (249.37 KiB) Viewed 2603 times

Now, it gets even more bizarre. After assigning labels to these images (with auto-sync on) they no longer appear under 1899, but they are correctly placed, where they belong. Why???

Finally:
Which dates are actually being used by the timeline? I always thought this would be the "photo date" or "date created". Recently though, I noticed that photos that I edited outside PSu show up in the timeline under their "date modified" - which of course is nonsense! Is there any way to avoid this?

Here two examples, first a recent print version, it incorrectly appears in the timeline under the date modified:

print-version-date-modified.jpg (102.89 KiB) Viewed 2603 times

If I switch to the main version, its caption shows the correct date, when the picture was taken (actually, when I scanned the slide):

main-version-correct-date.jpg (100.94 KiB) Viewed 2603 times

Why???

To generate a derivative version, I typically open the main version from within PSU into Photoshop or Affinity. There save it under a different name [appen "_print" or "_edited" to its file name]. Then in PSU scan the folder for missing files to add the images as a version. And finally I then cascade the metadata from the main version into all subversions, to make sure they match.

Now, I understand that external applications might cause the date of the derivative file getting messed up. But cascading the metadata into the file from the main version should take care of that, shouldn't it?
But the dates do not change after cascading!!! Why not???

I have tried re-dating these oddball files. Which of course is a lot of work and would add an additional, redundant step to my workflow. Even worse: in the re-date box there is no option to use the date from the main version! And unlike in the metadata panel, I cannot copy-paste dates, but must manually enter the correct dates and times.

Finally:
Is there any way to see the different dates all side by side? The re-date box lists three different dates: "base date/time" - "date/time original" - "date/time digitized". And then in addition to that bis a separate box below called "file date"...
I am completely confused!
Where can I see what dates are actually embedded inside the metadata of the files for these three fields??? And which is the one date that PSu uses to arrange the images in its timeline?
And why are these fields named differently from Window's File Explorer, are they the same?

How can I fix this mess and make sure all derivative files keep the same date as their originals?

Thanks,
Frank

[Hert]

1899 is the 0-date. Can happen if you cancel an import or when you close the application while an import runs.

When 1899 exist, select all those thumbs, right click and select Metadata-Read from file

[fbungarz]

1899 is the 0-date. Can happen if you cancel an import or when you close the application while an import runs.

Thanks for getting back so promptly. That explains it.

But does that mean the database does not handle dates before 1899? That would be bad news, since some of the specimens of which I take photos have a collection date that is older and I typically would enter that into the DarwinCore collection date. Perhaps, since this doesn't show up in the timeline it is not a big deal and the date still gets stored and written correctly?

What about the other glitches?

[Hert]

Dates before 1899 are also supported.

[fbungarz]

Good to know. Thanks!
Any chance "copy-paste" a date can be implemented for re-dating images?
Thanks,
Frank

[snowman1]

Hi Frank, if you open the detail pane, there is a hamburger icon to the left of each date which exposes options including copy and paste. Does that help? Perhaps there may be other ways too (scripts etc)

[edited to remove erroneous info]

[fbungarz]

Hi Snowman,

Hi Frank, if you open the detail pane, there is a hamburger icon to the left of each date which exposes options including copy and paste. Does that help? Perhaps there may be other ways too (scripts etc)

Yes, I know. But that's my point: Unfortunately this "hamburger icon" is missing from the re-date. So, although it is possible to "copy" the date from image details, it is not possible to paste that date into the re-date:

Copy-Paste-Date-Missing.jpg (43.46 KiB) Viewed 2477 times

This makes it unnecessarily cumbersome to manually correct dates/time from the main version to any subversion, which has an erroneous date modified by an external application.
[I wish it was possible to simply cascade the dates down from the main version; unfortunately that does not work either]

Cheers,
Frank

[snowman1]

Hi Frank, yes, at one point I thought you could do that but I was mistaken and had to edit my post! I agree that dialogue should have a hamburger.

But what you can do, which is what I was clumsily trying to say, is that if you press ctrl-D (windows) to open the detail panel, the dates in that panel have the hamburger. And so you can re-date one image to the desired date (using either this detail panel or the right-click redate function shown in your screenshot), then copy the date from that image, select the others you wish to receive that date, and paste.

There are of course a number of date fields, so if more than one needs changing it could get clumsy; plus as I am not very familiar with versioning - I don't use it much - I'm not sure if your versions would get it cascaded down, sounds like that could be an issue for your situation

[fbungarz]

And so you can re-date one image to the desired date (using either this detail panel or the right-click redate function shown in your screenshot), then copy the date from that image, select the others you wish to receive that date, and paste.

Unfortunately that does not seem to work either, because oddly enough the date shown in image details is the description date, which is different from the date the image was created, which again should be different from the date an image was modified by an external application. Why any external application would change the date created is a mystery to me, but it apparently has happened with quite a few images recently, especially some that I originally scanned.
That is why I originally in this post asked the question, which date PSU actually uses to display the images. I had always assumed the "modified" date would be ignored and the "created" date was being used and am now quite surprised that doesn't seem the case. Yes, by saving an image under a different name in (for example, with the extension *_pint) one could argue that this is not a "modification" but a "creation" of a new image. Obviously for the purpose of databasing this is nonsense and it wrecks havoc with my timeline. It only makes sense if PSU knows that all images of the same version set were taken at the same date.

So, long story short:
In have still not yet found the date that I need to change in the details panel. It is shown on the info panel, but there it cannot be edited...

BTW - copy/paste is not ideal anyways. The best way to do this if one could actually cascade the dates from the main version into all subversions. Perhaps I never before struggled with this and only just now noticed it, because I seem to recall that in IDI one could cascade all metadata. PSU now seems to restrict this to XMP and I presume that these dates are part of the Exif data.

Cheers,
Frank

[fbungarz]

Filed in Mantis as:
https://mantis.idimager.com/view.php?id=3344
and:
https://mantis.idimager.com/view.php?id=3345

[snowman1]

Description date is the first date shown but if you scroll down you will see the others, including "date time original" and "date digitised" (they are in the "technical" section. You have to select the "advanced view" using the hamburger at the top right of the details pane (in its heading bar so to speak) to show all the fields. Hope that helps a little.

I take your point about date usage; I would also have expected the date created to be the one that's used for sorting and timeline purpose, but I haven't actually checked it out or thought about it much conceptually.

The version cascade issue seems a more general question, possibly a conceptual "should it or shouldn't it" question, about versions and their purpose, especially now stacks are gone. Makes me wonder if versions should have gone and stacks remained - that might have been more flexible, especially if one or two options were offered around metadata cascade etc. But I guess that is a wider issue.

[Hert]

How the Photo Date is determined is described here;
viewtopic.php?f=57&t=22960&p=103498&hil ... te#p103498

[fbungarz]

Thanks Hert & snowman, that explains a lot...
Unfortunately it seems, dates in the technical section are locked for editing ;-(
But luckily the script that Hert refers to in https://mantis.idimager.com/view.php?id=3345 does seem to solve this by cascading the dates also:
https://repository.idimager.com/openres ... 0C56713A28

[Hert]

@Frank; you can alos right click on a thumb -> Run Script from Repository -> Version -> Cascade Meta to Full Version Set for Photo Supreme

More convenient than running it from the Scripter

[fbungarz]

Yes, I know. Thanks for pointing it out...