XnView Software

Very recently I have read and learnt the English term "unearthing", see jokoon's post in topic Info about Resampling algorithms. Let's unearth this topic...

Time has passed and now XnView 1.90 provides functionality like categories and ratings. Currently, both categories and ratings are stored in a central database file. Now, XnView does store image meta data. So it's time for raising this issue, again.

___________

In topic external HD archive (multiple PCs) JohnFredC and I have placed some basic statements, theories, and pros and cons regarding image meta data. Below is a copy of what I have posted in that other topic:

I like and support your [John FredC's] 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.

Below I've written up some few requirements and statements that should be taken into account when reading and storing image meta data:

T1 - Image meta data is almost as valuable as the image and should be readable for years.

T2 - Image meta data should be stored as close to the image as possible. Ideally, image metadata is stored in the image to ensure that image meta data and image are never separated when copying or moving the image. This allows for exchanging images and image meta data easily.

T3 - If available, standard means for storing image meta data should be used and supported (IPTC, EXIF, ...). If not available, open standard technologies (XML) should be supported to ensure long term readability.

T4 - Ideally, the solution should be applicable for all file formats, not just formats like JPG which may contain image meta data.

T5 - Categories should be supported

T6 - Fast search over the image meta data should be possible

Looking at Olivier's summary in the initial post I can see a lot of similar statements.

When discussing possible solutions we might find more statements/requirements. Also, we can evaluate solutions against against these statements and requirements to find the best solution.

Repeating from other thread (1 of 2):

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.

Repeating from other thread (2 of 2):

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"

PRESS RELEASE: ACDSee Pro 2.5 Accelerates Digital Asset Management, Image Editing and Sharing

Embed metadata

In addition to modifying standard IPTC and Exif fields, photographers can embed custom metadata, such as categories and ratings. Embedding this information protects and preserves photographers' custom metadata and enables information to be shared between ACDSee users. Photographers can now embed metadata in additional graphic file formats, such as logos, that do not support IPTC and Exif fields.

ACDSee has just implemented - part of - what I proposed here 4 years ago...

Olivier_G wrote:Photographers can now embed metadata in additional graphic file formats, such as logos, that do not support IPTC and Exif fields.

Really??? But how they make???

xnview wrote:

Olivier_G wrote:Photographers can now embed metadata in additional graphic file formats, such as logos, that do not support IPTC and Exif fields.

Really??? But how they make???

Three guesses:
- "Embedding" might mean that there is a hidden buddy file for each image which holds the meta data.

- Append meta data at the end of the file (might work with some graphic formats and some tools, but image files might get corrupted).

- Store meta data in image information (but this will change the image slightly and this won't work for small files).

xnview wrote:

Olivier_G wrote:Photographers can now embed metadata in additional graphic file formats, such as logos, that do not support IPTC and Exif fields.

Really??? But how they make???

Hello,
Right, with exiftool for example, you can create a *.mie file ( only the thumbnail of the pictures are saved + all metadata )

See my old post here (2007 november):
http://newsgroup.xnview.com/viewtopic.p ... t=exiftool
(FI: XnViewMP0.26 is able to view this kind of files *.mie files)
For example to save metadata from jpg files: recursively: with windows ( two %%): See here too:
http://www.sno.phy.queensu.ca/~phil/exiftool/
http://www.sno.phy.queensu.ca/~phil/exi ... l_pod.html
http://forum.macbidouille.com/index.php ... pic=298296