XnView Software

Love to - where do I find the link?

Even more discombobulating - if I select 10000 images, set a new category - decide actually I didn't want to do this and unset it - it still writes out all the XMP data again and there is no clean way to stop it doing this.

It might be more transparent if, when using the catalog filter, the images currently displayed in the browser always matched the current selection and do away with the global match and current folder match options. Then when a folder is selected and then the catalog filter is selected the current ...

I think you're right in the sense that if there is no category filter selection the ALT-click behaviour is not well-defined. For instance, if I select a folder and then go to the catalog filter and ALT-click on a category I get no results. ALL does not affect the filter selection but then neither ...

I believe it is working correctly and doing what it was intended to do - it's just not what would seem natural for it to do in terms of filtering categories. That would have to be added as a new feature such as the suggestion of adding a special ALL keyword to categories. Until then the best option ...

That didn't use to work and still does not seem to work on my latest XnView 1.9.3. That is precisely what I was arguing for in the link I provided.

I'm not sure that is the case? I believe ALL is just a way to display in the browser all images. Unfortunately I don''t think it can be used as part of a filter operation.

https://newsgroup.xnview.com/viewtopic.php?t=46855

Many thanks for your responses. I understand what you are saying.

My query about the time taken (on my system) to perform some minor changes to my categories has, I think,been answered by the statement that all images in the selection have been updated regardless of whether their keywords will ...

xnview wrote: Sun Aug 24, 2025 6:15 am do you have tried to 'update catalog from' on these files?

No - but presumably same effect as deleting and recovering catalgue.

Many thanks for you reply - could not find Settings/Integration/File associations from root/xnview on Ubuntu (only get Paths).

Default image viewer is imageViewer for all jpg images so not clear why some were displayable by xnview and some not.

But must be something along those lines being ...

I have versions of the affected files from a few days ago which are interpreted and displayed correctly by the vs 1.9.3 software.

The affected files fill the Info/Properties pane correctly but are not displayed by XnView but XnView uses imageViewer to display them.

Only the files' XMP data have ...

That agrees with my observation of time taken for the operation - not nearly zero as expected, but about half of the time taken if all image files are changed.

I'm not sure I quite believe your rationale for this behaviour though. Either the image XMP data and the catalogue are in sync or they're ...

When I click on an image within the xnview browser some of my images are now being displayed with my default image viewer app instead of xnview.

This did not use to be the case - I'm now using vs.1.9.3.

Unaffected image show 'mm f/s iso' in browser whereas affected images are greyed. Filenames and ...

So the 'change' flag is set for the entire selection and results in the entire selection being written out to XMP even if the change only actually affects one image.

yes -- add my vote for implementation of the complex 2nd case functionality