XnView Software

Hi all,

I have my image archive saved on an external HD.

I'm trying to understend if I can use different PCs with XnView saving categories, ratings or descriptions ecc. and having all sincronized in two or three clicks (descr is yet ok I guess, using descript.ion files or IPCT subformat).

Is it possible to choose the position of XnView application data direcory that now is saved under the user windows dirs (like C:\Documents and Settings\user_x\Application Data\XnView)? In this case it should be possible to save a XnViewStuff dir used by all the installations in an external drive.
XnView should at startup search for a predefined path (configured) and if found it shows the External HD Archive otherwise uses default.

Something like:
another little question: Is it possible to add a description do a single folder (not only files?)

What do you think about it?

Thanks anyway.

bye
Tommaso
http://www.tomsights.net

Tommaso wrote:Is it possible to choose the position of XnView application data direcory that now is saved under the user windows dirs (like C:\Documents and Settings\user_x\Application Data\XnView)? In this case it should be possible to save a XnViewStuff dir used by all the installations in an external drive.
XnView should at startup search for a predefined path (configured) and if found it shows the External HD Archive otherwise uses default.

Tools » Options... »

1. General » Operations » Startup » Startup Directory » select Current or your external HDD's root directory
2. System Integration » Integration » Save options » as INI in folder » select XnView

Info » Command line help... »

—> Tommaso

Hello!

…another little question: Is it possible to add a description do a single folder (not only files?)

• If you mean via a <descript.ion> file, this is not supported by XnView…

• I can do so in Total Commander, though, but the comment is not visible in the browser of XnView (folders tree),
because it gets its info from Win Explorer.

Kind regards,
Claude
Clo

Thanks XnTriq & Clo,

I understand, and that's really good, that I can tell to XnView to read db files from XnView Program dir (i.e. c:\Program Files\XnView\ ini, dbs ecc).

In this way I have one only place where settings are loaded.

There's a "but": if you use different PCs you need, at this point, to manually synchronize ini and db files overrighting the one you want to use with the one latest updated...

Looking at "System Integration » Integration » Save options » as INI in folder » select XnView" it seems that you can't point to a directory of your choice (the one I named "XnViewStuff" by example, placed in the External Drive).

But I think, correct me if I'm wrong, that if there's not a way to setup a custom directory for ini and dbs this should maybe a suggestion for a new feature.

bye
Tommaso
http://www.tomsights.net

I am trying to understand which of the XnView setup files should be copied for the above purpose (and, why not for backup).

I found the following files both in user appl data dir and in XnView dir (after changing the option as XnTriq suggested me):
category.db
xnview.ini
XnView.db
iptc.def

Please, someone can explain me the use of these files?
Is there any missing file?

Anyway, I did some test and I think only descriptions (via ion file or iptc) may work good on an ExtHDD. Isn't it?

Thanks in advance,
bye
Tommaso

You can place XnView's cache wherever you wish and access it from there, so in principle you could put the cache on the same external drive as the pics themselves and update the setting in XnView; the problem here is if you wish to catalog images both on that drive AND elsewhere, since you cannot have two separate caches. Always in principle, pointing all XnViews on different machines to the cache on the folder of the external drive should work, unless there are concurrency problems (more than one process accessing the database, more than one process updating it at the same time, etc.)

Thanks robc,

robc wrote:You can place XnView's cache wherever you wish and access it from there, so in principle you could put the cache on the same external drive as the pics themselves and update the setting in XnView;

That's exactly what I need. Evidently I'm not in the right way, where I can tell XnView to point exactly the dir I want?

robc wrote:the problem here is if you wish to catalog images both on that drive AND elsewhere, since you cannot have two separate caches.

No, well, I want to catalog only once, on the ExtHD.
But, what if I open XnView and the ExtHD is not plugged?

robc wrote:concurrency problems (more than one process accessing the database, more than one process updating it at the same time, etc.)

yes, but cuncurrency is not a problem for me. I'll access only one pc at a time.

bye
Tommaso

This whole issue points up the prevailing problem resolving "ownership" of the image data:

When is the data owned by the image file? vs. When is the data "owned" by the image software or the "system"?

EXIF, IPTC, etc. are formal attempts to resolve that issue in favor of the image file itself. Thumbnail and image data caches, on the other hand, are attempts to resolve the issue in favor of the image software/system perspective.

IMHO, an "object"-oriented approach is best: determine what object the data is about, then store it either inside the object itself or adjacent to it in such a way that simple operations such as moving and copying respect the stored data and move it/copy it whenever the image is moved/or copied.

Obviously things like dimensions, shutter-speed, and date should stay with the image. But what about ratings and categories? Are they intrinsic to the image? Or are they about a user's image grouping and management activity that is perhaps fluid and not necessarily intrinsic to the image?

The MP3/music distribution industry has settled on storing such values inside the MP3 (consider: genre and rating). The image industry has approached that issue with EXIF, IPTC standards, etc, but only for JPGs (and DNGS, perhaps?). I prefer PNG, but I am not aware of an equivalent internal data standard for PNGs...

These are not easy questions, involving conflicts between logical paradigms, private data formats, convenience, and system performance issues.

I personally want my ratings and categories to persist with the image under all circumstances forever, so I am generally opposed to centralized data caches for just the reasons expressed in the posts above.

Unless the tool in use respects the link between the centrally cached data and the image file under all circumstances of moving, copying, etc, then the best place for the cached data is with the image itself!!!

As a start toward this, I think there should be an XnView thumbnail/image data cache in each image folder (OK now you can flame me! ). That would make it easier for me to copy or move the image folder with an external tool (such as TC) to another media and have my ratings or whatever visible at the destination with no further input from me.

By the way, no software does any of this in a manner that satisfactorily resolves the issues of using alternate tools to manage the files.

Very interesting JohnFredC

At this point I see at least 2 options to use XnView with an archive on my ExtHD:

- Use IPTC also for Categories (missing, I suppose, the fine functionalities of XnView categories and just using IPTC dialog)
- Find the way to point to a folder on the ExtHD (still)

I thought also another solution that should be nice: Installing XnView into a folder on the ExtHD. Is it possible? Well, I'm going to try this.

bye
Tommaso

No one is flamed or grilled here, John.

JohnFredC wrote:... Unless the tool in use respects the link between the centrally cached data and the image file under all circumstances of moving, copying, etc, then the best place for the cached data is with the image itself!!!
....

I like and support your general statement approach and also think that image meta data must be embedded in each image. The crux here is that only few file formats support image meta data. And XnView is a file viewer for many image formats.

General basis for storing image meta data
Whenever possible, existing means should be used. In the case of storing image meta data like description, categorization, and so on, it is the IPTC data embedded in JPG files which is this means. Current limitation is that IPTC data can be stored in some few file formats like JPG, only.
For other file types, a more or less similar means for storing image meta data should be found. This solution might be a small file per file containing an XML description of the image meta data which lies in every folder. So the user would be able to edit IPTC data for any image format or video file, be it bmp, gif, png, avi, ... In case of JPG it would be stored as part of the image, in case of other file formats which do not support IPTC it would be stored as XML description file. One general interface for image meta data for all file formats.

Requirements in Handling
Once the above basis for storing image meta data is there, it must be made sure that the following requirements can be fulfilled:
a - Ensuring that image and image meta data is always bundled together
b - Accessing this information quickly
c - Allowing for searching (quickly)
d - Possibility to move the images within the file system or onto another PC/medium without loosing the image meta data.

Decentral image meta data, but central database
Some mass actions would work with the image meta data in each single folders, but I think for performance reasons most of the mass actions like "show me all images in category 'x') for example wouldn't.
From my point of view the above requirements can be handled by a central database only. This central database can be native (whereas the image meta data should be XML and thus open to public and other programs).
For building up the central database there must be a way for reading
in decentralized image meta data into the centralized database, this means reading of folder and subfolders" on user demand. Reading on-access would not be sufficient, because one would have to browse all folders first and then one could search.

When copying and moving image files XnView must ensure that the image meta data is copied or moved, too.

That's some of my thoughs (quickly written up). Handling masses of images is an important area for image viewers. It would be good if a good solution could be found and implemented in XnView.

Note: From what I can remember there was once a related thread with posts from Olivier. Perhaps someone can find it...

(ehm... maybe it's me flamed )
Reading Helmut and John posts I convinced myself that the smartest choice was to install XnView directly into my HD.

So I did it, downloaded the zipped version and just exctracted it into the HD. Than I changed the paths in system integration (as explained by XnTriq).
It seems all ok, now I'll try to use this solution for a while.

Later I searched again topics about path configurations and in partucular direct Combo/HD installations and I found http://newsgroup.xnview.com/viewtopic.p ... torder=asc that maybe confirm I did it right (even if I'm using the complete installation zip).

bye
Tommaso
[/url]

The issue concerning where to place image data is very similar (if not identical to) the distributed database architecture problem faced by most corporations that have branch offices. These are the issues sometimes referred to by the term "Replication".

Some Replication issues are:

Redundancy

...to what extent is it necessary for identical data to be housed in multiple locations such as: central office and also branch offices (XnView cache and also image folders)? What data should be duplicated? What is the cost in resources for the redundancy?

Synchronization

...if there is data redundancy, what methods should used to maintain the data's integrity, that is, make the multiple copies current with each other? How to verify successful synchronization?

We all think of XnView and other programs like it as "image viewers". In actuality, though, XnView is a database manager. The data it manages is image data, including the pixels of the image and all of the other items discussed in prior posts above.

As XnView becomes more complicated and such issues as "where to store such and such data" impinge on its effectiveness as a tool, perhaps a visit to distributed database design theory and associated best practices would be helpful.

Here is a Wiki about "distributed databases"

helmut wrote:Note: From what I can remember there was once a related thread with posts from Olivier. Perhaps someone can find it...

“Someone” found it: IPTC/XMP for hierarchical categories + internal DB

XnTriq wrote:

helmut wrote:Note: From what I can remember there was once a related thread with posts from Olivier. Perhaps someone can find it...

“Someone” found it: IPTC/XMP for hierarchical categories + internal DB

Good that you have found the other discussion. I had you in mind when writing "someone".

To me, Olivier's and my above approach sound very similar, I think, which I think is a good sign if independently same ideas are developed.

Hard to say which discussion we should continue, I'd suggest to continue in the other topic IPTC/XMP for hierarchical categories + internal DB, there the subject and initial post fits better. Unfortunately it's impossible for moderators to join topics. John, perhaps you can post a copy of your above post to the other topic, later, I'll repost, too.

Tommaso, sorry for partly hijacking your post. Here's an answer to your original post:

Tommaso wrote:another little question: Is it possible to add a description do a single folder (not only files?)

If folders are shown in the file list, you can add and description which is displayed in the statusbar when selecting that folder:

1.) In options (Tools > Options), category "File list" check the checkbox "Folders: Show item in view 'Thumbnail'".
2.) Confirm the options dialog with "OK".
3.) In Browser, select a folder in the file list.
4.) Choose menu "Edit > Describe..." or context menu (right mouse click on folder in file list) "Describe..." or Ctrl + D.
--> Dialog "Describe" appears and you can enter a description for the folder.