Re: modification historical on a pictures

The changes were not caused by digiKam, but by an Adobe program or similar.

Even in its latest version, Exiv2 writes XMP Core 4.4.0-Exiv2. If the write 
operation is performed with ExifTool, ExifTool appears at this point along 
with the version number; therefore, XMP Core 5.5.0 was not written by digiKam.

Maik

Am Donnerstag, 13. November 2025, 11:52:50 Mitteleuropäische Normalzeit 
schrieb frederic chaume:
> Hi all
> 
> I didn't find how to get the historical modifications of a file, but if
> it can help ,  I've found how to compare 2 pictures:
> Just export the metadata (exiftool) in a file (button tools/save in
> file)  for each version and then use a winmerge to compare the 2
> 
> I found several differences:
> 
> the XMPToolkit is different  : XMP Core 4.4.0-Exiv2 vs XMP Core 5.5.0
> for the most  recent one
> "subject" and "keywords" have been added in the most recent one
> "ImageDescription" has been removed in the most recent one
> and the CurrentIPTCDigest is different
> 
> This explain the size difference , but  still don't know not what has
> been done on 30th October that could have introduced those changes
> (after win11 and DK8.8 upgrade)
> Any comments ?
> Regards
> Frederic
> 
> Le 08/11/2025 à 12:40, Maik Qualmann a écrit :
> > We only have this one bug: https://bugs.kde.org/show_bug.cgi?id=511159
> > in digiKam-8.8.0 which led to unwanted changes when faces were ignored or
> > deleted, metadata was written even though it was purely a database
> > operation.
> > 
> > The background face recognition process can be disabled in the digiKam
> > setup. However, this process does not modify any images.
> > 
> > Maik
> > 
> > Am Samstag, 8. November 2025, 10:43:58 Mitteleuropäische Normalzeit
> > schrieb
> > 
> > frederic chaume:
> >> Thanks Gilles for the explanation.
> >> 
> >> in fact , my problem, as described  in my initial mail (missing in this
> >> thread), was about finding more than 2K jpegs files as modified when
> >> running my backup. Those are old images I didn't remember to have
> >> changed since my last backup (on 24th of October) but marked as modified
> >> in DK on 30th October and then I was wondering  if there is a way to
> >> identified what has been changed.
> >> Images identified as modified seems correct, but I 'm not able to
> >> compare tags between the 2 versions, as tags are not always visible from
> >> the file properties/detail of windows manager (while tags are present in
> >> DK)
> >> 
> >> Since the last backup (on 24th of October) , I have upgraded my PC to
> >> Win11 and upgraded DK to DK8.8
> >> I also notice that search face is now running at startup (new in 8.8?)
> >> but I checked no face tags have been added in the new version
> >> 
> >> I you want I can share example to you
> >> 
> >> Regards
> >> Frederic
> >> 
> >> Le 08/11/2025 à 09:47, Gilles Caulier a écrit :
> >>> Hi all,
> >>> 
> >>> First you must know that JPEG (and also other major file formats) are
> >>> structured as chunks. Depending on the format architecture, these
> >>> chunks are ordered by usage and priority, and generally metadata are
> >>> hosted in a chunk somewhere on the front of the file to be processed
> >>> quickly while cataloging. The image data is stored in other chunks,
> >>> after the metadata.
> >>> 
> >>> When you modify a metadata you don't touch the image data. In the
> >>> inverse, when you change the image data, metadata are always changed
> >>> (typically to host the image sizes for ex).
> >>> 
> >>> When digiKam changes something in the metadata (as for ex a keywords),
> >>> this touches the metadata chunk, not the image, somewhere on the front
> >>> of the file (first 1K of the file stream). This is processed by Exiv2
> >>> library or ExifTool, depending on the digiKam settings. Of course
> >>> changing metadata will change the file date as it is touched by the OS
> >>> file system module. In digiKam, there is an option from the metadata
> >>> settings panel to restore the file date when metadata is changed.
> >>> 
> >>> Another point to know is the registration of a file in the database
> >>> with a checksum algorithm, based on the first K bytes of the files.
> >>> calculating a checksum on the whole file takes a while and will reduce
> >>> the performances. This checksum allows you to follow the change in the
> >>> file for example when you touch contents with an external application,
> >>> or to identify files stored in the collection and already downloaded
> >>> from a camera.
> >>> 
> >>> To come to the original problem on this thread, to identify a
> >>> corrupted file is a complex and long task to process and will require
> >>> to compute a checksum on the whole files. This can be done with
> >>> scripts of course, and this will take a while on a large collection.
> >>> Processing this computation on the collection and on a backup will
> >>> help to identify the touched files.
> >>> 
> >>> A program as rsync used complex and fast algorithms to synchronize a
> >>> source folder and a destination folder. This is the best open source
> >>> to use on the command line under Linux to process these kinds of jobs.
> >>> Rsync can be used  in a "dry" mode to identify the differences between
> >>> contents.
> >>> 
> >>> https://superuser.com/questions/748069/how-do-i-compare-two-folders-recu
> >>> rs
> >>> ively-and-generate-a-list-of-files-and-folder
> >>> 
> >>> My best regards
> >>> 
> >>> Gilles Caulier
> >>> 
> >>> Le ven. 7 nov. 2025 à 12:44, frederic chaume
> >>> 
> >>> <[email protected]> a écrit :
> >>>> Hi Frederic
> >>>> 
> >>>> situation are different, in my case I didn't change or rename tags.
> >>>> I see there is an option set "detect faces in newly added images" , and
> >>>> I see it is running. I don't know in which version this option has been
> >>>> added, but I see it is effectively running. Now this concern new added
> >>>> images and in my case, problem is relative to old images.
> >>>> Regards
> >>>> Frederic
> >>>> 
> >>>> Le 07/11/2025 à 12:28, Frédéric Da Vitoria a écrit :
> >>>>> This has happened to me too, for example if I change a tag (for
> >>>>> example changing an upper case to lower case, or editing an
> >>>>> accent...). This tag modification is of course propagated to all
> >>>>> concerned pictures. I found this annoying at first, because previous
> >>>>> did not change the date in this case, but I understand that the files
> >>>>> are indeed modified. And for backup purposes, the backup files indeed
> >>>>> need to be refreshed IMO.
> >>>>> 
> >>>>> But maybe this is not the correct explanation in your situation?