metadata not saved in xmp, but in bridge cache

[_Omar_Shahine_]

I have a script that sets the metadata for the following fields:

GPSLatitude
GPSLongitude
GPSAltitudeRef
GPSAltitude

and the data shows as having been applied in the Bridge Application, but the data is not in the sidecar XMP file, nor DNG files. If I move the file out of bridge the metadata goes away.

Is there something I'm doing wrong when setting these values?

[01af]

I am having the same problem (albeit with different metadata fields). Altered metadata does get permanently saved in JPEG and TIFF files but not in raw image files that store their metadata in XMP sidecar files (didn't try DNG files yet); instead the new data will float around in Bridge's cache only.

You can force Bridge to write the altered metadata from the cache down into the XMP sidecar file by opening the File Info dialog, navigating to the "Extended" panel, and then pushing the "Save ..." button. Unfortunately you can save only one file's metadata at a time this way; it's virtually impossible to do it for hundreds or thousands of files at once 😞

-- Olaf

[dfranzen_camera_raw]

Olaf,

For which different metadata fields are you seeing this problem?

Thanks,
David Franzen
Adobe Bridge Quality Engineer
Adobe Systems, Inc.

[01af]

I am particularly having problems with aux:Lens and aux:SerialNumber (namespace xmlns:aux="http://ns.adobe.com/exif/1.0/aux/") and tiff:Model (namespace xmlns:tiff="http://ns.adobe.com/tiff/1.0/"). I made these fields accessible (editable) by customizing the Camera Data 1 tab in Bridge's File Info dialog. It works for JPEG files but not for raw files.

I assume there are more fields causing problems but those are the two or three I'd really like to use. Furthermore I also want to change time-zone data through a script (as Bridge always gets it wrong; it insists to confuse the computer's time zone with the images' time zones) but I can't :-(

I'm not having any problems with metadata fields that originally are accessible through the File Info dialog, for example all the IPTC Core fields. Also Camera Raw settings get stored just fine (for raw files that got touched by ACR).

By the way, the problem occurs in both Bridge 1.0.4 and Bridge CS3 Beta 2 (on Windows XP SP2).

-- Olaf

[dfranzen_camera_raw]

Olaf,

When updating the metadata in a file, Bridge writes back some of the EXIF properties to the native EXIF but not all. All the propertes changed are updated in the file's XMP.

This is the limitation you are hitting with Make and Model and other properties. Thanks for letting us know that, for you, these would be important fields to write back in the future. In general, only the fields editable in the Bridge UI are written back to the native EXIF metadata.

In Bridge CS3 the DateTimeDigitized and DateTimeOriginal, have been added to the set of EXIF properties that are written back to the native EXIF tags.

The native EXIF DateTimeOriginal and DateTimeDigitized EXIF tags do not, however, include any time zone information. Since XMP's date-time format does include a UTC offset (not technically the same thing as a "time zone"), the computer's local UTC offset is used in the XMP at the time a value read from the native EXIF is mapped to the EXIF property in XMP.

When using these XMP properties, however, we recommend that this UTC offset in the XMP value is simply ignored. It has no real meaning for the EXIF dates since you cannot tell from the EXIF tags what 'time zone' is associated with these these values. Note that Bridge's user Interface shows only the date and time and no UTC offset for the EXIF date-time values. Also Brides does not shift the time displayed when the machine's local UTC offset does not match the (meaningless) UTC offset in the XMP value.

--David Franzen
Adobe Bridge Quality Engineer
Adobe Systems, Inc.

[_Omar_Shahine_]

David, what about the GPS data?

[dfranzen_camera_raw]

Omar,

I do not believe the EXIF GPS tags are written back to the native metadata in Bridge CS3; they are updated in the XMP.

-David

[01af]

David Franzen wrote:
> Bridge writes back some of the EXIF properties
> to the native EXIF but not all. All the properties
> changed are updated in the file's XMP.

No, they're not. Actually they (or at least some of them) are updated in Bridge's cache only but not in the XMP file on disk. Meanwhile I have also tried DNG files---they don't get updated properly, too, even though they don't have sidecar files. By the way, the updating does work fine for all fields if the image file is a JPEG or a TIFF file. Updating is incomplete if the image file is a raw or a DNG file.

It must be considered a serious bug when Bridge does not properly update any altered EXIF, IPTC, or XMP metadata properties! After all, the File Info dialog is customizable. But what's the point in customizing it when only those properties will properly get updated that were editable in the original (i. e. non-customized) dialog?

And I really don't like those "meaningless" UTC offsets mindlessly added to the date-and-time tags! Please make them meaningful (and editable), or remove them altogether! Wrong offsets are much worse than no offsets at all.

-- Olaf

[dfranzen_camera_raw]

Olaf,

Please try turning off the "Prefer Adobe Camera Raw for JPEG and TIFF" preference and trying again. The following sample should write some of the EXIF properties to XMP.

#target bridge
if( ! app.preferences.ACRForJpegTiff ) {
	// Make a JPEG file for testing
	var bitmap = new BitmapData(100,100);
	var testJpg = new File( new File($.fileName).parent.fsName + "/test_xmpfiles.jpg" );

	bitmap.exportTo( testJpg );

	// Create a Thumbnail
	var testThumb = new Thumbnail( testJpg );
	var md = testThumb.synchronousMetadata;
	// Use synchronousMode to make multiple changes to the Metadata object
	app.synchronousMode = true;

	md.namespace = "http://ns.adobe.com/exif/1.0/aux/";
	md.SerialNumber = "1234556"
	md.Lens = "50 mm f/1.4";

	md.namespace = "http://ns.adobe.com/tiff/1.0/";
	md.Make = "SnazzyBrand";
	md.Model = "WizzBang 3000";

	$.writeln( testJpg.name );
} else {
	$.writeln("ACRForJpgTiff is on");
}

-David

[01af]

David Franzen wrote:
> Please try turning off the "Prefer Adobe Camera Raw
> for JPEG and TIFF" preference and trying again.

I can't, because I don't have Bridge CS3. I used to have Bridge CS3 Beta 2 and now I am back to Bridge 1.0.4. Anyway, with Bridge CS3 Beta 2 I never had the "Prefer Adobe Camera Raw for JPEG and TIFF" preference on; it was always off. Still I had the same problems in Bridge 1.0.4 as well as in Bridge CS3 Beta 2. I don't know if the problems still persist in the current release version of Bridge CS3 ... but until proven otherwise I have no reason to assume anything has changed for the better. That's why I have put off updating to CS3 yet. I'll wait until the first fixes are out.

md.namespace = "http://ns.adobe.com/exif/1.0/aux/";
md.SerialNumber = "1234556";
md.Lens = "50 mm f/1.4";

This is exactly what I am doing in one of my scripts---but it will work well only for JPEG and TIFF files, not for raw or DNG files.

-- Olaf

UPDATE: In the meantime, I have installed the 30-day trial version of Photoshop CS3, together with ACR 4.1 and Bridge 2.1. In Bridge CS3 2.1, adding/altering non-standard EXIF fields (like e. g. aux:Lens or aux:SerialNumber) now also works for DNG files. This definitely is an improvement!

However it still does not work for proprietary raw files that store their metadata in sidecar files---which is weird because when trying to update a raw file's metadata, the hard disk drive will chirp for an instant and the sidecar file's Date Modified label will jump to the current minute but its contents will remain unaltered still.

-- Olaf

[dfranzen_camera_raw]

Olaf,

Bridge uses the Adobe Camera Raw plugin for doing all metadata reading and writing to DNG and other RAW files. You may want to post your questions on the ACR forum as well.

-David

[01af]

UPDATE of the update: I was mistaken. Sorry! Adding/altering non-standard EXIF fields (like e. g. aux:Lens or aux:SerialNumber) in Bridge 2.1 does *not* work for DNG files. The data will end up floating around in Bridge's cache only; it won't ever make it into the image file on disk.

-- Olaf

[dfranzen_camera_raw]

Olaf,

Can you explain why you need to be able to modify this metadata through scripting? Does your camera not record it in the orignal EXIF? This information will help us understand how this issue may affect other customers.

Thanks,
David

[01af]

David Franzen wrote:
> Can you explain why you need to be able to modify this metadata
> through scripting? Does your camera not record it in the original
> EXIF?

The camera does indeed not record the serial number which is a pity as I have two bodies of the same make and model (Konica-Minolta Dynax 7D). So I add the serial numbers to the in-camera JPEGs during file ingestion and then propagate the data to the raw files using a script (I shoot RAW+JPEG; without the script I'd have to do the work twice). The camera does record a code for the lens but that's just an obscure ID number in the vendor-specific Maker Notes. So I add the lens description to the aux:Lens field manually (I'd love to write a script that would translate the lens IDs into the lens names automatically but unfortunately I cannot read Maker Notes fields through Bridge's scripting interface).

Anyway it does not make a difference whether I add non-standard EXIF fields like aux:Lens or aux:SerialNumber manually (i. e. via a customized File Info dialog) or via script---in any case raw files and DNG files won't accept the added/altered metadata.

However, standard EXIF fields (which in this context are those that are editable through the original File Info dialog) will update just fine with all kinds of image files.

-- Olaf

[_Erwin_van_der_Horst_]

Hi Omar,

I also was trying to insert GPS data in the XMP files, and came on to the same problem you encountered. I also don't understand why specific EXIF fields cannot be updated. I know they shouldn't be updated (in an user interface), but sometimes there are some exception, like we can find in this thread here.

However, I finally did find a solution, but it need some more testing to say it really works under all circumstances. Perhaps it can also be of any help on ohter EXIF fields.

Here is my solution:

1) Create a new XMPMeta object and fill in your GPS fields
2) Get the current XMP metadata from the selected thumbnail
3) Use XMPUtils.appendProperties to combine the two meta data objects
4) Write the appended metadata to the XMP file
5) Write the appended metadata back to the current thumbnail

I've used the following script snippit:

var xmp = new XMPMeta();

xmp.setProperty(XMPConst.NS_EXIF,'GPSLongitude',longitude);
xmp.setProperty(XMPConst.NS_EXIF,'GPSLatitude',latitude);
xmp.setProperty(XMPConst.NS_EXIF,'GPSAltitude',altitude);
xmp.setProperty(XMPConst.NS_EXIF,'GPSMapDatum','WGS-84');

var md = thumb.synchronousMetadata;
var xmp2 = new XMPMeta(md.serialize());

XMPUtils.appendProperties(xmp,xmp2,XMPConst.APPEND_ALL_PROPERTIES | XMPConst.APPEND_REPLACE_OLD_VALUES | XMPConst.APPEND_DELETE_EMPTY_VALUES);

var xmpFile2 = new XMPFile(thumb.spec.fsName,XMPConst.FILE_UNKNOWN, XMPConst.OPEN_FOR_UPDATE);

if (xmpFile2.canPutXMP(xmp2))
xmpFile2.putXMP(xmp2);
xmpFile2.closeFile();

var xml = xmp2.serialize(XMPConst.SERIALIZE_OMIT_PACKET_WRAPPER | XMPConst.SERIALIZE_USE_COMPACT_FORMAT);

thumb.metadata = new Metadata(xml);

I have not tested this with JPG and TIFF files. I have tested a bit with existing and non existing XMP files.

Any suggestions are very welcome!

Erwin

[_CRakoczy_]

Perhaps some of the trouble with editing EXIF data is due to the complexities of the field format - the EXIF offset is different and has to be calculated each time any field changes length or is added or deleted. Changing this offset may prevent compatibility of the file with the original source (i.e. camera).

I am having trouble getting Bridge CS3 to recognize the updated EXIF fields I've editing with another utility.

I shot an event with two cameras, one set to the wrong time (forgot to adjust for DST). I want the files to sort into their correct order based on Date/Time Created, regardless of filename. I batched processed all the files that were an hour late to reflect the correct hour nit heir EXIF. Windows Explorer recognizes the change and lets me sort them correctly. Bridge does NOT, and still shows the original WRONG time from the camera. Re-running the batch utility shows the EXIFs were changed.

What is Bridge reading to determine the Date/Time? Why won't it re-read the edited EXIF on a refresh or a purge of the folder's cache? Will future versions of bridge have [better] editing, and batch editing, of more EXIF/XMP fields to correct for common mistakes such as this or facilitate better organization of our photos?

Chris Rakoczy
Rakoczy Photography

Rakoczy Photography | Hartford Event Photographer

[_xbytor_]

I know I'm late to the thread, but...

I have to recommend exiftool (ExifTool by Phil Harvey) if
you have to do things with metadata (exif, iptc, xmp, etc...) that just aren't
possible with Bridge CS3 or the XMPScript lib. It handles just about everything.
The only problem is that it is an external app (actually, a bound perl script)
so you end up having to do a File.execute() somewhere along the way which can
result in less-than-elegant code. But it will work.

-X
--
for photoshop scripting solutions of all sorts
contact: xbytor@gmail.com

[_Erwin_van_der_Horst_]

Yes, I am aware of this tool and use it quite frequently (great software), but a disadvantage of this that you have to rebuild the Bridge cache, to see the changed fields within Bridge.

For GPS specific EXIF fields I prefer the more user friendly RoboGEO, with that same disadvantage as exiftool.

Still I think it would be nice to have a feature in Bridge or the scripting, to update (some) exif fields, particulary GPS, creation time and copyright fields.

[dfranzen_camera_raw]

Chris,

RE your post from 12:18pm Dec 18, 07 PST, without knowing what file format you are using or exactly what metadata properties you are changing, to what values, and how, it's impossible to tell you why what you are doing is not working.

-David Franzen
Bridge Quality Engineer
Adobe Systems, Inc.

[_CRakoczy_]

David,

Oops, I'm usually better about including pertinent info. Here it is

I'm working with JPG files generated in-camera, processed and sorted in Bridge CS3

I'm trying to correct a wrong time stamp from a camera I forgot to update after DST, so I'm editing the EXIF Date & Time, Date and Time Original and Date & Time Digitized, even the File D/T Created, File D/T Modified and File D/T Accessed attributes.

I'm using a program called Sophisticated Renamer (SR) to batch edit EXIF and file attributes. Changes I make there DO show up in Windows Explorer, allowingm e to sort by date.

No matter what I do however, Bridge reads the original D/T somewhere. When I then further process the files (open in ACR to crop and adjust) all their dates get reset back to the incorrect original D/T!

Image Processor in Photoshop doesn't seem to change the dates, keeping the edits I've made in SR. Perhaps it's a problem with both Bridge and ACR as Bridge reads the wrong date and ACR modifies the attributes to match? I'm not really sure what's going on, aside from I have to batch edit my files over and over again as I find each step I make changes them back.

Chris Rakoczy

[Varun Varshney]

Hi All,

We have released a new version of Adobe Bridge (CC 2019) on 15th October 2018. The new version build number is 9.0.0.204. This version is available to install via Adobe Creative Cloud application.

This Bridge update contains support for editing capture time of images (Edit the image capture time).

Please check following link to know about all new features in Adobe Bridge CC 2019 - What's new in Bridge

You may need to update the Creative Cloud application and restart your computer to see the updated installer.

Thanks,

Varun Varshney

[naisanza]

Bridge 11.1.1.185

Still does not read XMP sidecar files correctly, or updates keywords and metadata correctly. 

[Lumigraphics]

Please post your SPECIFIC problem as this post was originally about Bridge 1.0