Versioning

[Belenos2017]

I use IM2017.11.2/64bit/Win7. My workflow: Canon-CR2 - files in DB, Description in XMP. Some times later I develop some of these files with DXO to jpg.

I defined the buddy-files from dxo - that works.

I think, I have to define the jpg as version for propagation of the metadata - descriptions from CR2 to jpg ?
BUT - that doesnt work - the field "versioning" is not active - I cannot find my mistake....

[Mario]

Have you creates a new file relation definition?
Buddy relations and version relations are separate.
Create a new relation of type version. See the IMatch help for details.

[Arthur]

Here is my setup for the same case. You must only adapt what to propagate (in my case Categories and XMP Keywords).

And you must know whether to use the jpegs as previews for the raws on collapsed stacks only ("Version Stack Visual") or always ("As Visual").

I set up DNGs as masters also, because I was stupid enough to convert some CR2 to DNGs in Lightroom. You can remove that part if not needed.

[jch2103]

I use IM2017.11.2/64bit/Win7. My workflow: Canon-CR2 - files in DB, Description in XMP. Some times later I develop some of these files with DXO to jpg.

I defined the buddy-files from dxo - that works.

I think, I have to define the jpg as version for propagation of the metadata - descriptions from CR2 to jpg ?
BUT - that doesnt work - the field "versioning" is not active - I cannot find my mistake....

I'm a DxO user also (NEF instead of CR2, but otherwise should be the same experience). I add metadata via IM to the NEF as xmp buddy files. Sounds like the same workflow so far.

When I process NEF files in DxO, the resulting jpg files contain the metadata I've added in IM; IM doesn't need to do versioning (unless I later go back and add metadata changes to the NEF files in IM). Is that not what you're seeing?

[Arthur]

Only that NON keyword categories never go into XMP, so that DxO cannot write them to the JPEGs. I want to have the JPEGs in the same categories as the raws so that version stacks stay together.

If only XMP metadata has to be propagated, the version relation is not needed, I think. You must only activate the checkbox in the DxO settings, something like "receive XMP metadata from RAW images".

[jch2103]

Only that NON keyword categories never go into XMP, so that DxO cannot write them to the JPEGs. I want to have the JPEGs in the same categories as the raws so that version stacks stay together.

If only XMP metadata has to be propagated, the version relation is not needed, I think. You must only activate the checkbox in the DxO settings, something like "receive XMP metadata from RAW images".

In those cases, yes, of course.

[Aubrey]

I've recently started using DxO.
I export DNG files. Of course there are not processed correctly if loaded in LR - theres a lot on the web explaining why this is so.

However if I want to reload into DxO, I would just reload the NEF, the DxO associated buddy will reload all the operations already done in DxO. (Again DNG from DxO is not reloadable in DxO - bizarre!)

In general I don't like jpgs for archiving. I could use Tiffs, but I think they are too voluminous (files too big!)

I have a setup:
Version
Master: Name_DxO.dng
Version: Name.dng (It might have been previously processed in LR)
Version: NEF
Version: jpg

Might have file only processed in LR, then:
Master Name.dng
Version: name.nef
Version name.jpg

It appears to work well.

Aubrey.
PS: If anybody wants details of setup let me know.

[Mario]

Have you compared ZIP-compressed TIFF files with DNG?
If you are concerned about archival and longevity, I would rather go TIFF than DNG. Adobe changes DNG all the time (when they need something new for one of their applications) and the DNGs written by other software on the market also differs. This may cause issues in 10 or 20 years.

[sinus]

Have you compared ZIP-compressed TIFF files with DNG?
If you are concerned about archival and longevity, I would rather go TIFF than DNG. Adobe changes DNG all the time (when they need something new for one of their applications) and the DNGs written by other software on the market also differs. This may cause issues in 10 or 20 years.

I must stress this. I also had DNG in mind, but after read a lot of troubles from users, I let it be. But of course, the idea of DNG is fine.

[Arthur]

I thought also for two minutes to convert cr2 to dng, but if you read about problems with them, there is no reason to have them. you can always convert cr2 to dng, but you cannot convert in the oposite direction. you can embed the raw into the dng, this only doubles the file size without advantages. The dng which comes out of dxo is a linear dng, which is more a bitmap than a raw. So no advantage over tiff there, if you get the tiff ziped.

The only value a dng might have is the ability to use new raw formats in old software.

Because I do not want to spend around 100 mb on each tiff but want to see the exact dxo colors and exposure, jpegs is the only thing, what makes sense for me as a preview. I have bought Affinity Photo for pixel editing, but used it maybe 5 times in last year, so a 16bit prophoto tiff is needed almost never here. It all depends on what are your use cases.

[Belenos2017]

Thank you very mutch - Now it works! My mistake was looking for the definition of versions in another window than the definition of buddy files - and not in the same window!

You can read the help file 10 times - and always ignore one important sentence. And with one hint everything is new... 

[Belenos2017]

Now in my workflow the important step works: Propagation of the XMP-Data of the RAW-FIle to the versions.

NEXT Question:
During the Propagation IMATCH seems to produce a xmp-file for each picture - Why?
Is that necessary? Is it possible to prevent this? Is it possible to delete them? Is it allowed to delete them?
For me it seems sufficient to have all metadata only in the Database?
I always try to clean up useless files....

[Mario]

Propagation is performed in two steps:

1. Writing back metadata to the original file (RAW, in your case)
2. Copying the data from the RAW to the version(s) as configured.

RAW files may only contain EXIF/legacy IPTC/GPS metadata but not XMP data.
XMP data for RAW files goes by definition into a separate XMP file. This is the expected and standardized behavior.
Don't delete the XMP files. When IMatch later is required to reload the image file or metadata it will use the XMP sidecar file automatically. If you have deleted the XMP file, your metadata changes will be lost.

See the Metadata sections in the help for details and background info.
IMatch's default configuration ensures that metadata is safe and compatible with a wide range of applications.