Metadata (capture date) retrievable for unindexed files?

[Datameta]

Hi,

I'm evaluating iMatch (2017.14.1), and are currently looking at scripting.

I know, I can use nearly any approach as long as it does support calling URLs. But I would like to get a glimpse at the current power of iMatch scripting, because when doing the switch I want to be sure that I can do _all_ or _nearly all_ DAM-related workflow tasks within the new platform.

Exercise: Rebuild a simplified LR import workflow stripped down to the basic needs (*), which goes like this.

With a list of image file paths (made by explicit or implicit means) and process as in the following pseudo code.

Code Select Expand

  Foreach $unindexedFile
>>> $date = getCreationDate($unindexedFile) <<<
    $target = $ROOT + "\" + getExtension($unindexedFile) + "\" + getDateString($date, "YYYY-MM-DD")
    $indexedFile = copy($unindexedFile, $target)
    id = iMatch_DB.add($indexedFile)
    applyMetadataTemplate($indexedFile)

Question: can I retrieve the relevant metadata (>>> ...<<<) from unindexed files using the WebService API?


*: I now culling can be done completely in iMatch just like in LR. But some years ago I changed my habits to do the initial decisions (sharp vs. unsharp) outside LR. In the end, it is faster and more straightforward to just import the keepers-at-first-sight.

Maybe an iMatch DownloaderApp would be still a worthwhile way to go....


Thanks,
Datameta

@Mario: from a newbie's perspective the IMatch WebServices™ Documentation could benefit from flagging those web api calls which offer to process file items not yet added to the database.

[Mario]

IMatch has no information about files not in the database. It does not even know they exist.
You cannot retrieve metadata or other information via IMWS for files not indexed by your IMatch database.

[ubacher]

If I understand your desire correctly: You want to only add certain files, selected externally, to Imatch.
If you could put those files all together in a separate directory it would be no issue. You would just add
that directory. But it would still be messy having many unrelated directories in Imatch - impractical I think.

On a more philosophical note: When starting to use Imatch users try to maintain their previous way of keeping track
of images and often go thru great contortions to do so. It's understandable but unfortunate. I would recommend just starting
afresh with new files in Imatch and then, after having gotten to know the capabilities, converting old structure to the new one.

Old Imatch users have a similar problem: we organized our files based on the capabilities of Imatch 3 and then maintained this even though
the newer versions of Imatch would allow a better, simpler way to do things. Change is difficult. Being forced to change is (for me very) annoying.

The incredible flexibility of Imatch can be a curse in this matter: it does allow you to maintain you old ways even though you negate/neglect the already
built in functionality doing so.

[Datameta]

@Mario: Thanks

@ubacher:

The workflow "issue"
My "core" concept was/is the file system layout of my images, it was there (long) before the all-integrated-RAW-DAM-suites.

I've put LR on top of that some years ago. I always liked the catalog approach, because a real DB is pivotal in order to provide sophisticated and fast operations build around the assets.
However, it took me some time to realize the benefits of the import mechanism (as compared to the typical web myths about catalog-based image tools and the folder rescanning LR supports as well):

With a running database I can trigger the chain

select image(s) -> add metadata (by meta-templates) -> copy & rename -> add to database

all integrated, with a single click.

In the end it's just a folder based file picker (thereby offering a first culling instance) followed by a batch processor offering a well-selected choice of configurable and template-based steps. In short: a huge time-saver.


So far for the past.



Now, some more words on my motivation

Since I'm testing iMatch I want to check the "real" limits as much as possible (though I already made a pre-decision anyway), here by means of iMatch scripting/app power to recreate LR import process chain outlined above.

And I don't see any stop sign, since I DO have the endpoint that is mission critical:

Code Select Expand

v1/folders/add


Of course, I could easily flatten all files into one imatch_import folder (using a XYplorer script, for instance). But I want to try to recreate the import chain using all options iMatch offers.

Next thing to check: can I retrieve the creation date on the client side, e.g. using existing node-modules and "adapting" libs like browserify? I suspect no, since the limits are the security constraints of the inbuild scripting/app framework based on Chromium. I will see.

Otherwise, I could "simply" spill out an Electron import app with a layout nicely pairing with iMatch. 

Of course, there are much easier ways - but that's the fun part tools like iMatch offer for the ones loving scritpting fun. ;-)

Thanks for your words.

[Jingo]

Well.. this is I suppose what I do via my RAW editor (C1)...

- import from memory card to RAW Import hard drive via DownloaderPro (folders by date year/Mon, rename files by camera model)
- Import into C1 catalog via synch function (RAW and JPGs)
    - cull, edit, export as JPG to FINAL IMAGES hard drive via batch process
- Import into IMatch via watched folder
    - keyword, label, rate, etc 

Of course - all of this (besides RAW edits) can be done within IMatch directly as well including adding metadata upon import... so... not sure a unique process is needed outside of IM but this is the process I've been using for years..

[Datameta]

Hi Jingo,

thanks for outlining your workflow, very helpful. 

Especially since C1 (Sony edition, as an A7ii owner the A7iii is very tempting) will be likely added to my tool box (complementing LR and Affinity Photo which I have high hopes for future raw development).
Nevertheless, with 3+ RAW developers (they come and go anyway) I want to make the "total" switch, the DAM needs to become the core of my image workflow. That's the current focus of my trial - and my questions.

I should check DownloaderPro, it has been mentioned to often here (though I'm pretty sure, I will cover all "gaps" with the almighty XYplorer).

[Jingo]

Hi Jingo,

thanks for outlining your workflow, very helpful. 

Especially since C1 (Sony edition, as an A7ii owner the A7iii is very tempting) will be likely added to my tool box (complementing LR and Affinity Photo which I have high hopes for future raw development).
Nevertheless, with 3+ RAW developers (they come and go anyway) I want to make the "total" switch, the DAM needs to become the core of my image workflow. That's the current focus of my trial - and my questions.

I should check DownloaderPro, it has been mentioned to often here (though I'm pretty sure, I will cover all "gaps" with the almighty XYplorer).

My pleasure.. and glad it helps in some way.

I agree... RAW converters, downloaders and any viewers on my system are really just stepping tools that are used to get me towards my the ultimate goal of image organization in IMatch.  However, I think it is important to determine the best way for YOU to also get to this point.  This workflow works for me because a) I'm not concerned about the RAW images once I edit them  and  b) I only use JPG's in my DAM for ease of use, speed and ability to share easily with family and friends.

There are many users that do the entire workflow in IMatch... and only open up external software to edit.   

In terms of DownloadPro... the main reason why I use it over Imatch's own download module or XYplorer (which I also use and am amazed at its power) - is because I don't want the images on the memory card to get imported directly into IMatch... I want it stored elsewhere and then only final edits are in IM.... I recommend you review the import function in IM because it is amazingly complete and powerful... you may be able to use it as well.  If no - I highly recommend DLP...

[Datameta]

... - is because I don't want the images on the memory card to get imported directly into IMatch... I want it stored elsewhere ....

This should be a rather simple "challenge" for a XYplorer script. Once I have it, I'll let you know.

... and then only final edits are in IM.... I recommend you review the import function in IM because it is amazingly complete and powerful... you may be able to use it as well.  If no - I highly recommend DLP...

"Final" edits means metadata edits, right?

[Jingo]

... - is because I don't want the images on the memory card to get imported directly into IMatch... I want it stored elsewhere ....

This should be a rather simple "challenge" for a XYplorer script. Once I have it, I'll let you know.

... and then only final edits are in IM.... I recommend you review the import function in IM because it is amazingly complete and powerful... you may be able to use it as well.  If no - I highly recommend DLP...

"Final" edits means metadata edits, right?

Correct... metadata edits including Geo data via the Map panel, ratings, labels, colors, etc.  I also write all catalog details back into my JPG's to allow these images and all details to be opened in any software that supports XMP including web galleries and/or other photo viewers.