XnView Software

CameronD wrote:... The option presumably must apply to all image files, or none, and the wording should be clear about this.

Well, here is a problem. Theoretically you're right. But in practice, we cannot distinguish between image data change and embedded metadata change...

I don't see a major problem at all - if dates are newer then simply check if any mapped item is different between file and DB. There is not a lot of data to check. If the user has selected to keep embedded metadata in sync then update the DB. If the user has selected to ignore embedded metadata then ignore it.

bSidecar := FileExists(Sidecar); //test for the existence of sidecar 

if Photo.mDate > DB.mDate then
{
	if bSidecar then
	{
		if Sidecar.mDate > DB.mDate then
		{
			case AskTheUser of //ok, switch in C++
				0: Import_From_Sidecar; //default
				1: Import_From_Embbeded;
				2: //do nothing - this is the "Cancel" button
			end; // case
		}
		else
			Import_From_Embedded;
	}
	else
		Import_From_Embedded;
}
else
{
	if bSidecar then
	{
		if Sidecar.mDate > DB.mDate then
		{
		Import_From_Sidecar;
		}
	} //if bSidecar
}

m.Th. wrote:

Well, here is a problem. Theoretically you're right. But in practice, we cannot distinguish between image data change and embedded metadata change...

I don't see a major problem at all - if dates are newer then simply check if any mapped item is different between file and DB. There is not a lot of data to check. If the user has selected to keep embedded metadata in sync then update the DB. If the user has selected to ignore embedded metadata then ignore it.

Really? Let's see...

If XnView can detect that the image file has been recently changed, but the sidecar has not been modified...

1. Image file has been updated after date in DB, but sidecar has not (or does not exist). In this case there should be no ambiguity that any changes in the image file are newer
2. sidecar is newer than DB but image file is not - again there should be no ambiguity in XnView. Even if a user has selected to not use sidecars, XnView should check to see if there is something of relevance in there.
3. If both image and sidecar have been updated since the DB then is gets more complicated. My point is that the sidecar should not automatically be taken as authoritative, and I offer a modification of your example to show why.

On 1/1/2014: - XnViewMP scans the file and puts in DB the thumb, metadata (if finds) etc.
2/1/2014: The user with S1 enters the categories "Portrait", "John & Vangelis" and edits the caption.
3/1/2014: The user with E1, more knowledgeable, fixes the categories changing the "John & Vangelis" to "Jon and Vangelis" (removes the 'h') and adds 'Jon Anderson', ' Vangelis Papathanassiou', 'singer', 'musician', 'electronic', 'progressive rock' etc.
4/1/2014: Another user with E2 (or even E1) makes some edits to the scanned photo (brightness, vibrance, removes noise etc.) but it doesn't touch the metadata.

CameronD wrote:... The question that is still to be answered is: what happens to the embedded metadata that is out of date if XnView has been told not to touch the image file? To my mind, the worst option would be to leave the bad data in place. To answer that question, maybe we need somebody like Oops66, for whom it is more of a concern.

hic wrote:I would like to sum up this thread a little bit because it get's confusing.

1. The initial request was to prevent XMP-sidecars from being written for JPG and TIF. I guess this could be done by a simple "if" statement before the writing process.
2. The second request was to have an option to automatically update files and XMP-sidecars when database was changed.
3. The third request was, if it would be possible to handle other sidecars in file manamegent operations. These sidecars don't contain metadata, it thus would not be necessary to parse them but only to give an option to consider them in file management, i.e. copying, deleting etc. If in the options the opportunity would be given to define a custom sidecar which afterwards is defined by the system as belonging to image files, it would be sufficient.

Regards,
hic

xnview wrote:Currently if export is enabled, jpeg/png files are updated, and not for other
But if i add sidecar support, they will be

So like that?

Export to:
* None
* Metadata when possible
* Metadata and sidecar
* Sidecar

If both files are newer than the DB, then XnView cannot make any assumptions at all.

The only sensible course now is for XnView to scan each metadata field (where there are equivalent values in the DB and in the files) and compare against the DB contents.

m.Th. wrote:
1. Metadata placement

We need two options: embedded and sidecar regardless of file type.
I think that this is solved & summed up in Pierre's post here:

xnview wrote:Currently if export is enabled, jpeg/png files are updated, and not for other
But if i add sidecar support, they will be

So like that?

Export to:
* None
* Metadata when possible
* Metadata and sidecar
* Sidecar

The Research part is IMHO solved. Needs implementation.

PS: Yes, I know, no SilkyPix/Capture One support. But for this I think that's better to introduce a separate feature: Before/AfterFileOperation events: The ability to execute a parametrized custom script with {Folder} as argument Before/After each CMDR action. Hic (you're the most interested in this) what do you say? Perhaps is better to start another thread for this?

m.Th. wrote:Now commenting on the battlefield:

If both files are newer than the DB, then XnView cannot make any assumptions at all.

Agree. Hence XnView must ask the user.

The only sensible course now is for XnView to scan each metadata field (where there are equivalent values in the DB and in the files) and compare against the DB contents.

Here is the problem. While theoretically I agree, practically I think that the process can be rather slow (remember that usually there bunch of files/folders imported not just one or two) and troublesome from user's POV. Asking for each conflicting metadata field for each one of 100 - 600 - 1000 photos is quite a challenge for the user. Also, the code can become complicated.

There are some solutions here to consider:

Solution 1. I think that the only real solution is to ask just once: "Conflicts detected. What to take precedence? {Embedded} {Sidecar} {Cancel Import of metadata}"

Solution 2. Make a list of conflicts (which will grow up very quickly) and show it... ..

1. where (new) software behaves in a way that is not expected (or it has a bug),
2. another user operates in a way that conflicts with your chosen workflow,
3. other software cannot be made to operate in a way you desire.

• Automatically assign precedence to sidecar/embedded (this covers the 3rd situation where the user knows what the issue is)
• Automatically resolve as much as possible by scanning and comparing (as I suggested) and return to this window.
• manually review each conflict and allow me to resolve them one at a time. (this is for the user who has no idea what has gone wrong)

I think is is much less cpu effort than you think. In the case of embedded metadata , XnViewMP already scans every newer file and automatically updates metadata in the DB. To do this it has already opened the file, read the header and then scanned through it locating the relevant bits of metadata. A string compare is a trivial addition by comparison.

Automatically assign precedence to sidecar/embedded (this covers the 3rd situation where the user knows what the issue is)

...to ask just once: "Conflicts detected. What to take precedence? {Embedded} {Sidecar} {Cancel Import of metadata}"

...After all, XnView always has to read the file and metadata to display a lot of the contents that are not in the DB.

m.Th. wrote:Hmmm... you forget that now XnView MP blindly updates the metadata. Hence, if your proposal will be accepted, (and I'm not against to it - providing that this "field-by-field" mode will occur just in rare occasions)...

This is slower than what we have now ... As I said, of course, this will be a problem when we have many photos (IOW an entire card has "wrong" metadata WRT to our workflow).

Automatically assign precedence to sidecar/embedded (this covers the 3rd situation where the user knows what the issue is)

Well, this is exactly what I said: ...

...After all, XnView always has to read the file and metadata to display a lot of the contents that are not in the DB.

Not quite. Everything is in the DB. All the metadata, file properties and thumbnail. The file is read (scanned) only at the first time - when the thumbs are generated.

OK, maybe I am getting a bit old...

In the situations I am thinking of, it is clear that something has potentially gone horribly wrong, and if you are thinking of hundreds of images then we may assume it took days of work to get to the situation...

Even if it takes 10 seconds per image, that is certain to be far less than I or somebody else spent on the changes. I certainly hope it would be a rare situation.