SUMMARY When positioning the end handles of any channel curve so that the numeric values are exactly Input = Output, effectively clipping the output range without changing in-between values, the filter behaves like the curve hasn't been adjusted at all. STEPS TO REPRODUCE 1. Open Filter > Adjust > Color Adjustment curves... and pick any channel 2. Reposition the first end handle of the default linear curve and make sure the value of the Input exactly matches the Output - for example to 127, 127 on an 8-bit image to clip the lower half of the values 3. Add +/- 1 to the input and observe the immediate difference OBSERVED RESULT The adjusted result is identical to the untouched linear curve. EXPECTED RESULT The values beyond the end handles should be clipped in the adjusted image. SOFTWARE/OS VERSIONS Tested in 4.3.0-prealpha (git 511ecc7) and 4.2.6, resulting in the same behavior. ADDITIONAL INFORMATION Inserting additional curve nodes that also conform to Input = Output won't affect the result either.
I can't reproduce; can you please attach a file to see the results and the screenshot of your filter settings? Or maybe a .kra file with a filter layer or mask if it shows the issue, too.
Created attachment 122970 [details] Test file with buggy filter Here you go. The top layer is the Color Adjustment, and despite having crushed RGBA towards the middle and Red towards the brightest values, the image appears unaltered. When you open the layer properties and tweak the curves by a tiny amount, the adjustment turns visible.
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
Yeah, I can confirm with that image. I wonder if there's some kind of optimization or something doing this? I can see there's one for identity curves(KisPerChannelFilter::createTransformation 207), but is this really an identity curve?
identity seems to be added for optimization, to avoid calculating in extreme cases. However all it does is checking all curve points p, have the corrdinates (x,x). which makes the results wrong in cases were the extremes are not min/max respectively. REmoving the identity check solves the issue and should not give any error, but the "special case" will not be optimized.
Git commit 8b1ac0f6d645ba87502b8ccb471246fac9231b01 by Ivan Yossi. Committed on 14/10/2019 at 17:27. Pushed by rempt into branch 'master'. Fix Color Adjustment Curves not processing on some cases isIdentity will only resolve to true if the corners are placed in the corners and the middle points are all x = y M +7 -2 libs/image/kis_cubic_curve.cpp https://invent.kde.org/kde/krita/commit/8b1ac0f6d645ba87502b8ccb471246fac9231b01
Git commit bfd110a3a51385d57e1dd2aea8b73ead0053b37a by Boudewijn Rempt, on behalf of Ivan Yossi. Committed on 21/10/2019 at 12:58. Pushed by rempt into branch 'krita/4.2'. Fix Color Adjustment Curves not processing on some cases isIdentity will only resolve to true if the corners are placed in the corners and the middle points are all x = y (cherry picked from commit 8b1ac0f6d645ba87502b8ccb471246fac9231b01) M +7 -2 libs/image/kis_cubic_curve.cpp https://invent.kde.org/kde/krita/commit/bfd110a3a51385d57e1dd2aea8b73ead0053b37a