Announcement

Collapse
No announcement yet.

Rapid Deletion of Keywords from Keyword List

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Rapid Deletion of Keywords from Keyword List

    I did something, and it caused ACDSee to duplicate every keyword in my database, then apply all of those new keywords to every photo (6,400+) in an entire folder. The extra keywords are only in ACDSee and not written to the files, so I'm ok there. Also, they don't show up when I select all of the files in the folder, but they do for each individual photo when selected alone. There are so many keywords that it fills the keyword window and obliterates all of the keyword list entries, so I can uncheck anything. When I try to manually delete a keyword, it takes an average of 1:30 to delete a single keyword. At that rate it will take me days at the keyboard to delete them all. Is there a way to delete multiple keywords at a time, or a faster way to delete one at a time?

  • #2
    Well, if all good keywords (and other metadata information) are in the files and all bad ones just in ACDSee DB, start from a new ACDSee database getting metadata from files?

    Comment


    • #3
      I thought of that, but the 6000 photos that got screwed up don't have the metadata written to them yet, (I was preparing to do that when this happened) so I would have to spend a week or so re-keywording them, or a week or so deleting the extra keywords.

      Comment


      • #4
        [email protected]

        ACDSee will normally not allow you to create duplicate ACDSee keywords in the first place, so I would not have a lot of confidence in the integrity of the existing database.

        Click image for larger version  Name:	New Keyword.jpg Views:	0 Size:	45.3 KB ID:	61136

        If they really are exact duplications then creating a new database as suggested by brajaq and Cataloging the metadata back from those images that do have it embedded, would be the safest way to go.

        Before doing that however, you could perhaps use Tools\Metadata\Export Keywords to export a list of the keywords to a text file, and see whether the duplicates show up in that listing. If they don't it might be worth forcing ACDSee to recreate its indexes. see https://support.acdsee.com/en/suppor...il-cache-files
        Last edited by Greyfox; 07-17-2022, 04:43 PM.

        Comment


        • #5
          Thanks for the tip. ACDSee didn't exactly duplicate the keywords. It created new ones with "/i" in front of each one and "/i0" at the end. It also put them all at the top level, and didn't replicate my hierarchy.

          Comment


          • #6
            Update: The extra items were in the Keyword export, so short of creating a new database, which would force me to do a lot of repeat work, because not all the files had ACDSee data embedded in them, I didn't see an answer. I just took the opportunity to clean the extras out and reorganize my keyword list. It took about 11 hours to delete the erroneous keywords because each delete operation took a minute and a half to complete. Each delete should take a few seconds. I work in software development, and at my place of work, a minute and a half to delete a record from a database is called an "outage"

            Comment


            • #7
              Originally posted by [email protected] View Post
              .. I work in software development, and at my place of work, a minute and a half to delete a record from a database is called an "outage"
              To be fair, it isn't just a simple deletion of a record. It is the locating of the individual database entries for all of the 6400+ image records you indicate each of these keywords were assigned to, the rewriting of each of those database records to remove the keyword, and the updating of whatever indexes are relative. The time that takes will depend on the size of the collection, the resources of the computer, any read/'write/transfer rate restriction that applies to the media the database is on, and the state of the database itself.

              That aside, the format of the "rogue" keywords from your description (using a leading "/i" and a trailing "/i0" as delimiters?) appears structured, but it's not a structure I've seen produced by ACDSee in all of the years I've been using it. I know you said that you hadn't yet had ACDSee embedded the rogue keywords in the images, but have you actually examined the metadata content of these images in ExifTool to see whether it is actually in the images (from procedure or previous other software involvement), and being read back into ACDSee (as it might be if you carry out a Database\Catalog run at some future time). Obviously you would not want to have a repeat of this issue, so finding out exactly how it occurred in the first place could be quite important.

              Comment


              • #8
                So when a keyword is edited or deleted, is the change propagated to the photos embedded metadata as well?

                For background, I spent part of my career as a database administrator, and this type of operation is called a "cascading delete" and should be relatively fast, on the order of a few seconds at worst, which is what spurred my previous comments. So if it is a cascading delete, and just operates on the database, it should be significantly faster. If it inspects the embedded metadata on each image, I would expect it to be a lot slower than it actually is because ACDSee would have to read and inspect and potentially re-embed ACDSee metadata to every affected image file.

                As far as the rogue keywords go, I have examined the metadata that is embedded in the images that show the rogue keywords in ACDSee. I don't do automatic embedding, so the rogue keywords were not embedded. I also looked deeper into the rogue keywords and found that in some cases, the entire hierarchy tree was entered as a single keyword. For Instance Camera>Olympus>OM-1 was listed as a single new keyword "CameraOlympusOM-1", without the leading and trailing delimiters. Those constituted about 10% of the cases.

                I ended up spending about 11 hours manually deleting the rogue keywords, and also took the opportunity to streamline my keyword structure. I also created a metadata preset to clear out any embedded metadata and replace it with the new keyword assignments, so the old ones should not return if I re-catalog a folder or create a new database.

                Comment


                • #9
                  Originally posted by [email protected] View Post
                  So when a keyword is edited or deleted, is the change propagated to the photos embedded metadata as well?
                  ACDSee keywords: No, it does not remove the keywords embedded in the images..

                  ... this type of operation is called a "cascading delete" and should be relatively fast, on the order of a few seconds at worst
                  As I said in my earlier post, "The time that takes will depend on the size of the collection, the resources of the computer, any read/'write/transfer rate restriction that applies to the media the database is on, and the state of the database itself." The deletion of a single 12 character keyword from 5018 items that it has been assigned to, in one of my collections that has just over 30,000 items is taking only 2.86 seconds, and I personally don't have a problem with that. That is using the current ACDSee Ultimate 2022 version.

                  As with all software, some will be satisfied with the performance they experience, some will not.
                  Those that are not can, and should, raise support tickets detailing where they are experiencing less than desirable performance, and asking whether it can be improved, but for the moment, and most probably at least for the life of the current version, the reality is that "it is what it is".

                  I have examined the metadata that is embedded in the images that show the rogue keywords in ACDSee. I don't do automatic embedding, so the rogue keywords were not embedded. I also looked deeper into the rogue keywords and found that in some cases, the entire hierarchy tree was entered as a single keyword. For Instance Camera>Olympus>OM-1 was listed as a single new keyword "CameraOlympusOM-1", without the leading and trailing delimiters. Those constituted about 10% of the cases.
                  That suggests to me that the issue has more likely occurred as the result of some assignment issue, rather than a corruption of existing database entries, but sadly I have no idea what would cause that. In all the years I have been using ACDSee, I've never experienced anything like that at all.

                  Out of interest, are you assigning keywords by selecting images and then ticking the keyword box in the properties, organize tab, or by selecting the images and drag/dropping them onto the keyword in the keywords section of the Catalog tab?

                  Comment


                  • #10
                    I agree with you that some assignment issue could be at fault. I was updating images using a metadata preset to copy existing ITPC keywords from images edited years ago in Aperture to ACDSee keywords when this happened. This has the potential to cause issues with circular updates if it is run after with the one I have that copes keywords from ACDSee to ITPC keywords. You can see the potential for disaster there. I double checked the preset,and ran it again on a small subset of images, and it worked perfectly, so I'm at a loss there, but I can't rule it out as the cause.

                    I'm assigning keywords by selecting images, then picking the keyword from the Organize tab in the properties pane. I also have two metadata presets that I usually run after I assign keywords, that copies any digital camera data to keywords, and another that copies the ACDSee categories and keywords to the IPTC Keywords field.

                    The deletion of a single 12 character keyword from 5018 items that it has been assigned to, in one of my collections that has just over 30,000 items is taking only 2.86 seconds, and I personally don't have a problem with that.
                    The numbers that you are seeing are the numbers that I would expect to see from a large delete operation running on a PC. My collection is about the same size as yours, so I tried to reproduce your results. I created a 12 character keyword (called "12 Character") and assigned it to1205 images. Assigning it took less than 1 second. So far so good. Then I clicked to a different keyword and back again. The time from when I clicked on the "12 Character" keyword until the images associated with it showed up was 56 seconds. Then I deleted the keyword by left clicking on the keyword in the catalog pane and choosing delete. It took 26 seconds for the confirmation dialog to appear, and another 54 seconds for the keyword to be removed. I tried the experiment again but using the Keywords pane instead of the Catalog pane. Again, assigning the keyword was very quick, less than 1 second. When I clicked away and selected the keyword again from the catalog pane, it took 1 minute 21 seconds for the images to appear. Unassigning the keyword took about 1 second. Left clicking the keyword in the keyword pane, this time with no images assigned to it, and selecting delete, it took 46 seconds to complete, with no confirmation dialog showing up.

                    So this is telling me that there could be some kind of database optimization issue going on. So I optimized the database, optimizing thumbnails and removing orphans. Then tried the experiment again. Then I assigned the keyword to the 1205 images. and clicked out and back in. This time it took 26 seconds for the images to appear, a definite improvement. Then I unassigned the images from the images, which took about a second. Then I deleted the keyword by selecting it in the keyword section of the organize pane and clicked delete. It took 51 seconds to delete the keyword.

                    There is something funky going on here, but I'm clueless as to what. At this point I'm thinking of doing the old uninstall/reinstall trick to see what that does.

                    P.S I love ACDSee, it just drives me crazy sometimes.

                    Comment


                    • #11
                      Here's the latest update:

                      I tried the uninstall/reinstall. It made the problem significantly worse by adding a new problem. Upon startup, ACDSee will work for 3-4 seconds, then freeze altogether for about 30 seconds. This pattern then repeats for about 5 minutes, rendering the software completely unusable until it completes.

                      I tried the "12 Character" test again. This time it took 26 seconds for the confirmation window to appear, and 54 for the keyword to be removed, so uninstalling/reinstalling had pretty much no impact.

                      FYI, I've verified that it isn't a network issue by duplicating the test on the mac version. It completes in about 2 seconds.

                      Next up, I'm going to try creating a brand-new database.

                      Comment


                      • #12
                        Originally posted by [email protected] View Post
                        Upon startup, ACDSee will work for 3-4 seconds, then freeze altogether for about 30 seconds. This pattern then repeats for about 5 minutes, rendering the software completely unusable until it completes.
                        On startup here, ACDSee U2022 displays its splash screen for about 1.5 seconds, before showing the Manage mode Screen. The 1.5 second is partially dependent on the on line connection (Message Center update, licence check ?), and is a bit shorter if the Ethernet Adapter is disabled. I have ACDSee set to always start on a specific "Home" folder which is on a local SSD drive.

                        When yours starts up, in Manage Mode if you see any of the following in the bottom right hand corner of the Manage mode, it indicated that ACDSee is currently building thumbnails, or working through queued face recognition.. You can terminate this moving from Manage mode to any other mode, but this particular activity in Manage mode can be fairly intensive.

                        Click image for larger version  Name:	Work in progress.jpg Views:	0 Size:	62.2 KB ID:	61332

                        If it is working on face recognition, you can clear the queue, or simply let it finish the task. This tends to be more an issue when first enabling face recognition in ACDSee, and particularly on large collections. The help file explains this process. (Help Menu item "Detecting Faces in Manage Mode".

                        Each time you change the size of the manage mode thumbnails, ACDSee will update its thumbnail cache for the displayed thumbnails. If your display criteria is large (for example "Image Well") this this can take a significant time.

                        Next up, I'm going to try creating a brand-new database.
                        Hopefully that will solve the issues you are having.

                        Comment

                        Working...
                        X