Luminous Landscape Forum
Raw & Post Processing, Printing => Adobe Lightroom Q&A => Topic started by: Jim Kasson on April 14, 2013, 01:36:43 pm
-
This may be old news to many of you, but I just stumbled on to it and nailed it down. The new(ish) Lightroom exposure control (Process Version 2012) works differently than the Exposure adjustment layer in Photoshop CS 6. While the Lightroom control gives you a convenient way to simulate the shoulder of the film DlogE curve, the Photoshop control works more like the old Lightroom Exposure control (Process version 2010).
The details:
I created a 1/3 stop step wedge in Matlab:
(http://www.kasson.com/ll/stepwedgeProg.PNG)
I added a gamma of 2.2, and converted the image to 16 bits per color plane, and wrote it out as a TIFF. I imported it into Lightroom as an Adobe RGB file, and exported TIFFs with the Exposure Control set at 0, +1 EV, +2 EV, +3 EV, and +4 EV. I brought those images into Photoshop and measured the L* (the luminance channel in CIELab) component of the leftmost steps in each image. Here's what I got:
(http://www.kasson.com/ll/stepwedgeLR.PNG)
You can see that the Lightroom Process Version 2012 exposure control tries to avoid blowing out the highlights, unlike increasing exposure in a digital camera. I consider this to be generally a good thing.
Next, I brought the step wedge into Photoshop CS6, added an Exposure adjustment layer, and observed the L* values with the Exposure control set at 0, +1 EV, +2 EV, +3 EV, and +4 EV. Here's what I saw:
(http://www.kasson.com/ll/stepwedgePS.PNG)
The Photoshop CS6 Exposure control works more like actually increasing the exposure in a digital camera.
The question this brings up for me is: which is the better way to develop deliberately underexposed images made using "ISO-less" or Unity Gain ISO exposure methods. I suspect the PS way is better if you're trying to simulate what you'd get if you just turned up the ISO, but that the Lightroom way is better if you want soft clipping of the high values, like you get with film. It will take some testing for me to figure this out.
-
The question this brings up for me is: which is the better way to develop deliberately underexposed images made using "ISO-less" or Unity Gain ISO exposure methods. I suspect the PS way is better if you're trying to simulate what you'd get if you just turned up the ISO, but that the Lightroom way is better if you want soft clipping of the high values, like you get with film. It will take some testing for me to figure this out.
Thanks for your excellent analysis, as usual.
One of the benefits of using "ISO-less" (with cameras where it makes sense) is that you keep the maximum DR so you have a lot of headroom for highlights. In this case I think the LR way is much better. If you do it the other way (PS or old LR) then you lose whatever you gained going "ISO-less".
Regards
-
Jim,
I got similar results with a photographed Stouffer stepwedge with 0.3 EV steps over a range of 40 steps, but using ACR instead of LR. PV2012 rolls off the highlights rather than clipping them (within limits). The +2 EV exposure adjustment places the highlights short of clipping. ACR uses a baseline offset of +0.5 EV for this camera, so one must use a negative exposure compensation of -0.5 EV to correct for this. The ACR preview for this exposure is shown along with results obtained with Imatest on the files rendered into sRGB.
The graph is log-log as with the classical H&D density plots, which is the default for Imatest.
Regards,
Bill
(http://bjanes.smugmug.com/Photography/ACR7/i-6jXMtmM/0/O/ACR_ScrCapExpNegHalf.png)
(http://bjanes.smugmug.com/Photography/ACR7/i-pgMJd2p/0/XL/ACR_ScrCapPlus2-XL.png)
(http://bjanes.smugmug.com/Photography/ACR7/i-PPtFFJx/1/O/ExpGraph.png)
-
One of the benefits of using "ISO-less" (with cameras where it makes sense) is that you keep the maximum DR so you have a lot of headroom for highlights. In this case I think the LR way is much better. If you do it the other way (PS or old LR) then you lose whatever you gained going "ISO-less".
I tend to agree. I think we've determined that LR PV 2012 does a good thing along the grey axis. I will do a little experimenting to see what happens to the two chrominance axes, and to luminance with chromatic inputs.
Jim
-
I got similar results with a photographed Stouffer stepwedge with 0.3 EV steps over a range of 40 steps, but using ACR instead of LR. PV2012 rolls off the highlights rather than clipping them (within limits). The +2 EV exposure adjustment places the highlights short of clipping. ACR uses a baseline offset of +0.5 EV for this camera, so one must use a negative exposure compensation of -0.5 EV to correct for this. The ACR preview for this exposure is shown along with results obtained with Imatest on the files rendered into sRGB.
Thanks, Bill. It's nice when synthetic and real images produce roughly the same results, and I appreciate your doing the testing. In addition to the real vs simulated test images, you also got some differences because you fed LR raw files, while I fed it TIFFs, and, as you pointed out, it's smart enough (or too smart, depending on your point of view) to apply some corrections automagically. I didn't go into the dark parts of the DlogE (aka H&D) curve, but if I had, I think it would have dropped off much further at low EV boost than the curves you posted, probably because of real world lens flare and surface effects of the wedge.
Jim
-
I spent most of the morning looking at color effects in the LightRoom PV 2012 Exposure control. I made a target consisting of a series of equally spaced patches in CIELab, with an L* of 50, and a* and b* running from -50 to +40 in steps of 10.
Here's the target:
(http://www.kasson.com/ll/EVtgt.PNG)
I imported the target into Lightroom, did nothing to it and exported it in ProPhoto RGB. Then I brought it into Photoshop and converted it to Lab, then brought it into Matlab and produced a scatter plot in 3D:
(http://www.kasson.com/ll/LRRT3D.PNG)
This looks pretty bad until you look at the L* scale. All the values differ infinitesimally.
Looking down from the top, you see this:
(http://www.kasson.com/ll/LRRT2D.PNG)
Now that we've established the baseline, let's see what happens with a +1EV Exposure boost. First in 3D:
(http://www.kasson.com/ll/EVP13D.PNG)
Except for the blues and greens, there is a fair amount of luminance rolloff that increases with chroma.
In 2D, it looks like this:
(http://www.kasson.com/ll/EVP12D.PNG)
The yellows and oranges are becoming more chromatic, and the magentas and blues less chromatic.
A +2 EV push gives this in 3D:
(http://www.kasson.com/ll/EVP23D.PNG)
And this in 2D:
(http://www.kasson.com/ll/EVP22D.PNG)
A three stop push gives this:
(http://www.kasson.com/ll/EVP33D.PNG)
and this:
(http://www.kasson.com/ll/EVP32D.PNG)
Now even the cyans are rolling off in luminance, but the greens are holding up. As you would wish, the chroma of all the samples is decreasing, with most of the loss in the lower right quadrant -- magentas and blues.
At four stops plus, we see this:
(http://www.kasson.com/ll/EVP43D.PNG)
and this:
(http://www.kasson.com/ll/EVP42D.PNG)
More of same, basically.
A nit-picker could ask for more consistant chroma scaling, but I think this is pretty good performance. We may be looking as some effects caused by the gamut of ProPhotoRGB.
Jim
-
For completeness, here's what happens when you use the Exposure control to pull.
-1EV:
(http://www.kasson.com/ll/EVM13D.PNG)
The reds are a little brighter than you'd like.
In 2D:
(http://www.kasson.com/ll/EVM12D.PNG)
Pretty good.
-2EV:
(http://www.kasson.com/ll/EVM23D.PNG)
In 2D:
(http://www.kasson.com/ll/EVM22D.PNG)
Also not bad.
Note that, because of the nature of CIELab, reducing the amount of light on a reflective surface will result in decreased a* and b* values as well as L*. The reverse is true for increasing the amount of light (a* and b* go up), but in the previous post, this effect was completely overridden by the reduction in chroma caused by the shoulder that Lightroom introduces near clipping.
Jim
-
Yesterday I posted some Lightroom exposure adjustment tests. I now realize that, informative as they were, at least to me, they didn't get directly at the question, "Which is the best exposure tool to use to adjust deliberately underexposed images, the one in Photoshop or the one in Lightroom?" I decided to create a test to answer that question.
The answer: the tool in Photoshop does less damage to the colors, and comes much closer to the tonality and colors that you'd get if you turned up the ISO in the camera. I'm sorry to report that them's the facts, because I really like the soft clipping in the Loghtroom tool.
Here's the experiment. I started with a similar target (11x11, this time) as yesterday, encoded in ProPhoto RGB, the space I normally for Photoshop processing and, except for the gamma, the native color space of Lightroom. I went to my camera simulator program, and created a new camera. It's in all respects like a Nikon D4, except that it has no noise except for electron and ADC quantizing noise, and a Fovean-like sensor that directly encodes the light into the ProPhoto RGB color space. I know, I know; you could never build a camera like that, especially since two of the PP RGB primaries aren't physically realizable, but I wanted to minimize color space conversions and errors due to demosaicing.
With my simulated camera, I made five exposures of the target, one at the exposure that replicated the target tonality, and one each at - 1EV, -2 EV, - 3EV, and -4 EV from the first exposure. All exposures were made at ISO 640, which is close to the unity gain ISO.
I opened each exposure in Lightroom, and used the exposure control to compensate the four underexposed images to about the same RGB values (in the middle of the image) as the normally exposed image. To my surprise, it didn't take exactly one EV of correction for each EV of underexposure; it took somewhat less.
I exported all the images from Lightroom in ProPhoto RGB, brought them into Photoshop and converted them to CIELab, then brought those images into Matlab and analyzed them.
First, I looked at the chromaticity -- only the a* and b* values. Here's the result of a four-stop Lightroom push:
(http://www.kasson.com/ll/EVLR42D.PNG)
and the result of a four-stop Photoshop push:
(http://www.kasson.com/ll/EVPS42D.PNG)
The results of the one, two, and three-stop pushes all share the quality that the Photoshop Exposure tool does less damage to the chromaticity relationships than the analogous Lightroom tool.
More 2D results here. (http://blog.kasson.com/?p=2964)
3D results here. (http://blog.kasson.com/?p=2970)
Jim
-
It's hard to compare the two directly. With Ps you can just run the Exposure step and evaluate the before & after. With Lr, you can't do that because Lr involves a whole pipeline of imaging steps, some of which you can't turn off (like white balance and camera color profiles for raw data). This is an important distinction because many of the imaging stages in Lr are interrelated and "talk" to each other. For example, as you increase the Exposure control in Lr (with PV 2012) and push values closer to the high end of the display range, Lr "realizes" that highlight values (and near-highlight values) need to be gamut-mapped (compressed) to minimize unpleasant visual changes.
As others have noted, PV 2003 or 2010 are much more linear (similar to Ps's Exposure) as you increase the Exposure control (a la in-camera ISO) but a side effect is that when individual color channels start to clip you get unsightly hue shifts (e.g., blue skies become cyan) and a sudden loss of color detail.
The linear behavior of a digital sensor is a physical reality but not necessarily a desirable visual characteristic.
-
BTW: interesting potential topic of discussion in about 10 days, right Jim?
-
BTW: interesting potential topic of discussion in about 10 days, right Jim?
Hum...what's gonna happen in about 10 days?
-
BTW: interesting potential topic of discussion in about 10 days, right Jim?
Right you are, Eric. That's the thing that's got me doing all these experiments. I've got to hold up my end of the bargain.
Looking forward to it...
Jim
-
Hum...what's gonna happen in about 10 days?
Jeff,
Eric, Charles Cramer, Brian Griffith, Lionel Kuhlmann, Rex Naden, and I are going to be doing a one-day workshop on raw processing in Menlo Park.
Here's a link. (http://www.photography.org/workshops/raw_panel.php)
Jim
-
For example, as you increase the Exposure control in Lr (with PV 2012) and push values closer to the high end of the display range, Lr "realizes" that highlight values (and near-highlight values) need to be gamut-mapped (compressed) to minimize unpleasant visual changes.
Eric,
Yes, but I don't think that's what's going on here. I'm just applying enough Exposure adjustment to get the L* values back to about 50. We're a long way from the highlights.
I'm thinking that maybe Lightroom PV 2012 wasn't designed with the correction of intentional underexposures of 3 or 4 stops (like you get when you're following Unity Gain ISO precepts) in mind, but you'd know a heck of a lot more about than than I do.
Jim
-
Eric, Charles Cramer, Brian Griffith, Lionel Kuhlmann, Rex Naden, and I are going to be doing a one-day workshop on raw processing in Menlo Park.
Ooooh, that sounds like fun...if you haven't met Eric yet, you will be charmed! Wish I could make it but I'm in book hell :~(
-
Thanks, Bill. It's nice when synthetic and real images produce roughly the same results, and I appreciate your doing the testing. In addition to the real vs simulated test images, you also got some differences because you fed LR raw files, while I fed it TIFFs, and, as you pointed out, it's smart enough (or too smart, depending on your point of view) to apply some corrections automagically. I didn't go into the dark parts of the DlogE (aka H&D) curve, but if I had, I think it would have dropped off much further at low EV boost than the curves you posted, probably because of real world lens flare and surface effects of the wedge.
Jim
Jim,
Your simulations are quite sophisticated and interesting. You might want to apply them to PV2010 as well. Here are data from the same image with PV2010. As Eric stated, it is more linear than PV2010 and lets the highlights clip. As per Eric's comment, how do you handle the camera profile in your simulations?
You are correct about flare. It does lift the shadows even when I mask off the surround of the wedge, as shown by non-linearity in the shadow portion of the graph. The lens was the Nikkor 60 mm f/2.8 AFS which is multicoated and has the Nano coating on selected elements as well, so should have relatively low flare. With the surround of the light table not masked off, flare is quite prominent. Imatest does have an ability to measure veiling flair, but thus far I have not implemented it in my setup.
Bill
-
You are correct about flare. It does lift the shadows even when I mask off the surround of the wedge, as shown by non-linearity in the shadow portion of the graph. The lens was the Nikkor 60 mm f/2.8 AFS which is multicoated and has the Nano coating on selected elements as well, so should have relatively low flare. With the surround of the light table not masked off, flare is quite prominent. Imatest does have an ability to measure veiling flair, but thus far I have not implemented it in my setup.
Hi Bill,
Nothing new for you, but I can confirm that in every day practice, veiling glare makes a difference. It's a major killer of dynamic range if we are not careful. For critical work, one should attempt to limit the amount of ambient light that enters the front lens element to only the image forming rays, as much as practical. An unpleasantly deep lens shade may help (I use a Lee universal hood if the situation allows). That only leaves direct light-sources in the image to do their thing, but due to the angle of incidence, they are more likely to be affected by the lens coatings.
Cheers,
Bart
-
Hi Bill,
Nothing new for you, but I can confirm that in every day practice, veiling glare makes a difference. It's a major killer of dynamic range if we are not careful. For critical work, one should attempt to limit the amount of ambient light that enters the front lens element to only the image forming rays, as much as practical. An unpleasantly deep lens shade may help (I use a Lee universal hood if the situation allows). That only leaves direct light-sources in the image to do their thing, but due to the angle of incidence, they are more likely to be affected by the lens coatings.
Cheers,
Bart
Bart,
Thanks for the input, which prompts me to post a test I did previously with the Nikon D3. I photographed the Stouffer wedge with and without masking off the glare from the light table as shown and checked the DR with Imatest and there was hardly any difference despite the contaminated shadows from glare in the unmasked shot.
(http://bjanes.smugmug.com/Photography/Imatest/D800e-DR/i-zqSd3nP/0/O/small_comp.png)
(http://bjanes.smugmug.com/Photography/Imatest/D800e-DR/i-vJMv4Hm/0/O/03_08.png)
Imatest was able to detect the same number of steps and apparently computed the DR on this basis. However, the usual definition of DR involves the brightest highlight and deepest shadow for a given noise floor. Looking at the Imatest raw data for the patches in question, the sRGB values are shown in the table and converted to linear via the inverse sRGB function. The computed DRs are shown. As a check, I looked at the values in Rawdigger and got the same values for DR. There is a 3 stop difference in DR.
(http://bjanes.smugmug.com/Photography/Imatest/D800e-DR/i-HKLLgVH/1/O/ImatestRawdigger.png)
Regards,
Bill
-
You might want to apply [the simulations] to PV2010 as well.
Good idea, Bill. I'll do that.
As per Eric's comment, how do you handle the camera profile in your simulations?
I don't think LR uses a camera profile for the files I'm importing. Let me tell you exactly what I do, and then maybe you can comment on whether or no I'm right about that. I export the ProPhoto RGB image from Matlab as a 16=bit TIFF without a profile. I haven't figured out how to add the profile in Matlab, so I bring the image into Photoshop and attach the PPRGB profile. Then I save it as a 16-bit TIFF. I import the file into Lightroom, and export it with no corrections, still in PPRGB, just to make sure that LR isn't doing some automagic processing that's interfering with what I'm trying to measure. Then I apply the Exposure adjustments, exporting each corrected image as before. Then I bring all the LR-exported images into Photoshop and convert them to Lab. I save all the Lab images, bring them into Matlab, and make the plots.
The image with no LR Exposure corrections looks like the image that I imported into LR ins the first place, which is what makes me think that there is no camera profile applied by LR. This also makes sense to me, since you wouldn't want LR to do something to a finished TIFF image that you imported into LR just to use it's cataloging ability.
Does that make sense to you?
Jim
-
Imatest was able to detect the same number of steps and apparently computed the DR on this basis.
Hi Bill,
Thanks for the examples. They show that the DR is detectable, but no longer approx. linear, and as such the details in the shadows will have less micro-contrast (and be more sensitive to noise).
However, the usual definition of DR involves the brightest highlight and deepest shadow for a given noise floor. Looking at the Imatest raw data for the patches in question, the sRGB values are shown in the table and converted to linear via the inverse sRGB function. The computed DRs are shown. As a check, I looked at the values in Rawdigger and got the same values for DR. There is a 3 stop difference in DR.
(http://bjanes.smugmug.com/Photography/Imatest/D800e-DR/i-HKLLgVH/1/O/ImatestRawdigger.png)
Indeed, and that is mostly caused by glare from image forming rays which are more efficiently controlled by the lens coatings than the oblique outside the view angle ones that tend to bounce round between or inside lens elements and lens edges and retaining rings. That loss of contrast is a pity if avoidable by using better technique.
Cheers,
Bart
-
Your simulations are quite sophisticated and interesting. You might want to apply them to PV2010 as well.
Bill, I did a run with PV2010. The chromaticity errors associated with the 1 through 4 stop pushes on the middle luminance tones are roughly the same as with PV 2012;
The plots are here. (http://blog.kasson.com/?p=2980)
I'm thinking about computing the chromaticity delta-Es and summing them as a measure of overall accuracy in the chromaticity plane. In order to make it fair, I'll have to calibrate out the effects of my not getting the mean L* values back to exactly 50 in each of the pushes.
Jim
-
I'm thinking about computing the chromaticity delta-Es and summing them as a measure of overall accuracy in the chromaticity plane. In order to make it fair, I'll have to calibrate out the effects of my not getting the mean L* values back to exactly 50 in each of the pushes.
I did that work this afternoon. Well, almost. I decided to compute the average total error over the 121 patches, not just the chromaticity error. Here's the result:
(http://www.kasson.com/ll/ErrorvsPush.PNG)
To get the curves, I corrected all the values in the sample images by dividing them by the ratio of the mean of the luminance values in the sample image and the mean of the luminance values in the test (exposed for a 0 EV push) image. That corrects for Exposure slider settings that aren't quite right.
Jim
-
Good idea, Bill. I'll do that.
I don't think LR uses a camera profile for the files I'm importing.
The image with no LR Exposure corrections looks like the image that I imported into LR ins the first place, which is what makes me think that there is no camera profile applied by LR. This also makes sense to me, since you wouldn't want LR to do something to a finished TIFF image that you imported into LR just to use it's cataloging ability.
Does that make sense to you?
Jim
Jim,
Yes, it does. When I brought the subject of camera profiles in the context of TIFFs, I wasn't thinking clearly. Rereading Eric's post confirms that they would not be used with TIFFs. Demosaicing and conversion of the camera primaries to the working space have already been performed at the TIFF stage.
Regards,
Bill
-
As others have noted, PV 2003 or 2010 are much more linear (similar to Ps's Exposure) as you increase the Exposure control (a la in-camera ISO) but a side effect is that when individual color channels start to clip you get unsightly hue shifts (e.g., blue skies become cyan) and a sudden loss of color detail.
The linear behavior of a digital sensor is a physical reality but not necessarily a desirable visual characteristic.
What about changing the baseline exposure in the DNG profile? Will it behave like a linear adjustment as in-camera ISO?
-
The issue with using ACR/LR to test with normal TIFF files created externally is that ACR/LR assumes they are output-referred (i.e., already tone mapped). Thus it is true that the Exposure control may not be linear and have unintended side effects, because ACR/LR has to make a guess as to the scene-to-output referred mapping.
If you want to use TIFFs for doing this type of testing I would suggest you use floating-point TIFFs (not 16-bit integer) or use linear DNG.
-
Put another way: the current ACR/LR testing path on your TIFF files is going thru a different image processing path than compared to processing raw files.
-
I did that work this afternoon. Well, almost. I decided to compute the average total error over the 121 patches, not just the chromaticity error. Here's the result:
(http://www.kasson.com/ll/ErrorvsPush.PNG)
To get the curves, I corrected all the values in the sample images by dividing them by the ratio of the mean of the luminance values in the sample image and the mean of the luminance values in the test (exposed for a 0 EV push) image. That corrects for Exposure slider settings that aren't quite right.
Jim,
A delta E of 6 is significant. I'm no color expert, but the details of the calculation would be of interest since delta E includes luminance, chroma, and hue as briefly explained by Norman Koren in his Colorcheck documentation (http://www.imatest.com/docs/colorcheck_ref/#colorerr) (that is about all I know about the subject). It is well documented that ACR does increase saturation as exposure is increased and this is by design, as it is preferred by many users. However, a shift in hue is unwelcome by most.
Regards,
Bill
-
. I'm no color expert, but the details of the calculation would be of interest since delta E includes luminance, chroma, and hue...
Given two values in CIEL*a*b*, L1, a1, b1, and L2, a2, b2, the CIEL*a*b* Delta-E is:
sqrt((L1-L2)^2 + (a1-a2)^2 + (b1-b2)^2)
Stated in words, it is the distance in three-space between the two values plotted in Cartesian coordinates.
It is well documented that ACR does increase saturation as exposure is increased and this is by design, as it is preferred by many users. However, a shift in hue is unwelcome by most.
There is no measure of saturation in CIEL*a*b*. There are good technical reasons for this, which I won't go into unless requested to do so. There is one in CIEL*u*v*, but Photoshop doesn't support that system, and most photographers aren't familiar with it. Some have suggested that a saturation measure for Lab might look like this (dropping the stars):
PseudoSat = Sqrt(a^2 + b^2) / L
My tests indicated that Lightroom does not increase this quantity upon increasing exposure. It does -- and should -- increase chroma, defined as:
Chroma = Sqrt(a^2 + b^2)
If you imagine CIELab in cylindrical coordinates instead of Cartesian ones, luminance goes up and down, hue is the angle, and chroma is the radius.
If you look at the actual color plots, you can see that there is no general chroma or hue shift, just shifts that affect both.
Eric has put my testing methodology into question, and I'm going to have to fall back and regroup.
Jim
-
Given two values in CIEL*a*b*, L1, a1, b1, and L2, a2, b2, the CIEL*a*b* Delta-E is:
sqrt((L1-L2)^2 + (a1-a2)^2 + (b1-b2)^2)
Stated in words, it is the distance in three-space between the two values plotted in Cartesian coordinates.
There is no measure of saturation in CIEL*a*b*. There are good technical reasons for this, which I won't go into unless requested to do so. There is one in CIEL*u*v*, but Photoshop doesn't support that system, and most photographers aren't familiar with it. Some have suggested that a saturation measure for Lab might look like this (dropping the stars):
PseudoSat = Sqrt(a^2 + b^2) / L
My tests indicated that Lightroom does not increase this quantity upon increasing exposure. It does -- and should -- increase chroma, defined as:
Chroma = Sqrt(a^2 + b^2)
If you imagine CIELab in cylindrical coordinates instead of Cartesian ones, luminance goes up and down, hue is the angle, and chroma is the radius.
If you look at the actual color plots, you can see that there is no general chroma or hue shift, just shifts that affect both.
Eric has put my testing methodology into question, and I'm going to have to fall back and regroup.
Jim
Jim,
Did you look at Norman's writeup? He does separate total delta E into components. I will have to study the details.
Just for fun, I exposed a Colorchecker under Solux illumination at nominal exposure, and at -1, -2, -3, and -5 EV. I then used ACR 7.4 with PV2012 at default settings and the Adobe Standard profile and looked at the results with Imatest. I adjusted exposure so that the white patch was 236 in AdobeRGB (the nominal value according to Bruce Lindbloom's measurements). The -4 EV exposure on the camera LCD looked quite dark and the chart was hardly recognizable, but the resulting images after correction looked quite good and the color values were hardly different with increasing ACR correction. According to these tests, ACR works well for underexposed images, but the results do show relatively large constant color errors and I should probably use the DNG profile editor.
Nominal
(http://bjanes.smugmug.com/Photography/Macbeth-Under-Exp/i-brKNmDP/0/O/Img_0003_colorerror.png)
1 stop underexposed
(http://bjanes.smugmug.com/Photography/Macbeth-Under-Exp/i-NsX2Wsq/0/O/Img_0006_colorerror.png)
2 stops underexposed
(http://bjanes.smugmug.com/Photography/Macbeth-Under-Exp/i-NDX7GLj/0/O/Img_0007_colorerror.png)
3 stops underexposed
(http://bjanes.smugmug.com/Photography/Macbeth-Under-Exp/i-zTZB9nS/0/O/Img_0008_colorerror.png)
4 stops underexposed
(http://bjanes.smugmug.com/Photography/Macbeth-Under-Exp/i-Mppc8rm/0/O/Img_0009_colorerror.png)
Tabular Results
(http://bjanes.smugmug.com/Photography/Macbeth-Under-Exp/i-zJKhHFK/0/O/ResultsTable.png)
Regards,
Bill
-
Did you look at Norman's writeup? He does separate total delta E into components.
Yes, there are additional standard color differences. I thought about doing the chrominance delta E, or DeltaEab, and I'm glad that I didn't now, since Eric has said that my test methodology is flawed because I used TIFFs.
Just for fun, I exposed a Colorchecker under Solux illumination at nominal exposure, and at -1, -2, -3, and -5 EV. I then used ACR 7.4 with PV2012 at default settings and the Adobe Standard profile and looked at the results with Imatest. I adjusted exposure so that the white patch was 236 in AdobeRGB (the nominal value according to Bruce Lindbloom's measurements). The -4 EV exposure on the camera LCD looked quite dark and the chart was hardly recognizable, but the resulting images after correction looked quite good and the color values were hardly different with increasing ACR correction. According to these tests, ACR works well for underexposed images, but the results do show relatively large constant color errors and I should probably use the DNG profile editor.
Good work, Bill! I had been resisting using actual camera images because of the extra noise introduced, the difficulty in making the measurements, and the greater possibility of tester (that would be me) error. I think I'm going to have to bite the bullet and stop using the synthetic images. It would be different if I had a way to make DNG files (or, even better, NEF files) but I don't.
I wouldn't worry about the color errors that are constant throughout the image set. We' re trying to find out how useful LR is for the pushes we're likely to see with Unity Gain ISO exposure techniques, not how accurate the camera is in general at capturing accurate color.
In order to see how the color errors vary with exposure without looking at the effects of the overall errors, is is possible for you to compare just the values of the patches in the various images without looking at how far away they are from the original?
Thanks for going to the trouble of doing this testing!
Jim
-
The issue with using ACR/LR to test with normal TIFF files created externally is that ACR/LR assumes they are output-referred (i.e., already tone mapped). Thus it is true that the Exposure control may not be linear and have unintended side effects, because ACR/LR has to make a guess as to the scene-to-output referred mapping.
If you want to use TIFFs for doing this type of testing I would suggest you use floating-point TIFFs (not 16-bit integer) or use linear DNG.
Eric, although all my Matlab calculations are done with double precision floating point images, imwrite can't write a floating point TIFF file. I'm not sure that would solve the problem anyway, since they'd still be viewed by LR as output-referred. I don't have any tools that can write DNG files. I think I'm going to have to stop using synthetic images and suffer all the tribulations of using real camera images.
I can use a screen target or a printed target. I think the screen target would be more accurate, but I'd either have to defocus or do a lot of averaging. If I defocused, I couldn't vary the exposure by varying the f-stop, because the lens circle of confusion would change over the series. Actually, now that I think about it, I can't vary the exposure by changing the aperture, because that will change the light falloff away from the lens axis. Using exposures of faster than 1/30 on an LCD monitor is unsafe in terms of repeatability, but I could go from a second to 1/30, and that will give me five stops.
I could make an exposure at 1 second at the unity gain ISO, then decrease the exposure progressively: 1/2, 1/4, 1/8, 1/15, 1/30. As a control, I could do the same series increasing the ISO one stop for every change in shutter speed. Then I could bring the raw files into LR, develop them, and export them as TIFFs. Then I can read them into PS, convert them to Lab, and save them. Then I could bring them into Matlab, do filtering (probably with an nxn kernal where all the values are 1/n^2), resampling, correction for actual in-camera exposure errors, correction for Exposure adjustment setting errors (those two are the same correction), measurement, error computation, and statistics calculation.
Does that methodology make sense to you?
Jim
-
Yes, there are additional standard color differences. I thought about doing the chrominance delta E, or DeltaEab, and I'm glad that I didn't now, since Eric has said that my test methodology is flawed because I used TIFFs.
Good work, Bill! I had been resisting using actual camera images because of the extra noise introduced, the difficulty in making the measurements, and the greater possibility of tester (that would be me) error. I think I'm going to have to bite the bullet and stop using the synthetic images. It would be different if I had a way to make DNG files (or, even better, NEF files) but I don't.
I wouldn't worry about the color errors that are constant throughout the image set. We' re trying to find out how useful LR is for the pushes we're likely to see with Unity Gain ISO exposure techniques, not how accurate the camera is in general at capturing accurate color.
In order to see how the color errors vary with exposure without looking at the effects of the overall errors, is is possible for you to compare just the values of the patches in the various images without looking at how far away they are from the original?
Thanks for going to the trouble of doing this testing!
Jim
Jim,
I repeated the tests with PV2010 using a linear tone curve and a profile created with Xrite Passport. In previous testing, I have found that PV2010 with a linear profile gives the most accurate results.
The graphical results show values for each patch of the Colorchecker. Differences lying radially from the white point indicate chroma differences, whereas hue shifts show a skew from the radial direction. The results are also shown in tabular form, using CIEDE2000 terms. The Delta E ab includes luminance. The Delta C omits luminance and the Delta C (corr) includes correction for chroma boost. The 4 stop push does not affect the colors that much. Is this the information you wanted?
Regards,
Bill
PV2010 Passport Profile, Nominal Exposure
(http://bjanes.smugmug.com/Photography/Macbeth-Under-Exp/i-sb2qqCz/0/O/Img_0003_PV2010_pp_colorerror.png)
PV2010 Passport Profile, 4 Stop Push
(http://bjanes.smugmug.com/Photography/Macbeth-Under-Exp/i-m4HjrWx/0/O/Img_0009_PV2010_pp_colorerror.png)
Tabular Results
(http://bjanes.smugmug.com/Photography/Macbeth-Under-Exp/i-CGT4FMH/1/O/Table3.png)
-
If you're wanting to look at Hue differences, Lch equations would be much more useful (Luminance, chromaticity, hue). Delta E for Lab coordinates are useful, but you have to look at the specific coordinates to determine where the shift is taking place, as the axix for Lab is always expressed as L(lightness,darkness), a(red,green), and b(yellow,blue). Lch on the other hand, is just what it says. Chroma in a blue results in the c expressing yellow/blue, whereas in a red the c will be expressing red/green shift. If you want a 1 number equation that works pretty well at giving you a number that correlates with human "satisfaction" of of color difference, take a look at the CMC equation, preferably weighted with a 2:1 ration on the chroma and hue, meaning the hue "matters" twice as much as the chroma of a color where humans detecting color difference is concerned. In general, a CMC color difference of 1.0 unit or so is very close visually whereas 1.0 DE Cielab can be objectionable dependent on which axis is showing the majority of the difference.
I believe this is the topic you guys are discussing regarding how the exposure slider is working in Lr PV2012.
***I understand part of this is how Lr behaves in comparison to Ps, which is something I didn't do.
-
If you're wanting to look at Hue differences, Lch equations would be much more useful (Luminance, chromaticity, hue). Delta E for Lab coordinates are useful, but you have to look at the specific coordinates to determine where the shift is taking place, as the axix for Lab is always expressed as L(lightness,darkness), a(red,green), and b(yellow,blue).
John, when I redo the tests with a real camera instead of a simulated one, I'll present the results several different ways, since there is apparently interest in that. I've always found that these measures are best supplemented by looking at the actual 2D and 3D shifts. I presented both 2D and 3D plots earlier, as well as links to more. I think that I'll at least continue to present the links. I'm conscious of the fact that presenting a slew of graphs on this forum may be way more than most people want to see.
There is a problem with presenting 2D and 3D scattergrams with the real camera results. If not calibrated out, the grid for the "no push" or reference image will not be regular. I'm thinking that the way to handle that is to calculate the shifts from the reference image, apply those shifts to the canonical image which created the target (and has a regular grid in CIEL*a*b*), and plot that. Does anyone have a comment of that approach?
Jim
-
John, when I redo the tests with a real camera instead of a simulated one, I'll present the results several different ways, since there is apparently interest in that. I've always found that these measures are best supplemented by looking at the actual 2D and 3D shifts. I presented both 2D and 3D plots earlier, as well as links to more. I think that I'll at least continue to present the links. I'm conscious of the fact that presenting a slew of graphs on this forum may be way more than most people want to see.
There is a problem with presenting 2D and 3D scattergrams with the real camera results. If not calibrated out, the grid for the "no push" or reference image will not be regular. I'm thinking that the way to handle that is to calculate the shifts from the reference image, apply those shifts to the canonical image which created the target (and has a regular grid in CIEL*a*b*), and plot that. Does anyone have a comment of that approach?
Jim
Jim,
First I'll say I haven't fully digested what you have already done, which on the surface appear to be a lot of work, and accurate work. I only wanted to throw my .02 out there in reference to the color equations. I'm not even sure what options for color equations you have in some of the software you are using (I haven't used those personally). I think however, if the point of this exercise is to establish how the exposure sliding is operating with respect to rolling off highlights and/or the color shifts that result, that you will be well served to (in addition to the charts) present the data with actual Lab coordinates. I realize you can't do that for everypoint or color in an image, but you could probably choose 2 o3 three primary colors, and perhaps 2 or 3 spots with the same colors but lower chromaticity. I could be way off base here I'm just sort of speculating based on how some other things work but...
I suspect where you will see the largest shift is in the higher chroma areas that are approaching the edge of the color space and are on the verge of clipping? Is the shift related to the rolling off to prevent that? I think the lower chroma colors will perhaps behave in a more linear fashion, at least until such time as they start to approach the clipping point as well. If you actually put the Lab data for a few points in a tabular format, it will be relatively easy to see whether the shift is chroma and or the more objectionable hue shift. Again, that will depend on the color chosen and that has to be taken into account if the data being reviewed is Lab. Things like saturation/chroma cannot be fully expressed with the Lab equation to the extent of looking at one piece of the measurement, so seeing the three data points would be necessary to accurately interpret the results.
If you guys would let me know what software you're using I would be happy to assist. I'll say up front you guys probably know far more about electronic imaging than I do. I do know color and the various methods of measuring it very well however, so I might be able to assist in that area. Now I need to go take a closer look at the latest charts you posted, since they came in while I was typing my previous post :)
**I should be more clear, when I said a table of the measurements I meant the absolute Lab values as opposed to calculated differences.
-
I'm not even sure what options for color equations you have in some of the software you are using (I haven't used those personally).
Matlab is a programming language optimized for manipulating matrices. You can view a color image as a nxmx3 matrix. The good news is: I can implement any color measure I want. The bad news is: I have to program it all myself.
I suspect where you will see the largest shift is in the higher chroma areas that are approaching the edge of the color space and are on the verge of clipping? Is the shift related to the rolling off to prevent that?
No, it is not. I deliberately picked not-very-chromatic colors. The grid is L* = 50, a* and b* from -50 to +40 in steps of 9, for an 11x11 grid, or 121 points. That everything is well within the PP RGB gamut is indicated by the Exposure adjustment layer in PS working so well in that color space.
I think the lower chroma colors will perhaps behave in a more linear fashion, at least until such time as they start to approach the clipping point as well.
The colors that experience the greatest chromatic shift are not the most chromatic, but the ones near a* = 0, b* = -50.
If you actually put the Lab data for a few points in a tabular format, it will be relatively easy to see whether the shift is chroma and or the more objectionable hue shift.
Go look at the scatter plots. I think you can get this information from them.
Things like saturation/chroma cannot be fully expressed with the Lab equation to the extent of looking at one piece of the measurement, so seeing the three data points would be necessary to accurately interpret the results.
Yep, that's the reason for the 3D scatterplots.
I do know color and the various methods of measuring it very well however, so I might be able to assist in that area.
If you're professionally involved in color science, we may have some mutual friends, although I've been out of the field since 1995. I worked on device-independent color, color management, and color image processing research at the IBM Almaden Research Center for six years, and worked with folks from Kodak, Adobe, Xerox PARC, Apple, and hp.
Jim
-
Eric, I'm just getting started on this and already I can see that you're right about the Exposure control working differently for raw file and for TIFFs. The amount of Exposure adjustment needed in LR PV2012 for the raw files is the same as the amount of underexposure of those files. With the TIFFs, that much Exposure adjustment results in too-bright images.
Jim
-
Jim,
We may indeed, although I actually work in plastics (color for plastics) so color science is a large part of what we do from a product design standpoint. We work with pigments and dyes however, to achieve specific colors in various polymers. I use to know quite a few people at Datacolor, as well as Macbeth. I'm sort of beyond the hands on stuff these days however so my contacts are pretty old.
I may be entirely missing the point here, but... I just ran a quick test I THINK along the same lines of what you guys are doing above. I took 4 shots of a Colorchecker chart, one exposed correctly, then 3 more underexposed shots (in 1 unit increments). I imported these into Lr5 Beta since I can see actual Lab coordinates there, and measured all 18 color swatches, as well as the 1 white. I used the correctly exposed image as a control, then pushed the 3 stop underexposed image by 3 stops (which came out exactly where it should btw). While I do see some color difference between the two, indicating that Lr is doing a little in the pushing process, they are not nearly as dramatic as what I believe I see in the charts above. Most of the total DE's are in the ~1.50 range, except for the bright yellow swatch which is ~5 units.
**I understand part of this is comparing the behavior between Lr and Ps, which is something I didn't do.
This is interesting.
John
-
I just ran a quick test I THINK along the same lines of what you guys are doing above. I took 4 shots of a Colorchecker chart, one exposed correctly, then 3 more underexposed shots (in 1 unit increments). I imported these into Lr5 Beta since I can see actual Lab coordinates there, and measured all 18 color swatches, as well as the 1 white. I used the correctly exposed image as a control, then pushed the 3 stop underexposed image by 3 stops (which came out exactly where it should btw). While I do see some color difference between the two, indicating that Lr is doing a little in the pushing process, they are not nearly as dramatic as what I believe I see in the charts above. Most of the total DE's are in the ~1.50 range, except for the bright yellow swatch which is ~5 units.
Sounds like what I'm doing without all the programming. I'm a bit behind you here. I have all the images in Lab in PS, and I'm about to align them.
Jim
-
We may indeed, although I actually work in plastics (color for plastics) so color science is a large part of what we do from a product design standpoint. We work with pigments and dyes however, to achieve specific colors in various polymers. I use to know quite a few people at Datacolor, as well as Macbeth.
I still have my copy of Wyszecki and Styles, although it doesn't get much use these days...
Jim
-
Sounds like what I'm doing without all the programming. I'm a bit behind you here. I have all the images in Lab in PS, and I'm about to align them.
Jim
I'd be happy to post my spreadsheet assuming I can figure out how to get into a format I can host at smugmug. I thought pdf would work, but no.
When all else fails, take a picture :) This is the data from the aforementioned quick test I did.
(http://www.cothronphotography.com/photos/i-VLSCcr6/0/XL/i-VLSCcr6-XL.jpg)
-
Well, I have the results, and they pretty much echo what Bill and John came up with. Here they are:
(http://www.kasson.com/ll/ErrorvsPushraw.PNG)
I've plotted the mean error in CIEL*a*b* Delta-E, the worst case error, and the mean plus two standard deviations for the 121 point sample target. I could do more work to present scatter plots, DeltaEab, hue angle shifts, Lch, CMC, and all the rest of it, but the errors are so small that I'm pretty sure that it's not worth the effort.
Why are the errors for no push so big? Because I used a different exposure for the baseline image and the test image. That tells me that we're pretty much just looking at noise here.
Thanks to Eric for setting me on the path to working with the real raw files, and for pointing out that TIFF images have a different processing pipeline.
In a way, I'm sorry that I sounded the alarm based on TIFF images, which turned out to be a red herring. On the other hand, I've learned a lot from this exercise. I hope you folks don't think I've wasted your time, and I apologize if you think I have.
Jim
-
Not at all, I've found it exceedingly interesting actually. It's not often in life (outside of business) I see people talking color equations and calculation :)
-
Why are the errors for no push so big? Because I used a different exposure for the baseline image and the test image. That tells me that we're pretty much just looking at noise here.
Jim,
I'm not clear on what you are using as your "standard" in this case? I assumed, perhaps incorrectly, that your standard was an image with no exposure adjustment, and the 2,3,4 stop pushes were compared back to that. In light of your statement here I'm a little confused.
***Nevermind, I realize now that I'm looking at a group of data for 121 patches as opposed to a single color. I didn't read completely my mistake.
-
I'd be happy to post my spreadsheet assuming I can figure out how to get into a format I can host at smugmug. I thought pdf would work, but no.
When all else fails, take a picture :) This is the data from the aforementioned quick test I did.
(http://www.cothronphotography.com/photos/i-VLSCcr6/0/XL/i-VLSCcr6-XL.jpg)
John,
Here are my results using Imatest and consolidating the data in an Excel spreadsheet. The results are similar to yours and confirm that the exposure adjustment causes little color shift.
(http://bjanes.smugmug.com/Photography/Macbeth-Under-Exp/i-gCQKc47/0/O/Table5.png)
Bill
-
Hi Jim,
ACR/Lightroom assume that integer TIFFs (the vast majority of TIFFs are written as integer TIFFs) are output-referred, and that floating-point TIFFs are scene-referred (e.g., HDR files). The bit depth itself is not critical (ACR/LR will read 16-bit, 24-bit, and 32-bit floating-point formats for TIFF and DNG), but the data type itself (floating-point vs integer) matters to the default interpretation.
Hope this helps,
Eric
-
John,
Here are my results using Imatest and consolidating the data in an Excel spreadsheet. The results are similar to yours and confirm that the exposure adjustment causes little color shift.
(http://bjanes.smugmug.com/Photography/Macbeth-Under-Exp/i-gCQKc47/0/O/Table5.png)
Bill
Thanks Bill, much of our data look very very similar. I'm curious, you have a column that is labeled "ideal". Where does that ideal data come from?
-
John,
Ideal comes from Imitest and represents the nominal values for the Colorchecker patches.
Bill
-
ACR/Lightroom assume that integer TIFFs (the vast majority of TIFFs are written as integer TIFFs) are output-referred, and that floating-point TIFFs are scene-referred (e.g., HDR files). The bit depth itself is not critical (ACR/LR will read 16-bit, 24-bit, and 32-bit floating-point formats for TIFF and DNG), but the data type itself (floating-point vs integer) matters to the default interpretation.
Thanks, Eric, that makes sense to me. I'm still trying to figure out how to produce synthetic 32-bit floating-point TIFF files. I can make 32-bit FITS files, but I can't figure out how to convert them to TIFFs. I may need to buy another program.
On the real image front, you probably saw the results with all the noise. I am now in the process of figuring our how to remove most of that noise, with pretty good success so far. The best thing seems to be to use a median filter with an extent the same as the patch size, Because it's a median filter, it won't mater if the alignment isn't perfect and I get a few rows or columns of an adjacent patch. The current problem is that the filters for one set of images takes about 8 hours to run. I am going to have to recode so that I isolate each patch and calculate the median of that sub-image. That will take me a while. I will use the results of the real median filter runs to provide a exemplar result when debugging.
One tricky thing about using real images is just dawning on me. After I do the image alignment step, which I need to do because I'm using a 180mm lens to keep the angle subtended by the target small, the pixels in the camera appear at different places on the sample images. That means that I have to filter out PRNU and dust more than what I have to deal with were the images perfectly aligned as shot.
Perhaps you could talk about how the output-referred and scene-referred pipelines differ next weekend.
Thanks for your help,
Jim
-
I have some progress to report, and some preliminary conclusions.
I modified the Matlab program to calculate the medians of each patch individually, rather than passing a median filter over the whole image. That reduced the run times from 8 hours to 5 seconds, and most of that time was file reading; the actual media calculations take a little over a second. The results were the same to 9 decimal places. I looked at the results. I'm pretty sure I have successfully dealt with the random noise, as evidenced by scatter plots that are smooth rather then jittery. However, the graph of the statistics is barely changed from the one I posted above. This means that I have not dealt with capture variation well.
In the past, I've handled capture variation by averaging multiple exposures. I am loath to do that here, since the image manipulations are already fairly labor intensive. Instead, I plan to focus on working with synthetic images. Since they are almost noiseless (maybe a little LSB toggling in integer TIFFs), I'll have fewer images to deal with than if I have to do averaging. In addition, I will be able to precisely place the colors in CIELab., which you can't do with a real camera, due to the nature of the filters in the CFA. These errors can't be entirely calibrated out with camera profiles, since the CFA's spectral responses are not a 3x3 matrix multiply away from those of the human cone cells.
In order to present LR with images that it will process as it does raw files, I will have to learn how to create floating-point TIFFs (thank you, Eric, for the pointer here). I have discovered a TIFF object in Matlab that lets you do things that the image file writing function, imwrite, won't normally let you do, including, reportedly, writing 32-bit floating point TIFFs. However, before I do that, I will have to learn a lot about TIFF tags and the LabTIFF library.
The discovery that there are at least two image-processing pipelines in Lightroom (Eric, are there more than two?) makes me more motivated than ever to devise techniques to discover what LR is doing in various circumstances. Photoshop is not completely open about its image processing algorithms, but at least you can turn on or off each layer individually and see the effects. In LR, all the image processing takes place inside a black box, and the user can't see inside that box.
Jim
-
Hi Jim,
There are really just two paths in ACR/Lr: one for scene-referred images, and one for output-referred images.
Examples in the former group (scene-referred) include raw files and HDR images (e.g., floating-point images that are created by Merge to HDR Pro in Ps if you choose the 32-bit option in the dialog, or any third-party software that does exposure merges and lets you save out a floating-point linear image).
Examples in the latter group (output-referred) include -- well, everything else! In-camera JPEGs, film scans, web PNGs, etc.
-
There are really just two paths in ACR/Lr: one for scene-referred images, and one for output-referred images.
Thanks, Eric. I'm getting close. I can now write 32-bit floating point TIFFs and read them into Photoshop, and assign the ProPhotoRGB profile to them. However, although the RGB values as seen through the eyedropper match the RGB values of the 16-bit integer TIFF I started with, the image doesn't look the same, and the CIELab values as seen through the eyedropper are different.
I've been assuming that, with a floating point TIFF, that the white point is 1.0,1.0,1.0, not 255,255,255 or 65535, 65535, 65535, and the fact that I'm seeing something close to right seems to verify that. If I write an image with a gamma of 1 and tell PS it's in PPRGB, it's too dark, as I'd expect, and if I write the image with a gamma of 2.2, the RGB values are OK, but it doesn't look right or measure right in Lab.
Probably some TIFF tag I need to figure out. This is what I'm using now:
tagstruct.ImageLength = size(image, 1);
tagstruct.ImageWidth = size(image, 2);
tagstruct.Compression = Tiff.Compression.None;
tagstruct.SampleFormat = Tiff.SampleFormat.IEEEFP;
tagstruct.Photometric = Tiff.Photometric.RGB;
tagstruct.BitsPerSample = 32;
tagstruct.SamplesPerPixel = 3;
tagstruct.PlanarConfiguration = Tiff.PlanarConfiguration.Chunky;
I'll keep at it.
Jim
-
I'm enjoying reading this interesting thread. I find myself doing most of my corrections in Photoshop because I prefer to avoid the colour / saturation shifts that the ACR/Lightroom adjustments generate, processing separately for colour and for contrast using different curves using Luminosity and Color blending. It doesn't take long, but it's a bit clunky having to generate a separate tiff to do so. The one thing that you cannot do so easily in Photoshop is recover highlights and, to a lesser extent perhaps, shadows. Perhaps a future version of ACR will provide for easier separation of color and contrast enhancement.
-
I'm done more experimentation with 16-bit integer and 32-bit floating point TIFFs in Photoshop, with some confusing (to me) results.
First, I wrote out a 32-bit TIFF file from Photoshop and looked at a lot of the TIFF tags. Other than some tags that you'd expect to be filled being empty (White Point, Transfer Function), there weren't a lot of surprises. Still, I copied a bunch of tags from the PS file and used them when I created FP TIFFs. No joy, however. The RGB values were the same as the 16-bit files I started out with, but the Lab values were wrong, and the image looked wrong.
I checked the values in the PS-written FP file and found that they did indeed span the range from 0.0 to 1.0.
Then I brought a 16-bit integer PP RGB image into PS and converted it to 32-bit FP. The RGB values changed! They got smaller, except for the 0,0,0 and 255,255,255 patches, which did not change. The Lab values did not change. That leads me to believe that PS uses a different tone curve for 16-bit integer images and 32-bit FP images.
Anybody know what's going on?
Jim
-
Anybody know what's going on?
Hi Jim,
I'm not sure, but could it have to do with the fact that PS doesn't do 16-bit, but covers a maximum range of 2^15+1 integers ( [0,32768] )?
Cheers,
Bart
-
I'm not entirely sure how Ps itself handles 32-bit images and conversions to/from 16-bit or 8-bit, but I'm pretty sure that 32-bit images in Ps are always considered linear light (regardless of which color space you have assigned in your Color Settings or in the Assign Profile dialog ...) and are displayed as such.
-
The mystery is solved. PS writes 32-bit floating point RGB files with a linear tone curve. The values range from 0.0 to 1.0. PS writes 16-bit integer RGB files with the tone curve of the RGB color space. The values range from 0 to 65535.
The bug? Pro Photo RGB has a gamma of 1.8, not 2.2. Oops...
There's an interesting anomaly in PS. In the info box, the RGB values in a 32-bit FP image go from 0 to 255. However, if you click on the foreground or background square in the toolbar, you get a color picker that's only for 32-bit use. In it, the RGB values vary from 0.0 to 1.0.
Jim
-
I'm not entirely sure how Ps itself handles 32-bit images and conversions to/from 16-bit or 8-bit, but I'm pretty sure that 32-bit images in Ps are always considered linear light (regardless of which color space you have assigned in your Color Settings or in the Assign Profile dialog ...) and are displayed as such.
As usual, Eric, you are entirely right. I have now brought 32-bit underexposed synthetic images into both Photoshop and Lightroom. In each case, it takes less of an Exposure slider adjustment than the amount of underexposure to get the RGB values back to about those of the correctly exposed synthetic image. The necessary amount of Exposure slider adjustment is different in the two programs. In Photoshop, it takes +2.49 to correct a 3-stop-under image. In Lightroom, it takes about +1.67. The adjustment is a little trickier in LR because there's no CIELab pixel value readout (although I think that's in LR 5). I think the readout in LR 4.4, which is what I am using, is for the ProPhoto RGB primaries and white point with the sRGB tone curve, or a gamma of 2.2. Thus the RGB readouts in LR and PS for a ProPhoto RGB image are not comparable, since the gammas of the pixel value displays are different.
By the way, the imported images, which have the PP RGB ICC profile embedded (I copied it from a Photoshop-generated PP RGB image) have the color temperature set to 5000 degrees Kelvin, as I would expect with PP RGB, but the tint is set to +10, and I would have expected zero.
Now that I can get synthetic floating point images into Lightroom, I'll rerun the Exposure control tests with them.
Thanks,
Jim
-
I brought a set of synthetic images into Photoshop as 32-bit floating point TIFFs with ProPhotoRGB primaries and white point, but with a gamma of one (from now on, I'm going to call these type of files "linear ProPhoto RGB" or "linear PP RGB", even though, strictly speaking, there's no such thing. There were no surprises. The Lab values all read within one least-significant digit of the values in Matlab. Same as before: an 11x11 grid, L*=50 for all 121 points, and the a* and b* values running from -50 to + 40.
Then I imported the images into Lightroom. They appeared much brighter and much more chromatic than the same images in Photoshop. I applied one stop of LR Exposure correction for each stop of underexposure. All the images then looked pretty much the same. I exported them from LR as integer PP RGB TIFFs, brought them into Photoshop and looked at the Lab values. They read in PS about the way they looked in LR. L*s running in the high 60s, and a*s and b*s looking even higher that what you'd expect with that kind of L* bump. I converted them into Lab 16-bit integer TIFFs and read them into Matlab. They looked ugly. In 3d, here's the baseline(properly exposed) image:
(http://www.kasson.com/ll/floatlabbaseline3d.png)
And in 2D, looking down from along the L* axis:
(http://www.kasson.com/ll/floatlabbaseline2d.png)
Looks like gamut mapping to me, and probably some other stuff.
I went back to LR, created a set of virtual copies, and cranked the Exposure adjustment back one stop on each. When I exported them and read them into Photoshop, the L* values were about right, but they were too chromatic.
In 3d, here's the baseline(properly exposed) image:
(http://www.kasson.com/ll/floatlabbaseline3dM1inLR.png)
And in 2D, looking down from along the L* axis:
(http://www.kasson.com/ll/floatlabbaseline2dM1inLR.png)
It looks like LR is looking at the fact that the files I'm feeding it are floating point and is invoking some default processing that it considers appropriate for HDR images. If that's the case, I need to find out where that processing is, and figure out how to turn it off.
Jim
-
I haven't been able to figure out how to turn off the processing that LR automagically applies to 32-bit floating point files, but I did go ahead and compute the CIEL*a*b* Delta-E stats of the differences in the Lab values of the 121 patches in each of the "underexposed and compensated stop for stop less one stop for the Lightroom processing" patches. The results are much like what Bill and John have reported from real camera testing. They're also similar to what I have measured in real camera testing, but with far less noise.
The overall stats:
(http://www.kasson.com/ll/floatlabDeltaStatsM1inLR.png)
For reference, a 3D look at the difference between the baseline exposure and itself expressed as displacements of the original target values:
(http://www.kasson.com/ll/floatlabDelta3dM0M1inLR.png)
And a 3D look at the "4-stop under and corrected in LR image", processed the same way:
(http://www.kasson.com/ll/floatlabDelta3dM4M1inLR.png)
And, finally, a two dimensional look at the immediately preceding data:
(http://www.kasson.com/ll/floatlabDelta2dM4M1inLR.png)
I'd show you the one, two, and three stop under plots, but they'd be boring; they're virtually the same as the four stop under graphs above.
I'm not really happy about not understanding the LR processing of the 32-bit floating point files, but, until I find out more about that, I'm going to have to leave it there.
At least, now the synthetic and the in-camera testing is telling us pretty much the same thing.
Jim
-
A while back in this thread, before Eric Chan pointed out that there were two image processing pipelines in Lightroom and that all my integer TIFF testing wasn't really relevant to raw processing, some of you asked about different error measures than CIELab Delta-E, specifically something related to hue errors. These color difference measures can get quite complicated. Here's an example (http://www.ece.rochester.edu/~gsharma/ciede2000/ciede2000noteCRNA.pdf). I can, if there's sufficient interest, implement some of these more complex, and presumably, accurate, measures, but I'll present here just the basics. In the precious post, I presented the Delta-E curves.
Here's a set of Delta-H curves, the basic CIEL*a*b* difference metric that measures hue error:
(http://www.kasson.com/ll/floatlabDeltaHStatsM1inLR.png)
Like Delta-E, Delta-H can't go negative.
Here are the Delta-C curves, which measures differences in what's called "metric chroma", the radial distance from the grey axis:
(http://www.kasson.com/ll/floatlabDeltaCStatsM1inLR.png)
Delta-C is positive if the test color is more chromatic than the reference, and negative if the test color is less chromatic than the reference. The fact that there's a tendency towards positive Delta-C indicates that making positive LR exposure adjustments tends to make the colors more chromatic than they should be. You can see that from the scatter plots as well.
If you look at the numbers in the Delta-H and Delta-C plots, you can see that most of the chromaticity error comes from too much chroma, not from hue shift.
And, although it's not a CIELab standard, I like to look at hue angle errors. The big potential problem with looking at hue angle alone is that errors near the grey axis, where they are inconsequential, can have the same value as errors in highly chromatic colors, where they are significant. Still, it gives indications of any possible hue shift bias. Here is the hue angle data:
(http://www.kasson.com/ll/floatlabDeltaHueStatsM1inLR.png)
Pretty symmetrical.
Jim
-
That's interesting Jim. In most of the tests I ran, granted far more simplistic than what you have put together here, I saw the chroma decrease as I pushed the exposure from under-exposed to normal exposure. Example being the Bright Yellow, which went bluer as a result of pushing the exposure, or the bright purple... for example. Your data covers 121 different patches however, so the sample size may be more indicative.
-
I just can't stop coding, or, in this case, downloading Matlab code put up by these people (http://www.ece.rochester.edu/~gsharma/ciede2000/ciede2000noteCRNA.pdf).
Here are the results using the The CIEDE2000 Color-Difference Formula:
(http://www.kasson.com/ll/floatlabDeltaE20StatsM1inLR.png)
The errors seem much smaller. I have no experience with this formula, so I don't know quite what to make of the results.
Jim
-
lol@coding binge
-
I saw the chroma decrease as I pushed the exposure from under-exposed to normal exposure. Example being the Bright Yellow, which went bluer as a result of pushing the exposure, or the bright purple... for example.
John, it's possible that you are describing hue shift, not a change in chroma. It's hard for me to tell because of the example you chose. Do you mean the the bright yellow moved towards the grey axis? That means it got less chromatic. However, if the yellow acquired a color tinge, that's a hue shift.
Jim
-
John, it's possible that you are describing hue shift, not a change in chroma. It's hard for me to tell because of the example you chose. Do you mean the the bright yellow moved towards the grey axis? That means it got less chromatic. However, if the yellow acquired a color tinge, that's a hue shift.
Jim
I'm referring to chroma.. as in the case of the yellow which measures significantly "bluer" with the pushed exposure. The hue shift (red/green) was very small. The b value dropped from 114 to 109 or so.
Sample #16 in the chart I posted.
-
I'm referring to chroma.. as in the case of the yellow which measures significantly "bluer" with the pushed exposure. The hue shift (red/green) was very small. The b value dropped from 114 to 109 or so.
Sample #16 in the chart I posted.
Gotcha. You're absolutely right. I wouldn't have said it that way, because it makes my head hurt to think about a more bluish yellow or a more greenish red.
Jim
-
lol.. I understand. I'm just basing my phrasing on the Lab coordinates.