True raw representation in Lightroom?

[hjulenissen]

What are the chances of adding a section, or a small button that lets you do initial work in native camera color channel representation? I would like to know how far from clipping each image truly was (how many stops) so as to improve my recording technique, and I would like to be able to multiply exposure by several stops without introducing color shifts.

-h

[deejjjaaaa]

I would like to know how far from clipping each image truly was (how many stops) so as to improve my recording technique,

just run a spec. software like http://www.rawdigger.com

[Ellis Vener]

Typo fixing edit:

You mean with a straight gamma 1.0 rendering  I take it - but of course sort of profile has to be applied, probably two: a temporarily assigned "holding" space like Linear ProPhoto in Lightroom,  and then your display profile.  

[deejjjaaaa]

I would like to be able to multiply exposure by several stops without introducing color shifts.

didn't Sandy M produce a program to untwist the profiles = http://dcptool.sourceforge.net/Hue%20Twists.html

[deejjjaaaa]

you mena wit ha straight gamma 1.0 rendering  I take it - but of course sort of profile has to be applied, probably two: a temporarily assigned "holding" space like Linear ProPhoto in Lightroom,  and then your display profile.  

he means like RPP ( http://www.raw-photo-processor.com/RPP/Overview.html )

[eliedinur]

In WB set Temperature to 2050 and Tint to -150. This is the LR equivalent of using Uni-WB in your camera. Or, of course, you can shoot with Uni-WB and leave LR on "As Shot".

[madmanchan]

It's possible, but not easy to do this in Lr.  I say "not easy" because Lr always applies a camera profile when processing a raw image.  And all the normal profiles will apply some color transform (hence the result is not the same as the raw image data).  It is technically possible to build a color profile that is effectively a no-op (i.e., does nothing), and hence show you the per-channel histograms without color transforms.

[hjulenissen]

It's possible, but not easy to do this in Lr.  I say "not easy" because Lr always applies a camera profile when processing a raw image.  And all the normal profiles will apply some color transform (hence the result is not the same as the raw image data).  It is technically possible to build a color profile that is effectively a no-op (i.e., does nothing), and hence show you the per-channel histograms without color transforms.

Thank you. This seems to solve half of my request (being able to learn from my exposure mistakes by investigating true histograms) by making such a profile and switching to it temporarily.

But the ability to do some actual edits in the "camera domain" (such as exposure compensation), then moving into a generic respresentation for the remaining edit session seems to not be adressed. That would mean moving some (probably early) elements of the processing pipeline before the color matrix, and updating graphs/visual feedback to suit (primarily histogram).

I am guessing that highlight recovery must occur in native camera representation. I am under the impression that LR3 does exposure compensation in Prophoto RGB. Can you confirm if this is the case for LR4? Doing EC in the camera domain seems to be an obvious way to do it, and I am puzzled by this choice. I can only guess that Adobe did this to avoid confusing gui/histogram discrepancies?

-h

[deejjjaaaa]

Thank you. This seems to solve half of my request (being able to learn from my exposure mistakes by investigating true histograms) by making such a profile and switching to it temporarily.

But the ability to do some actual edits in the "camera domain" (such as exposure compensation), then moving into a generic respresentation for the remaining edit session seems to not be adressed. That would mean moving some (probably early) elements of the processing pipeline before the color matrix, and updating graphs/visual feedback to suit (primarily histogram).

I am guessing that highlight recovery must occur in native camera representation. I am under the impression that LR3 does exposure compensation in Prophoto RGB. Can you confirm if this is the case for LR4? Doing EC in the camera domain seems to be an obvious way to do it, and I am puzzled by this choice. I can only guess that Adobe did this to avoid confusing gui/histogram discrepancies?

-h

as far as I remember you never work (by that I mean user operations w/ UI controls) w/ raw data in Adobe converters... their workflow is that upon opening the raw file the image data immediately demosaicked and translated into to ProPhoto w/ gamma 1 and whatever you think you do you actually do on that data and not on the raw data... so I am not sure how Eric suggestion that selecting a special camera profile will help you to see the raw histogramm... demosaicking allready happened, so even if you manage to undo (by not doing it, by making a special matrix in dcp profile) color transformations in camera profile and conversion to Melissa RGB for histogram display w/ its non "gamma 1" curve - how ?

[sandymc]

as far as I remember you never work (by that I mean user operations w/ UI controls) w/ raw data in Adobe converters... their workflow is that upon opening the raw file the image data immediately demosaicked and translated into to ProPhoto w/ gamma 1 and whatever you think you do you actually do on that data and not on the raw data... so I am not sure how Eric suggestion that selecting a special camera profile will help you to see the raw histogramm... demosaicking allready happened, so even if you manage to undo (by not doing it, by making a special matrix in dcp profile) color transformations in camera profile and conversion to Melissa RGB for histogram display w/ its non "gamma 1" curve - how ?

I would think that what Eric meant was that you could create a profile in which the matrixes were unity matrixes. That would show you the "color" and intensity of the pixels before the overlaps in the RGB dyes, etc was dialed out. The image as displayed in LR would still have a gamma curve for display/cursor readouts applied, and be interpolated. The interpolation might turn out a bit strange because the interpolator's idea what were similar colors would be off.

<Edit> And the white balance processing would probably be way off.

If you wanted, you could build such a profile in dcpTool quite easily.

Sandy

[deejjjaaaa]

The interpolation might turn out a bit strange because the interpolator's idea what were similar colors would be off.

Adobe products do demosaicking as the very first step... so they have no idea about what profile you were going to apply later in UI (the only thing that might affect them is a selection of demosaicking method through : process 2003 - process 2010 - process 2012), what WB you are going to apply later (there are no WB before demosaicking in Adobe products), etc... so no ideas would be "off"... please correct me if I am wrong... and how exactly you are going to make WB w/ multipliers = 1... is WB = 2000/-150 really what somebody above claimed it is... it is just how Adobe's UI will try to display such WB in its UI, and not the other way around.

[sandymc]

Adobe products do demosaicking as the very first step... so they have no idea about what profile you were going to apply later in UI (the only thing that might affect them is a selection of demosaicking method through : process 2003 - process 2010 - process 2012), what WB you are going to apply later (there are no WB before demosaicking in Adobe products), etc... so no ideas would be "off"... please correct me if I am wrong... and how exactly you are going to make WB w/ multipliers = 1... is WB = 2000/-150 really what somebody above claimed it is... it is just how Adobe's UI will try to display such WB in its UI, and not the other way around.

To have any adaptive demosaic, you have to have to be making decisions on what similar colors (technically, the distance in 3-space). In the "classic" AHD algo, that's done in LAB space. With a unity matrix, I'd think that LR would not get that right  .

I recall a conversation with Eric - in fact, I think on this forum - where he said that to do WB, LR/ACR go right back to raw data. Which surprised me at the time.

Sandy

[deejjjaaaa]

I recall a conversation with Eric - in fact, I think on this forum - where he said that to do WB, LR/ACR go right back to raw data. Which surprised me at the time.

and the speed of work really shows that they do not redemosaick data... ACR/LR can't afford to do that as they target slider happy populace.

[deejjjaaaa]

To have any adaptive demosaic, you have to have to be making decisions on what similar colors (technically, the distance in 3-space). In the "classic" AHD algo, that's done in LAB space.

the mere fact of linear DNG existence shows that flow is = demosaick -> prophoto/g1 -> (wb, camera profiles/hue twists, curves, NR, sharpening, etc)

[sandymc]

the mere fact of linear DNG existence shows that flow is = demosaick -> prophoto/g1 -> (wb, camera profiles/hue twists, curves, NR, sharpening, etc)

Well, actually, demosaic -> (WB/camera profile part 1) -> prophoto -> camera profile part 2, curves, etc  

The camera profile is the core of getting to proPhoto (no matrix, no proPhoto), but parts of the camera profile are also post proPhoto. E.g., the tables, which are effectively in proPhoto gamma 1 space

However, I'm not sure what the point of this is, other than academic interest - where ever the WB is in the chain, it's probably going to blow out if you use a unity matrix - many raw formats (DNG itself is a good example) encode WB as an XY point. If the matrix doesn't take you to a correct XY, and a unity matrix sure won't,  then WB is guaranteed to blow out in that case. If WB is encoded as sensor relative rather than XY, then you might be ok.

Sandy

[deejjjaaaa]

Well, actually, demosaic -> (WB/camera profile part 1) -> prophoto -> camera profile part 2, curves, etc  

The camera profile is the core of getting to proPhoto (no matrix, no proPhoto)

yes, certainly it is, there should be a camera specific matrix (in Adobe's case) to transform RGB to PCS/working space which for Adobe is Prophoto/G1

However, I'm not sure what the point of this is, other than academic interest

just interesting as to how close you can get to the real raw histogram in ACR/LR using Adobe's only tools (or tools like your utility to compile dcp files) ...

- where ever the WB is in the chain, it's probably going to blow out if you use a unity matrix - many raw formats (DNG itself is a good example) encode WB as an XY point. If the matrix doesn't take you to a correct XY, and a unity matrix sure won't,  then WB is guaranteed to blow out in that case. If WB is encoded as sensor relative rather than XY, then you might be ok.

but we do not need to use whatever camera's firmware writes about WB in raw files... some raw converters like Iridient Rawdeveloper, RPP and certainly some others will allow you to set WB directly as per channel multipliers and as such to eliminate any WB conversion at all...

[sandymc]

but we do not need to use whatever camera's firmware writes about WB in raw files... some raw converters like Iridient Rawdeveloper, RPP and certainly some others will allow you to set WB directly as per channel multipliers and as such to eliminate any WB conversion at all...

Yes, agreed, my comments were specific to the "LR reading a modified profile" situation.

Sandy