Adobe ACR showing raw IR images as being over exposed

[Donald]

Is anyone else getting this problem ...........

Since the last update of CC, I've got this problem. I use DxO Photolab to process my raw files. But, when I convert them to .dng or otherwise take the raw file into ACR, the 'blinkies' show up, indicating over-exposure. Adjusting the Exposure slider suggests that I have over-exposed by anything between 0.60 and 0.95 stops.

I have not and when I ignore what ACR is telling me and go into Photoshop, the file is, of course, properly exposed.

It never used to do this. It has just started since the last update.

[DanK]

Very puzzling. Did you check to see whether the histograms look the same in ACT and Photoshop? And does the histogram in Lightroom indicate that there should be blinkies?

I just tried this with an overexposed image, one that I took in a series with exposure bracketing. The blinkies showed up in Lightroom, as they should. The histogram was identical in Lightroom and in Photoshop.

This suggests to me that the problem may have something to do with how you move the file from DxO to ACR, but since I don't have DxO, I can't experiment.

[Donald]

Very puzzling. Did you check to see whether the histograms look the same in ACT and Photoshop?

They are different. The Photoshop shows the image correctly exposed

And does the histogram in Lightroom indicate that there should be blinkies?

I don't use Lightroom

This suggests to me that the problem may have something to do with how you move the file from DxO to ACR.

That's what's most annoying, because I have not changed anything in terms of how I move the files and it, previously, never had this problem.

In itself it is not a huge problem. I just ignore it when I first go in ACR. Once I have then taken it into Photoshop, worked on it, including the B & W conversion and go back to ACR (as a filter) to correct B & W points, add Clarity or one of many adjustments available, the problem is 'cured'. It is a very odd situation.

[DanK]

I don't use Lightroom

Sorry. I meant ACR. Same processing engine.

[Donald]

Sorry. I meant ACR. Same processing engine.

In that case, Yes. The histogram shows that the image is 'blown', which as I say, it's not.

[Manfred M]

My understanding is that the algorithms that indicate over and underexposure in ACR / Lightroom (and Photoshop) are nothing more than indications that a group of pixels show a pure white (or black) value. It doesn't show up every individual pixel, but is only triggered when there are enough white pixels that are in close proximity to one another to trigger that response. Change the rule and the system will report blown out areas differently.

I suspect that this was likely a known and reported bug that Adobe "fixed" in its most recent update and that's why you see it. None of the software you are using can tell that these are IR shots, but IR shows up as a light gray to white tone in the way you are handling the images.

This change probably has little effect on how images are displayed on screen, but might be useful to us printers. Ink jet printers tend to print any values from around 243 - 255 as white; i.e. deposit no ink, which results in "bald" patches on the paper. By being more sensitive to how blown out areas are shown, the photographer is likely to tone down the white area and this would result in the printer depositing a very, very light gray on the paper, eliminating the bald areas. It would be interesting to know if you see any difference in what your prints come out like in those areas.

[george013]

In that case, Yes. The histogram shows that the image is 'blown', which as I say, it's not.

Sometime there's a threshold. Look for that.

George

[revi]

Does ACR apply some treatments on opening a raw file, especially a tone curve to transform the linear RAW data
into something more pleasing, or closer to what the camera jpeg would show?
Some of those curves tend to compress the highlights a lot (too much for my taste).

As an example, with Darktable and the standard Sony curve, it looks like I over-expose by ~1EV, where there is no
over exposure in the RAW (DT has an option to show where the RAW data clip, not just the processed data)

[Manfred M]

Does ACR apply some treatments on opening a raw file, especially a tone curve to transform the linear RAW data
into something more pleasing, or closer to what the camera jpeg would show?
Some of those curves tend to compress the highlights a lot (too much for my taste).

As an example, with Darktable and the standard Sony curve, it looks like I over-expose by ~1EV, where there is no
over exposure in the RAW (DT has an option to show where the RAW data clip, not just the processed data)

The default import curve setting for ACR is "linear", so unless the user changes that, the issue that you mention should not occur. The default profile is "Adobe Color; in my work I have replaced that with a custom .dcp profile I have generated with my x-Rite ColorChecker Passport.

The only changes that ACR makes to the imported file, based on the defaults is import sharpening (quite low) and noise reduction, which is also a low setting

[Donald]

The only changes that ACR makes to the imported file, based on the defaults is import sharpening (quite low) and noise reduction, which is also a low setting

Which you can zero in both cases, particularly if you processed in DxO which, in my view, does a much better job of the same things.

[DanK]

One way to narrow this down might be to take one image and bring it into ACR without using DxO first. If that is unproblematic, then the problem has to lie in something DxO does, perhaps inserting some metadata that the newest version of ACR doesn't handle correctly. On the other hand, if you encounter the same problem opening an unedited CR2 file, that would suggest that there is something wrong with your current installation of ACR.

[Manfred M]

Donald - what about exporting to Photoshop from PhotoLab as a 16-bit TIFF, which lets you take ACR right out of the equation?

[Donald]

Donald - what about exporting to Photoshop from PhotoLab as a 16-bit TIFF, which lets you take ACR right out of the equation?

I could do that indeed, I just like the idea of going with the .dng, which previously worked fine. But I do think your suggestion is the best way around it.

[george013]

In that case, Yes. The histogram shows that the image is 'blown', which as I say, it's not.

I still don't know what you see. If you see blinkies are the pixel values the max/min value? And if so all the channels or just one.
I didn't find any reference to a threshold so that might not be the problem here.
From a Dutch manual. ACR shows the overexposed blinkies when one of the channels is 255, and shows underexposed blinkies when all the channels are 0.
DxO shows the individual channels but it's impossible to read the pixel values directly. Shame

George

[odds]

...I just like the idea of going with the .dng

Is it possible that the over exposure indication is caused by a profile or preset being applied to image data somewhere in the path between the applications?

The "rule" for indicating over exposure, like a threshold value and the number of neighboring pixels exceeding the threshold, should not change the histogram as such. (Or should it?) You indicated different histograms if I understood posting #3 correctly. A profile or preset applied to image data could change the histogram?

--
Odd S.

[Manfred M]

I still don't know what you see. If you see blinkies are the pixel values the max/min value? And if so all the channels or just one.
I didn't find any reference to a threshold so that might not be the problem here.
From a Dutch manual. ACR shows the overexposed blinkies when one of the channels is 255, and shows underexposed blinkies when all the channels are 0.
DxO shows the individual channels but it's impossible to read the pixel values directly. Shame

George

George - this is a screen shot of Adobe Camera Raw (ACR) showing overexposure "blinkies", which actually do not blink at all. Clipped highlights are shown in red and crushed shadow details (there are none here) are shown in blue.

The histogram in ACR is a bit of a hybrid. Where the colour channels overlap, everything is shown as white, but where there are spikes in the individual colour channels, one can see them.

There is also an optional indicator, a small triangle, at the top left and top right corner of the histogram. When the triangles are activated (this is optional), the normal state if there is no clipping is black. They show which channels are clipped by showing the colour and if they show white, all channels are clipped.

[george013]

George - this is a screen shot of Adobe Camera Raw (ACR) showing overexposure "blinkies", which actually do not blink at all. Clipped highlights are shown in red and crushed shadow details (there are none here) are shown in blue.

The histogram in ACR is a bit of a hybrid. Where the colour channels overlap, everything is shown as white, but where there are spikes in the individual colour channels, one can see them.

There is also an optional indicator, a small triangle, at the top left and top right corner of the histogram. When the triangles are activated (this is optional), the normal state if there is no clipping is black. They show which channels are clipped by showing the colour and if they show white, all channels are clipped.

My question was about the pixel values. It's not a must the pixel must have a max. value of 255. There're programs that have standard a threshold build in. Just comparing the fact that clipping is seen is not enough. It shouldn't be that difficult.
I don't know about the dng. If it contains a rgb image in whatever form or if a rgb image has to be created. If so I know a nice diagram. I don't think you would appreciate it when I show it again.

George

[DanK]

My question was about the pixel values. It's not a must the pixel must have a max. value of 255. There're programs that have standard a threshold build in. Just comparing the fact that clipping is seen is not enough. It shouldn't be that difficult.
I don't know about the dng. If it contains a rgb image in whatever form or if a rgb image has to be created. If so I know a nice diagram. I don't think you would appreciate it when I show it again.

George

I think this isn't relevant because Donald did not observe this behavior before, and I doubt ACR has changed the threshold. I still think that an essential diagnostic would be to take the unedited raw file from an image that causes this problem and read it into ACR directly. That would reveal whether the issue is ACR or something embedded in the file by DxO. If the former, i would suspect a problem with Donald's installation of ACR, as my copy of ACR does not display this behavior. It produces precisely the same histogram as does Photoshop.

[Manfred M]

My question was about the pixel values. It's not a must the pixel must have a max. value of 255. There're programs that have standard a threshold build in. Just comparing the fact that clipping is seen is not enough. It shouldn't be that difficult.
I don't know about the dng. If it contains a rgb image in whatever form or if a rgb image has to be created. If so I know a nice diagram. I don't think you would appreciate it when I show it again.

George

Pixel values are easy enough to see in ACR. The sampler tool provides a readout of wherever anyone wants to sample the values at any particular location. I'm not particularly sure why this is relevant? That being said for an 8-bit image, each channel has a maximum value of 256. For 16-bit data, each channel can have a maximum value of 65,536.



A dng is a strange construct and there are two types. The first type is simply a wrapper for raw data, the metadata and a jpeg. It does not contain any RGB image other than the JPEG and the raw convertor has to turn it into RGB data.

The second type is what Donald is dealing with where processed data can be stored in the file; i.e. there is RGB data. The problem here is I have no idea how ACR handles this data and suspect that something is going on in the background that is causing the issue that Donald sees.

Regardless, this has nothing to do with what Donald is trying to figure out. His question is still trying to understand what has changed that ACR is reporting clipped highlights, where in the past it has not.

[george013]

...., and I doubt ACR has changed the threshold......

This is post 19 I think. The answer is only 3 keystrokes long.

George