Fill flash enhancement (PS7 from PSE2)

Hi!

I use both PS7 and PSE2. Only thing I'm really missing in PS7 is the PSE's "Enhance --> Adjust Lighting --> Fill Flash" feature for quick fixes (really helps with pics taken in dubious lighting conditions).

Is there a way to get this done in PS7?

Thanks in advance
Bernd

In article <cbkdnp$mm0$ says...

Hi!

I use both PS7 and PSE2. Only thing I'm really missing in PS7 is the PSE's "Enhance --> Adjust Lighting --> Fill Flash" feature for quick fixes (really helps with pics taken in dubious lighting conditions).

Is there a way to get this done in PS7?

Thanks in advance
Bernd

I'm not familiar with Element's Fill Flash, but first Curves in PS, next Levels in PS, and/or Image/Adjustment>Highlight & Shadow PSCS all come to mind for correcting an image, as though my actual "fill flash" had not fired, or was set incorrectly.

Hunt

Hunt!

Thanks for the advice... yes I used curves/levels to imitate this, so I think I'm the right track.

Thanks again
Bernd

"Hunt" wrote in message

In article <cbkdnp$mm0$

says...

Hi!

I use both PS7 and PSE2. Only thing I'm really missing in PS7 is the

PSE's

"Enhance --> Adjust Lighting --> Fill Flash" feature for quick fixes

(really

helps with pics taken in dubious lighting conditions).

Is there a way to get this done in PS7?

Thanks in advance
Bernd

I'm not familiar with Element's Fill Flash, but first Curves in PS, next Levels in PS, and/or Image/Adjustment>Highlight & Shadow PSCS all come to

mind

for correcting an image, as though my actual "fill flash" had not fired,

or

was set incorrectly.

Hunt

Bernd wrote:

Hi!

I use both PS7 and PSE2. Only thing I'm really missing in PS7 is the PSE's "Enhance --> Adjust Lighting --> Fill Flash" feature for quick fixes (really helps with pics taken in dubious lighting conditions).
Is there a way to get this done in PS7?

I'd recommend converting your image to Lab, then curve the Lightness channel with two points one about 1/4 the way in from the shadows to simulate the fill flash in the shadows.

Then add another point about 1/4 the way from the top to keep the top of the curve from flattening out, and to set the slope of the middle of the curve parallel to its original position. This shape of curve confines the lightening effect to the shadows, and keeps the brighter areas of the image from blowing out.

Another popular way to brighten up shadows is to duplicate the layer, then change the layer mode to screen. Add another such layer until you overshoot a bit, then use transparency on the final layer to back it off before flattening the image. You may stay in RGB for this manipulation, though I still prefer the results in Lab mode. The same effect may be had using curves, and this method has more impact on the brighter areas of the image than Elements's fill flash funciton.
--

Mike Russell
www.curvemeister.com
www.geigy.2y.net

In article <MfcEc.79243$>,
says...

Bernd wrote:

Hi!

I use both PS7 and PSE2. Only thing I'm really missing in PS7 is the PSE's "Enhance --> Adjust Lighting --> Fill Flash" feature for quick fixes (really helps with pics taken in dubious lighting conditions).
Is there a way to get this done in PS7?

I'd recommend converting your image to Lab, then curve the Lightness channel with two points one about 1/4 the way in from the shadows to simulate the fill flash in the shadows.

Then add another point about 1/4 the way from the top to keep the top of the curve from flattening out, and to set the slope of the middle of the curve parallel to its original position. This shape of curve confines the lightening effect to the shadows, and keeps the brighter areas of the image from blowing out.

Another popular way to brighten up shadows is to duplicate the layer, then change the layer mode to screen. Add another such layer until you overshoot a bit, then use transparency on the final layer to back it off before flattening the image. You may stay in RGB for this manipulation, though I still prefer the results in Lab mode. The same effect may be had using curves, and this method has more impact on the brighter areas of the image than Elements's fill flash funciton.
--

Mike Russell
www.curvemeister.com
www.geigy.2y.net

Thanks Mike. I don't work in LAB often, but will look into your recommendation for this.

Hunt

Hunt wrote:
[re working in Lab mode]

Thanks Mike. I don't work in LAB often, but will look into your recommendation for this.

Hunt,
Lab is a great color space for controlling image brightness. At first glance the RGB curve seems to do the same thing, but it is very prone to introducing color casts.
--

Mike Russell
www.curvemeister.com
www.geigy.2y.net

I use both PS7 and PSE2. Only thing I'm really missing in PS7 is the PSE's "Enhance --> Adjust Lighting --> Fill Flash" feature for quick fixes (really helps with pics taken in dubious lighting conditions).
Is there a way to get this done in PS7?

I'd recommend converting your image to Lab, then curve the Lightness channel with two points one about 1/4 the way in from the shadows to simulate the fill flash in the shadows.

Isn't the conversion between RGB and Lab lossy? (Speaking of which, I read once that PS' native color mode is Lab so how does that fit into the picture?)

Also, I believe you mentioned earlier that brightening up the image in RGB introduces a color shift (or words to that effect). Could you please be more specific?

Thanks!

Don.

Don wrote:

I use both PS7 and PSE2. Only thing I'm really missing in PS7 is the PSE's "Enhance --> Adjust Lighting --> Fill Flash" feature for quick fixes (really helps with pics taken in dubious lighting conditions).
Is there a way to get this done in PS7?

I'd recommend converting your image to Lab, then curve the Lightness channel with two points one about 1/4 the way in from the shadows to simulate the fill flash in the shadows.

Isn't the conversion between RGB and Lab lossy?

If this is a concern, work in 16 bits. Generally I don't worry about this, but the option is always there for those who care. Curvemeister also supports 16 bit mode for all it's color operations for this reason.

? (Speaking of which, I

read once that PS' native color mode is Lab so how does that fit into the picture?)

PS does use Lab as the PCS - profile connection space - when converting internally from one color mode to another, however there is no roundoff or quantization cost associate with this since the internal calculations are done at a higher precision.

Also, I believe you mentioned earlier that brightening up the image in RGB introduces a color shift (or words to that effect). Could you please be more specific?

Here's an example. Fill an image with RGB(10, 128, 245) Then lift the middle of the RGB curve by 10 values. The result is RGB(11, 138, 246) a color shift toward green. In HSB terms, this is a hue change of -2 degrees.

That's for an artificial image, but as always I think it is important that you try this experiment out on some of your own images. The simplest way to check this out is to put down several info points on various highly colored areas of your image, and set them to display in HSB mode. You will see the Hue value of your various points shift as you move the RGB curve around. Underexposed images are particularly prone to this kind of color shift, and chroma noise because the ratios between smaller values are more unstable.

BTW, if you are concerned about "lossy" conversion, staying in RGB is not necessarily the best solution. There is some extra quantization associates with staying in RGB and using the master RGB curve, due to the way Photoshop works.

The RGB curve's look up table (LUT) is applied to the integer values that come in turn from the red, green, and blut LUT's. The result of this is an extra step of quantization, and can cause slightly more histogram combing than you would get if you combined the curves mathmatically into a single per channel LUT.

Curvemeister does this extra mathmatics. The difference is subtle, but it is there.

Given that I don't advocate using the RGB master curve in the first place, I leave it to my customers to decide whether it's significant or not --

Mike Russell
www.curvemeister.com
www.geigy.2y.net

On Wed, 30 Jun 2004 20:16:35 GMT, (Don) wrote:

I use both PS7 and PSE2. Only thing I'm really missing in PS7 is the PSE's "Enhance --> Adjust Lighting --> Fill Flash" feature for quick fixes (really helps with pics taken in dubious lighting conditions).
Is there a way to get this done in PS7?

I'd recommend converting your image to Lab, then curve the Lightness channel with two points one about 1/4 the way in from the shadows to simulate the fill flash in the shadows.

Isn't the conversion between RGB and Lab lossy? (Speaking of which, I read once that PS' native color mode is Lab so how does that fit into the picture?)

No, it's just a different "view" of the same image. LAB has a wider gamut and is closest to what the human eye actually sees. You can print from LAB if you want to.

--

Hecate

veni, vidi, reliqui

On Wed, 30 Jun 2004 22:05:00 GMT, "Mike Russell" wrote:

Isn't the conversion between RGB and Lab lossy?

If this is a concern, work in 16 bits.

I do, and it's not really a big problem, but I was just curious.

Also, I believe you mentioned earlier that brightening up the image in RGB introduces a color shift (or words to that effect). Could you please be more specific?

Here's an example. Fill an image with RGB(10, 128, 245) Then lift the middle of the RGB curve by 10 values. The result is RGB(11, 138, 246) a color shift toward green. In HSB terms, this is a hue change of -2 degrees.

I repeated the test by first changing the color mode to Lab and that alone shifted the color to RGB equivalent of (0, 128, 245) or LAB(53, 5, -68).

After applying 10 clicks in Lightness curve at 50,50 to get 50,60 there was a color shift here as well but this time in the red. The resulting color was RGB(64, 152, 255) or LAB(62, 5, -68).

The blue seems to have been clipped so I repeated the test with RGB(64, 128, 192) and got this after applying 10 clicks in both:

(Note: The difference in magnitude is probably due to the fact that 10 out of 256 clicks in RGB is not the same as 10 out of 100 in Lab.)

in RGB: RGB(71, 138, 199)
in Lab: RGB equivalent(90, 154, 221) but due to conversion to Lab mode first, this change is from RGB(60, 129, 194) as the starting point.

So, if my math is right (it's very late!) that's a shift of RGB(+7, +10, +7) and Lab RGB equivalent (+30, +25, +27) which means there is a color shift in both cases, in this particular example with RGB favoring green while Lab favors red.

Could this be simply because of the nature of Curves? I mean they are not linear, they are, well, curves... :-) So, anything in the middle of the curve is bound to shift more than at either edge?

Don.

On Thu, 01 Jul 2004 03:53:28 +0100, Hecate wrote:

Isn't the conversion between RGB and Lab lossy? (Speaking of which, I read once that PS' native color mode is Lab so how does that fit into the picture?)

No, it's just a different "view" of the same image. LAB has a wider gamut and is closest to what the human eye actually sees. You can print from LAB if you want to.

I understand the concept and do realize that different color modes cover different gamuts, but I was just curious about the theory.

In practice, as I don't even print but just do all this for viewing on a monitor - and a notebook LCD monitor at that (!) - even the good old sRGB probably has more gamut than I can see here anyway...

Don.

Don wrote:

On Wed, 30 Jun 2004 22:05:00 GMT, "Mike Russell" wrote:

Isn't the conversion between RGB and Lab lossy?

If this is a concern, work in 16 bits.

I do, and it's not really a big problem, but I was just curious.

Also, I believe you mentioned earlier that brightening up the image in RGB introduces a color shift (or words to that effect). Could you please be more specific?

Here's an example. Fill an image with RGB(10, 128, 245) Then lift the middle of the RGB curve by 10 values. The result is RGB(11, 138, 246) a color shift toward green. In HSB terms, this is a hue change of -2 degrees.

I repeated the test by first changing the color mode to Lab and that alone shifted the color to RGB equivalent of (0, 128, 245) or LAB(53, 5, -68).

You've already done something I can duplicate but not explain. In Photoshop 6 I get this rather inaccurate result in 16 bit mode. Converting directly to 8 bit mode bumps the red channel back up. Photoshop CS gives a somewhat more accurate, but still not equivalent result. This strikes me as a bug in Photoshop's 16 bit color display function, rather than the actual image data.

After applying 10 clicks in Lightness curve at 50,50 to get 50,60 there was a color shift here as well but this time in the red. The resulting color was RGB(64, 152, 255) or LAB(62, 5, -68).
The blue seems to have been clipped so I repeated the test with RGB(64, 128, 192) and got this after applying 10 clicks in both:
(Note: The difference in magnitude is probably due to the fact that 10 out of 256 clicks in RGB is not the same as 10 out of 100 in Lab.)
in RGB: RGB(71, 138, 199)
in Lab: RGB equivalent(90, 154, 221) but due to conversion to Lab mode first, this change is from RGB(60, 129, 194) as the starting point.
So, if my math is right (it's very late!) that's a shift of RGB(+7, +10, +7) and Lab RGB equivalent (+30, +25, +27) which means there is a color shift in both cases, in this particular example with RGB favoring green while Lab favors red.

The "bug" is clouding things, unfortunately. Try the same thing in 8 bit mode, and I think the results will make more sense. You will see quantization - roughly 1 percent in the conversion, in 8 bits, but that will be less confusing that this rather gross bug in

Since the Lab info readouts are crazed, I recommend that you compare the swatches of color visually, and you will see that the one curved in RGB mode is greener than the one curved in Lab.

Could this be simply because of the nature of Curves? I mean they are not linear, they are, well, curves... :-) So, anything in the middle of the curve is bound to shift more than at either edge?

That's it exactly, though I'm willing to bet the farm that there is no color shift in Lab.

Even if the RGB master curve is kept linear, there is another interesting color shift that happens because of gamma. If only the endpoints of the curve are moved, clipping may occur, but the color shift is nonexistent for gamma 1.0 As the gamma value diverges ftom 1.0, there will be a subtle color shift. Some people choose to work in gamma 1.0 due to this and related effects.

All is not lost, however, because it is not normally necessary to go into this level of analysis other than for curiousity reasons. If you adjust your channels individually, and keep your neutrals balanced, it all comes out in the color correction "wash".
--

Mike Russell
www.curvemeister.com
www.geigy.2y.net

On Thu, 01 Jul 2004 08:43:34 GMT, "Mike Russell" wrote:

Here's an example. Fill an image with RGB(10, 128, 245) Then lift the middle of the RGB curve by 10 values. The result is RGB(11, 138, 246) a color shift toward green. In HSB terms, this is a hue change of -2 degrees.

I repeated the test by first changing the color mode to Lab and that alone shifted the color to RGB equivalent of (0, 128, 245) or LAB(53, 5, -68).

You've already done something I can duplicate but not explain. In Photoshop 6 I get this rather inaccurate result in 16 bit mode. Converting directly to 8 bit mode bumps the red channel back up. Photoshop CS gives a somewhat more accurate, but still not equivalent result. This strikes me as a bug in Photoshop's 16 bit color display function, rather than the actual image data.

Did I discover yet another obscure PS 6 bug? And I'm just a civilian... ;-)

Seriously though, I actually tried it in 8-bit mode first and found out that as I moved the mouse over - what should have been uniform color - every now then there was a dip in the red to 0. Apparently there were some pixels where the conversion was incorrect. That's why I switched to 16-bit. So the bug is in 8-bit as well, only intermittently.

Anyway, checking image data is easy enough to do. I used my "best friend" - and the best feature of PS ;-) in my opinion - export to RAW. (Although that's where I found my first major PS bug!)

And, sure enough, instead of same pixel values throughout there are variations. So it's not a display bug but a conversion bug. Here's a brief hex dump:

00004E20: 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C "<<<<<<<<<<<<<<<<" 00004E30: 3C 3C 3C 3C 3C 3C 3C 3C 3C 3D 3C 3C 3C 3D 3C 3D "<<<<<<<<<=<<<=<=" 00004E40: 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3D 3C 3C 3D 3D 3D "<<<<<<<<<<=<<===" 00004E50: 3C 3D 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3D "<=<<<<<<<<<<<<<="

All the "=" characters are, presumably, duds. There are quite a few.

Which once again puts things into perspective regarding "purity" of any graphics editing. I mean - like most people - I aimed at as pure an environment as possible, but all these inaccuracies (far too many to mention) make that a somewhat pointless exercise.

All is not lost, however, because it is not normally necessary to go into this level of analysis other than for curiousity reasons. If you adjust your channels individually, and keep your neutrals balanced, it all comes out in the color correction "wash".

Exactly! I'm currently fighting with a notebook LCD display so I can probably barely see the whole sRGB gamut let alone this amount of detail.

But, as I wrote, I like to learn things and this peaked my curiosity.

Don.

Don wrote:

On Thu, 01 Jul 2004 08:43:34 GMT, "Mike Russell" wrote:

Here's an example. Fill an image with RGB(10, 128, 245) Then lift the middle of the RGB curve by 10 values. The result is RGB(11, 138, 246) a color shift toward green. In HSB terms, this is a hue change of -2 degrees.

I repeated the test by first changing the color mode to Lab and that alone shifted the color to RGB equivalent of (0, 128, 245) or LAB(53, 5, -68).

You've already done something I can duplicate but not explain. In Photoshop 6 I get this rather inaccurate result in 16 bit mode. Converting directly to 8 bit mode bumps the red channel back up. Photoshop CS gives a somewhat more accurate, but still not equivalent result. This strikes me as a bug in Photoshop's 16 bit color display function, rather than the actual image data.

Did I discover yet another obscure PS 6 bug? And I'm just a civilian... ;-)

Seriously though, I actually tried it in 8-bit mode first and found out that as I moved the mouse over - what should have been uniform color - every now then there was a dip in the red to 0. Apparently there were some pixels where the conversion was incorrect. That's why I switched to 16-bit. So the bug is in 8-bit as well, only intermittently.

Anyway, checking image data is easy enough to do. I used my "best friend" - and the best feature of PS ;-) in my opinion - export to RAW. (Although that's where I found my first major PS bug!)
And, sure enough, instead of same pixel values throughout there are variations. So it's not a display bug but a conversion bug. Here's a brief hex dump:

00004E20: 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C "<<<<<<<<<<<<<<<<" 00004E30: 3C 3C 3C 3C 3C 3C 3C 3C 3C 3D 3C 3C 3C 3D 3C 3D "<<<<<<<<<=<<<=<=" 00004E40: 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3D 3C 3C 3D 3D 3D "<<<<<<<<<<=<<===" 00004E50: 3C 3D 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3D "<=<<<<<<<<<<<<<="
All the "=" characters are, presumably, duds. There are quite a few.

I think there's a dither operation going on. This may be controllable by the dither option in the color settings. I'll check this later, but with all your energy you may beat me to it!

Which once again puts things into perspective regarding "purity" of any graphics editing. I mean - like most people - I aimed at as pure an environment as possible, but all these inaccuracies (far too many to mention) make that a somewhat pointless exercise.

Well, a lot of people are interested in "purity". I haven't checked Curvemeister's color conversion yet, but will do so. I've decided it's something about the way Photographers, feel about their images, and I'm very conscious how important that is to some people.
--

Mike Russell
www.geigy.2y.net

On Thu, 01 Jul 2004 07:13:52 GMT, (Don) wrote:

On Thu, 01 Jul 2004 03:53:28 +0100, Hecate wrote:

Isn't the conversion between RGB and Lab lossy? (Speaking of which, I read once that PS' native color mode is Lab so how does that fit into the picture?)

No, it's just a different "view" of the same image. LAB has a wider gamut and is closest to what the human eye actually sees. You can print from LAB if you want to.

I understand the concept and do realize that different color modes cover different gamuts, but I was just curious about the theory.
In practice, as I don't even print but just do all this for viewing on a monitor - and a notebook LCD monitor at that (!) - even the good old sRGB probably has more gamut than I can see here anyway...

Well, just remember this - converting an image from RGB to LAB or CMYK doesn't make an image lossy. Nor does converting it back (though the colours will look a bit flat if you use RGB to CMYK to RGB). The number of pixels you have will remain the same. Lossy only happens when you save the file top a lossy format such as jpg which is converting blocks of colour to single values and then interpolating the missing values when you reopen the file.

--

Hecate

veni, vidi, reliqui

On Thu, 01 Jul 2004 07:13:50 GMT, (Don) wrote:

Could this be simply because of the nature of Curves? I mean they are not linear, they are, well, curves... :-) So, anything in the middle of the curve is bound to shift more than at either edge?

The reason you get colour shifts between modes is that the different modes have different colour spaces.

--

Hecate

veni, vidi, reliqui

On Thu, 01 Jul 2004 22:58:00 GMT, "Mike Russell" wrote:

And, sure enough, instead of same pixel values throughout there are variations. So it's not a display bug but a conversion bug. Here's a brief hex dump:

00004E20: 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C "<<<<<<<<<<<<<<<<" 00004E30: 3C 3C 3C 3C 3C 3C 3C 3C 3C 3D 3C 3C 3C 3D 3C 3D "<<<<<<<<<=<<<=<=" 00004E40: 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3D 3C 3C 3D 3D 3D "<<<<<<<<<<=<<===" 00004E50: 3C 3D 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3C 3D "<=<<<<<<<<<<<<<="
All the "=" characters are, presumably, duds. There are quite a few.

I think there's a dither operation going on. This may be controllable by the dither option in the color settings. I'll check this later, but with all your energy you may beat me to it!

You're right! The dither was on, which is *very* odd, because I clearly remember disabling it (I *hate* dither!). PS must have turned it back on after one its crashes... However, dither applies only to 8-bit images.

Still, it means that dither is buggy! Now you see why I hate it! ;-) It should *not* introduce *random* errors when the source is of uniform color, but that only explains those random irregularities, not the conversion clipping which still takes place.

Which once again puts things into perspective regarding "purity" of any graphics editing. I mean - like most people - I aimed at as pure an environment as possible, but all these inaccuracies (far too many to mention) make that a somewhat pointless exercise.

Well, a lot of people are interested in "purity". I haven't checked Curvemeister's color conversion yet, but will do so. I've decided it's something about the way Photographers, feel about their images, and I'm very conscious how important that is to some people.

Oh, absolutely! In spite of all this I still can't escape (irrationally) wrestling and agonizing over the smallest of things, but it helps me every now and then to do a "reality check".

Don.