Paul said:
If someone can enlighten me I Would be grateful.
Paul, allow me to have a go at doing that. I ran the "Database->Embed Database Information in Files" process against my test dataset which has approx 20K images.
From what I can see this new embed database feature only writes to the custom tab (and not the IPTC file proper)
I assumed I would see an XMP section somewhere, but in Custom I just have the same old Database, File, EXIF and IPTC sections, nary a sign of an XMP section -- what see you?
But If I look at the images with EXIFTool then I can see XMP data that <u>can only</u> have been written by ACDSee 2.5 because it contains a representation of my category hierarchies.
Whilst the EXIFTool software shows the "Categories" data in its GUI browser I can't coerce it into allowing me to export that XMP field, nor can I edit it the data, which is a pity because that means there's no easy way for me to get to grips with the manner in which ACDSee Pro 2.5 writes the hierarchies, all I can see is a truncated string in the EXIFTool GUI.
so quite what the use of this feature is I am at a loss to understand as it can only be read by ACDsee!
The data is there to "reconstruct" the database, including category hierarchies. This is the principal "stated purpose" of the XMP data, from what I can see that ought to be possible, but I have yet to import an image containing ACDSee pro 2.5 specific XMP data.
It is probably true to say that the XMP data that ACDSee Pro 2.5 writes can only "processed" by ACDSee pro 2.5; but it can be "read", albeit at a primitive level, by other tools. Maybe as I've suggested elsewhere this might include external search tools, providing they support IFilters. Google GDS used to support IFilter's but I'm not sure that that's still so. The MS search tools support IFilters, as does AImAtFile and another one whose name escapes me.
I suggest the lack of processability of ACDSee's XMP data by other software is entirely mutual. There appear to be no de jure or even de facto standards for how data such as hierarchical categories (or keywords) ought be represented. For IPTC and EXIF fields I think (hope) that the convention is use the same "labels" as are used in EXIF and IPTC data blocks. However I question the efficacy of writing EXIF and IPTC data to the XMP block, unless one is prepared to dispense with the IPTC and EXIF data blocks -- I doubt that the industry is ready to do that - more on this below.
But - why cant I see the ACDSee Pro 2.5 generated XMP data in its native from within ACDSee Pro 2.5. I should not have to resort to 3rd party tools to read what ACDPro just wrote!.
It would seem that what ACDSee Pro 2.5 writes to the XMP data block gets appended to what's already there, I think the same is true of Photoshop. given that there are no standards this is pretty much as one would expect.
On the other hand idManager writes all the EXIF data, all the IPTC data and its own database information to the XMP block; it also writes IPTC and EXIF data to their respective blocks, i.e we have data reduncancy, which sounds good - but it ain't necessarily so. IMO, idImager has created itself and its users a problem. If the value of Photographer in the IPTC block and the XMP block are not the same -- because the IPTC value was changed with something other than idImager (e.g. Photoshop, Photomechanic, EXIFTool, ACDSee Pro ...) -- then which value is correct. I don't think individual fields are time stamped, even if they were, then is what I see evidence of plagiarism, or merely an error correction?
I doubt that this has bought you into a state of true enlightment, in fact its quite likely that you are even more confused. But always remember, wisdom is confusions child - who said that - me.
Posted On September 13, 2008 - 03:21 AM (1 year ago) (
Permalink to this post)
New Content Since Last Visit
No New Content Since Last Visit
