Re: modification historical on a pictures

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-recurs
> > 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?