Log in to post in the forums, comment on the blog and submit or rate photos in the photo contests.
New Content Since Last Visit
No New Content Since Last Visit
backup batch Beta canvas categories category color management conversion Convert crop database date develop dng Edit editor email Embed EXIF fixed format import IPTC Keywords mac metadata NEF Nikon print pro Pro 2.5 Pro 3 Process process mode RAW resize Rotate save search slideshow thumbnails TIFF upgrade vista windows 7
Sign up to get special e-mail only offers, photography and software tips from ACDSee.
cheerful
Member
Is there a change log for 2.5? I am hesitating in upgrading. Would like to know the detailed feature list to see if it's worth the effort/risk.
Regarding XMP.
1. Does it work on XP?
2. I have a large collection with IPTC tags. Is there an easy way to migrate?
Thanks!
Tankred
Moderator
Hello cheerful,
I am hesitating in upgrading. Would like to know the detailed feature list to see if it's worth the effort/risk.
Pro 2.5 really is feature drive. So you can relatively easy answer the question if it's worth the effort/risk by evaluating the use of the main new features:
http://store.acdsee.com/store/acd/en_US/Di...ductID.78701700
If you want to have them: upgrade now. If not: don't. <<#EMO_DIR#>/wink.gif" style="vertical-align:middle" emoid=";)" border="0" alt="wink.gif" />
cheerful
Member
So will those fields in ACDSee DB go into XMP automatically? Or do I have any control over whether I want them?
I also use IPTC location fields. I guess I'd have to keep IPTC then.
Marc Sabatella
Moderator
So will those fields in ACDSee DB go into XMP automatically? Or do I have any control over whether I want them?
Unfortunately not. So I too am continuing to use Batch Set Information to write to IPTC.
The new import feature is pretty nice - both the interface and the ability to embed basic metadata right there, and the saved original features seems like it has potential to be very useful.
Tankred
Moderator
The answer
So will those fields in ACDSee DB go into XMP automatically?
Depends on the workflow. You can test it yourself:
Use ACDSee with a bunch of pictures in one directory. Give those pictures the rating 5 or anything else. Now close ACDSee. The program will tell you that metadata has to be embedded. You can also disable this notfication. But in both cases, the database metadata is automatically embedded into the XMP headers of the files.
I'm not sure what Marc Sabatella is referring to. Maybe that already entered database information is not automatically imported and embedded if you start using Pro 2.5!?
cheerful
Member
I certainly like the idea to have meta data embedded in the file itself rather than the ACDSee database. However, I'd rather see one meta data source, not XMP + IPTC. Since XMP does not capture everything, maybe it's better to avoid XMP for the moment. So I'd want to see an option to disable XMP for now.
One more thought: does everything in ACDSee database get embedded in XMP? If so, ACDSee db is simply a cache for XMP. Then that's more desirable. The question is: is there a way to force ACDSee to write existing database to images?
Marc Sabatella
Moderator
I'm not sure what Marc Sabatella is referring to.
Sorry, Tankred is absolutely right. I misread the question, since other aspects of the posts were about IPTC. The embed metadata feature does put your metadata in XMP - "automatically" in the sense of a prompt coming up when you exit unless you turn that off. But it does not go to XMP as IPTC or any other standard visible to other applications. You have no control over what fields ACDSee uses in XMP; it actually uses fields that specifically are *not* used by other applications. So the bottom line is if you want your metadata in IPTC, you need to use Batch Set Information, just as always. But if you just want it somewhere in XMP and don't care where as long as ACDSee can read it back in if/wehn necessary, the embed metadata feature should be fine, and no Batch Set Information should be needed.
Tankred
Moderator
One addition: there are of course tools that can read and export the XMP metadata written by Pro 2.5. Exiftool, for example, does this very well.
cheerful
Member
It sounds pretty disappointing that there is no standard for XMP. I know IPTC is not ideal but at least every application understands it.
Since XMP does not capture everything, maybe it's better to avoid XMP for the moment. So I'd want to see an option to disable XMP for now.
What one needs to be aware of are the ramifications of having the same data items represented in both the IPTC data block AND the XMP data block. I wrote about that yesterday in post 15 of this thread, http://forums.acdsystems.com/index.php?showtopic=7698
if like me you can't read that image (maybe a mod or an admin can tell me why I can't see the images attached to my own posts), then look at page 10 of the spec -- www.iptc.org/std-dev/PhotoMetadata/2008/specification/IPTC-PhotoMetadata-2008_4.pdf -
admins, I get this Sorry, but you do not have permission to use this feature. If you are not logged in, you may do so using the form below if available. same thing if I use a .png - which I normally would 'cos its smaller.
Tankred
Moderator
admins, I get this Sorry, but you do not have permission to use this feature. If you are not logged in, you may do so using the form below if available. same thing if I use a .png - which I normally would 'cos its smaller.
Try it now...
Try it now...
Tankred
Moderator
Well, if you and I can see it, others see it, too. <<#EMO_DIR#>/wink.gif" style="vertical-align:middle" emoid=";)" border="0" alt="wink.gif" />
cheerful
Member
Can someone confirm XMP can be disabled via some option (not hacking)? I would avoid upgrading if it can't.
Thanks!
Sam Dring
Moderator
Before Cheerful makes a decision, I think we have some confusion in this thread!! (Cud well be me)
Marc wrote:
So the bottom line is if you want your metadata in IPTC, you need to use Batch Set Information, just as always. But if you just want it somewhere in XMP....
The confusion for me is that the above sentence could be interpreted to mean your choices are iptc or xmp, whereas, in reality, if you write an iptc entry into a file (directly or using Batch), that iptc data goes into the xmp block. All the apps I use/have used such as LR, Idimager, Downloader Pro and,of course ACD Pro all write iptc fields to the xmp block but portray those entries as iptc and quite rightly so.
It just makes me wonder why Cheerful would want to disable xmp (don't think you can by the way!)
cheerful
Member
The thread above suggested it can:
http://forums.acdsystems.com/index.php?showtopic=7698
My question was:
1. If everything in ACDSee database is in XMP?
1a. If not, I don't want to use it b/c it can easily lead to inconsistent data.
1b. If it does, how do I make it write metadata in existing database to XMP.
1c. I'd only want XMP in the image file itself, not a side file. Is this possible?
Thanks!
Marc Sabatella
Moderator
Let's see if I can reduce some confusion.
First, Sam is right: when you write to ITPC, in at least some cases, that actually goes to XMP. XMP is a special area of a file - or a sidecar file for formats that do not support XMP directly. The XMP area can contain copies of the EXIF and IPTC data as well as stuff that lives *only* in XMP. And of the stuff that lives only in XMP, some of it is at least semi-standardized, but much of it is left open for individual applications to define however they want.
When you write IPTC to a file, ACDSee will write it to the regular IPTC area of the file if it exists and can be written to (eg, most JPEG files). If the format does not support writing to IPTC (like most proprietry RAW formats), then ACDSee write the IPTC data to the XMP area, and other applications can definitely see and use that information as if it were regular IPTC info. If a file has a regular IPTC area *and* and XMP area, ACDSee will write IPTC data to both areas, but it won't normally *create* an XMP area that doesn't already exist if the ITPC area will do.
That's why I said if you want your metadata in IPTC - which is to say, if you want it in a place where other applications know how to find it - then you need to use Batch Set Information. True, for proprietary RAW files or other formats that already contain an XMP area, that IPTC info actually gets written to XMP, but it gets written *as IPTC info*, meaning any modern IPTC-aware application should see it as if it were ordinary IPTC info.
If you don't care about having your metadata in IPTC format (and thus readily available to other programs), you can use Embed Metadata to write you metadata to XMP. It won't be in IPTC format, but in a proprietary ACDSee format. Note however that XMP is just plain text. So even if your other applications don't directly understand the meaning of the info ACDSee writes there, it can certainly see it. It would see there is something called an "ACDSee keyword" and that it's value is "animals, cats, pets". it would just have no idea this field had anything to do with any other type of keywords.
With that background, let me try to answer some of the specific questions:
1. If everything in ACDSee database is in XMP?
The database normally contains the fields listed on the Database pane of the Properties window as well as information taken from EXIF and IPTC. *If* you run the embed metadata operation, then all the fields from the Database pane of the Properties are written to XMP. I think the EXIF and IPTC info that is also present in the ACDSee database is copied to XMP also, at least sometimes, but it may not always be, nor need it be, because that info was already in the file.
1a. If not, I don't want to use it b/c it can easily lead to inconsistent data.
ACDSee normally keeps track of which files have had their metadata modified since the last embed operation. So any time you run the embed operation, it will bring all your files up to date,
1b. If it does, how do I make it write metadata in existing database to XMP.
The info is written when you run Database>Embed Metadata, or on program exit if you have left the option to do that enabled. It first displays a dialog indicating it is figuring out which files need to have their metadata embedded, then it does the embedding. The first you do this, it may take a long time, as basically *everything* needs to be embedded. Once that's done, though, subsequent operations should be much faster - at least in theory.
1c. I'd only want XMP in the image file itself, not a side file. Is this possible?
ACDSee will always write the data to the file itself if it knows how - and it knows how for JPEG, TIFF, DNG, and perhaps some other formats. But there are other formats that ACDSee cannot write directly to the file. These include proprietary RAW formats, but also things like ordinary text files, probably most sound formats, proprietary formats used by documents from other applications, etc. For these formats, ACDSee has no choice but the write sidecars if it is to write anything at all. There is an options to control whether or not it creates sidecars for these or whether it just skips the embed operation for these formats. Note that even if you set the option to *not* create sidecars for those formats, it will still create sidecars for proprietary RAW files. The rationale being, it was creating those sidecars anyhow any time you wrote EXIF or IPTC info or did RAW processing, so adding the embedded db info isn't creating sidecars it wasn't already creating.
I think the EXIF and IPTC info that is also present in the ACDSee database is copied to XMP also, at least sometimes, but it may not always be, nor need it be, because that info was already in the file.
Assume a jpegs existing XMP block contains the IPTC field Urgency with value of 0, don't worry about how it got to be there (in my opinion it would not be AP2.5 that put it ther). You then change the IPTC Urgency value to 3, if you then open that image with EXIFTool the Urgency value in the IPTC block will be 3 and the Urgency value in the XMP block will be 3. Note there's no "Batch Set Information" nor "Embed Database Information into XMP" operation, the data is there instantaneously.
Now did ACDSee write the bits "000011" twice in which case the IPTC Urgency field and the XMP Urgency fields each have there own "000011", or did ACDSee write the bits "000011" once and the IPTC and XMP Urgency data items each reference that same "000011" - I don't know. My current intuition is the latter, which means my remarks elsewhere regarding the dangers of having multiple copies of the same data, whilst remaining true in theory are irrelevant in this instance as there is only one copy of the data that's referenced from two places - that's OK.
ACDSee normally keeps track of which files have had their metadata modified since the last embed operation. So any time you run the embed operation, it will bring all your files up to date.
I think it's only the metadata contained in the Properties Database Tab that is being monitored, I have the impression that no IPTC or EXIF is stored in the database, it's only in the images and they get updated as changes are made.
The "database" probably has indices of IPTC and EXIF values for the purposes of search, but they are not the "definitive" values for an image. Thus if 50 images have the same caption then that caption value will have one entry in the caption index with 50 file references, but the caption itself will be contained within and I suggest sourced from (ie what you see is what's in the image) each of the 50 images.
The first time you do this, it may take a long time, as basically *everything* needs to be embedded. Once that's done, though, subsequent operations should be much faster - at least in theory
I think this is only true if you have values in the Database properties
For these formats, ACDSee has no choice but the write sidecars if it is to write anything at all. There is an options to control whether or not it creates sidecars for these or whether it just skips the embed operation for these formats.
Mark, where is the option for specifying which file types get sidecars and which ones don't. I can't see it, but that's not to say it's not there. I often cant see things that are under my nose.
TIP : If your keyboard has a Context Menu (CM) key wedged between the right alt and right ctrl; then ctrl/CM will bring up the shell context menu. For keyboard jockeys its a lot easier than ctrl/right mouse button, if you use your thumb on the CM key, then you'll find the arrow keys at your finger tips, ready & waiting to navigate the context menu.
1a. If not, I don't want to use it b/c it can easily lead to inconsistent data.
if your concerns regarding inconsistent data were influenced by my post regarding idImager writing IPTC data to the XMP block and the potential it has for creating inconsistencies, then you need to know that I have changed my position somewhat, although I'm less certain now about what is actually happening
With ACDSee at least there appears to be little chance of getting inconsistent data. I suspect this results from the manner in which the IPTC and XMP blocks are actually stored rather than ACD doing anything specific. So whilst we may see multiple representations of a data item (one in the IPTC block and another in the XML block) there is in fact only one stored value which is referenced from within each block, this should hold for all EXIF and IPTC data items. If that is true then the potential for inconsistent data would be eliminated.
See post 18 in this thread
There must be somewhere where all this is documented in a "for dummies" format, the IPTC 2008 spec is hard going and the Adobe XMP spec is no better.
cheerful
Member
I think there are more questions than answers. I have worked with a lot of meta data in other fields. I have to say it's extremely important for each piece of data appears at only ONE place. When they are duplicated at different places, it's impossible to keep all of them in sync in the long run. Even ACDSee is bulltet-proof, there are always more than one tool you use to access these data. In the real world, it's always too late to find out and it can (and has) cost a lot of money.
When I said "everything in ACDSee database", I meant for those fields exclusively in ACDSee database such as category and rating. The database also acts as a cache (rebuild metadata will force it reload EXIF/IPTC from the images). This is not considered a duplication since the image file wins everytime. However, when you say these get written back to the image, it's really SCARY! I would want to hear ACDSee developer to clarify this.
Marc, could you ask the developers? We want to get a clear picture about what get written where.
Thanks!
Subscribe to this topic via RSS
You must log in to post.
