Compatibility Aftershot Pro/Bibble

[michael33]

Dear PM-Team,

I am not quite sure whether this is a support or feature request.
A couple of programs, like Bibble/Aftershot Pro, use the following convention for xmp-sidecarfiles:

XXXX.yyy.xmp

where xxxx equals basename and yyy equals the filename extension (for example test01.nef.xmp).

PM uses by default the Adobe convention
XXXX.xmp

Now my question is:
Did I simply not find the feature to tell PM to write out xmp in first mentioned format or is it simply not implemented?
In case it is not implemented, would it be a major hassle to implement an option, in which format to write out sidecar files?

Workaround at the moment is, to let Bibble/ASP read the XXXX.xmp file, make an adjustment in Bibble in order to have a XXXX.yyy.xmp written out and than as a last step manually delete the XXXX.xmp.
With an option for PM to immediately write out the "extended" format, would streamline my work even further. Also with regards to the upcoming catalog, it is almost lilke christmas  , it would be really, really nice, if PM would be also able to read this format of xmp sidecarfile.

Best regards
Michael

[Kirk Baker]

Michael,

I am not quite sure whether this is a support or feature request.
A couple of programs, like Bibble/Aftershot Pro, use the following convention for xmp-sidecarfiles:

XXXX.yyy.xmp

where xxxx equals basename and yyy equals the filename extension (for example test01.nef.xmp).

PM uses by default the Adobe convention
XXXX.xmp

Now my question is:
Did I simply not find the feature to tell PM to write out xmp in first mentioned format or is it simply not implemented?
In case it is not implemented, would it be a major hassle to implement an option, in which format to write out sidecar files?

Workaround at the moment is, to let Bibble/ASP read the XXXX.xmp file, make an adjustment in Bibble in order to have a XXXX.yyy.xmp written out and than as a last step manually delete the XXXX.xmp.
With an option for PM to immediately write out the "extended" format, would streamline my work even further. Also with regards to the upcoming catalog, it is almost lilke christmas  , it would be really, really nice, if PM would be also able to read this format of xmp sidecarfile.

That is very non-standard.  Can Bibble/ASP be configured to permanently use the Adobe-standard file name format?

I know that in the past that Bibble would name its settings files like that but had no idea they did this with XMP sidecar files.

As for implementing a preference for it, I can't say if we will at this time.  There are problems with the whole idea (inconsistent filename length limitations on various file systems) that we don't want to have.

-Kirk

[michael33]

Sadly enough, I believe ASP insists on this behaviour. I also open a support case there.

I believe one reason for this might be the fact, that if you have for example Raw+JPG next to one another in one folder, with the Adobe way of doing things it is not clear to whom the xmp belongs to (not every program does ingest metadata in the jpg itself). With the extended format that becomes very clear. Besides that, I also have no idea why they implemented it this way.

For most modern OS there should be no relevant limitation on the filename length (for unix + derrivates that is even more true). Nevertheless I can see and appreciate your effort to support older OS where this still might be a limitation.
But implementing an option with a hint like "only do if you know what you are doing" is out of question?

Best regards
Michael

[Kirk Baker]

Michael,

Sadly enough, I believe ASP insists on this behaviour. I also open a support case there.

I believe one reason for this might be the fact, that if you have for example Raw+JPG next to one another in one folder, with the Adobe way of doing things it is not clear to whom the xmp belongs to (not every program does ingest metadata in the jpg itself). With the extended format that becomes very clear. Besides that, I also have no idea why they implemented it this way.

For most modern OS there should be no relevant limitation on the filename length (for unix + derrivates that is even more true). Nevertheless I can see and appreciate your effort to support older OS where this still might be a limitation.
But implementing an option with a hint like "only do if you know what you are doing" is out of question?

I haven't heard of any application that supports metadata editing produce sidecar files for JPEG, TIFF, or DNG.  It is expected that metadata be embedded in those formats because they are well documented file formats that support embedding.  PM would never expect to associate XMP sidecar files with a JPEG!  Does this software you're set on using insist on not embedding metadata in JPEGs?

XMP sidecar files always belong to RAW files!

-Kirk

[michael33]

Krik,

thank you for your information. I digged a little deeper and found this in the manual:

"Corel AfterShot Pro stores its settings in an XMP file that is slightly different from other popular image editors and photo management applications. We do this to prevent Corel AfterShot Pro from overwriting settings created by other applications and to circumvent limitations inherent in the current XMP standard (such as only being able to export the metadata from one version at a time, or the inability to save different settings for a RAW file and a JPEG that were created in camera as a RAW+JPEG pair)."


So the main reason is, that they do not want to interfere with other raw converter writing into the same file and the reason I mentioned (there are indeed converter that can writes xmp for RGB filetypes).

Further on this page they state:
"Corel AfterShot Pro reads and collects metadata embedded in image files, in Corel AfterShot Pro XMP files and standard XMP files. The process and order of collecting metadata from these various sources is shown below.
1.   If a Corel AfterShot Pro XMP file exists, metadata is read from this file and no other metadata is imported.
2.   If no Corel AfterShot Pro XMP file is found, metadata is read from Standard XMP files.
3.   If XMP content is embedded in the image file, this is read next and is added to any previously found XMP data, but common fields found in any other source are ignored."

In my mind I would love to connect ASP with PM (Cataloge). Preparing images with PM, the metadata is being read correctly. Then ASP wites out their xxxx.yyy.xmp. Problem here is, that if I change metadata at a later point in PM, there is no possibility that ASP is going to import this (see above order). So possible later exports will have old metadata.

I can see now that this is less a problem of PM and the behaviour on ASPs/Bibbles side is obviously wanted. The correct support case now seems to me to have a command in ASP to merge or even replace metadata from the XXXX.xmp into their XXXX.yyy.xmp.

Thank you for getting this straight.

Michael

[Franz Dur]

Hello Michael33,

I use Bibble (and now ASP) and PM and have no problem at all (bodies are Nikon D80, D7000 and Pana GF1).

I use PM to ingest/rename/geolocalize/complete some IPTC fields. This is written by PM into the normal xmp buddy file. When I open then the NEF or RW2 in Bibble/ASP all this is read and transfered in to a "Bibble xmp" file, xxxxxxx.NEF.xmp or xxxxxx.RW2.xmp, that will also contain all settings/edits applied within Bibble/ASP.

And you are right, the main reason for Bibble to introduce these special xmp was to take care of versioning and of RAW, JPG or Tiff treated differently (Bibble can edit jpg, not just raw).

You can ask Bibble/ASP you to batch write normal xmp files that the future PM catalogue should be able to read.

Francis

[michael33]

Francis,

thank you so much for your input. In fact, I misunderstood the "Write Standart XMP" function not as a command but as a setting. Now I have that figured out.

This way, at least there is a one way compatibility (ASP->Cataloge). Still, one will face the problem, that if you change the "buddy" xmp externally, ASP will ignore this as long as there is an ASP-xmp from former editing in ASP. I already opened a feature request to Corel with the question if a command that rereads the buddy file is possible.

Anyway, I am thinking of maybe implementing the pipe unidirectional anyway. Ingest+GPS+Metadata in PM, than move that whole bunch into ASP and use ASP´s capabilities to manage the Raw part of my Archive (Folder, maybe Cataloge). The Output (JPG, TIF) though, will be PM5´s job  

Just out of curiosity: Do you keep both xmps or do you get rid of the buddy xmp?

Best regards
Michael

[Franz Dur]

Michael,

Your "unidirectional pipe" is very similar to mine, I do most what I can in PM, it has a simple and efficient interface. I find it a logical way to handle the shot to catalogue workflow.

Concerning the normal xmp it really depends: with Panasonic RW2 PM writes everything to an xmp, it has no choice because officially the RW2 has no provision for internal IPTC/XMP. With the Nikon bodies PM writes everything into the NEF, so no xmp buddy file. The beauty of PM is that,once properly set up it does it all alone...

Bibble/ASP can read everything (from buddy xmp or from in NEF metadata) just fine AND output a normal xmp file if needed by an other program.

After going through B5/ASP (sometimes PWP after that) my photos go to IMatch for cataloguing, IMatch can read everything that's in the NEF, for the RW2 it uses the xmp buddy.

In B/ASP you can force a re-read of the buddy xmp of any image by using "Merge external metadata" in the Edit/Settings tab. I keep the xmp, they are about 5 Ko only.

Francis

[michael33]

Francis,

thank you so much. I never realised, that the merge option even existed, which I feel a little ashamed of.
I thank you so much!

Best regards
Michael