Main Menu

Recent posts

#1
Off-Topic / Re: AI Haluzinations...
Last post by sybersitizen - Today at 01:15:25 AM
Quote from: Mario on June 30, 2025, 02:04:53 PMDid you ask AI for how something works in IMatch? If so, which, and did you get useful results?
No, but I recently tried asking ChatGPT how to accomplish something in a popular photo editing app. It did not produce the results it said it would, it suggested using non-existent commands, and when it offered to provide a download of a file that it claimed would help me, the file could not be accessed for download.

AI in my experience often provides answers that are useless or obviously wrong.
#2
General / Re: IMatch freezes when readin...
Last post by thrinn - June 30, 2025, 10:19:32 PM
I think I figured it out, more or less. And the culprit is not IMatch as such but one of my own Apps :o . In my tests, the freezes only appear if the App is active. When I close the App window, I can write back 40 ARW/JPG pairs without any blocking and as fast as expected. Some more testing is needed because I also modified my relation rules for the tests, but it is pretty clear to me that my App is somehow involved. So there is no need for you to spend more time on this "bug".

Just for information:
This App displays some information about the focused file, using calls to v1/files and v1/files/relations like this (focusedFileId.value is the ID of the focused file):
        return Promise.all([
            s.IMWS.get("v1/files", {
                id: focusedFileId.value,
                fields: "id,name,versionstate,namene,ext",
                varPersons: "{File.Persons.Label}",
                varPersonIds: "{File.Persons.OID}",
            }) as Promise<FilesResponse>,
            s.IMWS.get("v1/files/relations", {
                id: focusedFileId.value,
            }) as Promise<RelationsResponse>,
        ]);

The App reacts on IMatch messages if the focus changes. So my first guess was that flooding it with messages somehow caused locks. But the App is properly "debounced", and I added some logging to make sure that the App behaves as expected, only calling the endpoints if no new messages are received during 3000 ms.

Therefore, my best guess now is that one of the IMWS calls above, maybe v1/files/relations, tries to get the versions of the focused file, while at the same time IMatch tries to update them, thus blocking each other. Does this make sense?

At least, I have a working solution now: Disabling my App while performing actions like write-back or propagating metadata.

I am sorry that you had to waste valuable time on this "bug" - which is no bug of IMatch at all..
#3
Off-Topic / Re: AI Haluzinations...
Last post by Menace - June 30, 2025, 05:24:09 PM
Unfortunately I have to admit that I use perplexity quite often for step by step instructions (Home Assistant, Blender, Photogrammetry and sometimes IMatch). I usually let the AI search more precisely, but it often happens that he takes old versions of the programs, some reddit comments or just fabulates, even with IMatch (when he suggested a panel for the autotagger that does not exist or I have not found so far).
I think if you work with AI you have to know about this weakness. I always link to the help page as a source for the AI and check the links first. I also often give him back tasks when I have doubts. That's how I get a lot of things solved that I couldn't manage before. But you should always doubt the AI first, not the programs or apps.
For biological species identification with automatic generation of categories and directories I use perplexity and it is a timesafer.
#4
Off-Topic / Re: AI Haluzinations...
Last post by Mario - June 30, 2025, 05:18:10 PM
Quote from: axel.hennig on June 30, 2025, 04:40:23 PMNo, but just because the help is so great.
Thanks.

I've made a test just now, asking Microsoft Copilot a rather complex question.
And it got it almost right. But the error in the response is one of the things that sends users one a goose chase and cause frustration. I have highlighted the error (no such command in the context menu) below.
The rest of the answer is kinda right.

Problem is, if you don't know something, you can usually not tell that the AI is wrong either... :(

Image1.jpg
#5
Off-Topic / Re: AI Haluzinations...
Last post by axel.hennig - June 30, 2025, 04:40:23 PM
Quote from: Mario on June 30, 2025, 02:04:53 PMDid you ask AI for how something works in IMatch?

No, but just because the help is so great.
#6
General Discussion and Questions / Re: Thumbnail corruption of so...
Last post by Mario - June 30, 2025, 03:03:14 PM
LibRaw / photools.com RAW processing is the default since IMatch 2025. No camera vendor provides WIC codecs anymore, or developer support. Microsoft seems to prioritize updates to their WIC codecs very low, as it seems. Wasting time with nonsense like Recall instead...

#7
From your comments above on LibRaw I am wondering when it would be better (if ever) to use WIC. thanks
#8
Off-Topic / AI Haluzinations...
Last post by Mario - June 30, 2025, 02:04:53 PM
The number of support emails where users have asked an AI first how to do something in IMatch is rising. Just got another one today.

The AI produced absolute nonsense, telling him to use non-existing commands in non-existing features. Even told him to look for files in a non-existing category.

This of course confused the user even more, and I've got a longer email with a two paragraph complaint about how hard it is to find the non-existing commands in IMatch  ;)

After reading through the rand I found the actual question and answered it in one sentence - and a link to the IMatch help system where it is explained in great detail.

One would think that AI should be capable of reading the IMatch help system and don't invent stuff. Else it generates eveb more support load for me.

I use AI in software development quite often, to avoid reading 16,000 pages of documentation or to safe time writing tests or refactoring. My impressions are generally positive. It's useful when you know the limits of what it can do.

Did you ask AI for how something works in IMatch? If so, which, and did you get useful results?
#9
General / Re: IMatch freezes when readin...
Last post by Mario - June 30, 2025, 11:16:05 AM
Just in case, I've improved monitoring for the next release. In addition to monitoring transaction duration (and disk util. and mem util. and cpu util.) IMatch now also monitors the average time it takes to begin a transaction. To handle situations where threads are starved by having to wait to long for entering a transaction. The average transaction duration measurement should already takle care for that, but who knows...

Aaannd I've had a neat idea to improve the scheduling and make it scale smoother. This should help on systems with specific ratios of processor cores and disks. And probably everyone a bit.

All of these performance measures are used to determine if background processing system can add more threads (when the system is not too busy) or reduce the number of parallel threads to reduce system load.

Leaving resources idle is not good for performance, maxing out resources is also bad for performance. The balance is controlled via the performance profile. And this seems to work really well, for the vast majority of users. And I have tested this for months on all kinds of hardware.

Exceptions like the one you report or the other currently open case are to be expected. There is one billion Windows PC's out there, and each one is different.

In many of the reported cases, the virus checker was the culprit.
And once a cheapo SSD which became 10 times slower once the internal high-speed cache was filled and it had to move data to the slow storage chips it uses. Replacing the SSD with a known good Samsung SSD (which only costs 20$ more) fixed the issue. Now the SSD holds up the write speed.

What the issue is with your Z: drive (or IMatch) I don't know yet.
#10
General / Re: Very slow imports and miss...
Last post by Mario - June 30, 2025, 10:34:32 AM
Do you still experience slow imports after updating your virus checker definitions and moving the cache?
If you can move the database to an SDD that not also contains your images, you should see performance improvements.

The "slow" time to create a cache image is down to 5 to 8 seconds, instead of 30. Still not that good. I would expect to see more like 1 or 2 seconds, max., for typical current RAW files.

I also see that some threads had to wait a rather long time to get access to the database. Database and images on the same disk still? Performance profile set to "Performance"?