Keyword including an * asterisk
To aid a fast search I have use a keyword which includes an asterisk * character. A search in Lightroom or Photo Mechanic Plus finds all my *a images, not so in Capture One. C1 tells me there are 254 pictures using the *a keyword in the keyword panel. But selecting that keyword results in "No results for the current filter(s)". I have checked the search and it is only looking for that keyword.
Maybe C1 is using * as a regular expression and so my search fails for that reason? Any thoughts?
-
Interesting. I don't use *, but : for some keywords (such as "town:Rome") and while creating a filter that _contains_ Rome produces the correct results, a filter with the exact match produces nothing. So I share the "suspect" that some special characters might have a special meaning and perhaps they need to be "escaped", but I was unable so far to find a solution (I even posted a related question time ago - https://support.captureone.com/hc/en-us/community/posts/4405069534225-Colon-in-keywords - without any response).
I think at this point it makes sense to ask a question to the official support.
0 -
> David Gordon: Maybe C1 is using * as a regular expression
I would not think so. C1 uses SQLite3 databases. SQLite3 does not support regexp out of the box. It can be customized though. I have not seen C1 claim regexp support. *a is hardly a valid regexp anyway. The C1 filter options appear to build on traditional SQL equal, not equal, like and not like.
A simple test in C1 (version 20 on Windows 10) finds images with keywords containing asterisks and colons, including keywords like *a , te:st* and others I made up for the occasion.
Could it be a character encoding issue?
0 -
Fabrizio Giudici says:
I think at this point it makes sense to ask a question to the official support.
Yes, already have. If I receive a reply I will let you know.OddS. says:*a is hardly a valid regexp anyway.I don't know enough about this. Can it not mean find anything ending in 'a' ?A simple test in C1 (version 20 on Windows 10) finds images with keywords containing asterisks and colons, including keywords like *a , te:st* and others I made up for the occasion.My keywords were 'imported' from other applications (all Mac) and are in XML sidecars. But I did the following test. I have a folder selected and the Keywords panel tells me there are 9 images with *a. In C1 I added a *a keyword to another image. The panel now says I have 10. So far so good. But when I select that keyword to filter them "No results for the current filter(s)".So for me C1 doesn't recognise or find my *a keyword even when it was entered in the application.0 -
Yes, already have. If I receive a reply I will let you know.
Same for me (for colon).
I don't know enough about this. Can it not mean find anything ending in 'a' ?
If we are strictly referring to regexps, the correct syntax for anything ending in 'a' is:
.*a
The asterisk is not a generic "repeater" ("0 or more"), but the repeater of the previously defined element (which in this case is the dot, which means "any single char").
Your syntax is indeed a 'glob': https://en.wikipedia.org/wiki/Glob_(programming)
But independently of the specific syntax for matching expressions, glob or regexp, one might ask if actually Capture One is supporting some kind of similar functionality. Whenever I've searched in the docs I've found nothing about that.
0 -
> Fabrizio Giudici: ...the correct syntax for anything ending in 'a' is: .*a
Quite a few regexp engines would find that the regexp .*a matches the string "Fabrizio". The regexp .*a$ matches anything that ends in "a". It is probably safe to say that C1 does not support regular expressions.
In my mind the mystery is why my C1 finds keywords that has one or more asterisks and/or colons while your C1 does not. It may be computer or operating system related rather than a bug in C1.
0 -
Of course you're right, the $ "fell off" my fingers...
It may be computer or operating system related rather than a bug in C1.
It's possible. BTW, I recently upgraded C1 to the latest version and the current behaviour is that _contains_ "town:Rome" works, while _equals_ doesn't (zero results). It's a step forward, but still would include any town whose name starts with "Rome".
0 -
> Fabrizio Giudici: ...the $ "fell off" my fingers
That is what I reckoned, my first reaction was not to comment on it, but as there is at least one user less familiar with regexps reading the thread, I felt it should be cleared up.
> Fabrizio Giudici: It's a step forward, but still would include any town whose name starts with "Rome".
I know it does not help you much that I can not reproduce the zero result, but then I use the older C1 version 20 (build 13.1.4) on Windows. I did some more tests last night using your key:value form, including your keyword town:Rome and various other town:<town>. I tried with a space char prefix/suffix, but it still works with all reasonable combinations for _contains_ and _equal_ I could think of.
It should be possible to dig deeper to see if the Mac C1 actually queries the database at all when it produces zero results, and what the exact query looked like if yes. But I seriously think C1 developers should do that.
0 -
OddS, I appreciate your contribution and correction of my imprecise answer.
For what concerns Windows/macOS, it's possible that we have a dual behaviour. Theoretically I can run Windows on a virtual machine (I have one in the archives, but I haven't used it for more than a year), so as soon as I find some spare time I could install Capture One on it and have a try.
0 -
For the record I asked the support about the colon and I got this answer (summarized):
«Yes, the colon is indeed a problem since it can affect the way Capture One searches for a keyword.»
0 -
For the record I asked the support about the colon and I got this answer (summarized):
I also asked and have yet to receive a reply. How long did they take to reply to you? It's been well over a month.
I wonder why I haven't upgraded to C1 22. Or installed C1 on a new Mac. TBH I no longer GAF about C1. Nice app but too much trouble to deal with. Using LrC.
0 -
Is there anything wrong with using the IPTC fields for information like which Town is related to the image location?
It seems to me it would be more portable across systems and applications with search functions. Useful if used for finished and exported images.
0 -
Is there anything wrong with using the IPTC fields for information like which Town is related to the image location?
That's exactly what the IPTC location fields are for. See https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-2021.1.html#location-structure
0 -
> stoppingdown: Yes, the colon is indeed a problem...
Thank you for coming back on this. Did they point to the user guide/manual? I can not remember seing it. If C1 follows good practice, they would likely provide some way to escape the special handling of colon and other characters.
0 -
They pointed to this document:
... which as far as I can see doesn't mention colon and maybe it's not entirely pertinent to characters in keywords. Lol.
Yes, there should be some way to do character escaping, but I didn't receive any suggestion.
I have the feeling that their support is under stress in these days, probably for the issues related to C1 22 licensing. In any case this is what I got and I'll see how to work around it. BTW at the moment I'm very busy with my job and have no time to deal with my photos...
0 -
David Gordon, they took some time to answer - I think they are under pressure.
David Gordon, SFA: there are multiple problems with IPTC, that for this use case doesn't fit with my needs.
1. https://iptc.org/std/photometadata/documentation/userguide/#_locations
The original ‘Location' fields in IPTC (Core) do not distinguish between the location where the image was created and the location shown in the image. The IPTC Location Created and Location Shown field structures were added later to remove this ambiguity.
AFAIK C1 has got only the generic Location field. Other apps have both - e.g. Photo Supreme (and it correctly supports the capability of having multiple Location Shown).
2. In any case, Location Shown has only a generic Sublocation that carries a name; my schema also includes the designation of the class of the object, for instance a church or a castle, or a mountain. Basically my tag is "class:name", such as "cathedral:Notre-Dame", "mountain:Monte Bianco", so I definitely need the colon.
3. I use this schema also for entities that are not a place, such as taxonomic scientific names for animals or plants (there is a standard stuff named Darwin Core for that, but C1 doesn't support it - and anyway DwC only supports a single taxon for photo, while I need multiple ones e.g. when I take a photos of a butterfly on a flower).
0 -
2. In any case, Location Shown has only a generic Sublocation that carries a name; my schema also includes the designation of the class of the object, for instance a church or a castle, or a mountain. Basically my tag is "class:name", such as "cathedral:Notre-Dame", "mountain:Monte Bianco", so I definitely need the colon.
Sounds like an incorrect use of the field to me. I'd have Monte Bianco as the sublocation and 'mountain' as a keyword. Maybe the folk at Controlled Vocabulary would have something to say about this. https://groups.io/g/ControlledVocabulary
C1 has a reputation for being poor when it comes to DAM. Which is a shame and odd as they bought iView which was very good. Maybe you should be looking at a better solution for DAM and keep C1 for processing. Photo Mechanic Plus for example.
0 -
stoppingdown,
Maybe it's my messy mind concept but I have never been a great fan of highly specific tags. Unless they are very necessary for some specific scientific reason.
Your "Location" point is valid, depending upon the subject matter, though many in need of identification of both positions- - subject and shooting location when they are not the same - would probably be thinking in terms of using geo-location for the shooting position and the name (or names?) of the significant subjects shown in the resulting image.
I prefer separate keywords, often but not always resulting from a hierarchical keyword structure. The benefit being that using the lowest level of KW allows selection of the hierarchy that will fill the values before it with no further effort. If necessary a keyword can be a phrase so spaces are fine - as you illustrate in your example.
If the resulting images are to be shared with others complete with metadata relating to content such as keywords if seems very likely, outside the constraints of scientific standards, that simple separate keywords, possibly in multiple languages, might be the more widely useful option for us by the uninitiated. Or at least that is the assumption I tend towards.
Using Google search as a testbed, if I use the search "cath notre" the screen instantly fills with references to the Cathedral of Notre Dame (Notre-Dame with or without the hyphen.) The one in Paris has the dominant number of entries but the same-named Cathedral in Luxembourg also appears.
Leaving out the "cath" part widens the result for Google since the words and especially the name are common and have been appropriated for many other places structures and facilities around the world. However, for a more constrained set of potential subjects, like a local set of images, that would not be an issue in many cases.
Handing over references to larger libraries leads to different, global-audience aware considerations probably best left to the Library or the search engine to deal with. Mont or Monte or Mount all pre-identify a mountain although also having an independent KW for "mountain" would likely provide cleaner search results when the name or "identification string" has also been used for other places or objects. Whether combining the 2 levels of identity - mountain and name of the mountain - as you do is entirely necessary for general use is open to discussion.
I think the general approach for search engines is to ignore "punctuation" (unless it is a character used for a specific purpose and so unwise to use it for "text"). Thus one can use a space rather than a colon in a "keyword". Or rely on "contains", as most search engines seem to do by default to some extent.
The day the entire population of the world is considered competent to work with regex commands would be the point at which some sophisticated mass use tagging and searching giving very precise results will become possible.
Basically, C1 allows the creation of KWs and potential addition using hierarchical structures to make the task of admin quite easy but then sets out to treat the result entries as a flat collection of KWs that can thus be connected in any way necessary. The structured addition and potential for unstructured application in searching probably offer the best usage experience for most users - or at least most of the users who bother with KWs (and metadata) at all.
0 -
I'd have Monte Bianco as the sublocation and 'mountain' as a keyword.
If you decouple the name from the class, ambiguities might arise. For instance you can have castle:Bianco and mountain:Rosa in the same photo. If you just use the 'mountain' keyword disconnected from Rosa, a search for monte Bianco designed as 'contains keyword mountain and contains sublocation Bianco' would erroneously pick that photo.
I would probably be thinking in terms of using geo-location for the shooting position and the name (or names?) of the significant subjects shown in the resulting image.
I actually use geo-location. Yes I could assume that IPTC Location is Location Shown since Location Created is in geo metadata, but other software applications handling the same metadata would still interpret that IPTC data as ITPC created... (I actually use other apps in addition to C1).
i>but not always resulting from a hierarchical keyword structure
The point is that my keywords come from an application that I wrote on my own several years ago (circa 2010) and used hierarchical RDF semantic metadata. It was the only DAM app that really fit my needs, but at some time I couldn't find the time to keep on with development, so I had to give up and move to Lightroom. I had to use "simple" keywords and mapped the previous data with the scheme I'm talking to. Then exported to C1 when I dropped Lightroom. I can't figure out a scheme of keywords that isn't like that.
0 -
"If you decouple the name from the class, ambiguities might arise. For instance you can have castle:Bianco and mountain:Rosa in the same photo. If you just use the 'mountain' keyword disconnected from Rosa, a search for monte Bianco designed as 'contains keyword mountain and contains sublocation Bianco' would erroneously pick that photo."
Sure.
But how many times would that be a major problem for you? And could you not resolve those occasions where it might be annoying by using a "does no include" option ? Or simply specify an additional criterion that included what you want and excludes what you do not want?
There are other approaches but the discussion can get a bit too complex without being able to run interactive searches related to the discussion.
I do understand that you would very much prefer to continue to work with the system you developed - I guess we all would. But I don't think C1 necessarily excludes that, though it may be a little ugly setting it up in a search.
I'm thinking here about getting past a current limitation with what is available rather than waiting in anticipation of what the future might hold.
0
Post is closed for comments.
Comments
19 comments