XnView Software

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.

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

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

See issue for current status and some details.

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

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.

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.

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?

Sirio wrote: Fri Jul 20, 2018 10:41 am 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...

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".

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

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

m.Th. wrote: Fri Jul 20, 2018 1:56 pm 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...

xnview wrote: Fri Jul 20, 2018 2:21 pm

m.Th. wrote: Fri Jul 20, 2018 1:56 pm 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.

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.