You would need to point IMatch back at the B&W image to render it monchrome again. Pointing a colour image at metadata for a B&W image won't render the colour image in B&W in IMatch. The "editing" metadata in the XMP is specific to the converter that created it. The textual metadata (IIM IPTC, EXIF, IPTC Core, etc, but not always maker's notes) is readable by any XMP aware application as it's presentation is standardised.

IMatch reads in the RAW image as is (which is what Sorted was saying I think); it can't interpret the editing instructions. When you create a B&W version and convert it to a DNG that XMP image editing metadata becomes part of the image. ACR stores it's editing data in XMP as part of Adobe's policy of non-destructive editing, but the information is intended to normally only be read by ACR (and or any of Adobe's software capable of interpreting ACR editing metadata. When you convert an image to TIFF for example, ACR takes the instruction set and turns it into actual binary information i.e. it makes an image, whereas a RAW file isn't properly an image but in effect, a set of instructions to make one.

If I've got any of this wrong, I apologise and I'm sure Mario or someone will jump in and rescue me.

Hi

Carl is correct. Adobe products store "render instructions" as part of the XML record in the image file. These instructions are proprietary to Adobe and tell the render engine in these Adobe products how to process the image before displaying it.

Other RAW processors work very similar, including Nikon Capture and Bibble. They all store sets of proprietary instructions inside the image file or a sidecar file.

For DNG, however, the software which produces the DNG is supposed to render a preview which gives a rendition of the file after applying all render instructions. In your case, the preview should be grayscale. If IMatch displays the DNG file in color, the embedded preview seems to be wrong.

Is it possible that ACR doesn't update the embedded preview unless some change has been made to the metadata within ACR? Maybe this is what I've been missing all along.

I just tried bringing the B&W DNG into ACR, the one that had the XMP "restored" to it in iMatch so that it was turned from color into B&W. This image would show in color in iMatch but in B&W in ACR. Then I changed one of the parametric values in ACR (turned "recovery" from 0 to 5), and clicked "done".

Then I opened iMatch and rescanned the image folder with "force updates" and the iMatch finally rendered the DNG in B&W.

This would imply that ACR doesn't update the DNG embedded preview when the XMP data has been changed from an external program, even though it will actually render the image according to the updated XMP. But if you make a small tweak to the image inside ACR then it's forced to update the preview.

I know this may be turning into more of a subject for the Adobe forums, but does this ACR behaviour sound right to you guys? I have ACR preferences set to "Update embeded JPEG previews (Full size)" under "DNG File Handling", by the way.

Yes, this is what I presumed. It seemed unlikely that IMatch could render an image according to a set of 'instructions' recorded by another raw converter in an XMP file.

Now, greyscale is one thing but most photographers will not perform a straightforward rendering of a colour image in b&w as a greyscale but rather do some channel mixing/brightness/contrast or whatever. Thus other steps are involved well beyond a simple conversion. Jorge may enlighten us on this but even if IMatch could perform a simple greyscale rendition this is a far cry from the more complex editing steps one presumes were performed on the 'lost' images.

True, it makes a lot of sense that iMatch won't be able to interpret all the XMP "instructions" that were created by ACR. I should have thought of that first. I suppose that as long as iMatch can store all those instructions (which I believe is the case) even if it doesn't understand them, that's what really matters.

The ACR/Bridge issue of not updating the previews is a little annoying, though, since it makes the images display incorrectly in iMatch. Seems like I need to find a way to make Bridge or ACR "do and undo" some sort of change to all the images just so it's forced to update the previews (something like increasing exposure by 0.05, then decreasing it by the same amount). I imagine there must be a way to do this. I'll have to investigate some more.