Pages: 1 2 [3]   Go Down

Author Topic: Universal white balance and ETTR  (Read 21312 times)

RFPhotography

  • Guest
Re: Universal white balance and ETTR
« Reply #40 on: November 04, 2011, 12:40:01 pm »

Sorry about the italics in that previous post.  Not sure why the entire string ended up italicised.  Only intended to do one word.

OK, that's what I figured.  But for it to be of best use, it has to be pre-capture for the reason noted previously.  Something akin to a peaking indicator on a video camera.  Eric, before WB?  But WB can impact colours/clipping so wouldn't it be better to have the preview include the WB?
Logged

fdisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1853
    • Frank Disilvestro
Re: Universal white balance and ETTR
« Reply #41 on: November 04, 2011, 12:48:47 pm »

If your Raw channels are not clipped then WB should not result in clipped channels, provided you do the right math in post processing

Some basic options:
- Use multipliers lower than 1 (this approach has issues when there are clipped raw values)
- Add bits (i.e. a 14 bit raw channel multiplied by the WB factor resulting in a 16 bit value)

NikoJorj

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1082
    • http://nikojorj.free.fr/
Re: Universal white balance and ETTR
« Reply #42 on: November 04, 2011, 12:55:08 pm »

But WB can impact colours/clipping so wouldn't it be better to have the preview include the WB?
No : as long as the raw data is not clipped, recovery is dead easy (or almost so) in post. For me in LR, no math involved but some sliders tweaking (recovery+, exposure-/brightness+ eg).
Logged
Nicolas from Grenoble
A small gallery

fdisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1853
    • Frank Disilvestro
Re: Universal white balance and ETTR
« Reply #43 on: November 04, 2011, 12:59:33 pm »

Well, I meant the Raw processor to do the right math. LR certainly does the right math.

RFPhotography

  • Guest
Re: Universal white balance and ETTR
« Reply #44 on: November 04, 2011, 01:30:15 pm »

If open an image in LR that has a lot of yellows/oranges/reds and push the WB to the right, I can induce clipping in the image.  

Attached are two images.  One taken with a WB of 10000 (read as 9100 in ACR), the other taken with a WB of 2500 (read as 2600 in ACR).  The histograms are different and the clipping indicators are different.  If WB doesn't affect a RAW exposure, what explains the difference between the two.  

Just so it can't be claimed that I've overexposed the images (ETTR'd, actually) I purposely took two additional shots at -1 exp comp..  Those screen shots are also included and, again, are very different based on the WB.
« Last Edit: November 04, 2011, 01:42:03 pm by BobFisher »
Logged

fdisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1853
    • Frank Disilvestro
Re: Universal white balance and ETTR
« Reply #45 on: November 04, 2011, 01:51:47 pm »

The difference is in the rendered image. If you opened both images in a tool like Rawnalize you will see no difference between both.

If the raw channels are not clipped, but clipping occurs as you adjust WB, you could then adjust back with the exposure slider (or recovery) and you'll be working out from real raw data.

In a simplified way, WB multiplies the Red and Blue channels by numerical factors depending on the color temperature and tint. Exposure is a linear multiplication of a same number for all the channels

So, suppose that a specific WB multiplies the Red channel by 2 and the Blue channel by 1.5. Here you might end with clipped values in the red and blue channels because of this multiplication.

Then, adjusting the exposure by -1 f stop will multiply all channels by 0.5, now you get back to non-clipped values.

fdisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1853
    • Frank Disilvestro
Re: Universal white balance and ETTR
« Reply #46 on: November 04, 2011, 02:04:43 pm »

Attached are two images.  One taken with a WB of 10000 (read as 9100 in ACR), the other taken with a WB of 2500 (read as 2600 in ACR).  The histograms are different and the clipping indicators are different.  If WB doesn't affect a RAW exposure, what explains the difference between the two.  

Bob,

I see that you have on both images the WB "as shot". Just do this test: On the image taken with the WB of 10000 (shown as 9100), use a custom WB of 2600; Tint +2 (as shown in the other image). In the second one, taken with the WB of 2500 use a custom WB of 9100; tint +12. You'll see that the results swap perfectly from one image to the other. This is because the RAW values are the same and what you see in ACR is the result of the rendered image according to the slider settings.

RFPhotography

  • Guest
Re: Universal white balance and ETTR
« Reply #47 on: November 04, 2011, 02:41:48 pm »

See, that's what I always thought too, Francisco.  There was another thread recently that indicated otherwise.  Given that I'm a photographer and not a scientist I decided I was wrong and that the scientists were right.  

Making the adjustment you suggested gets them close but not exact.  That difference could be the slightly different framing of the two shots though.  

I just found the last version of Rawnalyze and looked at the histos for the two images.  Very close, but slight differences.  Again, likely due to the slightly different framing of the two shots.
« Last Edit: November 04, 2011, 02:54:20 pm by BobFisher »
Logged

fdisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1853
    • Frank Disilvestro
Re: Universal white balance and ETTR
« Reply #48 on: November 04, 2011, 03:06:32 pm »

There are a few cameras, mostly early models, that altered the raw values depending on the WB. I think the Nikon D1 was one of these cases. I don't know of new cameras that do that.

Regarding getting an exact match between exposures, there are some factors that can affect this:
- exact aperture repeatability (there might be minor differences between exposures due to mechanical limitations, some brands are more affected than others)
- illumination flickering

About Rawnalyze: The histogram have a linear scale, so they are difficult to compare if there is a slight exposure difference between images. It would be easier if the scale was logarithmic (it would be analogous to f/stops) as in Guillermo Luijk's Histogrammar. Unfortunately, Rawnalize will not be developed any further since its creator passed away and its code wasn't public.

« Last Edit: November 04, 2011, 03:10:58 pm by FranciscoDisilvestro »
Logged

RFPhotography

  • Guest
Re: Universal white balance and ETTR
« Reply #49 on: November 04, 2011, 04:09:39 pm »

Not really that difficult to analyse.  The small differences are pretty easily figured out.
Logged

fdisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1853
    • Frank Disilvestro
Re: Universal white balance and ETTR
« Reply #50 on: November 04, 2011, 04:39:20 pm »

Not really that difficult to analyse.  The small differences are pretty easily figured out.

You're right, it is not really that difficult. What happens is that in a linear scale the Histogram will "expand" or "contract" as you change exposure. In a logarithmic scale it would shift left or right (like in Guillermo's great animation), which I consider more intuitive. Two raw images where the only difference is exposure will show the same Histogram shape at different locations.

RFPhotography

  • Guest
Re: Universal white balance and ETTR
« Reply #51 on: November 04, 2011, 06:38:12 pm »

You're right, it is not really that difficult. What happens is that in a linear scale the Histogram will "expand" or "contract" as you change exposure. In a logarithmic scale it would shift left or right (like in Guillermo's great animation), which I consider more intuitive.
Two raw images where the only difference is exposure will show the same Histogram shape at different locations.


I downloaded GL's tool and it's less intuitive to use than Rawnalyze.  It also seems to not directly read raw data unless the processed image is run through some process with dcraw.  I forget exactly what the pop up message was but it doesn't accept raw files natively, apparently.

Anyway, it's Friday night and, while this is fun and all, there are more fun things to do on a Friday.   ;D
Logged

Guillermo Luijk

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2005
    • http://www.guillermoluijk.com
Re: Universal white balance and ETTR
« Reply #52 on: November 08, 2011, 05:02:41 pm »

in a linear scale the Histogram will "expand" or "contract" as you change exposure. In a logarithmic scale it would shift left or right (like in Guillermo's great animation), which I consider more intuitive.

This is a sequence of histograms from 8 captures from a white wall (it looks green because it has no WB applied, the G channel got max exposure as usual) taken at 1 stop intervals. The histogram doesn't change in shape, it just shifts.

Only once some channel (R and G) gets saturated, the neighbour pixels (B) are affected and their histogram slightly expands (see most exposed shot). In the least exposed shots, the lack of levels in the RAW files produces peaks in the histogram (this histograms correspond to demosaiced data, but without any WB applied nor colour profile conversion, so they can be considered as RAW histograms).




Regards

Graystar

  • Guest
Re: Universal white balance and ETTR
« Reply #53 on: December 02, 2011, 10:21:50 am »

If the raw channels are not clipped, but clipping occurs as you adjust WB, you could then adjust back with the exposure slider (or recovery) and you'll be working out from real raw data.

In a simplified way, WB multiplies the Red and Blue channels by numerical factors depending on the color temperature and tint. Exposure is a linear multiplication of a same number for all the channels

So, suppose that a specific WB multiplies the Red channel by 2 and the Blue channel by 1.5. Here you might end with clipped values in the red and blue channels because of this multiplication.

Then, adjusting the exposure by -1 f stop will multiply all channels by 0.5, now you get back to non-clipped values.

I guess it depends on what tool you're using, but I've found that Rawnalyze and Raw Therapee don't work that way.  With both Rawnalyze and RT, if you reduce the exposure to -1 all the previously "blown" pixel become a lower value but they're all still the same...they're just not at 255 anymore.  In RT, if I use highlight recovery, the same thing happens...except that the rest of the image remains unchanged.

The only thing that worked for me in RT is the Highlight Reconstruction tool.  It seems to get rid of the obvious field of "blown but recovered" pixels.

If LR does something different, it would be interesting to hear what process it follows.

In any case...I see UNIWB as being quite a bit of work for too small a gain.  I'd rather not have to use a highlight recontruction tool on all of my images, and I don't feel like buying LR.  But of course, that just my personal feeling...others will feel differently.
Logged

ejmartin

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 575
Re: Universal white balance and ETTR
« Reply #54 on: December 03, 2011, 12:49:29 am »

I guess it depends on what tool you're using, but I've found that Rawnalyze and Raw Therapee don't work that way.  With both Rawnalyze and RT, if you reduce the exposure to -1 all the previously "blown" pixel become a lower value but they're all still the same...they're just not at 255 anymore.  In RT, if I use highlight recovery, the same thing happens...except that the rest of the image remains unchanged.

The only thing that worked for me in RT is the Highlight Reconstruction tool.  It seems to get rid of the obvious field of "blown but recovered" pixels.


In RT, go to the raw tab and open Preprocessing>Raw white/black point.  Adjust the 'White point: linear correction factor slider' to a value less than one.  There are two ways that channels can be blown -- (1) in the raw data; and (2) due to white balance pushing a color channel past the nominal maximum (eg 255 for 8-bit depth per channel).  If all blown channel pixels are due to (2) then it makes sense to reduce the exposure to bring back the channels and not clip them; this is what the above tool in RT does -- adjusts what the channel clipping point is, and brings down all channels uniformly. 

The problem comes when you do this, and some channels are clipped -- then one will get nasty color tints in those highlights (typically pinkish, since the red WB factor is usually largest).  Now one might say, clip the ones where channels are clipped but recover the ones where no channel is clipped; but that can lead to some nasty transitions.  So, in RT the default is to clip to the white point anything over 255, regardless of whether it is from WB or actual clipping, so as to avoid nasty transitions and color tints.  But that can be bypassed with the above tool, or by turning on highlight reconstruction which tries to build back the highlights that are clipped in the raw data.
Logged
emil
Pages: 1 2 [3]   Go Up