BBPro does not read PS/CS2 IPTC data in JPEGs from ACR...

[CameraShooter]

I searched on 'IPTC' and didn't find this reported or discussed, but if it's an old topic and I missed it, pls point me to the thread and I'll research it further.

Problem: BBPro 1.1.3 does not read IPTC data inserted by PS/CS2 Bridge, actually ACR.

Details: According to a reply to a post I made on the Adobe ACR forum, Thomas Knoll said, "The IPTC data is inside the XMP which is inside the JPEG. You need to use an XMP aware JPEG reader to see the IPTC data." As per tests performed by another person I'm conversing with in a dpreview thread, some IPTC/EXIF viewers see the data and some do not. Opanda and BreezeBrowser do not. Pixvue (never used) I'm told does.

I'm investigating using CS2 as my raw converter (no offense Chris, but crop, level and curves are too seductive). BUT, I'm 10000% committed to using BBPro before and esp. after CS2 in my workflow. Nobody has the rename power that BBPro does, nor does any other tool allow me to sort through pictures faster, or build output files with the same flexibility. But it's critical that all the metadata in the JPEGs coming out of CS2 be recognized by BBPro because right now, I am unable to capture a picture caption at raw conversion time (in ACR), and have that caption recognized by BBPro when I send the ACR output JPEGs through BBPro to build my HTML folder.

Thanks, and thoughts?

[roberte]

In CS2 Adobe legacy support for IIM is switched off by default and you need to enable it in the Adobe Bridge preferences. Adobe appears to also have broken legacy support for some older IPTC IIM filelds.

To be fair XMP is an Adobe initiative, so it's no wonder that Photoshop supports it. You are correct some apps do support it, but most still do not read and/or write XMP. Although XMP is an open format Adobe still control it.

ACR XMP sidecar files are also based on an open format but could be considered proprietary Adobe tags.

Adobe doesn't support Breeze Browsers dat files :D.

-- Robert.

[CameraShooter]

all I really want to know is whether there's some way to enter IPTC data into CS2/Bridge/ACR and pass it through to BBPro so it can appear in the files in the BBPro generated HTML folder. I'm still not clear from your answer whether that's possible

I looked in Bridge and in Edit, Preferences, Metadata, and ALL the fields in the IPTC (IIM, legacy) section are checked. I assume this is what you mean when you say the fields need to be enabled. They were this way before I ran my tests. So that would mean that CS2/Bridge/ACR is storing data in the legacy fields. This matches what I see when I look at the metadata with Bridge. The data I put into the headline field is identical in both copies, both Core and Legacy.

So while I do appreciate the explanation, and I have no special love for Adobe, what I really need to know is whether there's a way to do what I need to do. If not, I need to seek other solutions.

Thanks

[CameraShooter]

is to enter the IPTC data by BBPro into the Canon raw files before they get to PS/CS2/Bridge/ACR, but only if the added IPTC data in the CS2 created output JPEG is accessible by BBPro.

That's the key: BBPro must be able to see the added IPTC data, however that occurs, because right now, all that data is lost.

This really is a major disconnect that has to be fixed for my workflow to be usable. I understand the games Adobe is playing, and how difficult it is to be the tail when they're the big dog. But in my position as a consumer, a photographer, I can't afford to care. I need a usable workflow, and if I decide to use CS2 for my raw conversions, then BBPro may have to be replaced.

Thanks again for your explanation

[CameraShooter]

Took a brand new spanking clean CR2 file and entered a unique headline value. Adobe clearly sees it in Bridge, and passes it through, presumably only in the XMP package in the output JPEG. Pixvue can see the data, but BBPro can not.

Unless I can find some quick batch process that can move the XMP package data into whatever fields BBPro is seeing, this is a hard down for those who choose to use CS2.

I'm still holding off making a final decision until RSE comes out with their fee based version. Likely as not they will be more legacy and 3rd party application friendly.

[roberte]

Until Chris confirms whether Breeze Browser has the ability to read/write XMP I think you've already worked out the best approach. Caption in BB, process in ACR.

Good luck.

-- Robert.

[CameraShooter]

I have no good or best approach. Right now there's a hard disconnect if I expect to continue using BBPro to generate my HTML folders AND I want to continue seeing captions in my online posted pictures. It does not matter how the caption or headline or anything gets into the picture. If I use BBPro to process JPEGs from ACR 3.1, the caption/headline/whatever you insert will NOT come through because BBPro can not see it. Hard break.

The only possible workaround is an as yet undiscovered program to "copy" XMP package/payload IPTC data into the fields that BB CAN see, and to do that as a separate step after ACR and before generating the HTML. That manual step would go away once BBPro was fixed. But as of this moment, I haven't discovered such a program.

I agree that at some point, BBPro will either have to support XMP or else just forsake interaction with other products that do.

Thanks again for your thoughts.

[Chris Breeze]

I'm working on an update to read "IPTC" data from the XMP data. One of the problems is knowing what to do if the IPTC data is stored in more than one format and the contents are different.
Currently BBPro reads and writes IPTC data from the IIM block in JPEGs. It is relatively easy to update BBPro so that it reads the XMP block if the IIM IPTC data is empty.

[CameraShooter]

I hope I haven't sounded like I was trivializing what it takes to be the tail when Adobe is the dog. I also understand the problem/issue you described, and I'm sure you've already come up with many more creative ways to handle it than I could offer.

But I might suggest that however you do it, let the user (me) indicate WHICH block is priority on a folder by folder basis, i.e. store the setting in .dat. Even better, let me also decide whether to ONLY take data from that block, or whether to merge with priority. Past that, which is essentially a block level setting, we get into field by field settings, which in my limited view is excessive and unnecessary. Again, all I'm trying to do is hook up with the IPTC data that's being derailed as my raw files get processed by CS2.

The arrangement you describe, always taking XMP if IIM is empty, would certainly solve my PS/CS2/ACR3.1 integration problem. I could annotate in BBPro OR Bridge, the only issue being that if I go BACK to BBPro after the Bridge cache is built, I need to flush and rebuild the cache. And if I already have an XMP sidecar for a picture, I would need to delete the sidecar or I suspect that even without a cache Bridge won't use IIM fields to override XMP sidecar fields. But again, that's MY problem if I choose to create such a complex arrangement. Key is that for a "normal" workflow, data is transformed but retained.

Thank you for your attention to this matter.

[Earl Robicheaux]

As a new member to Breeze Browser and IPTC captioning, I became seriously interested in getting my digital files up-to-date with IPTC labeling when I was jointly beginning to build a digital asset management system of my image files. With Adobe’s Bridge, it applied IPTC captioning to various raw camera files (like Breeze Brower Pro). Upon doing some research, I have determined that Adobe was instrumental in the adoption of the new XMP and IPTC core format now being used by Adobe’s products and considered the standard by IPTC. (see http://www.iptc.org/IPTC4XMP/). Also, I determined from my research that one can either use the old IPTC IIM format in Adobe Bridge, or one can use Adobe’s new XMP core format, but you cannot use both because it writes over the camera metadata. So, I see this whole thing as a serious problem in transition. A lot of software, including Breeze Browser is programmed to read the old IIM IPTC format and not the new XMP IPTC core standard. If we start using the new standard, which will probably become the convention in the future, the only software right now that will read it is Adobe’s.

I came to the this forum to see if Chris Breeze is planning on going to adapt the new XMP and IPTC Core product. In all honesty, I like the new format and it makes a lot more sense than the old format.

Earl

[Evo2Me]

With PSCS2 can you still decide to carry the annotations (IPTC, EXIF, whatever) with the file itslef or are you confined to XMP sidecars?

If the latter it bears problems because files can easily be orphaned. For instance, while MediaPro does support CRW from Canon, it does not connect them to the THM files, which are essential as only they hold all the EXIF/IPTC info. Rather distressing to have annotated a file generously, written everything back to the file, open the CRW in another prog just to see - not!*

Potentially the same happens with any sidecar file.

So, where do you save annotations, XMP sidecar or within the original?


*Canon's files greatly break a good work flow except when you are using a Breeze-only one. The biggest advantage of MP over cumulus is they possibility to manipulate the file system from within the catalogue. Nice if you move or copy a CRW, annotate it, change its name, and have to find the THM later.

[Chris Breeze]

The old IIM standard has been around for over 10 years and is supported by most apps. The new standard will gradually take over, but it isn't going to happen overnight.
It is relatively easy to read the data from the XMP block, but writing the data and handling existing 'legacy' IIM data is more difficult. The latest beta version of BBPro (BBPro v1.2 beta 3) will read and display the XMP IPTC data if the image doesn't contain IIM data. The next step will be to change BBPro so that it both reads and writes IPTC in XMP form and only reads IIM data if there is no XMP data.

[CameraShooter]

:) I just reprocessed some old 10D pictures that contained captions/descriptions that CS2/Bridge/ACR had carried through into both legacy and core blocks, but which beta 2 couldn't see. Now with no additional processing from CS2, BBPro was able to use the converted JPEG files from CS2 and carry the descriptions through into the HTML folder, where they show up as expected. That's excellent and I can just re-process the folders I've already "converted" to CS2.

Now, I didn't test keying in a description into a new CR2 file with beta 3 and taking it through the whole process. I'll test that later today. BUT, I'm back in business.

THANK YOU AGAIN CHRIS :D