[Originally posted by louiscar on 2008-11-15 17:52:14-08]I've been so successful with using Exiftool that I'm thinking of some other possibilties. Your fault for giving us such a powerful utility. :-)
As Lightroom and Acdsee both save Raw settings to sidecar XMP files and it now seems withing the realms of possiblity to store both sets of data in the Raw file
I'm reworking my batchfiles to copy required fields from these sidecar files to the raw files directly.
Originally your previous suggestion works well but leads to problems particularly when using Acdsee which doesn't retain any Lightroom fields.
Interestingly LR does retain Acdsee settings by copying -xmp:acdsee to it's database.
So if I were to use:
exiftool "-xmp<=%%d/%%f.xmp" -ext nef .
to copy the sidecar files I get into a problem if I do any keywording in Acdsee after storing LR Raw adjustments,
simply because it's replacing ALL existing xmp data
So I came up with the following to isolate tags that I want to copy from any sidecar file:
exiftool -tagsFromFile dsc_2774.xmp -@ Copyfrom.args dsc_2774.nef
Copyfrom.args currently has just a few test lines in it:
# Raw settings
-XMP-crs:all > xmp-crs:all
-xmp-acdsee:all > xmp-acdsee:all
#xmp tags
-xmp-dc:subject > xmp-dc:subject
-xmp-dc:rights > xmp-dc:rights
The problem I have is that I cannot get exiftools to copy the acdsee tag (line 3), I get an error
'no writeable tags found in dsc_2774.xmp'. I've tried several alternatives but with the same result.
This is confusing as the xmp-crs: field copies without problem and so do the other xmp-dc tags.
Acdsee's tag starts like this:
<acdsee:rpp>
<rdf:Alt>
<rdf:li xml:lang="x-default"><?xml version="1.0"?><command><name>ExposureLevels</name><parameters><int id="Warning">0</int>< .....................
Do you have any idea what might be the problem?
[Originally posted by louiscar on 2008-11-15 17:58:31-08]Sorry for my code block error but just for clarity the following should have read:
Copyfrom.args currently has just a few test lines in it:
# Raw settings
-XMP-crs:all > xmp-crs:all
-xmp-acdsee:all > xmp-acdsee:all
#xmp tags
-xmp-dc:subject > xmp-dc:subject
-xmp-dc:rights > xmp-dc:rights
[Originally posted by exiftool on 2008-11-17 11:40:06-08]
If you could post or email me a sample of the acdsee XMP containing
all of the tags that it adds I will add write support for these to
the next release of exiftool. My email is philharvey66 at gmail.com.
Thanks.
- Phil
[Originally posted by exiftool on 2008-11-17 11:46:08-08]
I should point out that exiftool doesn't currently write
all crs tags, so copying all crs tags won't
necessarily do exactly what you want. The crs tag
hierarcy is rather complex, and it may be a while
before I add the ability to reproduce this faithfully
when copying as individual tags.
- Phil
[Originally posted by louiscar on 2008-11-17 13:51:58-08]
Ah! That's interesting.
So far I've checked the settings in LR and they all seem to return after putting the crs back.
Are there any significant tags one should know about? In my tests I've usually adjusted Whitebalance, contrast or set to greyscale so that I have some obvious effects to view.
I didn't think to check the whole range of settings.
It's doubtful I'd ever want to do individual tags within crs, most people I'd imagine would just want to be able to keep their current LR adjustments intact.
[Originally posted by exiftool on 2008-11-17 13:58:11-08]See the
XMP-crs
tag name documentation for a list of tags which are/aren't writable.
Basically it is the gradient- and paint-based correction tags that
exiftool can not write.
- Phil
[Originally posted by louiscar on 2008-11-17 14:40:02-08]
Actually, that's not too bad. At least if one avoids these adjustments or we can go back to keeping sidcar files if it's a problem.
I've sent you the Acdsee data btw.
[Originally posted by louiscar on 2008-11-17 15:13:12-08]
See the XMP-crs tag name documentation for a list of tags which are/aren't writable. Basically it is the gradient- and paint-based correction tags that exiftool can not write.
I might have misunderstood but I just tried it one way and the gradient information was retained. This was just grabbing the xmp sidecar as whole and writing it into the image.
exiftool "-xmp<=%%d/%%f.xmp" -ext nef .
Of course that was from the LR generated xmp file. So I guess the problem is when Exiftools extracts xmp:crs then those fields will not be written out.
[Originally posted by exiftool on 2008-11-17 15:20:45-08]
Copying the entire XMP as a block is OK. The issue only occurs
when copying XMP tags individually.
- Phil
[Originally posted by louiscar on 2008-11-17 15:31:26-08]
Ok, so I could still write OUT the whole XMP block with Exiftools then read it all back in without losing any data.
[Originally posted by exiftool on 2008-11-17 16:10:32-08]
Yes.
Thanks for the sample ACDSee XMP file. The next release of
exiftool will have the ability to write XMP-acdsee:rpp.
You may want to submit a bug report to ACDSee: They are
incorrectly using a tag ID of "exif:FocalLengthIn35mmFormat"
instead of "exif:FocalLengthIn35mmFilm" (but their track record
is much better than Microsoft, who made two such naming errors
in addition to four case errors in XMP tag ID's).
Aside: Software vendors
should really ask me to validate a sample of their meta information
(not only XMP, but EXIF as well) before they release it to the public.
I will do this for free, and it will save a lot of hassle trying to maintain
backward compatibility with incorrectly formatted meta information.
I can spot some problems immediately that may otherwise remain for
months or years before they are fixed, and by then it is too late.
- Phil
[Originally posted by louiscar on 2008-11-17 16:32:07-08]
Thank you PHil,
I'll submit the bug report as you suggest, although I'm not sure if they'll be bothered to fix it any time in the near future.
I'll suggest that they contact you for validation purposes, I'm sure some vendors might warm to the idea of someone who knows what they're talking about, others can be quite arrogant though. Still it's always worth a try I say.
Whilst on the subject, thinking about what you've been saying about copying out xmp-crs, I'm wondering if it's worth the effort of reworking the idea of keeping keyword edits AND raw data using only the XMP block copying when writing to the image.
I presume there's nothing wrong with the idea of (for example), creating a sidecar from LR then one from Acdsee and using Exiftools to copy the keywords from the latter to the former. Then block XMP copy the result back into the image?
One other question: What would be the advantages of MIE files as opposed to xmp sidecar files. Is there a significant reason to use one against the other?
[Originally posted by exiftool on 2008-11-17 16:52:18-08]
Adding the ACDSee keywords sounds like the way to go. If
you can get things playing together nicely you may be able
to avoid using two separate sidecar files, but this is somthing
you'll have to work out.
MIE files have the advantage of being able to store binary information,
and to store information as compressed text (with the -z
option). So they are more space efficient and aren't limited in they
type of information they may store. The disadvantage is that only
exiftool understands MIE files. If you are only working with XMP
information, then XMP sidecar files are the way to go. But for mixed
information types then MIE is the clear choice.
- Phil
[Originally posted by louiscar on 2008-11-17 17:28:51-08]
Ok thanks Phil,
I might just use the MIE files for Acdsee and and XMP for LR information to distinguish between them. That way I can keep filenames the same , it'll avoid renaming sidecar files and making mistakes when one goes into auto mode.
I've submitted the Acdsee bug report btw. I'll let you know if there's any positive response.
It'd be interesting to know how many versions of Acdsee that Exif misnaming has carried across. They might have been doing it for years. :-)
[Originally posted by exiftool on 2008-11-17 17:38:51-08]
Sorry, I realize I wasn't very clear about which tag ID was wrong.
I was talking about the XMP tag (in the "exif" namespace),
not the EXIF tag (which has a numerical ID).
I suspect that this error hasn't been around for too long because
I would guess that ACDSee has added the XMP support
fairly recently.
- Phil
[Originally posted by louiscar on 2008-11-17 20:44:37-08]
I hadn't realised that and didn't look till now. I see what you mean, in fact there are two fields named: FocalLengthIn35mmFormat. At least they have the right data albeit one shows 75mm and the other shows just 75.
Presumably when apps use this information they access it by ID? If so effectively, that would lower the significance down to a typo. Would focal length for '35mm format' ever differ from '35mm film' ?
[Originally posted by exiftool on 2008-11-17 21:47:15-08]
I'll start again from the beginning, in a bit more detail this time:
There is an XMP tag in the exif namespace that is called
FocalLengthIn35mmFilm according to the XMP specification.
ACDSee writes this incorrectly as FocalLengthIn35mmFormat.
By my terminology, these are the tag ID's (which I define as the tag
identification that is actually written to file).
ExifTool writes this tag using the correct ID ("FocalLengthIn35mmFilm"),
but the name it uses for this tag is FocalLengthIn35mmFormat. ExifTool
sometimes uses names that are different from the tag ID's, but these
tag names should not be confused with the ID's that are written to
the file.
So the answer is that the typo is significant, because it is the ID that
is important.
- Phil
[Originally posted by louiscar on 2008-11-18 07:41:21-08]
Ok, I thought the 'ID' was a numerical value which could be used to extract the tag by it's position in the list.