After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 792326 - Add color area widgets to the Color Balance tool
Add color area widgets to the Color Balance tool
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: Tools
unspecified
Other All
: Normal enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2018-01-08 13:48 UTC by Alexandre Prokoudine
Modified: 2018-05-24 18:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
color grading plug-in (236.41 KB, image/png)
2018-01-08 13:48 UTC, Alexandre Prokoudine
Details

Description Alexandre Prokoudine 2018-01-08 13:48:43 UTC
Created attachment 366492 [details]
color grading plug-in

Some bloke in a forum (c)(r)(tm) pointed out that the Color Grading plug-in (written in Python) provides an easier to use UI (see attached image) that relies on moving a dot on the color area. He also asked if we could update our Color Balance tool to use this kind of UI.

I've used this in video editors before and I tend to agree that Color Balance isa kind of a tool where visual adjustment would be a very much welcome addition to the numeric inputs we currently have. We already have a widget for that, and we even expose it to GEGL operations (e.g. Rotate Colors).

Moreover, our implementation differs from regular implementations of lift/gamma/gain by _not_ providing controls for lift/gamma/gain levels (the aforementioned plug-in does).

I see here several possible courses of action:

1. Add lift/gamma/gain (shadows/midtones/highlights) levels to gimp:color-balance and use color area widgets (e.g. on a different tab). Possibly switch to using LCH rather than HSL to keep Elle happy :)

2. Port darktable's color balance filter and write custom UI for it. Note that computations in darktable's implementation of color balance are all done in RGB, so we might cut processing time a little. _And_ there's an OpenCL version of that filter in dt which we could also port.

Since adding shadows/midtones/highlights levels would break API, I'd suggest targeting 3.0 rather than 2.10.x.
Comment 1 Alexandre Prokoudine 2018-01-09 13:19:29 UTC
Here's another idea from FCPX:

https://i.ytimg.com/vi/-VS6nsg-Xvw/maxresdefault.jpg

Each color area has co-sliders for saturation and brightness.
Comment 2 GNOME Infrastructure Team 2018-05-24 18:59:48 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/1279.