Bug 496364

Summary:	Metadata writing damages tiff files
Product:	[Applications] digikam	Reporter:	digbugs
Component:	Metadata-Engine	Assignee:	Digikam Developers <digikam-bugs-null>
Status:	REPORTED ---
Severity:	critical	CC:	caulier.gilles, dion, metzpinguin, testdroid
Priority:	NOR
Version First Reported In:	8.5.0
Target Milestone:	---
Platform:	Microsoft Windows
OS:	Microsoft Windows
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description digbugs 2024-11-17 00:12:02 UTC

digikam silently trashes tif files when metadata is written.

Observed by
STEPS TO REPRODUCE
1. With metadata writing enabled add a face tag to a tif file produced by photoshop which contains photoshop layer tags.

OBSERVED RESULT
The file is re-written with photoshop layers removed.   I only observed when loading into photoshop the layers were gone. I don't know if other tags were removed. Layer tags are often large (100MB+) which may be relevant. 

I only noticed the problem when updating a back up copy of some files and saw some file were 100MB+ smaller.  Lucky I noticed before trashing the backups as well. 

EXPECTED RESULT
Digikam not destroy parts of my tif files.

SOFTWARE/OS VERSIONS
Windows:  10

Comment 1 Maik Qualmann 2024-11-17 06:19:17 UTC

Have you enabled writing with ExifTool in the digiKam settings under Metadata? If not, please enable writing with ExifTool and test again.
We urgently need a sample TIFF file with which the problem can be reproduced.

Maik

Comment 2 digbugs 2024-11-17 10:33:35 UTC

exiftool metadata writing is not enabled (didn't try with it enabled).
Write this information to Metadata - all options checked.

https://mega.nz/file/Zoo0UJJT#BkKuchK4yy6iiHcCtgyEJRgQy6qhnDVu_I2CSvXlqDc

Scan for faces in this image. Name the face and  the 412MB tif file is silently replaced by a 37MB file.

Comment 3 Maik Qualmann 2024-11-17 10:55:37 UTC

Thanks for the sample image. Enabling writing of metadata with ExifTool helps, and it is best to also enable reading.
Exiv2 has a problem with the image:

Exiv2 ( 3 ) :  Directory Image, entry 0x935c has invalid size 384000092*1; skipping entry.

Maik

Comment 4 caulier.gilles 2024-11-17 11:00:02 UTC

@digbugs

The problem is located in libexiv2 shared library. Please report it as a UPSTREAM bug to the Exiv2 issues pool in github project, attaching the problematic file and explaining the context.

https://github.com/Exiv2/exiv2/issues

Thanks in advance

Gilles Caulier

Comment 5 digbugs 2024-11-17 14:42:37 UTC

I don't have a github account (the last one I created was shadow banned for using a VPN or something). 

Maybe you could post there a link to this thread.

Comment 6 Maik Qualmann 2024-11-17 16:33:46 UTC

The problem can also be reproduced with the CLI tool from Exiv2. Simply setting a dc.subject tag reduces the size to around 36MB.

exiv2 -M"set Xmp.dc.subject Test" Test.tif

Maik

Comment 7 Maik Qualmann 2024-11-19 16:15:50 UTC

I just see that someone has created a bug report on Exiv2 with exactly this problem.

https://github.com/Exiv2/exiv2/issues/3071

Maik

Comment 8 caulier.gilles 2025-03-15 15:32:20 UTC

Hi,

digiKam 8.6.0 is just released:

https://www.digikam.org/news/2025-03-15-8.6.0_release_announcement/

Problem still exists with this version?

Thanks in advance

Gilles Caulier

Comment 9 caulier.gilles 2025-04-11 17:34:06 UTC

Hi,

The digiKam 8.7.0 pre-release for Windows have been rebuild from scratch today with many improvements and updates. Please test with this version to see if the problem is reproducible.

Link to download: https://files.kde.org/digikam/

Thanks in advance

Gilles Caulier