Page 1 of 1

Enhanced support for paired Raw/JPEG photos

Posted: Sun May 13, 2007 1:39 pm
by DawMatt
Hi,

Many modern digital cameras, especially DSLRs such as the Nikon D70S, allow you to record JPEG and Raw (e.g. NEF) files simultaneously each time you take a photo. This gives you an immediately usable photo (the JPEG) while ensuring you still have access to the higher quality photo format for editing purposes. The downside is that these are, for all intents and purposes, the same photo so many operations should be performed on both photos at the same time. Few applications can support this. I'd like to see support for these "paired photos" to be added to XnView.

Specific examples of how this would work:
1) In the Browser, in thumbnail view you would see a single photo stack for each Raw/JPEG photo pair. The JPEG would be used as the source for the thumbnail.
2) In Compare, the photos would also be displayed stacked using the JPEG for display.
3) In the Browser or Compare, delete would remove the complete stack i.e. both the Raw and JPEG photos.
4) In the Browser, moving the stack would move both the Raw and JPEG photos.
5) When editing a stack, the Raw photo would be used as the source file for the changes.

Is there any chance of this capability being added to XnView? Obviously it isn't quite as simple as above (would need additional config options, context menu items, ability to expand stacks, etc) but it does describe a number of the key use cases for this feature.

Thanks,
Matt

PS The closest I can get to this currently is modifying the Custom filter to exclude the Raw photos in the browser, then switch back to All view when I need to delete/move both the JPEG and Raw photo. Unfortunately any file selections are lost when swapping filters, so this makes the workflow pretty painful.

Re: Enhanced support for paired Raw/JPEG photos

Posted: Mon May 14, 2007 7:01 am
by xnview
DawMatt wrote: PS The closest I can get to this currently is modifying the Custom filter to exclude the Raw photos in the browser, then switch back to All view when I need to delete/move both the JPEG and Raw photo. Unfortunately any file selections are lost when swapping filters, so this makes the workflow pretty painful.
Do you use Option/General/File op/For copy/move use companion?

Posted: Mon May 14, 2007 2:17 pm
by JohnFredC
Here is a previous thread about XnView's behavior with "companion" files...

http://newsgroup.xnview.com/viewtopic.php?t=10300

Linking the raw AND the jpg AND "sidecar"/"companion" (such as XMP) files for copy and move would be great.

A dialog showing a list of the linked files with options for including/excluding them from copy/move would be great.

Also, some way to define the rules that XnView uses to identify the companion files would be helpful.

Re: Enhanced support for paired Raw/JPEG photos

Posted: Thu May 17, 2007 1:22 am
by DawMatt
xnview wrote:Do you use Option/General/File op/For copy/move use companion?
Hi,

Yes, I do have that option selected, but it seems to be limited to xmp/thm files and I'm looking to link NEF and JPG files. But it sounds like this could be extended to address a number of the issues that led to my suggestion.

Thanks,
Matt

PS JohnFredC, the sidecar thread was pretty interesting and I am very interested in those suggestions. If you read "The DAM Book: Digital Asset Management for Photographers" they discourage the use of sidecar files (metadata should be applied to the files itself) in the interests of editor portability, and I guess the requirement to update XnView to support these sidecar files is validating that argument!

Posted: Thu May 17, 2007 3:14 am
by JohnFredC
One important thing for me about the sidecar file concept is its usefulness for implementing non-destructive versioning.

It should be a straight forward matter for XnView to record the edits it performs on graphic images and allow the user to save this automatically generated XnView script to a file named the same as the image, but with a version counter and script extension.

For instance: MyImage.01.XnV, MyImage.02.XnV, etc.

An XnView "Save a version" command might appear in the File menu beneath Save As... and display a dialog proposing a version number one increment higher than the last.

Perhaps on opening an image XnView could ask the user which "version" to open. That is, which .XnV script, if any, to apply to the original (an additional dropdown in the File->Open dialog would suffice). Then run the script on the original image in memory and display the results.

XnView would also need a "Render" command to save a version's script results back to the original image file, or to a new image file, should the user need that.

Perhaps the XnView version sidecar file format could be a jpg thumb of the versioned image with the script (and name of original file) residing in one of the IPTC fields, such as the Caption field.

Such a scheme could really separate XnView from the "pack".

Re: Enhanced support for paired Raw/JPEG photos

Posted: Thu May 17, 2007 1:22 pm
by xnview
DawMatt wrote: Yes, I do have that option selected, but it seems to be limited to xmp/thm files and I'm looking to link NEF and JPG files. But it sounds like this could be extended to address a number of the issues that led to my suggestion.
Ok, right i'll add jpg & raw too

Re: Enhanced support for paired Raw/JPEG photos

Posted: Thu Nov 05, 2015 8:42 am
by sternenfall
I am currently using XnView 2.32

I have enabled the General/File Operations/Use companion. I have added PP3, ORF, CR2 and XMP to Browser/File List/Custom files.

I had a file a.jpg and a.orf in some import folder. From a before session with RawTherapee there happened to be some a.pp3. I moved a.jpg into another folder. Xn moved the JPEG+ORF but left the PP3 behind. The problem: I wasn't even aware that it existed at the time (RawTherapee created it silently).

Generally all files that share the same basename belong together. Period. This is true for any OS, book titles, domain names. In 35+ years of using computers I cannot remember a single case were this assumption could have caused harm.

This is so basic, any program that tries to implement it's own logic on top of basenames (as common denominators) will soon or later cause pain.

Given a file named base.ext Xn should consider all files matching base*.*. Then, if there are more than the usual 2-3 files, it could present the list to the user and ask if he really wants to copy/move/delete them all together.

That would be great.