Search option

[Ingvar Thorsson]

In order to select images based on metadata or keywords/tags you have to open up a folder or a number of combined subfolders and then use the filter functionality

This works well when you are working with a small numbers of images within a limited number of folders, if you need to search thousands of images in a complex folder hierarchy though, this is not a very practical approach.

Nitro is currently limited to two levels if you want to combine subfolders (due to performance reasons)
To open up a large number of images and build thumbnails, is a quite demanding and time consuming process.

Would it be possible to implement a “search” function in addition to the current “filter” function?

The way I imagine is that you start by specifying the search criteria and then access just the xmp files and if possible just the metadata of the image files (no thumbnails)
when you have narrowed down your search, then you can open up the selected images.

By just accessing pure metadata I imagine that this might result in a significant preformance enhancement when working with large selections (maybe even the two subfolder levels limitation could be extended)

[Nik Bhatt]

It’s an interesting idea. Filtering and searching are similar concepts but with a key difference. Filtering: taking a large set and producing a subset. Searching: starting from nothing and producing a set of matches.

Both take a query and produce a result set, but filtering is starting with the images already visible, while search is starting from nothing visible. The app filters rather than searches because then it’s just hiding images from view and everything else works the same way as if there was no filter.

Nitro stores metadata for files it has seen in a database. However, because the file system can change behind its back, it cannot be sure that the files that it was are still there (or if new ones have been added).

So for a search, it cannot simply consider its database. It would still have to walk the entire tree. It would not need to display all the thumbnails, that’s true.

Then, when there is a match, it would need to find a different way or UI to show the images, since they can be scattered throughout the tree and that would break the assumptions of where the images are coming from. So, that would require a different type of view (in the way that the Finder has a different view when you search there).

[Ingvar Thorsson]

What are the performance impact of “walking the tree” and create some kind of ad hoc index based on the current folder selection and a limited subset of attributes? Can that be an option if you are willing to accept a certain delay before you can perform your search?

[Nik Bhatt]

Walking the tree is the time necessary to go through all of the files and folders that you want to search against. For an SSD, it’s pretty fast; for a network drive it’s pretty slow. Getting file names etc isn’t slow, but reading the metadata is. The app would need a spinner or something because the preparation time is not predictable or consistent.

[Author]

Posts