Brilliance is a color coordinate along a certain axis, that is illustrated when we compare a color against different surrounds, but as far as we are concerned, it’s just one dimension of a 2D vector space, defined by rotation of the brightness/chroma vector space by a certain angle.
We increase or decrease it by applying a gain along that axis. High brilliance will have a different look depending on surround, but any pixel gets a correction proportional to its original brilliance, so the local connections are preserved.
We don’t affect the contrast of brilliance, so no locality gets convolved into the mix.
I think figure 1.8.7 the bottom half is what you are referring to and I think I understood the graph and the concept with the only question left if ‘brilliance’ is a vector which points from the blackpoint to the point of maximum saturation/colorfulness for each hue-angle.
Which would be along the grey arrow(grayness/blackness) in said graph, bottom row, case C, except the arrow points into the other direction?
Okay! Thank you so much. I think I got it now, this will help explaining stuff to people.
The benefit of this method is to let you reach colors that were simply not accessible with the usual chroma boost. I have longed for Kodak Portra kind of rich pastel colors :
They are impossible to get with the usual chroma/luma approach because “desaturation” in this framework gives grey-ification whereas we need to add white in our colors.
I was trying this new module (3.5.0+1089) and have a few queries.
Firstly, I’d like to be able to get a pastel look, but I’ve not been able to get anything decent so far, I can’t work out what to do. What’s the technique for “pastelizing” an image please? Which dt modules should you use, how, etc?
Second: Old and new color balance come before filmic in the pipeline. Is it ok to move the new one post-filmic? I ask only because it feels a little strange as they are currently positioned. I remember it was said ages ago that typically you can use filmic to sort out your image basics, and hence you have a basis for further “artistic” adjustments if you need them. So it seems natural to me that you might do exposure, colour calibration, filmic etc and then on top of that apply changes such as pastel effect. In particular, if filmic is doing some heavy highlight reconstruction, I can’t help feel it’s best to get that processed in the pipeline before tweaking colours, saturation, brightnesses.
The whole pipeline has been designed so the view transform happens late, ideally just before conversion to output color space (but that’s not possible because of all the legacy modules), and the artistic transforms are done before. The reason is the view transform might need to change depending on the dynamic range of the output (even though for now it’s pretty much an 8 bits SDR LED panel all the time, for reasons that have to do with Gtk/Xorg, but let’s think ahead and prepare).
The pipeline order has not necessarily direct ties to the editing order. Image basic don’t imply the module should come early in the pipe, that place in the pipe depends on what kind of signal you expect, aka what you want your pixels to represent.
Don’t get mistaken by filmic’s reconstruction, it’s only meant to ensure smooth gradients where the dynamic range ends, in case there is highlight clipping. It’s more like a last-chance safety jacket than a technical signal reconstruction.
Pastel is achieved by pushing the saturation sliders left and purity sliders right in color balance rgb.
So when you say using tonal corrections do you mean to use a tone curve or contrast eq??? There will really be no scene-referred contrast slider?? If the Tone Eq how would you do a global contrast adjustment with that??
been playing around with the new colorbalancergb module. It’s an awesome new module. almost similar to resolve 17 HDR colors wheels the control is great. I think a 2d color wheel control would be a great addition as it would make the adjusting in complementary or triadic easier. and with the combination of CTRL and Shift for increment control it would enable very fine adjustment. a color wheel is also easier for most artist as most are train with the color wheel. it might not be 100% correct but that how most artist are train in school. one more thing I think it currently does not leverage opencl.
hope the devs would consider the 2D color wheel interface
Can you clarify…as to a global adjustment. I have noticed that this preset does seem to alter the image even though all the sliders are at zero and the curve is still strait. Any idea why that happens…wont you still have to adjust the sliders and or the curve…I am sure this is great for control accuracy correctness but sometimes you just want a slider to bump contrast…maybe I am missing something??
Never. 2D controls suck when you have a mouse and a keyboard, because nailing a position accurately with a mouse pointer on a 2D graph is a PITA. Color wheels in video software exist because colorists actually have hardware wheels on their control panels. But 2D graphs are really bad news otherwise.
But it’s exactly the same thing really. On the 2D wheel, radius is chroma and angle is hue. Here, you have chroma and hue as 2×1D sliders, which you can operate from shortcuts, arrow keys, mouse wheel or mouse pointer at your convenience, and even wire to MIDI controllers once the PR lands.
Another thing about a wheel is that it gets around a difficulty with a straight-line widget, namely that if you’re masking parametrically a redish hue, you might need the range to wrap around the colour bar, but it won’t do this. (However you can select the body of the colour bar, everything except what you actually want, then invert it)
Otherwise, it’s a bit like the old zone system, arranged differently.
If you select a spot and want more contrast around it, you push darker tones down, brighter tones up. Here’s a photo, just to demonstrate. Before:
The two prominent peaks are the green of the grass and the bright blue sky. By dropping the brightness of the first and increasing the latter, I can increase the contrast between them.
I’m not saying this is the most intuitive or best tool, but AFAIK, this is what Aurélien now recommends:
Then we could have a GUI helper slider that enlarges or reduce the lobes width around the ground level. Beauty of having a general framework is, again, to be able to specialize it later.
That would be awesome as you seem to be able to dial in some nice rich contrast without going overboard. And then you will have a format that you could add the the quick access as well…As always thank you for your comments…
I thought you would have it in that build…type rgb in the search and it should come up…maybe you need a bit later one…as for the tone eq see the short attached video…its not big deal but there is some calculation applied as the histogram shift a bit when you enable and disable it…all corrections are visibly set to zero…
