I just did a thorough evaluation of IMatch to catalog all my legacy images. Workflow details will vary for everybody, but I can say this:
 
- DT is a good RAW processor but a lousy Catalog with virtually no metadata.
- IMatch is an excellent Catalog with excellent metadata handling.
- You can use any RAW processor to edit you images and export JPG. With a little smart folder organization import into IMatch will be very easy.
 
If your RAW processor adds metadata, then you have to make sure it matches the controlled value lists in IMatch. This can be a headache for legacy data coming from different sources. But IMatch helps to clean this up.
XMP files are standardized and as such provide an "open" interface to your metadata.
 
The only (major) problem with IMatch is that it is Windows only.
 
Cheers, Jozef dassen
 
 
Sent: Friday, June 19, 2020 at 9:16 AM
From: "Terry Pinfold" <[email protected]>
To: "Guillermo Rozas" <[email protected]>
Cc: "darktable forum" <[email protected]>
Subject: Re: [darktable-user] Are their potential probelms when using iMatch with Darktable.
If you are using windows or Mac you can download and use Adobe Bridge free of charge and this may help you organise your images. 
 
On Fri, 19 Jun 2020 at 12:01, Guillermo Rozas <[email protected]> wrote:
(please keep the answers on the mailing list so everybody can read them)
 
On Thu, Jun 18, 2020, 19:52 tony Hamilton <[email protected]> wrote:

I'm in the process of using LightRoom 6 for both its DAM and its raw processor functions. At the same time I am looking at replacements - one of the main reasons being that most of my raw images come from an X-Trans sensor; Lr 6 does not demosaic these well. DT seems to be a suitable replacement as a raw processor. But it's DAM functions are not ss good as Lr's (so I'm told).

I've never used LR, but that's probably true. DT DAM capabilities are quite basic.

 

So my workflow, were I to be using DT, would be as close as possible to that which I use with Lr: acquire images (with renaming if possible), triage the images using whatever facilities there are in DT (in Lr I mainly use the 'rejected' flag on a quick pass through the imported images), crop, perform tonal correction, lens corrections, sharpening and noise correction, add/update metadata information, especially keywording, then export to jpeg.

OK, DT can do all of that. However, you'll need to be more precise about your workflow to understand if using another DAM in conjunction with it will do what you want.
 
For example, DT exports to the JPG only the metadata it knows of. If you use an external DAM, you'll need for it to independently write the metadata into the JPG, not only to a sidecar file.

For the DAM and metadata editing/keywording I am quite keen on using iMatch because It has a design philosophy which will always allow me to have access to my data  - by writing .xmp files which could be read by an alternative should iMatch cease to become available. I am concerned that DT's use of a  special .xmp is a long term risk - but maybe I don't fully understand the implications.

DT xmp's files have nothing special, you can read them with any other program just as you can read the iMatch's ones (the only difference is the name convention). All the DAM info is stored in standard metadata fields in the xmp file. You can check it by yourself, just open the files with a plain text editor.
 
The main limitation is probably that DT doesn't support many metadata fields, only the most common (although with some extra work this can be expanded in the lasts versions).
 

And that bothers me: if the developers of DT decide tomorrow that they don't want to do this any more, am I locked out of any other offering being able to access my edited images?

No, because even if the current developers suddenly stop working on it, two things will happen:
- somebody else will pick up the code and start working on it (it's open source)
- even if nobody ever touches the code again, the program will keep working forever (or at least until your OS changes enough that it's not possible to compile and run it anymore)
 
> Orr would I have to re-apply all those edits, 
> using the replacement raw processor. I think I
> already know the answer: yes, re-edit - all 50+
> thousand of them. But that is probably no 
> different to any raw processor, including Lr, is
> it?
 
Exactly, that's not different from any other RAW processor.
 
But there is an important difference: as DT is open source, you can actually see what the code does so in principle it's possible to port the editions to another program (which doesn't happen with LR). In practice, however, this probably won't happen because every RAW developer has it's own set of algorithms and it's quite difficult to match them.
 
In any case, as I said before, I wouldn't worry about it for DT. In the worst case scenario you will end up running an old program in a virtual machine.

One of the other requirements that I have for a DAM is that it should  focus on the 'D' part: DT doesn't fully do this: it won't manage or allow me to do complex searches on my considerable portfolio of audio, video or text files, will it?

No, DT only deals with images. And its search capabilities are a bit basic, so you would benefit of a dedicated DAM even for image-only libraries (I use digikam for that).
 
In the end, I think you should try it with a small set of files and see how your workflow works and which difficulties you encounter. You can always ask for specific advice if you get stuck.
 
Best regards,
Guillermo

____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to [email protected]
 
 
--
Dr Terry Pinfold
Cytometry & Histology Lab Manager
Lecturer in Flow Cytometry
University of Tasmania 
17 Liverpool St, Hobart, 7000
Ph 6226 4846 or 0408 699053
 

____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to [email protected]

____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to [email protected]

Reply via email to