2003-12-05 15:55:15 +00:00
|
|
|
/* LIBGIMP - The GIMP Library
|
|
|
|
* Copyright (C) 1995-1997 Peter Mattis and Spencer Kimball
|
2002-10-29 23:18:23 +00:00
|
|
|
*
|
|
|
|
* gimpcolorscale.c
|
2010-04-19 19:21:07 +02:00
|
|
|
* Copyright (C) 2002-2010 Sven Neumann <sven@gimp.org>
|
|
|
|
* Michael Natterer <mitch@gimp.org>
|
2002-10-29 23:18:23 +00:00
|
|
|
*
|
2009-01-17 22:28:01 +00:00
|
|
|
* This library is free software: you can redistribute it and/or
|
2002-10-29 23:18:23 +00:00
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
2009-01-17 22:28:01 +00:00
|
|
|
* version 3 of the License, or (at your option) any later version.
|
2003-12-05 15:55:15 +00:00
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
2002-10-29 23:18:23 +00:00
|
|
|
* Library General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
2009-01-17 22:28:01 +00:00
|
|
|
* License along with this library. If not, see
|
2018-07-11 23:27:07 +02:00
|
|
|
* <https://www.gnu.org/licenses/>.
|
2002-10-29 23:18:23 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include "config.h"
|
|
|
|
|
2002-11-25 00:04:26 +00:00
|
|
|
#include <string.h>
|
|
|
|
|
2012-05-03 03:36:22 +02:00
|
|
|
#include <gegl.h>
|
2002-10-29 23:18:23 +00:00
|
|
|
#include <gtk/gtk.h>
|
|
|
|
|
|
|
|
#include "libgimpbase/gimpbase.h"
|
2016-05-27 00:51:32 +02:00
|
|
|
#include "libgimpconfig/gimpconfig.h"
|
|
|
|
#include "libgimpcolor/gimpcolor.h"
|
2002-10-29 23:18:23 +00:00
|
|
|
|
|
|
|
#include "gimpwidgetstypes.h"
|
|
|
|
|
2010-09-10 21:27:42 +02:00
|
|
|
#include "gimpcairo-utils.h"
|
2002-10-29 23:18:23 +00:00
|
|
|
#include "gimpcolorscale.h"
|
2016-05-27 00:51:32 +02:00
|
|
|
#include "gimpwidgetsutils.h"
|
2002-10-29 23:18:23 +00:00
|
|
|
|
|
|
|
|
2010-07-05 18:01:28 +02:00
|
|
|
/**
|
|
|
|
* SECTION: gimpcolorscale
|
|
|
|
* @title: GimpColorScale
|
|
|
|
* @short_description: Fancy colored sliders.
|
|
|
|
*
|
|
|
|
* Fancy colored sliders.
|
|
|
|
**/
|
|
|
|
|
|
|
|
|
2011-02-15 18:52:00 +01:00
|
|
|
enum
|
|
|
|
{
|
|
|
|
PROP_0,
|
|
|
|
PROP_CHANNEL
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2017-05-17 19:28:40 +02:00
|
|
|
typedef struct _GimpLCH GimpLCH;
|
|
|
|
|
|
|
|
struct _GimpLCH
|
|
|
|
{
|
|
|
|
gdouble l, c, h, a;
|
|
|
|
};
|
|
|
|
|
|
|
|
|
2016-05-27 00:51:32 +02:00
|
|
|
struct _GimpColorScalePrivate
|
|
|
|
{
|
2011-01-02 02:39:12 +01:00
|
|
|
GimpColorConfig *config;
|
|
|
|
guchar oog_color[3];
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
const Babl *format;
|
2011-01-02 02:39:12 +01:00
|
|
|
|
|
|
|
GimpColorSelectorChannel channel;
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
GeglColor *color;
|
2011-01-02 02:39:12 +01:00
|
|
|
|
|
|
|
guchar *buf;
|
|
|
|
guint width;
|
|
|
|
guint height;
|
|
|
|
guint rowstride;
|
|
|
|
|
|
|
|
gboolean needs_render;
|
2016-05-27 00:51:32 +02:00
|
|
|
};
|
|
|
|
|
2018-05-03 12:51:36 +02:00
|
|
|
#define GET_PRIVATE(obj) (((GimpColorScale *) (obj))->priv)
|
2016-05-27 00:51:32 +02:00
|
|
|
|
|
|
|
|
2010-12-21 00:07:03 +01:00
|
|
|
static void gimp_color_scale_dispose (GObject *object);
|
|
|
|
static void gimp_color_scale_finalize (GObject *object);
|
|
|
|
static void gimp_color_scale_get_property (GObject *object,
|
|
|
|
guint property_id,
|
|
|
|
GValue *value,
|
|
|
|
GParamSpec *pspec);
|
|
|
|
static void gimp_color_scale_set_property (GObject *object,
|
|
|
|
guint property_id,
|
|
|
|
const GValue *value,
|
|
|
|
GParamSpec *pspec);
|
|
|
|
|
|
|
|
static void gimp_color_scale_size_allocate (GtkWidget *widget,
|
|
|
|
GtkAllocation *allocation);
|
|
|
|
static gboolean gimp_color_scale_draw (GtkWidget *widget,
|
|
|
|
cairo_t *cr);
|
|
|
|
|
|
|
|
static void gimp_color_scale_render (GimpColorScale *scale);
|
|
|
|
static void gimp_color_scale_render_alpha (GimpColorScale *scale);
|
|
|
|
|
|
|
|
static void gimp_color_scale_notify_config (GimpColorConfig *config,
|
|
|
|
const GParamSpec *pspec,
|
|
|
|
GimpColorScale *scale);
|
2002-10-29 23:54:02 +00:00
|
|
|
|
|
|
|
|
app, libgimp*, modules: don't use g_type_class_add_private() ...
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
2018-09-18 12:09:39 -04:00
|
|
|
G_DEFINE_TYPE_WITH_PRIVATE (GimpColorScale, gimp_color_scale, GTK_TYPE_SCALE)
|
2002-10-29 23:18:23 +00:00
|
|
|
|
2005-12-20 20:35:23 +00:00
|
|
|
#define parent_class gimp_color_scale_parent_class
|
2002-10-29 23:18:23 +00:00
|
|
|
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
static const Babl *fish_lch_to_rgb = NULL;
|
|
|
|
static const Babl *fish_hsv_to_rgb = NULL;
|
|
|
|
static const Babl *fish_rgb_to_cairo = NULL;
|
2017-05-17 19:28:40 +02:00
|
|
|
|
2002-10-29 23:18:23 +00:00
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_color_scale_class_init (GimpColorScaleClass *klass)
|
|
|
|
{
|
2010-10-15 02:12:33 +02:00
|
|
|
GObjectClass *object_class = G_OBJECT_CLASS (klass);
|
2004-07-13 14:55:16 +00:00
|
|
|
GtkWidgetClass *widget_class = GTK_WIDGET_CLASS (klass);
|
2002-10-29 23:18:23 +00:00
|
|
|
|
2018-05-20 02:06:47 +02:00
|
|
|
object_class->dispose = gimp_color_scale_dispose;
|
|
|
|
object_class->finalize = gimp_color_scale_finalize;
|
|
|
|
object_class->get_property = gimp_color_scale_get_property;
|
|
|
|
object_class->set_property = gimp_color_scale_set_property;
|
2002-10-29 23:18:23 +00:00
|
|
|
|
2018-05-20 02:06:47 +02:00
|
|
|
widget_class->size_allocate = gimp_color_scale_size_allocate;
|
|
|
|
widget_class->draw = gimp_color_scale_draw;
|
2011-02-15 18:52:00 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* GimpColorScale:channel:
|
|
|
|
*
|
|
|
|
* The channel which is edited by the color scale.
|
|
|
|
*
|
2015-05-31 21:18:09 +02:00
|
|
|
* Since: 2.8
|
2011-02-15 18:52:00 +01:00
|
|
|
*/
|
|
|
|
g_object_class_install_property (object_class, PROP_CHANNEL,
|
2017-06-06 21:19:17 +02:00
|
|
|
g_param_spec_enum ("channel",
|
|
|
|
"Channel",
|
|
|
|
"The channel which is edited by the color scale",
|
2011-02-15 18:52:00 +01:00
|
|
|
GIMP_TYPE_COLOR_SELECTOR_CHANNEL,
|
|
|
|
GIMP_COLOR_SELECTOR_VALUE,
|
|
|
|
GIMP_PARAM_READWRITE |
|
|
|
|
G_PARAM_CONSTRUCT));
|
2016-05-27 00:51:32 +02:00
|
|
|
|
2018-05-01 00:17:27 +02:00
|
|
|
gtk_widget_class_set_css_name (widget_class, "GimpColorScale");
|
|
|
|
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
fish_lch_to_rgb = babl_fish (babl_format ("CIE LCH(ab) double"),
|
|
|
|
babl_format ("R'G'B' double"));
|
|
|
|
fish_hsv_to_rgb = babl_fish (babl_format ("HSV double"),
|
|
|
|
babl_format ("R'G'B' double"));
|
|
|
|
fish_rgb_to_cairo = babl_fish (babl_format ("R'G'B' u8"),
|
|
|
|
babl_format ("cairo-RGB24"));
|
2016-05-27 00:51:32 +02:00
|
|
|
}
|
|
|
|
|
2002-10-29 23:18:23 +00:00
|
|
|
static void
|
2002-10-29 23:54:02 +00:00
|
|
|
gimp_color_scale_init (GimpColorScale *scale)
|
2002-10-29 23:18:23 +00:00
|
|
|
{
|
2018-05-03 12:51:36 +02:00
|
|
|
GimpColorScalePrivate *priv;
|
2011-01-02 02:39:12 +01:00
|
|
|
GtkRange *range = GTK_RANGE (scale);
|
2017-05-22 22:55:25 +02:00
|
|
|
GtkCssProvider *css;
|
|
|
|
|
app, libgimp*, modules: don't use g_type_class_add_private() ...
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
2018-09-18 12:09:39 -04:00
|
|
|
scale->priv = gimp_color_scale_get_instance_private (scale);
|
2018-05-03 12:51:36 +02:00
|
|
|
|
|
|
|
priv = scale->priv;
|
|
|
|
|
2017-05-22 22:55:25 +02:00
|
|
|
gtk_widget_set_can_focus (GTK_WIDGET (scale), TRUE);
|
2002-10-30 00:21:31 +00:00
|
|
|
|
2010-04-19 19:21:07 +02:00
|
|
|
gtk_range_set_slider_size_fixed (range, TRUE);
|
2009-10-17 18:51:48 +02:00
|
|
|
gtk_range_set_flippable (GTK_RANGE (scale), TRUE);
|
2018-06-20 12:39:26 +02:00
|
|
|
gtk_scale_set_draw_value (GTK_SCALE (scale), FALSE);
|
2009-10-17 18:51:48 +02:00
|
|
|
|
2011-01-02 02:39:12 +01:00
|
|
|
priv->channel = GIMP_COLOR_SELECTOR_VALUE;
|
|
|
|
priv->needs_render = TRUE;
|
2002-10-29 23:54:02 +00:00
|
|
|
|
2009-07-15 01:53:30 +02:00
|
|
|
gtk_orientable_set_orientation (GTK_ORIENTABLE (range),
|
|
|
|
GTK_ORIENTATION_HORIZONTAL);
|
|
|
|
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
priv->color = gegl_color_new ("black");
|
2016-06-01 22:38:58 +02:00
|
|
|
|
2017-05-22 22:55:25 +02:00
|
|
|
css = gtk_css_provider_new ();
|
|
|
|
gtk_css_provider_load_from_data (css,
|
2018-06-20 12:39:26 +02:00
|
|
|
"GimpColorScale {"
|
|
|
|
" padding: 2px 12px 2px 12px;"
|
2017-05-22 22:55:25 +02:00
|
|
|
" min-width: 24px;"
|
|
|
|
" min-height: 24px;"
|
|
|
|
"}\n"
|
2018-06-20 12:39:26 +02:00
|
|
|
"GimpColorScale contents trough {"
|
|
|
|
" min-width: 20px;"
|
|
|
|
" min-height: 20px;"
|
|
|
|
"}\n"
|
2018-05-01 00:17:27 +02:00
|
|
|
"GimpColorScale contents trough slider {"
|
2018-06-20 12:39:26 +02:00
|
|
|
" min-width: 12px;"
|
|
|
|
" min-height: 12px;"
|
|
|
|
" margin: -6px -6px -6px -6px;"
|
2017-05-22 22:55:25 +02:00
|
|
|
"}",
|
|
|
|
-1, NULL);
|
|
|
|
gtk_style_context_add_provider (gtk_widget_get_style_context (GTK_WIDGET (scale)),
|
|
|
|
GTK_STYLE_PROVIDER (css),
|
|
|
|
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
|
|
|
|
g_object_unref (css);
|
2002-10-29 23:18:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2011-01-02 02:39:12 +01:00
|
|
|
gimp_color_scale_dispose (GObject *object)
|
2002-10-29 23:18:23 +00:00
|
|
|
{
|
2004-07-13 14:55:16 +00:00
|
|
|
GimpColorScale *scale = GIMP_COLOR_SCALE (object);
|
2002-10-29 23:18:23 +00:00
|
|
|
|
2011-01-02 02:39:12 +01:00
|
|
|
gimp_color_scale_set_color_config (scale, NULL);
|
|
|
|
|
|
|
|
G_OBJECT_CLASS (parent_class)->dispose (object);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_color_scale_finalize (GObject *object)
|
|
|
|
{
|
|
|
|
GimpColorScalePrivate *priv = GET_PRIVATE (object);
|
|
|
|
|
|
|
|
g_clear_pointer (&priv->buf, g_free);
|
|
|
|
priv->width = 0;
|
|
|
|
priv->height = 0;
|
|
|
|
priv->rowstride = 0;
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
g_object_unref (priv->color);
|
2002-10-29 23:18:23 +00:00
|
|
|
|
2010-10-15 02:12:33 +02:00
|
|
|
G_OBJECT_CLASS (parent_class)->finalize (object);
|
2002-10-29 23:18:23 +00:00
|
|
|
}
|
|
|
|
|
2011-02-15 18:52:00 +01:00
|
|
|
static void
|
|
|
|
gimp_color_scale_get_property (GObject *object,
|
|
|
|
guint property_id,
|
|
|
|
GValue *value,
|
|
|
|
GParamSpec *pspec)
|
|
|
|
{
|
2011-01-02 02:39:12 +01:00
|
|
|
GimpColorScalePrivate *priv = GET_PRIVATE (object);
|
2011-02-15 18:52:00 +01:00
|
|
|
|
|
|
|
switch (property_id)
|
|
|
|
{
|
|
|
|
case PROP_CHANNEL:
|
2011-01-02 02:39:12 +01:00
|
|
|
g_value_set_enum (value, priv->channel);
|
2011-02-15 18:52:00 +01:00
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_color_scale_set_property (GObject *object,
|
|
|
|
guint property_id,
|
|
|
|
const GValue *value,
|
|
|
|
GParamSpec *pspec)
|
|
|
|
{
|
|
|
|
GimpColorScale *scale = GIMP_COLOR_SCALE (object);
|
|
|
|
|
|
|
|
switch (property_id)
|
|
|
|
{
|
|
|
|
case PROP_CHANNEL:
|
|
|
|
gimp_color_scale_set_channel (scale, g_value_get_enum (value));
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2002-10-29 23:18:23 +00:00
|
|
|
static void
|
|
|
|
gimp_color_scale_size_allocate (GtkWidget *widget,
|
2002-10-29 23:54:02 +00:00
|
|
|
GtkAllocation *allocation)
|
2002-10-29 23:18:23 +00:00
|
|
|
{
|
2011-01-02 02:39:12 +01:00
|
|
|
GimpColorScalePrivate *priv = GET_PRIVATE (widget);
|
|
|
|
GtkRange *range = GTK_RANGE (widget);
|
|
|
|
GdkRectangle range_rect;
|
2002-10-29 23:18:23 +00:00
|
|
|
|
2018-06-20 12:39:26 +02:00
|
|
|
GTK_WIDGET_CLASS (parent_class)->size_allocate (widget, allocation);
|
2002-10-29 23:18:23 +00:00
|
|
|
|
2010-04-19 19:21:07 +02:00
|
|
|
gtk_range_get_range_rect (range, &range_rect);
|
2002-10-30 14:52:58 +00:00
|
|
|
|
2018-06-20 12:39:26 +02:00
|
|
|
if (range_rect.width != priv->width ||
|
|
|
|
range_rect.height != priv->height)
|
2002-10-29 23:18:23 +00:00
|
|
|
{
|
2018-06-20 12:39:26 +02:00
|
|
|
priv->width = range_rect.width;
|
|
|
|
priv->height = range_rect.height;
|
2002-10-29 23:54:02 +00:00
|
|
|
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
/* TODO: we should move to CAIRO_FORMAT_RGBA128F. */
|
|
|
|
priv->rowstride = cairo_format_stride_for_width (CAIRO_FORMAT_RGB24, priv->width);
|
2002-10-29 23:18:23 +00:00
|
|
|
|
2011-01-02 02:39:12 +01:00
|
|
|
g_free (priv->buf);
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
priv->buf = g_new (guchar, 3 * priv->width * priv->height);
|
2002-10-29 23:18:23 +00:00
|
|
|
|
2011-01-02 02:39:12 +01:00
|
|
|
priv->needs_render = TRUE;
|
2002-10-29 23:54:02 +00:00
|
|
|
}
|
2002-10-29 23:18:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static gboolean
|
2010-10-15 11:13:47 +02:00
|
|
|
gimp_color_scale_draw (GtkWidget *widget,
|
|
|
|
cairo_t *cr)
|
2002-10-29 23:18:23 +00:00
|
|
|
{
|
2016-05-27 00:51:32 +02:00
|
|
|
GimpColorScale *scale = GIMP_COLOR_SCALE (widget);
|
|
|
|
GimpColorScalePrivate *priv = GET_PRIVATE (widget);
|
|
|
|
GtkRange *range = GTK_RANGE (widget);
|
2010-12-15 15:33:05 +01:00
|
|
|
GtkStyleContext *context = gtk_widget_get_style_context (widget);
|
2016-05-27 00:51:32 +02:00
|
|
|
GdkRectangle range_rect;
|
|
|
|
GdkRectangle area = { 0, };
|
|
|
|
cairo_surface_t *buffer;
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
guchar *buf = NULL;
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
guchar *src;
|
|
|
|
guchar *dest;
|
2016-05-27 00:51:32 +02:00
|
|
|
gint slider_start;
|
2017-05-22 22:55:25 +02:00
|
|
|
gint slider_end;
|
2018-06-20 12:39:26 +02:00
|
|
|
gint slider_mid;
|
2016-05-27 00:51:32 +02:00
|
|
|
gint slider_size;
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
const Babl *render_space;
|
2002-10-29 23:18:23 +00:00
|
|
|
|
2011-01-02 02:39:12 +01:00
|
|
|
if (! priv->buf)
|
2002-10-29 23:18:23 +00:00
|
|
|
return FALSE;
|
|
|
|
|
2010-04-19 19:21:07 +02:00
|
|
|
gtk_range_get_range_rect (range, &range_rect);
|
2017-05-22 22:55:25 +02:00
|
|
|
gtk_range_get_slider_range (range, &slider_start, &slider_end);
|
2002-10-30 19:54:34 +00:00
|
|
|
|
2018-06-20 12:39:26 +02:00
|
|
|
slider_mid = slider_start + (slider_end - slider_start) / 2;
|
|
|
|
slider_size = 6;
|
2002-10-30 19:54:34 +00:00
|
|
|
|
2011-01-02 02:39:12 +01:00
|
|
|
if (priv->needs_render)
|
2010-10-15 11:09:47 +02:00
|
|
|
{
|
|
|
|
gimp_color_scale_render (scale);
|
|
|
|
|
2011-01-02 02:39:12 +01:00
|
|
|
priv->needs_render = FALSE;
|
2010-10-15 11:09:47 +02:00
|
|
|
}
|
2002-10-30 19:54:34 +00:00
|
|
|
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
render_space = gimp_widget_get_render_space (widget, priv->config);
|
|
|
|
fish_rgb_to_cairo = babl_fish (babl_format_with_space ("R'G'B' u8", priv->format),
|
|
|
|
babl_format_with_space ("cairo-RGB24", render_space)),
|
2016-05-27 00:51:32 +02:00
|
|
|
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
src = priv->buf;
|
|
|
|
buf = g_new (guchar, priv->rowstride * priv->height);
|
|
|
|
dest = buf;
|
|
|
|
/* We convert per line because the cairo rowstride may be bigger than the
|
|
|
|
* real contents.
|
|
|
|
*/
|
|
|
|
for (gint i = 0; i < priv->height; i++)
|
2016-05-27 00:51:32 +02:00
|
|
|
{
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
babl_process (fish_rgb_to_cairo, src, dest, priv->width);
|
|
|
|
src += 3 * priv->width;
|
|
|
|
dest += priv->rowstride;
|
2016-05-27 00:51:32 +02:00
|
|
|
}
|
2010-10-15 11:09:47 +02:00
|
|
|
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
buffer = cairo_image_surface_create_for_data (buf,
|
|
|
|
CAIRO_FORMAT_RGB24,
|
|
|
|
priv->width,
|
|
|
|
priv->height,
|
|
|
|
priv->rowstride);
|
|
|
|
cairo_surface_set_user_data (buffer, NULL, buf, (cairo_destroy_func_t) g_free);
|
|
|
|
|
2010-10-15 11:09:47 +02:00
|
|
|
switch (gtk_orientable_get_orientation (GTK_ORIENTABLE (range)))
|
2002-10-30 02:02:18 +00:00
|
|
|
{
|
2010-10-15 11:09:47 +02:00
|
|
|
case GTK_ORIENTATION_HORIZONTAL:
|
|
|
|
cairo_set_source_surface (cr, buffer,
|
2018-06-20 12:39:26 +02:00
|
|
|
range_rect.x, range_rect.y);
|
2010-10-15 11:09:47 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case GTK_ORIENTATION_VERTICAL:
|
|
|
|
cairo_set_source_surface (cr, buffer,
|
2018-06-20 12:39:26 +02:00
|
|
|
range_rect.x, range_rect.y);
|
2010-10-15 11:09:47 +02:00
|
|
|
break;
|
2002-10-30 02:02:18 +00:00
|
|
|
}
|
|
|
|
|
2010-10-15 11:09:47 +02:00
|
|
|
cairo_surface_destroy (buffer);
|
2018-05-20 02:06:47 +02:00
|
|
|
|
|
|
|
if (! gtk_widget_is_sensitive (widget))
|
|
|
|
{
|
|
|
|
static cairo_pattern_t *pattern = NULL;
|
|
|
|
|
|
|
|
if (! pattern)
|
|
|
|
{
|
|
|
|
static const guchar stipple[] = { 0, 255, 0, 0,
|
|
|
|
255, 0, 0, 0 };
|
|
|
|
cairo_surface_t *surface;
|
|
|
|
gint stride;
|
|
|
|
|
|
|
|
stride = cairo_format_stride_for_width (CAIRO_FORMAT_A8, 2);
|
|
|
|
|
|
|
|
surface = cairo_image_surface_create_for_data ((guchar *) stipple,
|
|
|
|
CAIRO_FORMAT_A8,
|
|
|
|
2, 2, stride);
|
|
|
|
pattern = cairo_pattern_create_for_surface (surface);
|
|
|
|
cairo_surface_destroy (surface);
|
|
|
|
|
|
|
|
cairo_pattern_set_extend (pattern, CAIRO_EXTEND_REPEAT);
|
|
|
|
}
|
|
|
|
|
|
|
|
cairo_mask (cr, pattern);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
cairo_paint (cr);
|
|
|
|
}
|
2010-10-15 11:09:47 +02:00
|
|
|
|
2009-10-17 18:51:48 +02:00
|
|
|
if (gtk_widget_has_focus (widget))
|
2010-12-15 15:33:05 +01:00
|
|
|
gtk_render_focus (context, cr,
|
2018-06-20 12:39:26 +02:00
|
|
|
0, 0,
|
|
|
|
gtk_widget_get_allocated_width (widget),
|
|
|
|
gtk_widget_get_allocated_height (widget));
|
2002-10-30 02:02:18 +00:00
|
|
|
|
2009-07-15 01:53:30 +02:00
|
|
|
switch (gtk_orientable_get_orientation (GTK_ORIENTABLE (range)))
|
2002-10-30 02:02:18 +00:00
|
|
|
{
|
|
|
|
case GTK_ORIENTATION_HORIZONTAL:
|
2018-06-20 12:39:26 +02:00
|
|
|
area.x = slider_mid - slider_size;
|
|
|
|
area.y = range_rect.y;
|
|
|
|
area.width = 2 * slider_size;
|
|
|
|
area.height = range_rect.height;
|
2002-10-30 02:02:18 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case GTK_ORIENTATION_VERTICAL:
|
2018-06-20 12:39:26 +02:00
|
|
|
area.x = range_rect.x;
|
|
|
|
area.y = slider_mid - slider_size;
|
|
|
|
area.width = range_rect.width;
|
|
|
|
area.height = 2 * slider_size;
|
2002-10-30 02:02:18 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2010-10-15 11:09:47 +02:00
|
|
|
if (gtk_widget_is_sensitive (widget))
|
2010-12-15 15:33:05 +01:00
|
|
|
cairo_set_source_rgb (cr, 0.0, 0.0, 0.0);
|
2010-10-15 11:09:47 +02:00
|
|
|
else
|
2010-12-15 15:33:05 +01:00
|
|
|
cairo_set_source_rgb (cr, 0.2, 0.2, 0.2);
|
2010-10-15 11:09:47 +02:00
|
|
|
|
|
|
|
switch (gtk_orientable_get_orientation (GTK_ORIENTABLE (range)))
|
2002-10-30 02:02:18 +00:00
|
|
|
{
|
2010-10-15 11:09:47 +02:00
|
|
|
case GTK_ORIENTATION_HORIZONTAL:
|
|
|
|
cairo_move_to (cr, area.x, area.y);
|
|
|
|
cairo_line_to (cr, area.x + area.width, area.y);
|
|
|
|
cairo_line_to (cr,
|
|
|
|
area.x + area.width / 2 + 0.5,
|
2018-06-20 12:39:26 +02:00
|
|
|
area.y + slider_size);
|
2010-10-15 11:09:47 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case GTK_ORIENTATION_VERTICAL:
|
|
|
|
cairo_move_to (cr, area.x, area.y);
|
|
|
|
cairo_line_to (cr, area.x, area.y + area.height);
|
|
|
|
cairo_line_to (cr,
|
2018-06-20 12:39:26 +02:00
|
|
|
area.x + slider_size,
|
2010-10-15 11:09:47 +02:00
|
|
|
area.y + area.height / 2 + 0.5);
|
|
|
|
break;
|
2002-10-30 02:02:18 +00:00
|
|
|
}
|
2002-10-29 23:18:23 +00:00
|
|
|
|
2010-10-15 11:09:47 +02:00
|
|
|
cairo_close_path (cr);
|
|
|
|
cairo_fill (cr);
|
|
|
|
|
|
|
|
if (gtk_widget_is_sensitive (widget))
|
2010-12-15 15:33:05 +01:00
|
|
|
cairo_set_source_rgb (cr, 1.0, 1.0, 1.0);
|
2010-10-15 11:09:47 +02:00
|
|
|
else
|
2010-12-15 15:33:05 +01:00
|
|
|
cairo_set_source_rgb (cr, 0.8, 0.8, 0.8);
|
2010-10-15 11:09:47 +02:00
|
|
|
|
|
|
|
switch (gtk_orientable_get_orientation (GTK_ORIENTABLE (range)))
|
|
|
|
{
|
|
|
|
case GTK_ORIENTATION_HORIZONTAL:
|
|
|
|
cairo_move_to (cr, area.x, area.y + area.height);
|
|
|
|
cairo_line_to (cr, area.x + area.width, area.y + area.height);
|
|
|
|
cairo_line_to (cr,
|
|
|
|
area.x + area.width / 2 + 0.5,
|
2018-06-20 12:39:26 +02:00
|
|
|
area.y + area.height - slider_size);
|
2010-10-15 11:09:47 +02:00
|
|
|
break;
|
|
|
|
|
|
|
|
case GTK_ORIENTATION_VERTICAL:
|
|
|
|
cairo_move_to (cr, area.x + area.width, area.y);
|
|
|
|
cairo_line_to (cr, area.x + area.width, area.y + area.height);
|
|
|
|
cairo_line_to (cr,
|
2018-06-20 12:39:26 +02:00
|
|
|
area.x + area.width - slider_size,
|
2010-10-15 11:09:47 +02:00
|
|
|
area.y + area.height / 2 + 0.5);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
cairo_close_path (cr);
|
|
|
|
cairo_fill (cr);
|
|
|
|
|
2002-10-29 23:18:23 +00:00
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2003-02-26 12:48:48 +00:00
|
|
|
/**
|
|
|
|
* gimp_color_scale_new:
|
|
|
|
* @orientation: the scale's orientation (horizontal or vertical)
|
|
|
|
* @channel: the scale's color channel
|
2003-12-05 15:55:15 +00:00
|
|
|
*
|
2003-02-26 12:48:48 +00:00
|
|
|
* Creates a new #GimpColorScale widget.
|
2003-12-05 15:55:15 +00:00
|
|
|
*
|
2019-08-03 00:10:14 +02:00
|
|
|
* Returns: a new #GimpColorScale widget
|
2003-02-26 12:48:48 +00:00
|
|
|
**/
|
2002-10-29 23:18:23 +00:00
|
|
|
GtkWidget *
|
2002-10-29 23:54:02 +00:00
|
|
|
gimp_color_scale_new (GtkOrientation orientation,
|
2002-10-31 12:48:19 +00:00
|
|
|
GimpColorSelectorChannel channel)
|
2002-10-29 23:54:02 +00:00
|
|
|
{
|
2009-07-15 01:53:30 +02:00
|
|
|
GimpColorScale *scale = g_object_new (GIMP_TYPE_COLOR_SCALE,
|
|
|
|
"orientation", orientation,
|
2011-02-15 18:52:00 +01:00
|
|
|
"channel", channel,
|
2009-07-15 01:53:30 +02:00
|
|
|
NULL);
|
2002-10-29 23:54:02 +00:00
|
|
|
|
2009-10-17 18:51:48 +02:00
|
|
|
gtk_range_set_flippable (GTK_RANGE (scale),
|
|
|
|
orientation == GTK_ORIENTATION_HORIZONTAL);
|
2003-12-05 15:55:15 +00:00
|
|
|
|
2002-10-30 00:21:31 +00:00
|
|
|
return GTK_WIDGET (scale);
|
2002-10-29 23:54:02 +00:00
|
|
|
}
|
|
|
|
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
/**
|
|
|
|
* gimp_color_scale_set_format:
|
|
|
|
* @scale: a #GimpColorScale widget
|
|
|
|
* @format: the Babl format represented by @scale.
|
|
|
|
*
|
|
|
|
* Changes the color format displayed by the @scale.
|
|
|
|
**/
|
|
|
|
void
|
|
|
|
gimp_color_scale_set_format (GimpColorScale *scale,
|
|
|
|
const Babl *format)
|
|
|
|
{
|
|
|
|
if (scale->priv->format != format)
|
|
|
|
{
|
|
|
|
scale->priv->format = format;
|
|
|
|
fish_lch_to_rgb = babl_fish (babl_format ("CIE LCH(ab) double"),
|
|
|
|
babl_format_with_space ("R'G'B' double", format));
|
|
|
|
fish_hsv_to_rgb = babl_fish (babl_format_with_space ("HSV double", format),
|
|
|
|
babl_format_with_space ("R'G'B' double", format));
|
|
|
|
scale->priv->needs_render = TRUE;
|
|
|
|
gtk_widget_queue_draw (GTK_WIDGET (scale));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-02-26 12:48:48 +00:00
|
|
|
/**
|
|
|
|
* gimp_color_scale_set_channel:
|
|
|
|
* @scale: a #GimpColorScale widget
|
|
|
|
* @channel: the new color channel
|
2003-12-05 15:55:15 +00:00
|
|
|
*
|
2003-02-26 12:48:48 +00:00
|
|
|
* Changes the color channel displayed by the @scale.
|
|
|
|
**/
|
2002-10-29 23:54:02 +00:00
|
|
|
void
|
|
|
|
gimp_color_scale_set_channel (GimpColorScale *scale,
|
|
|
|
GimpColorSelectorChannel channel)
|
|
|
|
{
|
2011-01-02 02:39:12 +01:00
|
|
|
GimpColorScalePrivate *priv;
|
|
|
|
|
2002-10-29 23:54:02 +00:00
|
|
|
g_return_if_fail (GIMP_IS_COLOR_SCALE (scale));
|
|
|
|
|
2011-01-02 02:39:12 +01:00
|
|
|
priv = GET_PRIVATE (scale);
|
|
|
|
|
|
|
|
if (channel != priv->channel)
|
2002-10-29 23:54:02 +00:00
|
|
|
{
|
2011-01-02 02:39:12 +01:00
|
|
|
priv->channel = channel;
|
2002-10-29 23:54:02 +00:00
|
|
|
|
2011-01-02 02:39:12 +01:00
|
|
|
priv->needs_render = TRUE;
|
2002-10-30 14:52:58 +00:00
|
|
|
gtk_widget_queue_draw (GTK_WIDGET (scale));
|
2011-02-15 18:52:00 +01:00
|
|
|
|
|
|
|
g_object_notify (G_OBJECT (scale), "channel");
|
2002-10-29 23:54:02 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-02-26 12:48:48 +00:00
|
|
|
/**
|
|
|
|
* gimp_color_scale_set_color:
|
|
|
|
* @scale: a #GimpColorScale widget
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
* @color: the new color.
|
2003-12-05 15:55:15 +00:00
|
|
|
*
|
2003-02-26 12:48:48 +00:00
|
|
|
* Changes the color value of the @scale.
|
|
|
|
**/
|
2002-10-29 23:54:02 +00:00
|
|
|
void
|
|
|
|
gimp_color_scale_set_color (GimpColorScale *scale,
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
GeglColor *color)
|
2002-10-29 23:18:23 +00:00
|
|
|
{
|
2011-01-02 02:39:12 +01:00
|
|
|
GimpColorScalePrivate *priv;
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
GeglColor *old_color;
|
2011-01-02 02:39:12 +01:00
|
|
|
|
2002-10-29 23:54:02 +00:00
|
|
|
g_return_if_fail (GIMP_IS_COLOR_SCALE (scale));
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
g_return_if_fail (GEGL_IS_COLOR (color));
|
2002-10-29 23:18:23 +00:00
|
|
|
|
2011-01-02 02:39:12 +01:00
|
|
|
priv = GET_PRIVATE (scale);
|
|
|
|
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
old_color = priv->color;
|
|
|
|
priv->color = gegl_color_duplicate (color);
|
2002-10-29 23:18:23 +00:00
|
|
|
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
if (! gimp_color_is_perceptually_identical (old_color, priv->color))
|
|
|
|
{
|
|
|
|
priv->needs_render = TRUE;
|
|
|
|
gtk_widget_queue_draw (GTK_WIDGET (scale));
|
|
|
|
}
|
|
|
|
|
|
|
|
g_object_unref (old_color);
|
2002-10-29 23:54:02 +00:00
|
|
|
}
|
|
|
|
|
2016-05-27 00:51:32 +02:00
|
|
|
/**
|
|
|
|
* gimp_color_scale_set_color_config:
|
|
|
|
* @scale: a #GimpColorScale widget.
|
|
|
|
* @config: a #GimpColorConfig object.
|
|
|
|
*
|
|
|
|
* Sets the color management configuration to use with this color scale.
|
|
|
|
*
|
|
|
|
* Since: 2.10
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
gimp_color_scale_set_color_config (GimpColorScale *scale,
|
|
|
|
GimpColorConfig *config)
|
|
|
|
{
|
|
|
|
GimpColorScalePrivate *priv;
|
|
|
|
|
|
|
|
g_return_if_fail (GIMP_IS_COLOR_SCALE (scale));
|
|
|
|
g_return_if_fail (config == NULL || GIMP_IS_COLOR_CONFIG (config));
|
|
|
|
|
|
|
|
priv = GET_PRIVATE (scale);
|
|
|
|
|
2016-05-31 12:24:58 +02:00
|
|
|
if (config != priv->config)
|
2016-05-27 00:51:32 +02:00
|
|
|
{
|
2016-05-31 12:24:58 +02:00
|
|
|
if (priv->config)
|
2016-05-27 00:51:32 +02:00
|
|
|
{
|
2016-05-31 12:24:58 +02:00
|
|
|
g_signal_handlers_disconnect_by_func (priv->config,
|
2017-05-17 19:28:40 +02:00
|
|
|
gimp_color_scale_notify_config,
|
2016-05-31 12:24:58 +02:00
|
|
|
scale);
|
2016-05-27 00:51:32 +02:00
|
|
|
}
|
|
|
|
|
2018-06-01 12:59:52 +02:00
|
|
|
g_set_object (&priv->config, config);
|
2016-05-27 00:51:32 +02:00
|
|
|
|
2016-05-31 12:24:58 +02:00
|
|
|
if (priv->config)
|
|
|
|
{
|
2017-05-17 19:28:40 +02:00
|
|
|
g_signal_connect (priv->config, "notify",
|
|
|
|
G_CALLBACK (gimp_color_scale_notify_config),
|
|
|
|
scale);
|
|
|
|
|
|
|
|
gimp_color_scale_notify_config (priv->config, NULL, scale);
|
2016-05-31 12:24:58 +02:00
|
|
|
}
|
2016-05-27 00:51:32 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2002-10-31 12:13:36 +00:00
|
|
|
/* as in gtkrange.c */
|
|
|
|
static gboolean
|
|
|
|
should_invert (GtkRange *range)
|
2003-12-05 15:55:15 +00:00
|
|
|
{
|
2009-10-17 18:51:48 +02:00
|
|
|
gboolean inverted = gtk_range_get_inverted (range);
|
|
|
|
gboolean flippable = gtk_range_get_flippable (range);
|
|
|
|
|
2009-07-15 01:53:30 +02:00
|
|
|
if (gtk_orientable_get_orientation (GTK_ORIENTABLE (range)) ==
|
|
|
|
GTK_ORIENTATION_HORIZONTAL)
|
2009-10-17 18:51:48 +02:00
|
|
|
{
|
|
|
|
return
|
|
|
|
(inverted && !flippable) ||
|
|
|
|
(inverted && flippable &&
|
|
|
|
gtk_widget_get_direction (GTK_WIDGET (range)) == GTK_TEXT_DIR_LTR) ||
|
|
|
|
(!inverted && flippable &&
|
|
|
|
gtk_widget_get_direction (GTK_WIDGET (range)) == GTK_TEXT_DIR_RTL);
|
|
|
|
}
|
2002-10-31 12:13:36 +00:00
|
|
|
else
|
2009-10-17 18:51:48 +02:00
|
|
|
{
|
|
|
|
return inverted;
|
|
|
|
}
|
2002-10-31 12:13:36 +00:00
|
|
|
}
|
|
|
|
|
2002-10-29 23:54:02 +00:00
|
|
|
static void
|
|
|
|
gimp_color_scale_render (GimpColorScale *scale)
|
|
|
|
{
|
2017-05-17 19:28:40 +02:00
|
|
|
GimpColorScalePrivate *priv = GET_PRIVATE (scale);
|
|
|
|
GtkRange *range = GTK_RANGE (scale);
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
gdouble rgb[4];
|
|
|
|
gdouble hsv[3];
|
|
|
|
gdouble lch[3];
|
2017-05-17 19:28:40 +02:00
|
|
|
gint multiplier = 1;
|
|
|
|
guint x, y;
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
gdouble *channel_value = NULL;
|
2017-05-17 19:28:40 +02:00
|
|
|
gboolean from_hsv = FALSE;
|
|
|
|
gboolean from_lch = FALSE;
|
|
|
|
gboolean invert;
|
|
|
|
guchar *buf;
|
|
|
|
guchar *d;
|
2002-10-30 02:02:18 +00:00
|
|
|
|
2011-01-02 02:39:12 +01:00
|
|
|
if ((buf = priv->buf) == NULL)
|
2002-10-30 02:02:18 +00:00
|
|
|
return;
|
|
|
|
|
2011-01-02 02:39:12 +01:00
|
|
|
if (priv->channel == GIMP_COLOR_SELECTOR_ALPHA)
|
2002-10-31 10:55:51 +00:00
|
|
|
{
|
|
|
|
gimp_color_scale_render_alpha (scale);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
gegl_color_get_pixel (priv->color, babl_format_with_space ("R'G'B'A double", priv->format), rgb);
|
|
|
|
gegl_color_get_pixel (priv->color, babl_format_with_space ("HSV double", priv->format), hsv);
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
gegl_color_get_pixel (priv->color, babl_format ("CIE LCH(ab) double"), lch);
|
2002-10-30 14:52:58 +00:00
|
|
|
|
2011-01-02 02:39:12 +01:00
|
|
|
switch (priv->channel)
|
2002-10-30 14:52:58 +00:00
|
|
|
{
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
case GIMP_COLOR_SELECTOR_HUE: channel_value = &hsv[0]; break;
|
|
|
|
case GIMP_COLOR_SELECTOR_SATURATION: channel_value = &hsv[1]; break;
|
|
|
|
case GIMP_COLOR_SELECTOR_VALUE: channel_value = &hsv[2]; break;
|
|
|
|
|
|
|
|
case GIMP_COLOR_SELECTOR_RED: channel_value = &rgb[0]; break;
|
|
|
|
case GIMP_COLOR_SELECTOR_GREEN: channel_value = &rgb[1]; break;
|
|
|
|
case GIMP_COLOR_SELECTOR_BLUE: channel_value = &rgb[2]; break;
|
|
|
|
case GIMP_COLOR_SELECTOR_ALPHA: channel_value = &rgb[3]; break;
|
|
|
|
|
|
|
|
case GIMP_COLOR_SELECTOR_LCH_LIGHTNESS: channel_value = &lch[0]; break;
|
|
|
|
case GIMP_COLOR_SELECTOR_LCH_CHROMA: channel_value = &lch[1]; break;
|
|
|
|
case GIMP_COLOR_SELECTOR_LCH_HUE: channel_value = &lch[2]; break;
|
2002-10-30 14:52:58 +00:00
|
|
|
}
|
|
|
|
|
2011-01-02 02:39:12 +01:00
|
|
|
switch (priv->channel)
|
2002-10-30 14:52:58 +00:00
|
|
|
{
|
|
|
|
case GIMP_COLOR_SELECTOR_HUE:
|
|
|
|
case GIMP_COLOR_SELECTOR_SATURATION:
|
|
|
|
case GIMP_COLOR_SELECTOR_VALUE:
|
2017-05-17 19:28:40 +02:00
|
|
|
from_hsv = TRUE;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case GIMP_COLOR_SELECTOR_LCH_LIGHTNESS:
|
|
|
|
multiplier = 100;
|
|
|
|
from_lch = TRUE;
|
|
|
|
break;
|
|
|
|
case GIMP_COLOR_SELECTOR_LCH_CHROMA:
|
2017-06-01 04:38:19 -04:00
|
|
|
multiplier = 200;
|
2017-05-17 19:28:40 +02:00
|
|
|
from_lch = TRUE;
|
|
|
|
break;
|
|
|
|
case GIMP_COLOR_SELECTOR_LCH_HUE:
|
|
|
|
multiplier = 360;
|
|
|
|
from_lch = TRUE;
|
2002-10-30 14:52:58 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2002-10-31 12:13:36 +00:00
|
|
|
invert = should_invert (range);
|
|
|
|
|
2009-07-15 01:53:30 +02:00
|
|
|
switch (gtk_orientable_get_orientation (GTK_ORIENTABLE (range)))
|
2002-10-30 02:02:18 +00:00
|
|
|
{
|
2002-10-31 10:55:51 +00:00
|
|
|
case GTK_ORIENTATION_HORIZONTAL:
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
for (x = 0, d = buf; x < priv->width; x++, d += 3)
|
2002-10-30 14:52:58 +00:00
|
|
|
{
|
2011-01-02 02:39:12 +01:00
|
|
|
gdouble value = (gdouble) x * multiplier / (gdouble) (priv->width - 1);
|
2002-10-31 12:13:36 +00:00
|
|
|
|
|
|
|
if (invert)
|
2017-05-17 19:28:40 +02:00
|
|
|
value = multiplier - value;
|
2002-10-31 12:13:36 +00:00
|
|
|
|
|
|
|
*channel_value = value;
|
2002-10-30 14:52:58 +00:00
|
|
|
|
2017-05-17 19:28:40 +02:00
|
|
|
if (from_hsv)
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
babl_process (fish_hsv_to_rgb, &hsv, &rgb, 1);
|
2017-05-17 19:28:40 +02:00
|
|
|
else if (from_lch)
|
|
|
|
babl_process (fish_lch_to_rgb, &lch, &rgb, 1);
|
2002-10-30 14:52:58 +00:00
|
|
|
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
/* This is only checking if a color is within the sRGB gamut. I want
|
|
|
|
* to check compared to the image's space (anySpace) or softproof
|
|
|
|
* space. TODO.
|
|
|
|
*/
|
|
|
|
if (rgb[0] < 0.0 || rgb[0] > 1.0 ||
|
|
|
|
rgb[1] < 0.0 || rgb[1] > 1.0 ||
|
|
|
|
rgb[2] < 0.0 || rgb[2] > 1.0)
|
2017-05-17 19:28:40 +02:00
|
|
|
{
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
d[0] = priv->oog_color[0];
|
|
|
|
d[1] = priv->oog_color[1];
|
|
|
|
d[2] = priv->oog_color[2];
|
2017-05-17 19:28:40 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
d[0] = rgb[0] * 255;
|
|
|
|
d[1] = rgb[1] * 255;
|
|
|
|
d[2] = rgb[2] * 255;
|
2017-05-17 19:28:40 +02:00
|
|
|
}
|
2002-10-30 02:02:18 +00:00
|
|
|
}
|
|
|
|
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
d = buf + priv->width * 3;
|
2011-01-02 02:39:12 +01:00
|
|
|
for (y = 1; y < priv->height; y++)
|
2002-10-30 14:52:58 +00:00
|
|
|
{
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
memcpy (d, buf, priv->width * 3);
|
|
|
|
d += priv->width * 3;
|
2002-10-30 14:52:58 +00:00
|
|
|
}
|
2002-10-31 10:55:51 +00:00
|
|
|
break;
|
2002-10-30 14:52:58 +00:00
|
|
|
|
2002-10-31 10:55:51 +00:00
|
|
|
case GTK_ORIENTATION_VERTICAL:
|
2011-01-02 02:39:12 +01:00
|
|
|
for (y = 0; y < priv->height; y++)
|
2002-10-30 14:52:58 +00:00
|
|
|
{
|
2011-01-02 02:39:12 +01:00
|
|
|
gdouble value = (gdouble) y * multiplier / (gdouble) (priv->height - 1);
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
guchar u8rgb[3];
|
2002-10-31 12:13:36 +00:00
|
|
|
|
|
|
|
if (invert)
|
2017-05-17 19:28:40 +02:00
|
|
|
value = multiplier - value;
|
2002-10-31 12:13:36 +00:00
|
|
|
|
|
|
|
*channel_value = value;
|
2003-12-05 15:55:15 +00:00
|
|
|
|
2017-05-17 19:28:40 +02:00
|
|
|
if (from_hsv)
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
babl_process (fish_hsv_to_rgb, &hsv, &rgb, 1);
|
2017-05-17 19:28:40 +02:00
|
|
|
else if (from_lch)
|
|
|
|
babl_process (fish_lch_to_rgb, &lch, &rgb, 1);
|
2002-10-30 14:52:58 +00:00
|
|
|
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
if (rgb[0] < 0.0 || rgb[0] > 1.0 ||
|
|
|
|
rgb[1] < 0.0 || rgb[1] > 1.0 ||
|
|
|
|
rgb[2] < 0.0 || rgb[2] > 1.0)
|
2017-05-17 19:28:40 +02:00
|
|
|
{
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
u8rgb[0] = priv->oog_color[0];
|
|
|
|
u8rgb[1] = priv->oog_color[1];
|
|
|
|
u8rgb[2] = priv->oog_color[2];
|
2017-05-17 19:28:40 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
app, libgimpwidgets, modules: color selectors are now partly space-invaded.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
2023-12-12 17:01:17 +09:00
|
|
|
u8rgb[0] = rgb[0] * 255;
|
|
|
|
u8rgb[1] = rgb[1] * 255;
|
|
|
|
u8rgb[2] = rgb[2] * 255;
|
2017-05-17 19:28:40 +02:00
|
|
|
}
|
2002-10-30 14:52:58 +00:00
|
|
|
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
for (x = 0, d = buf; x < priv->width; x++, d += 3)
|
|
|
|
{
|
|
|
|
d[0] = u8rgb[0];
|
|
|
|
d[1] = u8rgb[1];
|
|
|
|
d[2] = u8rgb[2];
|
|
|
|
}
|
2002-10-30 14:52:58 +00:00
|
|
|
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
buf += priv->width * 3;
|
2002-10-30 14:52:58 +00:00
|
|
|
}
|
2002-10-31 10:55:51 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
gimp_color_scale_render_alpha (GimpColorScale *scale)
|
|
|
|
{
|
2011-01-02 02:39:12 +01:00
|
|
|
GimpColorScalePrivate *priv = GET_PRIVATE (scale);
|
|
|
|
GtkRange *range = GTK_RANGE (scale);
|
2024-02-16 22:05:23 +01:00
|
|
|
gdouble rgb[3];
|
2011-01-02 02:39:12 +01:00
|
|
|
gboolean invert;
|
|
|
|
gdouble a;
|
|
|
|
guint x, y;
|
|
|
|
guchar *buf;
|
|
|
|
guchar *d, *l;
|
2002-10-31 12:13:36 +00:00
|
|
|
|
|
|
|
invert = should_invert (range);
|
2002-10-31 10:55:51 +00:00
|
|
|
|
2011-01-02 02:39:12 +01:00
|
|
|
buf = priv->buf;
|
2024-02-16 22:05:23 +01:00
|
|
|
gegl_color_get_pixel (priv->color, babl_format_with_space ("R'G'B' double", priv->format), rgb);
|
2002-10-31 10:55:51 +00:00
|
|
|
|
2009-07-15 01:53:30 +02:00
|
|
|
switch (gtk_orientable_get_orientation (GTK_ORIENTABLE (range)))
|
2002-10-31 10:55:51 +00:00
|
|
|
{
|
|
|
|
case GTK_ORIENTATION_HORIZONTAL:
|
|
|
|
{
|
|
|
|
guchar *light;
|
|
|
|
guchar *dark;
|
|
|
|
|
|
|
|
light = buf;
|
|
|
|
/* this won't work correctly for very thin scales */
|
2011-01-02 02:39:12 +01:00
|
|
|
dark = (priv->height > GIMP_CHECK_SIZE_SM ?
|
2024-02-16 22:05:23 +01:00
|
|
|
buf + GIMP_CHECK_SIZE_SM * 3 * priv->width : light);
|
2003-12-05 15:55:15 +00:00
|
|
|
|
2011-01-02 02:39:12 +01:00
|
|
|
for (x = 0, d = light, l = dark; x < priv->width; x++)
|
2002-10-31 10:55:51 +00:00
|
|
|
{
|
|
|
|
if ((x % GIMP_CHECK_SIZE_SM) == 0)
|
|
|
|
{
|
|
|
|
guchar *t;
|
2003-12-05 15:55:15 +00:00
|
|
|
|
2002-10-31 10:55:51 +00:00
|
|
|
t = d;
|
|
|
|
d = l;
|
|
|
|
l = t;
|
|
|
|
}
|
2003-12-05 15:55:15 +00:00
|
|
|
|
2011-01-02 02:39:12 +01:00
|
|
|
a = (gdouble) x / (gdouble) (priv->width - 1);
|
2002-10-31 12:13:36 +00:00
|
|
|
|
|
|
|
if (invert)
|
|
|
|
a = 1.0 - a;
|
2003-12-05 15:55:15 +00:00
|
|
|
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
l[0] = (GIMP_CHECK_LIGHT + (rgb[0] - GIMP_CHECK_LIGHT) * a) * 255.999;
|
|
|
|
l[1] = (GIMP_CHECK_LIGHT + (rgb[1] - GIMP_CHECK_LIGHT) * a) * 255.999;
|
|
|
|
l[2] = (GIMP_CHECK_LIGHT + (rgb[2] - GIMP_CHECK_LIGHT) * a) * 255.999;
|
|
|
|
l += 3;
|
|
|
|
|
|
|
|
d[0] = (GIMP_CHECK_DARK + (rgb[0] - GIMP_CHECK_DARK) * a) * 255.999;
|
2024-02-16 22:05:23 +01:00
|
|
|
d[1] = (GIMP_CHECK_DARK + (rgb[1] - GIMP_CHECK_DARK) * a) * 255.999;
|
|
|
|
d[2] = (GIMP_CHECK_DARK + (rgb[2] - GIMP_CHECK_DARK) * a) * 255.999;
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
d += 3;
|
2002-10-31 10:55:51 +00:00
|
|
|
}
|
|
|
|
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
for (y = 0, d = buf; y < priv->height; y++, d += 3 * priv->width)
|
2002-10-31 10:55:51 +00:00
|
|
|
{
|
|
|
|
if (y == 0 || y == GIMP_CHECK_SIZE_SM)
|
|
|
|
continue;
|
2003-12-05 15:55:15 +00:00
|
|
|
|
2002-10-31 10:55:51 +00:00
|
|
|
if ((y / GIMP_CHECK_SIZE_SM) & 1)
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
memcpy (d, dark, 3 * priv->width);
|
2002-10-31 10:55:51 +00:00
|
|
|
else
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
memcpy (d, light, 3 * priv->width);
|
2002-10-31 10:55:51 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
2003-12-05 15:55:15 +00:00
|
|
|
|
2002-10-31 10:55:51 +00:00
|
|
|
case GTK_ORIENTATION_VERTICAL:
|
|
|
|
{
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
guchar light[3] = {0xff, 0xff, 0xff};
|
|
|
|
guchar dark[3] = {0xff, 0xff, 0xff};
|
2002-10-31 10:55:51 +00:00
|
|
|
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
for (y = 0, d = buf; y < priv->height; y++, d += priv->width * 3)
|
2002-10-31 10:55:51 +00:00
|
|
|
{
|
2011-01-02 02:39:12 +01:00
|
|
|
a = (gdouble) y / (gdouble) (priv->height - 1);
|
2003-12-05 15:55:15 +00:00
|
|
|
|
2002-10-31 12:13:36 +00:00
|
|
|
if (invert)
|
|
|
|
a = 1.0 - a;
|
|
|
|
|
2024-02-16 22:05:23 +01:00
|
|
|
light[0] = (GIMP_CHECK_LIGHT + (rgb[0] - GIMP_CHECK_LIGHT) * a) * 255.999;
|
app, libgimpwidgets: "Scales" color selection now space-aware.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
2023-12-17 10:32:48 +09:00
|
|
|
light[1] = (GIMP_CHECK_LIGHT + (rgb[1] - GIMP_CHECK_LIGHT) * a) * 255.999;
|
|
|
|
light[2] = (GIMP_CHECK_LIGHT + (rgb[2] - GIMP_CHECK_LIGHT) * a) * 255.999;
|
|
|
|
|
|
|
|
dark[0] = (GIMP_CHECK_DARK + (rgb[0] - GIMP_CHECK_DARK) * a) * 255.999;
|
|
|
|
dark[1] = (GIMP_CHECK_DARK + (rgb[1] - GIMP_CHECK_DARK) * a) * 255.999;
|
|
|
|
dark[2] = (GIMP_CHECK_DARK + (rgb[2] - GIMP_CHECK_DARK) * a) * 255.999;
|
|
|
|
|
|
|
|
for (x = 0, l = d; x < priv->width; x++, l += 3)
|
2002-10-31 10:55:51 +00:00
|
|
|
{
|
|
|
|
if (((x / GIMP_CHECK_SIZE_SM) ^ (y / GIMP_CHECK_SIZE_SM)) & 1)
|
|
|
|
{
|
|
|
|
l[0] = light[0];
|
|
|
|
l[1] = light[1];
|
|
|
|
l[2] = light[2];
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
l[0] = dark[0];
|
|
|
|
l[1] = dark[1];
|
|
|
|
l[2] = dark[2];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
2002-10-30 02:02:18 +00:00
|
|
|
}
|
2002-10-29 23:18:23 +00:00
|
|
|
}
|
2005-09-20 15:04:04 +00:00
|
|
|
|
2017-05-17 19:28:40 +02:00
|
|
|
static void
|
|
|
|
gimp_color_scale_notify_config (GimpColorConfig *config,
|
|
|
|
const GParamSpec *pspec,
|
|
|
|
GimpColorScale *scale)
|
|
|
|
{
|
|
|
|
GimpColorScalePrivate *priv = GET_PRIVATE (scale);
|
2023-11-22 23:38:25 +01:00
|
|
|
GeglColor *color;
|
2017-05-17 19:28:40 +02:00
|
|
|
|
2023-11-22 23:38:25 +01:00
|
|
|
color = gimp_color_config_get_out_of_gamut_color (config);
|
|
|
|
/* TODO: shouldn't this be color-managed too, using the target space into
|
|
|
|
* consideration?
|
|
|
|
*/
|
|
|
|
gegl_color_get_pixel (color, babl_format ("R'G'B' u8"), priv->oog_color);
|
2011-01-02 02:39:12 +01:00
|
|
|
priv->needs_render = TRUE;
|
2023-11-22 23:38:25 +01:00
|
|
|
|
|
|
|
g_object_unref (color);
|
2017-05-17 19:28:40 +02:00
|
|
|
}
|