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

[woenx]

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

[AndriusWild]

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 <[hidden email]>

Date: 2018-03-07 7:30 AM (GMT-07:00)

To: [hidden email]

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

[PackElend]

would be nice if exiftool could be executed within digikam for such cases

2018-03-07 16:14 GMT+01:00 Andrey Goreev <[hidden email]>:

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 <[hidden email]>

Date: 2018-03-07 7:30 AM (GMT-07:00)

To: [hidden email]

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

[AndriusWild]

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

Sent from my Samsung Galaxy smartphone.

-------- Original message --------

From: Stefan Mueller <[hidden email]>

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 <[hidden email]>

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 <[hidden email]>:

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 <[hidden email]>

Date: 2018-03-07 7:30 AM (GMT-07:00)

To: [hidden email]

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

[woenx]

Hi again,

I have been doing some tests, comparing images before and after the date was
changed in the Batch Queue Manager using an image comparer (
http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Comparer.shtml
<http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Comparer.shtml>
)

The file generated after a date change is identical to the original, not a
single pixel was changed. File size is different due to changes in the
metadata, but that's it.

As a comparison, I tried to open and save the same JPG picture using
Microsoft Paint, and the image comparer found lots of differences to the
original.

Therefore, I conclude that changing the date in digikam is a lossless
process.


PS: now, if only the date changing process were more intuitive in digikam...





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

[PackElend]

there isn't any 'open with' in digikam win64:

2018-03-07 16:29 GMT+01:00 Andrey Goreev <[hidden email]>:

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

Sent from my Samsung Galaxy smartphone.

-------- Original message --------

From: Stefan Mueller <[hidden email]>

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 <[hidden email]>

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 <[hidden email]>:

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 <[hidden email]>

Date: 2018-03-07 7:30 AM (GMT-07:00)

To: [hidden email]

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

[Maik Qualmann]

The BQM needs a target file. If there are no image editing tools in the tool
list, a copy is made from the source file and no changes are made to the image
data. Even overwrite mode to the target file is safe.

Maik

Am Mittwoch, 7. März 2018, 16:54:30 CET schrieb woenx:

> Hi again,
>
> I have been doing some tests, comparing images before and after the date was
> changed in the Batch Queue Manager using an image comparer (
> http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compare
> r.shtml
> <http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compa
> rer.shtml> )
>
> The file generated after a date change is identical to the original, not a
> single pixel was changed. File size is different due to changes in the
> metadata, but that's it.
>
> As a comparison, I tried to open and save the same JPG picture using
> Microsoft Paint, and the image comparer found lots of differences to the
> original.
>
> Therefore, I conclude that changing the date in digikam is a lossless
> process.
>
>
> PS: now, if only the date changing process were more intuitive in digikam...
>
>
>
>
>
> --
> Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[tosca]

I liked better the previous process, outside the BQM. It could be used on a selection, displayed a preview of the new date before update and - of course - acted on the original picture.

I don't understand why it had been incorporated in the BQM, it is much less convenient.

Marie-Noëlle

2018-03-07 18:50 GMT+01:00 Maik Qualmann <[hidden email]>:

The BQM needs a target file. If there are no image editing tools in the tool
list, a copy is made from the source file and no changes are made to the image
data. Even overwrite mode to the target file is safe.

Maik

Am Mittwoch, 7. März 2018, 16:54:30 CET schrieb woenx:
> Hi again,
>
> I have been doing some tests, comparing images before and after the date was
> changed in the Batch Queue Manager using an image comparer (
> http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compare
> r.shtml
> <http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compa
> rer.shtml> )
>
> The file generated after a date change is identical to the original, not a
> single pixel was changed. File size is different due to changes in the
> metadata, but that's it.
>
> As a comparison, I tried to open and save the same JPG picture using
> Microsoft Paint, and the image comparer found lots of differences to the
> original.
>
> Therefore, I conclude that changing the date in digikam is a lossless
> process.
>
>
> PS: now, if only the date changing process were more intuitive in digikam...
>
>
>
>
>
> --
> Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

--

[Jack Marxer]

I also liked the previous method of renaming files better than using the BQM. It clearly displayed the results before commiting changes.

Jack Marxer

On Wed, Mar 7, 2018 at 10:46 PM, Marie-Noëlle Augendre <[hidden email]> wrote:

I liked better the previous process, outside the BQM. It could be used on a selection, displayed a preview of the new date before update and - of course - acted on the original picture.

I don't understand why it had been incorporated in the BQM, it is much less convenient.

Marie-Noëlle

2018-03-07 18:50 GMT+01:00 Maik Qualmann <[hidden email]>:

The BQM needs a target file. If there are no image editing tools in the tool
list, a copy is made from the source file and no changes are made to the image
data. Even overwrite mode to the target file is safe.

Maik

Am Mittwoch, 7. März 2018, 16:54:30 CET schrieb woenx:
> Hi again,
>
> I have been doing some tests, comparing images before and after the date was
> changed in the Batch Queue Manager using an image comparer (
> http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compare
> r.shtml
> <http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compa
> rer.shtml> )
>
> The file generated after a date change is identical to the original, not a
> single pixel was changed. File size is different due to changes in the
> metadata, but that's it.
>
> As a comparison, I tried to open and save the same JPG picture using
> Microsoft Paint, and the image comparer found lots of differences to the
> original.
>
> Therefore, I conclude that changing the date in digikam is a lossless
> process.
>
>
> PS: now, if only the date changing process were more intuitive in digikam...
>
>
>
>
>
> --
> Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

--

[PackElend]

can anyone explain why there isn't any 'open with' in digikam win64?

2018-03-08 9:18 GMT+01:00 Jack Marxer <[hidden email]>:

I also liked the previous method of renaming files better than using the BQM. It clearly displayed the results before commiting changes.

Jack Marxer

On Wed, Mar 7, 2018 at 10:46 PM, Marie-Noëlle Augendre <[hidden email]> wrote:

I liked better the previous process, outside the BQM. It could be used on a selection, displayed a preview of the new date before update and - of course - acted on the original picture.

I don't understand why it had been incorporated in the BQM, it is much less convenient.

Marie-Noëlle

2018-03-07 18:50 GMT+01:00 Maik Qualmann <[hidden email]>:

The BQM needs a target file. If there are no image editing tools in the tool
list, a copy is made from the source file and no changes are made to the image
data. Even overwrite mode to the target file is safe.

Maik

Am Mittwoch, 7. März 2018, 16:54:30 CET schrieb woenx:
> Hi again,
>
> I have been doing some tests, comparing images before and after the date was
> changed in the Batch Queue Manager using an image comparer (
> http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compare
> r.shtml
> <http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compa
> rer.shtml> )
>
> The file generated after a date change is identical to the original, not a
> single pixel was changed. File size is different due to changes in the
> metadata, but that's it.
>
> As a comparison, I tried to open and save the same JPG picture using
> Microsoft Paint, and the image comparer found lots of differences to the
> original.
>
> Therefore, I conclude that changing the date in digikam is a lossless
> process.
>
>
> PS: now, if only the date changing process were more intuitive in digikam...
>
>
>
>
>
> --
> Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

--

[Gilles Caulier-4]

Hi,

Because "Open With" code is based on KDE API which is relevant of KIO framework, which DO NOT WORK under Windows and MACOS. Code is based on OpenDesktop standard for Linux, and Windows is not compatible with OpenDesktop of course. So this part must be re-written with delegate code, as nothing exist in Qt5 API to do the job.

https://bugs.kde.org/show_bug.cgi?id=380065

There is an entry in bugzilla, where i published a patch, which do not work yet, as i develop mostly under Linux, not Windows.

All help from a developer to finalize the patch for Windows is welcome.

Best

Gilles Caulier

2018-03-09 9:17 GMT+01:00 Stefan Mueller <[hidden email]>:

can anyone explain why there isn't any 'open with' in digikam win64?

2018-03-08 9:18 GMT+01:00 Jack Marxer <[hidden email]>:

I also liked the previous method of renaming files better than using the BQM. It clearly displayed the results before commiting changes.

Jack Marxer

On Wed, Mar 7, 2018 at 10:46 PM, Marie-Noëlle Augendre <[hidden email]> wrote:

I liked better the previous process, outside the BQM. It could be used on a selection, displayed a preview of the new date before update and - of course - acted on the original picture.

I don't understand why it had been incorporated in the BQM, it is much less convenient.

Marie-Noëlle

2018-03-07 18:50 GMT+01:00 Maik Qualmann <[hidden email]>:

The BQM needs a target file. If there are no image editing tools in the tool
list, a copy is made from the source file and no changes are made to the image
data. Even overwrite mode to the target file is safe.

Maik

Am Mittwoch, 7. März 2018, 16:54:30 CET schrieb woenx:
> Hi again,
>
> I have been doing some tests, comparing images before and after the date was
> changed in the Batch Queue Manager using an image comparer (
> http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compare
> r.shtml
> <http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compa
> rer.shtml> )
>
> The file generated after a date change is identical to the original, not a
> single pixel was changed. File size is different due to changes in the
> metadata, but that's it.
>
> As a comparison, I tried to open and save the same JPG picture using
> Microsoft Paint, and the image comparer found lots of differences to the
> original.
>
> Therefore, I conclude that changing the date in digikam is a lossless
> process.
>
>
> PS: now, if only the date changing process were more intuitive in digikam...
>
>
>
>
>
> --
> Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

--

[PackElend]

thx for the explanation 

2018-03-09 10:52 GMT+01:00 Gilles Caulier <[hidden email]>:

Hi,

Because "Open With" code is based on KDE API which is relevant of KIO framework, which DO NOT WORK under Windows and MACOS. Code is based on OpenDesktop standard for Linux, and Windows is not compatible with OpenDesktop of course. So this part must be re-written with delegate code, as nothing exist in Qt5 API to do the job.

https://bugs.kde.org/show_bug.cgi?id=380065

There is an entry in bugzilla, where i published a patch, which do not work yet, as i develop mostly under Linux, not Windows.

All help from a developer to finalize the patch for Windows is welcome.

Best

Gilles Caulier

2018-03-09 9:17 GMT+01:00 Stefan Mueller <[hidden email]>:

can anyone explain why there isn't any 'open with' in digikam win64?

2018-03-08 9:18 GMT+01:00 Jack Marxer <[hidden email]>:

I also liked the previous method of renaming files better than using the BQM. It clearly displayed the results before commiting changes.

Jack Marxer

On Wed, Mar 7, 2018 at 10:46 PM, Marie-Noëlle Augendre <[hidden email]> wrote:

I liked better the previous process, outside the BQM. It could be used on a selection, displayed a preview of the new date before update and - of course - acted on the original picture.

I don't understand why it had been incorporated in the BQM, it is much less convenient.

Marie-Noëlle

2018-03-07 18:50 GMT+01:00 Maik Qualmann <[hidden email]>:

The BQM needs a target file. If there are no image editing tools in the tool
list, a copy is made from the source file and no changes are made to the image
data. Even overwrite mode to the target file is safe.

Maik

Am Mittwoch, 7. März 2018, 16:54:30 CET schrieb woenx:
> Hi again,
>
> I have been doing some tests, comparing images before and after the date was
> changed in the Batch Queue Manager using an image comparer (
> http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compare
> r.shtml
> <http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compa
> rer.shtml> )
>
> The file generated after a date change is identical to the original, not a
> single pixel was changed. File size is different due to changes in the
> metadata, but that's it.
>
> As a comparison, I tried to open and save the same JPG picture using
> Microsoft Paint, and the image comparer found lots of differences to the
> original.
>
> Therefore, I conclude that changing the date in digikam is a lossless
> process.
>
>
> PS: now, if only the date changing process were more intuitive in digikam...
>
>
>
>
>
> --
> Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

--

[Gilles Caulier-4]

Hi Marie,

It have been moved to BQM, to chain this tool with more than one operations. This is the goal of BQM : batch processing over image. Changing the date is a batch operation.

There is an entry in bugzilla to improve the data change behaviour as the older tool do with GUI :

https://bugs.kde.org/show_bug.cgi?id=366777

Best

Gilles Caulier

2018-03-07 22:46 GMT+01:00 Marie-Noëlle Augendre <[hidden email]>:

I liked better the previous process, outside the BQM. It could be used on a selection, displayed a preview of the new date before update and - of course - acted on the original picture.

I don't understand why it had been incorporated in the BQM, it is much less convenient.

Marie-Noëlle

2018-03-07 18:50 GMT+01:00 Maik Qualmann <[hidden email]>:

The BQM needs a target file. If there are no image editing tools in the tool
list, a copy is made from the source file and no changes are made to the image
data. Even overwrite mode to the target file is safe.

Maik

Am Mittwoch, 7. März 2018, 16:54:30 CET schrieb woenx:
> Hi again,
>
> I have been doing some tests, comparing images before and after the date was
> changed in the Batch Queue Manager using an image comparer (
> http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compare
> r.shtml
> <http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compa
> rer.shtml> )
>
> The file generated after a date change is identical to the original, not a
> single pixel was changed. File size is different due to changes in the
> metadata, but that's it.
>
> As a comparison, I tried to open and save the same JPG picture using
> Microsoft Paint, and the image comparer found lots of differences to the
> original.
>
> Therefore, I conclude that changing the date in digikam is a lossless
> process.
>
>
> PS: now, if only the date changing process were more intuitive in digikam...
>
>
>
>
>
> --
> Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

--

[NeiNei]

There is an "open with" option in DigiKam on Linux.
For the Windows (and later the MacOSX) version, there is a feature
request where Gilles has been working on it a few days ago. See:
https://bugs.kde.org/show_bug.cgi?id=380065
However, for the most recent status of the feature request Gilles may
provide some explanations.

NeiNei

On 09.03.2018 09:17, Stefan Mueller wrote:

> can anyone explain why there isn't any 'open with' in digikam win64?
>
> 2018-03-08 9:18 GMT+01:00 Jack Marxer <[hidden email]
> <mailto:[hidden email]>>:
>
>     I also liked the previous method of renaming files better than using
>     the BQM. It clearly displayed the results before commiting changes.
>
>     Jack Marxer
>
>     On Wed, Mar 7, 2018 at 10:46 PM, Marie-Noëlle Augendre
>     <[hidden email] <mailto:[hidden email]>> wrote:
>
>         I liked better the previous process, outside the BQM. It could
>         be used on a selection, displayed a preview of the new date
>         before update and - of course - acted on the original picture.
>
>         I don't understand why it had been incorporated in the BQM, it
>         is much less convenient.
>
>         Marie-Noëlle
>
>         2018-03-07 18:50 GMT+01:00 Maik Qualmann <[hidden email]
>         <mailto:[hidden email]>>:
>
>             The BQM needs a target file. If there are no image editing
>             tools in the tool
>             list, a copy is made from the source file and no changes are
>             made to the image
>             data. Even overwrite mode to the target file is safe.
>
>             Maik
>
>             Am Mittwoch, 7. März 2018, 16:54:30 CET schrieb woenx:
>              > Hi again,
>              >
>              > I have been doing some tests, comparing images before and
>             after the date was
>              > changed in the Batch Queue Manager using an image comparer (
>              >
>             http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compare
>             <http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compare>
>              > r.shtml
>              >
>             <http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compa
>             <http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Image-Compa>
>              > rer.shtml> )
>              >
>              > The file generated after a date change is identical to
>             the original, not a
>              > single pixel was changed. File size is different due to
>             changes in the
>              > metadata, but that's it.
>              >
>              > As a comparison, I tried to open and save the same JPG
>             picture using
>              > Microsoft Paint, and the image comparer found lots of
>             differences to the
>              > original.
>              >
>              > Therefore, I conclude that changing the date in digikam
>             is a lossless
>              > process.
>              >
>              >
>              > PS: now, if only the date changing process were more
>             intuitive in digikam...
>              >
>              >
>              >
>              >
>              >
>              > --
>              > Sent from:
>             http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html
>             <http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html>
>
>
>
>
>
>
>
>         --
>         <http://marie-noelle-augendre.com>
>         Découvrez mes photos sur mon site
>         <http://marie-noelle-augendre.com> ou ma page Facebook
>         <https://www.facebook.com/PhotographeEnCevennes?ref=bookmarks>
>
>         <http://www.blurb.fr/user/mnaugendre><http://marie-noelle-augendre.com>
>         <http://www.blurb.fr/user/mnaugendre>
>
>         et tous mes livres-photos sur le site Blurb
>         <http://www.blurb.fr/user/mnaugendre>
>         <http://www.blurb.fr/user/mnaugendre>
>
>
>
>
>