photools.com Community

IMatch Discussion Boards => AI, FAQ, Workflow, Tutorials, Tips & Tricks => Workflow => Topic started by: Stenis on June 11, 2025, 12:05:37 AM

Title: An example: Where poor keyword-workflow issues can take you if you are unlucky
Post by: Stenis on June 11, 2025, 12:05:37 AM
Read this: https://forum.dxo.com/t/some-database-querying-tools-that-you-might-find-useful/50526

This example is from DXO Forums where people tries to cope with a very poor and archaic "PictureLibrary" in the RAW-converter DXO Photolab ith different emergency solutions. I refuse to call it a Photo-DAM, because it lacks even some of the more basic functions we are taking for granted in iMatch. Photolab is maybe the worst example but even Lightroom and Capture One has their problems and limitations.

One part of the problem is also the very poor interest the DXO staff has in their own DXO Forums. The difference compared to these user forums are enormus.
Title: Re: An example: Where poor keyword-workflow issues can take you if you are unlucky
Post by: PandDLong on June 11, 2025, 07:11:33 AM
That was an eye-opener - it all sounds very painful!  Thanks for sharing.

Michael
Title: Re: An example: Where poor keyword-workflow issues can take you if you are unlucky
Post by: Mario on June 11, 2025, 08:33:33 AM
Doing DAM right is hard!

And for DxO and C1 (even Lr) it's only a side-show. They concentrate (and should) on image editing and producing the best quality from RAW files.

My drill press cannot do what my planer does. Each tool does the job it's designed for to perfection.
Title: Re: An example: Where poor keyword-workflow issues can take you if you are unlucky
Post by: Stenis on June 12, 2025, 02:01:01 AM
I think you ought to read this tread carefully to see just how lost many DXO Photolab PictureLibrary users are today when it comes to their efforts to cope with the problems DXO has not managed to solve when it comes to metadatamanagement. I think DXO and Photools has a lot to gain from a life more in symbiosis than today because I see a lot of synergies there.


https://forum.dxo.com/t/some-database-querying-tools-that-you-might-find-useful/50526/33

This is about how both Adobe (Lightroom) with all its billions and market leader and industry standard software vendors like CameraBits (PhotoMechanic) have failed to solve the bottleneck problems that you a one man company have solved with iMatch. It is a comment on what is always said in apologies for DXO been a small company as an explanation for not fixing the problems the users are having with Photolab PictureLibrary. This is about being a small company this is about commitment and skills that are lacking and that goes even for a giant like Adobe.


https://forum.dxo.com/t/some-database-querying-tools-that-you-might-find-useful/50526/52

This is about how the productivity problems with the Descriptions and Keywords can be solved in a proper and holistic way with iMatch without leaving the users to turn to emergency solutions like the tread owner Freixas is trying to solve with SQL-queries or Joanna is trying to solve with the keyword-application she has made herself which she is running in parallell with Photolab!! to solve the problems Photolab hasn´t solved.


https://forum.dxo.com/t/some-database-querying-tools-that-you-might-find-useful/50526/54

This is really a call for you Mario and DXO to do something together (sell bundles - get in synch) and for the users that takes metadata serious but are stuck with Photolab´s poor PictureLibrary and apparently don´t know about anything else than Photolab or with Lightroom for that matter.

The reason I write this is that you really have a golden opportunity when so many are realy pissed with Adobe of a lot of reasons now to offer a joint scalable solution with Photolab AND iMatch that solves all the problems the users are trying to solve at DXO Forums. Nothing beats Photolab on image quality and I don´t think anything beats iMatch today as a real personal or workgrouo DAM that has all possibilities to scale all the way to be used as a front end for people working with corporate DAM-systems just because iMatch unlike for example PhotoMechanic (still works internally with just IPTC) is built on a solid base of XMP. There is also nothing that works and synchs better together today than Photolab and iMatch and since there are so many that have migrated to Photolab just because of being a non-subscription solution even iMatch fits into that offer being non-subscription too.

I have myself upgraded Photolab every year since 10 years just to support it despite I have to subscribe even to Capture One too since there are things that are really difficult to in Photolab. I need both. I want Photolab to survive because of the qualities it also have (image quality). I also want iMatch to survive because Photolab and iMatch is the best combo there is for me and many others today I think. They are an almost perfect match in order to scale Photolab to the next level for a reasonable cost. They have all to gain through a life in symbiosis and I also think it is sad so many are stuck there with Lightroom when there are better alternatives. There is an opening especially now when so many are so deeply disappointed in Adobe of so many reasons.
Title: Re: An example: Where poor keyword-workflow issues can take you if you are unlucky
Post by: Mario on June 12, 2025, 02:33:33 PM
It is indeed an interesting—and lengthy—thread. Over the years, I have read many similar discussions on sites like dpreview.com and within this community.

People differ in their gear choices and shooting habits. Professional photographers, librarians, historians, or plane spotters often have different approaches and requirements for metadata compared to "normal people" who enjoy capturing photos of friends, family, and vacation spots.

My general approach in developing IMatch is to provide users with options while ensuring flexibility to support a wide range of workflows and needs. This must be balanced against complexity, which inevitably arises when making software more powerful and adaptable.

The "Apple approach", as I term it, aims to simplify things to the minimum. And Apple has the clout to tell users "If our software does not do that, you don't need it". This approach would not work for the demanding IMatch user base  ;D

In recent years, due to changes in the user base, I've aimed to keep things simpler and avoid considering every possible feature or option from the outset. Often, I begin with a minimum viable product (MVP) but design internally to allow easy and safe additions.

Users inform me of what's missing, and when there is a significant number of users requesting specific features, I implement them. Or if I find an idea appealing  ;)

When accessing external services like the Map Panel, reverse geocoding, or AI, I investigate offering users multiple service options: GeoNames.org, HERE, or Google Maps for reverse geocoding? Google, Bing, or HERE for the Map Panel? Or OpenStreetMap?

This approach incurs higher development costs and maintenance debt but provides users with more choices—a good thing in my opinion. I don't want to lock users into specific services, nor can I cover IMatch user expenses related to maps, reverse-geocoding, or AI usage. Thus, these features are implemented as "bring your own API key."

I began working on AutoTagger in July 2024, delving into AI technologies and testing with OpenAI, Mistral, and Ollama. During this period of discovery, I encountered the dynamic nature of AI—vendors like OpenAI frequently updated their APIs to adapt and evolve, introducing new models that significantly enhanced previous offerings.

From the start, I knew AutoTagger needed to be easily extendable and adaptable as new AI vendors (e.g., Google) became supported in IMatch and their APIs evolved. It was also essential to provide features allowing users to control AI output and leverage existing information within the IMatch database for improved prompts and results.

This is why AutoTagger includes highly flexible keyword-related filtering, mapping features, and thesaurus integration. Prompts support variables, and context placeholders are available for ad-hoc prompting—a feature I frequently use when processing new images in batches.

I also wanted to enable users to distinguish between AI-generated and human-generated metadata to prevent "polluting" manually added keywords and descriptions with AI content. This is why I introduced AI tags (and traits).

The recently added feature to run a Metadata Template after running AutoTagger offers additional options, e.g. recording the AI and model used to fabricate the keywords and description, to re-apply person keywords and much more.

Many IMatch users likely don't use keyword mapping, context placeholders, or variables (no telemetry data on this), and they might be satisfied with the default prompts. Perhaps they store data in AI tags or use standard XMP description and hierarchical keywords—whatever works for them, IMatch supports it.

Other users invest time to determine which prompts yield the best results, how to utilize variables for precise keywords and descriptions, or how to employ IMatch's unique trait tags to let AI classify their images by various criteria automatically.

This situation is similar with other metadata: some users don't use metadata at all (or AutoTagger), while others find proper metadata management essential, with AI saving them significant effort.

From the thread you posted, I learned what I already knew: Many people don't know what they are missing. This applies to both RAW processing and Digital Asset Management (DAM). Users often express surprise upon discovering that other RAW processors produce superior results compared to Adobe Lightroom!
Additionally, many learn about the subpar state of metadata in their files and how improving it—through keywords, controlled vocabularies, descriptions, AI-generated content, and standardized, interchangeable metadata via IMatch and ExifTool—can be beneficial.
Title: Re: An example: Where poor keyword-workflow issues can take you if you are unlucky
Post by: Stenis on June 14, 2025, 12:00:50 AM
After my latest posts in that DXO tread we have discussed, it seems to have totally died. That was really not my intention.

People might have felt stupid about the level of that somewhat bizarre discussion that was going on there when I pointed out where the development-front around the keyword issues really lies today with iMatch and Autotagger as an example.

What's even more bizarre is the fact that these discussions have been going on for probably 4 years or more at DXO Forums, not the least around the problems DXO Photolab previously had with the handling of hierarchical keywords (it has not been fully compatible with, for example, PhotoMechnaic's handling of data exchange between applications). So, it has far from just being a matter of being able to export and import vocabularies.

You wrote: "From the thread you posted, I learned what I already knew: Many people don't know what they are missing. This applies to both RAW processing and Digital Asset Management (DAM). Users often express surprise upon discovering that other RAW processors produce superior results compared to Adobe Lightroom!
Additionally, many learn about the subpar state of metadata in their files and how improving it—through keywords, controlled vocabularies, descriptions, AI-generated content, and standardized, interchangeable metadata via IMatch and ExifTool—can be beneficial."

I think that comment: "many just don´t know what they are missing" is spot on. Many are stuck in a "bubble" where Photolab, Lightroom or for that mater Capture One is the "whole" monolithic metadata management world and relativelly few are taking steps to scale up by using PhotoMechanic och iMatch and know waht it really has to offer.

I also just find it astonishing what you Mario just wrote: "I began working on AutoTagger in July 2024, delving into AI technologies and testing with OpenAI, Mistral, and Ollama. During this period of discovery, I encountered the dynamic nature of AI—vendors like OpenAI frequently updated their APIs to adapt and evolve, introducing new models that significantly enhanced previous offerings."

So, you havn´t even spent a full year developing Autotagger (10 months?) to the state and full power and control it now empower the users of iMatch with, together with at least one on the AI-providers that Autotagger supports today. I think that is both pretty unique and remarkable not the least when it comes to how brilliant all keyword related tasks are handled and controlled in iMatch 2025. ... and again, this not really a question about the need for enormous R&D resources and big AI-centered development teams to achive this but more about one single developers brilliant skills och totally focused Holistic Engineering. Until now it hasn´t either helped Adobe with all their billions, has it?

With Holistic Engineering I mean how both iMatch Face Detection and the Autotaggers handling of the AI-driven image analysis through the four different promps together manage to write so often very well written Descriptions and even hierarchical keywords to the pictures and on top of that even managege to automatically manage our Thesaurus to our liking totally automatically regardless if we prefer using "controlled vocabularies" or prefer our own hierarchical keywords or just unstructured ones. Keywords with "Zero Administration" who saw that coming a year ago. I guess most people could not believe that even would be possible. Today it is a "non-issue".



Title: Re: An example: Where poor keyword-workflow issues can take you if you are unlucky
Post by: Mario on June 14, 2025, 08:27:55 AM
Quote from: Stenis on June 14, 2025, 12:00:50 AM. Today it is a "non-issue".
Yes. Unless one has very specific requirements for keywords or descriptions, we can leave that boring job to AutoTagger.

And I did a lot else since July, not only working on AutoTagger. Also did PeekView, CAI, Quick Filter ribbon, the new ribbon 
and menu system, drew over 300 vector icons, re-implemented the background processing engine for even faster performance etc.  ;D
Title: Re: An example: Where poor keyword-workflow issues can take you if you are unlucky
Post by: Stenis on June 14, 2025, 12:19:45 PM
.... and I have really stopped to make myself irritated on how much time I have to spend writing Keywords and Descriptions or doing the job once more in my Portfolios at Fotosidan where I host them:-)

I think the new version of Autotagger and the new AI-models ought to make it a more realistic task to build decent image archives than ever since my texts now are supported in my Fotosidan-workflows. Earlier many have tried but given up when realizing how much time and efforts it used to take. 
Title: Re: An example: Where poor keyword-workflow issues can take you if you are unlucky
Post by: Mario on June 14, 2025, 01:06:40 PM
QuoteEarlier many have tried but given up when realizing how much time and efforts it used to take.
Small libraries and companies with large unannotated image archives now have a good change, using AI to describe and tag stuff. Big AI companies support fine-tuning of models for specific purposes or to add "company know-how" for the AI to learn from, even specific vocabularies and terms can be incorporated.

Another neat thing is RAG (retrieval augmented generation). If you use LM Studio you can try this out. If you drop a text document into a Chat, LM Studio feeds it into the AI and you can ask the AI questions about it...
AnythingLLM drives this even further for local AI. Fascinating times.
Title: Re: An example: Where poor keyword-workflow issues can take you if you are unlucky
Post by: Stenis on June 15, 2025, 04:37:50 PM
I will keep an eye on RAG. Maybe even OpenAI will offer thinfs like that?
Title: Re: An example: Where poor keyword-workflow issues can take you if you are unlucky
Post by: Mario on June 15, 2025, 05:07:18 PM
One second of Googling reveals:
https://platform.openai.com/docs/guides/optimizing-llm-accuracy/retrieval-augmented-generation-rag
https://help.openai.com/en/articles/8868588-retrieval-augmented-generation-rag-and-semantic-search-for-gpts