PM, iMatch and some questions

[wiesiek]

Hello!

I am on my second day of evaluating PM and I must admit I like it a lot so far. I want to use PM together with iMatch (a very nice DAM application). Everything seems to be working just fine except the Unicode encoding. I am using UTF-8 in iMatch and when I fill some IPTC fileds in PM (with the "use Unicode" option turned on) they do not show up in iMatch correctly, even though both apps use UTF-8. Stange. I am using PM on WinXP Pro. Am I missing something?

I have one more "PM question": is it possible to hide/mask files in PM? For example, if I use Bibble with some of the files I will get a bunch of ".bib" sidecar files which I would prefer to hide from PM (or even better PM should allow me to associate them with the appropriate image files). Is it possible? If not yet then do you plan to introduce such a feature?

Wiesiek

[Kirk Baker]

Wiesiek,

I am on my second day of evaluating PM and I must admit I like it a lot so far. I want to use PM together with iMatch (a very nice DAM application). Everything seems to be working just fine except the Unicode encoding. I am using UTF-8 in iMatch and when I fill some IPTC fileds in PM (with the "use Unicode" option turned on) they do not show up in iMatch correctly, even though both apps use UTF-8. Stange. I am using PM on WinXP Pro. Am I missing something?

What fields are not showing up correctly in iMatch?

I have one more "PM question": is it possible to hide/mask files in PM? For example, if I use Bibble with some of the files I will get a bunch of ".bib" sidecar files which I would prefer to hide from PM (or even better PM should allow me to associate them with the appropriate image files). Is it possible? If not yet then do you plan to introduce such a feature?

What would be the full name of such a file?

-Kirk

[wiesiek]

Dear Kirk,

thanks a lot for looking at my problem!

What fields are not showing up correctly in iMatch?

I was using only two fileds: Author and Copyright  (they ended up in iMatch as By-line and Copyright respectively). Both contained some Polish characters.

What would be the full name of such a file?

The base name would  be the same as the image base name e.g. DSC_1234.bib (for DSC_1234.JPG). Actually I also encountered a problem with the ".xmp" files for JPG's. They also showed   among the "images" in PM. I know that PM at least prefers embedded XMP for JPG's but maybe if the xmp files exist PM could hide them in a similar way?

Wiesiek

[Kirk Baker]

Wiesiek,

What fields are not showing up correctly in iMatch?

I was using only two fileds: Author and Copyright  (they ended up in iMatch as By-line and Copyright respectively). Both contained some Polish characters.

What characters had you entered in those two fields?

What would be the full name of such a file?

The base name would  be the same as the image base name e.g. DSC_1234.bib (for DSC_1234.JPG). Actually I also encountered a problem with the ".xmp" files for JPG's. They also showed   among the "images" in PM. I know that PM at least prefers embedded XMP for JPG's but maybe if the xmp files exist PM could hide them in a similar way?

XMP is supposed to be embedded into JPEGs and never supposed to be in a sidecar file.  We're just not going to recognize them.

I didn't know Bible made .bib files for JPEGs.  Usually it does things like DSC_1234.NEF.bib and we handle that correctly.  Why doesn't it do JPEGs the same way (DSC_1234.JPG.bib)?

-Kirk

[wiesiek]

What characters had you entered in those two fields?

It was just one letter: "ł" (a crossed "l") - it unfortunatelly appears twice in my name

didn't know Bible made .bib files for JPEGs.  Usually it does things like DSC_1234.NEF.bib and we handle that correctly.  Why doesn't it do JPEGs the same way (DSC_1234.JPG.bib)?

Sorry - you are absolutely right! The bib files for JPGs have exactly the same name pattern as for NEFs (actually Bibble makes all the characters lowercase - at least on my machine - Bibble 4.9.5). I am absolutely positive that Bibble creates bib sidecar files for JPGs. It would be great if they were treated the same way as the ones for NEFs.

XMP is supposed to be embedded into JPEGs and never supposed to be in a sidecar file.  We're just not going to recognize them.

Yes, I know and you are right - in a sense xmp sidecar files for JPGs should stay visible under PM if it does not support them (i.e. does not read/write to them), but is it raelly the case? In my workflow, after some tweeking, I managed to configure all the apps so that they will not create xpm files for JPGs.

Wiesiek

[Kirk Baker]

Wiesiek,

What characters had you entered in those two fields?

It was just one letter: "?" (a crossed "l") - it unfortunatelly appears twice in my name

Can you send me a file that you have captioned in this manner?  I'll check to see if the characters are being encoded properly.  Otherwise I suggest you talk to the IMatch people about this issue.

Contact me directly by clicking on my name to the left of this message and send me a Personal Message.

didn't know Bible made .bib files for JPEGs.  Usually it does things like DSC_1234.NEF.bib and we handle that correctly.  Why doesn't it do JPEGs the same way (DSC_1234.JPG.bib)?

Sorry - you are absolutely right! The bib files for JPGs have exactly the same name pattern as for NEFs (actually Bibble makes all the characters lowercase - at least on my machine - Bibble 4.9.5). I am absolutely positive that Bibble creates bib sidecar files for JPGs. It would be great if they were treated the same way as the ones for NEFs.

I'll look into adding that support.

XMP is supposed to be embedded into JPEGs and never supposed to be in a sidecar file.  We're just not going to recognize them.

Yes, I know and you are right - in a sense xmp sidecar files for JPGs should stay visible under PM if it does not support them (i.e. does not read/write to them), but is it raelly the case? In my workflow, after some tweeking, I managed to configure all the apps so that they will not create xpm files for JPGs.

We only create/update XMP inside JPEGs.  We ignore XMP sidecars for JPEGs.

-Kirk

[wiesiek]

I have tested the problem and from what I can see Photoshop CS2 reads the IPTC fields just fine. So probably it is not PM's fault that they do not get imported correctly into iMatch. I will have to contact iMatch developers it seems.

I'll look into adding that support.

Thanks!

All the best
Wiesiek

[Kirk Baker]

I have tested the problem and from what I can see Photoshop CS2 reads the IPTC fields just fine. So probably it is not PM's fault that they do not get imported correctly into iMatch. I will have to contact iMatch developers it seems.

A while ago I had some discussion with Mario Westphal about captions created in Photo Mechanic that at the time were only encoded in the MacRoman character set.  I think he made a change to interpret the captions as MacRoman which may be what is going on here.  IMatch could be interpreting the data as MacRoman when in fact the data is in UTF-8 encoding.

The reason you are having success with CS2 is likely because you have told PM to write out XMP as well and Photoshop CS(1, 2, 3) prefer XMP over IPTC and are only interpreting the XMP data.

Maybe there is a setting in IMatch that allows you to tell it to use XMP instead of IPTC?

-Kirk

[Juerg]

Hi Wiesiek,

I hope you don't mind if I 'highjack' you post for a question regarding PM and iMatch.

I use PM for about 4 month now and it became the center of my workflow. But using the XP version I don't have any search functions accross multiple folders based on embedded metadata (I know the PM team is working on a cataloging funtion, but it seems to be a while until it's available).

I therefore tried iMatch to use as my cataloging program. I like it for what I need it for, but also ran into some troubles in syncronizing color labels generated in PM to iMatch.

It seems that if I label a picture in PM with YELLOW, and after that I add it to the catalog in iMatch, it show the label in yellow. So far so good.

If I now change the label of the same picture in PM to lets say GREEN (which I usually do after final editing), the label in iMatch refused to change and will stay in the original YELLOW, not matter what I tried (manual sync etc. didn't change). Other information that I change in PM (like star rating, IPTC info etc.) are updated OK in iMatch, but not the color label.

Do you have the same problem or if not how do you manage to sync the label from PM to iMatch?

Thanks,
Archer

[Kirk Baker]

Archer,

I hope you don't mind if I 'highjack' you post for a question regarding PM and iMatch.

I use PM for about 4 month now and it became the center of my workflow. But using the XP version I don't have any search functions accross multiple folders based on embedded metadata (I know the PM team is working on a cataloging funtion, but it seems to be a while until it's available).

I therefore tried iMatch to use as my cataloging program. I like it for what I need it for, but also ran into some troubles in syncronizing color labels generated in PM to iMatch.

It seems that if I label a picture in PM with YELLOW, and after that I add it to the catalog in iMatch, it show the label in yellow. So far so good.

If I now change the label of the same picture in PM to lets say GREEN (which I usually do after final editing), the label in iMatch refused to change and will stay in the original YELLOW, not matter what I tried (manual sync etc. didn't change). Other information that I change in PM (like star rating, IPTC info etc.) are updated OK in iMatch, but not the color label.

Do you have the same problem or if not how do you manage to sync the label from PM to iMatch?

Wiesiek may or may not have an answer for you, but I'd expect that the folks at IMatch would have a definitive answer or would tell you that what you're describing is a bug that they didn't know about and need to fix on their end.  I think it would benefit more people if you notified the IMatch folks about the issue and see what they have to say.

HTH,

-Kirk

[wiesiek]

Archer,

I started to evaluate PM four days ago so I have no real experience with it yet. I use iMatch for one year and I like it a lot - I am sure that if the problems we are having with transferring ratings to iMatch  turn out to be iMatch bugs they will be fixed pretty soon. I hope that PM and iMatch will work together nicely. I plan to use PM in the "pre-cataloging" stage of my workflow, e.g. to review and rate the images before cataloging them with iMatch. Maybe also the category assignment could be done in PM and then automatically transferred to iMatch (this part would require a specialized script to be written). I am investigating this possibility at the moment. Actually I do not think PM has to be extended with cataloging features. There are good cataloging apps around and what we lack is a reliable interface between PM and such apps. I have tried many cataloging apps and none of them is even nearly as fast in preview/rating as PM.

Kirk,

I have to check if the problem is MacRoman-related but I would be surprised if it was. iMatch 3.6 (the current version) has an extensive UTF-8 support combined with appropriate conversion mechanisms for "older encodings". Actually, in my case PM has been configured to "use ISO8859-2 and write it as Unicode", so there was no MacRoman around...

Wiesiek

[Juerg]

Just a short update in case someone else ask the question in the future:

It turns out that IMatch has as standard a preference setting that creates XMP sidecar files for all file types, even these that support embedded XMP dadas. With this setting, all in-file XMP data generated by PM will be ignored for JPG and TIFF fiels. On the otherhand, all labels ratings generated in IMatch for JPG and TIFF are written to sidecar files and subsequencely ignored by PM.

As soon as the two options in IMacht were unchecked (means it reads embedded XMP and writes embedded XMP), the synchronization worked fine.

Archer