Search for IMG_3234 returns IMG_0216 while in Categories View

[kiwilink]

While I was in the Categories view I did a search for IMG_3234 and it turned up IMG_0216.  Any idea why it would return this image also? (I looked in the Metadata and didn't see it).

Thanks

Michael

P.S.  When I do the same search in the "Media and Folders" view it returns IMG_0216 also.

[attachment deleted by admin]

[Mario]

The Search Bar uses the search engine to search all metadata. Does the file in question contain the search term anywhere? Check the Metadata Panel with the Browser layout selected to see all data in the file.

[kiwilink]

Mario:

Thanks for the response.  That was the first place I looked.  I turned on the Metadata panel and slowly looked for the words "IMG_3234" and I don't see it anywhere.

Is there someplace else I can look?

Michael

[Mario]

If the value does not show up in the Metadata Panel using the Browser layout, it should not be found.

So far this is the first ever problem report about the search function as far as I recall.

Did IMatch perhaps crash while you worked with that database?
Did you copy/paste metadata between files?
Do you use versioning?
Anything that may copy metadata between files?

Do this:

Secure the database by copying it (while IMatch is not running). This way we have it for further analysis.


Then open the database again and do a Database menu > Tools > Rebuild Search Engine Index.

This re-creates the index from the metadata in the database.

[Gerd]

Dear Mario,
can it be, that the underscore-sign (_) is used in a special way, e.g. as separator?

If I search for D_16, I get nothing (screenshot 1), if I use 7D_16, a result is found (screenshot 2). The meta-data of this picture contains severel times 7D and also 16, but not 7D_16 or D_16.

These both are only used in the file-name of this picture, but not used to find it ...

Regards
Gerd


[attachment deleted by admin]

[Mario]

Did you see the search bar syntax explanation in the help?

The search bar uses the full-text search engine. This engine is blazing fast even for 100,000 files but requires a special syntax.
You cannot search for partial words without using *

You cannot search for Mario by typing ario
To find Daytona you cannot type Day but you must type Day*

See the help for details.

[Gerd]

Dear Mario,

the picture-name is 2013-01-01_I7D_4402.JPG ...

It is NOT found with D_16, but found with 7D_16, but this string is not available in the picture-name. It is also not available in the whole meta-data ...

Why is then this file be found??? If I specify "7D_16", then I do not expect, that it was searched for "7D" ....

Regards
Gerd

[Mario]

The _ in your query is the problem. The search engine splits your query for

7D_16

into a query for two words

7D and 16

so all files containing 7D and 16 anywhere will be found.

The search engine is tuned for word-based high-speed searches. E.g. find all files containing beach AND vacation.
Specialties like looking for full phrases containing _ - or other special characters are better done using the file name or metadata filters.

[Gerd]

Yep,

that's what I told ... and that is the problem from kiwilink and me and all the others, because most images are using the underscore in the picturename ....

Regards
Gerd

P.S. a little workaround can be, to use the space instead of _ e.g. IMG 2382 jpg ... it looks like, that the space is used as 'and'-operator ...

[Ferdinand]

The _ in your query is the problem. The search engine splits your query for

7D_16

into a query for two words

7D and 16

so all files containing 7D and 16 anywhere will be found.

The search engine is tuned for word-based high-speed searches. E.g. find all files containing beach AND vacation.
Specialties like looking for full phrases containing _ - or other special characters are better done using the file name or metadata filters.

I recall that this was raised in the *very* early beta testing days.  You (Mario) were reluctant to change it at the time.  I'd still like this behaviour changed, so that _ isn't treated as a separator, if it's possible. 

[ChrisMatch]

Maybe not the best way to find new friends 
but I think I would prefer the _ to be used as as separator.

Hmm, maybe we could use a syntax similar used in other search engines...
If we want to search for an exact phrase use "this_and_nothing_else"?

[Mario]

The search engine is not developed by me. Changing how it parses search terms and breaks phrases into words would require me to develop my own extension for the database core. I maybe look into this when I have a couple of weeks of free time to spend on this. Please add a feature request.

Until then, I suggest you use the search box as it is designed. And when you want to search for file names, use the much better suited file name filter. Which not only supports special characters like _ and - but also simple searches, contains searches, and even regular expressions.

[kiwilink]

Thanks for all of the responses.  I did a search using *3234 instead of IMG_3234 and attached is what I got (a new image IMG_4072).  I guess it found this IMG_4072 because the number 3234 is in the DocumentID field in the Metadata.  I'm not sure where this number is derived from (Document ID) but that probably explains why it found this image.

However, what is puzzling is that it didn't find IMG_0216 like it did when I did a search using IMG_3234.  I would assume it would find it with both searches.[/color]




Mario, you asked me
Did IMatch perhaps crash while you worked with that database?   Yes, but I reloaded the database last week.
Did you copy/paste metadata between files?  No, I did not copy or move any Metadata.
Do you use versioning?  I don't use versioning.
Anything that may copy metadata between files?   Not that I am aware of


[attachment deleted by admin]

[Gerd]

Hi Kiwilink,

why did you not use IMG 3234 instead of IMG_3234?

Regards
Gerd

[kiwilink]

Gerd:

Thanks for the reply.  I did try this also and I still got IMG_3234 and IMG_0216 (see attached screenshot).

I checked the database and I got database errors (see attachment "databasehaserrors").  I also attached the "IM5diag".  I re-ran the database check and now there are no errors.

I then ran a search again for IMG 3234 (just a space, no Underscore) and II received the same thing as attachment 1 (IMG 3234.png)

Mike

[attachment deleted by admin]

[Gerd]

Hi kiwilink,

can you try all three: IMG 3234 jpg

What do you get then?

Regards
Gerd

[kiwilink]

Gerd:

Thanks for the reply.  I tried:

IMG 3234
IMG 3234.jpg

IMG_3234
IMG_3234.jpg

I get the same result (2 images, IMG_3234 and IMG_0216

Michael

P.S.  I created a new database in IMATCH5 and I copied only one picture into the database (IMG_0216) and then I did these same searches and it did not find anything.  Really strange!

[Mario]

IMG 3234

means you are looking for files containing IMG or 3234 somewhere in the supported metadata tags. IMG is very common and 3234 is also very likely to show up somewhere in a maker note or XMP field. Check the metadata of the results. So far the search engine was always right in my tests.

If you are unsure, send me the files and a list of searches you run and I will add them to a database. Since I'm currently working at the bottom of the bug list it may take a while before I can further respond to this.

Again, for searching for file names as you do, the file name filter is the tool of course. I may even remove file names from the search engine index in the future, concentrating on metadata alone.

[Gerd]

Hi Mario,

that might be the best idea, to remove it. It is much more better, to get a clear interface-structure, so you now what you can do where. Overlapping functions with different parameter setup leads to confusion.

Regards
Gerd

[ChrisMatch]

that might be the best idea, to remove it.

For me the filename contains very relevant information that may not be found in the meta data.
This is the cause for files that are many years old (before I used DAM software and keywords) and for files that have not yet been catgorized with iMatch.

So at least I would like to:
- keep the filename as part of the search (or have an option for that) OR
- have a simple way to transfer parts of the filename into the metadata
  (this may well be already possible - I have not thought about this yet).

[Mario]

Many users want to include the file name in the search. Users who have project codes int he file name, for example. Or other information.
If you only want to search for specific metadata, use one of the groups to limit the search bar (see IMatch help for details).

If you have created difficult file names for a word-based full-text search (e.g. containing _ or -) you can instead use the file name filter for precise and controlled results.

have a simple way to transfer parts of the filename into the metadata

Just use a Metadata Template to copy the file name variable into a metadata tag of your choice (XMP preferred). Using formatting functions you can extract, case-convert etc. the file name in many ways.

See the default Metadata Template Set Object Name / Title" from file name for example.

[kiwilink]

Mario:

I have attached the image (IMG_0216) as you requested so you can test this and see whyit comes up in a search for IMG_3234.

Thanks!

Michael

[attachment deleted by admin]

[Ferdinand]

It didn't work here.  Either there's unwritten metadata, or a missing sidecar, or some of the metadata was stripped in the upload and you'll have to zip the file.

[jch2103]

Yes, the upload process seems to strip metadata. Apparently, zipping files is necessary to preserve metadata.

[kiwilink]

OK ... I exported it via IMATCH5 and saved all Metadata with the file and created a ZIP file.

It is attached.

[attachment deleted by admin]

[Ferdinand]

Still no work

[kiwilink]

Ferdinand:

Thanks for the reply.  Can you clarify when you say "Still no work".  Are you referring to missing Metadata?  I just brought in the picture into IMATCH5 from the zip file and I se lots of metadata.

If you are referring to "Still no work" as my original problem where this photo appears when searching IMG-3234?

Thanks!

Michael

[Ferdinand]

A search for IMG-3234 does still not find this file. 

What happens if you create a new DB with just this file and try?  Are you sure that there isn't a sidecar for this file?

[kiwilink]

Ferdinand:

Thanks for the response.  I have decided to follow Mario's advice and just use "Filter", Filename, "contains" as he suggested. 

I do not use sidecars and I have searched and searched on the metadata for the number 3234 in Image 0216 and I don't see this number so I'm not sure why it came up.

Thanks for trying to help!  I appreciate everyone's input!  I'll move on to other testing issues.

Thanks!

Michael