Hello,
I'm once again fighting with tags and this battle seem to have no ending. I figured out that digiKam once again read data from 5 different namespaces(IPTC, Xmp digikam, Xmp Microsoft, Xmp lightroom) and only modify it to IPTC and own XMP namespace. This is bad because: If you wipe -> trigger write and then read -> all deleted tags are back. Some users said that namespaces that are not from digiKam should not be touched. Well this is impossible, you either: 1. grant digiKam to delete and modify all namespaces that it can read 2. remove the ability to read from that protected namespace Any other combination result in total mess on read/write. I'm waiting for suggestions about do you prefer the most: 1 or 2 Veaceslav _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Hello Veaceslav,
I may be wrong here, but my understanding is that Digikam does not "always" modify IPTC and XMP. It only syncs with IPTC if there is no XMP data available. So the situation is even worst than presented. My old IPTC data keep reappearing and is not even near to be in sync with XMP and the database. To your question, I see no purpose to restrain Digikam's ability to read any namespace. Therefore I would rather go for your first approach (1). regards gps On 07/23/2014 01:06 PM, Veaceslav Munteanu wrote: > Hello, > > I'm once again fighting with tags and this battle seem to have no ending. > > I figured out that digiKam once again read data from 5 different > namespaces(IPTC, Xmp digikam, Xmp Microsoft, Xmp lightroom) and only > modify it to IPTC and own XMP namespace. > > This is bad because: > If you wipe -> trigger write and then read -> all deleted tags are back. > > Some users said that namespaces that are not from digiKam should not be touched. > Well this is impossible, you either: > > 1. grant digiKam to delete and modify all namespaces that it can read > 2. remove the ability to read from that protected namespace > > Any other combination result in total mess on read/write. > > I'm waiting for suggestions about do you prefer the most: 1 or 2 > > Veaceslav > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > > Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
digiKam always write tags in XMP, into dedicated "digiKam" namespace.
After to write and read, as this XMP namespace is the first checked to sync database, other and old place in exif, iptc or xmp where tags are recorded must be ignored. So, i don't understand the original problem... Gilles Caulier 2014-07-23 20:13 GMT+02:00 Gian Paolo Sanino Vattier <[hidden email]>: > Hello Veaceslav, > I may be wrong here, but my understanding is that Digikam does not > "always" modify IPTC and XMP. It only syncs with IPTC if there is no XMP > data available. So the situation is even worst than presented. My old > IPTC data keep reappearing and is not even near to be in sync with XMP > and the database. > > To your question, I see no purpose to restrain Digikam's ability to read > any namespace. Therefore I would rather go for your first approach (1). > regards > gps > > On 07/23/2014 01:06 PM, Veaceslav Munteanu wrote: >> Hello, >> >> I'm once again fighting with tags and this battle seem to have no ending. >> >> I figured out that digiKam once again read data from 5 different >> namespaces(IPTC, Xmp digikam, Xmp Microsoft, Xmp lightroom) and only >> modify it to IPTC and own XMP namespace. >> >> This is bad because: >> If you wipe -> trigger write and then read -> all deleted tags are back. >> >> Some users said that namespaces that are not from digiKam should not be touched. >> Well this is impossible, you either: >> >> 1. grant digiKam to delete and modify all namespaces that it can read >> 2. remove the ability to read from that protected namespace >> >> Any other combination result in total mess on read/write. >> >> I'm waiting for suggestions about do you prefer the most: 1 or 2 >> >> Veaceslav >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users >> >> > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On Wed, Jul 23, 2014 at 10:12 PM, Gilles Caulier
<[hidden email]> wrote: > digiKam always write tags in XMP, into dedicated "digiKam" namespace. > > After to write and read, as this XMP namespace is the first checked to > sync database, other and old place in exif, iptc or xmp where tags are > recorded must be ignored. If you delete tags then sync, new read will look into the own namespace then if nothing found(all tags were deleted) it will go to next namespace(from the code there are 5 places which are checked). What I tried to test is the ability of Tags Manager to delete all from database and then sync database to images, but after re-read, all tags are back. Sometimes users request to read for new namespaces and support is added, but only for read and when it comes to writing, digiKam is no longer consistent and it result in a big mess of old, new and tags impossible to delete. > 2014-07-23 20:13 GMT+02:00 Gian Paolo Sanino Vattier <[hidden email]>: >> Hello Veaceslav, >> I may be wrong here, but my understanding is that Digikam does not >> "always" modify IPTC and XMP. It only syncs with IPTC if there is no XMP >> data available. So the situation is even worst than presented. My old >> IPTC data keep reappearing and is not even near to be in sync with XMP >> and the database. I'm working on it, and it will update every field it can read. I'm reworking tags read/write subsystem a little, to improve overall tag consistency. >> _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On Wednesday 23 July 2014 22:33:10 Veaceslav Munteanu wrote:
> On Wed, Jul 23, 2014 at 10:12 PM, Gilles Caulier > > <[hidden email]> wrote: > > digiKam always write tags in XMP, into dedicated "digiKam" namespace. > > > > After to write and read, as this XMP namespace is the first checked to > > sync database, other and old place in exif, iptc or xmp where tags are > > recorded must be ignored. > > If you delete tags then sync, new read will look into the own > namespace then if nothing found(all tags were deleted) it will go to > next namespace(from the code there are 5 places which are checked). > > What I tried to test is the ability of Tags Manager to delete all from > database and then sync database to images, but after re-read, all tags > are back. > > Sometimes users request to read for new namespaces and support is > added, but only for read and when it comes to writing, digiKam is no > longer consistent and it result in a big mess of old, new and tags > impossible to delete. This is exactly my experience. It is impossible to add a tag and to get rid of it again using Digikam. I raised this problem a couple of times on the list, but somehow I was not able to make myself clear. Right now I use exiv2 on the command line to clear tags from images. It would be _great_, however, to have a consistent handling of tags withing Digikam. > > > 2014-07-23 20:13 GMT+02:00 Gian Paolo Sanino Vattier <[hidden email]>: > >> Hello Veaceslav, > >> I may be wrong here, but my understanding is that Digikam does not > >> "always" modify IPTC and XMP. It only syncs with IPTC if there is no XMP > >> data available. So the situation is even worst than presented. My old > >> IPTC data keep reappearing and is not even near to be in sync with XMP > >> and the database. > > I'm working on it, and it will update every field it can read. I'm > reworking tags read/write subsystem a little, to improve overall tag > consistency. > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Everybody who have tagging problems, please send me some images(3-4)
with tags which you believe that digikam can't fully set, for testing purpose. On Thu, Jul 24, 2014 at 12:01 AM, Wolfgang Mader <[hidden email]> wrote: > On Wednesday 23 July 2014 22:33:10 Veaceslav Munteanu wrote: >> On Wed, Jul 23, 2014 at 10:12 PM, Gilles Caulier >> >> <[hidden email]> wrote: >> > digiKam always write tags in XMP, into dedicated "digiKam" namespace. >> > >> > After to write and read, as this XMP namespace is the first checked to >> > sync database, other and old place in exif, iptc or xmp where tags are >> > recorded must be ignored. >> >> If you delete tags then sync, new read will look into the own >> namespace then if nothing found(all tags were deleted) it will go to >> next namespace(from the code there are 5 places which are checked). >> >> What I tried to test is the ability of Tags Manager to delete all from >> database and then sync database to images, but after re-read, all tags >> are back. >> >> Sometimes users request to read for new namespaces and support is >> added, but only for read and when it comes to writing, digiKam is no >> longer consistent and it result in a big mess of old, new and tags >> impossible to delete. > > This is exactly my experience. It is impossible to add a tag and to get rid of > it again using Digikam. I raised this problem a couple of times on the list, > but somehow I was not able to make myself clear. > > Right now I use exiv2 on the command line to clear tags from images. It would > be _great_, however, to have a consistent handling of tags withing Digikam. > >> >> > 2014-07-23 20:13 GMT+02:00 Gian Paolo Sanino Vattier <[hidden email]>: >> >> Hello Veaceslav, >> >> I may be wrong here, but my understanding is that Digikam does not >> >> "always" modify IPTC and XMP. It only syncs with IPTC if there is no XMP >> >> data available. So the situation is even worst than presented. My old >> >> IPTC data keep reappearing and is not even near to be in sync with XMP >> >> and the database. >> >> I'm working on it, and it will update every field it can read. I'm >> reworking tags read/write subsystem a little, to improve overall tag >> consistency. >> >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users > Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Gilles Caulier-4
Gilles Caulier <[hidden email]> wrote:
> digiKam always write tags in XMP, into dedicated "digiKam" namespace. > > After to write and read, as this XMP namespace is the first checked to > sync database, other and old place in exif, iptc or xmp where tags are > recorded must be ignored. > Well that's pretty much useless IMHO, what happens when you move some images to other places? -- Chris Green · _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
After an user provided me with a pack of image that indeed creates
some problems with tags(some legacy images), I managed to repair some bugs. If you believe that you have images with obsolete tags which can not be deleted or anything that can't be fixed by read and then write, please make me a zip archive and will gladly test and fix it. On Thu, Jul 24, 2014 at 1:05 PM, <[hidden email]> wrote: > Gilles Caulier <[hidden email]> wrote: >> digiKam always write tags in XMP, into dedicated "digiKam" namespace. >> >> After to write and read, as this XMP namespace is the first checked to >> sync database, other and old place in exif, iptc or xmp where tags are >> recorded must be ignored. >> > Well that's pretty much useless IMHO, what happens when you move some > images to other places? > > -- > Chris Green > · > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Chris Green
>what happens when you move some images to other places
??? places ? What do you mean exactly ? Album ? if yes, this have no effect on tags. Gilles Caulier 2014-07-24 12:05 GMT+02:00 <[hidden email]>: > Gilles Caulier <[hidden email]> wrote: >> digiKam always write tags in XMP, into dedicated "digiKam" namespace. >> >> After to write and read, as this XMP namespace is the first checked to >> sync database, other and old place in exif, iptc or xmp where tags are >> recorded must be ignored. >> > Well that's pretty much useless IMHO, what happens when you move some > images to other places? > > -- > Chris Green > · > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Gilles Caulier <[hidden email]> wrote:
> 2014-07-24 12:05 GMT+02:00 <[hidden email]>: > > Gilles Caulier <[hidden email]> wrote: > >> digiKam always write tags in XMP, into dedicated "digiKam" namespace. > >> > >> After to write and read, as this XMP namespace is the first checked to > >> sync database, other and old place in exif, iptc or xmp where tags are > >> recorded must be ignored. > >> > > Well that's pretty much useless IMHO, what happens when you move some > > images to other places? > > > >what happens when you move some images to other places > > ??? places ? What do you mean exactly ? Album ? if yes, this have no > effect on tags. > world that uses tags on images. By creating its own little private place to keep tags it means it's never going to cooperate with other programs using tags. I mean what about images which one transfers to a web page and/or web gallery? They use tags too. I understand it may be difficult but without the ability to manage tags in such a way that other programs can see and use them then they are fundamentallyy useless (for me anyway). -- Chris Green · _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
digiKam XMP namespace is used primary to populate digiKam database and
duplicate database metadata to image, WITHOUt to lost anything. In second way, digiKam update also tags at other place in XMP and IPTC, but this can introduce some leak about database properties (IPTC for ex as serious limitation about strings. Nested Tags are also badly supported in standard XMP namespace. Gilles Caulier 2014-07-24 17:55 GMT+02:00 <[hidden email]>: > Gilles Caulier <[hidden email]> wrote: >> 2014-07-24 12:05 GMT+02:00 <[hidden email]>: >> > Gilles Caulier <[hidden email]> wrote: >> >> digiKam always write tags in XMP, into dedicated "digiKam" namespace. >> >> >> >> After to write and read, as this XMP namespace is the first checked to >> >> sync database, other and old place in exif, iptc or xmp where tags are >> >> recorded must be ignored. >> >> >> > Well that's pretty much useless IMHO, what happens when you move some >> > images to other places? >> > >> >what happens when you move some images to other places >> >> ??? places ? What do you mean exactly ? Album ? if yes, this have no >> effect on tags. >> > I mean other applications. Digikam isn't the only program in the > world that uses tags on images. By creating its own little private > place to keep tags it means it's never going to cooperate with other > programs using tags. > > I mean what about images which one transfers to a web page and/or web > gallery? They use tags too. > > I understand it may be difficult but without the ability to manage > tags in such a way that other programs can see and use them then they > are fundamentallyy useless (for me anyway). > > -- > Chris Green > · > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
I confirm also that mirroring with XMP namespace is working great
work Gilles.
About IPTC I fully agree and understand the concept that it is limited, however the actual way that Digikam deals with is by adding the database content to IPTC without removing the previous content on that namespace, resulting that tags that were introduced by Digikam in the past, that may now be considered as deprecated remain there, cannot be deleted and have a change to reappear on the database if the images are shared with computers with previous versions of Digikam (ej. 3.5.0) or other applications that may focus on IPTC. It makes sense to me that Digikam should be able to delete content that was added by Digikam. Maybe it can and I just do not know how to use it. It just happened to me when sharing a catalog of photos with our remote research station with limited Internet access to upgrade Digikam (and its dependencies), many deprecated tags reappeared on the database creating a huge confusion on the operators. It would be great to find a way to really erase the previous IPTC keywords in the process that updates its content (instead of the actual additions), removing that way deprecated tags on IPTC namespace and that way we can move on XMP without leaving behind deprecated tags in other namespaces. Just an idea about the subject... kind regards gps On 07/24/2014 12:47 PM, Gilles Caulier
wrote:
digiKam XMP namespace is used primary to populate digiKam database and duplicate database metadata to image, WITHOUt to lost anything. In second way, digiKam update also tags at other place in XMP and IPTC, but this can introduce some leak about database properties (IPTC for ex as serious limitation about strings. Nested Tags are also badly supported in standard XMP namespace. Gilles Caulier 2014-07-24 17:55 GMT+02:00 [hidden email]:Gilles Caulier [hidden email] wrote:2014-07-24 12:05 GMT+02:00 [hidden email]:Gilles Caulier [hidden email] wrote:digiKam always write tags in XMP, into dedicated "digiKam" namespace. After to write and read, as this XMP namespace is the first checked to sync database, other and old place in exif, iptc or xmp where tags are recorded must be ignored.Well that's pretty much useless IMHO, what happens when you move some images to other places?>what happens when you move some images to other places ??? places ? What do you mean exactly ? Album ? if yes, this have no effect on tags.I mean other applications. Digikam isn't the only program in the world that uses tags on images. By creating its own little private place to keep tags it means it's never going to cooperate with other programs using tags. I mean what about images which one transfers to a web page and/or web gallery? They use tags too. I understand it may be difficult but without the ability to manage tags in such a way that other programs can see and use them then they are fundamentallyy useless (for me anyway). -- Chris Green · _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Gilles Caulier-4
Hello everybody.
I want to thank everybody who sent me pack of images to test. I really called them nuke pack, because they really had everything in them: legacy tags, duplicates and obsolete tags :D Thanks to them I was able to reproduce a lot of issues and fix them all. What I did: 1. Fixed more than 3 different scenarios in which digiKam could not write tags 2. Fixed IPTC being out of sync with XMP 3. Fixed _Digikam_root_tag_ which appears in images tagged with old version of digiKam 4. Added extra deduplication when writing tags + logic to remove all occurrences of _Digikam_root_tag_ 5. Tested all packs received from users: All images contain fresh clean tags after read then write 6. XMP sidecar files also tested: read then write will remove any inconsistency 7. Fixed Tags Manager write option, which was broken 8. Tested all 3 options to read and write metadata: from maintenance, from menu and from tags manager 9. Tested face tags and read/write on them 10. If you have large collections, use Tags Manager write option, it will only write tags and process will be much faster Anybody who can compile and run git repository can test and give me some feedback :) I hope you will really enjoy tagging, because I spent almost a week, full time, working on them ^_^ On Thu, Jul 24, 2014 at 7:47 PM, Gilles Caulier <[hidden email]> wrote: > digiKam XMP namespace is used primary to populate digiKam database and > duplicate database metadata to image, WITHOUt to lost anything. > > In second way, digiKam update also tags at other place in XMP and > IPTC, but this can introduce some leak about database properties (IPTC > for ex as serious limitation about strings. Nested Tags are also badly > supported in standard XMP namespace. > > Gilles Caulier > > 2014-07-24 17:55 GMT+02:00 <[hidden email]>: >> Gilles Caulier <[hidden email]> wrote: >>> 2014-07-24 12:05 GMT+02:00 <[hidden email]>: >>> > Gilles Caulier <[hidden email]> wrote: >>> >> digiKam always write tags in XMP, into dedicated "digiKam" namespace. >>> >> >>> >> After to write and read, as this XMP namespace is the first checked to >>> >> sync database, other and old place in exif, iptc or xmp where tags are >>> >> recorded must be ignored. >>> >> >>> > Well that's pretty much useless IMHO, what happens when you move some >>> > images to other places? >>> > >>> >what happens when you move some images to other places >>> >>> ??? places ? What do you mean exactly ? Album ? if yes, this have no >>> effect on tags. >>> >> I mean other applications. Digikam isn't the only program in the >> world that uses tags on images. By creating its own little private >> place to keep tags it means it's never going to cooperate with other >> programs using tags. >> >> I mean what about images which one transfers to a web page and/or web >> gallery? They use tags too. >> >> I understand it may be difficult but without the ability to manage >> tags in such a way that other programs can see and use them then they >> are fundamentallyy useless (for me anyway). >> >> -- >> Chris Green >> · >> >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On Friday 25 July 2014 14:32:47 Veaceslav Munteanu wrote:
> Hello everybody. > > I want to thank everybody who sent me pack of images to test. I really > called them nuke pack, because they really had everything in them: > legacy tags, duplicates and obsolete tags :D > > Thanks to them I was able to reproduce a lot of issues and fix them all. > > What I did: > > 1. Fixed more than 3 different scenarios in which digiKam could not write > tags 2. Fixed IPTC being out of sync with XMP > 3. Fixed _Digikam_root_tag_ which appears in images tagged with old > version of digiKam > 4. Added extra deduplication when writing tags + logic to remove all > occurrences of _Digikam_root_tag_ > 5. Tested all packs received from users: All images contain fresh > clean tags after read then write > 6. XMP sidecar files also tested: read then write will remove any > inconsistency 7. Fixed Tags Manager write option, which was broken > 8. Tested all 3 options to read and write metadata: from maintenance, > from menu and from tags manager > 9. Tested face tags and read/write on them > 10. If you have large collections, use Tags Manager write option, it > will only write tags and process will be much faster Hello Veaceslav, thank you for your work on this. This is great news! In order to remove all tags from already taged images, do you recommend to use Tags Manager (your point 10)? Do you still need more images. I can prepare a set next week (I am right now away from my images). > > Anybody who can compile and run git repository can test and give me > some feedback :) > I hope you will really enjoy tagging, because I spent almost a week, > full time, working on them ^_^ You can be sure that this work is appreciated! Best, Wolfgang > > > On Thu, Jul 24, 2014 at 7:47 PM, Gilles Caulier > > <[hidden email]> wrote: > > digiKam XMP namespace is used primary to populate digiKam database and > > duplicate database metadata to image, WITHOUt to lost anything. > > > > In second way, digiKam update also tags at other place in XMP and > > IPTC, but this can introduce some leak about database properties (IPTC > > for ex as serious limitation about strings. Nested Tags are also badly > > supported in standard XMP namespace. > > > > Gilles Caulier > > > > 2014-07-24 17:55 GMT+02:00 <[hidden email]>: > >> Gilles Caulier <[hidden email]> wrote: > >>> 2014-07-24 12:05 GMT+02:00 <[hidden email]>: > >>> > Gilles Caulier <[hidden email]> wrote: > >>> >> digiKam always write tags in XMP, into dedicated "digiKam" namespace. > >>> >> > >>> >> After to write and read, as this XMP namespace is the first checked > >>> >> to > >>> >> sync database, other and old place in exif, iptc or xmp where tags > >>> >> are > >>> >> recorded must be ignored. > >>> > > >>> > Well that's pretty much useless IMHO, what happens when you move some > >>> > images to other places? > >>> > > >>> >what happens when you move some images to other places > >>> > >>> ??? places ? What do you mean exactly ? Album ? if yes, this have no > >>> effect on tags. > >> > >> I mean other applications. Digikam isn't the only program in the > >> world that uses tags on images. By creating its own little private > >> place to keep tags it means it's never going to cooperate with other > >> programs using tags. > >> > >> I mean what about images which one transfers to a web page and/or web > >> gallery? They use tags too. > >> > >> I understand it may be difficult but without the ability to manage > >> tags in such a way that other programs can see and use them then they > >> are fundamentallyy useless (for me anyway). > >> > >> -- > >> Chris Green > >> · > >> > >> _______________________________________________ > >> Digikam-users mailing list > >> [hidden email] > >> https://mail.kde.org/mailman/listinfo/digikam-users > > > > _______________________________________________ > > Digikam-users mailing list > > [hidden email] > > https://mail.kde.org/mailman/listinfo/digikam-users > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On Fri, Jul 25, 2014 at 2:38 PM, Wolfgang Mader
<[hidden email]> wrote: > On Friday 25 July 2014 14:32:47 Veaceslav Munteanu wrote: >> Hello everybody. >> >> I want to thank everybody who sent me pack of images to test. I really >> called them nuke pack, because they really had everything in them: >> legacy tags, duplicates and obsolete tags :D >> >> Thanks to them I was able to reproduce a lot of issues and fix them all. >> >> What I did: >> >> 1. Fixed more than 3 different scenarios in which digiKam could not write >> tags 2. Fixed IPTC being out of sync with XMP >> 3. Fixed _Digikam_root_tag_ which appears in images tagged with old >> version of digiKam >> 4. Added extra deduplication when writing tags + logic to remove all >> occurrences of _Digikam_root_tag_ >> 5. Tested all packs received from users: All images contain fresh >> clean tags after read then write >> 6. XMP sidecar files also tested: read then write will remove any >> inconsistency 7. Fixed Tags Manager write option, which was broken >> 8. Tested all 3 options to read and write metadata: from maintenance, >> from menu and from tags manager >> 9. Tested face tags and read/write on them >> 10. If you have large collections, use Tags Manager write option, it >> will only write tags and process will be much faster > > Hello Veaceslav, > > thank you for your work on this. This is great news! In order to remove all > tags from already taged images, do you recommend to use Tags Manager (your > point 10)? Tags Manager use a specialized option from maintenance, which sync only tags (without caption, rating, etc) > Do you still need more images. I can prepare a set next week (I am right now > away from my images). yes, you can always send me packs of image which create problems on your machine. WARNING: Please call read tags before calling write tags. digiKam now simply delete everything before setting tags from database. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On Friday 25 July 2014 14:45:20 Veaceslav Munteanu wrote:
> On Fri, Jul 25, 2014 at 2:38 PM, Wolfgang Mader > > <[hidden email]> wrote: > > On Friday 25 July 2014 14:32:47 Veaceslav Munteanu wrote: > >> Hello everybody. > >> > >> I want to thank everybody who sent me pack of images to test. I really > >> called them nuke pack, because they really had everything in them: > >> legacy tags, duplicates and obsolete tags :D > >> > >> Thanks to them I was able to reproduce a lot of issues and fix them all. > >> > >> What I did: > >> > >> 1. Fixed more than 3 different scenarios in which digiKam could not write > >> tags 2. Fixed IPTC being out of sync with XMP > >> 3. Fixed _Digikam_root_tag_ which appears in images tagged with old > >> version of digiKam > >> 4. Added extra deduplication when writing tags + logic to remove all > >> occurrences of _Digikam_root_tag_ > >> 5. Tested all packs received from users: All images contain fresh > >> clean tags after read then write > >> 6. XMP sidecar files also tested: read then write will remove any > >> inconsistency 7. Fixed Tags Manager write option, which was broken > >> 8. Tested all 3 options to read and write metadata: from maintenance, > >> from menu and from tags manager > >> 9. Tested face tags and read/write on them > >> 10. If you have large collections, use Tags Manager write option, it > >> will only write tags and process will be much faster > > > > Hello Veaceslav, > > > > thank you for your work on this. This is great news! In order to remove > > all > > tags from already taged images, do you recommend to use Tags Manager (your > > point 10)? > > Tags Manager use a specialized option from maintenance, which sync > only tags (without caption, rating, etc) > > > Do you still need more images. I can prepare a set next week (I am right > > now away from my images). > > yes, you can always send me packs of image which create problems on > your machine. Ok. > > WARNING: Please call read tags before calling write tags. digiKam now > simply delete everything before setting tags from database. Since taging is for some workflows important and time consuming to set up, do we need a little research on how to make Tags in Digikam more robust? I would hate to lose all my tags, just because I clicked two actions in the wrong order. > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
I can help you with some warning messages on bulk operations such as
options from Tags Manager and Maintenance. The write tags operation from Tags Manager is guarded by 2 warnings, one describing and suggesting read before write. I can't do more than this. Veaceslav On Fri, Jul 25, 2014 at 2:51 PM, Wolfgang Mader <[hidden email]> wrote: > On Friday 25 July 2014 14:45:20 Veaceslav Munteanu wrote: >> On Fri, Jul 25, 2014 at 2:38 PM, Wolfgang Mader >> >> <[hidden email]> wrote: >> > On Friday 25 July 2014 14:32:47 Veaceslav Munteanu wrote: >> >> Hello everybody. >> >> >> >> I want to thank everybody who sent me pack of images to test. I really >> >> called them nuke pack, because they really had everything in them: >> >> legacy tags, duplicates and obsolete tags :D >> >> >> >> Thanks to them I was able to reproduce a lot of issues and fix them all. >> >> >> >> What I did: >> >> >> >> 1. Fixed more than 3 different scenarios in which digiKam could not write >> >> tags 2. Fixed IPTC being out of sync with XMP >> >> 3. Fixed _Digikam_root_tag_ which appears in images tagged with old >> >> version of digiKam >> >> 4. Added extra deduplication when writing tags + logic to remove all >> >> occurrences of _Digikam_root_tag_ >> >> 5. Tested all packs received from users: All images contain fresh >> >> clean tags after read then write >> >> 6. XMP sidecar files also tested: read then write will remove any >> >> inconsistency 7. Fixed Tags Manager write option, which was broken >> >> 8. Tested all 3 options to read and write metadata: from maintenance, >> >> from menu and from tags manager >> >> 9. Tested face tags and read/write on them >> >> 10. If you have large collections, use Tags Manager write option, it >> >> will only write tags and process will be much faster >> > >> > Hello Veaceslav, >> > >> > thank you for your work on this. This is great news! In order to remove >> > all >> > tags from already taged images, do you recommend to use Tags Manager (your >> > point 10)? >> >> Tags Manager use a specialized option from maintenance, which sync >> only tags (without caption, rating, etc) >> >> > Do you still need more images. I can prepare a set next week (I am right >> > now away from my images). >> >> yes, you can always send me packs of image which create problems on >> your machine. > > Ok. > >> >> WARNING: Please call read tags before calling write tags. digiKam now >> simply delete everything before setting tags from database. > > Since taging is for some workflows important and time consuming to set up, do > we need a little research on how to make Tags in Digikam more robust? I would > hate to lose all my tags, just because I clicked two actions in the wrong > order. > >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On Friday 25 July 2014 15:07:00 Veaceslav Munteanu wrote:
> I can help you with some warning messages on bulk operations such as > options from Tags Manager and Maintenance. > > The write tags operation from Tags Manager is guarded by 2 warnings, > one describing and suggesting read before write. > Well, I guess this should be sufficient! :) Thanks, Wolfgang > I can't do more than this. > > Veaceslav > > > > On Fri, Jul 25, 2014 at 2:51 PM, Wolfgang Mader > > <[hidden email]> wrote: > > On Friday 25 July 2014 14:45:20 Veaceslav Munteanu wrote: > >> On Fri, Jul 25, 2014 at 2:38 PM, Wolfgang Mader > >> > >> <[hidden email]> wrote: > >> > On Friday 25 July 2014 14:32:47 Veaceslav Munteanu wrote: > >> >> Hello everybody. > >> >> > >> >> I want to thank everybody who sent me pack of images to test. I really > >> >> called them nuke pack, because they really had everything in them: > >> >> legacy tags, duplicates and obsolete tags :D > >> >> > >> >> Thanks to them I was able to reproduce a lot of issues and fix them > >> >> all. > >> >> > >> >> What I did: > >> >> > >> >> 1. Fixed more than 3 different scenarios in which digiKam could not > >> >> write > >> >> tags 2. Fixed IPTC being out of sync with XMP > >> >> 3. Fixed _Digikam_root_tag_ which appears in images tagged with old > >> >> version of digiKam > >> >> 4. Added extra deduplication when writing tags + logic to remove all > >> >> occurrences of _Digikam_root_tag_ > >> >> 5. Tested all packs received from users: All images contain fresh > >> >> clean tags after read then write > >> >> 6. XMP sidecar files also tested: read then write will remove any > >> >> inconsistency 7. Fixed Tags Manager write option, which was broken > >> >> 8. Tested all 3 options to read and write metadata: from maintenance, > >> >> from menu and from tags manager > >> >> 9. Tested face tags and read/write on them > >> >> 10. If you have large collections, use Tags Manager write option, it > >> >> will only write tags and process will be much faster > >> > > >> > Hello Veaceslav, > >> > > >> > thank you for your work on this. This is great news! In order to remove > >> > all > >> > tags from already taged images, do you recommend to use Tags Manager > >> > (your > >> > point 10)? > >> > >> Tags Manager use a specialized option from maintenance, which sync > >> only tags (without caption, rating, etc) > >> > >> > Do you still need more images. I can prepare a set next week (I am > >> > right > >> > now away from my images). > >> > >> yes, you can always send me packs of image which create problems on > >> your machine. > > > > Ok. > > > >> WARNING: Please call read tags before calling write tags. digiKam now > >> simply delete everything before setting tags from database. > > > > Since taging is for some workflows important and time consuming to set up, > > do we need a little research on how to make Tags in Digikam more robust? > > I would hate to lose all my tags, just because I clicked two actions in > > the wrong order. > > > >> _______________________________________________ > >> Digikam-users mailing list > >> [hidden email] > >> https://mail.kde.org/mailman/listinfo/digikam-users > > > > _______________________________________________ > > Digikam-users mailing list > > [hidden email] > > https://mail.kde.org/mailman/listinfo/digikam-users > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Veaceslav Munteanu-2
Hello,
Gilles, how should I update from repository ? https://www.digikam.org/download?q=download/GIT Should I only run ./download-repos again (after uninstalling my local version of digikam) ? Or should I uninstall all and the download repository again ? Veaceslav, Have you some case to test. I have a test collection with a lot of pictures (that I had clean with exiv2) and tagged with digikam since old digikam versions (2004), tags are not write to file since two years and cleaned with exiv2 due to those "tags" jam. I will try to launch some tests next week. Greatings, Eric Le mercredi 23 juillet 2014 à 20:06 +0300, Veaceslav Munteanu a écrit : > Hello, > > I'm once again fighting with tags and this battle seem to have no ending. > > I figured out that digiKam once again read data from 5 different > namespaces(IPTC, Xmp digikam, Xmp Microsoft, Xmp lightroom) and only > modify it to IPTC and own XMP namespace. > > This is bad because: > If you wipe -> trigger write and then read -> all deleted tags are back. > > Some users said that namespaces that are not from digiKam should not be touched. > Well this is impossible, you either: > > 1. grant digiKam to delete and modify all namespaces that it can read > 2. remove the ability to read from that protected namespace > > Any other combination result in total mess on read/write. > > I'm waiting for suggestions about do you prefer the most: 1 or 2 > > Veaceslav > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
2014-07-25 14:20 GMT+02:00 eric <[hidden email]>:
> Hello, > > Gilles, how should I update from repository ? > > https://www.digikam.org/download?q=download/GIT > > Should I only run ./download-repos again (after uninstalling my local > version of digikam) ? on directories where are source code use "git pull" to update source code from git/master > > Or should I uninstall all and the download repository again ? This is a radical way. It will work sure... Gilles Caulier > > > Veaceslav, > > Have you some case to test. > > I have a test collection with a lot of pictures (that I had clean with > exiv2) and tagged with digikam since old digikam versions (2004), tags > are not write to file since two years and cleaned with exiv2 due to > those "tags" jam. I will try to launch some tests next week. > > Greatings, > > Eric > > > > Le mercredi 23 juillet 2014 à 20:06 +0300, Veaceslav Munteanu a écrit : >> Hello, >> >> I'm once again fighting with tags and this battle seem to have no ending. >> >> I figured out that digiKam once again read data from 5 different >> namespaces(IPTC, Xmp digikam, Xmp Microsoft, Xmp lightroom) and only >> modify it to IPTC and own XMP namespace. >> >> This is bad because: >> If you wipe -> trigger write and then read -> all deleted tags are back. >> >> Some users said that namespaces that are not from digiKam should not be touched. >> Well this is impossible, you either: >> >> 1. grant digiKam to delete and modify all namespaces that it can read >> 2. remove the ability to read from that protected namespace >> >> Any other combination result in total mess on read/write. >> >> I'm waiting for suggestions about do you prefer the most: 1 or 2 >> >> Veaceslav >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users > > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Free forum by Nabble | Edit this page |