IMatch: indexing workflow.

Started by jmsantos, April 26, 2019, 02:51:35 PM

Previous topic - Next topic

jmsantos

Things that I discovered with IMatch.

My workflow in recent years had the following steps:
1. Downloading RAW files from the camera with a card reader using Downloader Pro. This small program allowed me:
- Rename the photos with an own scheme based on YYYYMMDD_HHHMM(etc).ext
- Distribute photos in folders based on Year, Month and Project.
- Introduce metadata with basic data: author, Copyright, project. Also type the file name in the Title field.
- Make a backup of the photos in another location with the same parameters as above.
Import the photos into Lightroom Classic and make the usual settings: metadata, keywords, classification, developing...

This can be done by LR in one step, but with some limitations compared to DP.

As I explained in another post, I am now testing IMatch for more effective management of photos, videos and other documents. IMatch (that is, Mario) has discovered things that weren't right, especially in metadata. For example, for IMatch to show correctly the Author and Copyright metadata written by Downloader Pro, I have to activate the option "Favor XMP sidecar file". But then, IMatch doesn't read the GPS data because DP doesn't write that data to the XMP sidecar. LR does read them and can write them to the XMP sidecar, and then IMatch can read them as well. Ufff.

What would be the solution? Do all that downloading, distribution and metadata in IMatch. Then there is no problem and all programs can read the data correctly. But to do everything that LR can do in one step, in IMatch I have to do three: 1- download the photos to a folder and IMatch indexes those files; 2- Renamer distributes the photos in folders and renames them; 3- Write metadata with a template. Step 3 could be done when indexing, but then I would write the original camera file name in Title, and not the name with the YYYYMMDD_(etc) scheme.

Would it be possible to simplify this? Perhaps it would be better to integrate everything in the indexing process.

Mario

#1
You said that Lr does all that for you. Why don't you use it? Why the extra step of Downloader Pro, which does not seem to handle the Metadata well?
Can't you configure DLP to not modify metadata and do it in either Lr or IMatch?

In the rare case I have to download files directly from a device (I usually use a card reader, for speed), I use the built-in feature in Windows 10.
The Windows Photo app can download from any device, creates folders as needed, distributes files based on date into folders and all that. No external software needed.

Since the folders produced by this step are sub-folders of a folder indexed by IMatch, IMatch picks up all the new files. Apples metadata templates. Organizes the files into workflow categories. I use a simple naming schema so running the Renamer once after I have culled the files in the Viewer I'm done.
-- Mario
IMatch Developer
Forum Administrator
http://www.photools.com  -  Contact & Support - Follow me on 𝕏 - Like photools.com on Facebook

Jingo

I used to use DLp [since moved on to Photo Mechanic] because I process my RAW files into JPG's and only read THOSE into IM (strange workflow but it works for me).  Pretty strange that Dlp doens't include the Origin info inside an XMP section of the sidecar file.  I always do my GPS stuff in IM so never into this.. but that could be the simple workflow change for you as well.

Hmm... I wonder about creating an APP inside IM to be a card reader/renamer/importer.  The app could:

  - Allow the user to select a drive where a memory card resides
  - Allow the user to set advanced renaming of items (folder/image), assign metadata templates, etc using IM variables that get read from the file
  - Read the contents of the memory card items to the folders, applying the rename along the way

Might be too much work for the end result... but an importer within IM would be an interesting experiment.

jch2103

Quote from: Jingo on April 26, 2019, 03:23:52 PM
Hmm... I wonder about creating an APP inside IM to be a card reader/renamer/importer.  The app could:

  - Allow the user to select a drive where a memory card resides
  - Allow the user to set advanced renaming of items (folder/image), assign metadata templates, etc using IM variables that get read from the file
  - Read the contents of the memory card items to the folders, applying the rename along the way


Interesting idea that's occurred to me more than once, but I don't have the programming chops to do it.
John

Mario

I've did some successful tests with the "download" programming interfaces (API) available as part of Windows 10.

But I'm still in the phase of thinking if this would be worth the effort of integrating into IMatch. Because, the functionality accessible via the API are already exposed to the user via the Windows Photo app in Windows 10. This includes folder creation based on date, the date-based renaming etc. There are only limited ways to control how folders are created and file names are modified during the download. The API handles RAW and JPEG files, and XMP buddy files. Not much else. But using this API is required, you cannot access a camera in the same way as a mounted disk or card.

I saw no real advantage of integrating this into IMatch. The old API used by some stand-alone downloader applications may be discontinued in a future W10 edition so the API I used will be 'the thing'. IMatch already cooperates with Windows Photo. When you download files into an indexed folder, the files will show up. Including the new sub-folders if you have advanced rescan on (else you will need to do a Shift+F5 on  the parent).

For more advanced renaming or processing operations, the user will have to run the Renamer anyway. And solving edge cases like downloading into an already existing folder, which would cause a different naming schema (probably) than downloading into an empty folder. Mixing new files with existing ones etc.

IMatch currently just deals with file system evens by rescanning folders and files. Implementing a downloader app would also require a new technology to "group" downloaded files and excluding them from the normal rescan processing based on Windows file system events. Only then IMatch could process the downloaded files in a batch, run the Renamer, Metadata Templates, Versioning, buddy file processing.

This can get real complex real fast. The more I thought about this, the more problems came up. So I put it aside, for a later reconsideration. There is also no real pressure from users. Windows Photo does the job quite nicely already. Others use a dedicated downloader, Lr or whatever RAW processor they use. The DAM is usually at the end of the pipeline anyway. Or, they just drag files from the card reader to a folder in Windows Explorer. This is how I do it most of the time. I always have more photos than can fit on one card.
-- Mario
IMatch Developer
Forum Administrator
http://www.photools.com  -  Contact & Support - Follow me on 𝕏 - Like photools.com on Facebook

jmsantos

Quote from: Mario on April 26, 2019, 03:00:21 PM
You said that Lr does all that for you. Why don't you use it? Why the extra step of Downloader Pro, which does not seem to handle the Metadata well?
Can't you configure DLP to not modify metadata and do it in either Lr or IMatch?

Sure, I could do that. Only by testing IMatch have I noticed that metadata is not correct. In that case,  it's irrelevant to download with the card reader in DLP or Windows Photo (I'll try it). I have verified it is better to introduce the metadata in IMatch than in LR, because as you know LR only writes the data of Creator and Copyright in XMP and not in EXIF.

These tests are helping me to check the robustness of IMatch compared to other options, I have no doubt about this. But from my point of view it would be nice if IMatch could index those folders and at the same time rename and write metadata, with the new filename in the Title field. Currently, indexing and metadata template go together, but not Renamer. I may have to rethink my workflow.

(Thanks for your advice about DeepL translator, very nice (I think  ???)).