How can I see Adobe Camera RAW edits in IMatch?

anmue · June 02, 2014, 10:08:15 PM

Hi,

At first I hope this topic was not discussed elsewhere in the forum. If so please point me to the thread (yes I tried find it).

Now to my question: I use Adobe Bridge to check my Nikon RAW images (.NEF) before I ingest them into IMatch. During this Bridge session I sometimes use Adobes Camera RAW to look if a failed image is salvageble. If so I instantly apply the corrections (crops and other image corrections like white balance or exposure) to the to the image, which are written in a XMP sidecar file. When I'm back in the Bridge I can see the corrections in the thumbnails and in the preview. So far so good.

But when I then import the files into IMatch I only see the original image without the corrections I made. Is it possible to see the corrections of Camera RAW in IMatch?

I understand that this issue could depend on the WIC codec I use. I currently tried it with the NEF codec from Nikon and with the FastPictureViewer Codec Pack. This is what the WIC diagnostics says:

Code Select


List of installed codecs:
	Codec 'BMP Decoder' for extensions .bmp,.dib,.rle
	Codec 'GIF Decoder' for extensions .gif
	Codec 'ICO Decoder' for extensions .ico,.icon
	Codec 'JPEG Decoder' for extensions .jpeg,.jpe,.jpg,.jfif,.exif
	Codec 'PNG Decoder' for extensions .png
	Codec 'TIFF Decoder' for extensions .tiff,.tif
	Codec 'WMPhoto Decoder' for extensions .wdp,.jxr
	Codec 'Google SketchUp Thumbnail Provider (FastPictureViewer Codec Pack)' for extensions .skp,.skm
	Codec 'Adobe XMP-Based PDF Thumbnail Provider (FastPictureViewer Codec Pack)' for extensions .pdf
	Codec 'Fuji Raw Decoder (FastPictureViewer Codec Pack)' for extensions .raf
	Codec 'Adobe Lightroom Preview Decoder (FastPictureViewer Codec Pack)' for extensions .lrprev,.noindex
	Codec 'Samsung Raw Decoder (FastPictureViewer Codec Pack)' for extensions .srw
	Codec 'Radiance HDR Decoder (FastPictureViewer Codec Pack)' for extensions .hdr,.pic,.rgbe,.xyze
	Codec 'PNM Decoder (FastPictureViewer Codec Pack)' for extensions .ppm,.pgm,.pbm,.pnm
	Codec 'OpenEXR Decoder (FastPictureViewer Codec Pack)' for extensions .exr
	Codec 'Hasselblad Raw Decoder (FastPictureViewer Codec Pack)' for extensions .3fr,.fff
	Codec 'Adobe DNG Decoder (FastPictureViewer Codec Pack)' for extensions .dng
	Codec 'TGA Decoder (FastPictureViewer Codec Pack)' for extensions .tga
	Codec 'JPEG Rotator (FastPictureViewer Codec Pack)' for extensions .jpg,.jpeg,.jpe,.jfif,.exif
	Codec 'PhotoLine Thumbnail Provider (FastPictureViewer Codec Pack)' for extensions .pld
	Codec 'Canon Raw Decoder (FastPictureViewer Codec Pack)' for extensions .cr2,.crw
	Codec 'Epson Raw Decoder (FastPictureViewer Codec Pack)' for extensions .erf
	Codec 'Nikon .NEF Raw File Decoder' for extensions .nef
	Codec 'Panasonic Raw Decoder (FastPictureViewer Codec Pack)' for extensions .rw2
	Codec 'Adobe XMP-Based Thumbnail Provider (FastPictureViewer Codec Pack)' for extensions .eps,.ai,.indd
	Codec 'Nikon Raw Decoder (FastPictureViewer Codec Pack)' for extensions .nef,.nrw
	Codec 'Leica Raw Decoder (FastPictureViewer Codec Pack)' for extensions .raw,.rwl
	Codec 'Sony Raw Decoder (FastPictureViewer Codec Pack)' for extensions .sr2,.srf,.arw
	Codec 'JPEG Derivative Handler (FastPictureViewer Codec Pack)' for extensions .jps,.mpo
	Codec 'Mamiya Raw Decoder (FastPictureViewer Codec Pack)' for extensions .mef
	Codec 'Autodesk Maya IFF Decoder (FastPictureViewer Codec Pack)' for extensions .iff,.tdi
	Codec 'Minolta Raw Decoder (FastPictureViewer Codec Pack)' for extensions .mrw
	Codec 'Rawzor Compressed Raw Format Previewer (FastPictureViewer Codec Pack)' for extensions .rwz
	Codec 'Pentax Raw Decoder (FastPictureViewer Codec Pack)' for extensions .pef
	Codec 'Sinar Raw Decoder (FastPictureViewer Codec Pack)' for extensions .cs1
	Codec 'Kodak Raw Decoder (FastPictureViewer Codec Pack)' for extensions .dcr,.kdc
	Codec 'DDS Decoder (FastPictureViewer Codec Pack)' for extensions .dds
	Codec 'Softimage PIC Decoder (FastPictureViewer Codec Pack)' for extensions .pic
	Codec 'Photoshop Document Decoder (FastPictureViewer Codec Pack)' for extensions .psd,.pdd
	Codec 'JPEG 2000 Baseline Decoder (FastPictureViewer Codec Pack)' for extensions .jpf,.jpx,.jp2,.j2c,.j2k,.jpc
	Codec 'Olympus Raw Decoder (FastPictureViewer Codec Pack)' for extensions .orf
	Codec 'Sigma X3F Decoder (FastPictureViewer Codec Pack)' for extensions .x3f
	Codec 'Valve Texture Format Decoder (FastPictureViewer Codec Pack)' for extensions .vtf
	Codec 'Silicon Graphics RGB Decoder (FastPictureViewer Codec Pack)' for extensions .sgi,.rgb


Testing file 'D:\Users\Andreas\Pictures\Originale - Testkopie\O_IMG-2013\O_IMG-2013-00008\Kopie\20131025-0004.NEF'
	Thumbnail: Codec 'Nikon Raw Decoder (FastPictureViewer Codec Pack)'
		() 104x160 pixel in 15 ms.
	Preview: Codec 'Nikon Raw Decoder (FastPictureViewer Codec Pack)'
		() 2832x4256 pixel in 31 ms.
	Full resolution: Codec 'Nikon Raw Decoder (FastPictureViewer Codec Pack)'
		() 2844x4284 pixel in 0 ms.

The only positive result I got was a crop that was applied to the thumbnail of IMatch. But in the end this was errornous anyway, because in Camera RAW I made landscape crop to a portrait original. The result in IMatch was portrait crop with a wrong aspect ratio

.

Has any one an idea how I can achieve the same results in IMatch as in the Bridge? Maybe I have to change my workflow, but I like to reuse the corrections I made with Camera RAW later when I fine tune the image in Photoshop.

Kind regards

Andreas.

joel23 · June 02, 2014, 10:46:58 PM

Quote from: anmue on June 02, 2014, 10:08:15 PM

Has any one an idea how I can achieve the same results in IMatch as in the Bridge? Maybe I have to change my workflow, but I like to reuse the corrections I made with Camera RAW later when I fine tune the image in Photoshop.

Well, I think to display all XMP-crs settings in IMatch is not easy to achieve and this IMHO has nothing to do with the WIC code.
Note: ACR settings can be stored in a database or XMP sidecar files.
You may consider launching a feature request (for reading ACR settings from XMP sidecars) if this is an important feature for you.

Erik · June 03, 2014, 01:05:13 AM

You won't be able to see the edits that I'm aware of. Bridge shows them (as would other Adobe software) because all Adobe software can interface with ACR easily.

That I am aware of, the best one can do is embed a preview into the raw file. I'm not sure how that works in ACR (I only use Lightroom), but Lightroom has a setting to update metadata and preview.

However, from what I recall, the preview option is only available in DNG files. Someone else can correct me if they know that ACR will embed previews in other file types.

jch2103 · June 03, 2014, 01:53:09 AM

Quote from: anmue on June 02, 2014, 10:08:15 PM
...Maybe I have to change my workflow, but I like to reuse the corrections I made with Camera RAW later when I fine tune the image in Photoshop.
...

I assume you can reuse the ACR corrections when you open them in Photoshop (even if you can't see them in IMatch)?

joel23 · June 03, 2014, 07:21:48 AM

Quote from: Erik on June 03, 2014, 01:05:13 AM

However, from what I recall, the preview option is only available in DNG files. Someone else can correct me if they know that ACR will embed previews in other file types.

The ACR settings are embedded in XMP for DNG, JPG and TIF (with PS/Bridge we can chase even JPG and TIF through ACR)
For RAW they can be stored in XMP sidecar files or in a database.

Mario · June 03, 2014, 08:33:26 AM

That is a general misconception users have about 'virtual' or 'non-destructive edits' they apply to their RAW files in software like LR or ACR. And it sometimes leads to nasty surprises when they decide to switch to another brand of RAW processor...

If you use ACR or LR, you lock yourself into the Adobe product line. If you switch to another RAW processor, all the change you made to your RAW files previously are lost, unless you persist these changes by exporting your RAW files with all changes applied to a file format like PSD, TIFF or JPG.

When you make changes in ACR/LR, these changes are written as instructions for the proprietary Adobe render engine - either into the crs namespace in the XMP file or straight into the proprietary LR/Bridge database.

These instructions can only be interpreted by other Adobe software - and usually only if this software has the same version as the software you have used to produce it, or a higher version. Older Adobe products usually fail to read all or some of the virtual processing instructions created by newer products. Hell if you work in mixed environments where not everybody has the latest and greatest Adobe products.

To see your files in IMatch or other software as you see them in ACR/LR, you have 3 options:

1. Persist the changes and export your files into a standard file format like PSD, TIFF, JPG

2. Switch to a DNG-based workflow. The semi-standard DNG format contains an embedded preview which is updated by ACR/LR. This preview shows the file "as final" when all virtual edits are applied to the RAW. Software like IMatch and WIC codecs can use this preview to show the file "as-is".

3. Export your files to JPEG in ACR/LR and then make them a "visual proxy" version of the RAW in IMatch. IMatch then uses the thumbnail/preview created from the JPEG whenever you look at the RAW file. It will then look as the file you see in LR/ACR.

<flame on>

While non.-destructive edits are a fine thing when it comes to RAW, users have to be aware that using these features binds them to the product forever, unless they are prepared to throw away all their work when switching to another brand or platform.

A fact that has recently caused some waves because of Adobe's change to a subscription model for most of their software (and soon for all, I suppose). If your subscription expires or you cannot longer afford to pay for it, the software stops working. And you cannot longer use or apply all the non-destructive edits you have made in LR or ACR. A very, eh, interesting business model...

<flame off>

Ferdinand · June 03, 2014, 08:52:17 AM

Mario has given a long response. Here is my short one. I am always surprised when people make this request. Because if you think for a moment about it, then it mostly doesn't make sense. If you can see the edits, one of two things must have happened:
. Either Mario has reverse engineered and replicated the entire Adobe raw conversion engine, so that he can interpret the settings stored in the XMP sidecar; or
. the RAW converter has updated the embedded thumbnail so that it reflects the edited image.

The first isn't going to happen for both practical and legal reasons.

The second happens only in specific circumstances - Nikon Capture updates the embedded thumbnail for NEF; and Adobe does so for DNG.

Mario · June 03, 2014, 10:16:20 AM

I think the predecessor successor of Nikon Capture (NX-D) does not longer have this option. The new Capture is basically a re-labeled Silkypix version.
Since the old Capturer was developed by nik Software, which was bought by Google, I think Nikon has lost access to most of the technology used in Capture. Hence they switched to another development company, but apparently lost the "update preview in NEF" feature - at least for now.

Ferdinand · June 03, 2014, 10:41:07 AM

I think you mean "successor".

Mario · June 03, 2014, 10:59:05 AM

Right

Erik · June 03, 2014, 05:00:18 PM

Quote from: joel23 on June 03, 2014, 07:21:48 AM
Quote from: Erik on June 03, 2014, 01:05:13 AM

However, from what I recall, the preview option is only available in DNG files. Someone else can correct me if they know that ACR will embed previews in other file types.
The ACR settings are embedded in XMP for DNG, JPG and TIF (with PS/Bridge we can chase even JPG and TIF through ACR)
For RAW they can be stored in XMP sidecar files or in a database.

Right, the settings are embedded. But when you see the edits in OTHER software (non-Adobe) it is because the embedded preview has been embedded into the XMP record, and that I believe is only done with DNG files. Non-Adobe software can't interpret and regenerate the edits since it doesn't have the actual rendering code that is owned by Adobe.

Erik · June 03, 2014, 05:07:54 PM

Mario,

You previous post and flame is a potentially great benefit to IMatch. As users become more aware of the limitations that are going to occur with the subscription model and the embedded development settings in files, they will probably inevitably go back to a more traditional workflow of exporting their Tiffs, Jpegs, etc. and perhaps keep their DAM separate from their PP. The key item of reference is LR, which once it goes subscription (and I'm sure it will), will be something that people might quickly dump.

And, once they find their new RAW processors can't read their old one's settings, they'll want more permanent records of their efforts. The market for IMatch should improve in that case, and the versioning features should be a huge benefit to those users.

As a LR user, I'm becoming weary that the next version will be subscription, and I am starting to shop for a new RAW processor to fill in when the inevitable happens. I'm happy that my DAM is not in that same basket.

joel23 · June 03, 2014, 06:25:26 PM

Quote from: Erik on June 03, 2014, 05:00:18 PM
Non-Adobe software can't interpret and regenerate the edits since it doesn't have the actual rendering code that is owned by Adobe.

Yes, sure, I agree and that is the problem.

Mario · June 03, 2014, 06:39:56 PM

A key point of IMatch was always "openness". Even 'proprietary' data like IMatch categories, the thesaurus or the new Attributes can be exported in several ways, in case a user wants to switch from IMatch to another product. And if you use none of the advanced features and stick to metadata like XMP/IPTC/EXIF only, all your data stays in your image files or sidecars, and will travel with your files automatically.

The effect of proprietary non-destructive edits and subscription models and what it means to users is not understood yet - and the vendors don't raise the topic for good reasons. It's a bit like cloud storage for your files: once you have all your files in the cloud, it becomes increasingly slow, complex, dangerous and probably expensive to switch to another cloud vendor. You lock yourself in for your life. You lose a lot of control over your data.

If you have bought Photoshop or LR, it will work as long as the Windows version you run it on supports it. Many users have used (and happily so) Photoshop two or three generations out of date. If you don't need all the new bells and whistles, why pay for them? The same is true for for Office etc. I know many users who run Office 2003 and it works fine. And that's a software 10 years old, and it still gets free security updates.

But now, if you have a subscription and it expires. the applications stop to work after a months or so. And all your files will be dead data.

A DAM like IMatch is used to manage files created over 10,20 or more years. Files created with a multitude of cameras and applications. IMatch must be as universal and open as possible so users can get their data in and out easily. That's one of the main principles for IMatch since 1998.

anmue · June 04, 2014, 09:43:46 PM

Hi,

Thanks for sharing your insights. Well, I will rethink my current strategy. At the moment it tends that a hybrid strategy will fit my needs the best.

That is still using Camera Raw as my RAW processor, because I like it very much and I'm used to. Additionally I will store the results of Camera Raw to a new image file, just in case I'm forced to change the horses. In IMatch I would use this file as visual proxy.

Currently I'm not shure what file format to choose TIF or DNG? And with DNG what flavour (w/ or w/o embedded camera file)?

So thanks again.

joel23 · June 04, 2014, 10:19:36 PM

Quote from: anmue on June 04, 2014, 09:43:46 PM

Currently I'm not shure what file format to choose TIF or DNG? And with DNG what flavour (w/ or w/o embedded camera file)?

So thanks again.

If you want to keep the RAW untouched as possible use DNG with embedded RAW. Just in case. I also store standalone RAW processor or converter (like RawTherapee or Adobe DNG converter) once in a while to DVD.

Use PSD/TIF only for editing - even when storage is cheap nowadays, PSD/TIF uses to much space. Also consider file relations: I wonder how a file relation between TIF as Master and TIF as Version would work out (in case you use TIF for editing) - I wouldn't be surprised, if this gives a loop somehow when propagating metadata.

They downside of using DNG is (and also PSD/TIF, but since the latter are usually larger it's much worse with them), that every edit by ACR or IMatch is directly written to them, which possible means larger incremental/differential backups.

Erik · June 05, 2014, 04:30:53 AM

Quote from: anmue on June 04, 2014, 09:43:46 PM
Hi,

Thanks for sharing your insights. Well, I will rethink my current strategy. At the moment it tends that a hybrid strategy will fit my needs the best.

That is still using Camera Raw as my RAW processor, because I like it very much and I'm used to. Additionally I will store the results of Camera Raw to a new image file, just in case I'm forced to change the horses. In IMatch I would use this file as visual proxy.

Currently I'm not shure what file format to choose TIF or DNG? And with DNG what flavour (w/ or w/o embedded camera file)?

So thanks again.

Ultimately, the important is too keep track of how you version things. I don't think you have to worry about an endless loop with versioning using the same file types. I've done it before. The key is in how you do your versioning. I use file names and versions always have something appended to the root file name:

thus: File.tiff = Master
File-V01.tiff = version

There is no doubt what the version is. I even have it set up so that there can be versions of versions (file naming not IMatch relations). I won't say it's ideal, but in those cases, I could have

File-V01-V01.tiff if that is how it works out. This isn't really kept track of directly by IM. I let IM keep thinking the file is a version of the original master, but it lets me know that the version did not come directly from the master.

In reality, my camera shoots DNG, so I won't comment on format. There are too many what-ifs, and it's worth considering them all at least once. It looks like you are.