SUMMARY JPG and CR2 are recorded simultaneously for each shot on a Canon EOS60D. When using the File Renaming Options during download/import from the camera, the customize option using the date. For example: [date:yyyy-MM-dd_hh-mm-ss]_[file].[ext] Appears to use different time zones depending on the file type. In the example given the will result in: 2019-09-08_15_04_06_IMG_0428.JPG (correct time, camera set to this time CET (UTC+2 for daylight savings time)) 2019-09-08_17_04_08_IMG_0428.CR2 (2 hrs +, eg UTC+4) (seconds are expected to differ because of the time difference between writing the two files) Renaming after the import leads to the correct renaming: 2019-09-08_15_04_06_IMG_0428.JPG 2019-09-08_15_04_08_IMG_0428.CR2 The local time on my computer is set to CET (UTC+2), its hardware clock is set to UTC. This appears to be the cause of an error in interpreting / correcting for time zones in the original shot time and date in the CR2 during the renaming. STEPS TO REPRODUCE 1. Set camera to record both JPG and CR2 2. Shoot picture 3. Connect Camera to computer 4. Switch on camera 5. On KDE, when camera device notifier pops-up select "Download Photos with DigiKam" 6. In "renaming options", select "customize", set rename pattern string to "[date:yyyy-MM-dd_hh-mm-ss]_[file].[ext]" 7. "Auto-Createtion of of Albums" set to "Date-based sub-albums" with "Date format" set to "ISO" 8. Select all images for download 9. In Menu select "Item"->"Download and delete selected" 10. Select default location for new download folder by clicking "OK" 11. Select download directory to verify OBSERVED RESULT CR2 files are renamed with incorrect time. EXPECTED RESULT CR2 files are renamed using correct (eg corresponding to JPG files) SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.12.8 KDE Frameworks Version: 5.55.0 Qt Version: 5.9.7 ADDITIONAL INFORMATION The workaround which was to rename the files after import, no longer works in the current digikam version.
The problem is known, if the camera is connected via the GPhoto2 driver, we can not read metadata on RAW files and have to use the file date. As a workaround, rename the files after import. Maik
*** This bug has been marked as a duplicate of bug 387004 ***
Created attachment 122577 [details] attachment-14993-0.html Hi Maik, As noted in the additional information, the workaround no longer seems to work. "have to use the file date": There is a date digikam currently works off. Can be this incorporated correctly? Just do the right time zone compensation math for the CR2 file after reading the file date? 2-3 years ago this worked with the right date selected in rename. Martin On September 10, 2019 9:22:45 AM GMT+02:00, Maik Qualmann <bugzilla_noreply@kde.org> wrote: >https://bugs.kde.org/show_bug.cgi?id=411780 > >Maik Qualmann <metzpinguin@gmail.com> changed: > > What |Removed |Added >---------------------------------------------------------------------------- > CC| |metzpinguin@gmail.com > >--- Comment #1 from Maik Qualmann <metzpinguin@gmail.com> --- >The problem is known, if the camera is connected via the GPhoto2 >driver, we can >not read metadata on RAW files and have to use the file date. As a >workaround, >rename the files after import. > >Maik > >-- >You are receiving this mail because: >You reported the bug.
The problem may not have been different 2-3 years ago. The main problem is that in the camera metadata the set timezone is not saved, only in the undocumented Makernotes. That's why many professional photographers on a trip around the world generally set their camera to UTC. Maik
Created attachment 122578 [details] attachment-15829-0.html Thanks for the reply and the utc tip! I am however positiv that this was not a problem on the past (Q1 of '16 or '17). I do remember having tried to fix the rename string then. Unfortunately o can't remember how (should have reported it at the time, sorry). I also think I remember that two different time stamps were available prior to that and I'm pretty sure I was using the alternate. I might have been using a different one (maker specific perhaps) back then . On September 10, 2019 9:46:02 AM GMT+02:00, Maik Qualmann <bugzilla_noreply@kde.org> wrote: >https://bugs.kde.org/show_bug.cgi?id=411780 > >--- Comment #4 from Maik Qualmann <metzpinguin@gmail.com> --- >The problem may not have been different 2-3 years ago. The main problem >is that >in the camera metadata the set timezone is not saved, only in the >undocumented >Makernotes. That's why many professional photographers on a trip around >the >world generally set their camera to UTC. > >Maik > >-- >You are receiving this mail because: >You reported the bug.
Fixed with #387004