My question for xnview is how it most safely serves users who need a pure organizer first and foremost . These are users who will separately and later turn attention to modifying images. It is great that XNView has modifier tools, but what are the pure organizer tools and how are they safely configured?
Organizer practice and beliefs have 2 clear camps
1. extract embedded EXIF data but Never rewrite it into the original image file
2. display and modify embedded data and rewrite At Will and even at Risk of altering an original image file and/or slowing down your system
I am of the FIrst camp
I think that Xnview can be configured to Never rewrite to original image files and still display original EXIF data, search data, and accumulate new categorical tags. It would be tragic to serve 2 gods and to operate an external database to serve the storage of new user data like comments and still tamper with EXIF data regions for the storage of new metadata that is derived from EXIF original.
But I am not sure how to configure using the graphical buttons and check boxes with their cursory short text definitions and I am not sure of the database paradigm practiced by xnview. Obviously a significant collection of data harvested from EXIF and added through tags and comments requires a database external ..... the database is a proxy for the multiplicity of metadata regions in thousands of individual image files .
IF XNView can be safely configured for pure organizing to serve camp #1:
Can someone succinctly describe that configuration as it is available in the graphical settings?
If that is doable, it could also be represented by an explicit "mode" of operation with a toggle that configures all the consequential configure choices to "Never write to source image files/process and store all metadata through external database"
This is a suggestion and also a plea for help by a curious new user
Ty
pure organizer locking metadata out of sourcefile
Re: pure organizer locking metadata out of sourcefile
I hope XnView will still consider to more explicit IN configuration labels and buttons to allow first time users to run with certainty that writing to original image files is positively excluded.
This is valuable to a first time user who is not immediately aware of the 2 paradigms of persisting data in either the sql database (for Categories) or for various other IPTCXMP that is persisted in the image files. If you want the source image preserved (read but never written) and data stored determines which tags/ratings labels you must restrict to......for now I must stick to the paradigm of category tags only .
I will point from this suggestion thread to the general support topic where "m.Th" has been a helpful coach
viewtopic.php?f=82&t=38395
Still learnng Ty
This is valuable to a first time user who is not immediately aware of the 2 paradigms of persisting data in either the sql database (for Categories) or for various other IPTCXMP that is persisted in the image files. If you want the source image preserved (read but never written) and data stored determines which tags/ratings labels you must restrict to......for now I must stick to the paradigm of category tags only .
I will point from this suggestion thread to the general support topic where "m.Th" has been a helpful coach
viewtopic.php?f=82&t=38395
Still learnng Ty