Skip to main content
U
umlautnord
Inspiring
February 13, 2024
Question

Issue searching by file name for Enhance/Denoise-created dngs and dupe filename imports

  • February 13, 2024
  • 1 reply
  • 463 views

I'm running into a fairly annoying issue when searching for an image by file name. Search doesn't work properly with images that Lightroom generated or renamed from another image in some circumstances. I'm hoping there's a way of searching for those images that I've missed. Or, that there's a fix in the pipeline.

 

Two examples of Lightroom "creating" a new image that result in an issue:

 

- Denoise creates a new dng with a new filename: It'll create APC_0043-Enhanced-NR.dng from Enhance/Denoise on APC_0043.dng.

- Lightroom renames images on import if another image already exists in the library with the same filename. For example, if IMG_0112.jpg exists, Lightroom imports a new/different IMG_0112.jpg as IMG_0112-2.jpg.

 

Those new filenames are what Lightroom shows as the file name in the info pane. They're also used as the "original" filename if you're using that in the Export functionality. Everything makes sense to this point.

 

But search doesn't operate as I'd expect:

 

- If I search for APC_0043-Enhanced-NR.dng or IMG_0112-2.jpg, I would expect to get only that image. Instead, I get a host of images vaguely related in time/space/filename/? to the single image I want. I assume this is Sensei stepping in. The number returned depends on the image I'm searching for, but is commonly well above 50. Usually, the one I want is buried somewhere in that mess, but it's not at all useful.

 

What sort of works/current workaround:

 

If I search for the original/source file name, I only get all of the images directly related to that original file name in some way. E.g.:

 

- If I search either for APC_0043.dng (or just APC_0043), it returns both APC_0043.dng and APC_0043-Enhanced-NR.dng. (Only those two images, no extraneous stuff.)

- If I search for IMG_0112.jpg (or just IMG_0112), it returns IMG_0112.jpg and IMG_0112-2.jpg.

 

This workaround is helpful, as it doesn't retrieve anything truly unrelated. But it's not great—to get APC_0043-Enhanced-NR.dng, I need to trim the desired file name down to what I see/believe an "original" file name was. Once that revised search term gets me the images that are at least directly related, I then have to individually select each one and look at the info pane to find the exact file name I want. (Note that I also have to go through that if I only want APC_0043.dng or IMG_0112.jpg, too—since those search terms retrieve both the original and the enhanced/import dupes!)

 

Am I missing something in how to use the search tool, or a better workaround? Is this intended behavior? What field is it actually searching?

 

--

 

Issue seen on Lightroom Desktop (v7.1.2), Lightroom Web, and Lightroom Mobile (iOS, v9.1.1). For Lr Desktop, running MacOS Sonoma v14.3.1, although this has happened on earlier versions of MacOS.

 

Note: Not an issue caused by Sensei taking a while to index/tag newly "created" enhanced/dupe-filename-import photos. This is a consistent issue with images that have been in the library for weeks/months.

 

    This topic has been closed for replies.

    1 reply

    Jim Wilde
    Community Expert
    Jim WildeCommunity Expert
    Community Expert
    February 13, 2024

    Like you, if I search using the complete filename of an enhanced file I get that image and multiple related images (70 in one case), but if I search only for filename-enhanced (i.e. without the -NR.DNG) I get the single image that I was looking for. Using your example, yes searching just for apc_0043 would produce both the original raw and the enhanced version, but searching for apc_0043-enhanced would produce just that one single image. Certainly odd, but it does seem to work.

    U
    umlautnordAuthor
    Inspiring
    February 13, 2024

    Oh, that's really weird. Very good to know that I don't have to pare the filename back all the way on the enhanced ones, at least, and can get them specifically that way.

     

    Jumping off of that, I am realizing that I think all of the 70+ extra images that result when I search for "apc_0043-enhanced-nr" are "apc_####_enhanced-nr" file names. And all of the 600+ images that result when I search for "IMG_0112-2.jpg" appear to have "2.jpg" in the filename. Some of them are IMG_####-2-2.jpg.

     

    It seems the search tool is likely interpreting things outside of a standard logical "match X term, use and/or, treat certain characters as spaces" system when deciding when to be loose in its interpretation and when not to be. It's so counterintuitive that having a longer search term that still matches one specific file (ie, adding -NR) suddenly opens up to everything with that structure and number. There's no specific standard logic I can see that works across all of these cases.

     

    This may be just the joy of working with an AI that's still learning. 

     

    Short of changing how Sensei is parsing things entirely, it seems like just having a "filename" operator (ala "Extension:" and "Orientation:" and the like) would be quite helpful so that there was a way to do a strict search outside this more... interpreted... experience.

    U
    umlautnordAuthor
    Inspiring
    February 13, 2024

    Oh. Well. It definitely is just a learning AI... and, apparently if you try to communicate with it more conversationally/like an AI, it works better.

     

    If you enter "exactly IMG_0112-2.jpg" or "exactly apc_0043.dmg" or "exactly apc_0043-enhanced-nr.dng" it works, well, exactly as you would expect. To the point where "exactly apc_0043" on its own doesn't return anything.

     

    But, it doesn't seem to understand "includes" or "contains" yet, so "contains apc_0043" or the like doesn't return anything. Based on the other results, I assume that's all AI and not just a hidden "exactly" operator...?

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices