XnView Software

Addition to my request:
IPTC:Caption-Abstract is limited to 2000 characters in the IPTC/IM specifications.
EXIF:Image Description and XML:Description are not directly limited.
The total amount of EXIF data in a JPEG image is limited to 64 KB. Data larger than 64 KB can only be written to a sidecar file.

Metadata > Edit IPTC... only allows 2 KB of data – OK.
Metadata > Edit XML... allows more than 3.7 KB of data (I have not tested the maximum) – OK.

My sample file has 3747 characters in the description.
Sample file:
https://www.swisstransfer.com/d/663d5094-7f5b-4289-8268-06afca2219a9
Screenshots
new 29.10. -15:36 https://www.swisstransfer.com/d/915fdea6-f1c1-4e02-beed-3ac553c6fced

The info area in XnView MP shows:
EXIF displays 2049 characters in a larger field. I would like to see a larger display (4 KiB) here.
IPTC-IIM displays 2030 characters in one line. Copy value only returns a subset.
XML displays 259 characters in one line. Copy value only returns a subset.
Exiftool displays in one line
- EXIF:Image Description 3747 characters. OK
- XML:Description 3747 characters. OK
- IPTC:Caption-Abstract 1995 characters. OK

Image management > Quick info (tooltip ) > {EXIF:Image Description} displays 1024 characters.
Image view > Information > {EXIF:Image Description} displays 1024 characters. I would like to see a larger display here (4 KiB).

Just by the by, I'd rather not use sidecar files for my routine photos. Too "messy" to deal with, doubling the number of files in use... Works fine if the only thing you use is the particular application using the files but if I use another - a file manager, for example, then I have all these 'random' (well, perhaps not random) files hanging around. ON1 does this - creates a file (*.on1) for every photo that it catalogues and I spend time deleting them...

Just my preferences.

Richard

Ideally, I want a set-up that mimics this :
- I shoot in RAW+JPG, so after importing I want files to be linked so that I do not see duplicated images.
- I want the actions I perform through the culling process to be applied to each photo (If I rate an image, the rating applies to the companion JPG file as well as the RAW that I've rated (or vice versa)


Configure companion files, then enable sidecar files and configure your ratings to be to be saved there.

The software can already do what you’re asking.

XnView MP itself uses umlauts without any problems and the metadata sidecars are also saved correctly. But the preview displays them incorrectly. At least this happens with all files that have a text format. I set everything to ‘UTF-8’ in the settings to be on the safe side, but the programme itself seems to save everything correctly.

The screenshots are from an XMP sidecar and a normal text file.

https://freeimage.host/i/KecOmve
https://freeimage.host/i/KecOba9

Still facing lots of issues and confusion with how XnViewMP handles sidecars.

When i assign Photoshop to Open With (Alt+1) menu and start it with on 007.ARW then it creates sidecar 007.XMP .

1. However that 007.XMP is only used when i use Open With (Alt+1) from XnViewMP menu, if i open using Photoshop > File > Open and select 007.ARW it does NOT load 007.XMP automatically as it should.

2. If Photoshop > File > Open used then changes made to 007.ARW in Adobe Camera Raw then it saves new sidecar file 007 .arw_xmp because file 007.XMP already exists.


Pinpointed the problem its because when opening 007.ARW with Open With (Alt+1) and save changes then inside 007.XMP it adds line
photoshop:SidecarForExtension="ARW "
space after "ARW ", this is reason it never being auto loaded from Photoshop Photoshop > File > Open


If Photoshop > File > Open then save XMP it will have
photoshop:SidecarForExtension="ARW"
no space after "ARW", then XMP loads properly when opening from Photoshop > File > Open and select 007.ARW


From what i understand when opening one file in XnViewMP using Alt+1 then it adds spaced "ARW " to that file's XMP, however if opening multiple files in XnViewMP then it adds spaced "ARW " only to the last file in series, must be something in part of source that supply file path or file name to external program.

Hello,
I was testing my issues on version 1.9.3 and it seems to have been fixed at some point?
Sidecar files appear to be moved/deleted when acted on when viewing search & filter results.
Cheers!

Currently when a file is loaded, XnView checks always if there is file.xm or file.ext.xmp

Should this be according to the activation of the 'Create or update XMP sidecar' setting?


No, "creating or updating" a sidecar file should be a separate option.

You said it "ALWAYS" checks.

When opening a file, It should only check (and then read the XMP) if the IMPORT options are checked on the Metadata page.

It should only write the file if "Create or update XMP sidecar" is checked.

As for the companion file settings, it only needs to check and process the XMP if the master file is deleted, moved, or renamed.

nope
I think it should stay like this:
read (Settings > Companion files)
* -- {ext}.xmp;xmp in Association list


write (Settings > Metadata > Sidecar)
'Create or update XMP sidecar' checkbox



On the other hand, I would probably merge these 2 settings tabs somehow as sidecar is a subset of companion files

Complément d'analyse par rapport à ma réponse précédente.

Dans ma config de paramétrage XnViewMP dans le module "Métadonnées/Companion" j'ai les options suivantes :
- pas de création ou mise à jour du sidecar XMP
- convention de nommage <nom de fichier>.xmp

Cette option est plus pour l'ecriture des .xmp
Actuellement, "<nom de fichier>.xmp" ou "<nom de fichier>.<extension>.xmp" si existe est chargé.

Du point de vue de la compatibilité, je vais demander sur le forum.

Currently when a file is loaded, XnView checks always if there is file.xm or file.ext.xmp

Should this be according to the activation of the 'Create or update XMP sidecar' setting?

my main problem
--> Simultaneous playback of sound files with the same name when displaying an image <--

Do I have to write a script for this function?
Forgive me, unfortunately I have not found any information or a link for integrating scripts.
I am a pensioner, I programmed TurboPascal 30 years ago . . .

- Which scripting language is it ? GhostScript ?
- how are scripts integrated and saved in XnView MP ?

many thanks in advance
Gerald


Gerald, I think we are having a communications problem with Pierre here.

As best as I can tell, this functionality just does not work.

When you open an image in the viewer that has a .WAV sidecar file, XnViewMP should play the WAV file automatically. It does not.

I hope Pierre will see this and understand what we mean and add this functionality.

maybe date change detection would be safer?

If one swaps cat with dog in the same sidecar it should be the same size and no change detected

xmp file size or date change?

just the same as in change detection routine for image files
is there any reason why it could be different?

xmp file size or date change?

I just wanted to provide a quick update on this after a bit more testing. (Also, I received a notification that someone had replied, but the reply was not here when I checked the thread.)

The issue where XnViewMP won't search the IPTC data it has (and shows in the dialog) without writing the file I'll call the "Unsearchable Cached Data issue".

First, regarding using the "Write" (or Write All) button to nudge the app to make the metadata searchable.
Using the Write button in the Edit IPTC dialog isn't a suitable solution because this always writes the original image file, and not the sidecar. Since the whole point was to avoid modifying the original image file, this won't do.
Using the Write button in the Edit XMP dialog isn't a solution because using it does not make the IPTC data searchable.

So we seem to have a "Catch-22" or unwinnable situation:
The metadata that can be stored in the sidecar file without modifying the image file, XnViewMP won't search
The IPTC metadata XnViewMP has in its database, it won't search without modifying the image file

One of the main purposes of sidecar files (along with storing data the original image file can't hold, or for compatibility with other software) is to avoid modifying the original image file.

It looks like QuickFilter just can't search these sorts of fields without modifying the original image file, and that's a significant problem that somewhat hamstrings the whole sidecar file situation.

So it's full circle to where I was before. Fixing the Unsearchable Cached Data issue would certainly help, but the best thing would be to just make the XMP data searchable.

I would think fixing the Unsearchable Cached Data issue would be quick and straightforward; just do to the database whatever the Write button does without touching the image file.

Searching XMP would be more work, but would certainly yield much greater benefits for users. (IPTC is the past, XMP the future).

But one of these things needs to be addressed if QuickFilter is going to be functional for people who need to frequently search metadata or use sidecar files.