Data is getting clipped.

Submitted by Iain on Wed, 01/20/2016 - 21:18
Forums: 
Bug reports

Hi,
I've found an issue with clipping which prevents highlights from being displayed correctly. 
Attached are two images showing the red channel of an image. It is unclipped, but FRV clips the data and loses highlights.

I'm having trouble getting the second image to upload and display.

Iliah

Wed, 01/20/2016 - 22:36

Dear Sir:

In FastRawViewer, please check what are the settings you have in Preferences -> Image Display. Histogram in FastRawViewer does not show the red channel clipped, neither does the statistics; so you may want to un-check "Apply Adobe hidden exposure correction", un-check "Set hidden exposure correction to..." (if it is checked), set "Exposure correction on file open" to "No correction", set "Fixed exposure shift" to 0. You can look up those parameters in the manual, it comes as a pdf with the installer, and also is available online: http://www.fastrawviewer.com/usermanual/program-settings/image-display . In case you will be still experiencing this problem, please provide the raw file.

Iain

Wed, 01/20/2016 - 23:09

I think it is a white balance problem. It does not occur with UniWB.
RAW file here: https://dl.dropboxusercontent.com/u/10782279/DSC_6867.NEF
please let me know when you have download the file and I will remove it.
 
 
 

Iliah

Wed, 01/20/2016 - 23:25

Yes, the file is downloaded.

lexa

Thu, 01/21/2016 - 01:44

Thank you for RAW sample, it is much easier to understand the problem with file on hands.

This is well known 'pink clouds' problem.

Let's examine small selection on white dress with RawDigger histogram:

Selection area is shown on RawDigger screenshot (gray rectangle):

And here the RAW histogram on selected rectangle:

Green channel 'hits the wall' at 4095 (so, the camera is in 12-bit mode), while Red and Blue are not clipped in RAW data.

Next step: let's apply White Balance coefficients. To show it, we'll switch FRV to 'WB Coefficients mode' in Preferences - White Balance - WB Display mode.

For 'As Shot' White balance, coefficients are 2.66, 1.0 and 1.45 for Red, Green, Blue:

So, on first processing steps Red values to be multiplied to 2.66, so any RAW pixel with red value above 1539 will become large than 4095 (green channel limit).

Blue values to be multiplied to 1.45, so any pixel with blue value above 2824 will move to 'above 4095' (fortunately, very small fraction of white dress pixels are above 2824).

Let's examine small very small selection on white dress in RawDigger again (small gray square on screenshot):

The numbers are min/max/average of raw values in this small selection:

Red channel:  average 1657 before WB applied, so after WB coeff of 2.66 it will become 4407.

Green: average 4058, multiplied by 1.0

Blue: average 2730, multiplied by 1.45, so becomes 3958 in average. Maximum value is 3226 (4667 after WB coeff 1.45 applied).

So, average color for this selection is RGB (4407,4058,3968). This is pink(-ish) color, not white.

That's because green channel is limited by camera (this channel is most sensitive in given light), while Red/Blue (not so sensitive) are not limited.

There are two ways to deal with this imbalance:

1) Perform some kind of highlights recovery (so, try to recover limited green channel by correlation with red and blue). This works well for neutral highlights, but not so good for colored highlights.

2) Cut white-balance-corrected values by lowest value of (channel limit * WB coeff for this channel). For given case: cut anything above 4095 (green limit * Green wb coeff /1.0/). This will preserve neutral highligths from colorization and also will simulate camera with equal channel sensitivity.

FRV uses second way, mostly because of speed issues, it it not easy to recover highlights fast.

--

Alex Tutubalin/FastRawViewer team

Iain

Thu, 01/21/2016 - 19:26

I understand. 
My reason for bringing this up is becuase I want to be able to see what details might be able to be recovered.  At the moment it is awkward, because it invovles switching to UniWB, possibly looking at RGB channels individually,  and possibly changing the contrast curve to gamma 1.8 to increase highlight contrast.
Here are some suggestions for you to consider. 
1) The option to view individual RGB channels before WB clipping. So when you view the red channel, for example, WB scaling is ignored.
​2) The option to view the minimum value of the RGB channels (prior to WB scaling). 
3) The option to show 'pink clouds' 
4) The option, like boost shadows, to apply curve that increases highlight contrast, perhaps a gamma of 0.6 or something like that. 
 

lexa

Fri, 01/22/2016 - 01:06

Tnank you for you suggestions.

We'll implement some kind of 'Anti-Shadow-Boost' (highlight boost) in next minor update (FRV 1.3)

--

Alex Tutubalin/FastRawViewer team

lexa

Thu, 03/17/2016 - 12:10

The highlights inspection mode is implemented in FRV 1.3 (now 'Release Candidate'): http://www.fastrawviewer.com/testing/fastrawviewer-1-3#

See announce text for details.

--

Alex Tutubalin/FastRawViewer team

Iain

Fri, 03/18/2016 - 00:38

I just had a quick test, and it looks good.  
It also works well for checking highlight sharpness in conjunction with focus-peaking.
 
Thanks. :)

Iain

Wed, 01/20/2016 - 23:31

Thank you.
 
I hope it is useful.  

Add new comment