I agree… let’s see if I manage to explain things correctly, maybe @Elle can step in if I’ll say something wring:
luminance is the second component of an XYZ triplet. Relative luminance is Y divided by the luminance of the reference white point Yn (Yr = Y/Yn). However, the RGB → XYZ matrix given by the RGB primaries of an ICC profile are such that Yn = 1, therefore the Y value computed from the ICC primaries is actually Yr.
lightness (HSL) is a different thing, which unfortunately is called in the same way as L*…
The reason why I have used the term luminance in the B&W conversion tool is that the resulting image is encoded with the same TRC as the initial RGB data, and not necessarily with the L* TRC. However, the resulting image is equivalent to L* lightness.
Finally, the luminance blend mode in PhF does exactly what Elle describes in the article you are referring to. Moreover, since few days the LCH Lightness blend mode is also available…
Hope this is shading a bit of light on this lexical mess!
This switch allows to edit a linear RGB image using a linear curve represented with perceptually uniform axes.
Here is an example of a curve applied to a linear image and represented in perceptual coordinates. Notice the non-trivial behaviour of the curve in the dark tones, which is not a mistake but the result of the linear part of the L* TRC:
The same curve control points, but this time applied to an image encoded with the L* TRC. The curve is now smooth, because the spline interpolation between the points occurs in the same L* encoding, however the effect on the dark areas is much less “natural”:
My suggestion: keep the image in linear RGB, and switch between perceptual and linear representation of the curve depending if you want to fine-tune the dark or light areas of the image.
EDIT: I hope that @Morgan_Hardwood has nothing against the use of this image as an illustration…
Absolutely, in fact I’m happy if you do as that lets me see rendering of this scene in other ways than the ones I attempted. FWIW the scene looked overall much lighter to the human eye.
What I show above is the mere result of a non-linear tone curve applied to the linear RGB data, without any local contrast enhancement… I guess that our brain performs some sort of local contrast enhancement to compress the dynamic range. Or maybe a better definition would be global contrast compression?
Anyway, I still need to find a local contrast enhancement/global contrast compression method that does not look “fake”… One day or another I will play with RT’s retinex tool, as I have read a lot of good things about it!
@Carmelo_DrRaw Uncertain whether it is fake-looking or not but I have always enjoyed using CLAHE. It is implemented in a bunch of ways, some of which don’t look appealing at all.
Hi @Carmelo_DrRaw - I’ve been using PhotoFlow (updated just a couple of days ago, linear gamma branch) and had some more or less minor user interface observations:
When I asked PhotoFlow to mark hot pixels that were fixed, I didn’t see any marking lines in the PhotoFlow window before transferring the image to GIMP, but once transferred to GIMP the hot pixels all had vertical lines through them.
When setting custom RGB values for the white balance, the WB mode continues to read “Camera”, but it might be less misleading/confusing if it said “Custom”.
The little boxes for typing in custom RGB values are too narrow, at least on my machine, so it’s hard to tell if all the numbers have been selected and even harder to enter new numbers. Making the panel wider doesn’t make the little boxes any wider.
How does one save a preset for the raw processing layer? I’ve been right-clicking on the layer and saving “something” to the PF config folder that shows up as the suggested place to save the prefix, but when I go to load a saved preset, it’s just not ever there. Maybe PF is saving to the home folder and looking in the prefix folder? Is it necessary to add a suffix/file extension or does PF do this automatically? If I need to add a file extension, which one?
@Elle What do you mean by the first point? I am interested. I have been complaining about the second point for a while now, but I know it is on @Carmelo_DrRaw’s to do list so I can wait .
Hi @afre, I’m not sure what you are asking about, so I’ll cover some possible interpretations.
“Hot” and “dead” pixels are pixels that respectively have one or more channels that read 100% full well instead of responding to the actual amount of recorded light, or else don’t respond at all, but I suspect this is something you already know .
PhotoFlow (and also darktable) allows to show the user which pixels have been fixed, by drawing a short line through the hot/dead pixels on the screen during raw processing. The lines aren’t supposed to be in the output image, only in the image shown on the screen during raw processing.
In Photoflow, the relevant dialog is on the Raw developer layer in the tab labelled “Corr”.
First of all, I have just finished introducing the RCD demosaicing into photoflow. The implementation is based on the RT version, adapted to process small image tiles in parallel.
Moreover, and following what @agriggio has reported, I have modified the RAW data clipping behaviour in photoflow, which results in much lower purple fringing around dark objects on clipped backgrounds. The improvement is visible for all demosaicing methods, but only when the highlights reconstruction is set to clip (which is the default mode).
The new logic is the following:
when the highlight reconstruction is set to clip, the WB multipliers are scaled such that the lowest one has a value of 1. The RAW values are then multiplied by the WB coefficients and then clipped to the [0…1] range.
when the highlights reconstruction is set to blend or none, the WB multipliers are scaled such that the highest one has a value of 1. The RAW values are then multiplied by the WB coefficients, without being clipped. After the demosaicing, and before the conversion to the working colorspace, the RGB values are then scaled by the ratio between the highest and lowest WB coefficient, so that the image brightness is the same as in clip mode.
Note that in all cases the demosaicing is performed after converting the RAW data to the user-chosen WB.
Here is a comparison between the Amaze output with HL reco set either to clip and blend (which corresponds also to the old clip mode as long as purple fringing is concerned):
Amaze, blend mode:
Amaze, clip mode:
Finally, here is the output of the RCD demosaicing in clip mode:
There is a slight difference between the two demosaicing methods, but not really a striking one…
Second, I have added a curve representation for the tone mapping functions, which should ease the tweaking of parameters. The curves are represented in perceptual encoding, to better visualise the effect in dark areas. Here is a screenshot showing the filmic new curve with default parameters:
You are perfectly right! However, while the solution it is easy to describe, it requires some refactoring of the WB UI code in order to implement it. I think I will postpone this until I will also implement some “spot WB over a user-selectable area”, which is something I have on my TODO list since long time and I now want to finally get done.
Are you talking about the boxes in this screenshot?
Just to be sure that I’ll modify the good ones…
Right-clicking on the layer and saving is the correct procedure. The preset can be saved in any folder of your choice, but nedds to have a .pfp extension. I should modify the code such that the extension is automatically added if missing… please ping me on this github issue in case you have no news during the next couple of weeks…
Was asking because I haven’t been seeing those lines. If you could provide an image of what that looks like, that would be great.
@Carmelo_DrRaw Thanks for the implementation of RCD and giving attention to WB. About clipping, I didn’t understand the relationship between the reconstruction mode and the negative and overflow clipping back when you briefly explained it to me in the other thread. Could you explain it to me again but in the context of the new changes? Thanks.
Let’s suppose we are processing aRAW image with daylight WB multipliers, which can be typically of this order of magnitude:
WB_R = 2.0
WB_G = 1.0
WB_B = 1.6
A clipped highlight will have a normalised RAW value of 1.0 in all channels. After WB correction, the highlights will acquire a purple tint due to the fact that the R and B channels are multiplied by a larger factor than the G channel. This is obviously unphysical and must be cured…
What is done by RT and the previous PhF code is the following:
the WB multipliers are first scaled such that the largest coefficient is equal to one. In our specific case, this would mean
the RAW values are scaled by those coefficients and then fed to the demosaicing routine
the resulting RGB values are scaled by the ratio between the maximum and minimum WB multipliers (2.0 in this case).
finally, the RGB values are clipped to fit into the [0…1] range
What happens in this case is that blown-out RAW pixels around dark areas have an overall purple tint instead of being neutral, and this tint “leaks” into the dark areas through the demosaicing process.
A more conservative approach, which cures the purple issue at the expense of some loss in dynamical range, is the following:
the RAW values are scaled with the higher WB coefficients, those for which WB_G = 1.0, and then clipped to the [0…1] range and fed to the demosaicing routine
the resulting RGB values are again clipped to the [0…1] to remove possible over- or under-shooting introduced by the demosaicing.
This is what happens in the latest PhF version when you set the HL reconstruction to clip. The other methods still use the first procedure.
The caveat with the clip method is that R or B pixels that have large (but not clipped) values will be discarded by the clipping applied at step 1. For example, any raw R value above 0.5 will be clipped, reducing the effective dynamical range of the R channel to one half.
I am currently testing some workaround that allows to keep all the available information without introducing the purple fringing problem…
@Carmelo_DrRaw Thanks for the detailed response. I actually understand that part already. What I intended to ask about was the relationship between the exp and color tabs. I.e., highlights reco and clip negative / overflow values. Which is done first and do they affect one another?
The clipping in the color tab happens after the ICC conversion to the working colorspace. For example, you can have an RGB value in the camera colorspace where all three components are below 1.0. However, such color might be outside of the gamut of the output colorspace (sRGB or whatever) and therefore result in at least one RGB channel above 1.0 or below 0.0. Activating both clipping options in the color tab will cut the RGB values in the working colorspace to the [0…1] range.
I hope this clarifies your doubts, otherwise just ask further…
No, the exposure compensation is applied after demosaicing and before the color space conversion, otherwise you would get problems with DCP profiles that have a nonlinear tone curve…
@Carmelo_DrRaw, I have lately been using version 20171117 and now 20171124. In both versions I get a crash everytime I use more than one layer as mask.
Furthermore in Version 20171124, when I use the L channel of the clone layer I get strange results
.
.
(in RT though). I’ll report back when I have something people can test