EXIF data stripped on export??

Why on earth would FW strip a photo's exif data when exporting? Web graphics are sometimes contractually required to retain metadata. This opens users up to liability if they don't realize that a photographer's credit is removed during compression.
Is there any way to have this reversed??

I'm aware of the fact that image copying is widespread. This is why exif data is often a requirement to inclusion in web-displayed images; it reduces liability of web publishers, because we've done all we can to prevent copyright attribution from being removed from the image. Are you aware that many photographers' contracts stipulate harsh penalties for publishers who remove metadata from provided files?
Photoshop has 2 problems. The first is that it seems impossible to automate a batch to export a folder of images with "save for web" settings. All my research suggests that it's impossible without digging into actual scripting, rather than relying on actions.
The second problem is that the fireworks "save for web" option is roughly 40% more efficient than the photoshop method, for comparable compression artifacts. I have no idea why photoshop wouldn't use the more efficient fireworks algorithm, but it simply doesn't.
In the past I've used imageready, which provided slightly better compression ratios than photoshop, retained all exif data, and allowed the creation of droplets. With the nonsensical removal of imageready from photoshop, and its replacement with the comparatively crippled fireworks (the compression efficiency is nice, no droplets is tolerable, but exif stripping is unforgivable in this day and age), I'm left searching for a product that will serve my needs.

Similar Messages

Corrupted EXIF data in photos exported from Lightroom CC

After upgrading to Lightroom CC EXIF can't be read by some apps. "Re-saving" a file in Photoshop fixes the problem. I'm using Mac OSX 10.9.5. Are there any plans to update and fix the EXIF data generated when exported from Lightroom CC?
Also, this command fixes the issue with Create Date part of EXIF.
#!/bin/sh
exiftool -AllDates="$(exiftool ${1} | grep 'Create Date' | awk '{print $(NF-1), $NF }')" -overwrite_original ${1}
The reason I'm asking is because we run a site where "Create Date" read from JPG's EXIF is crucial and it's a matter of letting users upload the pic or deny uploading.
So again, any plans on the fix?
Regards,
Pawel Kadysz

I confirmed that the Exiftool command line:
exiftool -m -all= -tagsfromfile @ -all:all -unsafe file.jpg
removes the ICC Profile, which could account for significant color differences, considering that the profile is Adobe RGB. I think this may be a bug in Exiftool, so I filed a bug report. (But it might be that Exiftool just can't handle the non-standard layout of LR's JPEGs.) The author is typically very responsive.
I tried some alternate Exiftool command lines that touch as little metadata as possible, and this one seems to address both of LR 6's JPEG problems:
exiftool -m '-exif:datetimeoriginal<exif:datetimeoriginal' -xmp-crs:all= file.jpg
The -m option ignores minor errors and issues, in particular, when there are more than 1000 entries in the XMP metadata.
The '-exif:datetimeoriginal<exif:datetimeoriginal' option sets the EXIF Date Time Original Field with its current value; this tricks Exiftool into rewriting just the EXIF metadata without touching the other metadata segments (e.g. the ICC profile), addressing the first JPEG problem. (You could use any EXIF field that's present -- I picked DateTimeOriginal since every camera adds that.)
The -xmp-crs:all= option option deletes all of LR's develop settings from the XMP metadata, addressing the second JPEG problem.That metadata is not ready by any programs other than LR, as far as I know.
I've tested this new command line on a couple of pics, including the example you provided above, and it appears to work correctly. But given that we're dealing with buggy output from LR that doesn't conform to the de facto and de jure standards, it's hard to have high confidence without testing on dozens if not hundreds of pics.

Photoshop not seeing lens model in exif data from A3 export

Hi, I am trying to use the lens correction features in CS5 but the lens type can't be read in the exif data of an image I've exported from A3. It sees the focal length and body type. The lens type is listed in the Metadata Inspector in A3. I took the image into iPhoto and checked "extended photo info" and the lens type isn't there either. This happens with at least 2 lenses. One prime and one zoom. Any ideas?

Hi again
Having played with metadata a bit more, it is possible to include EXIF data for the lens size etc.. eg...EF300mm f2.8L IS USM But it doesn't append the manufacturer's name, eg I use Canon, yet 'Canon' is not appended to the Lens data like it is to the camera name..
In the library Inspector click > Metadata > where it says 'General' click the down arrow, then click > Edit > from the window that appears click > EXIF > from the drop down list click > Lens (scroll down a bit)
The lens you used will now be appended to your data.
I have not tried exporting this to Photoshop so maybe you could post back if its possible to export this data to PS or not.
Maybe someone has information on this and can chip in here with advice....
Hope this is helpful....... Gerry....
PS to all reading this, I also noticed while playing around with this ( I have not delved into metadata too much since Ap2) that all my personal details like mobile number, address, email etc are all appended by default, I imagine my address book info has been used here.
A useful feature indeed while selling photo's, or if you intend it to be there..... but not so good if you are not aware it's there in the first place.....!
Just a shared thought to whom it may concern....... Gerry.
Message was edited by: windhoveruk

EXIF data filtered when exporting to Flickr

I've noticed that some EXIF data seems to be filtered out when exporting photos to Flickr via Aperture's built-in Flick exporter.
For example, if I export same photo using Flickr's upload page, then using Aperture's built-in Flickr exporter, then re-download original back to my computer, the fields like "lens size" are missing from the copy exported by Aperture.
There's few other fields that are silently filtered out by Aperture. Looking at the differences between two copies of the same photo re-downloaded back from Flickr, examples include fields such as digital zoom, subject distance, focus mode, macro mode, firmware version, serial number, owner name (and the list goes on)...
While one could argue that some fields contain personal information, there's my real name on my Flickr account, so having serial number or owner name in EXIF data removed is kind of pointless for my use case. Also, there's tons of photos I exported in the past to various photo sharing sites containing these headers anyhow.
I'd really like to preserve some interesting and useful (technical) fields such as lens size or subject distance. Is there a way to tell Aperture "I don't care, the world already knows this stuff, don't filter EXIF info when exporting"?

Hi Raja,
Not sure, what version are you in, but must not be in latest.
You have to write a e-text to get csv/txt of the desired format.
By default, if you are not in latest version, you will see some data when you select csv without E-text template

Batch Change "Date Modified" to match Exif Data After iPhoto Export

Among several other posts about similar situations, I have found none that directly and simply resolve this issue.
My wife imported a bunch of photos into iPhoto directly, but I wanted them in a folder on the hard drive.
I pulled them out of iPhoto into a folder, then deleted the ones in iPhoto so that I could sort them and reimport.
I then realized that the photos all now showed the date they were imported into iPhoto as their created/modified dates, which makes it impossible to easily sort them by the date of the pictures.
I checked the Exif data, and it has preserved the correct creation date event though checking "info" on the pictures shows create date the same as modified the same as iPhoto import.
Is there an easy way to batch change an entire folder of pictures to change the Created/Modified dates to match the Created date from the Exif data?
The only other similar posts had answers that reccomend a piece of software that does not seem to actually do this, and one that suggests some sort of confusing script that I don't really understand.
Please help - I have a bunch of family photos that I really need to fix.

shootShifter helps to redate and rename complete folders of images based on the EXIF data or Finder dates.
So it will do batches.
I also believe that exporting the Original (File -> Export: Kind Original) will make all of this unnecessary.
I don't like having them only in iPhoto so I organize the originals into folders by choronological event then import them so I have copies outside the iPhoto library to put elsewhere.
You understand that you're using twice the disk space there, right? And that it's quite unnecessary. All iPhoto does is to put them in folders too. Have you looked inside the iPhoto Library ever?
Go to your Pictures Folder and find the iPhoto Library there. Right (or Control-) Click on the icon and select 'Show Package Contents'. A finder window will open with the Library exposed. Your photos are in the Masters folder.
Standard warning: Don't change anything in the iPhoto Library Folder via the Finder or any other application. iPhoto depends on the structure as well as the contents of this folder. Moving things, renaming things,, deleting them or otherwise making changes will prevent iPhoto from working and could even cause you to damage or lose your photos.
Regards
TD

Photo EXIF Data Stripped When Sync'd BACK to iPhone via iTunes

I'm not sure whether this belongs here or in the iPhone forum, but since it looks like an iTunes problem, I thought you all might have an idea. Here's the problem:
1. Take Picture with iPhone (3GS, if it matters) in portrait orientation.
2. Import Picture into Photoshop Elements 7.
3. EXIF Data survives (including correct orientation).
4. Put Picture in "iPhone Pictures" Album in Photoshop Elements 7.
5. EXIF Data survives (including correct orientation).
6. Delete Picture from Camera Roll on iPhone.
7. Sync "iPhone Pictures" Album (which includes Picture) to iPhone using iTunes 8.2.0.23.
8. EXIF Data lost (including incorrect orientation).
9. Picture appears on iPhone with incorrect orientation and all other EXIF Data appears to have been lost.
This appears, then, to be a problem with the way iTunes is treating the Picture when it syncs it back to the iPhone as a part of the "iPhone Pictures" Album, but I'm not certain.
My particular concern is with the loss of the orientation flag (which results in all portrait images rotated 90* CCW).
Any help or suggestions are appreciated.
Thanks.

Great bug report! Sorry, I don't have any ideas on how you might workaround it. I can only suggest that you submit it to Apple as a "real" bug report.
Submit bug report here:
https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa
If you don't already have an ADC account, you can get a free "ADC online" account here:
http://developer.apple.com/products/membership.html

Photos uploaded from iphone have exif data stripped out

How can I upload a photo from iphone via safari or an app with the EXIF data still intact? When I upload now from the phone via safari or an application, the EXIF data is lost.

You need to use the photo stream folder to share photos on a PC.

Exif data when exporting images

Hi, I have question about Aperture writing its signature in the exif data when i export pictures to websites like Flickr, in the past i used DPP, and it always shoved "digital photo professional" under more properties, just this is missing all the rest is there.
Is there a way i can get Aperture to get that pice of information in there......?
Jess Thorsen

There's a simpler method which you might consider using.
What file naming convention are you using on import? Why not rename your camera files on import into Aperture something like " dateclient_joboriginalfilename ". You could then either use that, or export with that name plus a sequential numbering scheme.
Or -- the same as Viren's excellent suggestion -- select all the files you are going to export, create duplicate versions, with the duplicates still selected create a new Album containing all of them, then use Aperture to rename the Versions prior to export and export using the Version name. Versions don't use much space (they are text files), and you end up with an Album of neatly numbered Versions of just the photos you've given to your client +with the file names of their files exactly the same as your Aperture Version names+.

3.4RC not exporting Exif data in jpegs?

I just checked and there seems to be no Exif data in my exported jpegs, even though Minimize Metadata is not checked. Anybody else experiencing this? DId I miss some new setting or way of specifying this? Win 7 64-bit, 64-bit LR.

In terms of the XMP standard, the EXIF schema properties have been omitted from the LR 3.4RC version of the image. For example, the 3.3 version has the property XMP:DateTimeOriginal, while the 3.4RC version does not. See below for all differences in the metadata.
I think this may be a bug. The XMP standard was designed to encapsulate legacy metadata such as EXIF, and it was intended that the XMP metadata contain duplicates of the EXIF properties. Unlike the EXIF standard, XMP allows multi-byte characters and time zones, so not exporting the XMP EXIF properties means that it won't be possible to export multi-byte characters and time zones.
Differences in metadata:
8d7
< [Composite]     Date/Time Created               : 2011:04:09 13:03:22
10d8
< [Composite]     Digital Creation Date/Time      : 2011:04:09 13:03:22
18c16
< [Composite]     Thumbnail Image                 : (Binary data 12845 bytes, use -b option to extract)
> [Composite]     Thumbnail Image                 : (Binary data 12854 bytes, use -b option to extract)
22c20
< [EXIF]          Copyright                       : Â©2011 Eulogio Garcia / Dhananjaya
> [EXIF]          Copyright                       : (C)2011 Eulogio Garcia / Dhananjaya
26c24
< [EXIF]          Exif Version                    : 0230
> [EXIF]          Exif Version                    : 0221
43c41
< [EXIF]          Modify Date                     : 2011:04:25 20:34:48
> [EXIF]          Modify Date                     : 2011:04:25 20:38:26
50d47
< [EXIF]          Software                        : Adobe Photoshop Lightroom 3.4
53,54c50,51
< [EXIF]          Thumbnail Length                : 12845
< [EXIF]          Thumbnail Offset                : 870
> [EXIF]          Thumbnail Length                : 12854
> [EXIF]          Thumbnail Offset                : 828
63c60
< [File]          Current IPTC Digest             : f6e139c9a1abb4f443dbcad907844238
> [File]          Current IPTC Digest             : c620bc8bc4f36f55110ec1c719189bf7
67,68c64,65
< [File]          File Modification Date/Time     : 2011:04:26 00:32:58-07:00
< [File]          File Name                       : image_pjpeg.jpg
> [File]          File Modification Date/Time     : 2011:04:26 00:33:13-07:00
> [File]          File Name                       : image_pjpeg.good.jpg
70c67
< [File]          File Size                       : 143 kB
> [File]          File Size                       : 144 kB
102,103c99
< [IPTC]          Application Record Version      : 4
< [IPTC]          Coded Character Set             : UTF8
> [IPTC]          Application Record Version      : 2
106,108d101
< [IPTC]          Digital Creation Date           : 2011:04:09
< [IPTC]          Digital Creation Time           : 13:03:22
< [IPTC]          Time Created                    : 13:03:22
112,113c105,106
< [Photoshop]     IPTC Digest                     : f6e139c9a1abb4f443dbcad907844238
< [Photoshop]     Photoshop Thumbnail             : (Binary data 12845 bytes, use -b option to extract)
> [Photoshop]     IPTC Digest                     : c620bc8bc4f36f55110ec1c719189bf7
> [Photoshop]     Photoshop Thumbnail             : (Binary data 12854 bytes, use -b option to extract)
116a110
> [XMP]           Aperture Value                  : 16.0
119a114
> [XMP]           Camera Model Name               : Canon EOS-1Ds Mark III
130c125,126
< [XMP]           Creator Tool                    : Adobe Photoshop Lightroom 3.4
> [XMP]           Creator Tool                    : Adobe Photoshop Lightroom 3.3
> [XMP]           Custom Rendered                 : Normal
131a128,129
> [XMP]           Date/Time Digitized             : 2011:04:09 13:03:22.00-04:00
> [XMP]           Date/Time Original              : 2011:04:09 13:03:22.00
132a131,133
> [XMP]           Exif Image Height               : 800
> [XMP]           Exif Image Width                : 1200
> [XMP]           Exif Version                    : 0221
133a135,139
> [XMP]           Exposure Compensation           : -1
> [XMP]           Exposure Mode                   : Auto
> [XMP]           Exposure Program                : Aperture-priority AE
> [XMP]           Exposure Time                   : 2
> [XMP]           F Number                        : 16.0
136a143,151
> [XMP]           Flash Fired                     : False
> [XMP]           Flash Function                  : False
> [XMP]           Flash Mode                      : Unknown
> [XMP]           Flash Red Eye Mode              : False
> [XMP]           Flash Return                    : No return detection
> [XMP]           Focal Length                    : 21.0 mm
> [XMP]           Focal Plane Resolution Unit     : inches
> [XMP]           Focal Plane X Resolution        : 3957.71670190275
> [XMP]           Focal Plane Y Resolution        : 3961.90476190476
150a166,167
> [XMP]           ISO                             : 100
> [XMP]           Image Height                    : 800
151a169
> [XMP]           Image Width                     : 1200
152a171
> [XMP]           Legacy IPTC Digest              : C620BC8BC4F36F55110EC1C719189BF7
167a187
> [XMP]           Make                            : Canon
169,170c189,192
< [XMP]           Metadata Date                   : 2011:04:25 20:34:48-04:00
< [XMP]           Modify Date                     : 2011:04:25 20:34:48-04:00
> [XMP]           Max Aperture Value              : 2.8
> [XMP]           Metadata Date                   : 2011:04:25 20:34:19.329+04:00
> [XMP]           Metering Mode                   : Spot
> [XMP]           Modify Date                     : 2011:04:25 20:38:26-04:00
185a208
> [XMP]           Resolution Unit                 : inches
196a220
> [XMP]           Scene Capture Type              : Standard
203a228
> [XMP]           Shutter Speed Value             : 2
213c238
< [XMP]           Version                         : 6.4
> [XMP]           Version                         : 6.3
217c242,245
< [XMP]           XMP Toolkit                     : Adobe XMP Core 5.2-c004 1.136881, 2010/06/10-18:11:35
> [XMP]           White Balance                   : Manual
> [XMP]           X Resolution                    : 240
> [XMP]           XMP Toolkit                     : Adobe XMP Core 4.2-c020 1.124078, Tue Sep 11 2007 23:21:40
> [XMP]           Y Resolution                    : 240

Exif data gets stripped exporting to camera roll

I import pics from camera roll to edit in PST. I then export back to camera roll so tha I can use another picture management app to sort my edited pics into files. However the original exif data seems to get stripped out, especially the original date an time the original photo was taken. Apps like Photogene and Filterstorm do no do this. Is there a way of stopping this happening ? Or is it a bug ..... Why can the original exif data not be left intact ?

Sounds daft as it would probably be easier for the app to eave the exif data intact rather than deliberately alter it !
I hope adobe can put his right as preserving the original date and time of a photo is crucial for some photographers. This kinda prevents me from using PST as it is very important for me, and I no need to resort back to using Photogene.

Lightroom strips very valuable EXIF data - details

Hey everyone - I've just been playing around with some EXIF stuff, and I noticed something very concerning.
I do a lot of macro photography, specifically with Canon's MP-E 65mm 1x-5x Macro. This lens records its macro magnification factor in the EXIF data, and does so far more accurately and conveniently than I can.
I know that Lightroom and Photoshop strip out A LOT of obscure EXIF data when processed, but this magnification data is extremely valuable when reviewing my photos at a later date.
I can provide sample files if needed, and here is my observations so far:
- data stays intact when converting from .CR2 to .DNG
- data is stripped when converting to JPG, TIFF, and other formats
- data is stripped by both Lightroom and Photoshop
Here is the EXIF data (from exiftool) right from the Canon CR2 or DNG file (both are identical):
http://don.komarechka.com/exif/exif-original.txt
Here is the EXIF data (from exiftool) from a jpg that has gone through Lightroom:
http://don.komarechka.com/exif/exif-lightroom.txt
You'll notice a HUGE amount of extra data in the original raw file. It is certainly worth noting that the EXIF data in a JPG, unaltered from the camera, contains all of the same data as the RAW file.
So, is this something that has been overlooked, is there any way to change this behaviour? Even though Lightroom might not be able to decode this data, I don't see a reason why it cannot be left intact.
Thank you.
- Don Komarechka
http://don.komarechka.com

donkom wrote:
clvrmnky, thanks for your response.
Here's an example for you, the one I've been giving:
I shoot with a special macro lensm the Canon MP-E 65mm f/2.8 1-5x Macro. This lens does not zoom, but the magnification can change from 1x to 5x.This lens communicates its magnification to one decimal point accuracy to the camera, which adds it to the maker notes.
This is important in reviewing images for a number of reasons, including calculating the effective aperture and depth fo field. This is a valuable piece of information that is stored within the makernotes that is removed from the image when sending it through LR, Photoshop, or ACR.
That isn't the only valuable information, however.
The makernotes will tell me if the image was captured using LiveView, if Mirror Lockup was used, if the shot is part of a bracketed set, what the internal camera temperature was, etc. etc.
I'm not sure you've justified your reasoning behind why this block of data shouldn't be blindly copied. If it is removed simply because it is not understood, I would like the option to understand this data on my own, using third-party tools, after the image has left LR.
I understand that this can be proprietary, but likely far less so than the RAW file formats that LR and ACR already understand. It would be trivial to understand where this block of data begins and ends and to leave it in the file on export.
I think this would allow for more in-depth searching based on metadata, for whoever wants to take up that torch. For example, what if I want to see all macro photos I took at a 4x magnification or higher. What if I want to see all photo I took using LiveView. Even if LR doesn't want to do this, stripping the data out prevents anyone else from doing it in the future.
Well, there is an SDK for metadata that has been around for awhile, which allows for custom metadata definitions. But, according to the SDK:
"Values stored in custom metadata fields are stored only in Lightroom's database. In the current release, a plug-in cannot link custom metadata fields to XMP values or save them with the image file."
So, this is more for searching and interfacing with tagset plugins.
Even so, using the SDK to get at maker notes is a losing proposition.
Note that some metadata is proprietary and will not be read into the database. This is to be expected. Lr is not an arbitrary metadata reading app, and there is no guarantee that any app could read all metadata. For example, Lr tries its best to get the serial number info, but this is because there is a lot of value in that for other Lr operations. So the contortions necessary to reliably get that is worth it. Another example is lens info (which is a twisty maze of passages; no app is ever guaranteed to actually retrieve lens info reliably in all cases) where there is a lot of value trying to extract the information that makers often store in very interesting ways. In some of those cases I think Lr will look in the maker notes, but only after exhausting other avenues, and with the caveat that it may never be able to get some information. The app does its best to get at the most valuable info it can get that fits with the standardized metadata models in place.
However, the key here is that maker note data is not in exported files that Lr makes, because it is not normalized data that belongs to the vendor. (This obviates the recommendation of using Metadata Wrangler, which can filter out only that metdata that exists in Lr; I had vaguely remembered a setting that referred to this section but was wrong.)
The field and data formats are not standardized, so you are asking Lr to understand most or all data from all or most lenses and bodies (all of it in varying degrees of similarity and difference) not just data from this lens and this body.
This is also not a trivial matter of "copying" the maker notes over, because copying implies parsing and duplicating what is essentially unknown formatted data containing proprietary data, possibly by custom serialization routines. Remember that maker notes were never intended to be editable, and could be composed of any number of data formats. Some cameras make maker notes that are megabytes of nulls and nothing else!
I think you are out of luck for this specific case. Perhaps with EXIF 3 we will have a more standardized interface cameras and software can more easily interoperate on shared data. Makers need to stop using the maker notes! It was always an egregious hack.
One workaround I can think of is to have a post-export action that uses EXIFTool to update exported images. For those cases where it matters, you could create your own "sidecar" file that has only the maker notes, and then shove those into the JPEG after they are created, or just read it from the on-disk copy and then put it in the new file (possibly in the same directory and added back into the catalogue for convenience.)

LR3.2 export - no more EXIF data on JPEG

Hello everybody,
trying to get some help...
My setup: iMac 24 running OSX 10.5.8 and Mac Book Pro 15" same OSX.
In both I'm using LR 2 for years, and couple of weeks ago I purchased the LR3.2
My photographs are in my galleries in Smugmug.
The images I want from my Nikon D 700 (NEF files) or other cameras I uploading for years in the Smugmug account
by sending initially the images in a reduced size and JPEG format to my desktop, and upload from there .
In the Smugmug clicking on the Info button anybody can see the EXIF data.
Now after the upgrade to the LR3.2 I got a problem: from the MBP everything is fine like before.
From the iMac - that is my main computer - the JPEG files will not carry the EXIF data. Nothing.
I did check the settings on the iMac and MBP, and are absolutely identical. However something might be different.
I wrote to Adobe, and after two weeks, 5 mails, and a few hours on the phone twice (shared the screen, so they can see it in life demo , what is going on - otherwise is hard to believe it...) nobody knows the solution.
I called Apple , and because is not their software, they couldn't help.
Tried the Delete and Download again and reinstall stuff, but is still doing the same thing.
Anybody has the something like this?
Any hints?
Thanks in advance
Joe

Well the files are reduced to 1200 pixels in longer side in LR. But would be a very strange thing to be a problem because the image is reduced to any specific size.
And as I said: the settings are identical in LR2 and LR3 and in both computers (iMac and MBP) .
The two LR2 is exporting with EXIF and the LR3 on MBP does. The LR3 in iMac is the only stripping the info.

When exporting a photo to photo library, all EXIF data is lost. What rational is behind this?

When exporting a photo to photo library, all EXIF data is lost.
What rational is behind this?

Thanks for your reply on this!
One issue seems to be with Foto Library app itself. When running an auto-correct there it looks like EXIF will be stripped more or less completely.
Second issue is in iPhoto app on iOS when working on RAW. When exporting to the roll the EXIF is modified in a way. It was keeping most of the EXIF in case of Canon 5D MKII that I tested today, but the EXIF data is definately changed, e.g. lens type is different because maybe some fields are ignored there. Also the images are silently scaled down by 50% which is kind of annoying.
The initial problem was observed with a Pentax K7 and I will need to reproduce the issue in this config I assume. Maybe tomorrow I can do this.

IPhoto not exporting Aperture EXIF data

Does anyone know why iPhoto will store the aperture value from the original EXIF data, however it will drop this information when exporting? I store my pictures on flickr and keep the EXIF data visible, but no matter how I export it will continually cut out a lot of EXIF data, including this important piece of information.

How are you exporting? Are you using a flickr plugin for iPhoto? If so that's what's stripping the info from the file. If you export from iPhoto to the Desktop via the File->Export->File Export all of the EXIF data is preserved and you can include the keywords, comments and file name.
Do you Twango?
TIP: For insurance against the iPhoto database corruption that many users have experienced I recommend making a backup copy of the Library6.iPhoto database file and keep it current. If problems crop up where iPhoto suddenly can't see any photos or thinks there are no photos in the library, replacing the working Library6.iPhoto file with the backup will often get the library back. By keeping it current I mean backup after each import and/or any serious editing or work on books, slideshows, calendars, cards, etc. That insures that if a problem pops up and you do need to replace the database file, you'll retain all those efforts. It doesn't take long to make the backup and it's good insurance.
I've written an Automator workflow application (requires Tiger), iPhoto dB File Backup, that will copy the selected Library6.iPhoto file from your iPhoto Library folder to the Pictures folder, replacing any previous version of it. It's compatible with iPhoto 08 libraries. You can download it at Toad's Cellar. Be sure to read the Read Me pdf file.

Exports aren't showing the EXIF Data

I just started shooting in RAW and today I exported some pictures to post on DPReview. The pictures did not include the EXIF data and I would like to include that information. Is there a setting I need to select prior to export so this data will be included? Thank you!

Use the setting in the export dialog.
You can choose from the dropdown menu e.g. copyright only or all metadata.
Also ensure DPreview is not stripping out metadata when you upload files.

EXIF data stripped on export??

Similar Messages

Maybe you are looking for