Enhanced support for paired Raw/JPEG photos

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

[xnview]

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?

[JohnFredC]

Here is a previous thread about XnView's behavior with "companion" files...

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.

[DawMatt]

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!

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

[xnview]

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