Pages: 1 2 [3]   Go Down

Author Topic: No way to balance color with R,G,B points?  (Read 18083 times)

Vladimirovich

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1311
Re: No way to balance color with R,G,B points?
« Reply #40 on: November 29, 2012, 10:42:33 am »

That's partially cooked data.

yes, and that is what ACR/LR do internally - they partically cook the data and then all previews, all your UI work is with that partially cooked data... so if you will feed that partically cooked data to ACR/LR there will be no difference for you in preview or UI operations... that is why linear DNG exists... and you can get TIFF prepared the same way...
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20614
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: No way to balance color with R,G,B points?
« Reply #41 on: November 29, 2012, 10:43:54 am »

That is why I find it very strange that Schewe did not describe that in his book - he knows that 100%...

Not only haven't I seen this in any book (I own a few on these products), I don't recall hearing this from Adobe. I guess it's time for Jeff and/or Eric to reply...
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20614
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: No way to balance color with R,G,B points?
« Reply #42 on: November 29, 2012, 10:49:36 am »

yes, and that is what ACR/LR do internally - they partically cook the data and then all previews, all your UI work is with that partially cooked data...

That part makes sense. Assuming this is done to a lower resolution proxy. The differences here between a preview and all the data being processed, wherever we edit or not is what I'd like to know more about.

Quote
so if you will feed that partically cooked data to ACR/LR there will be no difference for you in preview or UI operations... that is why linear DNG exists... and you can get TIFF prepared the same way...

I'm not sure bringing DNG, linear or not into the discussion makes the path clearer. Are you saying that if someone imports a proprietary raw into LR, even if they do not convert to DNG, behind the scene there's some conversion going on?

My understanding of linear DNG was for someone who wants partially processed data. Explained like this:

Quote
DNG is both a raw image format and a format that supports "non-raw", or partly processed, images.[2] The latter (non-raw) format is known as "Linear DNG".[31] Linear DNG is still scene-referred and can still benefit from many of the operations typically performed by a raw converter, such as white balance, the application of a camera color profile, HDR compositing, etc.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Vladimirovich

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1311
Re: No way to balance color with R,G,B points?
« Reply #43 on: November 29, 2012, 10:55:47 am »

I guess it's time for Jeff and/or Eric to reply...

I guess Eric said that many times, may be not that directly... here is a piece where you can see that happens in DNG processing model (shown in DNG SDK) -

Eric Chan : ( http://www.luminous-landscape.com/forum/index.php?topic=38898.msg321693#msg321693 ) @ November 01, 2009

Quote
   The best place to start in terms of the code would be dng_validate.cpp. The dng_validate () routine in there will read in a negative, parse through it, and build the various image stages. This includes decompressing the raw image data, linearizing it if necessary, and render to a TIFF file if you want. From a developer's perspective, I'd suggest putting a breakpoint somewhere in that routine, feeding a DNG raw file to it, and then stepping through to see how the code flows. In terms of terminology, the code comments use the term "stage 1" image to describe the raw image data, "stage 2" to describe the linearized raw image data (in a canonical space [0, 1], or [0, 65535] if you prefer), and "stage 3" to describe the 3-channel or 4-channel data (i.e., after demosaic). If you want to do processing on linearized mosaic data, you want to grab the stage 2 image; see the Stage2Image () routine in the dng_negative class (dng_negative.h). If you want to do processing on RGB demosaiced data in the native camera color space, prior to white balance, you want the stage 3 image; see the Stage3Image () routine in the dng_negative class.

see - RGB demosaicked prior to WB... WB is not applied to raw data...



Eric Chan : ( http://www.luminous-landscape.com/forum/index.php?topic=56863.msg461536#msg461536 ) @ August 17, 2011

Quote
    HueSatMap1 and HueSatMap2 tables precede the Exposure & Blacks controls.

see again - exposure is not applied to raw (per channel) data...

reading postings of Eric Chan is the best book you can get about LR/ACR
« Last Edit: November 29, 2012, 11:00:37 am by Vladimirovich »
Logged

Vladimirovich

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1311
Re: No way to balance color with R,G,B points?
« Reply #44 on: November 29, 2012, 10:57:09 am »

That part makes sense. Assuming this is done to a lower resolution proxy.

no, you can view what you do at 100% in ACR/LR and you can have a screen that will show you all pixels... what proxy you are talking about ?
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20614
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: No way to balance color with R,G,B points?
« Reply #45 on: November 29, 2012, 11:01:48 am »

no, you can view what you do at 100% in ACR/LR and you can have a screen that will show you all pixels... what proxy you are talking about ?

The proxy would be that 1:1 preview. IOW, build the 1:1 for the screen view (maybe a bit more), update as the user moves around. An one-the-fly rendering of only what you need to see rather than rendering the entire image. Kind of like Live Picture from the last century. It too would process (render) instructions and data when you asked it to. JIT (Just In Time) processing.

Doesn't it seem odd to render a full 5DMII image, let alone those big medium format captures just to show me a 1024x768 or similar 1:1 preview?

As to Eric's post, well it's over my head. Where in there does it say the entire image is processed at this stage of the editing? And when I ask that question, I'm asking you to decipher what he wrote as I don't understand it.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

RFPhotography

  • Guest
Re: No way to balance color with R,G,B points?
« Reply #46 on: November 29, 2012, 11:35:48 am »

you can have WB = UniWB... which is the same as no WB established... by the way raw data also have WB established always (and no - I am not talking about tags - I am talking about data recorded per sensel)... it is just that WB is UniWB (except some exotic cameras where firmware actually does multiplication of the raw data per channel)  ;)

What you're suggesting is contrary to anything I've read and heard about white balance and raw files. 
Logged

walter.sk

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1433
Re: No way to balance color with R,G,B points?
« Reply #47 on: November 29, 2012, 12:26:53 pm »

I'm not sure if the OP is white balancing or merely adjusting colors to some artistic intent.
It could be either.  Often, when I want to adjust colors to some artistic intent it helps me to see what a neutral starting point would be for comparison.

I also don't think I am looking for an automatic adjustment by using the Alt key in conjunction with the color levels in Photoshop.  What I do is find the first meaningful black and white points in each of the channels ignoring the "noise" to the left or right of where the "real" data starts in that channel.  I can eyeball the white or black overlay on the screen to determine where I should put those black or white points in each channel, and this usually does a creditable job of creating neutral grays/blacks/whites.  Whether that produces what I want artistically is a decision I make at that point.

My original question is based on the fact that many of the adjustments in LR utilize the Alt Key and a temporary change to the displayed image to a white or black screen with threshold-like representations of the brightest or darkest areas of the image appearing as I drag the slider.  That, plus the fact that the Point Curves panel allows individual adjustment of the R, G and B curves, including dragging the endpoints of those curves to meet the parts of the histograms containing real picture data, cause me to think that it should be possible to recreate in LR the process I use in Photoshop.

So, at this point my question is to find which of the following is (are) true:

1) This is not possible in LR.
2) This is possible in LR but just not previously considered.
3) This is possible in LR but would require too much planning, code changes or code writing to make it feasible.
4) Nobody knows.
« Last Edit: November 29, 2012, 12:35:46 pm by walter.sk »
Logged

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6229
    • http:www.schewephoto.com
Re: No way to balance color with R,G,B points?
« Reply #48 on: November 29, 2012, 04:00:34 pm »

That is why I find it very strange that Schewe did not describe that in his book - he knows that 100%...

What I know and what I can say publicly are not always the same. While Eric is free to disclose whatever he wants to (and Eric is very good at walking that line), what I know about the Camera Raw processing pipeline can only be discussed in general terms by me.

Honestly, this whole question is a rabbit hole. Exactly what ACR/LR is doing and in what order isn't really important for the user since the user really has no control over the pipeline. To be accurate, the "first" thing ACR does when opening a proprietary raw files is to actually convert the file to DNG on the fly, load the entire image in memory and demosaic the data. What is does next is apply some normalizations to the linear Pro Photo RGB data and wait for the user to decide what controls, if any, need adjustment. The final stage of processing is to transform to a gamma encoded color space. In between the open and the save, it's really a black box. Some of the information is disclosed in the DNG SDK, but not all of the pipeline...the rest is still proprietary.

If you want to know EXACTLY what ACR/LR is doing when and where and why, the only people who can answer are Thomas and Eric.
Logged

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6229
    • http:www.schewephoto.com
Re: No way to balance color with R,G,B points?
« Reply #49 on: November 29, 2012, 04:14:18 pm »

So, at this point my question is to find which of the following is (are) true:

1) This is not possible in LR.
2) This is possible in LR but just not previously considered.
3) This is possible in LR but would require too much planning, code changes or code writing to make it feasible.
4) Nobody knows.

None of the above...

It's a question of usefulness. The point curve editor in LR is first designed for tone mapping. In ACR 7/LR 4, Thomas snuck in per channel color curves because he finally decided it might be useful. The use case you are trying to make is actually questionable because the per color curves were not designed to be used to set end points per color. They were designed to address cross curved color casts. Trying to use the per channel curves to adjust the white balance doesn't make sense. That's what the white balance is designed to do. The curves function in ACR/LR will never match the functionality of curves in Photoshop.
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20614
  • Andrew Rodney
    • http://www.digitaldog.net/
Re: No way to balance color with R,G,B points?
« Reply #50 on: November 29, 2012, 04:24:38 pm »

To be accurate, the "first" thing ACR does when opening a proprietary raw files is to actually convert the file to DNG on the fly, load the entire image in memory and demosaic the data. What is does next is apply some normalizations to the linear Pro Photo RGB data and wait for the user to decide what controls, if any, need adjustment.

Fascinating and thanks Jeff. That's a heck of a lot more about this path than I've seen yet!

If one converts to DNG first, that save any time?

Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

walter.sk

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1433
Re: No way to balance color with R,G,B points?
« Reply #51 on: November 29, 2012, 06:18:19 pm »

None of the above...

It's a question of usefulness. The point curve editor in LR is first designed for tone mapping. In ACR 7/LR 4, Thomas snuck in per channel color curves because he finally decided it might be useful. The use case you are trying to make is actually questionable because the per color curves were not designed to be used to set end points per color. They were designed to address cross curved color casts. Trying to use the per channel curves to adjust the white balance doesn't make sense. That's what the white balance is designed to do. The curves function in ACR/LR will never match the functionality of curves in Photoshop.
Thank you.  I can live with that. (Doesn't make me too blue  ::)
Logged

Tim Lookingbill

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2436
Re: No way to balance color with R,G,B points?
« Reply #52 on: November 29, 2012, 06:37:17 pm »

Quote
Trying to use the per channel curves to adjust the white balance doesn't make sense. That's what the white balance is designed to do.

The WB sliders have one hue missing in its construct which the RGB curves might address and that is the cyan hue. The actual color temp cast appearance in the scene won't change this.

Where cyan is useful in this regard is to perform a hue twist so that warm reddish to yellowish orange tungsten and sunset color casts turns a brownish hue or coffee stain color. This requires cyan and a bit of saturation adjustments without changing luminance which the WB sliders tend to do.

Split Tone offers the solution in ACR but of course it's a bit hard to isolate the effect only in the highlights. I've tried this technique and it works most of the time.

The reason I mention this is because some one posted here a Nikon shot with these brownish tungsten hues and was complaining about this orangish WB appearance with their Canon the poster couldn't remedy.

But if I had the use of separate RGB curves in ACR I wouldn't use them as much except for the above. 

Logged

Vladimirovich

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1311
Re: No way to balance color with R,G,B points?
« Reply #53 on: November 29, 2012, 07:03:09 pm »

What you're suggesting is contrary to anything I've read and heard about white balance and raw files. 

the true WB is just multiplying the raw data per channel (like dcraw does) - there are no kelvins, no tint numbers... just the numbers used to multiply the data written per sensel... so if you will multiply each channel by 1.0 you do not change anything and yet the raw data w/o any multiplication (x 1.0) might have the "right" WB as is  (hint - something like magenta filters on your lens or magenta filters on your light)... the to say that the data has no WB is not quite right... it just has WB = 1.0, 1.0, 1.0, 1.0 applied  ;) and with magentish (for classic RGBG bayer) light coming through your lens it might be just what a  doctor prescribed.
Logged

Peter_DL

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 544
Re: No way to balance color with R,G,B points?
« Reply #54 on: November 30, 2012, 03:33:26 pm »

>> The best place to start in terms of the code would be dng_validate.cpp…  In terms of terminology, the code comments use the term "stage 1" image to describe the raw image data, "stage 2" to describe the linearized raw image data, and "stage 3" to describe the 3-channel or 4-channel data (i.e., after demosaic). If you want to do processing on linearized mosaic data, you want to grab the stage 2 image… If you want to do processing on RGB demosaiced data in the native camera color space, prior to white balance, you want the stage 3 image...<<

the true WB is just multiplying the raw data per channel (like dcraw does)

But this is just parts of the story.

White Balance in ACR/LR by means of Color Temperature and Tint also let you interpolate between, or even extrapolate beyond, a pair of two camera profiles built for illuminants D65 and A.  So the influence of these sliders stretches back to the colorimetric interpretation of the demosaiced data.

Next, the execution of the per-channel-multiplications was reported to be part of the conversion from the camera space to 1.0 ProPhoto RGB, rather than being just applied after arrival in this intermediate working space.  It was explained that Color Temperature, Tint and Exposure, next to the 3 x2 Hue/Sat.-sliders of the Calibrate tab, actually tweak the conversion while corresponding to the 9 degrees of freedom of a 3 x 3 matrix which is still the core to describe the camera space, even though today we may have a HueSat-delta table applied before.  Like with dcraw this allows to steer the highlight clipping behavior.

Or, the correction of chromatic aberration was explicitly stated to be done soon after demosaicing and in the native camera space.  I'd further assume that the repair of single clipped raw channels (by emulating surrounding colors, if done like in dcraw) and also the lens corrections happen at such very early stage as well.

Seems there was more openness on such mechanistic details in early comments and contributions by Bruce Fraser or Thomas Knoll himself – from what I remember.

I'd exempt the above tools and sliders from your initial claim, while counting it among the basic steps of raw conversion, or what is sometimes called scene reconstruction.

Peter

--
... all sliders that you are moving in UI are instructions of what shall be done with the data that was already 1) demosaicked and 2) transformed to a color space with prophoto coordinates and linear gamma... why do you want to argue w/ that ?
Logged

Vladimirovich

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1311
Re: No way to balance color with R,G,B points?
« Reply #55 on: November 30, 2012, 04:18:03 pm »


I'd exempt the above tools and sliders from your initial claim, while counting it among the basic steps of raw conversion, or what is sometimes called scene reconstruction.


nope - as long as the do not operate on per channel data from sensor sensels they do not operate w/ raw data... but yes, if Eric Chan posted somewhere (I need to find, I did not finish my work studying all of his posts over years) that CA corrections operate on demosaicked data BUT before chains of conversions to cieXYZ to Prophoto/1 then certainly that operates at least in camera's "RGB space" (non colorimetric - is it the right way to say ?)...

PS: is it legal to publish a collection of somebody's posts quoted as a single file (free to download) ?
Logged

Schewe

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 6229
    • http:www.schewephoto.com
Re: No way to balance color with R,G,B points?
« Reply #56 on: November 30, 2012, 05:18:43 pm »

PS: is it legal to publish a collection of somebody's posts quoted as a single file (free to download) ?

Reposting a collection of what somebody wrote without explicit permission would be questionable. Quoting somebody is acceptable...
Logged
Pages: 1 2 [3]   Go Up