No, we’ll have both (just try the PR mentioned above):
1 Like
I’m happy, thanks.
All, a note about the old method… There have been several comments about adding/changing a point having a “global” effect which means other parts of the curve change. There is a simple workaround if you don’t want that. Simply have two points fairly close together and this acts as a clamp. That is, moving the curve on one side of the clamp has negligible effect on the curve that’s on the other side of the clamp. A second point can be easily added close to an existing one by placing it with CTRL + mouse click - it will jump exactly onto the curve. So the old curve can be nice and smooth if you want that. Or by placing more points, you can imitate the more “local” behaviour of the new curve.
1 Like
Question: Which curve is used by the Auto-Matched Tone Curve, new or old?
new
Which means that you have to move two points when you want to change the curve in that region. Makes it more difficult to immediately see the result. Also you can easily delete a node if you drag one node over the other.
This is true. But once you’ve dragged one away, then you immediately see the result as you move the remaining one. It takes me a while to do a curve so having to do this removing thing once or twice isn’t much of an overhead for me.
Sorry for the late input, just got back from the woods…
I’ve considered this in my software, and I’ve come to the conclusion that I’m wedded to Tino Kludge’s spline algorithm until the heat death of the universe. The spline algorithm that forms the foundation of a curve tool really becomes the basis of the image manipulation with respect to determining input->transform->output, and changing it renders a good many curves as defined by a set of control points based on the previous spline as plain wrong.
I explored a more ‘local’ spline algorithm, but abandoned the effort when i realized 1) the legacy of control point lists I already had, and 2) I can make my Tino Kludge spline be local, but I can’t make a local algorithm easily provide the sweeping curves that distort my image tones less than, say, a lift in one area that then produces a relatively flat slope that really distorts the tones of a particular band.
I do a good bit of what Andrew describes, using two close points to anchor the remaining slope. Works for me…
1 Like
Hmm, those zeros are from rtengine::DiagonalCurve::getVal() which is not GUI specific as far as I can tell.
1 Like
You’re right, I was a bit too quick in dismissing this. I’ll take a look when time permits 
@agriggio Alberto, I think I found the culprit: It’s the special case for 0 and 1. Though I don’t know how to fix that…
1 Like
yes, I’m working on it… thanks for the hint!
Here’s the patch. I’ll push later today
diff --git a/rtengine/diagonalcurves.cc b/rtengine/diagonalcurves.cc
--- a/rtengine/diagonalcurves.cc
+++ b/rtengine/diagonalcurves.cc
@@ -326,6 +326,9 @@
if (p1_y == p2_y && (p1_y == 0 || p1_y == 1)) {
for (i = 1; i < n_points-1; ++i) {
t = p1_x + space * i;
+ if (t >= p2_x) {
+ break;
+ }
res_x.push_back(t);
res_y.push_back(p1_y);
}
2 Likes
@agriggio this is awesome! thanks for the fix. Btw is this C++ or an RT-specific scripting language?
That’s C(++)
@floessie @heckflosse well I took a C++ class in highscool many years ago …and I technically enjoy programming. I could get off my butt and check out the source code 
Was that a serious invitation? I’d probably try to turn the RGB curves into two versions of them, one for just RGB, the other for just luminance and piss everybody off
2 Likes
As release cycles are long you should definitely do that to get the latest greatest RT and report new bugs early.
Why not give it a try. Incubate the feature in your fork, file a PR, and we’ll see if it’s of use for everyone.
HTH,
Flössie
1 Like
Actually, I believe that some would love it.
2 Likes
@Claes the reason I thought they may not is that I mentioned it a bunch of times and people were quick to reassure me that the fact that there is only one instance, and you have to choose whether you want to modify regular RGB curves OR luminance curves, it is definitely not a bug but a feature. So I’m like okay… guess people think it’s irrelevant and overkill to have both.
Now that being said, I get it, I have a history of editing in Gimp and that if I had it my way, RawTherapee would have a button next to each tool to add an additional instance of that tool, or a number of them, so one can have 4 or 5 curves (let’s say in the Exposure section), and that such a thing might be a little much to implement. As far as I am concerned, though, I am very happy that now there are 2 of them, rather than just the one that Lightroom has, and the more versatility in tool usage the better. RawTherapee’s engine is great, and the more work on an image I can do in it, rather than export and open in another program, the better. I do a lot of portrait work, but not much involving cloning or other local stuff, though I am glad that the locallab is on its way to completion, and I will certainly use it on portraits once its there.
Since on this topic, just out of curiosity, according to the current way that things are implemented in RawTherapee, would it be complicated to have multiple instances of tools in the flow? Say how we have the exposure section; we can turn it on or off, would we be able to add another instance with the same content, to be applied right after the first, after which to continue with the other tools as per usual? I suppose it would depend on whether the pp3 file system is programmed to expect a certain series of tools in a certain order, or whether it is programmed to scan the file from beginning on progressively based on what’s in the file and apply things as they show up.
I am aware that the people in the development team (for whom I have a great deal of respect and admiration btw) are currently in the process of figuring out the feasibility and ins and outs of potentially saving the snapshots that RT allows to create (so that they are not lost once the file is closed and reopened); and this is why I thought it a good time to bring this up …if we are to modify the very way pp3 files work, rather now than doing it over again later. Now that being said I don’t mean to cause anybody unneeded headaches, and I am grateful for whoever bothers to write this novel I posted here and reply on it 
1 Like
Now this is very hypothetical, but if one wanted to start dabbling in the development is there a guide on:
- How RT is structured? Which tools code can be found where?
- How to work on github effectively without getting on everybodies nerves?
@stefan.chirila: +1 on the double curves.
2 Likes