modification historical on a pictures

[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-recurs
>>> ively-and-generate-a-list-of-files-and-folder
>>>
>>> My best regards
>>>
>>> Gilles Caulier
>>>
>>> Le ven. 7 nov. 2025 à 12:44, frederic chaume
>>>
>>> <frederic.chaume at gmail.com> 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?
>
>
>