photoken hat geschrieben:Also, cathodeRay mentions that the first thing to do is convert the original image to 32-bit, but your action does not do that. Is converting to 32-bit necessary?
No, it's not necessary – negative values are mapped to the 0..127 range, so it will work in 8 and 16 bit modes, too. (The way the HF layer is computed is also a bit different, but the result is the same as with the histogram adjustments.)
OK, I've run the 16 bit and 8 bit versions by changing the bit depth of the background layer to these settings (my understanding is that in PL the bit depth of the BG layer sets the calculation depth for the whole image - someone please correct me is this is wrong!)'. I expected it to throw out the layer stack badly and yes it does throw it out but not hugely: both 8 bit and 16 bit seems to be the same (!) and what seems to have happened is the HF layer ends up lighter in the HF areas and the Visual Check/Difference blend mode appears to confirm this: HF areas are just visible. Perhaps there is just one setting that needs to be changed to get the stack to work 100% correctly for 16 bit and 8 bit?
The other thing is that, rather unexpectedly, using Curves instead of a HG adjustment layer doesn't behave as expected. I thought a straight line from (x,y) 0,127 to 255,255 would produce the same mapping as the HG 127-255 output setting but it doesn't.
Just as I was about to hit 'Submit' I see Burkhard has replied on the 8/16 bit question - but from the HG-different bit depths experiments I've just just run the results aren't 100% right...
cathodeRay hat geschrieben:OK, I've run the 16 bit and 8 bit versions by changing the bit depth of the background layer to these settings (my understanding is that in PL the bit depth of the BG layer sets the calculation depth for the whole image - someone please correct me is this is wrong!)'.
In image mode, yes. In Document mode, you can set the bit depth in the document attributes.
cathodeRay hat geschrieben:I expected it to throw out the layer stack badly and yes it does throw it out but not hugely: both 8 bit and 16 bit seems to be the same (!) and what seems to have happened is the HF layer ends up lighter in the HF areas and the Visual Check/Difference blend mode appears to confirm this: HF areas are just visible. Perhaps there is just one setting that needs to be changed to get the stack to work 100% correctly for 16 bit and 8 bit?
You probably use a different colour space (linear gamma) in 32 bit mode. Note that frequency separation (just like most, if not all, adjustments) depends on the colour space used. 50% grey is much lighter in linear gamma than in sRGB, and also details in the HF layer will be rendered differently (details in light areas should show more than details in dark areas, compared to sRGB). Some versions of PL did this linear gamma conversion automatically, but as far as I can see, the current versions (released + beta) don't do this, so you shouldn't notice a difference when switching colour depths.
Anyway, just put a copy of the original image on top of the layer stack in mode "Difference" to check that you have a proper frequency separation. In 8 bit mode, there will be some rounding errors, of course, but apart from that, everything seems ok.
On the HG/Curve adjustment of the HF layer (using 32 bits): I'm probably being very thick here and missing something obvious (and in fact I had wondered about gamma but I don't think that's it) but I can't see why Curves don't work as I would expect them to. If I use the HG to do the mapping, I have the following settings, and the red arrows show my understanding of how the mapping is happening. In the preview box you can see the lower nose area, looking as it should do.
HG mapping.jpg
If I try and replicate this in Curves, using the settings shown, which should - I thought - produce identical mappings to the HG settings, I get a different result, as can be seen. Neutral grey is fine in both, but the HF detail is different, and, in the Curves case, wrong.
Curves mapping.jpg
I also still find I get the same or similar errors (confirmed using the Visual Check/Difference mode tests) in 8 and 16 bits using either the HG or Curves...
All very perplexing!
cathodeRay
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
cathodeRay hat geschrieben:On the HG/Curve adjustment of the HF layer (using 32 bits): I'm probably being very thick here and missing something obvious (and in fact I had wondered about gamma but I don't think that's it) but I can't see why Curves don't work as I would expect them to. If I use the HG to do the mapping, I have the following settings, and the red arrows show my understanding of how the mapping is happening. In the preview box you can see the lower nose area, looking as it should do.
Ah, so you are referring to your layer stack, not the one produced by my action, with the HF layer produced by subtracting the LF layer from the original.
The reason why you get different results is that Curves and Histogram Correction give different results when applied to negative values. "Curves" treats negative input values as 0 and values above 1.0 (float) as 1.0. That's not what you want. Histogram Correction works, but afaik, the behaviour of either is undefined for values outside the 0 to 1.0 range. If you want something more definite, you can use "Optimize HDR" which is a histogram correction with extended range (just set the min and max values to -1.0 and 1.0 and leave gamma at 1).
This is where I think I've go to. When we blur the image, we knock the edges off it - extreme pixels become less extreme. When we subtract the blur from the original, most of the two images' pixels are still the same value, so x-x=0. Where highlights have been knocked off in the blur, the subtraction results in a value just above 0, because the blur value is closer to mid grey, and so smaller than the original value, and where the shadows have been pulled back a bit (made less extreme), the subtraction yields a negative number, because the blur value is a bit bigger than the corresponding original value. In 0-255 notation, we have an 'image' where most of the pixels are 0, but with a few spread in a very narrow range from say -10 to +10. Mathematically, this 'image' can exist, but we can't (yet) see the bits below 0.
So we add 127 (or 128, 128 might just be slightly better, but in practice the difference is trivial, less than half a percent of the total range) and the vast majority of pixels now become mid grey (0+127=127), the slightly lighter ones fractionally above mid grey, and the slightly darker (negative) ones are lifted out of negative territory into the visible, just below (darker than) mid-grey (-5+127 = 122).
The problem comes with how PL and other similar programs deal with negative numbers in blend displays and calculations. Most of the time anything less than zero is clipped to zero, so we lose the info in the negative numbers. Curves always do this, but for some reason Histograms in 32 bits but not 16 or 8 bits don't clip the negative numbers, so they can successfully be retrieved from negative territory. So the HG technique works, but only in 32 bits.
As it happens, so too does the custom filter (I was experimenting with various bit depths to see whether some voodoo like minus number in the various boxes might somehow roll 8 and/i6 bit negative numbers back into the light ie visible territory, but no dice, even when the clip checkbox is left unchecked). However, it does work at 32 bits with a 3x3 matrix of all 1s (or a centre 1, rests 0s), Div = 2, Bias =127. Result: perfect HF separation, with no errors. It also works (as expected) if Div is set to 1 (so no multiplication or division is applied), leaving just the Bias (offset) of 127 with the Linear Light HF layer blend mode set to 50%. But, as in PS, using Div=2 is a convenient shortcut. But either work.
So it seems that, as I said at the beginning of the recipe, setting to 32 bits is crucial, to get the 'right sort of maths'. 32 bits is the only way to 'turn on' correct handling of negative numbers (at least in this context, ie using the layer stack recipe rather than the action). At the moment, I'm content with that: simple, transparent in its workings and effective.
I've downloaded and merged and run the Frequency separation (virtual) action and while it works in my tests, including at 16 bits as well as 32, damned if I can see how it works! The LF bit is fine, but where it loses me is in the HF group: invert the LF (virtual) image and and then overlay the original (virtual) image at 50%... perhaps this is the adding an inversion is a subtraction (because an inversion isn't a true 1/x inversion, it's a conversion (interesting suffix there...) ie 1 minus the standardised pixel value, not 1 divided by the standardised pixel value, and this somehow keeps the values/maths out of negative territory (because we are always adding, not subtracting)... but its is still a lot more complex than the simple Original - LF = HF and HF + LF = Original logic of the subtraction based stack.
cathodeRay hat geschrieben:I've downloaded and merged and run the Frequency separation (virtual) action and while it works in my tests, including at 16 bits as well as 32, damned if I can see how it works! The LF bit is fine, but where it loses me is in the HF group: invert the LF (virtual) image and and then overlay the original (virtual) image at 50%... perhaps this is the adding an inversion is a subtraction (because an inversion isn't a true 1/x inversion, it's a conversion (interesting suffix there...) ie 1 minus the standardised pixel value, not 1 divided by the standardised pixel value, and this somehow keeps the values/maths out of negative territory (because we are always adding, not subtracting)... but its is still a lot more complex than the simple Original - LF = HF and HF + LF = Original logic of the subtraction based stack.
It's not so bad – as you figured, the inversion by curves gives 1 - LF. Blending with 50% of the original gives 0.5(1-LF) + 0.5 Original, that is, HF = 0.5 + 0.5 (Original - LF). The two histogram corrections above give the same result, maybe it's easier to see what happens. Anyway, the HF layer is basically the same as in your calculation, just scaled to fit the 0..1 range. The only complication is to carry out the computations such that there is no overflow in 8 and 16 bit modes. Now Linear Light is just the right blending mode: it adds 2* layer - 1 to the previous image, so all together you get LF + 2*(0.5 + 0.5 (Original - LF)) - 1 = Original.
Just an idea how thinking about this topic can be a little easier:
A black picture with 1 white Pixel. Blur it enough, and the lowpass layer will practically turn black, at least in 8/16 Bit. That leaves 255 to somehow add for the highpass layer.
And then think about the same, just inverted.
----------------
Herr Doktor, ich bin mir ganz sicher, ich habe Atom! /Doctor, doctor, I'm sure, I've got atoms!
Burkhard - thanks for the explanation, and Hoogo thanks for the analogy, and thank both of you for your time. Being a non-mathematician, but having to use maths (or rather stats) when I'm wearing other hats, I have always found simple formulas, and explanations using words and analogies, help the light to go on in the dark. In the world of image editing, the language of the blend modes doesn't do much to help: 'multiply' makes values smaller (because the maths are done on standardised pixel values), and you might just as well call Linear Light and Vivid Light 'Voodoo 1' and 'Voodoo 2' for all their names reveal about what they do, perhaps causing non-matheticians to forget that behind each blend lies a specific equation. However, maybe I'm getting there. I wonder, is another way of looking at the inversion as a sort of transformation that causes the numbers to stay in the right territory and allows, perhaps even requires, the use of addition in place of subtraction?
I would like to refer to your action "Frequency Separation (virtual).actions.zip". What I seem to miss why "Retouch High Frequency" Layer is located between "High Frequencies" and "Virtual Copy, 50%". With which kind of tool should I retouch??? If I try "healing brush" it blows up; if I try "50% gray brush" all Luma details are gone.
Wouldn't it be better to place "Retouch High Frequencies"-Layer right above "High Frequencies". Then I could use "Healing brush" and that would only copy Luma (Texture) information.
Tida hat geschrieben:I would like to refer to your action "Frequency Separation (virtual).actions.zip". What I seem to miss why "Retouch High Frequency" Layer is located between "High Frequencies" and "Virtual Copy, 50%". With which kind of tool should I retouch???
Thanks very much for your feedback.
For some reason, the retouch tools in PL don't seem to work as expected in isolated groups – you'll have to turn off the layers below to use them. (Healing brush also requires that you change the layer mode of the "High Frequency" group to "Normal". In most cases, it's better to merge the "High frequencies" and "Low frequencies" groups once you have set the right radius.
Tida hat geschrieben:If I try "healing brush" it blows up; if I try "50% gray brush" all Luma details are gone.
If you fill the layer with 50% grey, the image should just be blurred (all high frequencies gone).
Tida hat geschrieben:
Wouldn't it be better to place "Retouch High Frequencies"-Layer right above "High Frequencies". Then I could use "Healing brush" and that would only copy Luma (Texture) information.
That doesn't work, unfortunately, because then retouching will not be restricted to high frequencies. If I remember correctly I placed the Low frequencies retouch layer directly in the layer stack because of the retouch tools problem, but haven't found a nice solution for the high frequencies.
[/quote]
That doesn't work, unfortunately, because then retouching will not be restricted to high frequencies. If I remember correctly I placed the Low frequencies retouch layer directly in the layer stack because of the retouch tools problem, but haven't found a nice solution for the high frequencies.
Cheers
Burkhard.[/quote]
Hi Burkhard,
was trying whole afternoon even to get an idea to overcome Mask issue without any result. Then I thought to change workflow that we can still work non-destructive.
Please find below new action. Most content of your "Frequency Separation (virtual).actions" is not changed. I moved HF-Mask above HF-Group. Left this group at normal (Drawn Isolated - disabled), made a new group out of the HF-Mask and HF-Group. Into this group I added an deactivated histogram correction just to help (magnify grey HF-Layer) for new workflow.
If you now want to retouch high frequencies
a) goto new "HF Retouched" group, disable "Draw Isolated" in "Layer Properties"
b) activate "Histogram Correction" to magnify texture - makes life easy to find disturbing textures
c) Make your Retouch with "Healing Brush" in "Retouch High Frequencies" mask, always use "Active Below" tool settings
if you finish
d) disable "Histogram Correction" layer
e) enable "Draw Isolated" of "HF Retouched" group (it should go back to "Linear Light" blending mode)
done:-)
Frequency Separation (virt2).actions
P.S. If you need to sharpen some more - use "HF Retouched" group and blend above 100%
Hope you understand how it works...
Enjoy
Martin
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
bkh hat geschrieben:
For some reason, the retouch tools in PL don't seem to work as expected in isolated groups – you'll have to turn off the layers below to use them. (Healing brush also requires that you change the layer mode of the "High Frequency" group to "Normal". In most cases, it's better to merge the "High frequencies" and "Low frequencies" groups once you have set the right radius.
Hi Burkhard,
now the 3rd version should work as expected. This time High Frequency Retouch works together with healing brush.
Just made from High Freq group an additional virtual copy on top and used this to linear blend with low freq below. Hence retouch masks are changed in its order for now.
Switch from "linear blend" to "normal" and back again is not needed any more:)
Thanks
Martin
Frequency Separation (virt3).actions
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Tida hat geschrieben:now the 3rd version should work as expected. This time High Frequency Retouch works together with healing brush.
Nice workaround, seems to work well, thanks.
Taking the idea a bit further, one could even move the "Retouch High Frequencies" layer out of the group and create a top level isolated group where virtual copies of HF retouch and HF group get combined. In that way, the retouch layers would be more accessible.
bkh hat geschrieben:
Taking the idea a bit further, one could even move the "Retouch High Frequencies" layer out of the group and create a top level isolated group where virtual copies of HF retouch and HF group get combined. In that way, the retouch layers would be more accessible.
Sounds great,
additional idea is to set high freq layer to 200% and create a layer Mask with 50% gray. Hence white Airbrush would sharpen and black would soften the texture wherever you want.
