Luminosity masks are technically not in PL7 but in FP7. Control lines are in PL7 but not in FP7. However, if you buy both packages, PL7 then contains both.
This feature request is about making the two mask types consistent.
Control lines don’t support modification using the brush/eraser tools; luminosity masks do.
Luminosity masks don’t support chroma selection; control lines do.
I am requesting that both masking tools include the features supported by the other. The only difference between the two, then, would be that one begins life as a gradient and the other doesn’t.
Control lines use a Luma slider to accomplish what luminosity masks do more flexibly with explicit ranges for luminosity and independent ramps for feathering. It would make sense to use the luminosity mask’s method for control lines.
Control lines use a Chroma slider to feather the range of colors included in the mask. It might make sense to also apply the luminosity mask’s greater flexibility here. The HSL tool already provides a way to select color ranges and their feathering, so there is already an existing interface for the job.
It is useful to define a mask using both luminosity and color. Control lines already do that; they would be sufficient if they allowed the use of the eraser tool.
Of course, with this change, there would be no need to buy FP7 to get luminosity masks. A control line that is placed below the image would work exactly like a luminosity mask.
As I’m sure many people have noted (and complained about), requiring FP7 in order to get luminosity masks and fine contrast is just about selling copies of FP7. The two tools belong directly in Photolab and have little to do with film styles.
You reminded me that control points/lines are more complex than I had remembered. One can mix control points and control lines within one mask. Further, you can have positive and negative control points/lines. The “plus” control points/lines add to the mask; the “minus” control points/lines subtract from the mask.
Within a single mask, the luma/chroma sliders control the feathering of the value selected by every control point/pipette. This means that the sliders cannot be replaced by a control that selects an absolute value—the modifiers must be relative so they can be applied to different luminosity/color selections.
This is a bizarre system, but there are probably some edge cases where it is useful. However, it would prevent making control points/lines completely consistent with luminosity masks due to backward compatibility requirements.
It would still be possible to allow the brush and eraser tools to work with control points and lines. They would simply add or subtract to the existing selection, similar to how one can add and subtract with more control points and lines.
It would also still be possible to add a chroma selection to the luminosity mask, and the chroma selection tool used should be analogous to the luminosity selection tool. My own preference is that the tool initially selected a luminosity range, but all colors. If I also needed to narrow the mask by color, I would adjust accordingly. The tool should indicate the color at the selected point, but I could choose to pick any range (just as with luminosity).
Minus control points and lines don’t really subtract from the mask but protect areas from being affected by the mask. The end result is the same though.
This would require some experimentation, but the behavior I observed appeared to be exactly the same as addition and subtraction and not at all like protection.
I don’t know how PL handles masks internally, but Photoshop uses one byte per pixel, where 0 means the pixel is not masked at all and 256 means it is fully masked.
PL appears to work like this:
Select a control point.
Create a mask based on the control point radius and the luma/chroma feathering.
Each mask value is interpreted as a positive number or negative number depending on whether it is a plus or minus point.
For each pixel, sum the mask values in the order in which control points were defined.
Limit the results to the range 0-256.
With a little testing, it was easy to see that adding a + point after a - point could result in reversing the effect of the - control point. Therefore, minus points don’t protect, they subtract.
Another way to check this is to create some -/+ control points and enable mask viewing. Delete one of either type and then add it back at the same spot. You are moving the control point to the end, so its effect will change since they are processed in order. If minus points offered protection, there would be no change when you moved a plus point behind it in the processing sequence.
The only part that’s unclear is whether the limit of 0-256 is applied for each addition/subtraction or only for the final result. I would bet on the latter.
You can see it better if you add a second then a third protective line : the zone is better protected after the second and third protective line (but not completly yet) :
image 4 - 2 protective lines (second one selected) :
even with 3 protective lines, the effect is still visible in the most protected part of the image.
PS : you can move any pipette anywhere on this image, the result is the same since there is only one color in this image : this test result does not depend on pipettes positions.
Interesting. You can see what’s happening pretty well with your examples, but it’s even clearer when viewing the B&W masks.
I played around with this a bit on PL7 and noticed two things:
Control points don’t seem to have the same problem, or at least the problem is less (i.e. the center of the control point seems fully protected).
Given an image with a single color, one would expect the chroma and luma sliders to have no effect, but they do! The change is best observed if one slider is in the middle and the other is moved around.
Luminosity masks work much more sensibly.
Given what I’ve learned, I don’t think control points/lines can be adapted to match luminosity masks. Nor should luminosity masks be given lumen/chroma sliders. I’m limiting my feature request here to adding a feathered color range selection to the luminosity mask.
Hmmm, which is difficult (not to say impossible), as a Luminosity mask by definition is based on luminance only – unlike Control line and Control point.
.
However, it would be helpful to equip the local HSL tool the same as its global counterpart
with a picker
and the sophisticated color range selector
(in Windows: holding down Ctrl while pulling on of the color range markers)
Well, if the name is the only barrier, change the name.
By having the default be to 100% select all colors, then this tool (whatever its name) would be exactly equivalent to a luminosity mask.
Some notes:
The global HSL tool already has a picker, but changes to the selected pixels are global and limited to the controls in the HSL tool.
The new HSL adjustment in the Local Adjustments pane has no picker. Even if it did, it would only be useful in defining a range to apply to the masked pixels.
A new tool that used an HSL control to create a mask is less useful than adding the same ability to the luminosity mask. I’d like to mask pixels based on both luminosity and color.
Currently, some mask selection tools can be combined; e.g. you can use a luminosity mask and then use the brush and erase tools (and it has to be in that order: the luminosity mask must be first). I would be OK with having an HSL tool that could be combined with the luminosity tool (applied in either order), but I suspect it would be easier to design a combined luminosity/color selector tool.
A long time ago in my misspent youth, I actually wrote what I called a color replacer tool as a Photoshop extension. It still works with my old CS6 version of PS. It selects pixels based on hue, luminosity, and saturation and then generates a PS mask or selection.
I believe DarkTable has this feature as well (the ability to create masks from hue, luminosity, and saturation) and a number of other advanced masking capabilities. Their user interface is atrocious, though.
The feature is not hard to implement–the toughest part is the UI and the HSL control already provides a good starting point. Let’s not get hung up on a name.
The HSL tool, as it stands, would need a luminosity range selector in order to specify both hue and luminosity. DxO could either add a hue range selector to the luminosity mask tool (what I proposed) or DxO could add the luminosity range selector to an entirely new HSL mask tool. If we wanted to make sure the masking tool’s functionality conformed to the HLS name, DxO could further add a saturation range selector.
It’s fine with me. But I’d also be fine with just adding a hue range selection to the current luminosity mask tool. In my experience working with my “color replacer” PS extension, having a saturation range is not that critical.
