Lightroom modifies EXIF after import?

When I import photos with Lightroom, they seem to loose part of the lens data that DxO uses to process images with. For example, a photo with the lens Nikon 12-24mm f/4 AF-S will just be 12-24mm afterwards, and DxO won't know which lens algorithm to do the processing with.
Is there something I'm missing, or does Lightroom always modify the EXIF like this?
TIA.

I'm importing as they are, either RAW (NEFs) or JPEG. I know Lightroom isn't supposed to touch the EXIF, but somehow the lens data gets missing or corrupted, and I'm wondering if theres a setting on Lightroom that does this? I notice the Lens info gets turned into the same as whats in the Lens tree in the Metadata Browser.

Similar Messages

Files missing in Lightroom catalog after import?

I've got an external HD that has 7712 pictures in a single folder. All the files are either .JPG or .CR2 files taken from the same camera, a Canon EOS 5D. After importing the pictures into Lightroom the catalog only shows that 6712 pictures were imported. So there is a difference of 1000 pictures between what is in the folder on my external HD and what was put in the Lightroom catalog. Is there an easy way to determine which of the 1000 files did not get imported into Lightroom?

It might be that some Raws and Jpegs shared the same base filename, and Lightroom treated them as one Raw+Jpeg.
Check if your "treat jpegs and raws as separate files" option is selected in Preferences. If it is not, select it, and reimport your folder. Synchronize folder might work too.

How do I get Lightroom to delete photos from my iPhone after importing them?

Lightroom 4 imports photos and videos from my iPhone and puts them where I want them to go, and names the directories the way I want. All good. But it also leaves the photos on the phone to be manually deleted. Is there some way to have it delete the photos after import?

Not from Lightroom.

Lightroom library is almost 5gb after importing photos

I am new to Lightroom 5 and just imported about 4000 photographs. I just added them to Lightroom since they were already on my hard drive. I was amazed an confused why the Lightroom library file is almost 5 gb. I have yet to do anything else except import. I didn't think the library file would start to get large until I started processing and editing the files. What can I do to not have my library file get so huge, or is this what I can expect with Lightroom?

Minimal means a thumbnail-sized preview, so anything larger than that would be recomputed at the time you first view the photo. If you feel you'll be scrolling through all 4000 photos in Library Grid view at some point then compute Minimal previews.
I'd compute standard monitor-sized previews the first time you import a new folder of photos so you can do your tagging and flagging and rating and rejecting using the Fit or Fill zoom levels without waiting too long. If you find yourself needing to zoom in to check focus on many of the images then maybe computer 1:1 previews for the newly imported folder, otherwise zooming into 1:1 will require a preview to be computed rather than looked up from the previews folder.
Once you go to Develop the previews aren't used except as a placeholder until the on-the-fly rendering has occurred as you zoom in or out or flip to the next image in Develop.
You'll figure out what you want to do after working on a few folders of images, the tradeoff between getting started on any of the photos in the folder vs waiting longer as you move to each one for the first time.

Where is eject card after import in lightroom 4.1?

where is the "eject card after import" in lightroom 4.1?
'Devices', which is under 'Sources' (for import) has dissapeared, and only 'files'shows, The 'eject after import' phrase and it'scheckbox has vanished.
How do I get it back?
Thanks
Steve

The Eject checkbox is available when the device is selected from the 'From' drop down menu. See below screenshot

Separating jpg and raw files after importing in lightroom 5

i would like to separate my jpg and raw files once they are in lightroom (right after importing) so that all my jpgs are 1 after the other on the film strip below and my raw files are one after the other. is this possible?

In Library Grid view, on the Tool Bar (T), change "Sort:" to "File Extension"

Lightroom 5 Darkens Photos after Importing Images Used with Different Camera [NOT SHOOTING IN RAW NOR B

I seriously need help, my whole entire catalog of photos just got darkened for some reason after importing photos used with a different camera. What happened is that I imported photos taken with a different camera (Canon EOS 60D) and when I did that, it darkened all the rest of my photos (taken with Canon EOS Rebel T3). Why did this happen? This is making my photos insanely hard to edit.

If you always want Camera Neutral picture style to be applied, then open one of your images that you have imported and have changed nothing else in Lightroom. Set the camera profile to Camera Neutral and save new camera default settings. Then whenever you import that setting will be applied to all of your images.
If you don't always want that style, you could save a preset that applies the Camera Neutral picture style, and then you could choose to use that preset during the import process.
It is simply a matter of determining your workflow and then setting things the way you want them to work.

Colours trouble with a psd file after import/export through Lightroom 4

I'm working with CS5, and I just bought LR4. I took a psd file (in Adobe 98 space) and I imported it in LR 4, and the exported as psd file in Adobe 98 colour space. Both files, the original one and the other after import/export, are quite different. The saturation of the res is not the same... When I repeat this experinece with a psd file in sRGB or in Prophoto, I have no difference betwwen both files.
I then conclude that LR doesn't recognize the adobe 98 pprofile of my psd file.
Is that normal, have you tried this experience, is there a bug in LR or a bug in the way, I proceed?
Best regards

When you import there is an Advanced button in one of the dialogs. Click that and you will be able to Paginate against chosen styles. That will break your document into topics.
See www.grainge.org for RoboHelp and Authoring tips
@petergrainge

Lightroom export - original file with Lightroom modification data

Hello, hello!
I have imported a folder of, for arguments sake, some JPEGs, TIFFS, and DND photos into Lightroom, leaving the files in place, and just linking them to the Lightroom Catalogue's Library. I have then made a whole load of 'modifications' to the photos in Lightroom (the data for these modifications is stored in the Lightroom Catalogue file, right?).
Can I now export some of the photos from Lightroom so that the file that comes out is in the same/different file format (e.g. JPEG/TIFF/DNG) and have the Lightroom modification data embedded (perhaps in the EXIF data) of the exported file? Can I then open this with a 'normal' program and have it show the original? Can I then open this with Lightroom/Photoshop (?) and it show the original with the modification data applied?
Thanks a lot! :-))

Can I now export some of the photos from Lightroom so that the file that comes out is in the same/different file format (e.g. JPEG/TIFF/DNG) and have the Lightroom modification data embedded (perhaps in the EXIF data) of the exported file?
Yes, but you should not export. Just hit Ctrl/Cmd+S to Save Metadata. the metadata will be embedded into the files. Note that the actual image will not be altered. That is, if you view the jpeg in an external viewer you will not see the adjustments made in Lightroom. Only Adobe products can interpred those.
Can I then open this with a 'normal' program and have it show the original?
Yes.
Can I then open this with Lightroom/Photoshop (?) and it show the original with the modification data applied?
Yes. When you open in Photoshop and it's a non-RAW file (e.g. JPEG or TIFF), there's an option somewhere in Camera RAW to be used for opening non-RAWs. The point is, those have to pass through Camera RAW, rather than opened directly in Photoshop, for metadata to be interpreted properly.

Different colors after imported into LR3

I really i do not know what is this problem related to, but after I imported pitures into lightroom , it makae some modification and change the color of the picture.
Here are the examples:
The picture rendered by CDPP, looks as i wanted the picture to look like (also looks like this in the camera), while the one in LR modified the color, I have check the setting in the importer and i do not apply any preset. What am i am doing wrong? or there is a known problem in LR? Note: the render preview option is minimal.
The other issue i have. is when i shoot a picture with a high iso it ended up in LR with a red color. if needed i can post some exmaples as well.
Thanks for the help.

Helena,
You're right.
@Cafu_co,
Lightroom won't automatically match your camera settings, and it never will.
What you can do is to edit a file in Lightroom so it approximates the starting point that you'd like to have, and then make that the default change to the image that you're presented with after importing. You set the default in the Develop Module: hold down the Alt/Opt key and the button on the lower right of the window changes to Set Defaults... Press it.
One of the things that you'll want to investigate during that process is the Profile setting in the Camera Calibration panel. Most Canon models have profiles available that mimic your picture styles that can be set in the camera.
Hal

Unlogged Missing Photos After Import From Aperture

Hi!
I have just made the switch from Aperture to Lightroom, and have use the 1.1 version of the Aperture import plugin.
In my Aperture Library I have, according to the Library -> Photos: 11105 Photos, however after importing to Lightroom, I have only 10967 photos. I have checked the import log, and there were 4 items which failed to import - 3 were .mpo files (panoramas from an xPeria) and 1 was a .gif file. This leaves a deficit of 133 photos that I can't account for.
Is there any way to compare the aperture library to the lightroom library to see what is missing?

*WARNING* Once agin, this is a VERY long post! And this contains not only SQL, but heaps of command line fun!
TLDR Summary: Aperture is storing duplicates on disk (and referencing them in the DB) but hiding them in the GUI. Exactly how it does this, I'm not sure yet. And how to clean it up, I'm not sure either. But if you would like to know how I proved it, read on!
An update on handling metadata exported from Aperture. Once you have a file, if you try to view it in the terminal, perhaps like this:
$ less ApertureMetadataExtendedExport.txt
"ApertureMetadataExtendedExport.txt" may be a binary file. See it anyway?
you will get that error. Turns out I was wrong, it's not (only?) due to the size of the file / line length; it's actually the file type Aperture creates:
$ file ApertureMetadataExtendedExport.txt
ApertureMetadataExtendedExport.txt: Little-endian UTF-16 Unicode text, with very long lines
The key bit being "Little-endian UTF-16", that is what is causing the shell to think it's binary. The little endian is not surprising, after all it's an X86_64 platform. The UTF-16 though is not able to be handled by the shell. So it has to be converted. There are command line utils, but Text Wrangler does the job nicely.
After conversion (to Unicode UTF-8):
$ file ApertureMetadataExtendedExport.txt
ApertureMetadataExtendedExport.txt: ASCII text, with very long lines
and
$ less ApertureMetadataExtendedExport.txt
Version Name    Title   Urgency Categories      Suppl. Categories       Keywords        Instructions    Date Created    Contact Creator Contact Job Title       City    State/Province Country Job Identifier Headline        Provider        Source Copyright Notice        Caption Caption Writer Rating IPTC Subject Code       Usage Terms     Intellectual Genre      IPTC Scene      Location        ISO Country Code        Contact Address Contact City    Contact State/Providence        Contact Postal Code     Contact Country Contact Phone   Contact Email   Contact Website Label   Latitude        Longitude       Altitude        AltitudeRef
So, there you have it! That's what you have access to when exporting the metadata. Helpful? Well, at first glance I didn't think so - as the "Version Name" field is just "IMG_2104", no extension, no path etc. So if we have multiple images called "IMG_2104" we can't tell them apart (unless you have a few other fields to look at - and even then just comparing to the File System entries wouldn't be possible). But! In my last post, I mentioned that the Aperture SQLite DB (Library.apdb, the RKMasters table in particular) contained 11130 entries, and if you looked at the Schema, you would have noticed that there was a column called "originalVersionName" which should match! So, in theory, I can now create a small script to compare metadata with database and find my missing 25 files!
First of all, I need to add that, when exporting metadata in Aperture, you need to select all the photos! ... and it will take some time! In my case TextWrangler managed to handle the 11108 line file without any problems. And even better, after converting, I was able to view the file with less. This is a BIG step on my last attempt.
At this point it is worth pointing out that the file is tab-delimited (csv would be easier, of course) but we should be able to work with it anyway.
To extract the version name (first column) we can use awk:
$ cat ApertureMetadataExtendedExport.txt | awk -F'\t' '{print $1}' > ApertureMetadataVersionNames.txt
and we can compare the line counts of both input and output to ensure we got everything:
$ wc -l ApertureMetadataExtendedExport.txt
   11106 ApertureMetadataExtendedExport.txt
$ wc -l ApertureMetadataVersionNames.txt
   11106 ApertureMetadataVersionNames.txt
So far, so good! You might have noticed that the line count is 11106, not 11105, the input file has the header as I printed earlier. So we need to remove the first line. I just use vi for that.
Lastly, the file needs to be sorted, so we can ensure we are looking in the same order when comparing the metadata version names with the DB version names.
$ cat ApertureMetadataVersionNames.txt | sort > ApertureMetadataVersionNamesSorted.txt
To get the Version Names from the DB, fire up sqlite3:
$ sqlite3 Library.apdb
sqlite> .output ApertureDBMasterVersionNames.txt
sqlite> select originalVersionName from RKMaster;
sqlite> .exit
Checking the line count in the DB Output:
$ wc -l ApertureDBMasterVersionNames.txt
   11130 ApertureDBMasterVersionNames.txt
Brilliant! 11130 lines as expected. Then sort as we did before:
$ cat ApertureDBMasterVersionNames.txt | sort > ApertureDBMasterVersionNamesSorted.txt
So, now, in theory, running a diff on both files, should reveal the 25 missing files.... I must admit, I'm rather excited at this point!
$ diff ApertureDBMasterVersionNamesSorted.txt ApertureMetadataVersionNamesSorted.txt
IT WORKED! The output is a list of changes you need to make to the second input file to make it look the same as the first. Essentially, this will (in my case) show the Version Names that are missing in Aperture that are present on the File System.
So, a line like this:
1280,1281d1279
< IMG_0144
< IMG_0144
basically just means, that there are IMG_0144 appears twice more in the DB than in the Metadata. Note: this is specific for the way I ordered the input files to diff; although you will get the same basic output if you reversed the input files to diff, the interpretation is obviously reversed) as shown here: (note in the first output, we have 'd' for deleted, and in the second output it's 'a' for added)
1279a1280,1281
> IMG_0144
> IMG_0144
In anycase, looking through my output and counting, I indeed have 25 images to investigate. The problem here is we just have a version name, fortunately in my output, most are unique with just a couple of duplicates. This leads me to believe that my "missing" files are actually Aperture handling duplicates (though why it's hiding them I'm not sure). I could, in my DB dump look at the path etc as well and that might help, but as it's just 25 cases, I will instead get a FS dump, and grep for the version name. This will give me all the files on the FS that match. I can then look at each and see what's happening.
Dumping a list of master files from the FS: (execute from within the Masters directory of your Aperture library)
$ find . -type f > ApertureFSMasters.txt
This will be a list including path (relative to Master) which is exactly what we want. Then grep for each version name. For example:
$ grep IMG_0144 ApertureFSMasters.txt
./2014/04/11/20140411-222634/IMG_0144.JPG
./2014/04/23/20140423-070845/IMG_0144 (1).jpg
./2014/04/23/20140423-070845/IMG_0144.jpg
./2014/06/28/20140628-215220/IMG_0144.JPG
Here is a solid bit of information! On the FS i have 4 files called IMG_0144, yet if I look in the GUI (or metadata dump) I only have 2.
$ grep IMG_0144 ApertureMetadataVersionNamesSorted.txt
IMG_0144
IMG_0144
So, there is two files already!
The path preceding the image in the FS dump, is the date of import. So I can see that two were imported at the same time, and two separately. The two that show up in the GUI have import sessions of 2014-06-28 @ 09:52:20 PM and 2014-04-11 @ 10:26:34 PM. That means that the first and last are the two files that show in the GUI, the middle two do not.... Why are they not in the GUI (yet are in the DB) and why do they have the exact same import date/time? I have no answer to that yet!
I used open <filename> from the terminal prompt to view each file, and 3 out of my 4 are identical, and the fourth different.
So, lastly, with a little command line fu, we can make a useful script to tell us what we want to know:
#! /bin/bash
grep $1 ApertureFSMasters.txt | sed 's|\.|Masters|' | awk '{print "<full path to Aperture Library folder>"$0}' | \
while read line; do
openssl sha1 "$line"
done
replace the <full path to Aperture Library folder> with the full path to you Aperture Library Folder, perhaps /volumes/some_disk_name/some_username/Pictures/.... etc. Then chmod 755 the script, and execute ./<scriptname> <version name> so something like
$ ./calculateSHA.sh IMG_0144
What we're doing here is taking in the version name we want to find (for example IMG_0144), and we are looking for it in the FS dump list. Remember that file contains image files relative to the Aperture Library Master path, which look something like "./YYYY/MM/DD/YYYYMMDD-HHMMSS/<FILENAME>" - we use sed to replace the "./" part with "Masters". Then we pipe it to awk, and insert the full path to aperture before the file name, the end result is a line which contains the absolute path to an image. There are several other ways to solve this, such as generating the FS dump from the root dir. You could also combine the awk into the sed (or the sed into the awk).. but this works. Each line is then passed, one at a time, to the openssl program to calculate the sha-1 checksum for that image. If a SHA-1 matches, then those files are identical (yes, there is a small chance of a collision in SHA-1, but it's unlikely!).
So, at the end of all this, you can see exactly whats going on. And in my case, Aperture is storing duplicates on disk, and not showing them in the GUI. To be honest, I don't actually know how to clean this up now! So if anyone has any ideas. Please let me know I can't just delete the files on disk, as they are referenced in the DB. I guess it doesn't make too much difference, but my personality requires me to clean this up (at the very least to provide closure on this thread).
The final point to make here is that, since Lightroom also has 11126 images (11130 less 4 non-compatible files). Then it has taken all the duplicates in the import.
Well, that was a fun journey, and I learned a lot about Aperture in the process. And yes, I know this is a Lightroom forum and maybe this info would be better on the Aperture forum, I will probably update it there too. But there is some tie back to the Lightroom importer to let people know whats happening internally. (I guess I should update my earlier post, where I assumed the Lightroom Aperture import plugin was using the FS only, it *could* be using the DB as well (and probably is, so it can get more metadata))
UPDATE: I jumped the gun a bit here, and based my conclusion on limited data. I have finished calculating the SHA-1 for all my missing versions. As well as comparing the counts in the GUI, to the counts in the FS. For the most part, where the GUI count is lower than the FS count, there is a clear duplicate (two files with the same SHA-1). However I have a few cases, where the FS count is higher, and all the images on disk have different SHA-1's! Picking one at random from my list; I have 3 images in the GUI called IMG_0843. On disk I have 4 files all with different SHA-1's. Viewing the actual images, 2 look the same, and the other 2 are different. So that matches 3 "unique" images.
Using Preview to inspect the exif data for the images which look the same:
image 1:
Pixel X Dimension: 1 536
Pixel Y Dimension: 2 048
image 2:
Pixel X Dimension: 3 264
Pixel Y Dimension: 2 448
(image 2 also has an extra Regions dictionary in the exit)
So! These two images are not identical (we knew that from the SHA-1), but they are similar (content is the same - resolution is the same) yet Aperture is treating these as duplicates it seems.. that's not good! does this mean that if I resize an image for the web, and keep both, that Aperture won't show me both? (at least it keeps both on disk though, I guess...)
The resolution of image 1, is suspiciously like the resolutions that were uploaded to (the original version of) iCloud Photos on the iPhone (one of the reasons I never used it). And indeed, the photo I chose at random here, is one that I have in an iCloud stored album (I have created a screensaver synced to iCloud, to use on my various Mac's and AppleTVs). Examining the data for the cloud version of the image, shows the resolution to be 1536x2048. The screensaver contains 22 images - I theorised earlier that these might be the missing images, perhaps I was right after all? Yet another avenue to explore.
Ok. I dumped the screensaver metadata, converted it to UTF-8, grabbed the version names, and sorted them (just like before). Then compared them to the output of the diff command. Yep! the 22 screensaver images match to 22 / 25 missing images. The other 3, appear to be exact duplicates (same SHA-1) of images already in the library. That almost solves it! So then, can I conclude that Lightroom has imported my iCloud Screensaver as normal photos of lower res? In which case, it would likely do it for any shared photo source in Aperture, and perhaps it would be wise to turn that feature off before importing to Lightroom?

After importing images from my card using LR 5.4, the GPS data does not show in the metadata panel. However, when I look at the imported images using Bridge, the GPS data is visible. Anybody know why LR is not seeing the GPS data? Camera is Canon 6D.

After importing images from my card using LR 5.4, the GPS data does not show in the metadata panel. However, when I look at the imported images using Bridge, the GPS data is visible. Anybody know why LR is not seeing the GPS data? Camera is Canon 6D.

Ok, the issue seem to be solved. The problem was this:
The many hundred files (raw and xmp per image) have been downloaded by ftp in no specific order. Means - a couple of files in the download queue - both raw and xmps. Most of the time, the small xmp files have been finished loading first and hence the "last change date" of these xmp files was OLDER than the "last change date" of the raw file - Lightroom then seem to ignore the existence of the xmp file and does not read it during import.(a minute is enough to run into the problem)
By simply using the ftp client in a way that all large raw files get downloaded first followed by the xmp files, we achieved that all "last changed dates" of the xmp files are NEWER than the related raw files. (at least not older)
And then LR is reading them and all metadata information has been set / read correctly.
So this is solved.

Aperture 3.4.5 will not show NEF files after importing in OSx 3.8.5

Hi this is driving me crazy. I have quite a few NEF files from a Nikon E5000 that I would love to be able to process using Aperture but have run into a rather difficut situation. When I import my images into Aperture I can see the preview of the files in the browser but can not get them to display after they have been imported. I have tried importing localy through the internal hard drive on my IMac late 2007 as well as through an external NTFS formated USB backup of my files. It also chokes on direct imprting from the CF card using a card reader. In all cases they will sometimes display for a brief second both in the picture browser after importing or on the film strip view but will then disapear and display "unsupported image format" in its place. I have reinstalled aperture and run both repair persissions through disk utility and the aperture repair utility that ships with aperture. I have no problems with canon raw files or other file formats - jpg, tiff, png, photoshop, bmp. Also NEF files will open in lightroom 5 and photoshop cs6 with out issue as well.
Any help in restoring functionility would be greatly appreciated. Thanks for the time and effort in advance.
Que Too

Nikon E5000
Do you mean a NIkon CP 5000 (Coolpix 5000)? Aperture supports many raw formats, but not all, because the raw support has to be camera specific. Not all NEF files are in the same format - all Nikon cameras will call their raw files NEF.
For some cameras Aperture never included raw support. The currently supported cameras are listed here:
http://www.apple.com/aperture/specs/raw.html
It looks like your camera is not on this list, so if you want to shoot raw with that camera, develope the raw files using a different raw converter (Adobe's dng converter or the suftware that came with your camera) and import tiff or dng files to Aperture.
Regards
Léonie

Lightroom 4 does not import RAW files from D610

I've just purchased Nikon D610, and my Lightroom 4 is not importing RAW files anymore. What is the problem?

The current version of LR 5 is 5.7 so I’d guess LR 6 will be out at some point later this year, in the next few months. If money’s no object then upgrade to LR 5, now and to LR 6 in a few months. If you’ll be very upset to learn you’ve paid $80 to upgrade and then need to pay another upgrade fee for LR 6 then maybe wait and do the DNG thing for a few months, and then upgrade from LR4 to LR6.
The other concern is whether your OS is new enough. I’d suggest you download the latest LR 5.7.1 update and run that in trial mode for a few weeks—you have 30 days, to make sure your computer can handle it, before spending the money and finding out you need a new computer, first.
The other thing to consider is the $10/month Photography Plan subscription which gets you the most up-to-date versions of Lightroom and Photoshop as long as you keep paying. Since you have your old LR4 serial number, you can decide to cancel the subscription after a year and use the LR4 serial number to buy the LR 6 upgrade, then. This assumes that LR 6 will be available as a serial-number-licensed product, still.
The latest LR 5.7.1 update is here:
http://www.adobe.com/downloads/updates
The lens profiles added to each version are listed here:
http://helpx.adobe.com/x-productkb/multi/lens-profile-support-lightroom-4.html

After import, image from camera replaced with old (and incorrect) image

i imported photos this morning. maybe 200. into Lightroom 5.6 (with
camera raw 8.6, running on macosx 10.9.5; see below for "system info"). the images came from my
Leica M Typ 240, and were in raw format. after importing the images, i
went through them in my first editing pass.
going through, image 1867 ("L1001867.DNG") in LR was *not* the same as
image 1867 on my camera, but was, rather, an image (no longer on the
card in my camera) from 8 months ago in China.
the image on the camera was from 07.10.2014 15:49.15 (following one
taken at 15:49:07, which *did* show up in LR). the *meta* data in LR
appears correct for the image from the camera (i.e, shows a date of
07.10.2014, has likely exposure information, etc.), but the image itself
is the wrong image.
the image in LR *may* have been one i deleted (in LR), though i don't
know that for sure. if i *did* delete it, i deleted it months ago.
the LR image was shot on 22.02.2014 at 02:51-02:52 (i typically don't
change the clock). while i don't know for sure the image number of the
image in LR, it *appears* to be image 1419.
obviously, this is fairly worrying (as i count of LR to keep my
inventory!). what can i do to help you troubleshoot this? what can you
tell me about what is happening?
here is what "help:system info" says:
Lightroom version: 5.6 [974614]
License type: Perpetual
Operating system: Mac OS 10
Version: 10.9 [5]
Application architecture: x64
Logical processor count: 4
Processor speed: 2.9 GHz
Built-in memory: 8192.0 MB
Real memory available to Lightroom: 8192.0 MB
Real memory used by Lightroom: 1673.7 MB (20.4%)
Virtual memory used by Lightroom: 3555.8 MB
Memory cache size: 1608.3 MB
Maximum thread count used by Camera Raw: 2
Displays: 1) 2560x1600
Application folder: /Applications
Library Path: /Users/minshall/Pictures/Lightroom/Lightroom 5 Catalog.lrcat
Settings Folder: /Users/minshall/Library/Application Support/Adobe/Lightroom
Installed Plugins:
1) Behance
2) Canon Tether Plugin
3) Facebook
4) Flickr
5) Leica Tether Plugin
6) Nikon Tether Plugin
7) Photoshelter Archive Publisher
Config.lua flags: None
AudioDeviceIOBlockSize: 512
AudioDeviceName: Built-in Output
AudioDeviceNumberOfChannels: 2
AudioDeviceSampleRate: 44100
Build: Uninitialized
CoreImage: true
GL_ACCUM_ALPHA_BITS: 0
GL_ACCUM_BLUE_BITS: 0
GL_ACCUM_GREEN_BITS: 0
GL_ACCUM_RED_BITS: 0
GL_ALPHA_BITS: 8
GL_BLUE_BITS: 8
GL_DEPTH_BITS: 24
GL_GREEN_BITS: 8
GL_MAX_3D_TEXTURE_SIZE: 2048
GL_MAX_TEXTURE_SIZE: 16384
GL_MAX_TEXTURE_UNITS: 8
GL_MAX_VIEWPORT_DIMS: 16384,16384
GL_RED_BITS: 8
GL_RENDERER: Intel HD Graphics 4000 OpenGL Engine
GL_SHADING_LANGUAGE_VERSION: 1.20
GL_STENCIL_BITS: 8
GL_VENDOR: Intel Inc.
GL_VERSION: 2.1 INTEL-8.28.32
GL_EXTENSIONS: GL_ARB_color_buffer_float GL_ARB_depth_buffer_float
GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers
GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced
GL_ARB_fragment_program GL_ARB_fragment_program_shadow
GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB
GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_instanced_arrays
GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query
GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite
GL_ARB_provoking_vertex GL_ARB_seamless_cube_map GL_ARB_shader_objects
GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shadow
GL_ARB_sync GL_ARB_texture_border_clamp GL_ARB_texture_compression
GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map
GL_ARB_texture_env_add GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float
GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two
GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix
GL_ARB_vertex_array_bgra GL_ARB_vertex_blend GL_ARB_vertex_buffer_object
GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr
GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate
GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract
GL_EXT_clip_volume_hint GL_EXT_debug_label GL_EXT_debug_marker
GL_EXT_draw_buffers2 GL_EXT_draw_range_elements GL_EXT_fog_coord
GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample
GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB
GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4
GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float
GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color
GL_EXT_separate_specular_color GL_EXT_shadow_funcs
GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture_array
GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc
GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic
GL_EXT_texture_integer GL_EXT_texture_lod_bias GL_EXT_texture_rectangle
GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB
GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_EXT_transform_feedback
GL_EXT_vertex_array_bgra GL_APPLE_aux_depth_stencil
GL_APPLE_client_storage GL_APPLE_element_array GL_APPLE_fence
GL_APPLE_float_pixels GL_APPLE_flush_buffer_range GL_APPLE_flush_render
GL_APPLE_object_purgeable GL_APPLE_packed_pixels GL_APPLE_pixel_buffer
GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_specular_vector
GL_APPLE_texture_range GL_APPLE_transform_hint
GL_APPLE_vertex_array_object GL_APPLE_vertex_array_range
GL_APPLE_vertex_point_size GL_APPLE_vertex_program_evaluators
GL_APPLE_ycbcr_422 GL_ATI_separate_stencil GL_ATI_texture_env_combine3
GL_ATI_texture_float GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip
GL_NV_blend_square GL_NV_conditional_render GL_NV_depth_clamp
GL_NV_fog_distance GL_NV_light_max_exponent GL_NV_texgen_reflection
GL_NV_texture_barrier GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp
GL_SGIS_texture_lod

it appears the actual image is probably in place, but the *preview* is incorrect. clicking on the image to zoom in causes (the normal) "Loading...", followed by a zoomed in view of the *correct* image. zooming back out gives the normal view of the correct image. (*very* good to know!)

Lightroom modifies EXIF after import?

Similar Messages

Maybe you are looking for