Ad
Ad
Ad
Pages: « 1 [2] 3 »   Bottom of Page
Print
Author Topic: No way to balance color with R,G,B points?  (Read 7688 times)
Schewe
Sr. Member
****
Offline Offline

Posts: 5489


WWW
« Reply #20 on: November 27, 2012, 04:32:35 PM »
ReplyReply

operations that you control through UI (except process version and camera profile selected) in ACR/LR do not operate on raw data

They operate on previewed data derived from the raw data and in the case of the raw processing pipeline, you can't really separate one part of the pipeline from the rest...the entire processing pipeline is being applied from the start of the pipeline to the end of the pipeline. If you want to hold to the fact that ACR/LR must first demosaic the raw data and as a result, any processing is done on the demosaiced data (which you claim makes it no longer "raw") I think that's a distinction without relevance...ACR/LR process raw files into gamma encoded RGB files.
Logged
digitaldog
Sr. Member
****
Offline Offline

Posts: 9164



WWW
« Reply #21 on: November 27, 2012, 05:11:40 PM »
ReplyReply

1) a raw converter hidden from you (almost, again - you can select the process version and dcp profile) that reads the data, does whatever normalization you need, does demosaick, does color transform and the pass the result to next component with which you actually interact, thinking that you work with raw data

I'm sorry, I don't understand that.

Quote
2) a version of PS designed to work with images originating from that hidden raw converter - that is what exposed to you through UI, where you do "WB", "exposure compensation" and so on... but you do not do this with the raw data

If not the raw data, what? Not the current rendered preview. It's updated on the fly as I move sliders and such. I now have to do something with the preview but I need something a lot bigger. If I'm not exporting, printing, building web galleries from the raw data, then what data?

Quote
the point is - all of your sliders in ACR/LR UI do not work operate on raw data...

OK what stuff is raw and what stuff is, whatever else there is when I make a 16x20 print?
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
Vladimirovich
Sr. Member
****
Offline Offline

Posts: 1320


« Reply #22 on: November 27, 2012, 06:39:19 PM »
ReplyReply

I'm sorry, I don't understand that.

you can use dcraw to output .tiff with demosaicked data with color space = prophoto and linear gamma and no WB applied (you can set your own WB multipliers there)... is that a raw data ? now what is the difference between the raw file opened in ACR and that .tiff opened in ACR for you working with ACR's UI ? different demosaick ? that does not change anything... may be different color transform from camera RGB to prophoto coordinates - that does not change anything either in principle... so where is the difference for you playing w/ the sliders in ACR ? no difference... so to say that you are working with raw data in ACR through UI is not true... ACR has a raw conversion component, yes... but sliders and curves are not working with raw data... no matter how you will change a WB or exposure in ACR it will not redo demosaick and it will not apply WB multipliers to raw data channels - but will be working with demosaicked data in a regular color space instead, linear gamma or not - does not make that data a raw data... you can call it scene-referred as much as you want - but it is not a raw data... and you might as well get some image editor and work with the above mentioned tiff from dcraw...  and do you white balancing (ACR style), tone mapping and further color transforms there and you will not call that raw conversion, right ?
Logged
digitaldog
Sr. Member
****
Offline Offline

Posts: 9164



WWW
« Reply #23 on: November 27, 2012, 07:07:50 PM »
ReplyReply

you can use dcraw to output .tiff with demosaicked data with color space = prophoto and linear gamma and no WB applied (you can set your own WB multipliers there)... is that a raw data ?

No it isn't. It's rendered (in this case) to a TIFF at some size at some resolution.

Quote
now what is the difference between the raw file opened in ACR and that .tiff opened in ACR for you working with ACR's UI ?

I don't know what you mean by open in ACR. If you 'open' a raw file, ACR provides a preview it generates of some rendering instructions just like Lightroom. When you say open if you mean the command telling ACR to render the data, it's the same as the example you asked about above. It's a rendered TIFF. The difference is that the preview is one thing, a proxy. The rendering instructions are another. If I ask ACR to open the raw data within Photoshop it has to render the data with raw+instructions, from the raw data.

Quote
but sliders and curves are not working with raw data... no matter how you will change a WB or exposure in ACR it will not redo demosaick and it will not apply WB multipliers to raw data channels -

OK then please explain then the processing path. I import a raw into LR. I've got a preview right? It was generated by LR agreed? At some point I have a pile of sliders set such I like the way the preview looks. Now I want a 16-bit RGB full resolution from this 5DMII. You are saying none of the raw is touched at this point? LR renders the data from what? Can you explain the processing path once I've told LR or ACR via instructions what color appearance like based on the preview.
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
RFPhotography
Guest
« Reply #24 on: November 28, 2012, 07:35:44 AM »
ReplyReply

I think what Vladimirovich is saying is that once the 'raw data' is previewed on screen in a demosaiced form with a colour model applied to it it's no longer raw data and that any changes you make via the application UI aren't working on the actual undemosaiced, non-colour transformed (i.e., no ProPhoto working space with linear gamma, no calibration profile).  He's saying, I believe, that any changes you make don't require or don't force a rerendering of the undemosaiced, non-colour transformed raw data or provide a new preview but that the changes made via the UI sliders are made on top of the already demosaiced, colour transformed preview and that as a result of not generating a new screen preview from the undemosaiced, non-colour transformed raw data it's no longer a raw image that's being worked on.  I think what he's saying is that those first couple steps - demosaic and colour transform - are like hidden steps in the LR history.  I think what he's saying is that at the point of the image preview on screen in demosaiced, colour transformed form that it's no different from working on a fully rendered tiff in PS.
Logged
digitaldog
Sr. Member
****
Offline Offline

Posts: 9164



WWW
« Reply #25 on: November 28, 2012, 08:42:42 AM »
ReplyReply

I think what Vladimirovich is saying is that once the 'raw data' is previewed on screen in a demosaiced form with a colour model applied to it it's no longer raw data and that any changes you make via the application UI aren't working on the actual undemosaiced, non-colour transformed (i.e., no ProPhoto working space with linear gamma, no calibration profile). 

To which I'd answer: Duh (or, most here area totally aware of that).

I tried to separate the preview (which is clearly not raw but a low rez rendered proxy) from the processing of the data and asked Vladimirovich to more clearly define the processing path since some of what Vladimirovich has written I don't quite understand.

When I ask LR to provide an sRGB 900x1800 image OR I ask for the full rez in ProPhoto 16-bit (or any combo you want to make up), the raw data has to be accessed I'd believe, to produce this new data unless Vladimirovich can explain how the processing path works without the raw data plus instructions.
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
Tim Lookingbill
Sr. Member
****
Offline Offline

Posts: 1164



WWW
« Reply #26 on: November 28, 2012, 12:06:47 PM »
ReplyReply

Vladimirovich might as well be saying we don't really see reality. Our brains decipher photon particle wave patterns across 400nm to 700nm light spectrum onto our rods and cones in the back of our eyeballs which excite our optic nerve to form a picture that's still not considered technically as reality.

Reality doesn't exist unless there's an observer to define it. So...

You can't edit what you can't see. Can't see it? It doesn't exist as we know it.

We can't edit RGB filtered mosaic patterns into a picture our brains associate with reality. All Raw data comprises (off the electronic sensor source) is luminance grayscale pixels from black to white captured from light projected through the lens and onto the sensor filtered by Bayer (RGGB) patterns into voltage signals that represent grayscale values which are then converted by the A/D electronics into 1's and 0's that will later be interpreted back into a visual pattern that is recognized by humans called a preview by software.

Further metaphysics discussions will begin momentarily if so desired.
Logged
digitaldog
Sr. Member
****
Offline Offline

Posts: 9164



WWW
« Reply #27 on: November 28, 2012, 12:30:22 PM »
ReplyReply

Further metaphysics discussions will begin momentarily if so desired.

Not till I can get out of the Matrix!
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
Scott Hargis
Full Member
***
Offline Offline

Posts: 194



WWW
« Reply #28 on: November 28, 2012, 11:09:24 PM »
ReplyReply

So......I think what you guys are saying is, there's no way to balance color with R,G,B points.


Right?
Logged

<a href="http://www.scotthargisphoto.com">Website</a>
Schewe
Sr. Member
****
Offline Offline

Posts: 5489


WWW
« Reply #29 on: November 29, 2012, 12:14:20 AM »
ReplyReply

So......I think what you guys are saying is, there's no way to balance color with R,G,B points.
Right?

Wrong...there's simply no way to do it the way Photoshop does...LR/ACR is a different animal. Color balancing with RGB curves in ACR/LR is useful but there are no Option/Alt clicking ways of making an auto adjustment. Do it by hand/eye.
Logged
bjanes
Sr. Member
****
Offline Offline

Posts: 2794



« Reply #30 on: November 29, 2012, 07:56:21 AM »
ReplyReply

It would do you guys well to forget and ignore what you do in Photoshop VS ACR/LR. Why? Because in Photoshop you have already committed to a gamma encoded color space. In ACR/LR you are dealing with raw images in a linear gamma and in the camera's native, undefined color space. That's a really big friggin' difference in tool sets.

You may wish you could use techniques you've found that may work in Photoshop, but you are spitting into the wind...it ain't gonna happen and your only option is to learn how to use ACR/LR...then do the stuff that can't be done there in Photoshop. The more you learn to do in ACR/LR, the better your images will be (and the less time you spend diddling images in Photoshop).

I'm not sure if the OP is white balancing or merely adjusting colors to some artistic intent. However, if the former, it is not a good idea to white balance on gamma encoded data. Lightroom and ACR can white balance gamma encoded files, but they do so in a linear space. With a curve adjustment of gamma encoded data, the endpoints (0 and 255 in 8 bit) will be fine, but the midtones will be distorted when one performs a linear adjustment on the nonlinear data in Photoshop. One could convert the PS data to linear using a linear profile space, perform the adjustment, and then convert back to the gamma encoded space. Alternatively, one could merely use preset curves to perform the conversions.

These curves are shown below for sRGB and inverse sRGB. Points for 0 and 255 are the same for linear and sRGB, but the midpoints are quite different.
Logged
Vladimirovich
Sr. Member
****
Offline Offline

Posts: 1320


« Reply #31 on: November 29, 2012, 08:30:51 AM »
ReplyReply

No it isn't. It's rendered (in this case) to a TIFF at some size at some resolution.
the same is with ACR/LR - in its processing workflow/path (codewise), raw data is demosaicked as soon as possible and color transformed into a regular colorspace (colorimetric - isn't that the word ?) just with linear gamma... that happens before you see any rendered (from raw data by ACR) image on screen... and then, from that point on, it is not different from working with .TIFF opened in ACR/LR (or linear DNG for that matter), provided that .TIFF will generated the same way (w/ demosaicked data, prophoto coordinates, linear gamma)... data obtained at this stage is the data that will be used by ACR/LR code to generate previews, do all adjustments that you control through UI (including WB and exposure)... so to claim that you adjust raw data is quite incorrect here... you adjust the data that was already converted (by ACR/LR) and not raw data... that is unlike proper "raw converter" like dcraw (WB before demosaicking for example, so WB on raw data, per raw channel)... the only operation available to you in ACR/LR UI that actually works with the raw data is changing "process" version (= new demosaick) and camera profile change (= new color transform, even that does not require new demosaick)... so the codewise there is a point in ACR/LR code after which everything is the same for raw file, for linear DNG file converted from raw, for .TIFF... and that point in code, like it or not, lies before any preview is generated and before UI controlled code that does changes (except process/camera profile controls)...
Logged
digitaldog
Sr. Member
****
Offline Offline

Posts: 9164



WWW
« Reply #32 on: November 29, 2012, 09:08:41 AM »
ReplyReply

the same is with ACR/LR - in its processing workflow/path (codewise), raw data is demosaicked as soon as possible and color transformed into a regular colorspace (colorimetric - isn't that the word ?) just with linear gamma...

Hold on, you are still not clear enough for me to understand. Are you saying that as soon as I import the image into LR (or open in ACR), the full resolution raw data is demosaiced? And from that point on, if I want a 1mb or 30mb file, the ACR engine takes this processed (or particularly processed data) of full resolution data and then provides the size/color space/bit depth I've asked for?

Quote
that happens before you see any rendered (from raw data by ACR) image on screen... and then, from that point on, it is not different from working with .TIFF opened in ACR/LR

Again, I'm having difficulty with perhaps our native languages. When you say open, do you mean the preview seen as soon as I select "Open" on a raw file for ACR OR open when I expect ACR to provide the data size, color space, bit depth etc shown to me IN Photoshop?

Perhaps if you outlined how you think the processing path operates I'd understand better:

1. Select Open in ACR
2. ACR access raw data and builds (you have to fill in the rest)
3. Parametric edits from user are applied
4. User exports 1mb image in sRGB for web (you have to fill in the rest in terms of what happens next).

Here's what I *think* happens and I'm wondering if you feel this is true or not:

I 'open' a raw file in ACR or import into LR.
A small preview is generated (in LR we have preferences to select the size).
I edit the image by building a list of parametric instructions. I suspect there is no reason this has to be applied to anything but this small preview but maybe you are saying the engine has processed data using the full resolution raw data.
The raw data file is accessed and with the edits I've built, an image is now rendered as I desire. Size, bit depth, color space etc.


Where above am I off?

If this sounds correct, then the where we are not communicating clearly is the very last sentence above, where it seems that the raw data plus the instructions have to both be accessed so rendering can take place. If that's the case, then the raw has to be used here no? Or are you saying the raw data was processed the very first time I accessed the data (or build a preview), that data lives somewhere waiting to be rendered? It seems that would make a huge overhead in processing and storage just to view a raw you might not edit.
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
RFPhotography
Guest
« Reply #33 on: November 29, 2012, 09:22:14 AM »
ReplyReply

the same is with ACR/LR - in its processing workflow/path (codewise), raw data is demosaicked as soon as possible and color transformed into a regular colorspace (colorimetric - isn't that the word ?) just with linear gamma... that happens before you see any rendered (from raw data by ACR) image on screen... and then, from that point on, it is not different from working with .TIFF opened in ACR/LR (or linear DNG for that matter), provided that .TIFF will generated the same way (w/ demosaicked data, prophoto coordinates, linear gamma)... data obtained at this stage is the data that will be used by ACR/LR code to generate previews, do all adjustments that you control through UI (including WB and exposure)... so to claim that you adjust raw data is quite incorrect here... you adjust the data that was already converted (by ACR/LR) and not raw data... that is unlike proper "raw converter" like dcraw (WB before demosaicking for example, so WB on raw data, per raw channel)... the only operation available to you in ACR/LR UI that actually works with the raw data is changing "process" version (= new demosaick) and camera profile change (= new color transform, even that does not require new demosaick)... so the codewise there is a point in ACR/LR code after which everything is the same for raw file, for linear DNG file converted from raw, for .TIFF... and that point in code, like it or not, lies before any preview is generated and before UI controlled code that does changes (except process/camera profile controls)...

I think this is not correct and where you're going off the rails a bit.  A tiff or jpeg file, even when opened in ACR/LR has the pixels fully cooked.  White balance is established and while it can be altered the effect is not the same as working on a raw file.  It's gone from being simply a metadata entry to actually fixing pixel values.  Similarly any changes to colour or contrast, while able to be made, aren't the same as working on a raw file.

While a raw file opened in ACR/LR is still a raw file in that the pixels are not locked.  At this point White Balance is still just a metadata entry.  You're much more free to adjust exposure/white point/black point to recover highlights or open up shadows.  You're not working on fully cooked pixels as you are with a tiff or jpeg.  While the image is demosaiced and has a render curve applied via the Adobe Standard, or whatever dcp is used, dcp and has a gamma adjustment for on screen preview, those settings aren't locked in.  That render curve can be changed by using a different dcp.  That is necessary to get an image on screen that can be worked with and that looks, visually, similar to reality.  But those settings don't lock pixels at that point.  Any adjustments you make in LR/ACR are parametric and don't affect the actual pixels in the file until the image is exported in a fixed file format.  
Logged
Vladimirovich
Sr. Member
****
Offline Offline

Posts: 1320


« Reply #34 on: November 29, 2012, 09:27:15 AM »
ReplyReply

Hold on, you are still not clear enough for me to understand. Are you saying that as soon as I import the image into LR (or open in ACR), the full resolution raw data is demosaiced?

YES, that is a core feature of Adobe's so called "DNG processing model", to get rid of the raw data as soon as possible and work with the data that is demosaicked and color transformed to a proper color space... the mere fact that gamma is 1 does not change much, you can have tiff w/ the data that is linear...
Logged
Vladimirovich
Sr. Member
****
Offline Offline

Posts: 1320


« Reply #35 on: November 29, 2012, 09:31:44 AM »
ReplyReply

I think this is not correct and where you're going off the rails a bit.  A tiff or jpeg file, even when opened in ACR/LR has the pixels fully cooked.

first of all - I did not talk about JPG, I was talking about TIFF (those are just containers, but let us leave JPG out to make things simple)... define fully cooked ? I can get an image data output from a raw converter to tiff that will be exactly the same processing wise (demosaicked and no WB... no WB means WB = UniWB by the way... so absence of raw channel data multiplication is just UniWB WB applied formally) as in linear DNG produced by ACR/LR... do you call linear DNG data fully cooked ?
Logged
Vladimirovich
Sr. Member
****
Offline Offline

Posts: 1320


« Reply #36 on: November 29, 2012, 09:34:01 AM »
ReplyReply

White balance is established

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)  Wink
Logged
digitaldog
Sr. Member
****
Offline Offline

Posts: 9164



WWW
« Reply #37 on: November 29, 2012, 09:34:11 AM »
ReplyReply

YES, that is a core feature of Adobe's so called "DNG processing model", to get rid of the raw data as soon as possible and work with the data that is demosaicked and color transformed to a proper color space... the mere fact that gamma is 1 does not change much, you can have tiff w/ the data that is linear...

I'm very clear understanding that the gamma encoding has nothing to do with whether the data is raw or rendered. But I find it hard to believe that instead of accessing the raw + instructions at rendering time, the Adobe engine builds a full rez, demosaiced document whether I edit the image or not. I do however remember the role of the ACR cache or more recently the option for DNG quick preview data. But my assumption is this isn't the full resolution demosaiced but only partially processed preview.

Why would LR for example, build all this data before I even move into Develop or throw away some of the imported images I don't want?
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
digitaldog
Sr. Member
****
Offline Offline

Posts: 9164



WWW
« Reply #38 on: November 29, 2012, 09:36:49 AM »
ReplyReply

do you call linear DNG data fully cooked ?

That's partially cooked data. And I don't really get behind the idea of a linear DNG or for that matter, a TIFF that's been saved out as a DNG.

IOW, a DNG doesn't have to be about raw data.
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
Vladimirovich
Sr. Member
****
Offline Offline

Posts: 1320


« Reply #39 on: November 29, 2012, 09:40:03 AM »
ReplyReply

But I find it hard to believe that instead of accessing the raw + instructions at rendering time, the Adobe engine builds a full rez, demosaiced document whether I edit the image or not.

That is why I find it very strange that Schewe did not describe that in his book - he knows that 100%... it is very clear that for performance reasons Adobe can't redemosaick always to have a real time UI feedback... so Adobe demosaick raw data when the file is opened and then just works with that... and the further processing path is the same as for linear DNG files... that is why the work with original raw and linear DNG converted from that raw by Adobe's tools is identical in ACR/LR !!! it is so clear... that is why in dcraw you have WB applied to raw data and in Adobe's tools not to raw data... because users are moving temp/tins sliders and they want real time feedback... and you can't have that with WB applied to raw data before demosaicking.. unless you do some tricks (like binning 4->1 instead of demosaicking, showing only part of the image demosaicked in a 100% loupe, etc)... Schewe likes to call this Knoll's genius - but that was just performance considerations, wasn't it ?
« Last Edit: November 29, 2012, 09:46:31 AM by Vladimirovich » Logged
Pages: « 1 [2] 3 »   Top of Page
Print
Jump to:  

Ad
Ad
Ad