Camera Raw 5.6 - ISO speed is incorrect in EXIF data.

Shooting with a Nikon D3S at ISO's above 25,600, the EXIF data reports 36,000 no matter what the actual ISO was when the shot was taken. Do not know if this is Nikon writing the wrong data to the EXIF or ACR 5.6 interpreting it.

function(){return A.apply(null,[this].concat($A(arguments)))}
function(){return A.apply(null,[this].concat($A(arguments)))}dbcdon wrote:
Shooting with a Nikon D3S at ISO's above 25,600, the EXIF data reports 36,000 no matter what the actual ISO was when the shot was taken
I don't have ACR 5.6, but the DNG converter converts ISO 102400 to 36864; ISO 51200 should be correct. The reason is, that 102400 is the first full stop ISO over 65535, the limit for an USHORT field value. Time to change the declaration to ULONG.
However, there is a big problem: while the ISO specification in the NEF file is in Nikon proprietory format and it can grow for a long while, the ISO in the Exif format is unsigned 16bit value, it can not be expanded; a new field needs to be defined (expanding the existing field may cause havoc under older programs).
Gabor

Similar Messages

Why does adobe camera raw keep saving images with the incorrect white balance?

I am having an issue when I edit images. here is the scenerio:
I choose 50 Raw files and open them in Camera Raw.
I edit each individually - many of them have different white balances.
Once I have each image how I want them, I select all and click done.
Sometimes all the edits are saved correctly, but very often all the changes are saved correctly except white balance. The program seems to take the white balance from one image and applies it to all the images.
Why??? Very frustrating to have to go back and individually edit all the white balances again.
Thanks!

It seems to not happen if I slow down a few seconds before I click select all and then done.
That should not be the problem, once you changed settings and hitting done they all should be applied immediately. It even is not needed to first select all, that is only needed when you need to open or save the files.
But I still don't know why it would only change the white balance in every shot and not everything.
If it happens again could you first in Bridge select one of the none changed files and with right mouse click menu choose select purge cache for selection?
And can you provide more details about system version, app versions and file types?

Aperture incorrectly duplicating exif data - how can I stop this?

The situation...
a) I have 2 cameras (Canon 5D, and a Canon 5D MII)
b) I imported photos from 2 Compact Flash cards (1 from each camera) where the file names (e.g. _MG_9670.CR2) clashed. (i.e. both cards used the same file numbering range)
c) Aperture imported the images correctly, however the EXIF data on both images match identically apart from image resolution. Aperture believes these photos were taken at the exact same date/time and with the same camera which of course is incorrect.
d) If I export the original files from aperture and use the finder 'Get Info' option I can see that the RAW files contain correct EXIF data, so the issue must purely be an aperture bug.
Question - is this a known bug and is there any way to work around this?
Unfortunately I have spotted this on some wedding photos I shot for a client so I have had to switch to Lightroom for some confidence in not loosing important photos. Hopefully if someone can provide a workaround before I get stuck into my editing I can switch back to Aperture that I am more familiar with.
Thanks
Adrian

Interesting problem. The duplicate filenames could be causing Aperture to get confused but I've never seen this myself. Do you have Do not import duplicates set in the Import pane? If it is not set and you set it does Aperture see the files on the second card as dups?
As a test, when you import from one of the cards (either one) rename the originals. Does the EXIF problem still happen? If not then you will need to rename one of the cameras files either on import or in the camera. I believe Canon allows you to set a filename no?
Also make sure to file a bug report with Aperture, Aperture->Provide Aperture Feedback, look for the bug report entry.
If renaming the files does not fix the problem post back.
regards

Why are no Pentax lenses in the Adobe Camera Raw lens profiles when processing JPG files?

I normally shoot and process raw files and use the latest version of Adobe Camera Raw for processing. Some of these files are converted to jpg for use on the net or e-mailing etc. Sometimes I want to make minor changes to the now converted jpg file and often go to Adobe Camera Raw for ease and speed of use. Lately I have gone back to some files that were not thoroughly processed as raw files before conversion to jpg. When, in ACR, I go to Lens Corrections panel, Profile tab, I Enable Lens Profile Corrections and choose Setup: Auto (or Default) and get the message, "Unable to locate a matching lens profile automatically".
I then go down to Lens Profile and click on Make with the intention of choosing the Pentax lens which I used for the photo. Here is the problem - there are only six choices under make, namely Apple, Canon, Nikon, Sigma, Sony and Tamron. I have no such issues when processing a raw file in Adobe Camera Raw. Pentax lenses are automatically detected and Pentax, along with Leica, Samsung, Zeiss, etc. are choices under Make of lens.
Do other people have this problem? Is there some setting I have missed? Is Adobe just not permitting some makers' lenses, for which there are profiles, to be corrected if the files are jpgs?
BTW, I have checked and the same issues exist for tiff files opened in ACR.

Assuming I read your post correctly, and that you're trying to use Lens corrections on JPEGs and TIFFs... I believe there's a completely different set of profiles for correcting already "developed" images (such as JPEGs and TIFFs). If I recall correctly (and it's been a while since I read about this), it's the same set that's used inside Photoshop for the Filter - Lens Correction tool (I hope someone here will correct me if I'm wrong, but I'm sure I read this somewhere).
If your lenses are known to Camera Raw when you develop raw files, I suggest you will need to go all the way back to your Raw file and reprocess it from that stage. You'll get a better result anyway.
-Noel

PSE 8 compatibility with Adobe Bridge CS 5 Camera Raw

I have Photoshop Elements 8 installed with Camera Raw 5.5 on a Windows 7 64-bit platform. I recently purchased Photoshop CS 5 which came with Camera Raw 6.2. I think both products work well independently, with the exception noted at the end of this posting. Where I'm encountering an issue is when I use Adobe Bridge to access an image file for processing which invokes Camera Raw 6.2. -- the changes made to the file show up in Adobe Bridge, but are not observable when the same file is viewed in the Photoshop Elements Organizer. When I look at the file properties I can see that Camera Raw 6.2 updated the file and the updated date does appear in the file properties accessible through PS Elements Organizer. However, the items listed in the Camera Raw metadata are different in the two products (PS vs PSE). Since the sidecar .xmp files are a form of XML, I'm wondering if Camera Raw 6.2 is writing data in a structure that is not supported by Camera Raw 5.5? I've tried to update PSE Camera Raw to version 6.2 following the instruction that appear on line, but it does not seem to install. Durring installation there are no error messages, but after the "installation" PSE Camera Raw still shows version 5.5. I noticed this first when editing a large number of "legacy" .jpg files, but I also have concern when editing Nikon .nef files.
It's a bit hard to tell, but when editing .nef files in Camera Raw 6.2 the changes may migrate to PSE once I tell PSE to update the thumbnail view. But what I observed was a very distinct differece in file's visual appeared when viewed in Adobe Bride CS5 vs PSE 8 Organizer. The PSE 8 images had greater color saturation. This leaves me wondering what's going on.

On my Windows 7 64 bit system the original version of Camera Raw.8bi was found in:
C:\Program Files (x86)\Common Files\Adobe\Plug-Ins\Elements8\File Formats\ and had a size of 11,781 Kb shown in Windows Explorer. The file properties listed the size as (12,063,088 bytes). The digital signature was signed Thursday, September 03, 2009 3:34:37 PM. To the best of my knowledge this is the version that shipped on the PSE 8 disk which I installed in December 2009.
There is another copy of Camera Raw.8bi found in:
C:\Program Files (x86)\Common Files\Adobe\Plug-Ins\CS5\File Formats\ and had a size of 11,856 Kb shown in Windows Explorer. The file properties list the size as (12,140,496 bytes). The digital signature was signed Friday, August 20, 2010 3:30:03 AM. This date post dates the installation of Photoshop CS 5 on my system so it must have happened through some (automatic?) update.
The Camera Raw.8bi file that I've down loaded from Adobe for ACR 6.2 is the same size and has the same signing date as the one identified immediately above in the CS5\File Formats\ sub folder.
When I copy the down loaded file into the Elements8\File Formats\ sub folder PSE still indicates that ACR is version 5.5
I also have a copy of ACR in C:\Program Files\Common Files\Adobe\Plug-Ins\CS5\File Formats\ with a length of 14,526 KB shown in Windows Explorer. The file properties list the size as (14,874,576 bytes) and the signing date as Friday, August 20, 2010 10:39:07 AM. I presume this to be the copy of ACR used by Adobe Bridge and Photoshop which I installed as a 64-bit application. Since the signing date (but not the time) is the same as the date for the file in CS5\File Formats\ I'm guessing that it is also the result of an automatic update to version 6.2.
Something that's not making sense to me is that the down load was approximately 50 MB and I'm messing around manually moving a 12 MB file into a specific sub folder.

Significant reduction in file size from Camera Raw to DNG

Hi,
I am currently testing the conversion of Leaf camera raw files into DNGs for a photographer's archive. I am hoping to convert all of the mos files to DNGs because Leaf Capture and the Leaf Raw Converter are not being updated and because the photographer wants to have an Adobe centered workflow. In my testing I discovered that converting mos files to DNGs through ACR 8.4 and LightRoom 5.4 resulted in a reduction of file size by nearly 50%. A 44.5MB mos file became a 23.6MB DNG. From what I've read only about 15-20% of the camera raw file should be lost and all of the data lost should be propietary.
Here-in lies my quesiton, is there any way that I can track or determine exactly what sort of compression is being done to the mos file and what information is or is not travelling in the conversion to DNG?
These are the settings I have used for converting raw files to DNGs:
ACR:
JPEG Preview: Medium Size
Embed fast load data
Don't use lossy compression
Preserve pixel counts
Don't embed original
LIGHTROOM 5.4:
Only Convert Raw files
Delete originals after successful conversion
File Extension DNG
Compatibility Camera Raw 7.1 and later
Jpeg Preview Medium Size
Embed Fast Load Data
Thanks!

50%? - I thought we were talking about 15-20%?
In my first post I questioned why I was seeing a reduction in file size of 50% when according to forums and articles I've read I should only be seing a 15-20% reduction in file size. I then wondered what data I might be losing, which you addressed.
Same as what? - what were the results.
I was referring to testing I preformed on camera raw files produced during different years (all mos). I converted all files with the same ACR and LR settings and found that the DNGs always reflected a 50% reduction in file size. This test suggests that any conversion issues is not necessarily related to how the camera raw files might have been differently built across years.
Adobe's raw data compression is touted by DNG zealots, but I haven't scrutinized it enough to corroborate or refute.., but my experience is that reduction is relatively marginal. All of this assumes original is also compressed - if uncompressed in original source, savings would be large.
The files I am dealing with are definitely uncompressed which could account for the large reduction in file size. I didn't realize until I posted to this thread that converting to a DNG results in a compression of the original image data. I understand that this compression is supposed to be lossless like a lossless compression to a tiff and thus result in no decrease in image quality or harm to the original image. I am baffled by how it is possible that any compression of a file (especially by 50%) could not result in a loss of important data but I will accept that it is possible to have a truly lossless compression and that the size reduction I am seeing could be a result of all of the different processes a file undergoes that you have outlined.
I looked into the effects that backwards compatibility has on the conversion process which might interest you http://dpbestflow.org/DNG#backwards-compatibility
I also posted to luminous landscape's forums http://www.luminous-landscape.com/forum/index.php?topic=89101.new;topicseen#new
Although it wouldn't surprise me if the DNG conversion process tossed the xmp-like metadata, and kept the original stuff, but it would surprise me if it tossed the original stuff - but as I said before, I haven't scrutinized for completeness so I don't know.
I've done testing in which I converted .mos camera raw files with their sidecar xmps and without their sidecar xmps. My tests revealed that the DNG definitely carries over xmp metadata although it is not clear to me exactly how it is carried and if anything is lost.

P65+ RAW files with camera RAW - Not yet

Folks,
I'm just wondering if I'm alone here cos I can't find any mention anywhere online. Just had a shoot come in froma photographer (I'm in an ad' agency and we get all types of files from various photographers) shot on a P65+ back. The RAW TIFs are about 55MB each and when I bring them into to Photoshop or Lightroom to process the image to photoshop for retouch, it shows the four sensors from the camera back.You can just see it at this size, (client confiedential prodcut shoot I've had to blank out)
A close up shows the centre of the four sensors...
My workaround is to go back to CaptureOne and process the files to DNG, then bring them into Lightroom, but my DNGs become 110MB, twice the size the original RAW.
I know it's a fairly new digital back, but surely I'm not alone with this problem? Cos that would be really lonely ;-)

Mark Kenny wrote:
I know it's a fairly new digital back, but surely I'm not alone with this problem? Cos that would be really lonely ;-)
Correct...as far as I know, Phase still needs to get certain info out to Adobe in order to address the 4 quadrants. As I understand it, there are actually 4 "pipelines" of data being pulled off the chip. Think of them as arrayed data streams...none of them is gonna match "exactly" so Phase tucks calibration data in the file. Camera Raw can (as far as I know) read the data from a P 45+ so I don't think it's a question of if, but one of when...it didn't make the 5.4 update, maybe it'll make the next one (I don't actually know).
However, depending on the camera in use, you may indeed want to do the tiff > DNG conversion to take advantage of the Lens Correction capabilities of Capture One. I use a Phase 645 with Phase lenses that benefit from the DNG conversion.

Camera Raw 6 - Question

I hear Camera Raw 6 is around the corner. Cool!
I wonder whether any fundamental change has been made to change the way it responds to partial overexposure... With my Canons at least, all the current versions of Camera Raw desaturate colors as soon as one of the color channels saturates. Since we know that Canon's AA filter is bluish-green, this makes it highly likely the green and blue channels will saturate (max out) first before red. As it should be, Camera Raw tries to recover at least some of the data using the red channel.
So, for example, if the green channel saturates, the subject will turn kind of gray instead of leaving the blue channel alone and having it be bright yellow. Here's a graphic example:
A long time ago I recall corresponding with Thomas Knoll on this and I believe the thinking was that if the color can no longer be accurately determined because of one or two channel overexposure then the color will be desaturated so that it will not shift, and in a sense be made inaccurate. I recall thinking that gray is a color too, but Camera Raw is what it is.
This philosophy may work fairly well for clouds in the sky, but it's not so good for some other things. I think it also negatively impacts the way HDR images are assembled in many cases, as bright things end up with gray halos that don't mix well at all.
Any chance there's an option in ACR 6 to disable this desaturation behavior? If not, could we please have one in the future?
Thanks.
-Noel

Thanks for your input, Curt, but I'm quite some distance beyond a basic understanding of the Bayer pattern at this point.
Re your comments on when new versions of Camera Raw are prepared, they are still adding features actively. Camera Raw 6.1 specifically is the version I've heard is nearing release.
I'm hoping someone from Adobe with a significant depth of understanding of the innards of Camera Raw might comment on this.
-Noel

Camera Raw/Mac image update problem

I am a new Mac user. When I adjust an image in Camera Raw (I have Photoshop CS4 and most up to date Camera Raw) and click the Done button my image is updated in Photoshop, Bridge and Camera Raw, however if I go into Finder on my Mac the preview is not updated and if I open the file in, say, Picasa, the original file is opened. If I click the file and open it in Bridge, the edited file opens. How do I get it so the preview is updated and the edited file is opened in programs other than Photoshop?

Editing in ACR is non-destructive (the original image data is not modified) and the edits are carried in either a sidecar file or database, depending upon your settings. Only ACR/Bridge/Photoshop (and Lightroom) will "see" the edits, therefore the original non-edited image will show when opening in another program.
One can save directly out of ACR in a variety of formats, which will them incorporate the edits and make them visible to other programs.
Richard Southworth

Saving IPTC in Camera Raw

I am creating IPTC data in Photo Mechanic and using Photoshop/Camera Raw 7 to edit and color correct those images. But when I attempt to save, the resulting .jpeg images do not have the IPTC data I wrote. I know it is possible, because this was my workflow in previous versions-the IPTC data also came through in one image. Why is this different in Photoshop CC and Camera Raw 7? How can I get my IPTC data through the edit and save process?

Had the same issue, found the solution in Photo Mechanic. I use the cmd-shift-i (ctrl-shift-i) command and fill in the IPTC fields, this works fine. Using the global IPTC (cmd-i / ctrl-i) doensn't work for me.
cheers
Lars

Export of RAW files loses EXIF data

I am having a problem when I export files out of the PSE Organizer from RAW format to JPG that I am losing EXIF data on the resulting JPG file.
I am using PSE 6 on Windows Vista and primarily manage my images in RAW format (Nikon D300 NEF) within the Organizer. I am using the latest Adobe Camera RAW plugin ver 5.1 but I have tried this with the last three Camera RAW plugin versions without any difference.
I typically need to get the RAW NEF images into JPG format to post them to my blog so I normally select several NEF files at once within the Organizer then CTRL-E (or File, Export, As New Files), select JPEG, then Export.
The resulting JPG file has no EXIF data for the camera (e.g. Camera make, model, f-stop, exposure, etc) that was on the original NEF file. I am determining this by right-click, Properties, Details on the file within Windows explorer.
Other tests I have done to diagnose this are:
1. Opening an NEF file in Full Edit mode from the Organizer then doing a File, Save As (JPEG), the missing EXIF data *does* get saved properly. The problem with this approach is that it is not suitable to export hundreds of NEF files.
2. I downloaded a trial version of PSE 7 and it behaves identically to PSE6 in this test.
3. I downloaded a trial version of Lightroom 2 and the export feature works properly in this test.
Any help would be appreciated.
Baden Smith

My observations of what is happening is exactly what you are seeing with one exception about the XMP update. My reply that I posted about seeing the XMP file being updated was based on the observation that when I did a File > Write Keyword Tag the time and date changed on the XMP file as seen with Windows Explorer. I also looked inside the XMP file with a text editor and saw the updated comments and tags inside. See this section of the XMP file that shows the comments and tags: ------------ <rdf:Description rdf:about="" xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:creator> <rdf:Seq> <rdf:li>Baden Smith</rdf:li> </rdf:Seq> </dc:creator> <dc:rights> <rdf:Alt> <rdf:li xml:lang="x-default">Copyright - Baden Smith - All Rights Reserved</rdf:li> </rdf:Alt> </dc:rights> <dc:description> <rdf:Alt> <rdf:li xml:lang="x-default">Fishing boats sailing by our balcony at dawn in Zanzibar</rdf:li> </rdf:Alt> </dc:description> <dc:subject> <rdf:Bag> <rdf:li>Africa</rdf:li> </rdf:Bag> </dc:subject> </rdf:Description> ------------ My original question posted was about the export to JPG and not seeing the camera EXIF info being exported. Do you know if this is configurable or is a bug? Baden

Lens incorrectly recognised following update to Digital Camera RAW 4.03

I have a Canon 5D II and use a Sigma 12-24 DG HSM II lens with it.
My lens used to be identified in Aperture 3 as "Unknown (137) 12-24mm' until I updated to the latest Digital Camera RAW Compatibility 4.03.
Now the lens is incorrectly identified as Sigma 8-16mm with 1.4x converter.
Has anyone come across this issue or knows how to resolve this?
Using other softwares, the lens gets correctly recognised as 12-24mm.

I'd suggest you use Aperture's "send feedback" mechanism to report this.

Camera Raw 7 Speed - Can We Hope for GPU Acceleration?

Photoshop CS6 in general in my environment seems about as fast as CS5 and better in some ways, but Camera Raw 7 is slower than Camera Raw 6.6. This is not unexpected, given that the process is more sophisticated, but my question is this:
Now that we see that Photoshop in general, with the MPE, is able to use OpenCL on capable GPUs, will we be seeing Camera Raw make use of OpenCL to achieve faster screen updates, and ultimately faster overall conversions in the near future? In a 7.x update perhaps?
The competition does it.
-Noel

Back off? I should heed your expert advice on avoiding confrontation, Jeff? I have to assume by your unwavering support of Adobe on this issue that you are looking forward to having stylish artifacts like these in your own images. I guess this will define your new style for 2012. LOL
All the slack that's going to be cut on this has already been cut.
Hey, I could have just quietly dropped back to 7.0 and just have my own images be superior to those made by those using 7.1, but no - I chose to try to help Adobe by pointing out a problem to them here.
When I reported this problem during the beta, I was clearly ignored. When I reported it again after the release, I was argued-with.
I don't need to be argued-with nor reasoned-with - Adobe needs to listen to people who know what they're talking about. People not blindly praising the emperor's new clothes.
I don't need nor expect appreciation, but I had thought I might have earned enough respect around here that Adobe's first response wouldn't be "choose different settings, stupid".
An output image quality problem should be a release show-stopper. Experts like me and Vit telling Adobe that their latest color fringing reduction changes aren't working well enough should be considered seriously. Instead, it's just business as usual: Release whatever's in the pipeline.
Adobe's dropping quality standards are something I find myself wanting less and less to be associated with each passing day.
Just typing this message took me longer than it should have, because of this bogus forum software.
There's a difference between leadership and "too big to fail" thinking.
This is my last post in this thread. Thanks for your participation.
-Noel

Does anyone know when there will be Camera Raw Support in Lightroom 3 for the Olympus E-PL2?

Just bought the Olympus E-PL2, shot some test shots and came home to open my RAW files to view them and discovered that they won't open in lightroom because the .ORF files for the E-PL@ are not supported. I figured since the E-PL1 was supported this would be too.There are some minor differences between the two like base ISO, etc. I am new to RAW and notices that E-PL1 users experienced the same thing when it first came out. How long does it usually take for Adobe to get new cameras compatible with Camera Raw? The camera is very popular and I imagine people will want to use the program to process their files. Will that speed up Adobe's process? And in the mean time, does anyone have any suggestions on what program I can use to open my .ORF raw files?
Thank you in advance,
Anthony

It isn't a plug in. It is a tool that allows you to read and write to the Exif data. See the web site for how to use
Keep a copy of your original files. It doesn't cause any problems changing the camera maker name.Usually this is the only thing that has actually changed between each version of the same camera in the RAW file. However until this has been checked by ADobe and they have created a specific colour calibration it Adobe don't support the format. This does not prevent you hacking the format as long as you understand what you are doing and that you keep original copies to import once Adobe support it
If manufacturers used DNG there would be no problems, but until they do you may have to wait for up to three months for Adobe support. However Adobe do usually issue a RC of the next version of LR and ACR before the full update, that may be any time now. Certainly there is a beta version that includes support for this camera as it has been used by reviewers

Current Lightroom / Camera Raw Camera Profile for Sony ILCE-6000 inaccurate: green cast in shadows! Capture one better! Please fix it!

Hi folks from Adobe!
Please take note that the current Lightroom / Adobe Camera Raw Camera Profile for the Sony ILCE-6000 is very inaccurate: There is a serious green cast in the shadows!
Capture One Express for Sony (which is free by the way) renders a lot more correctly!
Please correct this, since I'd rather buy the coming LR6 because of keeping my established workflow instead of going the Capture One route.
A good example can be found in the dpreview forum "LR5 A6K shadow pulling, a mess! Adobe LR is broken? "
Or search for Philp Reeves 3 weeks with the Sony A6000 review "3 Wochen mit der a6000", where he compares it to the Sony A7, using both times Lightroom to push the shadows.
The Sony A7 is fine where earth looks like brown earth, the A6000 picture looks like grass instead.
Please fix this! This is a high volume camera frequently bought by enthusiast or as second body for FF photographers. That would be really great!

I am talking about the two raw files linked in the very last post of page 6 of the Reeves comparison thread, not JPGs or screenshots of unknown manipulation. In LR they both say f/11 and ISO 100 and have a similar tone, but one is shot at twice the shutter speed as the other. This side-by-side is using Adobe Factory Defaults for each image where the profile is Adobe Standard, the toning sliders are all 0, tone-curve linear, and the Sharpening and Color NR are 25:
However, when I look at the camera-embedded JPGs, side-by-side, the 1/80th image on the left is darker than the 1/40th image on the right, as expected given the reported shutter-speed difference:
And it is indeed the darker image that has more shadow problems, also as expected.
When I do manipulate the darker (a6000) raw file in LR, I do see that the shadows are greenish when brightened unlike most other cameras which usually show magenta, which is the combination of the blue and red sensors showing more noise because there are half-as-many photosites as compared to the green, so I am seeing what people are complaining about and would expect shadow noise to be purple not green, I'm more concerned that these two example raws aren't actually comparable due to apparent differences in exposure. It is also odd that the lens listed in LR is different than the lens listed in the filename, so either someone has mistakenly or deliberately renamed the file wrong or someone or something has changed the EXIF parameters that LR is reporting to be the same when they're really not.

Camera Raw 5.6 - ISO speed is incorrect in EXIF data.

Similar Messages

Maybe you are looking for