IMatch Improvements

[Arthur]

Admin: I will split this sub-thread into its own topic because it is totally unrelated to the original topic.

OK, first feedback to this, if no other wants to:

This is nothing I could use, but as a press release feature, as you mentioned it last days, this could be great. :-)
IMatch is really feature complete for me. Would be more happy about improvements of existing features in terms of usability and speed.

[Mario]

Would be more happy about improvements of existing features in terms of usability and speed.

Feel free to post details about what you mean in the feature request board.

If you talk about performance, please include your machine specification, the database size, image formats used etc. What is super-fast on a 100,000 files database maybe inevitably slower on a 500,000 files database. When your images are on a slow network, everything will be 10 to 100 times slower than on a local disk or disk. Things like that.

[Arthur]

No, I don't have special requests. Everything is OK. I rather ment such improvements like where you improved how categories are stored to save space or where the file window became faster through directx. These are core elements everybody works with. I think, if you would advertise for example that writing metadata of files is 20% faster in the new version, even if this is not requested, it would be a nobrainer to update as soon as it is out.

I would even pay for the mouse wheel improvement, which was released in one of the last versions, because it was so important for a fluid workflow.

[Mario]

This kind of improvements are always on my list and I implement them when I see a chance or have an idea. New tools also often include better analysis features which enable me to spot slow code paths I can improve.
The Viewer uses DirectX, but not the file window. The slowest part in the file window is the XAML-rendering. What gives us unmatched flexibility (variables, formatting) comes at a cost.

Moving to 64-bit and engineering a new way to store categories have been huge steps, performance-wise.

Of course IMatch offers numerous features which can impact performance. Users are allowed to shot into their own foot when the get carried away - I just dealt with a database having +350,000 files, almost 60 data-driven categories (!) and 'performance problems' 

[Carlo Didier]

I had an idea, since long, concerning data driven categories and performance problems.
I know this could be difficult to manage in the context of iMatch Anywhere, but I always wanted something like database queries.

There's saved filters, but it might be interesting to have data driven categories and queries which would work the same but only evaluate when requested, like an SQL query on a database.

Same for the category builder where I'd often wish I could easily save such a "query" for future use. I know, you can create a new category from the builder, but that would again be sort of a data driven category.

Maybe a "Queries" panel would be possible where the user could put saved filters, search results, @builder formulas etc and they would only be evaluated on demand when they are needed.

If you think something like that would be possible, I'll post a feature request to see if more people would be interested.

[Mario]

IMatch Anywhere WebViewer already has this. It's called Navigator.

The Navigator stores query instructions and replays them later. IMWS can perform caching and if an already existing query is re-run on an unchanged database it can return the cached results immediately.
IMatch works the same with categories and collections, keeps results cached in memory and only re-calculates when the database changes (which happens often, depending on your workflow).

Same for the category builder where I'd often wish I could easily save such a "query" for future use.

The easiest way to do that is to copy the formula shown in the @Builder into a category formula. Create a root category "Queries" and below that any number of formula categories for queries you often need. Set them to "manual update" to not slow down the database and then update them when you need them. Works a treat.

I doubt that many users would have a use for a dedicated feature for this. I don't know how many users use category formulas at all, or the @Builder.
Post a feature request so we can see if and how many users are interested.

[Arthur]

Mario,

did you think about extending IMatch's layouting capabilities? When I came from Lightroom, I wanted to achieve the same layout like in Lightroom (see attachment). The problem is, that the file window and the trees build a monolithic union. I can live with how it is now, but I was not free to setup the layout I wanted. The file window at the bottom would have to scroll horizontally to be more like a filmstrip. This would be a real improvement from my point of view.

[Mario]

Please remember post feature requests into the appropriate board. I don't watch other boards for feature requests and the FR board is also the best place to discuss feature ideas.

I would say that forcing the file window into one single row just to imitate Adobe Lightroom is nothing I would consider. To break up the structure of Views ("Tree" on the left, file window on the right) would also be very hard to change - are all used to it for over 10 years of IMatch. You can easily create a "Lr" similar layout with IMatch, showing the M&F / Category / Collection /... tree only when needed, moving the FW to the bottom:



or with more than one row of thumbs:



IMatch gives you so many ways to customize the layout, including the ability to move panels to other monitors and workspaces. I'm sure you'll find a layout that works even better than what you are used to from Lr.

[Arthur]

Puting the file window at bottom is not an option, because I want always to see the M&F tree and there I do not have enough height for it. Forcing the file window in one row has not that high priority, but having the trees separatable would be cool for the millions of Lightroom, Dxo and some Capture one users (basically your main audience). This is especially useful for the 80% (estimation) of home users, which do not have a multi monitor setup. They cannot put the "Quick View" on a second screen. Not having this makes IMatch "special" here. But as I said, I can live with it.

[Mario]

If the tree would be a separate panel, you could switch to the Category View and still see M&F. Won't work.
Adding yet another grouping level inside the file window itself would require a lot of work. Write your FR and then we'll see how many users in addition to you would need such a thing.

[Arthur]

If that is the problem you could have an "Organizing"-Panel containing a tab control as root, which contains all the trees. This would ensure that only one tab of M&F, Categories, Timeline or Collections is visible at a time. Basically nothing would change. The tab content would shrink to the trees and the file window would be decoupled from this panel. I will write a FR later, maybe there are some metoos.

[Mario]

This is the wrong place to discuss this. Write a FR so other users can see it and comment on it.

[DigPeter]

The easiest way to do that is to copy the formula shown in the @Builder into a category formula. Create a root category "Queries" and below that any number of formula categories for queries you often need. Set them to "manual update" to not slow down the database and then update them when you need them. Works a treat.

Do I understand from this that it is possible selectively to set updating of both individual data-driven categories and user formulas to manual update?

Is so, how is this set up?  I have preferences set to 'update data-driven categories'.  If I try to set an individual category to manual in properties and change 'Automatic update'  in 'Edit data-driven category' to 'off', the OK button is greyed out.

What am I missing?

[Mario]

The OK button is usually only grayed out when there is a problem with the settings of the dd-cat (no activated level).

[DigPeter]

I have a number of user formula categories.  These do not use metadata tags, as in data-driven categories. Therefore , in data-driven properties, 'Enabled' cannot be set to 'Yes';  instead thereis a warning: "You can only enable this level after selecting a metadata tag".  So it seems that user formula categories cannot be set to manual update individually.

[Mario]

The message show quote is only displayed when a dd-cat is set to "Tag" but no tag has been selected.
If you have set the dd-cat to use a variable but no variable is entered, the message is "You can only enable this level after entering a non-empty variable.".



BTW: I wrote nonsense above. There is no manual option for formula-based categories. This property was accidentally visible in the properties pane of the categories tree. It should only be visible for data-driven categories. I have fixed that for the next release.