Is anyone using Aftershot Pro 3 with IMatch successfully?

[jonz]

I am having trouble setting up metadata sharing (both import and export) between IMatch and Aftershot Pro 3 for jpg, dng, and raf formats.

According to the sparse Corel documentation when ASP imports a photo the first time it reads existing internal metadata and stores it in its database. On subsequent imports (or exports) it writes (or reads) metadata to/from the XMP sidecar file. According to my experience (so far) this seems a bit dodgy. Some tags import from IMatch, but IMatch does not seem to pick up changes in the xmp sidecar file. '

There are a lot of variables though and this is hard for me to figure out.

I've never (willingly) used XMP sidecar files in IMatch, and Mario has pointed out (in another thread) a whole world of XMP sidecar control through preferences>metadata 2>configure file formats which I appreciate but I don't seem to be able to get things working at all. In the XMP export setup, for example, on the metadata 2 tab export is stated as (disabled) and I don't see where that is coming from at all.

Help appreciated, thank you.

[Mario]

This usually just works with the default settings. JPEG and DNG files must use embedded XMP metadata. That's the standard. RAF files are RAW files, and thus use external XMP files.

When an external application changes XMP metadata (embedded or sidecar), IMatch automatically detects this by the modified 'last update' timestamp and rescans the files to bring in new metadata. If you use the protection features under E > P  > Metadata 2, IMatch will retain metadata that is marked as pending in the database, protecting the changes you have done to metadata in IMatch (but not yet written) from being overridden by other applications.

As usual, when you work with multiple applications on XMP data, you need to make sure that each application has written it's changes before the other application accesses the files. Adobe has not designed XMP to be a cooperative metadata handling format.

You should set IMatch to write-back changes immediately (E >  P > Background Processing) or remember to flush out changes made to metadata in IMatch before you use ASP. And vice versa. I don't know if ASP gives you that kind of option.

If you think that ASP has written XMP data, but that data is not shown in IMatch:

1. Rescan the folder in IMatch. Just in case. Does IMatch report new or updated files?

2. Is the last modified timestamp of the image and sidecar changed in the file system? If not, IMatch cannot detect the changes done in ASP.

3. You can see all metadata for your files in the Metadata Panel in IMatch. Switch to the Browser mode.

4. To see the XMP metadata contained in XMP sidecar files in human-readable form (to see what ASP has written), select the corresponding image file in IMatch and run the ExifTool Command Processor via <F9>,<E>. Select the "List Metadata in XMP files" preset and run it. This command finds the XMP file associated with the image and displays its contents.

[jonz]

>>1. Rescan the folder in IMatch. Just in case. Does IMatch report new or updated files?

IMatch flags the directory as changed so I rescanned it. The new metadata did not show up in IMatch. In other words, neither the ratings change or the title etc changes show up in IMatch. Below section lifted from XMP sidecar:

   photoshop:DateCreated="2016-05-21T08:16:56.000Z"
   photoshop:Headline="Headline from ASP"
   Iptc4xmpCore:Location="Location from ASP">
   <dc:title>
    <rdf:Alt>
     <rdf:li xml:lang="x-default">Title from ASP</rdf:li>
    </rdf:Alt>
   </dc:title>
   <dc:rights>
    <rdf:Alt>
     <rdf:li xml:lang="x-default">Copyright from ASP</rdf:li>
    </rdf:Alt>
   </dc:rights>
   <dc:description>
    <rdf:Alt>
     <rdf:li xml:lang="x-default">Caption from ASP</rdf:li>
    </rdf:Alt>
   </dc:description>
   <dc:creator>
    <rdf:Seq>
     <rdf:li>Creator from ASP</rdf:li>
    </rdf:Seq>
   </dc:creator>

Near the top of the XMP file there is also xmp:Rating="4" as well as other lines.


>>2. Is the last modified timestamp of the image and sidecar changed in the file system? If not, IMatch cannot detect the changes done in ASP.

Image file not changed, XMP sidecar changed and correct.

>>3. You can see all metadata for your files in the Metadata Panel in IMatch. Switch to the Browser mode.

As I said, the metadata entered in ASP is not there after update in IMatch. In browser mode all the original metadata is there.

>>4. To see the XMP metadata contained in XMP sidecar files in human-readable form (to see what ASP has written), select the corresponding image file in IMatch and run the ExifTool Command Processor via <F9>,<E>. Select the "List Metadata in XMP files" preset and run it. This command finds the XMP file associated with the image and displays its contents.

When I run the command processor as you say both the rating from ASP and the metadata fields I edited in ASP are visible and correct.

Where am I going wrong?

[Mario]

1.  I assume you are talking about the XMP sidecar for the RAF?
IMatch will not use sidecar files for JPEG or DNG files.

2.  Under Edit > Preferences > Metadata 2, ensure you don't have the protection enabled.

Usually this is all just a no-brainer. IMatch detects the changed XMP file for the RAF and re-imports the metadata. Unless the RAF has XMP data embedded as well, in that case things get more complicated.

[jonz]

OK, well this is the problem: ASP writes the changes to the XMP sidecar file for jpgs. Is there no way to force IMatch to read this data even though what ASP is doing is not correct?

[Mario]

Well, I would rather fix the problem in ASP if I were you. It makes no sense to violate established rules about where XMP data must go for JPEG files. You render your files incompatible with almost all other software out there!

IMatch allows you to override XMP handling per file format. Please see the help for all details. Press <F1> while  E > P > Metadata 2 is open, for example.

This explains how to favor, ignore or force XMP sidecar files. But, really, don't. Not for JPEG or DNG files.

[sinus]

OK, well this is the problem: ASP writes the changes to the XMP sidecar file for jpgs. 

Sorry, I do not know ASP, but if they write changes to a XMP-sidecar for JPGs, that seems to me a bad idea, no idea, why a software does this.

[jonz]

I agree with you totally in principle, but here's the problem:

Lightroom works okay but to tell you the truth I find that the combination of ASP (old Bibble) with the NIK collection filters is a better editing environment. That can be debated, of course, Bibble lacks certain amenities that LR has (and the other way around). But if you want to get off the Adobe treadmill there are limited choices. I shoot with Fuji equipment and something like DxO doesn't even go there. So the sticking point is around interfacing with IMatch (and Photoshop).

Is it possible for me to keep both the internal jpg metadata and the xmp file in sync, while being able to read back in xmp changes caused by ASP? In other words maintain both internal and XMP sidecar in IMatch, and when there are conflicts the XMP sidecar is authoritative if newer, and the internal metadata authoritative if it's newer?

I know it seems ridiculous...and probably it is. It seems like a total headache, like you say.

[sinus]

ASP writes xmp-files in this format, I think:

file_123.jpg.xmp

It hangs simply a xmp at the end of the completely name including the extension (what is for me personally also a bad idea to have two points).

A normal xmp file does replace the normal extension (nef for example) with a xmp.
And a jpg has normaly no xmp-file.

I think, you could sync the sidecar from ASP with a relation-rule. But I am not sure and I am not sure what about writing/reading in IMatch.
(maybe only hold the xmp in sync, but read/write inside IMatch into the jpg directly).

Depending of the importance for you using ASP I would think about a new workflow with other software. Depending of course also about the amount of files you have already done with ASP.

[Erik]

The answer is you can't keep external and internal xmp information is sync, at least not as IMatch is shipped (you could use scripting perhaps).  This is why there was a strong suggestion against external XMP files for the JPEG and DNG files.

Aside, I recall a lot of issues with the fact that Bibble uses an XMP file as their side-car file. I think you'd have to look into details, but I had thought they were only using the external XMP file to hold develop settings and not necessarily any other metadata.  If that was actually the case (I suspect it isn't given the remainder of the thread), you in theory wouldn't have to worry about the file since you probably wouldn't care much about develop settings within IMatch.

Now if Bibble is using the XMP files for everything, you do have options, although all of them are probably going to be a challenge. You do probably want to verify whether Bibble does anything to the XMP information that may be embedded in the first place (knowing that some software can strip information because it doesn't fit their perception of what people should do).

(1) don't edit any metadata in Bibble / ASP.  This could potentially mean the external XMP files either don't get created or only include Bibble information that you wouldn't need outside the software.
(2) Utilize the ExifTool Command Line window in IMatch to merge the external XMP with the internal XMP (and delete the external XMP).  I can see this being dangerous, but with care it could work.
(3) Write a script to copy the data you need from the external XMP to the internal XMP.  This is a variation of (2), but gives you an opportunity to provide automation and perhaps more security in working with the metadata.
(4) Work exclusively with external XMP files per Mario's suggestion before just recognize that you could end up with issues in other software down the road.

----- additional ------

Sinus's comments are what I was remembering.  I think this is why I am thinking it may just be develop settings.  You could just use those .XMP files as buddy files (.jpeg.xmp would be the buddy).  THis still depends on whether Bibble removes all the XMP data that was initially embedded in the file or not.

[jonz]

First of all, thank you very much Mario, sinus, and Erik for helping me on this. A large part of what makes IMatch what it is gets reflected in the community (or university!) that Mario started.

That said, I'm ready to throw the towel in on Aftershot. It's really a shame, it comes so close to being a really good non-destructive editor (at least to my tastes) but yet one quirky decision made long ago to write jpg metadata to xmp sidecars derails the whole project. There's so much I like about it. But it's just unusable in its current form. But don't hold your breath ... I was an early Corel Draw user (in the 80s and early 90s) and the company really marched to its own drum. The end user was really just a bother to them. I migrated long ago to Adobe Illustrator but coming back and dealing with Corel tech support I get the same old vibe. It's a shame, it would be useful to have something lightweight and configurable (as ASP is in some areas).

So, to put it in a nutshell: Corel Aftershot Pro 3 in its current form can't reasonably be used as an editor with IMatch if you expect to maintain any kind of integrity with metadata edits.

[Mario]

If they really store standard metadata like title, description, rating etc. in a separate XMP sidecar file for JPEG and DNG files, they have a problem. Or rather their users. All software I know expects XMP data to be embedded in JPEG and DNG files, because that's the standard, the Metadata Working Group requires it etc. bla-bla. Adobe does it that way - and that means it's industry standard.

I wonder how other AS users deal with that. Or maybe they don't care or know about this. Like the people wo worked with Lightroom and then decided to switch to another RAW processor, learning the hard way that all the edits they did in LR are of no use in other RAW processors. And vice-versa....

IMatch can handle XMP in JPEG/DNG files when you configure it accordingly - on a per file format basis (E > P > Metadata 2: File Formats). But I really don't recommend this, because you make the metadata in your files incompatible with almost everything. Consider the future and a switch to maybe another software...

You can use ExifTool on the command line, in the integrated ExifTool Command Processor in IMatch to re-import the metadata from the XMP file into the XMP record embedded in the JPEG/DNG files, and then delete the XMP file produced by AS. But this should be the last step in your workflow, when you're done with the file in AS.

[jonz]

Let's see if any other Aftershot users are out there and have something to say.

I tried various strategies to try and get Aftershot to write the XMP data internally and it didn't. All changes after import got made to the sidecar file. Wacky, yes, but I believe Bibble did the same. I don't want to admit to having such a bad memory but I think the reason I stopped using Bibble was that it just wouldn't work with IMatch. In those days I didn't have much experience with metadata and it felt like I was switching to a program that offered a future (Lightroom) versus Bibble, which hadn't been upgraded for a long time and also, if I remember correctly, had just been sold to Corel. But my bottom line is that while it's undoubtedly possible to write the sidecar data back using the ExifTool processor, I'd rather take your advice and stop experimenting with ASP, and stick with LR. What's the saying ... "better the devil you know than the devil you don't..."?

[Mario]

It's not uncommon that users who migrate to a DAM (not just IMatch, any capable DAM) realize that the metadata they have in their files (if there is any) is often in a real mess...

I was involved in a number of consolidation/migration projects where all kinds of files and metadata had to be converted into formats considered safe for the future and long-term archival. Thanks to the combined power of ExifTool, IMatch scripting and other tools it was always somehow possible to get everything up to a state where the metadata in the files became actually usable.

These experiences are the reason why I'm so keen on sticking to standards, why IMatch is so pedantic about the (still fuzzy) metadata standards we have today etc. And why IMatch follows the 'data in files first' approach - because this requires proper standardization and also makes your files (and you!) independent from IMatch or another specific software. Once your metadata is in a proper format like XMP, you can never lose it.

I know that this is bad, from a business perspective. Making it hard for your users to switch to another software is better, because it increases customer retention. As are subscription-based models where you basically lock your customers in for a lifetime. But I'm more for the open cross-application / cross-platform approach. That best for the user in the long-term.

[Erik]

From my own perspective, I think you'd have to ask yourself exactly what you want out of ASP?  I think many people (I had this problem when I tried to use LR with IM) get into trouble using software like LR or ASP for more than just developing.  If you start using the software for DAM features like keywords, then there ends up being havoc because you're using two software for DAM at once.  It really shouldn't matter (and I've made it so I could do some in LR if I wanted to), but things get simplified if you just use the software for PP and leave the DAM to one program.

For instance, if you are just using ASP for processing, the external XMP files it creates would be unimportant for your IM workflow.  Why?  because ASP would only be using those files to write processing/develop settings to the external XMP files.  My recollection (albeit dated from trying Bibble towards its end) is that it leaves XMP data that is already there alone.  They recognize that they can't break your ability to use the software elsewhere by completely erasing it.

In this regard, ASP's XMP files are really just buddy files for their system, which is why I think they broke to standards by tacking on the XMP extension to the full file name, ****.jpg.xmp.

Now, I think problem gets to be that ASP apparently writes any other metadata changes to those same XMP files.  So writing keywords in ASP will cause the problems you are seeing.

Ultimately, you need to decide how important ASP is to you.  Can you make it work and change your workflow accordingly.  IM could still help with the XMP's through a buddy file relationship, but it's going to take effort if you intend on reading information from them.  Conversely, if you have other Post-processing software you like, you could just change.  It's really just a matter of preferences.  If ASP is good for your photography, it would be hard to dump it completely.  But if you can make LR, DxO, Capture One, Silkypix, etc. work, then maybe it's worth a change.

[jonz]

>>what you want out of ASP
I guess the simple answer is a high-quality production-grade non-destructive editor that handles all formats, including Fujicolor RAW, and isn't totally precious (meaning that the interface isn't from Mars).

The Corel program does okay. That said, it has a lot of trouble (like doesn't work) with different flavors of TIFs and all psd files. I'm not convinced too on RAF (Fujicolor RAW), but at least it reads them. It blows out on its handling of metadata, as shown in this thread.

The complicated answer is that I want the above, but with the ability to go back and forth with IMatch.

Lightroom does this pretty well...I object to Adobe's endless corporate expansionism, however. Most especially, in how they are already starting to hobble the latest version of non-"cloud" Lightroom. In my opinion, the writing is on the wall.

It's like Mario says - it's bad business to remain open software but IMatch's values are where I've cast my net and agree, and I need something that works with it. I have this fantasy that Mario will go back to having an integrated environment and he'll buy Bibble and make it work ... but I know that's a fantasy and that probably a lot of people would be annoyed because their workflow is already set. This should be another thread but the real sticking point for me with Lightroom is the need to move groups of photos between the two programs (IMatch and Lightroom). Like I said in another thread - in ASP it's a drag and drop from IMatch, which is good enough for me. No drag and drop in Lightroom and using tags or other metadata just doesn't work for me - there are too many files and it's just too slow and cumbersome or else people are doing it some way I don't know.

Ferdinand used to have scripts for IMatch > Bibble that made a snap in moving groups of photos, but those days are long gone.

So I stick with Lightroom, which I guess is the norm.

By the way, I actually had to ask Corel tech support to stop contacting me. I haven't dealt with end-user tech support in a while, and Corel's flavor is truly bizarre. I would like to defend a Canadian company, but ...!

[Erik]

I think you can make it work. 

1) Don't actually change metadata in ASP (i.e. don't mess with keywords, captions, titles, etc).
2) Define ASP's unique XMP files as an independent buddy file (since they aren't normal XMP files)
3) Get it out of your mind that you need anything from those XMP files.  I don't think ASP will actually eliminate the XMP data that IMatch uses.  ASP's XMP files are just extra.  You could probably even delete them. 

You should be able to work without changing software. 

You could even test this by just deleting one of the ASP XMP files and see whether you are losing anything. 

[cytochrome]

Jonz,

I didn't read the forum for some time so I see your post only now, as long as IMatch works fine I just catalogue my photos.

I use ASP (ASP3 Pro) with the Nik filter collection, I find it an excellent combination and I am used to it since the early Bibble days. I have a simple workflow and really no problem at all:

- I ingest/rename/annotate/locate/geotag my raw files (NEF and RW2) with PM5. I could do all this with IMatch as well, it is simply a routine that I have since years (old guys tend to stick at what works -for them-). PM5 writes xmp sidecars for the raw

- I open the raw files in ASP, do my stuff. I never trouble even to look at the metadata in ASP, if something is wrong/missing IM is a much better place to work on metadata. Of course I don't use the ASP "catalogue", this is what I pay  IM for

- I open the folder in IM everything is there. Since I am of the "everything in the raw" confession I run a EP script to transfer all metadata to the raw, so the derived JPGs and TIFs will inherit everything.

Francis

I hadn't read the whole thread Seems to me part of your problem is that ASP uses sidecars with an XMP file type. This is idiotic since they are not bona fide xmp files in the general (adobe) sense although they include metadata. ASP can write out "real" xmp sidecars for the raw on demand, I don't use this. If you don't ask for it ASP does not fiddle with the original sidecar that is written by PM5, so ASP is transparent metadata wise. In IMatch Exiftool takes good care of all this (PM writes some tags of it own).