[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 caulier.gil...@gmail.com changed: What|Removed |Added Version Fixed In||8.1.0 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #18 from Metal450 --- Aha, perfect, thanks! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 Peter changed: What|Removed |Added CC||benedekppe...@gmail.com --- Comment #17 from Peter --- > No rush, take your time! I was just curious where to find them, more > generally - sounds like I did have the right spot :) Hi Metal450, It is in the same place as 7.10, only in the unstable branch: https://files.kde.org/digikam/unstable/ -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #16 from Metal450 --- (In reply to caulier.gilles from comment #15) > Hi Maik and Merry Christmas, > > Yes, i'm busy bu i advance well > > https://docs.digikam.org/en/index.html > > I hope to finalize online doc in few days... > > I will rebuild the Windows bundle tomorrow morning, no problem. > > Gilles No rush, take your time! I was just curious where to find them, more generally - sounds like I did have the right spot :) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 caulier.gil...@gmail.com changed: What|Removed |Added Platform|Other |Microsoft Windows CC||caulier.gil...@gmail.com --- Comment #15 from caulier.gil...@gmail.com --- Hi Maik and Merry Christmas, Yes, i'm busy bu i advance well https://docs.digikam.org/en/index.html I hope to finalize online doc in few days... I will rebuild the Windows bundle tomorrow morning, no problem. Gilles -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #14 from Metal450 --- (In reply to Maik Qualmann from comment #13) > Normally, Gilles creates weekly snapshots. However, he is very busy at the > moment, restructuring and porting the digiKam documentation. I don't think > he'll be anywhere near the build machines over the holidays either. A bit > patience... > > Maik Ah OK, so I guess they'll appear at that same place when available then? Just wasn't sure if there was somewhere else for 8.x snapshots. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #13 from Maik Qualmann --- Normally, Gilles creates weekly snapshots. However, he is very busy at the moment, restructuring and porting the digiKam documentation. I don't think he'll be anywhere near the build machines over the holidays either. A bit patience... Maik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #12 from Metal450 --- (In reply to Maik Qualmann from comment #11) > The metadata viewer only displays the entry of a single selected image. In > the case of a multi-selection or maintenance tool process, we would have to > examine the images for this beforehand. Ohh I see - so that's literally directly viewing the metadata in the file, not in the catalog (and the catalog only stores a more generalized subset of meta - not knowing that "tags" came from XP specifically). > Writing an empty tags list now correctly removes XPKeywords. If you don't > have write with ExifTool enabled, XPKeywords will be removed in all cases. If > you have enabled writing with ExifTool, XPKeywords will be written correctly. Gotcha, great! So no settings changes needed. > My research resulted in a bug report for a Windows photo program, either they > also use Exiv2 in the background, since XPKeywords is also always deleted. > Also the author of ExifTool writes that one should avoid the XP* metadata. Yeah, I mean I wouldn't use it myself. But since one doesn't have control over what others might have done to photos before they were received, I just wanted to make sure it was possible to reliably work with tags, more generally, even if someone else has already used XP tags. Sounds like this fix now does it :) Sorry, quick semi-related question: I'm using v8.0.0 (per our other discussion related to sharing the db between win+linux), but it looks like the weekly builds are for 7.10, not 8.0 (https://files.kde.org/digikam/). Is there somewhere with weekly builds for 8.0, that contain all the latest patches? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #11 from Maik Qualmann --- We already have requests to provide a user viewable log in digiKam. I'm sure it will come in the future. The metadata viewer only displays the entry of a single selected image. In the case of a multi-selection or maintenance tool process, we would have to examine the images for this beforehand. Writing an empty tags list now correctly removes XPKeywords. If you don't have write with ExifTool enabled, XPKeywords will be removed in all cases. If you have enabled writing with ExifTool, XPKeywords will be written correctly. My research resulted in a bug report for a Windows photo program, either they also use Exiv2 in the background, since XPKeywords is also always deleted. Also the author of ExifTool writes that one should avoid the XP* metadata. Maik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #10 from Metal450 --- (In reply to Maik Qualmann from comment #7) > Giving a warning every time isn't really practical. So currently the software has that toast UI, i.e. "Updating database - process is done." I was thinking a similar pop-up when applying from database to file, i.e. "Writing files from database - xxx items may not have been successful." Something like that. > On the one hand we don't get an error message from Exiv2 in this case. But the digiKam catalog already knows the files have that particular metadata tag: https://jiij.cc/snaps/2022-12-25_09.17.56.png. So it shouldn't need an explicit error for Exiv2, right? Just knowing that "we're writing tags to a file" and "that file has the XP* tag" is enough to infer that "this file may not be written correctly." > On the other hand, we would have to read all the metadata of the images to > determine which ones contain the XP* tags, which would lead to a severe loss > of performance, especially on network drives. Why would it need to read all the metadata from files again? The catalog clearly already knows the metadata is there (that's how it knew that tag existed in the first place, and made it available to be unchecked in the "Captions" pane). So no need to re-read from disk again...? > We can actually write the XP* tags with ExifTool in the same step as the > modified metadata container. In a first patch we will generally remove the > XP* tags when writing new tags. > add write support for XP* metadata when Exiftool writing is enabled > By default, the legacy XP* metadata is disabled in a new config. So to clarify, to avoid the issue, I need to explicitly enable "Settings->Metadata->Delegate to ExifTool all backend operations to write metadata to files"? If so, any other ramification/side effect, besides this bug not occurring? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 Maik Qualmann changed: What|Removed |Added Resolution|--- |FIXED Latest Commit||https://invent.kde.org/grap ||hics/digikam/commit/0e93b53 ||44bf740ad0db1ca85532a66f1f4 ||72146a Status|REPORTED|RESOLVED --- Comment #9 from Maik Qualmann --- Git commit 0e93b5344bf740ad0db1ca85532a66f1f472146a by Maik Qualmann. Committed on 25/12/2022 at 13:40. Pushed by mqualmann into branch 'master'. add write support for XP* metadata when Exiftool writing is enabled By default, the legacy XP* metadata is disabled in a new config. Related: bug 422242, bug 421464, bug 450522 M +8-5NEWS M +22 -2core/libs/metadataengine/dmetadata/dmetadata_comments.cpp M +13 -1core/libs/metadataengine/dmetadata/dmetadata_tags.cpp M +3-0 core/libs/metadataengine/dmetadata/dmetadatasettingscontainer.cpp https://invent.kde.org/graphics/digikam/commit/0e93b5344bf740ad0db1ca85532a66f1f472146a -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #8 from Maik Qualmann --- Git commit d71f6605893d5b1b801ebc425756114711c5fc97 by Maik Qualmann. Committed on 25/12/2022 at 10:20. Pushed by mqualmann into branch 'master'. add support for XPTitle and remove XP* metadata when writing Related: bug 422242, bug 421464, bug 450522 M +36 -1core/libs/metadataengine/dmetadata/dmetadata_comments.cpp M +24 -10 core/libs/metadataengine/dmetadata/dmetadata_tags.cpp M +13 -5 core/libs/metadataengine/dmetadata/dmetadatasettingscontainer.cpp https://invent.kde.org/graphics/digikam/commit/d71f6605893d5b1b801ebc425756114711c5fc97 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #7 from Maik Qualmann --- Giving a warning every time isn't really practical. On the one hand we don't get an error message from Exiv2 in this case. On the other hand, we would have to read all the metadata of the images to determine which ones contain the XP* tags, which would lead to a severe loss of performance, especially on network drives. We can actually write the XP* tags with ExifTool in the same step as the modified metadata container. In a first patch we will generally remove the XP* tags when writing new tags. Maik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #6 from Metal450 --- Those options all work as a one-off fix for a particular images/images (or for users who somehow become aware of the issue), but more broadly, the software should really provide some warning. Ie just a simple check to see if that tag is there, and if so, the confirmation toast should let the user know that their changes may have not been applied. Otherwise, anytime someone copies a bunch of photos from a friend/relative/etc, and attempts to just work with tags normally, it's not at all obvious that half the actions taken were actually ignored. If or until there's a true fix, why not just show: "Warning: 12 of the images written contained XP metadata, so your changes may not have applied. Please see (link to this issue, or to the most relevant)." -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #5 from Maik Qualmann --- Exactly, XP Keywords is the problem. I can look up the relevant bug reports for you. Just so much, because of the encoding, this tag has historically only been read-only in Exiv2. It also doesn't help to enable writing with ExifTool in digiKam-8.0.0 because we create the container with Exiv2. digiKam uses the C++ program Exiv2 internally. What options do you have? 1. You can remove XP Keywords using batch processing and the Remove Metadata Tool, there is an extra entry for Exif in the combo box. 2. You can disable the reading of XP Keywords in the advanced metadata settings, but the value of XP keywords will still remain in the image metadata. 3. We find another solution... Maik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #4 from Metal450 --- Is the output of exiftool enough? Let me know if not & I'll send the picture itself, but exiftool's output is below. I do see mention of "XP Keywords." However, if there's a known issue that a particular type of keyword will not be properly written, shouldn't the software raise an error/warning, rather than appearing to succeed but just silently failing? I spent quite some time going through & cleaning up tags before (much later) uncovering that all that time had actually been wasted, and nothing was actually being updated. I found it completely by chance when I diffed an image for other reasons, then re-read from metadata and suddenly every single tag I'd just removed was back. So apparently I hadn't actually done anything. ``` ExifTool Version Number : 12.51 File Name : Mich visit 10-2010 003-2.JPG Directory : . File Size : 969 kB File Modification Date/Time : 2022:12:22 22:57:20-08:00 File Access Date/Time : 2022:12:23 08:38:53-08:00 File Creation Date/Time : 2022:12:17 19:44:13-08:00 File Permissions: -rw-rw-rw- File Type : JPEG File Type Extension : jpg MIME Type : image/jpeg Exif Byte Order : Big-endian (Motorola, MM) Make: SONY Camera Model Name : DSC-W70 Orientation : Horizontal (normal) X Resolution: 72 Y Resolution: 72 Resolution Unit : inches Software: Adobe Photoshop CS5 Windows Modify Date : 2010:10:27 09:21:26 Y Cb Cr Positioning : Co-sited XP Keywords : Mich visit 10-2010 PrintIM Version : 0300 Exposure Time : 1/50 F Number: 5.2 Exposure Program: Program AE ISO : 160 Exif Version: 0221 Date/Time Original : 2010:09:23 17:56:36 Create Date : 2010:09:23 17:56:36 Components Configuration: Y, Cb, Cr, - Compressed Bits Per Pixel : 8 Exposure Compensation : +1.7 Max Aperture Value : 2.8 Metering Mode : Multi-segment Light Source: Unknown Flash : On, Return detected Focal Length: 18.9 mm Flashpix Version: 0100 Color Space : sRGB Exif Image Width: 2304 Exif Image Height : 3072 Interoperability Version: 0100 File Source : Digital Camera Scene Type : Directly photographed Custom Rendered : Normal Exposure Mode : Manual White Balance : Auto Scene Capture Type : Standard Contrast: High Saturation : High Sharpness : Normal Padding : (Binary data 2060 bytes, use -b option to extract) Offset Schema : 4200 Compression : JPEG (old-style) Thumbnail Offset: 5030 Thumbnail Length: 6889 XMP Toolkit : XMP Core 4.4.0-Exiv2 Creator Tool: Microsoft Windows Photo Gallery 6.0.6001.18000 Metadata Date : 2010:10:27 09:21:26-07:00 Format : image/jpeg Color Mode : RGB ICC Profile Name: sRGB IEC61966-2.1 Instance ID : xmp.iid:0B6D863FE6E1DF11964DF8DAF7BB095B Document ID : xmp.did:0B6D863FE6E1DF11964DF8DAF7BB095B Original Document ID: xmp.did:0B6D863FE6E1DF11964DF8DAF7BB095B Description : History Action : saved History Instance ID : xmp.iid:0B6D863FE6E1DF11964DF8DAF7BB095B History When: 2010:10:27 09:21:26-07:00 History Software Agent : Adobe Photoshop CS5 Windows History Changed : / Profile CMM Type: Linotronic Profile Version : 2.1.0 Profile Class : Display Device Profile Color Space Data: RGB Profile Connection Space: XYZ Profile Date Time : 1998:02:09 06:49:00 Profile File Signature : acsp Primary Platform: Microsoft Corporation CMM Flags : Not Embedded, Independent Device Manufacturer : Hewlett-Packard Device Model: sRGB Device Attributes : Reflective, Glossy, Positive, Color Rendering Intent: Perceptual Connection Space Illuminant : 0.9642 1 0.82491 Profile Creator : Hewlett-Packard
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #3 from Maik Qualmann --- According to the log, the metadata was written without errors. If the tag was written with Windows programs, there is a possibility that the tag is written in Microsoft XP* metadata. Exiv2 can currently only read this metadata area, but not change it. That would explain the tag reappearing. Can you email me the image? Maik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 --- Comment #2 from Metal450 --- > Whether the modification date changes depends on the metadata settings. Yeah, that was desired - was just mentioning it to illustrate that digiKam had actually done something to the file (even though no binary changes took place). > You enabled it to update back to the previous one. Not sure what you mean by this...? > We need a DebugView log [11176] digikam.metaengine: Loading metadata with "Exiv2" backend from "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.general: Writing tags [11176] digikam.general: Delete all keywords [11176] digikam.metaengine: "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" ==> New Iptc Keywords: () [11176] digikam.metaengine: MetaEngine::metadataWritingMode 0 [11176] digikam.metaengine: Will write Metadata to file "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.metaengine: wroteComment: true [11176] digikam.metaengine: wroteEXIF: true [11176] digikam.metaengine: wroteIPTC: true [11176] digikam.metaengine: wroteXMP: true [11176] digikam.metaengine: Metadata for file "Mich visit 10-2010 003-2.JPG" written to file. [11176] digikam.metaengine: Loading metadata with "Exiv2" backend from "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.dimg: "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" : "JPEG" file identified [11176] digikam.database: Scanning took 6 ms [11176] digikam.database: Finishing took 7 ms [11176] digikam.metaengine: Loading metadata with "Exiv2" backend from "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.general: Trying to get thumbnail from "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" ( "image" ) [11176] digikam.general: Trying to get thumbnail with Exiv2 for "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.metaengine: Loading metadata with "Exiv2" backend from "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.general: Trying to get thumbnail from "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" ( "image" ) [11176] digikam.general: Trying to get thumbnail with Exiv2 for "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.general: Trying to get thumbnail with DImg preview for "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.general: Trying to get thumbnail with DImg preview for "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" [11176] digikam.dimg: "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" : "JPEG" file identified [11176] digikam.dimg: "D:/_Pics+Vids_/Pics/0-(82-94) - Early Childhood/Pops & Grandma Misc/Mich visit 10-2010 003-2.JPG" : "JPEG" file identified [11176] digikam.general: Using 8 CPU core to run threads [11176] digikam.general: Using 8 CPU core to run threads [11176] digikam.general: Action Thread run 1 new jobs [11176] digikam.general: Action Thread run 1 new jobs [11176] digikam.general: One job is done [11176] digikam.general: Cancel Main Thread [11176] digikam.general: One job is done [11176] digikam.general: Cancel Main Thread -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 463378] Applied Tags Don't Get Written To File?
https://bugs.kde.org/show_bug.cgi?id=463378 Maik Qualmann changed: What|Removed |Added CC||metzping...@gmail.com --- Comment #1 from Maik Qualmann --- We need a DebugView log of the process. Download and launch DebugView from Microsoft. Activate internal debugging in the digiKam settings under Miscellaneous-> System and start digiKam again. Run the tag operation and post the DebugView log. Whether the modification date changes depends on the metadata settings. You enabled it to update back to the previous one. Maik -- You are receiving this mail because: You are watching all bug changes.
