Best way to remove a master-file and keep its associated buddy-files only?

[leifel]

I shoot RAW-files and export to JPG after editing them with PhotoLab. The exported JPG-files are then buddy-files. This works well, except I find it a bit cumbersome to toggle whether to show the buddy-files as separate thumbs in the files-list. But this is not a big problem. Problem is that when I delete a buddy-file its associated master-file is also deleted. But I want to keep the buddy (JPG) only, and delete the master (NEF) once I have finished editing the RAW-image. What is the best and safest way to achieve this in IMatch?

What I do no is deleting the NEF-file from outside IMatch and then do a "Rescan now" operation on the folder. But I feel this is a bit unsafe and I probably risk loosing some metadata that is associated with the master-file only (for example the GPS-coordinate, if I have not remembered to add that also to the buddy-files).

[Mario]

Problem is that when I delete a buddy-file its associated master-file is also deleted

This should never happen. And I just checked and it does not.

When you have a foo.jpg that is a buddy of foo.raw, foo.jpg will be deleted when you delete foo.raw, not the other way round.
Deleting the buddy file foo.jpg will not affect foo.raw at all.

Make sure you don't have setup your buddy file relation in the wrong direction.
Tip: To see the file names of buddy files for the selected file, use this variable in VarToy:

{File.BuddyFiles}

Buddy files are not necessarily indexed by IMatch (e.g. setting files used by some RAW processors) and this variable actually checks the file system to find all buddy files.

[leifel]

Oh, sorry, my fault. I was stating the wrong case in the question. What I mean is that when I delete the master the buddies are also deleted. But I want to keep the buddy and delete the master only (as stated in the subject). Again, sorry. It is getting too late in the evening here.

[Mario]

What I mean is that when I delete the master the buddies are also deleted.

That's the sole purpose of buddy files. They are copied, moved, renamed and deleted together with the master. Else they have no purpose and you won't need buddy files.

In the very, very rare occasion you must delete a master and retain the buddy you can move the buddy to another folder or temporarily disable the buddy file relation.

If you find yourself in a situation where you have to delete the master but retain the buddy often, consider rethinking your workflow and file organization. Or just don't use buddy files.

[thrinn]

I wonder if you really want to have a buddy relatation rule at all? What is the purpose of the buddy relationship in your workflow?

[leifel]

I use buddy files mostly as the final target of an edited raw-file. I want to keep the raw-file for future use, but "on pair" with the result jpg-file. Whenever I browse, manage and show images using IMatch I want to use the jpg-file as the basis. The raw-file I need only in the "background" in case I need to edit it again in the future. However, for raw-files which jpg is not yet generated (that is unedited raw-files in my case) I want to se and use the raw-file as the basis. This is the closest I come to the old way of doing it with NEF-files from older Nikon-cameras, where editing the NEF with Nikon software such as "Capture NX" saved an updated jpg-preview inside the NEF-file itself so I never really needed anything more than the NEF-file. Since Nikon has left this philosophy, and I use newer non-Nikon software to edit my NEF-files, edited NEF-files needs to be represented with separate jpg-files. IMatch is the best software I have found that still lets me operate the pair of raw/edited files as virtually "one single image". With those some problems and limitations, though.

The RAW-files are quite large, and brutally fills up my disks. Therefore, to free disk-space, as times goes by and I am certain that I will no longer need to edit an image, I want to delete the raw-file and keep the buddy jpg-file only. When this happens I would like to keep all relevant attributes of the original raw-file also in the jpg-file. This is, as mentioned, one of the "struggles" with IMatch in my workflow. With IMatch, as of today, it always feels "dangerous" to delete the raw-file. I have to remember to "synchronize and double-check attributes equality" and turn off file relations whatsoever before deleting the raw-files in question, turning it back on when done. But this is cumbersome and time-consuming, so I end up deleting the raw-files from outside IMatch, with those "scary" uncertainties I have mentioned.

I would like IMatch to be able to support my workflow in a better way, and I am a bit surprised that this kind of workflow isn't used by many more people 

[Mario]

With IMatch, as of today, it always feels "dangerous" to delete the raw-file.

Why. Unless you make the JPG a buddy file to the RAW, nothing will happen.
To propagate metadata from the NEF to the JPG you must make the JPG a version, not a buddy file.

Files can be versions without being a buddy file and vice-versa. If you don't want to use buddy files, just don't. Easy.

Versions are not deleted, moved, copied or renamed when the master is moved, copied, renamed or deleted.
You may want none of this, only versions, only buddy files, or both. Which is why IMatch keeps buddy files and versions separate.

And yes, if you propagate data from the RAW to the JPEG and you don't write back before deleting the RAW, data will be missing in the JPG. Metadata propagation is performed by writing back to the master, then copying metadata from the master to the versions. There is a lot going on in that phase, including metadata propagation between XMP, EXIF, IPTC, GPS, and that's complex enough and best managed by ExifTool. 

I would like IMatch to be able to support my workflow in a better way, and I am a bit surprised that this kind of workflow isn't used by many more people

This kind of surprise is not uncommon. Many users think their workflow is standard and used by many, but isn't at all. There are many workflows, and no software can implement them all. Not without drowning in options and settings and causing a lot of "shot yourself in your own foot" scenarios.

If you make the JPG the version of the NEF you can propagate metadata. Using the JPG as the visual proxy ans version stack proxy allows you to fold the entire stack and see the final image. 

When you now have a A.NEF + A.JPG and a B.NEF in a folder, and you use the File Properties Filter in the Filter Panel with the "hide masters" option, you see A.JPG and B.NEF - because B.NEF is not a master since it lacks a version.
If you use "Hide versions" instead, you see both NEF files.
If you combine "Hide versions" with the "Invert filter" option, you only see the JPG file.

[hluxem]

This is, as mentioned, one of the "struggles" with IMatch in my workflow. With IMatch, as of today, it always feels "dangerous" to delete the raw-file.

I don't think this is really a problem of your workflow with Imatch. I have a similar workflow and it works well with Imatch. The important difference is that I use a versions relation and not a buddy relation. I think the buddy relation is best and meant for sidecar files like xmp and others. For me it also works best to define the jpg as master. That will totally eliminate the "dangerous feeling when a raw file is deleted.

The raw-file I need only in the "background" in case I need to edit it again in the future.

My raw files are in separate directories, they are naturally in the background. I use a hide version/master filter when I'm importing and working on both.


I suggest doing some tests with version rules to see if that's a better option to use Imatch with your workflow.

Heiner

[PandDLong]

I don't think this is really a problem of your workflow with Imatch. I have a similar workflow and it works well with Imatch. The important difference is that I use a versions relation and not a buddy relation. I think the buddy relation is best and meant for sidecar files like xmp and others. For me it also works best to define the jpg as master. That will totally eliminate the "dangerous feeling when a raw file is deleted.

I use the same approach with such related files and I make a jpg version the master.  This master is the one I spend the time to add metadata and then use propagation to copy selected metadata to the versions.  I also keep the originals in separate folders.

To underline Mario's point about variability of workflows...

I am currently working with scans of vintage photos - which I capture in TIFF files.  I edit a copy to get to a jpg version which will be the version for distribution - it is this "target" jpg I make the master.  To support my workflow, I use a couple different version relation definitions - one is for the original scan and the other for edited jpg variations I wish to retain - eg. sepia colour, different crop.  I use the different version definitions as the metadata I wish to propagate is different and it is nice to automatically have them in different collections.  I delete the original scan about 3/4 of the time several weeks or months later.

It did take me a couple of attempts within IMatch to support what I wanted to do in my workflow and I managed to do it without disrupting my overall workflow, metadata, category and folder structure which was already well established using IMatch for just digital photo jpgs. IMatch makes it possible to support my needs and workflow - which may be unique.


IMatch has so many capabilities, it does take a little time to test out different setups to find the one that works best. I have also found that I will make changes and improvements over time - you are not locked in which is a big benefit.


Michael

[leifel]

Turning it around and use the jpg-file as master sounds like a very good idea. I will try that.

Thank you for the tip!

I guess the reason I used nef as master is just because my workflow starts with the raw-file. I have always set up all my cameras to shoot raw only. Now I will change this to shoot raw+jpg to help me shift my mindset. From this point I will think of the raw-file just as a backup version, and the jpg as the master.

[Mario]

IMatch makes no assumptions about which files you consider a master or a version. It is complete agnostic.

The same is true for buddy files.
You can make the RAW the buddy of the JPG. Deleting the RAW then does not affect the JPG, but renaming, moving, copying or deleting the JPG will also rename, move, copy or delete the RAW.

Just give it a think and then use whatever works best for your workflow.