[digiKam-users] Is changing the date of a photo a destructive process?

[Andrey Goreev]

Right click- open with - others - then type your exiftool command followed by %U


Sent from my Samsung Galaxy smartphone.
-------- Original message --------From: Stefan Mueller <stefan.mueller.83 at gmail.com> Date: 2018-03-07  8:27 AM  (GMT-07:00) To: digiKam - Home Manage your photographs as a professional with the power of open source <digikam-users at kde.org> Subject: Re: [digiKam-users] Is changing the date of a photo a destructive	process? 
would be nice if exiftool could be executed within digikam for such cases

2018-03-07 16:14 GMT+01:00 Andrey Goreev <aegoreev at gmail.com>:
I might be wrong but I think BQM always produces a new file and the operation is not lossless.
You might want to use exiftool / exiv2 to shift date/time of multiple pictures.
Here is an example from exiftool website:
Common metadata date/time tags are incremented by -6 hours, while
FileModifyDate is not changed:

exiftool -alldates-=6 -P FILE(FOLDER)

Sent from my Samsung Galaxy smartphone.
-------- Original message --------From: woenx <marcpalaus at hotmail.com> Date: 2018-03-07  7:30 AM  (GMT-07:00) To: digikam-users at kde.org Subject: [digiKam-users] Is changing the date of a photo a destructive process? 
So I want to correct the date to a bunch of pictures. If use the metadata
editor on the tools panel, I can just change it one by one. If I want to
process several at a time, I use the Batch Queue Manager.

By default, the Batch Queue Manager does not overwrite pictures, you have to
actively check that option, and there's also a whole "Saving images" tab
dealing with JPG quality and that kind of stuff. 

My question is: If I am just changing the date of a group of JPG pictures,
do they lose quality every time a change is made, or the batch queue manager
just changes the metadata and leaves the picture intact? 



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20180307/2876053f/attachment.html>