Tagging JPEG creates xmp-sidecar

[hic]

Hello,

I just started to learn working with XNViewMP, and I'm impressed so far.

However, if I try to add a category to a file, XNView always creates an xmp-sidecar file. That is fine for raw files, but odd behaviour for jepg, tiff and dng, which all can hold xmp in the file itself. Did I miss to check any option?

Regards,
hic

[xnview]

?? There is no xmp created by XnViewMP

[hic]

Yes, there is. If I tag a JPEG file in XNViewMP and afterwards update the file according to the database, a new xmp file shines up, containing the keywords.

Regards,
hic

[xnview]

sorry but XnView don't create .xmp files, it use XMP metadata from jpeg files

[m.Th.]

Yes, there is. If I tag a JPEG file in XNViewMP and afterwards update the file according to the database, a new xmp file shines up, containing the keywords.

Regards,
hic

Do you use "View | Update files from database" ?

[hic]

Yes, that is exactly what I do. The Jpg is updated and a new XMP file is created along the Jpg.

Regards,
hic

[m.Th.]

Yes, that is exactly what I do. The Jpg is updated and a new XMP file is created along the Jpg.

Regards,
hic

Hmmm... mhmm.... Well... I don't know. I really don't know.

Perhaps you're right.

However there are on other platforms enough support cases for this. You know, "Why the metadata is saved for my CR2/NEF and not for my TIFF/JPEG?"

...but I think that the best solution is Lightroom which throws the following window at the similar action with 'View | Update files from database":

Lr-message.jpg

[hic]

I wonder that nobody before recognized this behaviour. My question was if that is intended, I now know it is not

How do others assure that the metadata of the database and the files are synchronized?

Lightroom does indeed write metadate to files, if files are writable, and to XMP if they are not writable. But in the first case (e.g. Jpg) it doesn't create an additional XMP.

Regards,
hic

[oops66]

...How do others assure that the metadata of the database and the files are synchronized?...

... For the integrity of files (jpg, tiff, ect), XnView(MP) do no touch the original files by default, even the metadata (it's more secure).
... But if you want, you can synchronize db to file by checking "all export ..." and "write comment" here:(I have not tested since a long time )

Settings\Metadata\IPTC & XMP \
Keywords

x Export DB Category to XMP subject and IPTC keyword
x Export rating in XMP metadata
x Export color label in XMP metadata

Comment
x Write comment in XMP (dcdescription and exifrusercomment)

[xnview]

Yes, that is exactly what I do. The Jpg is updated and a new XMP file is created along the Jpg.

Oh ok, with 'Update files from database', .xmp files are always created. Perhaps an option here??

[m.Th.]

Yes, that is exactly what I do. The Jpg is updated and a new XMP file is created along the Jpg.

Oh ok, with 'Update files from database', .xmp files are always created. Perhaps an option here??

Yes. As I/the others wrote many times here, we need a fine-grained XMP engine. See also here:

http://newsgroup.xnview.com/viewtopic.p ... 15#p117771

Fortunately it is easy to do.

Add the two checkboxes from above and for the topic here I'd suggest another checkbox saying "Embed the XMP data in image files, where possible"

[xnview]

Yes, that is exactly what I do. The Jpg is updated and a new XMP file is created along the Jpg.

Oh ok, with 'Update files from database', .xmp files are always created. Perhaps an option here??

Yes. As I/the others wrote many times here, we need a fine-grained XMP engine. See also here:

So 'Export keywords in XMP metadata when possible' as an option for 'Update files from database' or for global XMP engine?

Currenlty we have Metadata>Export category to XMP/IPTC

[oops66]

...Oh ok, with 'Update files from database', .xmp files are always created. Perhaps an option here??

Yes. As I/the others wrote many times here, we need a fine-grained XMP engine. See also here:

So 'Export keywords in XMP metadata when possible' as an option for 'Update files from database' or for global XMP engine?
Currenlty we have Metadata>Export category to XMP/IPTC

... NO ( or not by default ... because, by default, it is too dangerous for the integrity of the users files)

... The default behavior of XnView (and others softs) must be (for the integrity of the users data) ... "do not touch the originals users files/pictures by default". ... And in fact, it will be interesting to have this single option checked into settings by default :"Do not touch the originals users files/pictures" ... instead to have a lot of options to allow to write into the users files/pictures embedded metadata.

... So for me it's important to have an option ( preserve user file integrity into Tools\Settings\...)

... And all exceptions/options to this rule should be in the same setting location, so here : Metadata>Export category to XMP/IPTC

[m.Th.]

Wait, wait, wait...

While I fully agree with "don't touch my originals" policy by default, I think that we should take a global approach in consolidating the settings of I/O metadata engine. AFAIS now is an easy programming work but we must be attentive at GUI.

I'll prepare a document for this...

[CameronD]

... The default behavior of XnView (and others softs) must be (for the integrity of the users data) ... "do not touch the originals users files/pictures by default". ..... instead to have a lot of options to allow to write into the users files/pictures embedded metadata.

In my workflow, I make a big distinction between image data and metadata. Storing image transformation instructions rather than burning them in is always a good idea, but this has to apply to the raw image, rather than a jpeg. To me, a jpeg is never "the original".
My aim is for maximum interoperability between software packages, and to my mind that means I have no option but to embed the metadata within the jpeg image whenever possible.

The last thing I want is to have to tick numerous options to turn that on, so if there is a single option then it should switch between:
Metadata: use sidecar files whenever possible, or
Metadata: embed within image file whenever possible.

With the list of override options, I can imagine a potential nightmare of situations brought about by: "When I write metadata X to image files of type Y then software Z does not read it, so I'll need to write that one the other way around".