Re: modification historical on a pictures

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