This behavior is consistent with a number of applications such as, Microsoft Photo Info, IrfanView, etc. Once the IPTC data is touched by one of these applications, Picassa will see it, even if modified later by iMatch. You can use MS Photo Info tool to add 1 field to the IPTC data of a group of pictures and henceforth Picasa will read it. This somewhat minimizes the pain you are experiencing, but does add a field to your IPTC data that you may or may not want to be there.

If you take an image that iMatch has added IPTC fields to, copy it and touch it with any of the above apps, the differences are interesting. The header data is laid out in a completely different manner. Might be the same data, but the layout is different.

In an earlier message, I quoted documentation from the 'libiptcdata' Reference Manual which acknowledged the problem and indicates a resolution.

Announcing that an issue is not your problem does not fix the problem as it is obvious more than one customer is struggling with this issue.

Chris,

I do not say that this is not a problem in IMatch.
But the IPTC data writer in IMatch is in place since 2001, and it has been tested and hardened with many applications over the years. This includes all applications which are used in a "professional workflow", the backoffice systems used by stock photo agencies and wire servies, archival applications, and...Adobe applications, which are very picky.

All work with the IPTC data written by IMatch, so my assumption is that this is not a general problem. The sample images sent to my by users which fail to work in Picasa work with all other applications I've tested so far.

All I wanted was that somebody by Google tells me _what_ actually the problem is, and I will fix it. I will not risk the stability and portability of the IPTC writer (which includes may quirck modes to make other applications happy) by trying to change "something" to make Picasa happy.

I wrote several emails to Google, and also some other users. So far to no avail.



This is a hint. IPTC data has no "header", really. Depending on the file format used, the IPTC data stream needs to be wrapped in different ways, and then inserted into the image file according to the rules valid for the given file format. Many headers (I assume you tried JPEG files?) contain lead in bytes, length bytes, padding bytes to produce a certain alignment etc. Rewriting IPTC in an application will change this header most likely without changing anything in the IPTC data at all. This may cause the "changes" you see.

When I have some extra time, I will again download and install Picasa, and try to produce this effect. Perhaps I can come up with an idea this time. But it would be easier if a Google programmer just would tell me what their problem is with the otherwise perfect IPTC data...


Your comment about the lipiptcdata relates only to UTF-8 encoding in IPTC. IMatch supports reading and re-writing IPTC data in UTF-8 encoding, so this is not the problem. IMatch does not write UTF-8 data by itself in order to maintain compatibility with all the processing applications out there which cannot handle UTF-8 yet. And probably never will.

If Picasa can only handle UTF-8 encoded IPTC, this will be a problem that I cannot solve for them. UTF-8 was a late addition, added to the "final" IPTC standard. Now this is obsolete by the IPTC Core standard used in XMP - which is UTF-8 only.

Please help me to understand Picasa.

I today downloaded the latest version and tried to reproduce this effect.

I added IPTC data in Picasa (Keywords and Caption, is there other?) and the data showed up in IMatch.

I then changed the IPTC caption in IMatch. Picasa still showed the old caption. I refreshed the folder in Picasa, but Picasa still shows the old caption.
I looked in the actual image file with a hex editor, but the ITPC record in the image file only contains the new IPTC caption. The caption shown by Picasa is nowhere in the image file. Where does it come from? Is there a cache I need to clear or something?

I don't use Picasa, but perhaps this can help.

Apparently it's not just iMatch that has issues with Picasa:
http://groups.google.com/group/PicasaSom...e7e93d0ec1475d1

Exifer and many other programs apparently write IPTC information in such a way that Picasa can 'see', but there's apparently something different about the iMatch (and iPhoto) write it.

I don't understand the differences, but I did try starting with a simple image and adding IPTC information (just the Caption 'Magenta') to separate copies using Exifer, Photoshop Elements and iMatch. They and the original are attached in case they're any help.

Hi,

that did not help. I changed the caption in IMatch from the caption "Boo" written in Picasa to "Test".

The image file contains the caption Test inside the IPTC record as expected, and nowhere in the file is the word "Boo" anymore. I checked with a binary file editor. But even after several folder refreshes and restarts, Picasa still shows the caption "Boo". I wonder where this comes from when it is not in the image file anymore.

I made a trial once of Picasa (v.2.0), but I was quickly turned off of it because of problems like Mario describes. I think I found that once image information is imported into Picasa's database (if that is the right term for it), it stays internal to the database...

For instance, it seemed that it would bring in the IPTC on the initial import of a file into Picasa, but after that, it would never look at the file again for modified IPTC. This is not all that different from when you edit files in Picasa (which was my primary issue). Making edits in Picasa allowed you to have different versions of a file, but you really didn't have different versions of a file. The file outside of Picasa was still just the original file. All the corrections were just written to the database and only really available in Picasa. Of course, there were ways to export the file so the corrections were permanent, but it really wasn't very convenient and didn't make the program very useful... It seems likely that Picasa is still doing something similar, although I haven't looked at it myself in a couple of years.

My whole purpose in evaluating Picasa was to find a program that could deal with Versioning (I was getting tired of waiting for IMatch to implement it), and while Picasa had promise on paper, it failed miserably (in my opinion) in use. As an aside, I stuck with IMatch and have developed a versioning workflow that suits my needs until it does get implemented into IMatch. Really this means that I've learned to expand on my use of scripting and XMP (for dynamic categories) to make things work.

Erik

Mario - Try this: Open your test photo w/ Exifer or other program that Picasa recognizes. Change a different IPTC field than the one you entered but don't change Caption (e.g., Headline - add a space or other character)and save. You should find that Picasa will now recognize the revised caption you entered using iMatch.

There's some difference in file versions that Picasa somehow detects. As you note, if their developers were more forthcoming it would be easy to figure out. Obviously Picasa also maintains its own database somewhere on the computer; the database doesn't get updated unless Picasa recognizes a change in a file.

I'm sorry but I have put this one aside for some later time.
I don't have the time to try to analyze which bug causes Picasa to fail to see the data which is perfectly visible in all other applications I use, including the ones you mention. Unless Google is a bit more helpful, I won't spend time on this. The IPTC record written by IMatch is perfectly valid, and not even Photoshop has a problem with it, or FotoStation, Cumulus or the other applications used in a professional environment. Exifer sees the data, even PolyImage or LeadTools. Only Picasa fails. Their problem, really.

I doubt that many IMatch users would even look at Picasa, and hence I better spend my time on features or extensions which will benefit all users.

I made some additional tests while implementing an enhancement for the IPTC editor. It seems that Picasa shows this strange behavior only with IPTC data encoded using the standard ASCII/ANSI character set, but not with IPTC data encoding using UTF-8.

This would indicate that Picasa either expects only UTF-8 encoded IPTC data, or can only work correctly if this encoding is used or the corresponding flags are set inside the IPTC record. Which would clearly not be OK because most of the IPTC data around does not use UTF-8 encoding at all...