Companion / XMP files

[Sirio]

Hi, a lot of water has flowed under the bridge since the last post.

I would like to know if there is an interest from the programmers about linking
the RAW+JPEG+XMP (or .pp3 for RawTherapee, .on1 for ON1-Photo-RAW) in an actions like rename, move and delete?
Personally I think is important, specially because there is no many software able to do that.
When you come back at home with 1000 pictures, I would like to eliminate in a fast way the bad ones before to import them in a raw editor software, and not the opposite.

Have a nice day.

[Gérard 91]

Hi
It's a good idea Sirio.
I'm just a photographer and I would also like to select and manage both raw (nave for me) and Jpeg (and why not companion files). Sometimes I have 10,000 photos after a few weeks of wildlife photography.
Xnview MP is an excellent program with features that increase a lot in recent years. I know Pierre never stops to improve it, It's a big challenge to have it full reliable on three platforms, I hope He can and will do.

Bonne soirée
Gérard

[Sched]

Yes, at least move and delete, for me it will be enough.
Thank you.

[xnview]

See issue for current status and some details.

[xnview]

This problem is supposed to be fixed in XnView MP 0.91. Please check and confirm the bug fix here.

[m.Th.]

In 0.91b4 Win x64 we have:

[ ] - show companion
[x] - Delete
[x] - Copy/move/Rename

Works ok BUT... there is a problem with "Show Companion" OFF.

Steps:

0. Have the settings above.
1. Select a file with a companion. Press Ctrl+C
2. Press Ctrl+V

Expected: The file with the sidecar should be copied in the same folder but the sidecar is hidden.

Actual: Sidecar is shown.

Note: Go out from the folder and go back to the same folder (to force a refresh) and the sidecar is hidden correctly.

Another steps to show the same problem:

0. Have the settings above
1. Select a file with a sidecar & Rename it.

Expected: The file & sidecar is renamed.

Actual: The file & sidecar is renamed AND the sidecar is (wrongly) displayed.

[m.Th.]

In 0.91b4 Win x64 we have TWO OTHER BUGS:

Have the following settings:

[ ] - show companion
[x] - Delete
[x] - Copy/move/Rename

Bug #1

Steps:

1. Have a file named 1.CR2 with its sidecar (or any other file with a sidecar)
3. Copy the file by drag & Drop in the same folder.

Expected: The file AND the sidecar is copied in the same folder

Actual: Only the file is copied.

Note: The drag & drop doesn't support the sidecars.

...but let's continue:

Bug #2

...by using the bug #1 create several copies of 1.CR2 and now we will have in the same folder the following files:

1.CR2, 1.XMP, Copy of 1.CR2, Copy (2) of 1.CR2, Copy (3) of 1.CR2

Steps:

A. Select 1.CR2 and press Ctrl+C
B. Press Ctrl+V

Expected:
Copy (4) of 1.CR2 and Copy (4) of 1.XMP should be created

Actual:
Copy (4) of 1.CR2 is created and Copy of CR1.XMP is created.

Note: That is the names are desynced. Please keep the file names the same.

[Sirio]

I can confirm the first bug that I call bug #0:
when the sidecar files are still shone. With the behaviour: Go out from the folder and go back to the same folder (to force a refresh) and the sidecar is hidden correctly.

I confirm the bug #1: the drag & drop copy copy only the file selected without the companions.

I confirm the bug #2, but I am not sure that is a real bug, is logical, no?

[xnview]

I can confirm the first bug that I call bug #0:
when the sidecar files are still shone. With the behaviour: Go out from the folder and go back to the same folder (to force a refresh) and the sidecar is hidden correctly.

Ok, i'll check

I confirm the bug #1: the drag & drop copy copy only the file selected without the companions.

i can confirm only if you don't drag&drop into a subfolder (from thumbnail view)

I confirm the bug #2, but I am not sure that is a real bug, is logical, no?

A difficult problem...

[m.Th.]

I confirm the bug #2, but I am not sure that is a real bug, is logical, no?

Nope. (UNfortunately)

Remember, the user does not "see"/"know" that a sidecar exist. He "sees" only the metadata and/or his edits.

When he copies his Raw file, these edits/metadata should be copied "transparently" because for him these edits/metadata are in his (conceptual) document / "file".

[m.Th.]

Pierre, it is your custom code the one which generates "Copy of foo.jpg" names?

[Sirio]

I think when the bug #1 will be solved, the bug #2 automatcaly too, no?

[xnview]

Pierre, it is your custom code the one which generates "Copy of foo.jpg" names?

yes, but the paste don't know about companions, it copy a list of files, and rename if needed...

[m.Th.]

Pierre, it is your custom code the one which generates "Copy of foo.jpg" names?

yes, but the paste don't know about companions, it copy a list of files, and rename if needed...

I suggest that the sidecar should forcibly take the name of the main file. In the case in which such a sidecar exists, it should be deleted because it is a broken pair left from a previous mistake. Perhaps better, before deletion ask "Old sidecar for Copy (10) of 1.CR2 exists. Overwrite?" if {Yes} then overwrite. If {No}, don't copy/paste the old one.

[Sirio]

Personally I never get this problem, because even when I make one copy of a file with companions, is already a lot and when I do that, I rename directly the new file with a real name. The "copy of" never stay. I wonder if this is a real figure in real situations.