NEF + ACR = HOPELESS

I'm using ACR 3.3 on Mac OSX 10.4.3. I'm a Nikon user - D2X, D200 and D70. I'm also a wedding shooter, which means nailing color (bride's skin and dress must be correct) in sometimes wildly different light - bright sunlight to deep shade to warm sunset to studio flash to on-camera flash to dim incandescent - all in a few hours of the same shoot. Sometimes exposure is off a bit - dress highlights blown or flash fails to fully recycle. Sometimes color is off a bit, or a lot; I'll take a custom WB when I can, but things are often moving too fast for that.
So I need color accuracy, the ability to correct color quickly and easily, and workflow efficiency (I average one wedding per week and 1300-1500 images captured per event with 500-700 "keepers"). Nikon Capture (4.4.1) gives me color accuracy and I'm so used to the interface that I can get a lot of images processed with relatively few mouse clicks. But it's extremely slow, crashes frequently and lacks certain key tools, such as a straightening tool and a decent cropping tool - forcing me to run most images through PS anyhow.
I tried ACR in it's early releases and had very little luck. Recently I got the Fraser book and tried again. I calibrated all my camera/lens combinations using the Fors script and the initial results were encouraging, but I was testing with easy subjects - nature scenes and studio shots of people. Then I tried a wedding: no joy!! I went running back to NC after a couple dozen images. I spent so much time tweaking the exposure and color controls in ACR that any time I gained due to the products speed was lost (and then some) fighting the color. At least with NC most of the wasted time is spent just waiting - so I can multitask to some degree.
I'm coming to the conclusion that ACR just doesn't work in my scenario. For anyone interested, my last sad and apparently wasted attempt with ACR is detailed in the DPReview thread below - note the change in my enthusiasm from the start of the thread until now.
http://forums.dpreview.com/forums/read.asp?forum=1021&message=17605133
If I'm missing something obvious would someone please point it out?

Hi Greg,
I empathize. I own a couple of Nikon DSLRs-- but in my line of business I work with raw brands from all kinds of camera makers. Like you, like many others, I therefore prefer ACR for my workflow-- but accurate colo(u)r processing can be as elusive as riding atop a bucking bull. You can only stay on the saddle as long as you accurately predict, within narrow tolerances, the next wild swing.
From my humble experiences, calibration works best for daylight and tungsten-ish. I assume, and the more technically informed members are free to correct me, that's because those are the two fixed targets third party solutions will profile for. Most any deviation to the known profiles therefore becomes a moving target. Fortunately, in my case, most of the photos I deal with are more or less true to daylight. However for mixed lighting, the camera makers packages have shown to demonstrate their own advantages. I'll frequently disagree with some arguments Mr. Borg puts forth in the link you provided--but in this case I believe his reservations are accurate.
From what I have learned, here's why: Adobe and most third party alternatives don't have access to all the colo(u)r information your camera produces. Most, if not all, camera makers won't publish or document that data. Therefore Adobe, and other raw processors, must take the time to generate new profiles for every camera once it's released. Those new profiles, won't be anywhere near as detailed as the camera makers have avaialble to them. I believe this is the case because:
1. There isn't enough time to generate more than a couple of profiles (probably daylight and tungsten) before the market HOWwwwwels for their favorite new camera to be supported.
2. The ISO sensitivity of each sensor is not an absolute. The camera makers know much more about camera to camera deviation than the entire networked raw processing community.
3. There could be other proprietary channel data that only the camera makers are privy to.
So what does this mean? My interpretation of this is that if you use the Fors script to recalibrate ACR for a specific camera's deviation, you will have the best results when shooting at temperatures the camera was only initially profiled at. Anything else is a moving target and requires further futzing. Nikon Capture can lookup nikon's full library of profiles, and therefore provide you with more accurate results the first time around. This can be advantageous if you're shooting under deviant lighting and need bulk processing. Bruce, or others, are free to weigh in and dispute any of these interpretations if I'm not correctly describing them.
So what can be done? If you shoot under deviant conditions, you can either futz in ACR or grow your beard waiting for NC to process your images. Freshly enlightened, you could also join the growing movement to ask camera makers to document their formats so that everyone has access to the same colo(u)r information. In DPreview you'll read that the Open RAW foundation and others are active proponents of this solution. As an alternate, but I believe ultimately more effective solution, is one that you'll find myself, as well as some other forum members putting forth. That would be insisting camera makers --such as Nikon--first support the *option* of saving your raw files to DNG over NEF.
Why DNG? DNG places the burden of providing the correct spectral response with the file's maker. Therefore, Nikon, as the camera maker, would need to embed the correct, or at least a sanctioned spectral response into any in-camera DNG --thus making it self contained and independent of third party profiles. It's my assumption, but I'm not yet clear if this is absolute, that Nikon could do this *without* the need to openly document what they are doing. Furthermore, I believe that while camera makers will need their arms twisted by their customers to offer either:
A. full and open documentation or
B. DNG support
it will be far easier to leverage market support for a universal raw container--such as DNG before camera makers succomb to openly publishing the ingredients to their secret sauce.
In conclusion, while your title suggests NEF+ACR is hopeless, it's my belief that DNG+ACR could be very hopeful to your cause. :-)

Similar Messages

D3 NEF/ACR Conversion

I notice that there are now two ACR Profile options in the Camera Calibration panel for the Nikon D3. Namely 4.3 and 4.4; the latter apprearing to be the default. I have to say to my eye the conversions each make on a sample NEF file appear remarkably similar - although I have no doubt some who know better will tell me otherwise.
Notwithstanding that, I also notice from a thread in the LR Beta2 forum the hint from Eric Chan that moves are afoot to improve the ACR conversion performance nearer to that of Nikon, Canon etc. A hint supported by Thomas Knoll no less in the same thread. As my local farmers say, relative to rumours of the Beast of Exmoor: 'thar mut be summut init'.
Looking at the timeline of these postings and the release of ACR 4.4, my supposition is that such 'improvement' was not incorporated therein, and there is more on the way. Unless, of course, someone knows better.

There were some improvements made to all profiles in Camera Raw/DNG 4.4/Lightroom 1.4.
From the release notes:
Previous camera profiles identified in the Calibrate panel of the Develop module may have displayed poor results at extreme ends of the temperature and tint ranges. A new camera profile identified as Camera Raw 4.4 is now available and will be applied by default to all images without existing Camera Raw or Lightroom settings. The creation of new default profiles will also include the updated Camera Raw 4.4 profile.
So there might be a slight improvement for all your files in 4.4.1/1.4.1 (the current release). I created a preset to enable batch conversion, which is available on the site in the sig.
The 4.4 release isn't the same thing that Thomas and Eric are talking about.
Richard Earney
[commercial link deleted]

Bridge NEF view - selected image altered - Camera Raw issue?

I use a Nikon D700 and CS3 Bridge on a MAC OSX 10.4.11, and when browsing NEF images in Bridge there is an action performed on the image whenever I click on it. I use the settings where a filmstrip is along the bottom and upon selection a larger image appears above. Initially the image appears as I recall exposing it and looks balanced with good saturation, but after selection the image brightens and loses saturation after a few moments. When I open the image in Camera Raw I find that the Brightness is set at +50 and the contrast is set at +25, and the Blacks slider is set at 5. When I reset those parameters to zero I do not recover the look of the image as it was before selection in the bridge window. In order to do that I have to raise the saturation, decrease the brightness and do a fair amount of work to get back to the way the image appeared in Bridge prior to selection. Can anyone tell me what is happening to the image in bridge and how to keep the image from changing after I select it, or at least how to find the settings that have been evidently applied to the image? If I right click on the thumbnail first, I find that the image will open in camera raw without any changes being made in Bridge, so I was able to make jpegs that show the difference between the two images. The first image is as it appears before selcting the thumbnail, and the second is the image in camera raw. If I were to have selected the image normally with a left click in Bridge, the photo as you see it in camera raw would have appeared in bridge and not been recoverable to its earlier state. Can someone help me undertand what is happening here? How can I find out what Bridge or Camera Raw is doing to the images and retain the appearance as it first appears in Bridge? Thank you for your help.

This is a common question.
What you see first in Bridge is actually a JPG which the camera has embedded in the NEF, and uses all the camera's color settings (contrast, saturation, etc.). Once you select the NEF, ACR (Adobe Camera Raw) attempts to render its own preview of the NEF. Because ACR does not understand the camera's color settings, it gives you its default rendering, which usually is somewhat different than the camera's.
In newer versions of ACR (5.x), Adobe has profiles which mimic the camera's presets ('Standard', 'Vivid', etc.) and can be applied automatically in Bridge. Unfortunately, you will need CS4 for this version of ACR (and these profiles have some issues of their own, e.g. http://forums.adobe.com/thread/479960?tstart=0). You can also create your own ACR presets to more or less emulate a particular look (I believe you will need CS4 for this as well).

Bug: Multiple Files Open ACR Crashes Photoshop...

I have several small files (500 pixels wide) and ACR crashes Photoshop (three times in last hour) when I make small moves with the sliders Exposure/Blacks/mids.
I don't seem to have this problem when I don't keep several open files.
I have noticed this over some time now and the key to repeating the problem is having several files open in PS and opening/adjusting d300 nef files in ACR.
This is 8-core, 14000 MB ram, 10.5/CS3extended (all updates ran)

Well I built another 100-layer 720x540 .psd file before it Crashed with the following Report keeping a max 2 files open (Bridge> .nef> ACR> Photoshop 16-bit) has greatly reduced my ability to reproduce this crash, but not eliminated the problem -- sigh... <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE AdobeCrashReport SYSTEM "AdobeCrashReporter.dtd"> <crashreport version="1.1" crVersion="2.5.0.02272007" applicationName="Photoshop" applicationVersion="10.0.1" build="10.0.1 (10.0.1x20071012 [20071012.r.1644 2007/10/12:09:30:00 cutoff; r branch]), ©1990-2007 Adobe Systems Incorporated"> <time year="2008" month="6" day="20" hour="19" minute="37" second="5" /> <user guid="5F46434A-15D5-4A63-A652-31682CE59DD0" /> <system platform="macintosh" osversion="10.5.3" applicationlanguage="en" userlanguage="en" oslanguage="en_US" ram="14336MB" machine="i386" model="MacPro3,1" cpuCount="8" cpuFreq="2800MHz" busFreq="1600MHz" /> <crash exception="Unmapped Memory Exception" instruction="c683068b"> <backtrace crashedThread="0"> <thread index="0"> <stackStatement index="0" address="0xffff07c2" symbolname="unknown"/> <stackStatement index="1" address="0x902f962d" symbolname="__ZN18CTextensionIOSuite17SearchIOSuiteTypeEmP11TDataHeaderh"/> <stackStatement index="2" address="0x902f956b" symbolname="__ZN18CTextensionIOSuite16FreeSuiteObjectsEm"/> <stackStatement index="3" address="0x902f953a" symbolname="__ZN18CTextensionIOSuite16FreeSuiteObjectsEv"/> <stackStatement index="4" address="0x90306ffb" symbolname="__ZN18CTextensionIOSuite4FreeEv"/> <stackStatement index="5" address="0x902c3357" symbolname="__ZN22CTextensionEditCommand4FreeEv"/> <stackStatement index="6" address="0x90306e39" symbolname="__ZN15OpaqueTXNObject4FreeEv"/> <stackStatement index="7" address="0x90306d6a" symbolname="_TXNDeleteObject"/> <stackStatement index="8" address="0x2ee213a3" symbolname="_EntryFM"/> <stackStatement index="9" address="0x2edefb52" symbolname="_EntryFM"/> <stackStatement index="10" address="0x2edb561a" symbolname="_EntryFM"/> <stackStatement index="11" address="0x2edb1be6" symbolname="_EntryFM"/> <stackStatement index="12" address="0x2edf1d06" symbolname="_EntryFM"/> <stackStatement index="13" address="0x2edb561a" symbolname="_EntryFM"/> <stackStatement index="14" address="0x2edb1be6" symbolname="_EntryFM"/> <stackStatement index="15" address="0x2edd1d13" symbolname="_EntryFM"/> <stackStatement index="16" address="0x2edb561a" symbolname="_EntryFM"/> <stackStatement index="17" address="0x2edb1be6" symbolname="_EntryFM"/> <stackStatement index="18" address="0x2edf3cf9" symbolname="_EntryFM"/> <stackStatement index="19" address="0x2edb561a" symbolname="_EntryFM"/> <stackStatement index="20" address="0x2edb1be6" symbolname="_EntryFM"/> <stackStatement index="21" address="0x2edf4fd1" symbolname="_EntryFM"/> <stackStatement index="22" address="0x2edb561a" symbolname="_EntryFM"/> <stackStatement index="23" address="0x2edb1be6" symbolname="_EntryFM"/> <stackStatement index="24" address="0x2edd1d13" symbolname="_EntryFM"/> <stackStatement index="25" address="0x2edb561a" symbolname="_EntryFM"/> <stackStatement index="26" address="0x2edb1be6" symbolname="_EntryFM"/> <stackStatement index="27" address="0x2edf3cf9" symbolname="_EntryFM"/> <stackStatement index="28" address="0x2edb561a" symbolname="_EntryFM"/> <stackStatement index="29" address="0x2edb1be6" symbolname="_EntryFM"/> <stackStatement index="30" address="0x2edf4fd1" symbolname="_EntryFM"/> <stackStatement index="31" address="0x2edb561a" symbolname="_EntryFM"/> <stackStatement index="32" address="0x2edb1be6" symbolname="_EntryFM"/> <stackStatement index="33" address="0x2edd1d13" symbolname="_EntryFM"/> <stackStatement index="34" address="0x2edb561a" symbolname="_EntryFM"/> <stackStatement index="35" address="0x2edb1be6" symbolname="_EntryFM"/> <stackStatement index="36" address="0x2edb1d6b" symbolname="_EntryFM"/> <stackStatement index="37" address="0x2ec79868" symbolname="unknown"/> <stackStatement index="38" address="0x2edb561a" symbolname="_EntryFM"/> <stackStatement index="39" address="0x2edb1be6" symbolname="_EntryFM"/> <stackStatement index="40" address="0x2edd1d13" symbolname="_EntryFM"/> <stackStatement index="41" address="0x2edb561a" symbolname="_EntryFM"/> <stackStatement index="42" address="0x2edb1be6" symbolname="_EntryFM"/> <stackStatement index="43" address="0x2edd1d13" symbolname="_EntryFM"/> <stackStatement index="44" address="0x2edb561a" symbolname="_EntryFM"/> <stackStatement index="45" address="0x2edb1be6" symbolname="_EntryFM"/> <stackStatement index="46" address="0x2edd1d13" symbolname="_EntryFM"/> <stackStatement index="47" address="0x2edb561a" symbolname="_EntryFM"/> <stackStatement index="48" address="0x2ee147b9" symbolname="_EntryFM"/> <stackStatement index="49" address="0x2ee14a01" symbolname="_EntryFM"/> <stackStatement index="50" address="0x2ecc5f80" symbolname="_EntryFM"/> <stackStatement index="51" address="0x2ee04f8a" symbolname="_EntryFM"/> <stackStatement index="52" address="0x2ee04bc7" symbolname="_EntryFM"/> <stackStatement index="53" address="0x2ee04c6c" symbolname="_EntryFM"/> <stackStatement index="54" address="0x2ee04cd3" symbolname="_EntryFM"/> <stackStatement index="55" address="0x2ecc656f" symbolname="_EntryFM"/> <stackStatement index="56" address="0x2ec8e63b" symbolname="unknown"/> <stackStatement index="57" address="0x2eca7eb3" symbolname="unknown"/> <stackStatement index="58" address="0x2ee06176" symbolname="_EntryFM"/> <stackStatement index="59" address="0x2ee099cf" symbolname="_EntryFM"/> <stackStatement index="60" address="0x2ecaea1b" symbolname="_EntryFM"/> <stackStatement index="61" address="0x0073cb5a" symbolname="unknown"/> <stackStatement index="62" address="0x00474448" symbolname="unknown"/> <stackStatement index="63" address="0x0047511a" symbolname="unknown"/> <stackStatement index="64" address="0x00474d2b" symbolname="unknown"/> <stackStatement index="65" address="0x00479187" symbolname="unknown"/> <stackStatement index="66" address="0x0050e151" symbolname="unknown"/> <stackStatement index="67" address="0x004cfeae" symbolname="unknown"/> <stackStatement index="68" address="0x0007e712" symbolname="unknown"/> <stackStatement index="69" address="0x0007eb7c" symbolname="unknown"/> <stackStatement index="70" address="0x00b50dcf" symbolname="unknown"/> <stackStatement index="71" address="0x0007e273" symbolname="unknown"/> <stackStatement index="72" address="0x00065187" symbolname="unknown"/> <stackStatement index="73" address="0x004755a9" symbolname="unknown"/> <stackStatement index="74" address="0x0006594a" symbolname="unknown"/> <stackStatement index="75" address="0x00065a6f" symbolname="unknown"/> <stackStatement index="76" address="0x000688cb" symbolname="unknown"/> <stackStatement index="77" address="0x000676c7" symbolname="unknown"/> <stackStatement index="78" address="0x000602ee" symbolname="unknown"/> <stackStatement index="79" address="0x0006045d" symbolname="unknown"/> <stackStatement index="80" address="0x00060570" symbolname="unknown"/> <stackStatement index="81" address="0x00219cd6" symbolname="unknown"/> <stackStatement index="82" address="0x00219d31" symbolname="unknown"/> <stackStatement index="83" address="0x00003272" symbolname="unknown"/> <stackStatement index="84" address="0x00003199" symbolname="unknown"/> <stackStatement index="85" address="0x00000002" symbolname="unknown"/> </thread> </backtrace> <registerSet> <register name="CS" value="0x00000017"/> <register name="DS" value="0x0

Bridge won't write metadata; Photoshop will

I have some TIFFs created from scans. Here's the problem I'm seeing.
When opening the image in PS CS5 I often get a message saying This file contains file info data which cannot be read and which has been ignored.
First, I try to change some metadata in Bridge and save the image. Sometimes this solves the problem. Often, though, I get a message saying There was an error writing metadata to "filename".
Next, I open the image in PS simply clicking OK on the error message above. I open File Info, change some metadata and save the image. So far this has always solved the problem thus far.
The source of hte problem will likely not be easy to discover since the error message provides no useful information and since it is happening frequently, but not universally. At first I thought it was related to specific fields, but further testing seems to indicate it is not. Then I thought since another running application gave me a low storage message, it might be related to that. That does not seem to be the case either.
However, even if I don't find the root cause, it would be helpful if Bridge would simply rewrite the metadata to fix the problem rather than having to go into PS.
Any thoughts?
Dale

From
what you are saying the TIFF's are corrupt somehow. Open them in PS
and then save with another name and see it you can then write metadata.
For whatever reason Bridge may be more sensitive to the error than PS.
Can you change the scan to another format to eliminate the problem?
Granted the metadata is somehow corrupt. However opening them in PS and then saving them with the same name solves the problem, so it must rebuild the corrupt metadata fields.
I've scanned several hundred TIFFs and only had the problems on a few files. The only archival formats Nikon Scan 4 gives me are TIFF and nef and if I used nef ACR won't recognize the colorspace.
Dale

Fraser/Schewe RWCR Book - Sharpening Question

Real World ACR > Great book, good explanations. Compiling questions as I read and re-read. Need sharpening workflow guidance. Let's say I am working on an NEF file that ultimately I want to upsample or crop/upsample in Photoshop. Should I sharpen both in the ACR image detail adjustment phase and then do an USM in photoshop again when I am ready to save my final edit? What effect does upsampling in Photoshop have on image adjustments done in ACR?
MacBook Pro, OS 10.4.11, Nikon D300 NEFs, ACR 4.3, PS-CS3

>Pretty sure sharpening is done before the down sample in Camera Raw in the pipeline and the down sample is a Lanczos algorithm (see http://en.wikipedia.org/wiki/Lanczos_algorithm for geek explanation) which has a "degree" of sharpening in it.
Jeff,
Your Wikipedia link is indeed very geeky--It talks about recovering
Eigenvalues, but doesn't even mention resampling. Perhaps this link is more appropriate
Lanczos Resampling.
I have no idea whether ACR sharpens before or after resampling, but to sharpen before resampling seems counterintuitive, since it is often advised to sharpen after resampling to offset the loss of sharpness occasioned by the resampling. With significant downsampling the sharpening halos would be resampled out of existence. Perhaps the Lanczos algorithm obviates these concerns.

Need to open NEFs from D5100 in ACR.

I am trying to open raw photos from a Nikon D5100 in PS4. Cannot do it. I am told I need PS5. Must I purchase the PS upgrade (about $179) to CS5 or can I open the NEFs without additional purchase? If I need to purchase an upgrade, what exactly do I need to buy in order to view the images in PS and ACR? Thank you.
I have PS CS3 and CS4.

If you are going to upgrade hold off, CS6 will be out shortly.
In the meantime download the DNG as it is free and will work for you new camera. You will have to convert the NEF to a DNG.
If that freeks you out then keep the original on your backup drive.

NEF processing in Adobe Camera Raw (ACR)

I originally posted thin in the Photoshop forum and someone pointed out to me that there was an ACR forum.
How exactly does ACR 5.4 determine color for Nikon Nef files? Does Adobe use their own unique color profile for Nikon cameras?
I did the following tests with a D700.
I used the capture mode RAW+jpg fine. I took photos with the camera set to srgb and then to Adobe RGB 98.
I then processed the RAW files in ACR 5.4, once using srgb and once using Adobe 98. When opened in Photoshop CS4, the colors in the images do no look like the colors in the jpg files from the camera.
For the image shot with the camera set to srgb, if I process the RAW nef with ACR 5.4 set to srgb and open the processed NEF in Photoshop CS4 the colors are very different from the in-camera jpg, and there appears to be no way to get the colors close to the jpg from the camera. For the same image shot with the camera set to srgb, if I process the RAW nef with ACR 5.4 set to Adobe RGB 98 and open the processed NEF in Photoshop CS4, and then assign (assign, not convert) the processed NEF the srgb color profile, the image is very close to the jpg from the camera, which I verified by doing a difference.
For the image shot with the camera set to Adobe RGB 98, if I process the RAW NEF with ACR 5.4 set to Adobe RGB 98 and open the processed NEF in Photoshop CS4 the colors are very different from the in-camera jpg. If I now assign the profile srgb to the processed NEF, the result is very close to the jpg image from the camera (with Adobe RGB 98!).
This is very confusing.
Any explanations.

Thanks for your replies I do indeed want Adobe to read and USE the metadata. If so many others also want it, and if flags are set in the metadata,. it's surely not beyond the wit of a huge software house to read those settings and apply them.
I took the trouble to search through several threads and found no adequate explanation for why Adobe is disdaining the needs of its customers.
In many respects LR3 and PS12 aregreat products but they could be vastly more productive and useful to far more peolple if they improved workflow by using these settings. At the very minimum they could refrain from ignoring the preview jpeg - if Microsoft and Mac etc are able to display and print images correctly using the nef codec I fail to see why Adobe with all its expertise in imagery can not.
Nikon have a substaintial proportion of the DSLR ,enthusiast and professional market which are at the heart of Adobe's target audience. Why would Adobe wish to alienate such an important group of potential customers ?
Thanks - Alaeia

ACR 8.3 and D600 .nef Files

I'm using a Nikon D600, shooting with a flaat picture profile to create both RAW and JPG files.
I'm using: Adobe Bridge CC ver: 6.0.1. 6 x64 / Lightroom 5.3 / ACR 8.3 (I'm a CC user and I have all the current software available.)
I have alot of experience with the workflow of Adobe Bridge->ACR->Photoshop using Photoshop CS3 extended version. I'm not sure what the Adobe Bridge Version would've been, nor ACR.
Today, when I look at my .nef files in Adobe Bridge, they are heavily contrasted images. The .jpgs look flat, just like the profile I chose, but the .nef's look like a preset is being applied to them.
I've read the forums topics about .nef files and Camera Profiles, but I've never had to change any preset when I used Bridge->ACR->Photoshop in the past. However, I did go into Adobe Bridge->ACR->Camera Calibration and changed the CAMERA PROFILE to "Camera Neutral" and left the PROCESS as "2012(current)." The "Camera Nuetural" DID help alot. But is that all that is available- or am I missing something?
I thought there was (maybe) a problem with Adobe Bridge, since the images looked like the preset was applied even before I ever tried to open any of the .nef images. So I went into Lr and when I imported the images, they looked like I would expect them to- until I clicked on them. Then I could see the preset being applied. So, I went into Lr->Develop->Camera Calibration and the same 2 settings as mention above where there. So I left the PROCESS as "2012(current), and changed the PROFILE to "Camera Neutral". It helped alot, but is that all that I can do?
Is that all I can do? It seems like too much is being changed on the .nef files without me ever touching them.
Thanks for your help,
Cathey

Thank you Jim. I appreciate your help. I have seen the different profiles that can be applied and the Camera Neutral makes a huge difference in the .nef image (bringing it back to more of a flat image, which is what I wanted).
I have the same issue in Adobe Bridge, and I can select the Camera Neutral from there as well and it makes about the same difference as in Lr.
I've pulled up some older images that I shot with my D200 (I can't tell you what picture profile I shot with). It confirms what I remember from working with .nef files before I got my D600 and started using the CC versions of Lr & Br which is: The .nef files are, well... 'raw', while the .jpgs look 'refined'.
In my case (now) its the complete opposite. My jpegs look 'raw' and my .nef's are punchy, contrasty, bright....
I can't help but wonder why my .nefs are so changed when they're supposed to be raw files. Even when I apply the profile in Lr, or in ACR of "camera neutral" it still does not get me back to what (I believe) the raw image should look like. Why would a .nef look better than the .jpg when I haven't yet applied ANY setting to it. And, if it's the profile in ACR or Lr that is causing this to happen, then why doesn't the .nef image look at least as flat as the .jpg when I change it to 'camera neutral'?
You said that Lr generates its own preview of the raw image data. I guess I don't understand why, then, when I change the image in Lr to Camera Neutral, how come I still have a .nef that is considerably brighter, more contrasty than the original .jpg?

.NEF files not opening with ACR in CS6

I run CS6 on my iMac with OS 10.6.8 with the ACR 7.1 update downloaded and installed. When browsing my Nikon D600 images in Bridge, thumbnails for my .NEF files load initially, but some immediately change to the stock .NEF icon. None of my .NEF files open in PS and instead I get the popup telling me I need to get the latest version of ACR. No ACR update appears under Help>Updates>Photoshop. When I do all these same actions on my MacBook Air running CS6 with ACR 7.1 on OS 10.9.4, everything works fine, all thumbnails load properly in Bridge and all .NEF files open in ACR.
-Why does it work on my laptop setup and not my desktop?
-Is there a newer version of ACR than 7.1 or is it bundled in with the newer DNG updates? I also installed DNG update 8.3 (the newest that my OS will support) and there was no change.
Thanks

You need at least ACR 7.3 for the D600. Adobe stopped providing downloads after 7.1. They want you to use Help > Updates.
I'm not a Mac person, but I think OSX 10.6 might not support the latest (8.6) version of ACR. In which case, you could try this link:
http://swupdl.adobe.com/updates/oobe/aam20/mac/PhotoshopCameraRaw7-7.0/8.3.52/setup.dmg

After editing file in ACR 8.6 (Mac) , the file (NEF and XMP) modification dates are not updated

With both my Mac's, reset Photoshop C (2014) to previous version 2014.0. Now find that after editing file in ACR 8.6 (Mac) , the file (NEF and XMP) modification dates are not updated. Reloaded camera raw, etc., but still find modification dates are not updated, either using Finder or using Bridge to view dates. Editing other files, PSD, DNG, TIFF, etc., are updated and the information is correctly displayed.

Ok, not entirely sure what I did but it's now working (Bizarre!). The only thing I did was 'eject' the ACR 8.6 .dmg file from the finder side bar and restart PS CC, so that may have been where I was going wrong all along!
However, I now have another issue in that there is no preview of the shot in Finder on my iMac when I highlight the NEF file. I assume this is simply because Apple haven't yet released an update for the new D810 NEF files and so the computer doesn't know what it's looking at?!?
If anyone has any other ideas though, then I'm more than willing to listen.
Thanks again.

Time to export/save one D2X NEF to JPG Aperture vs. Bridge/ACR

15" PB, 1.5 Ghz, 1.5 GB RAM, running Firefox, Entourage, while each app is running test.
Single D2X NEF in an Aperture project:
-No sharpening applied, export to JPG 11 seconds
-Any sharpening applied, export to JPG 29 seconds
Single D2X in a folder in Bridge, open in ACR
under Bridge:
-Any sharpening or not, save to JPG 15 Seconds
Note, while Aperture exports, the entire app is tied up. Bridge does the saving in the background, which allows you to continue working in Bridge/CS2

I have not run that test, but I did do Aperture batch versus CS(1) batch...
Basically, when I'm batching from CS RAW -> JPEG, my dual G5 turns 12 images per minute. When I "export" from Aperture (which might as well be a "batch," it's doing the same function), I get a little over 13 images per minute.
Frankly, I almost never sharpen when coming from RAW. I prefer to make a highly selective sharpening pass later after going to JPEG, sharpening only those that need it the most. I'm not a big believer in sharpening, due to fact that I have no control over how image will be resized, and sharpening prior to a significant resizing is pointless in my experience... and despite all the talk about how digital images are soft compared to film (due to the built-in sensor filter) I don't really buy that. I don't remember film being so dang sharp.... with the L series glass I'm using and 8.2 megapixels, this stuff looks as freakin' sharp as 35mm film ever did to me... now I will concede that medium format film has a certain sharpness advantage, but 35mm??? Maybe Kodachrome on a tripod, but probably not an ISO 400 print film hand held at a wedding reception... I digress.
Now I'm going to go run your sharpness test to see what I can see, seeing as how I finally upgraded to CS2 this week.

PowerMac DP 2 Ghz vs 15" Powerbook & Aperture vs Bridge-ACR and 10 D2X nefs

10 D2X nefs, equal settings(including sharpening) on each file.
Test: Time the export/saving 10 full sized JPGs(level 10) on both systems under both Aperture and Bridge/ACR
In Aperture, stamp the same settings to 10 nefs, wait for the changes to appear on each thumbnail, then select the 10 nefs, and select export versions.
In Bridge, paste the camera raw settings to the 10 nefs, wait for the thumbnails to show changes(building cache), select the 10 nefs, open ACR under Bridge(not CS2) by pressing CMD-R, in the ACR dialog, select all images on the left, click "Save 10 images".
PowerMac: G5 dual 2 Ghz, 2 GB RAM, X 800 XT vid card, Aperture library and Bridge cache on separte SATA 7200 RPM internal disk
PowerBook: 15" 1.5 Ghz, 1.5 GB RAM, ATI Mobility Radeon 9700, and 80 GB disk
Aperture results:
PowerMac: 2:07
PowerBook: 5:06
Bridge/ACR results:
PowerMac: 1:18
PowerBook: 2:12
As you can see Aperture requires 2x the time to export/save when compared to Bridge/ACR.
Further, it is amazing that the Powerbook could plow through the images in Bridge in the same time it took the Powermac to export the Aperture images...
Hmmm, then that would imply the best money is on a Powerbook running Bridge/ACR/CS2?
Sooooo, if you can cull/sort the images and apply raw settings in Aperture three to four times as fast as in Bridge then it is a wash...

zozi56 wrote:Can you reproduce the problem without Skype, Bastian?
From what I remember I have also had this issue when Skype wasn't open.
Yesterday my computer started up beeping - I took the harddisk out and it started normally (initramfs tho). Then I put it back in and the laptop have been running fine so far. I suspect it might just have been a bad connection, but I am giving it time..
EDIT: Still experiencing the issue..
Last edited by Bastian (2014-01-19 18:09:08)

ACR 7.3 suddenly won't open multiple NEFs from bridge

Suddenly today, when I select multiple NEF files from the bridge (updated pc, cs6) .. the ACR opens ONE file at a time. The bar to the left isn't there showing me all of them. When I close ACR another window pops up with the next image I had selected. What setting is messed up or what can I do?!? I have rebooted.

I swear I looked really hard for that handle, am aware of it and thought myself it had to just be hidden but if that was the case, clicking to say I was "done" would NOT have opened up more individual ACR windows, each one with the next image that should have been opened in the first place. So it wasn't the handle/bar just being hidden.
I did a system restore back to before a java update. Not sure if that update had anything to do with it, but the restore point did the trick, the first attempt at ACR opened multiple images just like it should have .. so.. problem still a mystery, but it's working now.
thank you for the suggestion.. I'll still watch to see if others answer.. sure was weird

ACR 8.5 and Nikon NEF: in Photoshop and Lightroom

Today I was on Nikon presentation. A manager from Russian office sad that Nikon gave Adobe some information how to open NEF files CORRECTLY in ACR, but that algorithms can be used ONLY in Photoshop, not in Lightroom. Is that true or fake? As I know, ACR for Ps and Lr is the same in case color reproduction (and has some differences in image correction).

To compare PS/ACR with LR, if you have both products, you can do an Export a TIF from LR and do a Save Image TIF from ACR, using the same parameters, and then open both in PS and layer one on top of the other, set the blend mode to Difference, merge the layers, and see if you have anything besides 0s for the pixel values of the combined layers. You could stretch the image in Levels to make finding any non-zero pixels, easier.
It has been said, above, that LR 5.x versions had a bug where they did not apply noise-reduction or sharpening in some situations during the Export so its important to understand what precise versions of the products you're talking about. Intending for the raw-conversion algorithms to be the same, and a coding error making them not so are two different things. In other words the mathematics would be the same, but the implementation in a different programming language by different people could have coding errors.
As far as which of Nikon Capture or Adobe Lightroom/PS-ACR is better, the words someone says or writes are a fact if you have the recording or original documents, but the idea they are communicating is an opinion and you can really only list pros and cons for someone else to draw their own conclusion, and unless you're quoting word-for-word, your interpretation of what is being said is also somewhat of an opinion, yours.

NEF + ACR = HOPELESS

Similar Messages

Maybe you are looking for