Problem with "Set Created Date to EXIF"

[SL09]

There is a command that would be very useful, but does not work with certain file types:

File special | Set Created Date to EXIF

With .jpg, there is no problem. But with .dng {Huawei P30 Pro VOG-L29}, there is simply no reaction, the 'Date Created' stays the same.

Exiftool(GUI) shows several dates :
- FileAccessDate (the useless one that changes all the time) - as shown in XYPlorer
- FileModifyDate - as shown in XYPlorer
- FileCreateDate - as shown in XYPlorer (but not the correct one)

In the corresponding .jpg, I see a 'CreateDate' value, absent in the .dng - maybe the cause of the problem ?
- DateTimeOriginal (in the 'Exif' tab, in both image types) shows the real date the file was created

Wouldn't it be possible to retrieve the Date Created from the 'DateTimeOriginal' value instead of [no reaction] ?

[admin]

Select the file and run echo <dateexif yyyy-mm-dd hh:nn:ss>; through the address bar. Do you get a date?

[SL09]

> Do you get a date?
There is no date if a .dng is selected, only (i) Echo

With .jpg, cr2 the date (and time) shown is identical to the data in the list of files

By the way:
- For .psd generated from a .dng "without" CreationDate, the command shows the data as in "DateTimeOriginal" [ExifToolGUI]. Some sort of tunneling ...

- For .MP4 {those are created by my Canon 6 D Mark II} the same thing as with the .dng happens

[admin]

Just checked the Help and it reveals that the function is limited to JPEG and TIFF files:

Set Created Date to Exif
Sets the Created date of each selected image file (JPEG, TIFF) to its Exif date.

Then I checked the code and it turns out that the help is wrong. It's currently even more limited to these extensions: .jfif .jpg .jpeg .jpe. This bug will be fixed, but it won't help your case.

You will also get an error message now: "Could not retrieve EXIF date."

BUT: If the shell property "Date taken" can see the date, then this date is taken as a fallback for the non-retrievable EXIF date. And this will work for ALL image file types that can probably have a "Date taken" property. Will update the Help accordingly.

[jupe]

@Don: Since we are on a related subject, I just tested this change out hoping it would resolve a discrepancy I have always had where some images would show the date for the XY special prop, and others wouldn't, the non and working jpg images have the date available as <dateexif> and System.Photo.DateTaken though, just the special prop column and #image.datetaken doesn't display them.

[admin]

Yep, should work better soon.

[jupe]

I updated to .0135 to test, and I receive the following error now with the special property column visible in the same image folder, and the list pane aborts after only 2 files are listed, of a folder of ~500. If I use fresh I get the smaller error dialog and then a silent close too.

2023-09-23_094041.png

[admin]

Oh, not here. Anyway, I can fix it.

BTW, the inconsistency you noticed goes back to this change:

Code: Select all

v17.00.0102 - 2016-08-11 21:18
    * Special Properties: Property "Date Taken" (#image.datetaken) now only 
      draws on Exif Tag 0x9003 (DateTimeOriginal).
      Before, it fell back to Exif Tag 0x0132 (DateTime) if DateTimeOriginal was 
      not available. Disadvantage of the fall back strategy: a blurred relation 
      between display and reality.

Now I would say, since the v17.00.0102 and later state is inconsistent with other places in XY, go back to before v17.00.0102.

[SL09]

It seems I started quite a nasty process for the programmer-in-chief ... Thank you for (all) your work !

> the function is limited to JPEG and TIFF files
I never would have had the idea to consult the helpfile ... So sorry if I over-estimated the program. But:
As far as I remember, the function DID work with every Canon Raw file, beinning with those out of my Powershot S60 (.CRW), 400 D, 50 D, 6 D & Mark II (all called .CR2, but certainly quite different one from the other).

Recently, I found some .JPGs showing nothing when I call [echo <dateexif yyyy-mm-dd hh:nn:ss>;]. They date from 2002 and older, produced by a Videocamera with a photo function. ExifToolGUI shows no data in the EXIF tab.

[admin]

Business as usual. Actually the Help file was wrong here, I could improve the app, and everything should work now in the current beta.

[jupe]

Confirmed fixed in .0136

[SL09]

I tried the Beta (.0137). It runs in a folder 'D:\PROV\xyplorer_24.90.0137_beta_noinstall', without licence data ("### 30-Day Trial Version"). With this, I only get a message "Could not retrieve EXIF date."
I consider it too risky to install the Beta instead of my regular version; also, I see no opportunity to enter my license data into the Beta. So I will wait for the next regular update ...

[admin]

A Codec is needed to extract this kind of information.

[SL09]

> A Codec is needed to extract this kind of information.
... complicated ... another Codec ??

As I see in my posts, in 2016 I was successfull with the CameraCodecPack from Microsoft - then in 2018 I bought FastPictureViewer and FastPictureViewerCodecPack 3.8.0.97 and installed it. I remember that without it, XYplorer couldn't show previews of .CR2 files.
The Beta shows the preview, so it has access to this Codec.

When I use the command "Datei | Datei speziell | Erstelldatum auf EXIF setzen"
- the regular version does nothing
- the Beta shows the message "Could not retrieve EXIF date."
Are these so very different functions ? what furhter "Codec" would I need ??

[admin]

One Codec should be enough.

Can you mail me a CR2 file for testing?