Ad
Ad
Ad
Pages: [1]   Bottom of Page
Print
Author Topic: Correct me if I am wrong about RAW vs. JPEG White Balance Corrections  (Read 11643 times)
Edalongthepacific
Full Member
***
Offline Offline

Posts: 118


« on: December 12, 2011, 08:22:22 PM »
ReplyReply

My thinking is that correcting RAW file white balance using the RAW plugin is completely nondestructive to RAW files. However, when using the RAW plugin on JPEG images, white balance correction comes at some cost to the tonal range of the JPEG image. True???
Logged
pindman
Full Member
***
Offline Offline

Posts: 191


« Reply #1 on: December 12, 2011, 10:06:41 PM »
ReplyReply

JPEG throws away much of the information.  I'm not aware of a "Raw plugin" for a JPEG image.  If you shoot in RAW, you can adjust the white balance later and not loose any information.  It can always be changed.  When shooting in JPEG the white balance is embedded in the file, and the rest of the information is thrown away.  Once you shoot in JPEG you can never really adjuct the white balance correctly. 

JPEG shooting is great for quick images you don't care too much about.  For anything else use RAW!

Paul

Logged
Edalongthepacific
Full Member
***
Offline Offline

Posts: 118


« Reply #2 on: December 12, 2011, 10:18:45 PM »
ReplyReply

Well, you can use the RAW plugin in Photoshop for adjusting the white balance of JPEG images (or TIFF for that matter). The question is, at what cost in terms of digital information lost.
Logged
Schewe
Sr. Member
****
Offline Offline

Posts: 5469


WWW
« Reply #3 on: December 12, 2011, 10:33:34 PM »
ReplyReply

My thinking is that correcting RAW file white balance using the RAW plugin is completely nondestructive to RAW files. However, when using the RAW plugin on JPEG images, white balance correction comes at some cost to the tonal range of the JPEG image. True???

The tonal range? No...the ultimate bit depth, perhaps...depends on what you do and how aggressive the move is. But as otherwise indicated, once you bake the file by using JPEGs, you can never get back the ultimate control you would have over the raw version which is really more about controlling the highlights of a raw file vs the white balance of the file. So I guess your question is wrong...
Logged
ErikKaffehr
Sr. Member
****
Offline Offline

Posts: 7333


WWW
« Reply #4 on: December 12, 2011, 11:04:09 PM »
ReplyReply

Hi,

Yes. But it may be still a smart idea to use the raw plugin for initial adjustment of JPEGs.

Best regards
Erik


My thinking is that correcting RAW file white balance using the RAW plugin is completely nondestructive to RAW files. However, when using the RAW plugin on JPEG images, white balance correction comes at some cost to the tonal range of the JPEG image. True???
Logged

Edalongthepacific
Full Member
***
Offline Offline

Posts: 118


« Reply #5 on: December 12, 2011, 11:26:37 PM »
ReplyReply

I am beginning to believe that correcting JPEG in AP CS5 RAW and setting white & black points is about as good as using any other editing tool if not better assuming you end up with an image with good color balance overall. Bets to shoot RAW. And if you are going to do post production anyway there is no good reason not to use RAW.
Logged
ErikKaffehr
Sr. Member
****
Offline Offline

Posts: 7333


WWW
« Reply #6 on: December 12, 2011, 11:52:42 PM »
ReplyReply

Hi,

With a good tool for handling images, like Lightroom, you actually get a very good raw workflow. There are some other options, Apple Aperture and BibblePro come to my mind.

I wouldn't live without Lightroom if shooting raw. I started out with C1-light, older versions of Bibble Pro and Raw Shooters premium, those were the dark time.

ACR uses the same engine as Lightroom, but with Lightroom that engine is installed in a Porsche instead of a firetruck, which one would you like to drive?!

Best regards
Erik


I am beginning to believe that correcting JPEG in AP CS5 RAW and setting white & black points is about as good as using any other editing tool if not better assuming you end up with an image with good color balance overall. Bets to shoot RAW. And if you are going to do post production anyway there is no good reason not to use RAW.
Logged

bjanes
Sr. Member
****
Offline Offline

Posts: 2785



« Reply #7 on: December 13, 2011, 06:24:40 AM »
ReplyReply

The tonal range? No...the ultimate bit depth, perhaps...depends on what you do and how aggressive the move is. But as otherwise indicated, once you bake the file by using JPEGs, you can never get back the ultimate control you would have over the raw version which is really more about controlling the highlights of a raw file vs the white balance of the file. So I guess your question is wrong...

I am a bit confused about the statement regarding tonal range. Consider two shots: one with tungsten illumination and another with daylight illumination. Tungsten is very deficient in blue light and the blue channel multiplier for WB in this shot is 4.7, whereas it is 1.2 for daylight in the selected scene. In the histogram, the tonal range for the blue channel with tungsten illumination is severely constrained and the histogram is far to the left. The effective bit depth is also markedly truncated.

Regards,

Bill
Logged
hjulenissen
Sr. Member
****
Offline Offline

Posts: 1677


« Reply #8 on: December 13, 2011, 07:12:03 AM »
ReplyReply

Raw-development and JPEG encoding are (when done jointly) a lossy process that cannot be exactly inverted. Further, the parameters necessary to do an approximate inversion are generally not available.

I wonder how many bits it would add to the JPEG header to include simplistic information about tonecurve, color matrix, WB and black/white clipping? I imagine that there are many good images out there that (sadly) are available only in JPEG, where improved WB adjustement is desirable.

-h
Logged
madmanchan
Sr. Member
****
Offline Offline

Posts: 2108


« Reply #9 on: December 13, 2011, 08:00:38 AM »
ReplyReply

JPEG images are nearly always already white-balanced. This means that 1 or more channels may have already clipped as part of the process. Changing the WB afterwards cannot "undo" the clipping (the clipped data is gone).

The other aspect is that WB is really best performed on linear data.  Otherwise you'll get uneven white balance effect across the tonal scale.  But JPEGs are no longer in linear form, and it is not generally possible to get the data back into linear form.
Logged

hjulenissen
Sr. Member
****
Offline Offline

Posts: 1677


« Reply #10 on: December 13, 2011, 10:30:08 AM »
ReplyReply

JPEG images are nearly always already white-balanced. This means that 1 or more channels may have already clipped as part of the process. Changing the WB afterwards cannot "undo" the clipping (the clipped data is gone).

The other aspect is that WB is really best performed on linear data.  Otherwise you'll get uneven white balance effect across the tonal scale.  But JPEGs are no longer in linear form, and it is not generally possible to get the data back into linear form.
Let us assume that jpeg produce sRGB data (it does not, but the conversion from YCbCr->sRGB is initself lossless or practically lossless)
if
[r,g,b] = [m00 m01 m02;m10 m11 m12; m20 m21 m22]*[ri+rioff,gi+gioff,bi+bioff]
for each of r,g,b
 ch = ch + offset
 ch = clip(ch, min, max)
 ch = nonlinear_function(ch) + noise
end

My 3x3 matrix is thought to contain color correction, WB, saturation, exposure correction etc. The clippers limit black point and white point. The nonlinear function is any tonemapping/gamma that stretch levels. The noise contains roundoff errors, JPEG quantization errors etc.

if:
-the nonlinear function is approximately invertible (I believe that gamma functions tend to be),
-the noise is not too high
-the clipping affects relatively few samples and/or with a small change
-the linear 3x3 matrix has an inverse

Then I believe that a one can do an inversion that might have practical application (even though it will be a non-perfect one)? The problem usually is that the handful of parameters needed to do the inversion are unknown and practically impossible to estimate blindly.

-h

(my model is based on my own limited understanding and how I believe it applies to only the problem of white-balancing jpeg files.)
« Last Edit: December 13, 2011, 10:36:53 AM by hjulenissen » Logged
sandymc
Sr. Member
****
Offline Offline

Posts: 256


« Reply #11 on: December 13, 2011, 10:37:08 AM »
ReplyReply

I would think that what Eric was referring to was that in order to create the JPEG, the processing chain from sensor data to JPEG would have had a number of potentially non-linear steps in it - e.g., tone curves, and the effects of various controls such a brightness, etc. Unless you know what those steps were, you can't accurately adjust white balance.

Sandy
Logged
hjulenissen
Sr. Member
****
Offline Offline

Posts: 1677


« Reply #12 on: December 13, 2011, 10:44:32 AM »
ReplyReply

I would think that what Eric was referring to was that in order to create the JPEG, the processing chain from sensor data to JPEG would have had a number of potentially non-linear steps in it - e.g., tone curves, and the effects of various controls such a brightness, etc. Unless you know what those steps were, you can't accurately adjust white balance.

Sandy
My point was that if you _have_ to adjust WB on a jpeg file, knowing those steps (or having good approximations) cannot hurt. Embedding 4 byte in JPEG headers seems like a small cost to pay for that flexibility.

I dont think that you need to go all of the way back to sensor data. Going back to a standardized linear intermediate representation should be enough to do WB (but not to do highlight recovery, not something I would try to do on jpeg files anyway).

-h
« Last Edit: December 13, 2011, 10:48:30 AM by hjulenissen » Logged
madmanchan
Sr. Member
****
Offline Offline

Posts: 2108


« Reply #13 on: December 23, 2011, 10:06:11 AM »
ReplyReply

Technically, the problem is that the raw->jpeg rendering process is usually non-invertible (e.g., because of clipping). 

Politically, I think it is unlikely that camera vendors will describe the internal rendering process used.  So, even if the process was invertible and easy to describe via tags, I doubt they would embed such tags. 

It is possible for a third party to model & measure the process, but it is a moving target because the trend is for in-camera JPEG engines to do more and more "auto processing" where the processing applied varies on a per-image basis, depending on scene content and possibly user-driven parameters.  IMO not worth the effort.
Logged

ErikKaffehr
Sr. Member
****
Offline Offline

Posts: 7333


WWW
« Reply #14 on: December 26, 2011, 01:22:08 AM »
ReplyReply

Hi,

JPEG has a gamma curve, it is really needed if you want represent full tone scale with only 8 bits.

Best regards
Erik

I would think that what Eric was referring to was that in order to create the JPEG, the processing chain from sensor data to JPEG would have had a number of potentially non-linear steps in it - e.g., tone curves, and the effects of various controls such a brightness, etc. Unless you know what those steps were, you can't accurately adjust white balance.

Sandy
Logged

hjulenissen
Sr. Member
****
Offline Offline

Posts: 1677


« Reply #15 on: December 26, 2011, 02:19:47 AM »
ReplyReply

Technically, the problem is that the raw->jpeg rendering process is usually non-invertible (e.g., because of clipping).  
My argument was that clipping might not occur for a large percentage of files, and even if it occured, doing clever WB on a JPEG with information about development should be better than doing WB on a JPEG w/o info about development.
Quote
Politically, I think it is unlikely that camera vendors will describe the internal rendering process used.  So, even if the process was invertible and easy to describe via tags, I doubt they would embed such tags.  
Agreed. Perhaps with some minor exceptions (companies doing standardized raw formats right now, companies that does not put any effort into in-camera jpeg anyways, companies that wants certification for legal and medical customers etc).

How revealing can it be to signal simple black-point (3*14 bit), white-point (3*14 bit), nearest standardized gamma response (2 bit?), applied color temp (14 bit) and nearest 3x3 linear color correction(9*14 bit?)? Those should be fairly easy to reverse-engineer anyways.

I do believe that we customers should figure out what we want, and make our desires audible. Sometimes major companies will listen to a vocal minority when designing products, although I have my doubt about the major asian ones.
Quote
It is possible for a third party to model & measure the process, but it is a moving target because the trend is for in-camera JPEG engines to do more and more "auto processing" where the processing applied varies on a per-image basis, depending on scene content and possibly user-driven parameters.  IMO not worth the effort.
I have been thinking about the relation between my umpteen raw + jpeg files that I have taken myself using two different Canon DSLRs. It would be an interesting project to model the in-camera jpegs using raw-files + e.g. dcraw. For WB to work, I believe that the task is somewhat easier than getting all aspects of visible quality to match up (demosaicing, denoising and sharpening should not matter that much for getting a similar WB).

-h
« Last Edit: December 26, 2011, 02:26:32 AM by hjulenissen » Logged
Tim Lookingbill
Sr. Member
****
Offline Offline

Posts: 1153



WWW
« Reply #16 on: December 26, 2011, 08:52:31 PM »
ReplyReply

It is possible for a third party to model & measure the process, but it is a moving target because the trend is for in-camera JPEG engines to do more and more "auto processing" where the processing applied varies on a per-image basis, depending on scene content and possibly user-driven parameters.  IMO not worth the effort.

Glad my suspicions were verified on this by Eric.

All you have to do to see why this isn't worth it is to compare color relationship hue shifts by increasing contrast and saturation between any camera's menu adjusted incamera processing and different Raw converters. We're not even factoring in profiling the color look up tables of unedited jpegs or Raws.

I notice quite a bit of these color relationship hue shift differences by just adjusting ACR/LR's Vibrance over Saturation sliders over HSL's Saturation slider compared to increasing saturation in my camera's menu system shooting jpegs?

My own camera's Raw converter saturation boost acts differently than ACR/LR's. Raw Developer's as well which I believe is using Lab as its color engine. Unexpected hue shifts abound among them all editing on an image by image basis.
« Last Edit: December 26, 2011, 08:56:01 PM by tlooknbill » Logged
Pages: [1]   Top of Page
Print
Jump to:  

Ad
Ad
Ad